Computing stuff tied to the physical world

TD – Infrared Remote

In Hardware on Apr 10, 2012 at 00:01

Welcome to the Tuesday Teardown series, about looking inside the technology around us.

Steve (@tankslappa) recently sent me two spare IR remotes he had lying around. Very joyfully and gratefully accepting his generous gift, I decided to tear one down to see what makes these things tick:

DSC 3043

Frightfully little, I’m afraid. Just a single SOIC-20 type IC! Marked “DUSUN021” and “1003” (3rd week 2010):

DSC 3044

The switches are custom-designed, using a silicone mat with buttons, each of them holding some sort of little carbon-lined conducting pad. When pressed, they connect two traces on the PCB and that’s it!

Oh, wait, the other side has two more components and some simple battery clips:

DSC 3045

The electrolytic cap just helps the battery supply power for IR LED, I presume, while the other component is a cap 3.45 MHz resonator, and part of the frequency-generating circuit.

Here is a scope trace of the emitted IR light when pressing a single button:

SCR03

This was picked up with an AMS302 light sensor, BTW. You can see the two pulse trains, i.e. the button press gets repeated twice. Perhaps not as easy to see, is the fact that “ON” is not represented by a simple IR pulse, but by a pulse train. This allows the receiver to filter out noise and random pulses, by filtering and detecting pulses only when modulated in this way.

As you can see in the zoomed-in section, the pulse train consist of turning the IR LED on and off at a 36 KHz rate.

This is within the detection range of the TSOP34838 IR receiver, as used on the Infrared Plug, even though that receiver is optimized for 38 KHz modulation. Don’t be put off by the term “modulation” in this context, BTW – it simply means that the 38 KHz frequency used to drive the IR LED is turned on and off in a certain pattern.

Each key has its own pattern. This remote appears to use the RC5 protocol. Here’s a snapshot of one keypress using the TSOP34838 chip, which detects, demodulates, and then outputs a clean logic signal:

SCR07

I’ve enabled the tabular pulse search listing, which gives us information about the encoding used by this remote:

  • 829 µs for a short “OFF”
  • 953 µs for a short “ON”
  • 1738 µs for a long “OFF”
  • 1752 µs for a long “ON”

Decoding such a pulse train is fairly easy, and as you can see, the component count for such IR transmissions is extremely low and hence very low-cost. Which also explains the popularity of this system!

PS. I’ve switched to light oscilloscope screen shots as a trial. The colors are not as pronounced, but it seems to be a little easier on the eyes. Here’s the same info, in the dark version as it shows on-screen:

SCR06

  1. JCW, I prefer the dark version of the screen shot :)

    Wayne.

    • Heh – me too, the hues are too faded, especially with more colors. I’ll probably switch back…

  2. Are you sure the blue item is a capacitor? If that’s labelled “X1” that suggests a ceramic resonator, rather than a cap.

    • Ah, good catch – it’s indeed a 3-pin resonator. I checked, and there’s a 3.45 MHz signal while a button is pressed.

  3. It is interesting that this is a single-sided PCB, and yet it seems to have two electrical layers, one is copper traces routing from the SOIC, and the other one a grey material(?) forming the interdigitated button contact patterns. The two seem to be separated by a green-ish mat or soldermask.

    • It certainly seems to look that way. The grey layer appears to be screen printed on top of the solder mask. I should really take one of them apart myself, I’ve got a few!

  4. As JC said, these send Philips RC5 format messages. RC5 incorporates a toggle bit, which flips each time a key is released and then presses. This allows for buttons which require autorepeat (e.g. volume) to just keep sending the exact same code, and other keys which you don’t want to autorepeat to be suppressed at the receiver side.

    I’ve played with one on a JeeNode using JC’s IR plug and it works well. I used a hacked about version of Ken Sherriff’s IR receive library. I seem to have a problem with a couple of the buttons not being detected correctly. I haven’t worked out if this is a quirk in the remote or a bug in the library. Curiously enough these are the same buttons which don’t output straight ASCII when I plug in the IR USB receivers which came with the remote… Coincidence?? Hmmm…

  5. Yes – a conductive (just) ink stencilled over the solder mask. The button push detection is at high impedance anyway, so “lossy” paths don’t matter in this context. Way cheaper than going to a double-sided PCB.

  6. If I am not mistaken, RC5 uses 888us half-bit time (bi-phase encoding). Each bit takes 2 half-bits, or 1.776ms per bit.

    With bi-phase encoding, zeroes and ones get encoded as a 0-1 and 1-0 sequence (could be the other way around, I would need to check) in order to generate a sufficient amount of signal changes for flank detection.

    It has a preamble with a couple (3?) of start-bits, a toggle bit, some 5 address bits and 7 command bits followed by a stopbit and a fixed “medium free time”, IIRC.

    Like Tankslappa said, the toggle bit flips on each new keypress. This helps when entering numbers, for example TXT page numbers like 888.

    There are several variations on the RC5 protocol, lfor example the CD-i remote.

    RC6 was developed as a faster / more flexible successor to RC5. It uses a 444us half-bit time with biphase encoding. Some remotes will send both RC5 and RC6 codes on each keypress for backward compatibility.

    Ah, memories ;-)

  7. I belive the “1003” stands for “the third week of 2010”.

Comments are closed.