Jump to content
Flirc Forums

Possible to program with non-learned IR sequence?


xnappo

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
Link to comment
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.

Link to comment
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

Link to comment
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?

Link to comment
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.

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...