xnappo Posted January 30, 2018 Report Share Posted January 30, 2018 (edited) 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 Edited January 30, 2018 by xnappo Quote Link to comment Share on other sites More sharing options...
yawor Posted January 30, 2018 Report Share Posted January 30, 2018 Hi xnappo. Flirc doesn't support such functionality, at least not yet. I've proposed something similar myself, but my idea was to be able to directly add a hash value (Flirc doesn't store the original signal, but a calculated hash). I like your idea with importing from a raw signal like the one in the log output, but I don't know if it would be possible. Regarding the "less than optimal" learns you don't have to worry. As I've mentioned Flirc doesn't store full learned signal but calculates its hash value. The algorithm for that is not that sensitive to signal variation between key presses. The same algorithm is applied during normal operation. So if the key works after learning its signal then the hash has been calculated correctly (the hash calculated for a signal during the normal operation must be equal to the hash calculated during recording for key to be recognised afterwards). As you can see providing perfect raw data (for example from IrScrutinizer) wouldn't make any difference. BTW I'm a JP1 member myself :) (my nick there is yaworski). You've probably seen some of my posts. Quote Link to comment Share on other sites More sharing options...
xnappo Posted January 30, 2018 Author Report Share Posted January 30, 2018 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 Quote Link to comment Share on other sites More sharing options...
yawor Posted January 30, 2018 Report Share Posted January 30, 2018 I can confirm that the Ortek doesn't work well with Flirc. But NEC2 should work without issues. I'm using NECx2 with my Flirc and it works perfectly with the remote. I don't have the RF though (Nevo C2). There are sometimes some issues when the transmitter is too close to Flirc. Flirc's receiver is very sensitive and doesn't even need the direct line of sight to pick up the signal from the remote. Mine is behind the TV and picks the signal bounced from walls. So if the transmitter is close to the the Flirc try moving Flirc farther or place some IR-opaque object so the Flirc is not lit directly from the transmitter's IR diodes. BTW which Flirc do you have? Quote Link to comment Share on other sites More sharing options...
jason Posted January 30, 2018 Report Share Posted January 30, 2018 This is doable. It's on my todo list to implement yawor's request this week. Quote Link to comment Share on other sites More sharing options...
xnappo Posted January 30, 2018 Author Report Share Posted January 30, 2018 @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 Quote Link to comment Share on other sites More sharing options...
xnappo Posted January 30, 2018 Author Report Share Posted January 30, 2018 @jason - is the calculation of the hash from the IR sequence 'open source'? Quote Link to comment Share on other sites More sharing options...
jason Posted January 30, 2018 Report Share Posted January 30, 2018 4 hours ago, xnappo said: @jason - is the calculation of the hash from the IR sequence 'open source'? Unfortunately no, as it's one of the fundamental pieces of intellectual property that defines the device and it's great sensitivity across environments. Quote Link to comment Share on other sites More sharing options...
xnappo Posted January 30, 2018 Author Report Share Posted January 30, 2018 (edited) 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...? Edited January 30, 2018 by xnappo Quote Link to comment Share on other sites More sharing options...
foto808 Posted February 13, 2018 Report Share Posted February 13, 2018 Any traction on this? In my experience, while NEC works decently, it's still very slow - not sure if it's because it's not recognized at the protocol level, takes too long to hash or... But the result is that there's no comparison on the speed of native remote support and that translated through Flirc. I've found that other codes besides NEC aren't worth learning as the Flirc software just doesn't deal with them in a satisfactory manner at all, even the simple and well documented RC5. Quote Link to comment Share on other sites More sharing options...
yawor Posted February 13, 2018 Report Share Posted February 13, 2018 NEC is slow because it's quite sparse timing-wise. The whole single frame is 108 ms long (when lead-out is included). This means that the signal is repeated every 108 ms when a button is being held down. With recent firmware versions you can try playing with Sony20 protocol. It's frame is only 45 ms long with lead-out. RC5 is not really that fast. Its frame is 114 ms long with the lead-out, so it's even slower than NEC. RC6 (and MCE which is in RC6 family) frame is 107 ms long with lead-out. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.