Blog & White

Several months ago, the leffakone infrared receiver started to misbehave. There were a lot of errors in syslog about spikes in the signal, and the problem seemed to come from the serial port on the motherboard rather than from the homebrew IR receiver, connected to the serial port, that I had built in 2002 or 2003 and that I had been using with lirc ever since. One of the symptoms was that unloading the lirc-serial kernel module caused the computer to freeze, while testing the receiver with an oscilloscope seemed to show that it was working correctly. For many months, I was too lazy to do something about it, as using a keyboard with a long enough cord was enough to control leffakone. During the last autumn vacation, I tried to test the receiver with the serial port on minikone, but the latter seems to deliver only 1.2V signals, when the receiver expects at least 7V to power its onboard voltage regulator. So that was not very conclusive.

At the same time, I had the idea of building a CO₂ monitor using a Jeenode I had lying around, and somehow I wondered if the IR receiver module would not just fit into one of the Jeenode's ports. Guess what? It fits perfectly, allowing to use the IRQ pin as the input, which is exactly what the Arduino-IRremote library suggests to use. Writing the software was a bit of a headache, because the library assumes that the compiler would run with the -flto option (and the compilation ends with an error if it is not set), but my custom Makefile somehow fails to compile the code correctly if I enable that option. Thankfully, you can get around the problem with #define SUPPRESS_ERROR_MESSAGE_FOR_BEGIN. After that, the program is quite straightforward: configure it for the RC5 protocol (as this is what my remote control produces), read a code and write it to the serial port if it matches the RC5 address. I also added a new feature: if the code is the power on button, it would set a pin to HIGH for a short while, allowing to switch the computer on. I used the Jeenode USB as it has an on-board USB-to-serial adatpter, which makes it perfect to connect to a modern computer. I had one reed relay left from the timer and despite being rated for a 5V control voltage, it works with the Jeenode's 3.3V signal. The Jeenode is connected to the computer with a USB cable where I have replaced the USB Type A connector with a Molex connector so that I can use one of USB headers on the motherboard. Crimping the very small contacts was difficult as I don't have a crimping tool, but the connections seem to be working despite having done quite a poor job of it.

Yesterday, I installed the extra reed relay and the Jeenode onto the PCB that holds the relays of the timer, and now it's inside leffakone and working well. And since I forgot to take a picture, there is no image of what it looks like. In addition, I'm quite happy I have been able to do this project by using only bits and pieces I already had (the Jeenode, the headers, the reed relay, the IR receiver module, the USB cable, the Molex contacts and housing).

I finally built the timer for the new Leffakone. It is based on an Arduino Uno, which controls two reed relays and one LED. The reed relays can be activated with a very low current (10 mA), meaning that the Arduino can drive them directly from any I/O pin. The relays' contacts are connected in parallel to the power button and the reset button. The Arduino's serial-over-USB port is connected to one of the USB headers of the motherboard with a home-made cable, and the timer is set by software through this serial connection. All the wires coming from the computer case's front panel are connected to the circuit (to the 8-pin header protruding from the protoboard), and wires go from there to the motherboard's front-panel header (2 white wires for the power button, 2 grey wires for the reset button, and 2 blue+black wires for the power-on LED. The two boards are screwed on the bottom plate of the case of an old CD drive; for installation, I closed the case and put it into the computer as a regular CD drive.

While the timer is counting down, it blinks the computer case's HDD LED (which therefore is not anymore indicating the HDD activity).

When the timer expires, it closes the power button's relay for 500 ms. An optional watchdog timer would close the reset button's relay if the machine does not boot correctly i.e., if the timer is not reset within 30 s. This watchdog timer is currently disabled in the code, since the problems I have had with GRUB freezing on startup seem to be related to manually powering the device and switching the TV on shortly after. I'll enable it if it seems necessary. Here is the code for the Arduino.

The software client for the timer is written in Python and is very straightforward: send ASCII digits to the serial port, ending with a newline character. It interprets this number as a number of seconds, and starts counting down. When disconnecting the client from the serial port, the Arduino resets and forgets all about the timer value; I found out that setting the DTR line to False in the Python Serial object prevents this from happeining. I haven't however found out how to prevent a reset when connecting to the Arduino; this is less a problem, since when I connect to it, I want to reset the timer, and reseting the whole program does just that. It seems that it's the Linux driver that asserts the DTR line when opening the serial port; I haven't investigated further. It is worth noting that when the machine boots, it does not reset the Arduino.

Finally, the cristal in the Arduino is accurate to 99.5% which is not enough to guarantee that the timer will wake up the computer within a minute after a countdown of several days. I therefore apply a corrective factor to the time sent to the Arduino. The factor was estimated from a 15.5 hour countdown, which lasted about 90s more than it should have. Over a 7-days countdown, it would cause the timer to expire about 16 minutes too late.

I use a shell script wrapper around MPlayer for recording TV programs in my Leffakone, the problem being that when TV reception is too bad, MPlayer crashes or freezes, so the wrapper restarts it when needed. Since MPlayer doesn't output anything while recording, I use a loop that checks every second that the recorded file is actually growing. Whem it stops growing (and there is still some recording time left), it means that MPlayer stopped working and that it needs to be restarted. Until now, I did this in a loop like this:

while [ $(stat -c %s $filename) -gt $last_size ]
do
  last_size=$(stat -c %s $filename)
  sleep 1
done

I then noticed that all recordings exceeding one hour (there aren't that many, that's why it took so long to notice it) where cut in two even though the picture doesn't show hints of bad reception. More peculiar, the size of the first part is slightly over 2 GB in size (therefore the problem is not related to a 2 GB size limit, right?). An experiment conducted yesterday show that it actually is: the test program (used here in its |[| form) handling the -gt comparison actually doesn't like values greater that 2ˆ31, which caused the loop to be interrupted and the recording to be split into two parts.

The solution is then (for Bash at least) to use the following syntax:

while [[ `stat -c %s $filename` -gt $last_size ]]

which seems to be working with values greater than 2ˆ31 (and than 2ˆ32, I just checked).

Leffakone's timer's been working perfectly for almost two years, but since we moved, it doesn't always work as it should. The LED goes off when it starts to receive data (as expected), but then it just reboots (because of the watchdog timer) and then waits for data again (its LED on). But it will not accept the data anymore. And after a couple of days, for no reason, it works again (and blinks happily while counting down).

I took it to the telecom lab last Tuesday and Niko took a look at it. The solders seem fine. We changed the micro-controller and flashed it. It still behaved erratically on the bench, rebooting repeatedly for no obvious reason, sometimes receiving data with the available signal low but touching the data wire with the finger (I mean the insulation of the wire, not the metallic part). Niko unsoldered and resoldered the crystal, thinking it was faulty, with no effect. It seemed doomed.

Then I took it back home, checked with an ohm-meter that all the resistors were resisting, that the capacitors were capaciting, and I put it back in Leffakone. This was last Thursday. Since then, it's been working perfectly…

Today when Leffakone was supposed to record MacGyver, it didn't record anything. The DVB-T card was able to tune to the right frequency, but nothing came out of it. I openend the case, removed the PCI card, unplugged the wakeup timer, blew on the PCI card, put the card back, and it worked. Then I unplugged the card again, plugged the timer back (the WOL port is between two PCI slots, it can't be reached without removing one of the nearby cards), plugged the card back, and it's still working, currently recording Lois & Clarke. I just hope it will continue to work.

It's not the first time I have trouble with the computer, two years ago, the DVB-T card refused to record anything while I was connected to the computer through the modem with a simple serial terminal. Computers work in mysterious ways…

The timer was working almost correctly, except that the most significant byte of the timer value was mishandled: there was a for 65536 loop statement, but since the PIC 16F84a is an 8 bit microcontroller, the value 65536 was understood as 0, and the MSB of the timer was considered as null. Niko reprogrammed the PIC using two nested for 256 loop statements.

Thanks to Niko, my Leffakone project is finally complete. He built the timer I designed already two and a half years ago, that enables Leffakone to boot automatically when it is time to record a TV show.

The device is based on a Microchip 16F84A PIC and is connected to the Wake On LAN connector of the computer, as well as to the parallel port. The WOL connector provides +5V to the device even when the computer is powered down. The parallel port is used for sending the 24-bit timeout value to the timer, one bit at a time (one line is data, another line is a “data available” signal). The timer then ignores all input for three minutes, giving enough time to shutdown the computer (when the computer shuts down, some garbage is sent to the parallel port, which would be considered as input if it were not ignoring it). After that delay, it counts down to zero, and then sends a signal to the WOL connector that boots the computer. It's as simple as that.

The device has two LEDs, one indicating that power is on, and one status LED. The status LED is:

• On when the device is in standby, waiting for input.
• Off when the device has received partial input and waiting for more.
• Blinking at 0.25 Hz when ignoring all inputs.
• Blinking at 0.5 Hz when counting down.

When the timer is in the process of receiving input, and the procedure does not complete, the internal watchdog timer makes it reboot after about two seconds, putting the device back to standby mode.

The timer is supposed to accept timeout values in seconds, but the programming contraints in the device are such that the actual time unit is worth about 1.02 seconds.