Jump to content
Flirc Forums
xnappo

Possible to program with non-learned IR sequence?

Recommended Posts

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 by xnappo

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

This is doable. It's on my todo list to implement yawor's request this week.

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 by xnappo

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×