Rover 5 Infrared Code Processing Notes

Infrared Remote Code Processing Programs

While learning how to implement my Robot's Infrared LED Tangential Collision Detection, I stopped along the way to write two programs that run in an Arduino Nano.

The first one captures and records Infrared Codes, i.e., from TV Remote Controls, using the:

GP1UX31QS/AX1838 Sharp "IR Detecting Unit for Remote Control"

It confirms that the codes have been recorded correctly, by matching each recording with the Remote's transmissions, to ensure that they all have been correctly identified.

The other program plays the recorded codes back on demand, emitting/clocking them out using a IR LED and two of the AT328's three internal Timers.

I'm using these programs to implement an IFF-beacon on my collaborating Robots, which they use when encountering each other while hunting in my living room for balloons, both to indentify each other, and to exchange map updates and location data about their quarry.

[Update: 8/6/14]: I observed very recently this unfortunate fact in the IR Receiver's datasheet above:

Meaning that the IR Receiver's output is Active Low, rather than the Active High that I was assuming it is <sigh>.

This gives at least a partial explanation of why my Emitter sketch test output was not recognized by my TV, as the 38kHz pulses it was transmitting are being emitted on the opposite side of the gating pulses from where they should be, and the gating pulses themselves are too narrow and too wide in various places.

Happily, this oversight on my part does not impact the Recorder sketch's functionality when it is used by itself, i.e., to Record and then later Recognize previously recorded pulse trains.

I'll record pulse trains for several of my VCR, etc., Remotes at home, to get a clearer idea of what the "more typical" Remote code patterns are, then modify the Recorder and Emitter sketches to take this change into account.

I'll add another update here as soon as I can update the programs to take this new information into account.

Infrared Codes Recording Programming

Here is an excerpt of my ATmega328 Programming to record my TV Remote's Infrared Pulses.

Infrared Codes Data Patterns

I didn't have an oscilloscope when I started these programs, so I first visualized the pulse lengths received from the Remote in Excel, displaying the Long and Short pulses in Red, and the Off pulses in blue.

Below you can see this pulse train in Excel:

3 Long, 3 Short, 1 Long, 2 Short, 1 Long, 5 Short:

Long and Short Pulse Durations in Excel.

Click on the image above to see the complete pulse train, including the very long Gaps.

Later on I did finally get a DSO Quad oscilloscope, which simplified things.

Alas, my "programmable" Toy Retired SparkFun Remote, re-programmed itself, meaning that now the codes it emits are different than the ones I first visualized in Excel above.

To wit, below are the pulses I'm now receiving from the SparkFun Remote, via the Sharp IR Receiver component above.

I captured these waveforms using the LOW pulseWidth less-than trigger mode on my DSQ Quad oscilloscope.

I believe the initial long HIGH and long LOW pulses are a preamble, rather than part of the actual data, thus I do not include them in my data recordings.

Note that the IR Receiver has already stripped out the 38kHz modulation from the waveforms below, which I have labeled with the number of Long and Short pulses that make up this pattern:

And here is an example of the auto-generated Array declaration (and comments as well), which you can see starts with the same


	1 Long,6 Short,1L,1S,6L,1S

pattern shown in the waveforms above.

Infrared Codes Emitter Timer Programming

Here is an excerpt of my ATmega328 Timer Programming to clock-out/emit the pulse trains that I recorded from my toy Infrared Remote Control.

Infrared Codes Clocked-Out to Target Device

Here are some typical pulse-trains that the second program clocks-out to control the target device.

This screenshot shows the initial pulses, where the Cyan pulses below are fed to the IR LED to signal the target device, i.e., the TV, Room Fan, etc.

Unfortunately, the initial 6 Cyan pulses (the ones just before the Orange vertical dotted Trigger line), should not be there :-(. [This screenshot is with the program running in Slow/Debugging w/LED's mode, as shown by the 500mS/division indicator at the top of the screen]:

And here the extra initial pulses are as well, this time when running at Full Speed, as shown by the 1mS/division indicator at the top of the screen:

These extra initial pulses prevent the controlled device from recognizing the transmitted code, so I worked on this for a while and was able to remove them:

Lastly, below we have the Gap emitted between the initial transmission of the pulse train, and its repeat.

Interestingly, the Yellow pulses (that gate the Cyan ones) invert after the gap.

I suppose I should have expected this. In any case, the Cyan pulses (going to the IR LED) are still clocking-out correctly, so I remain happy with this program's performance.

Next Steps

I'll be hooking up my IR LED (the black tube in the lower-right corner below) to my circuit:

and hopefully will be able to produce a strong-enough Infrared signal that the TV will respond to it, i.e., from maybe 1"-2" away :-).

I was able to confirm that the program is turning on the IR LED, as they do appear illuminated in Digital Cameras, both Still & Video.

I.e., below on the left, the IR LED is on, and it's off on the right (it has a little bit of red reflection from the nearby test probe):

Alas, in my daylight-lit room test this morning, the TV didn't respond to the IR pulse trains I sent it, so I'll try again this evening, in a completely dark room.

I have already found a Super-Powerful IR LED (with a MOSFET to drive it: Danger, don't look into this device), so I'll look into proceeding with this.

In parallel with that, I've read in passing that "real" Remotes blink a standard IR LED at high currents, and protect it from burning out by limiting the on-portion of the pulse to a few uSec., with the usual 38kHz frequency.

I'll search a bit for details on what current, voltage, and circuit are used in this approach, again with a MOSFET.

More news on this soon.

Back to Main Page...