Jump to content
Flirc Forums

xnappo

Members
  • Content count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral

About xnappo

  • Rank
    Curious Flirc-er
  1. Okay, can definitely understand that. It is a much more difficult task, I assume, to take an input in the form the debug presents and provide and API to change that into a hash...?
  2. @jason - is the calculation of the hash from the IR sequence 'open source'?
  3. @yawor - thanks I will play with it @jason - cool - even if it doesn't help with my current problem, it would be nice to have a non-learning workflow with JP1 stuff
  4. Ha - of course I recognize you as yaworski - I didn't make the connection! Thanks for the explanation - perhaps I should describe the problem I am trying to solve rather than a naiive perceived solution :) I have an RF->IR box - REX-433 for the XSight touch. I am using this with other equipment and it works well - however with the FLIRC is sometimes does not respond to key presses. I have learned the FLIRC with the remote rather than with the emitter from the RF box. I tried learning with the emitter, but it seems to put out some kind of constant low-level signal that confuses FLIRC. I was originally using the horrid Ortek protocol and it REALLY didn't work. I then switch the NEC2, and it is better, but still not perfect... Thanks, xnappo
  5. Hello, I have been peripherally involved with the guys over at hifi-remote.com/forums for 15+ years. If you are not familiar, there is an open source toolset available for UEI-based remotes, and many other tools that have been developed to support IR in general over there. I am wondering if there is a way to program FLIRC with a sequence similar to the raw IR format shown in the FLIRC debug window rather than using learns. Since with the RM-IR toolset we know the exact correct IR signal, it would be nice to be able to program the FLIRC with that rather than relying on learns. Obviously the goal here is to avoid less than optimal learns. Thanks, xnappo
×