I built a remote control system that uses an ATMega328 microcontroller and a Linksys WRT54G to read IR codes from standard TV remote controls and relay them over the WiFi network to a Python script running on the Boxee server.

Here’s how it works:

1. An IR receiver is attached to an ATMega328 microcontroller (Arduino), which reads the IR codes from standard TV remote(s).
2. The microcontroller is also connected to the serial port of a WRT54GSv4, which is connected as a client to my WiFi network.
3. When the microcontroller receives an IR code, it pipes the code through netcat to a Python script running on the Boxee server.
4. The Python script finds the keyboard key in its lookup table that corresponds to the received IR code and then simulates that key press using the xte utility.

The IR receiver is a TSOP1738 which was pulled out of a broken DirectTV box that had been thrown away. Most IR receivers from old VCRs / DVD players  / whatever should also work:

TSOP1738 Pin Out

The microcontroller code was kept sweet and simple using Ken Shirrif’s multi-protocol infrared Arduino library. All it does is read a code from the IR receiver, check to make sure that it’s a valid code, and sends the command echo “<ir protocol>:<ir code>” | nc <boxee server> 4919 to the BusyBox shell running on the WRT54G’s serial port. The Arduino code can be downloaded here.

The WRT54G is an old Fonera router re-loaded with Tomato firmware. The router has two serial ports, one of which (/dev/ttyS0) provides a root shell; this shell is used by the microcontroller to send messages to the Boxee server:

Tomato 1.25.1720

BusyBox v1.14.0 (2009-05-25 16:08:27 PDT) built-in shell (ash)
Enter 'help' for a list of built-in commands.

#
# echo "NEC:18E708F7" | nc boxee 4919
#

The following schematic depicts how the ATmega328 is interfaced with the IR receiver and the router’s serial port. Both the ATmega328 and the TSOP1738 require 5v, so a 7805 regulator is used to drop router’s 12v power supply down to 5v, and suppress any power supply disturbances that may occur. The 3.3v zener diode drops the 5v output from the microcontroller down to 3.3v for the router’s TTL serial interface, while the 2200 ohm resistor limits the current through zener diode so that the it doesn’t burn out:

IR Receiver Schematic

Here is the circuit wired up to the WRT54G during testing. As you can see, the WRT54G case has plenty of room for the new circuit board:

Testing The Circuit Board

To mount the IR receiver, the “Cisco Systems” logo was cut away from the front panel of the case. The logo did not have any hard plastic behind it, so it was easy to cut out with a hobby knife, and is the perfect size for the TSOP1738:

The Cisco Logo Removed

The Cisco logo was used to cover the “Secure Easy Setup” button, so in order to use that space for the IR receiver, the SES button needed to be removed from the Linksys board as well:

Secure Easy Access Button

Secure Easy Access Button Removed

Fitting The Circuit Board And IR Receiver Into The Case

The Router, Reassembled

With the hardware complete, as much of the logic as possible was placed into a Python script that runs on the Boxee server; this way if I need to add or change some IR codes, I can just edit the Python script, rather than re-program the microcontroller.

The Python script runs as a daemon, and currently has codes for most of the buttons on my Sony, RC6, and NEC remote controls at home. Since Python in Linux doesn’t have an API for simulating keystrokes to GUI applications, the script uses the xte utility which is part of the xautomation package.

I managed to scrounge up most of the parts for this project (including the router), keeping the total cost to around $15. I’m also thinking of using a similar set-up to control other applications running on my PC.

Platform: Texas Instruments AR7, 150MHz
Flash: 4MB
RAM: 16MB
Ethernet: 4 Ports
Wireless: TI ACX111, 802.11b/g

The firmware install is pretty straightforward, once you get the commands right. The process is very similar to that documented for generic AR7 devices, but not exactly the same. It helps to have a terminal connected to the JP603 serial port (ttys0, 38400, 8N1)during this process as well, but it is not necessary:

The serial port on the right (JP603) is ttys0

The pinout for the serial port is, as pictured, from bottom to top: ground, transmit, receive, unknown, Vcc, unknown.

In order to flash the firmware, you’ll need to get access to the Adam2 bootloader. The easiest way to do this is to turn off the router, hold down the reset button, and turn the router back on. Keep holding the reset button until you see the Power and Internet LEDs stay on; this indicates that the router has dropped into the Adam2 shell prompt.

The prompt can be accessed via the serial connection, or via FTP. To connect via FTP, simply FTP to the router and login with the user name of ‘adam2′ and password ‘adam2′. The default adam2 IP address is 192.168.0.1. If this IP address does not work, you will have to connect via the serial connection and issue the following command:

printenv
 

Look for the variable named ‘my_ipaddress’, which will list the Adam2 IP.

Once you have access to Adam2 (either via FTP or serial), you will have to set a couple of environment variables. First, you need to create a partition to install OpenWRT to. The existing partitions can be viewed by issuing the printenv command at the serial console. They are:

mtd2                  0×90000000,0×90010000
mtd1                  0×90010000,0x900d0000
mtd0                  0x900d0000,0x903e0000
mtd4                  0x903e0000,0x903f0000
mtd3                  0x903f0000,0×90400000

Since the OpenWRT image contains both the kernel and the file system, your new partition should cover both the existing kernel and file system partitions (mtd1 and mtd0, respectively). To create the partition via the serial console, run:

setenv mtd5,0×90010000,0x903f0000
 

Or via the FTP connection:

quote SETENV mtd5,0×90010000,0x903f0000
 

You will also have to set the MAC_PORT environment variable in order to enable the internal ethernet port. From the serial console:

setenv MAC_PORT,0
 

Or from FTP:

quote SETENV MAC_PORT,0
 

With that done, you’re ready to FTP your new firmware to the router; other reports on the GT-701 and GT-704 have noted that the ActionTec recovery utility sends a message to UDP port 5035 (actually, two messages in the case of the GT-704). However this appears to be simply for discovery of the router’s IP address and is not necessary for loading firmware onto the router.

Go to OpenWRT’s download page, and get the latest release of openwrt-ar7-squashfs.bin (currently Kamikaze 8.09.1). If you haven’t already, FTP to the router and login with the previously described credentials. You will need to issue the following commands:

ftp> binary
200 Type set to I.
ftp> quote MEDIA FLSH
200 Media set to FLSH
ftp> quote STOR openwrt-ar7-squashfs.bin mtd5
226 Transfer complete
ftp> quote REBOOT

It will take the router a minute or two to clear the flash and load the firmware. Note that you do NOT want to enter passive mode for the file transfer; doing so will slow the file transfer significantly (it would have taken about a week by my estimation). You can monitor the router’s progress via the serial console, or by watching the file transfer in Wireshark. Once the firmware transfer is complete, the reboot command will reboot the router, and you should have a working OpenWRT install:

Please press Enter to activate this console.

BusyBox v1.11.2 (2009-05-28 18:22:45 UTC) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 KAMIKAZE (8.09.1, r16278) ----------------------------
  * 10 oz Vodka       Shake well with ice and strain
  * 10 oz Triple sec  mixture into 10 shot glasses.
  * 10 oz lime juice  Salute!
 ---------------------------------------------------
root@OpenWrt:/#

So far everything checks out OK using the generic firmware image; ethernet and wireless works, opkg updates and installs packages fine. The only downside is that the wireless doesn’t seem to support WPA, possibly due to the poor open source support from TI. I haven’t tested the USB port, but it appears to be a client-only USB device, so it’s of limited use.

Usually, it is helpful to have a serial console connected to the router while doing a TFTP transfer, so that you can see when the bootloader (CFE, in the case of the Asus) is listening for TFTP connections, as with the Linksys WRT54G:

CFE version 1.0.37 for BCM947XX (32bit,SP,LE)
Build Date: Thu Mar 24 16:31:45 CST 2005 (motoplayer@cvs.gemtek.com.tw)
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.

Initializing Arena
Initializing Devices.
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.90.39.0
CPU type 0×29008: 200MHz
Total memory: 8192 KBytes

Total memory used by CFE:  0×80300000 – 0×80399700 (628480)
Initialized Data:          0x8032F870 – 0x80331F50 (9952)
BSS Area:                  0x80331F50 – 0×80333700 (6064)
Local Heap:                0×80333700 – 0×80397700 (409600)
Stack Area:                0×80397700 – 0×80399700 (8192)
Text (code) segment:       0×80300000 – 0x8032F870 (194672)
Boot area (physical):      0x0039A000 – 0x003DA000
Relocation Factor:         I:00000000 – D:00000000

Committing NVRAM…done
Device eth0:  hwaddr 00-40-77-BB-55-10, ipaddr 192.168.1.1, mask 255.255.255.0
gateway not set, nameserver not set
Reading ::

Unlike the WRT54G however, the WL-520GU bootloader did not specify its IP address, and the usual 192.168.1.1 did not work; watching the network traffic while attempting the TFTP transfer revealed that this address was not responding to ARP requests at all. Additionally, while the WRT54G waits for a TFTP connection for a few seconds before timing out, the WL-520GU only listens for about one second before timing out and loading the kernel. Such a short time period, coupled with not knowing the bootloader’s IP address, made flashing via TFTP nearly impossible.

The solutions to both these problems were found (directly and indirectly) through DD-WRT’s WL-520GU Wiki page. By holding down the reset button on the router on boot up, the bootloader will enter hardware restoration mode and perpetually listen for TFTP connections rather than continuing with the boot process. This can be confirmed by watching the serial console output; you should see repeating messages that read: “Reading :: Failed.: Timeout occured”. The power LED should also be blinking slowly when the router is in hardware restoration mode.

Once you have the router constantly listening for TFTP connections, you still need to know the IP. This was discovered by downloading the Asus restoration utility and monitoring the network traffic it generated. This revealed that the router’s bootloader IP address was 192.168.1.49. With the router in hardware restoration mode and knowledge of the bootloader IP address, it was easy to upload the firmware via TFTP:

tftp> mode binary
tftp> trace
tftp> connect 192.168.1.49
tftp> put openwrt-brcm-2.4-squashfs.trx
sent DATA <block=1, 512 bytes>
received ACK <block=1>
sent DATA <block=2, 512 bytes>
received ACK <block=2>
…