Skip to main content ↑ ↓
Topic: convert LIRC file to IRToy raw commands (Read 18250 times) previous topic - next topic

Re: convert LIRC file to IRToy raw commands

Reply #15 –
Hmmm.  I seem to have discovered an issue with the IR Toy, albeit an easy one to workaround.  Following the recommended procedure for capturing with the IR Toy, of holding the transmitting remote within 1 cm of the IR Toy's detector allegedly to get accurate frequency measurement, I get neither accurate frequency measurement nor proper demod timing.

Here's an OBLS logic analyzer picture showing the raw IR detector output and the demod output:



Notice how during the lead-in, the demod output does not follow the raw IR.

This was taken with IR Scrutinizer doing an IR capture and here's what IR Scrutinizer thought of the data returned by the IR Toy.




Pretty much the same.  I think this demonstrates that the IR Toy is returning data corresponding to the output of the demod, though I can't explain the erroneous frequency detection of 90 KHz.

Similarly an irtoy.exe recording of the same IR, returns data that while it reflects the output of the demod, does not reflect the actual IR burst data.  This may be the root cause of some recordings not operating the intended device when played back.  In this case, the lead-in burst is grossly shortened and replaced with gap time.  Many devices will not tolerate such massive deviation from the ideal signal.

But all is not lost.  Simply moving the remote back about 10-15 cm, is sufficient to correct the situation.  Once that is done, capture works as expected with the demod signal reasonably closely following the raw IR and frequency detection that is pretty close to the actual burst frequency.




The question arises as to exactly how close does the demod timing match the raw IR burst and how close does the IR Toy get the frequency measurement on the raw IR burst?

Here's a zoom in on the logic analyzer showing how closely the demod follows the raw IR burst:



As you can see, the raw burst is some 534 us wide.  The demod burst measurement (not shown) came out to 523 us (cursor 4 - cursor 3).  Not too bad.  The frequency of the raw IR burst was 38.3 KHz compared to the IR Toy claim of 39.531 KHz.  That's close enough for any consumer IR device.  The delay between the start of the raw IR burst and the demod output is to be expected and is due to the signal processing in the demod chip.  The delay is replicated at the end of the raw IR burst.  So, there is an overall delay, but the on/off times are reasonably accurate.

I think that the instruction to hold the remote within 1 cm of the IR Toy when capturing, should be revised to say "hold the remote at 6-9 inches from the IR Toy when capturing".  It's clear that there is something going terribly wrong in the demod's analog front-end when you follow the recommended 1 cm advice.  This may depend upon how strong the IR output is on the remote being recorded.  So, perhaps some experimentation is in order.  If playbacks are not able to operate the intended device, move the remote further away from the IR Toy during recording.

Re: convert LIRC file to IRToy raw commands

Reply #16 –
It would seem at the same time you found this I too was running the  same experiments and came up with exactly the same conclusions (almost!). The demod receiver does not like to be saturated and there is a happy medium for both IR chips to receive a nice signal to. However there was a slight difference in that in my tests I found the distance for my NEC IR remote to be more in the range of 6-9cm not inches. This distance probably changes a lot depending on the power of the IR LED. This is something that people can experiment with now that they know.

Nice work with all the images and details. Where's the forums thumbs-up thingy?

Re: convert LIRC file to IRToy raw commands

Reply #17 –
[quote author="Simpkins"]It would seem at the same time you found this I too was running the  same experiments and came up with exactly the same conclusions (almost!). The demod receiver does not like to be saturated and there is a happy medium for both IR chips to receive a nice signal to. However there was a slight difference in that in my tests I found the distance for my NEC IR remote to be more in the range of 6-9cm not inches. This distance probably changes a lot depending on the power of the IR LED. This is something that people can experiment with now that they know.

Nice work with all the images and details. Where's the forums thumbs-up thingy?[/quote]

I think it absolutely depends on the transmitting power of the remote being recorded.  I tried 5 different remotes and only the one I tend use all the time, has so much power that it overwhelms the demod at close range.  Most remotes, I could put directly against the demod without any issue, but this OneForAll URC-8910 apparently puts out a lot more power than the others.

Given any random remote, it's hard to tell if there is a problem or not (without a scope or logic analyzer), unless you playback the captured IR record and it doesn't operate the device.  In such case, adjusting the distance is in order.

Re: convert LIRC file to IRToy raw commands

Reply #18 –
Hi
I think you need to treat measurement of Modulation frequency separately from demodulated signals with the IR Toy.

Some points of interest:
1. The IRToy returns 2 values for the modulation frequency, which are captured from the first 2 modulation pulses at the start of each signal. For this to be accurate, you need the remote to be up close and personal!. In my experience you are either getting the Modulation frequency or the IR signal, but not both simultaneously.
2. There ia a bug in the current V222 firmware, wherby only the first value returned for modulation frequency is accurate, this is covered elsewhere in this forum, but remains outstanding.
3. If you make a request for modulation frequency after a signal where the remote was not up close, you will get a bad out of range result.
4. There is always a lag with IR Receivers and the resulting timings are always distorted, due to things like AGC within the device. You can get some insight in our blog post "Infrared Receivers – signal lag and distortion":
http://http://www.analysir.com/blog/2014/03/27/infrared-receivers-signal-lag/
5. IR Receivers are not designed for use at ranges of a few cms & from what I have observed the internal circuity can be overloaded when this happens and may (sometimes) operate outside of spec.

IR decoders must make allowances for variations in timings. Some use up to +/- 200 uSecs others use +/- 25% of pulse lengths.

I am not sure this addresses your points, but hopefully is of some interest nonetheless.

Re: convert LIRC file to IRToy raw commands

Reply #19 –
[quote author="AnalysIR"]Hi
I think you need to treat measurement of Modulation frequency separately from demodulated signals with the IR Toy.

Some points of interest:
1. The IRToy returns 2 values for the modulation frequency, which are captured from the first 2 modulation pulses at the start of each signal. For this to be accurate, you need the remote to be up close and personal!. In my experience you are either getting the Modulation frequency or the IR signal, but not both simultaneously.
2. There ia a bug in the current V222 firmware, wherby only the first value returned for modulation frequency is accurate, this is covered elsewhere in this forum, but remains outstanding.
3. If you make a request for modulation frequency after a signal where the remote was not up close, you will get a bad out of range result.
4. There is always a lag with IR Receivers and the resulting timings are always distorted, due to things like AGC within the device. You can get some insight in our blog post "Infrared Receivers – signal lag and distortion":
http://http://www.analysir.com/blog/2014/03/27/infrared-receivers-signal-lag/
5. IR Receivers are not designed for use at ranges of a few cms & from what I have observed the internal circuity can be overloaded when this happens and may (sometimes) operate outside of spec.

IR decoders must make allowances for variations in timings. Some use up to +/- 200 uSecs others use +/- 25% of pulse lengths.

I am not sure this addresses your points, but hopefully is of some interest nonetheless.[/quote]

For capturing precise timing, using just the raw IR sensor seems like the way to go, even if it does require the remote be quite close.  I've never seen the raw sensor fail to give correct timing in such case.  The demod on the other hand starts out with a handicap and it gets worse from there.

Many people know that the IR Toy can actually operate in IR Widget mode that uses the raw IR sensor exclusively.  The demod sensor use was abandoned long ago by the Widget developers, due to the inaccuracies.  Sadly, the built-in Widget mode of the IR Toy is badly broken.  There is a stand-alone "Widget only" FW for the IR Toy and it works beautifully, though the "Widget only FW" gives up the capability to transmit IR.  Ideally, if someone with an understanding of the IR Toy FW, fixes the built-in Widget mode, we could have the best of both worlds; pulse accurate timing on captures and retain the ability to transmit IR.

In native IR Toy sampling mode, I wouldn't go so far as to say that you need 2 captures, one to get the frequency and another to get the timing.  I haven't had much trouble finding a happy medium on distance that allows both to work reasonably well.... once you know not to get too close.  It hadn't occurred to me that the demod might malfunction in such a peculiar way, if encountering a really strong IR source.  I think I rather expected the "on" times to get blown out, rather than shrink.

Re: convert LIRC file to IRToy raw commands

Reply #20 –
Quote
It hadn't occurred to me that the demod might malfunction in such a peculiar way, if encountering a really strong IR source. I think I rather expected the "on" times to get blown out, rather than shrink.

Yes, you are right. What I have mainly seen is that some of the internal stuff, like inbuilt noise rejection gets overloaded.
Some receivers are designed to disregard long pulse sequences and will ignore long AC or continuous signals.  Sometimes holding the remote close to the receiver, will overcome this 'feature'.

Regarding timings, the strength of the IR signal landing on the receiver will influence the distortion of the mark/space lengths. Modulation duty cycle would also be a factor. However, the duration of mark/space pairs is usually good/consistent and this characteristic can be used to good effect in decoding algorithms.

The mark times can be increased or decreased with the space times more or less compensating, but mostly I see mark times increased and space times decreased in normal operation. (up to +/- 100 uSecs). The data sheet will give the range in mutiples of the modulation period (for a pre-defined test signal).

Re: convert LIRC file to IRToy raw commands

Reply #21 –
I am not sure if it is still an issue, but the recently released version 1.1.1 of IrScrutinizer generates the binary format the OP was soliciting. Just select "IrToy-bin" as the export format.