Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by jason

  1. Sorry we are all tirelessly working. Final samples arrive soon for approval, and I'll have dates locked in as soon as I give my thumbs up. We will start to share regular updates. Promise

    • Thanks 1
  2. 5 minutes ago, jessicajonny said:

    I don't understand. Is it a firmware or hardware issue with Flirc? What is the maximum age of my FLIRC device for new firmware?

    I don't understand the question.

    I don't post older version of the firmware, they are embedded inside the GUI. There is no maximum age limit, any device can load any firmware. If someone needs to try an older version.

    The older version of hardware is really old. It's like 10 years old. I've done some minor updates. The firmware isn't compatible, the processor in the new model is infinitely better.




  3. Okay, here is how to figure it out.

    Check out the Desktop Consumer Usage table Here: https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf

    Find Table 17


    Now, as an example, in this table, AC_BACK is used to go back. To record this manually using the commandline, do the following:

    flirc_util record_api 0x2 0x223


    The first argument is always going to be 0x2 for this table.

    The answer is something in this table. 0x297 is save and close. That would be strange they used that, but we can try it with the following:

    flirc_util record_api 0x2 0x297

    Could it be decimal 297? Which would translate to hex code 0x129, but that's not in the table. So maybe they chose something that isn't listed to be safe?  Try that with:

    flirc_util record_api 0x2 0x129

    But if those don't do it, and I were to guess, I would think it would be something that kinda made sense. Maybe AC Catalog? 

    That should help, let me know how that goes.

  4. 50 minutes ago, rcdsystems said:

    Hey Jason, really appreciate all the help here. I've disabled the profile and will leave it plugged in overnight to see if it happens again.

    I was able to reproduce the issue with 2 different adapters:



    Another data point to report is that I've tried leaving it plugged in the hub/adapter without the power supply. The next morning when I checked the iPad battery had been drained completely. This is perhaps another indication that the usb receiver prevents the ipad from sleeping. If I leave the usb-c power connected to the adaptor then it will eventually become unresponsive as described. 


    All really helpful clues, thank you. It's strange, because tens of thousands of users use flirc in pi's, and htpc's while in sleep, and allow the remote to wake up the PC. I would have a lot of complaints of users that can't get their devices to stay asleep. 

    However, Apple's USB stack, and especially on their ipad is a different beast. I have not tested it, and that isn't to say there is something I'm missing. I'm thinking it's not so much with the device receiving a signal and waking up the ipad, but something in the USB response that reports a wake-up event.

    I have one more idea. Do you have anything like this: https://www.amazon.com/Syntech-Adapter-Thunderbolt-Compatible-MacBook/dp/B07CVX3516/ref=sr_1_4?crid=18PWPIJS0D44O&keywords=USB+A+to+C&qid=1661473174&sprefix=usb+a+to+c%2Caps%2C155&sr=8-4

    Something without a hub to rule that out?

    Curious, how did you extract the log? 

  5. Can you disable the built in profiles. Fire up the GUI, go to advanced, and then disable all those profiles. Let me know if it's any better after that. 

    Outside of that, if it doesn't work, can you clear the config, and just leave the flirc in there, and see if it happens again? I know that seems silly, but it would tell me if it's something wrong with my USB stack, rather than the usb submission of codes (because nothing would ever be received/submitted).

    Thank you. I'll see if I can reproduce locally. Is it in there with just an adapter, or a hub with other devices? A link to the adapter would be helpful.

  6. On 8/20/2022 at 3:33 PM, Ross MacGregor said:

    Here is the full listing of Pronto hex codes for Flirc. I used the specification provided by Jason to write an command line utility to generate Pronto hex codes. I've tested them on my Nvidia Shield and they seem to work fine. I was able to control the Shield by directly sending Flirc commands with my IP to IR flasher and not requiring any configuation of Flirc, it's just plug and play.  This should make things easier for those that have more sophisticated IR controllers.

    I've attached the listings of all the codes for each device. I've even included commands that don't exist yet. Use the Flirc IR Documentation (above) to find the command you want then look up the code for it using the device ID and command ID. The Pronto codes follow the command identifier in square brackets.

    Here is the link to my utility on gihub: https://github.com/rossmacgregor/FlircProntoCodes 

    FlircProntoCodes.zip 15.69 kB · 2 downloads  

    Hey Nice job.

  7. On 8/3/2022 at 1:32 PM, Googlhupf said:


    First time poster and long time FLIRC user here.  :-D

    I found out about the Skip 1S just hours ago. I've been reading everything I could find about it. My Harmony is on its way out and will need to be replaced soon. :-/

    I have questions. To program the FLIRC USB, you need to have a remote that sends a unique IR code for each button. Even with a very good device database, you can't have buttons for everything. Say I want a button that brings up the audio delay slider in KODI. There can't possibly be a button for everything. Does the Skip app allow creation of a new button that brings its own new IR code? When I needed a custom button on my Harmony, I just grabbed an ancient VCR remote and learned an IR code from that. What's the Skip's approach to that?

    As for the IR database... Is that your own or third party? What about European makes and models?

    Will there be a connection between the FLIRC USB and Skip app?

    Greetings from Germany



    To add on to Nate's response, it's a commercial licensed database. It's updated frequently, and well done. We will have in an update a mode, similar to how flirc works, where you can learn buttons into the remote. 

    Flirc has it's own protocol, and if you need a code, there will be a ton of extra named, 'custom1, custom200, etc. You can use those to repurpose whether it's through flirc, or another device. I'll publish the IR spec as well.

  8. Thank you so much for the feedback. Yes, there is a lot that we didn't include on the 1s. But we have a lot of plans, and it was really important for us to start from scratch. Too many companies try to throw everything in the remote and fuck it all up, it's complicated. So we started with the basic, want to nail it, and then we'll be rolling out additional technologies. Not to mention the chip shortage really screwed everything up.

    But one of the best things we did, was do everything in react native desktop. This is not a webapp, this was a massive effort. And that was specifically so we can leverage a lot of our work back to tablet/mobile. 

    I could say for certain, I do not want to do a hub. I don't like those things. No reason why everything can't be on the remote.

  • Create New...