Motivation
 

In the beginning there was xine, powering my humble multimedia system. Then I suddenly found myself contamined by same general lazyness that hit everybody, I don't want to leave my chair anymore to change the channels, increase the volume and navigate on DVD menus: I want a remote control. So LIRC (Linux Infrared Remote Control) came to help. LIRC is a very nice piece of software, the API is easy to use and the hardware support covers a lot of the existing commercial IR receivers and also the home-grew ones.

Still the available LIRC home-grew projects seemed somewhat cumbersome to me, both from hardware and software point of view. That LIRC parallel port receiver, for example, has that timing generation circuit and requires the software to wait in a do-nothing loop just to measure the pulse width. The LIRC serial receiver is nice, but I had no free serial ports to use.

One thing that caught my attention is that those SFH506-like receivers (the IC used in parallel and serial LIRC projects) provide a convenient filtered TTL output, so it has to be a way to use it without any other components...

Subverting LIRC
 

LIRC is a well thought project, it has mechanisms to support a wide range of devices just by changing some configuration files and drivers. Well, I don't need all his features, I just want to detect my cheap AIWA remote control codes.

Take the LIRC parallel port receiver project as a starting point. There is a notice at the end of the page saying "Instead of the inverter IC (74LS04) you can also use some smarter circuit that will generate an interrupt for each change of the signal coming from the IR detector (SFH 506-38). Then the 65536 Hz generated by the NE556 IC won't be necessary either." Ok, parallel port will only generate interrupts on the rising edge of /ACK signal, so we can measure the time between rising edges (like the full period) but not the pulse width. Wait a minute... do we really need to know the pulse width?

I checked how AIWA was coding the bits for his remote control. It is one of the kind of the so called "japanese remotes" (NEC, APEX, HITACHI, PIONEER, and probably others) that use a very simple bit-width codification. Therefore just by looking at the period it is possible to say if we received a "zero" (period=2T) or a "one" (period=4T). We don't need to know the pulse width!

So I just hooked the SFH506 receiver to my parallel port like that:

 GND o--------------------------+
                                |
                                |   +--------------+
                                +---|1             |
                                    |   =========  | <---
 Vcc o------------------------------|2  SFH506-38  | <---
                                    |   =========  | <---
                                +---|3             |
                                |   +--------------+
/ACK o--------------------------+

Having a capacitor between power pins might be a good idea, but again it is not absolutely required. So what does the lazy engineer do? Forget the capacitor. You can always solder it later if you run into problems.

Then there was the issue with the software support. LIRC expects the driver to be able to measure the signal time for both low and high levels, but my simple circuit knows only about rising edges. The time between rising edges gives the sum (low+high) but not the individual values. So the lazy engineer is forced to subvert LIRC, reporting that low and high times are equal. Unfortunately, this pretty much breaks LIRC ability to properly detect the codification used and to reuse existing remote configuration files.

You must apply this patch to the lirc parallel driver in order to support the circuit above. The patch is pretty straightforward, drop me a letter if you have any questions.

With everything set, you should use irrecord to configure your remote. Just as an example, here is my lircd.conf file for AIWA RC-T501.

Have fun!

Contact

Miguel Freitas <miguel@cetuc.puc-rio.br >
Center for Telecommunications Studies of the
Catholic University of Rio de Janeiro (CETUC/PUC-Rio)
Brazil
please send your spam to this email