Unfortunately, answering these questions takes a lot of time.  What is particularly time consuming is that I often answer the same questions over and over again.

Why is this?

One reason is that I receive a lot of requests for support via private channels such as PMs on the forums, contact form submissions, and e-mail.

In an effort to reduce my support workload and encourage collaboration between customers and readers of the blog, I have slowly started to redirect support requests to the support forums.  The forums help me help you.  All posts on the forums are public, so other readers can participate in and benefit from the discussion.

Moving forward, I will no longer be answering support requests via a private channel.  If you send me an e-mail, contact form, or PM on the forums that is not of a specifically private nature, there’s a good chance I will respond with a form letter redirecting you to the support forums.  This isn’t because I don’t want to help, but because I need to make the most effective use of the limited amount of time I have to provide support.

Of course, this doesn’t mean that I won’t be responding to private communications at all – if you have something you would like to discuss that warrants a closed conversation, then by all means, send me a private message on the forums or submit a contact form.

I’d also like to point out that product support gets top priority, so if you have a question about a project that doesn’t involve a kit (like the Wifi Radio project) and I don’t respond immediately, please bear with me – I’ll get to your request as soon as I can.

The rain and dropping temperatures in San Francisco this weekend reminded me of a project I made in the winter of 2006.  This was long before mightyohm.com existed, so I originally documented the project at instructables.  I’m not going to repeat everything here, but I wanted to share some pictures and provide a link to the instructable in case anyone else wants to try this at home.

The project involves using a digital programmable thermostat to control an inexpensive space heater.  The original motivation for this was that I wanted to lower the temperature of the heater at night, reducing my energy bill, while still being able to wake up to a toasty room in the morning by setting the heater to turn on full blast 30 minutes before I awoke.

Here’s a schematic of the simple circuit I made to interface the thermostat to the space heater.  The resistor/diode/capacitor circuit allows the thermostat, which is designed to control an AC load, to switch power to a 24VDC coil relay.  A 36VAC

I installed the necessary components inside the case of an old power and telephone line filter, used to protect a fax machine or office copy machine from power surges.  The case came with a handy 110V outlet mounted on the front panel which I reused for this project.  The digital thermostat mounts to the top cover of the case.

I used a barrier strip as a way to simplify the wiring and mount the few loose components:

I had to adjust the value of C1 to get reasonably clean DC to the relay while not having an annoying turn-off lag when the control line from the thermostat goes low.  100uF works well for the relay I used.

Here’s the finished product installed in my former bedroom:

I haven’t used it since I moved into a house with working central heating, but it sure came in handy during the cold winter I spent in a 100 year old farmhouse in Petaluma.  This solved the problem of the sub-50 degree mornings I was having nicely!

instructables.com: Space heater controlled by digital thermostat

Comments?  Questions?  Leave a comment below!

This is my nephew, Harrison, doing what he does best – being cute.

For his first birthday, Harrison’s Mom wanted to give him something really special.  Not just an ordinary toy for a one year old, but something strange and wonderful, tactile, interactive, unique.  Thus was born the idea of an “electric box”, an electronic contraption full of switches, lights, buttons, knobs, levers, and sounds.

An elite task force was assembled to create this special gift, codenamed “Harrison’s Box”.  The team consisted of Grandpa, the Woodworker, Jeff (alias mightyohm) the Engineer, and Kylie, the Project Manager.

Upon defining the project, we immediately jumped into phase one, Procrastination.  Deliverables were met, and as the birthday loomed closer, we eased into phase two, Git ‘er’ Done.

Supplies and materials were ordered, wood chips started flying, and soldering irons blazed.  A short time later, the front panel was realized:

Harrison’s box consists of (clockwise from the upper left):

• A buzzer (sound comes out the four holes)
• A group of red, yellow, and green LEDs that respond to button pushes below
• A panel meter (for looks!) from the junkbox
• A pair of robots with blinking red eyes (aka tradeshow schwag)
• A pong controller, scrounged at the Prototype This! garage sale on Treasure Island
• Three large, brightly-colored arcade-style pushbuttons and a large joystick
• A numeric keypad
• Some random buttons and switches

Almost all of the electronic components, including the arcade buttons and joystick, were sourced from All Electronics.  A few odds and ends came from my junkbox.

The wiring is point to point – zipties and hot glue keep all of the individual wires in place.  Here’s a shot of the wiring for the pushbuttons and the joystick.

The buzzer consists of the guts of a cheap bicycle buzzer and a single C cell battery to power it.  Some creative wiring allows a pushbutton elsewhere on the panel to control the buzzer.

I salvaged a few high brightness red LEDs from a surplus automotive taillight assembly I picked up at Weird Stuff a few years ago.  A 5 Watt power resistor I had in my junkbox limits the current to the LEDs to a bright but not blinding level.

The whole box (with the exception of the buzzer, as noted above) is powered by a pair of AA batteries.

Finally, the big day arrived, and it was time to present Harrison (and Mom) with his gift:

Initially the Box was met with some skepticism.  Perhaps Harrison was dwelling on the simple question: Toy or thermonuclear device?  Understandably, there were very cautious button pushes at first.

Moments later, knobs were being turned, switches switched, buttons pushed, and Harrison had learned how to use the joystick.  Look out Steve Wiebe!

The front panel mounts to a small stand that conceals and protects the wiring while also giving Harrison something to hold onto while operating the Box.

I’m happy to report that Harrison’s Box was a success.

Check out more pictures of the box on flickr.

This is the eighth part of an ongoing series about building a low cost, open source streaming internet radio based on the ASUS WL-520gU Wireless Router.  If you haven’t already, check out the previous parts (see the links at the end of this article) for some background about the project.

In part seven, we added an LCD status display for the radio that shows the stream name as well as the artist and title of the current track.  In this part, we’ll add a tuning knob that lets us change stations without using a computer.

It turns out that this is mostly a software exercise, made simple by taking advantage of the analog to digital converter function of the Atmel ATmega168 AVR that is controlling the LCD display.  The addition of the tuner control turns the display circuit into a very simple user interface.  Turn the knob and the station changes.  The position of the knob determines what station the radio is “tuned” to, and when combined with a calibrated scale it will make it easy to change to any one of the several streaming radio stations stored as presets (favorites?) in the router.

To give you an idea of how this works, here is a demo of the tuner control changing between ten preset stations I have set on the router.  The tuner control is in the upper right hand corner of the breadboard.  As I adjust the control, the music changes and LCD display updates to show the name of each new station.

Is that cool or what?

If you are interested in adding this functionality to the radio, keep reading and I’ll show you how.

Changes to the hardware:

You will need:

• The completed AVR-based LCD display from part seven
• A 1k-10k trimmer or potentiometer, linear taper
• Some hookup wire

Schematic:

Here is an updated schematic of the AVR circuit showing the potentiometer connected to ADC4 (pin 27).

click to enlarge

Firmware:

The AVR firmware has been significantly expanded, slightly reworked and cleaned up in some areas.

The most important changes are:

• The addition of a serial transmit function so the AVR can talk to the router (based on the uart_putchar function)
• New code supporting the analog to digital converter (ADC) which reads the value of a potentiometer connected to ADC4.
• A new Timer1 overflow interrupt has been added, which occurs roughly every 0.5 seconds.  The interrupt service routine (ISR) checks the position of the tuner control, and if it has changed, sends the value to the router.  The ISR is towards the top of the file, see the SIGNAL (TIMER1_OVF_vect) section.

The ADC range of the ATmega is 0 – 1024 for an input voltage from 0 to 5V.  The AVR sends serial data in the format “Tuner: Value” back to the router when the tuner position changes by more than ADC_SENS counts (default is 5).  The AVR waits for an “AVR Start!” command from the router before sending any data, this avoids filling up the serial receive buffer on the router before it’s ready to start processing data.  An important consequence of this is that the AVR must be reset before running the control script on the router.

You can download the source code and compiled .hex file here.  Flash it to the AVR using any compatible ISP programmer and you should be good to go.  The source is commented fairly well so if you’re interested in learning how the interface works, take a look.  You will need a copy of the ATmega168 datasheet to understand the register names and other architecture-specific parts of the code.  Feel free to post in the comments with any questions.

Modifying the circuit:

This part is pretty simple – just wire the potentiometer as shown in the schematic.  Most potentiometers have three terminals.  The left terminal goes to ground, the right one to +5V, and the middle terminal to ADC4 on the AVR (pin 27).

Tweaks to the OpenWrt configuration:

To make bidirectional communication with the AVR work, we have to change a couple config files on the router and disable some services that would otherwise get in the way.

/etc/config/network

The first change is to modify the /etc/config/network file so that we can always telnet or ssh into the router on a LAN port using the IP 192.168.1.1.  The ability to access the router via ethernet is helpful in case we screw something up and lose the wireless connection or the router loses it’s IP address, etc.

Modify the LAN section of /etc/config/network to look like this (changes in bold):

#### LAN configuration
config interface lan
#option type     bridge
option ifname    "eth0.0"
option proto    static
option ipaddr    192.168.1.1
option netmask    255.255.255.0

Save changes, restart the router, and connect an ethernet crossover cable (straight cable might work on some computers) to the router.  Configure your desktop/laptop computer with a static IP, like 192.168.1.185.  Try to open a telnet connection (or ssh if you have set a password on the router) and see if you can log in.  If not, don’t continue with the next steps until you can get this working.

/etc/inittab

We previously used the router’s serial port to get a login shell.  Now that we’re trying to receive data from the AVR on the same serial port, we need to disable the login shell or it will capture the data before we can get to it.

Edit /etc/inittab to look like this (changes in bold):

::sysinit:/etc/init.d/rcS S boot
::shutdown:/etc/init.d/rcS K stop
#tts/0::askfirst:/bin/ash --login
#ttyS0::askfirst:/bin/ash --login
tty1::askfirst:/bin/ash --login

/etc/sysctl.conf

Sysrq is a fascinating and very low level debugging feature of the Linux kernel.  It can be used to perform troubleshooting operations and reboot the system.  Usually it is invoked with a magic key combination on a desktop computer, but in this case I found that it is easy to accidentally trip over the serial port when using an AVR.  (The “break” RS-232 code triggers Sysrq, this probably has something to do with it.)

Fortunately, it’s easy to disable by editing the /etc/sysctl.conf file and adding these lines:

# Disables the magic SysRq key
kernel.sysrq = 0

Reboot the router to apply the changes.  Now we can get on with the good stuff!

Shell scripting magic:

The real action happens on the router, where a shell script waits for input from the router and changes the station accordingly.

This script is called interface.sh and can be downloaded to the router using wget as shown:

root@OpenWrt:~# cd ~
root@OpenWrt:~# wget http://mightyohm.com/files/wifiradio/interface.sh
...
root@OpenWrt:~# chmod ugo+x interface.sh

The interface script calls an updated version of the display script from part 7, called display2.sh:

root@OpenWrt:~# wget http://mightyohm.com/files/wifiradio/display2.sh
...
root@OpenWrt:~# chmod ugo+x display2.sh

Once both scripts are downloaded, executable and located in /root you can launch interface.sh as follows:

root@OpenWrt:~# ./interface.sh
volume: 60%   repeat: on    random: off
volume: 60%   repeat: on    random: off
adding: http://relay3.slayradio.org:8000/
adding: http://scfire-dtc-aa01.stream.aol.com:80/stream/1046
adding: http://208.101.28.234:8004

… more stations here …

Tuner Position:  0
New station...

http://relay3.slayradio.org:8000/

[playing] #1/10   0:00/0:00 (100%)
volume: 60%   repeat: on    random: off

The interface script adds ten presets to the router, shows the playlist, and then waits for valid tuner data from the AVR.  Once it receives a “Tuner: value” line (which should occur shortly after the AVR receives a go signal from the script), the script prints the received tuner positon and changes to the requested station.  It will then wait for new tuner data from the AVR and change the station when necessary.

As you can see in the video, this works very well.  Over a fast Wi-Fi connection, the time to change stations is almost instantaneous – very satisfying!

That’s it for part eight.  In part nine, I’ll add some finishing touches to the router configuration and start talking about enclosures.  Stay tuned!

Update: There is a new Wifi Radio Discussion Forum, hop over there to ask questions about the project or see what other people are working on!  (4/12/09)

Update 2: Part nine is now available.

In part six, we used OpenWrt’s UNIX-style shell commands to interface with mpd, the music player daemon, and redirect song and stream information to our ASUS WL-520gU wireless router’s serial port.  In this part, we’ll use a Sparkfun 16×2 LCD display and a handful of other components to build an LCD status display for the radio.

The Atmel AVR Microcontroller:

After much thought, I decided to use an Atmel ATmega168 AVR microcontroller to drive the display.  I realize that this raises the technical level of this project significantly, but I have been wanting to feature an AVR project on the site and this is a great opportunity.  The truth is that an Arduino would work just as well and it shouldn’t be too difficult to port this program to an Arduino sketch.  (The Arduino is built with the same ATmega168 microcontroller, after all.)  If anyone does this, let me know and I’ll post a link to your version of the display.

If you’re an AVR veteran, you can skip over this part and straight to the bill of materials below.

If you are new to the AVR, don’t be intimidated.  There are a number of tutorials online to help you learn how to use this inexpensive and powerful microcontroller.  I recommend starting with this one or maybe this one, but see my note about AVR MacPack below if you’re using a Mac.  If you’ve never programmed in C before, you’ll have an additional hurdle to get over, although for this project you won’t need any actual knowledge of programming or C to burn the code to the AVR and get things working.

You will need to install some software to work with the AVR, I recommend:

• AVR MacPack for OS X (the Adafruit tutorial recommends OSX-AVR, use this instead)
• WinAVR for Windows

I recommend following a tutorial or two and getting a simple blinking LED example working on your AVR before building the LCD display.  That way you can be sure your programmer, development environment, breadboard, etc are working first.

Building the display:

Bill of Materials:

You will need:

• one A-B USB cable (the kind with one flat and one square end)
• an AVR programmer, such as the Adafruit USBTinyISP
• an Atmel ATmega168 AVR microcontroller
• a working AVR development suite or at least a way to get a .hex file onto an AVR (see above)
• an LCD display like this fancy LED backlit Sparkfun 16×2 Character STN
• a solderless breadboard, like this one (comes with precut wires!) or this one.
• a 4-pin female 0.1″ header, this breakaway header is handy.
• two 22pF ceramic capacitors, rated >6V (mine are 25V)
• a 0.1uF capacitor, rated >6V
• a 10 Ohm resistor
• for contrast adjustment, a small 1k or 10k potentiometer
• a few feet of 20 to 24 gauge solid hookup wire

also nice, but not required:

• a Sparkfun ISP breakout board to simplify connecting the programmer to the breadboard
  
• a normally-open pushbutton switch to reset the circuit

Schematic:

Here is the schematic of the LCD display (click to enlarge):

Firmware:

You can download the source code and compiled .hex file here.

Special thanks to Peter Fleury for his excellent LCD library, which saved me from reinventing the wheel!  He also has another page about interfacing LCD displays to an AVR.

Assembling the circuit:

Assembling the circuit on the breadboard is pretty straightforward.  Here’s a photo showing all components of the setup.  The router is shown above with the serial port wired to the breadboard (the RX line is floating as we’re not using it yet).  The USB AVR programmer is on the right, where it is also functioning as a 5V power supply for the circuit. Make sure the 2-pin jumper on the USBTinyISP is installed, this enables the +5V supply.  The LCD is shown displaying the current stream name (DI.fm).

Here is a closeup of the components installed on the breadboard to show how I did things, feel free to experiment with the placement of components.  As long as you follow the schematic the circuit should still work.

Here is a closeup of the serial port connection to the router, including the 4-pin female 0.1″ header.  I soldered wires to the pins of the female header (not the pins on the board).

Here is a closeup of the AVR, crystal, and the Sparkfun ISP breakout board showing the pinout:

Flashing the AVR:

Once the circuit is assembled on the breadboard, we need to flash the AVR microcontroller with the main.hex file included with the firmware above.

If you’re using AVR MacPack and OS X, this should be easy (since that’s what I’m using).  PC guys will need to figure this out for themselves but hopefully the process is similar (please let me know if the Makefile works).

Connect the USBTinyISP to your computer with the USB cable and to the breadboard with the ISP cable.  The green light on the programmer should be on, indicating it is ready, and the backlight of the LCD should be lit, indicating that the breadboard is getting power.

Open a terminal window and create a new directory, I used ~/temp.  Unzip the firmware into a directory somewhere, and execute ‘make flash’, as shown:

macbook:temp jkeyzer$ unzip ./AVR_wifiradio_display.zip
Archive:  ./AVR_wifiradio_display.zip
  inflating: lcd.c
  inflating: lcd.h
  inflating: main.c
  inflating: main.hex
  inflating: Makefile
macbook:temp jkeyzer$ make flash
avr-gcc -Wall -Os -DF_CPU=16000000 -mmcu=atmega168  -c main.c -o main.o

a few warnings later …

avr-gcc -Wall -Os -DF_CPU=16000000 -mmcu=atmega168  -c lcd.c -o lcd.o
avr-gcc -Wall -Os -DF_CPU=16000000 -mmcu=atmega168  -o main.elf main.o lcd.o
rm -f main.hex
avr-objcopy -j .text -j .data -O ihex main.elf main.hex
avrdude -c usbtiny -p atmega168 -U flash:w:main.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9406
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "main.hex"
avrdude: writing flash (1326 bytes):

Writing | ################################################## | 100% 3.32s

avrdude: 1326 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex contains 1326 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.68s

avrdude: verifying ...
avrdude: 1326 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

If everything went well, the LCD display firmware is now loaded into the ATmega168 and the circuit is ready to go.  If not, double check your connections and take a look at the help! page for the USBTinyISP.

Testing the display:

Telnet or ssh into the router.  Start mpd and connect to a stream using mpc (we covered this in part five).

Once the stream starts playing, execute the display.sh script we created in part six.  Within a few seconds, if everything is working, you should see the stream name on the display, followed by the artist and name of the current song.  Congratulations!

Here is a video of the LCD display in action, including the horizontal scrolling feature to show information that is too wide to fit within the visible area of the display:

That’s it for part seven!  In part eight, we’ll start working on the input side of the user interface.

Like what you’re seeing?  Have suggestions about what could be improved?  Leave a comment or contact me directly.

Update: Part eight, in which I add a tuning control to the radio, is now available.

Update 2: There is a new Wifi Radio Discussion Forum, hop over there to ask questions about the project or see what other people are working on!  (4/12/09)

Let’s review…

It’s been a few weeks since I posted part five, so let’s quickly review where we are with this project:

At this point we have a hacked ASUS WL-520gU wireless router running OpenWrt (Linux).   A cheap USB-audio adapter is connected to the router’s single USB port, and in part four we installed kernel drivers for Linux USB and audio support.  In part three we added a connection to the router’s internal serial port via a 4-pin header.  Wireless networking worked pretty much out of the box, and in part five we used opkg, OpenWrt’s package manager, to install mpd, the Linux music player daemon, and mpc, a command-line-based mpd client.

This gives us a compact networked device that can wirelessly connect to streaming radio stations and play 16-bit 44kHz stereo audio on a pair of headphones or amplified external speakers.  Pretty impressive, given that this device started as an inexpensive wireless router!

What’s missing?

Something big is missing from the radio.  The original concept for this radio was that it would be a standalone device.  Shell access is cool, and iPhone control is even better, but ideally we’d like to be able to see what song and station are currently playing as well as change stations without the use of another computer or mobile client.

What we need is a user interface!

Based on our requirements, the user interface needs to do two things:

1. Display information about what’s playing from mpd
2. Gather input from the user and tell mpd when to change stations.

A volume control will be part of our finished user interface as well, but it will be simple enough to do this in hardware when we put the radio into an enclosure.  In this part, we’ll start work on the first requirement – the display.

Note: The following steps assume you are accessing the OpenWrt shell through a telnet or ssh connection, not using the FTDI USB-serial cable.  The reasons for this will become obvious later, when we start using the router’s serial port for other purposes!

First of all, how do we get information about what’s currently playing on our radio?

Chatting with mpd:

The command-line program mpc that we installed in part five will return information about the current song if we execute it without any options:

root@OpenWrt:~# mpc
SLAY Radio: Jogeir Liljedahl - Terra Cresta
[playing] #1/5  22:36/0:00 (100%)
volume: 60%   repeat: on    random: off

Mpc obtains playlist, volume, and settings information by sending queries to the mpd server running on the router.  The mpd site includes an overview of the communications protocol and command set.  By default, mpd listens for commands on port 6600.  You can access this port remotely by using one of many client programs, or locally by opening a telnet connection to port 6600 locally (the commands are in bold for clarity):

root@OpenWrt:~# telnet localhost:6600
OK MPD 0.13.0
status
volume: 60
repeat: 1
random: 0
playlist: 14
playlistlength: 5x
fade: 0
state: play
song: 4
songid: 4
time: 2348:0
bitrate: 192
audio: 44100:16:2
OK
currentsong
file: http://relay3.slayradio.org:8000/
Name: SLAY Radio
Title: Jogeir Liljedahl - Terra Cresta
Pos: 0
Id: 0
OK

The connection will timeout in about a minute if left idle.

As you can see, there is a lot of information available, including some of the same information mpc gave us earlier.  The advantage of directly accessing mpd is that we get the stream name (the Name: line) and the artist/title (the Title: line) broken down separately instead of on one continuous line, with handy labels that will make it easy for us to parse the data later.

We can also access mpd by using the nc command, short for “network cat”.  Using nc allows us to easily pipe data from other commands to mpd and examine the results.

root@OpenWrt:~# echo "currentsong" | nc localhost 6600
file: http://relay3.slayradio.org:8000/
Name: SLAY Radio
Title: Jogeir Liljedahl - Terra Cresta
Pos: 0
Id: 0
OK

(As an aside, OpenWrt uses a program called busybox to emulate a UNIX-style shell environment – several common shell commands are included.  There is considerable documentation here, but not all commands listed are actually included in the default OpenWrt busybox installation.)

If we just want the name and title of the current song, we can use the UNIX command grep to strip out just those two lines:

root@OpenWrt:~# echo "currentsong" | nc localhost 6600 | grep -e "^Title: " -e "^Name: "

Name: SLAY Radio
Title: Jogeir Liljedahl - Terra Cresta

Talking to external devices:

Now that we have a way to get song information from mpd, we need a way to direct this information to an external display.  The router comes with a handy mechanism for doing this – the builtin serial port.  Linux makes it easy to direct the output of grep to the router’s serial port, just add a redirect to /dev/tts/0 at the end of the command (all on one line, wrapped here to fit the page):

root@OpenWrt:~# echo "currentsong" | nc localhost 6600 | grep -e "^Title: "
-e "^Name: " > /dev/tts/0
root@OpenWrt:~#

However, it turns out that the serial port’s default speed of 115200 baud is too fast for some external displays.  If we want to be able to talk to an AVR microcontroller, for example, we need to change the speed of the serial port from it’s default value of 115200 to 9600 baud.  This can be done easily with the stty command.

Note: If you downloaded and installed OpenWrt prior to December 3rd by using the files on this site, stty is most likely missing from your installation.  Unfortunately, the only way I know of to easily fix this is to completely reinstall OpenWrt, since stty is part of busybox and included in the base firmware image.  You can check if you have it by executing ‘stty’ from the command line of the router – if you get an error, you will need to reinstall.

You can change the baud rate of the serial port by executing:

root@OpenWrt:~# stty 9600 < /dev/tts/0

Connect your FTDI USB-serial cable to the router’s serial port and open a terminal program set to 9600 baud, 8N1. Execute the last mpd query again, you should see the name and title appear in your terminal window:

root@OpenWrt:~# echo "currentsong" | nc localhost 6600 | grep -e "^Title: "
-e "^Name: " > /dev/tts/0

In the terminal window:

Name: SLAY Radio
Title: Jogeir Liljedahl - Terra Cresta

Now we have a way to get information about the current song and direct it to the serial port.

We can do this is an automated way by using a shell script:

#! /bin/sh -
# display.sh - Wifi Radio LCD display routines
# 12/12/08    Jeff Keyzer    http://mightyohm.com
# This shell script queries mpd for current song information and sends
# relevant bits of it to the serial port, where an AVR-based LCD display
# is waiting.
#
# For more information, visit
# http://mightyohm.com/blog/
#
trap 'exit 1' SIGINT    # exit on ctrl-c, useful for debugging
stty 9600 < /dev/tts/0  # set serial port to 9600 baud
                        # so we can talk to the AVR
while true        # loop forever
do
 echo "currentsong" | nc localhost 6600 | grep -e "^Title: " -e "^Name: " > /dev/tts/0
 sleep 1
done

You can either copy and paste this script to a file on the router, or download it with wget:

root@OpenWrt:~# cd ~
root@OpenWrt:~# wget http://mightyohm.com/files/wifiradio/display.sh
Connecting to mightyohm.com (72.32.209.132:80)
display.sh           100% |*******************************|   668  --:--:-- ETA

Be sure to make the script executable by using chmod:

root@OpenWrt:~# chmod ugo+x display.sh

If you run the script you should see the name and title information update in the serial terminal once a second.

root@OpenWrt:~# ./display.sh

The script will loop forever – hit control-c in the router’s shell to exit.

That’s it for part six!  In part seven, we’ll add an AVR-based serial LCD display to the router – stay tuned!

Update: Part seven is now available.

Update 2: There is a new Wifi Radio Discussion Forum, hop over there to ask questions about the project or see what other people are working on!  (4/12/09)

Building a Wifi Radio – Part 1, Introduction

Building a Wifi Radio – Part 2, Choosing an Embedded Platform

Building a Wifi Radio – Part 3, Hacking the Asus WL-520GU

Building a Wifi Radio – Part 4, Installing OpenWrt

Note:

The instructions that follow assume that you have an Asus WL-520GU wireless router with the following modifications: an externally accessible serial port, OpenWrt installed and working, and a configured network connection on the router.  If not, check out the previous parts of the series to learn more.

Using opkg to customize OpenWrt:

OpenWrt includes a utility called opkg that allows the end user to easily add and remove optional software packages.  These packages include functionality that is not a part of the OpenWrt base image, such as hardware drivers (including USB), optional software, and utilities.  Most packages are not installed by default (after all, the router only contains 4MB of flash storage).  The OpenWrt Community Wiki includes a very helpful page about Packages that contains a lot of useful information about configuring and using opkg.

Before we can use opkg we need to configure it.  The file /etc/opkg.conf contains a few options, including the URL of the server opkg uses to find and download packages.  We need to change this server from the default by modifying the config file:

root@OpenWrt:~# vi /etc/opkg.conf

Modify the first line to look like this:

src/gz snapshots http://mightyohm.com/files/kamikaze-2.4/packages/mipsel 

dest root /

dest ram /tmp

lists_dir ext /var/opkg-lists

You can also download the complete set of packages and set up a server of your own for opkg to access.  I have had great success using the apache server included with OS X, but I won’t cover the setup here.

The following command tells opkg to fetch a list of available packages from the server:

root@OpenWrt:~# opkg update

You should see the following response:

Downloading http://mightyohm.com/files/kamikaze-2.4/packages/mipsel/Packages.gz

Connecting to mightyohm.com (72.32.209.132:80)

Packages.gz          100% |*******************************|  8326  --:--:-- ETA

Inflating http://mightyohm.com/files/kamikaze-2.4/packages/mipsel/Packages.gz

Updated list of available packages in /var/opkg-lists/snapshots

Signiture check for snapshots skipped because GPG support was not enabled in this build

Now we can start installing packages.  To access our USB-audio converter, we need to install USB 1.1 (OHCI) support and some sound drivers:

root@OpenWrt:~# opkg install kmod-usb-audio kmod-usb-ohci

This should automatically install kmod-usb-core and kmod-sound-core, but if not you can also install them manually with the opkg install command.

At this point you should insert the USB-audio converter if you haven’t already.  Then reboot the router:

root@OpenWrt:~# reboot

As the router is booting again, watch for new status messages like these:

...
usb-ohci.c: USB OHCI at membase 0xb8003000, IRQ 6

usb-ohci.c: usb-00:03.0, PCI device 14e4:471a

usb.c: new USB bus registered, assigned bus number 1

usb.c: registered new driver audio

audio.c: v1.0.0:USB Audio Class driver

usbaudio: device 2 audiocontrol interface 0 has 1 input and 1 output AudioStreaming interfaces

usbaudio: device 2 interface 2 altsetting 1 channels 1 framesize 2 configured

usbaudio: valid input sample rate 48000

usbaudio: valid input sample rate 44100

usbaudio: device 2 interface 2 altsetting 1: format 0x00000010 sratelo 44100 sratehi 48000 attributes 0x01

...
usbaudio: registered dsp 14,3

usbaudio: constructing mixer for Terminal 6 type 0x0301

...

If you see this, the USB-audio converter is most likely working and the correct drivers have been loaded.  At this point the green LED inside the USB-audio converter should be lit, another sign that everything is working correctly.

Installing mpd:

To actually play some tunes we need to install some additional software.  We can use opkg to do this, as follows:

root@OpenWrt:~# opkg update

root@OpenWrt:~# opkg install mpd mpc

This command installs mpd, the music player daemon.  mpd is an open source music server that can be accessed locally or across a network by using a variety of clients, which are available for many different platforms.  This includes the command line client mpc which is also now installed on the router.

mpd requires some setup before we can use it:

root@OpenWrt:~# cd ~

root@OpenWrt:~# mkdir .mpd

root@OpenWrt:~# mkdir music

root@OpenWrt:~# mkdir .mpd/playlists

root@OpenWrt:~# vi /etc/mpd.conf

Scroll down and look for the audio_output section of the mpd configuration file, and change the reference to /dev/dsp to make it look like this:

# An example of an OSS output:
#
audio_output {
        type                    "oss"
        name                    "My OSS Device"
        device                  "/dev/sound/dsp"
        format                  "44100:16:2"
}

There are many other options you can play with; mpd is very powerful.  There is a list of features here and a lot more information on the mpd wiki.

Exit vi, saving the changes to mpd.conf.  Now launch mpd with the following command:

root@OpenWrt:~# mpd

The player should start silently, without errors.  Run mpc and verify that it can talk to the server:

root@OpenWrt:~# mpc
volume:100%   repeat: off   random: off

If you see this, good news, the server is running and we have the ability to control it with mpc!

Now would be a good time to connect speakers or headphones to the USB-audio adapter’s headphone output.  Warning – the initial volume can be VERY LOUD. Don’t wear headphones during testing!  PC speakers with a volume control are best.  Start at a low volume.  (My ears are still ringing!)

We can add a streaming radio server to the playlist by executing

root@OpenWrt:~# mpc add http://relay3.slayradio.org:8000/
adding: http://relay3.slayradio.org:8000/

And finally, the moment of truth:

root@OpenWrt:~# mpc play

http://relay3.slayradio.org:8000/

[playing] #1/1   0:00/0:00 (100%)

volume:100%   repeat: off   random: off

root@OpenWrt:~#

If all goes well, within a few seconds you should hear Slay Radio playing on your headphones or speakers.  The Air light on the router should flicker as traffic crosses the WiFi interface, and the green light on the USB-audio converter should flash repeatedly to indicate that audio is being sent to the device.

If you’ve made it this far, I recommend celebrating with your favorite beverage and enjoying some tunes!  Congratulations!

You can add other servers to the playlist by executing the mpc add command again, and then play them with the mpc play n command, where n is the position of the server in the playlist.  mpc playlist will display the current playlist. mpc help will give you a list of available commands.

One very powerful feature of mpd is that it operates as a server on port 6600 of the router, so it can be controlled from any other device on your local network.  If you download an mpd client such as Theramin, you can control the router remotely from your desktop computer.  There is an excellent client for the iPhone too.

That’s it for part five.  I hope you have enjoyed the series thus far.  In part six, we’ll start writing some scripts to control mpd and talk about options for a user interface.  If you are building a Wifi Radio of your own, I’d love to hear about it – leave a comment below!

Update: Part six is now available.

At this point you should have an Asus WL-520GU wireless router with a serial port header installed and some way of communicating with the serial port from your PC.  If not, go back to part three.

What is OpenWrt?

According to openwrt.org:

OpenWrt is described as a Linux distribution for embedded devices.

OpenWrt replaces the stock firmware on the WL-520GU with an open source Linux distribution that aims to be extremely powerful and flexible.  This is important for us because in turning a wireless router into a Wifi radio, we using the device in a way that the manufacturer never intended for it to be used.  In addition to including a stripped down version of the Linux operating system, drivers for wireless networking and all the basic functionality of a residential network gateway, a package manager called opkg allows you to install a wide variety of add-on modules to extend the functionality even further.

Setup:

To install OpenWrt on the WL-520GU you will need a few things:

• Your Asus WL-520GU wireless router, modified to allow access to the internal serial port
• A 3.3V USB-serial cable like the FTDI-232-3V3
• A short ethernet cable (a crossover cable is not required)
• A desktop or laptop computer with an open USB and ethernet port
• A terminal program such as ZTerm or Hyperterminal
• A TFTP client, (surprisingly) included with most operating systems.  I’ll be using the one included with OS X.
• A WiFi network with a reasonably simple encryption scheme (ie. none, WEP, WPA)

If you want to compile your own OpenWrt image and optional packages, you’ll also need

• A machine running Debian or similar Linux operating system, or if you are really ambitious, a Mac running OS X.  I won’t cover compiling OpenWrt using OS X here, but there are several issues that prevent it from being straightfoward, the first of which is that OS X does not use a case-sensitive filesystem by default.

Note: If for any reason you need to go back to the stock firmware, you can download it from Asus here (enter WL-520GU into the search field on the left).

Getting OpenWrt:

There are two ways to do this:

The hard way:

Visit the OpenWrt Wiki and read the instructions on Installation.  Follow these instructions to build Kamikaze (Kamikaze is the current OpenWrt distribution).  Download the source with subversion (svn), and compile it yourself.  This method requires a moderate level of skill with Linux, but if you can compile your own kernel you should be able to compile OpenWrt.  You will need to link to the feeds for madplay, mpc, and mpd (as well as any other 3rd party packages you want) before executing make menuconfig, by using the scripts/feeds command.  Here is the sequence of commands I used, yours may differ slightly:

svn co https://svn.openwrt.org/openwrt/trunk/ ~/kamikaze
cd ~/kamikaze
./scripts/feeds update -a
./scripts/feeds install madplay mpc mpd
make prereq

If make fails, you may need to install some optional Linux tools, such as gawk, bison, or gcc.  On Debian I used the apt-get command to do this

apt-get install gawk bison gcc

Once you have all necessary prerequisites installed, you can configure the build with

make menuconfig

You’ll need to set the following options:

Target System (Broadcom BCM947xx/953xx [2.4])

Target Profile (Generic, Broadcom WiFi (default))

Select all packages by default

Image configuration —>

• Base system (Added 12/18/08 to support part six)
  • busybox (press enter to open hidden menu)
    • Configuration
      • Coreutils
        • stty
• Kernel modules
  • Sound support
    • kmod-sound-core
  • USB support
    • kmod-usb-core
    • kmod-usb-ohci
    • kmod-usb-audio
• Sound
  • mpd
  • mpc
  • madplay

Once you’re done, exit, saving the configuration.  Then execute

make world

This will take quite a while.  If the build fails, you will be prompted to run make again

make world V=99

and fix any problems that occur, based on the error messages.  The OpenWrt forums are a good place to get help, but do a quick search before you post to avoid asking a question that has already been answered.

If the build completes successfully, you should be left with a bunch of files in the kamikaze/bin directory, including openwrt-brcm-2.4-squashfs.trx, the main image file, and a bunch of packages in the bin/packages/mipsel directory.

The easy way:

I’ve already done the hard work for you.

Download my precompiled openwrt-brcm-2.4-squashfs.trx image.

Addon packages (you’ll need a few of these when we configure the router later) are located here.

Installing OpenWrt:

Connect your FTDI cable to the serial port on the router that you added in part three.  Launch your favorite terminal program and connect to the router at 115200 baud, 8N1.

Connect the LAN1 port of the router to your computer using a short ethernet cable.  The router is hardcoded to be 192.168.1.1 on boot, and we need to configure our computer to talk to that address.  I set my Macbook to use a static IP of 192.168.1.185.  You may need to set a gateway to 192.168.1.1.  If your home network is also on the 192.168.1.x subnet, you will need to disconnect/disable it.  On my Macbook, this meant disabling the internal wireless and losing internet access while the router was connected.  (Eventually I got tired of this and moved my home network to 192.168.24.x, but that is outside the scope of this tutorial.)

Press and hold the Restore button on the back of the router and plug in the power cable.  The Restore button is shown just to the right of the red EZSetup button here:

Continue holding the Restore button until the power LED starts flashing once a second.  Release the restore button.  In your terminal window, you should see some boot messages and then

Reading :: TFTP Server.
Failed.: Timeout occured
Reading :: TFTP Server.
Failed.: Timeout occured

and so on (the messages will repeat forever).

Now it’s time to transfer our .trx file to the router.  These instructions are for OS X.  Instructions for other operating systems are here.

cd ~/kamikaze/bin
tftp
trace
timeout 1
mode binary
connect 192.168.1.1
put openwrt-brcm-2.4-squashfs.trx

On the serial console you should see (exact numbers may vary):

Reading :: TFTP Server.
TFTP_BLKLEN!!
break!! last block!!
Done. 1918724 bytes read
Download of 0x1d4704 bytes completed
Write kernel and filesystem binary to FLASH (0xbfc20000)
Programming...
copysize=1918724, amtcopy=1918724

If you don’t see this, chances are your computer is not talking to the router.  Most likely this is a configuration problem with your ethernet port or you don’t have the cable connected to a LAN port of the router.

If it worked, wait a couple minutes (don’t touch anything, unplugging the router at this point could brick the router!)  Eventually you should see the message

done. 1918724 bytes written

After this message appears (it typically takes 3-5 minutes for the whole process) unplug the router, wait a few seconds, and then plug it back in again.  In your serial terminal window, you should see the Linux boot messages again, but the process will pause briefly while the jffs file system is created.  Once the router has finished booting, you’ll see a couple messages like this

mini_fo: using base directory: /
mini_fo: using storage directory: /jffs

Press enter and you should now see the OpenWrt banner and a shell prompt

BusyBox v1.11.2 (2008-10-02 20:59:06 PDT) 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 (bleeding edge, r12831) -------------------

  * 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:/#

Congratulations!  You have successfully installed OpenWrt!

A complete log of the first boot is available here.

Configuring OpenWRT:

There is a lot of information on the OpenWRT Wiki with regard to Configuring Kamikaze, but I will walk through the fairly basic configuration I am using here.  To follow along, you will need to be comfortable using vi (if not, check out this quick reference card.)

You should be able to use your serial terminal to execute the following commands.  I had issues using the arrow keys to navigate in vi and had to use the basic movement keys instead (h=left, l=right, k=up, j=down).

Before we can get the router on a WiFi network we need to modify a couple files.

root@OpenWrt:~# vi /etc/config/wireless

You should edit this file to look like this (changes are in bold)

config wifi-device  wl0
	option type     broadcom
	option channel  2  # the channel your wireless network is on

	# REMOVE THIS LINE TO ENABLE WIFI:
	# option disabled 1 (comment out or remove this line entirely)

config wifi-iface
	option device   wl0
	option network	lan
	option mode     sta  # configures the router to connect to your network
	option ssid     MyNetwork # the SSID of your network
	option encryption wep  # the encryption mode of your network
	option key	XXXXXXXXXX  # add this line with your WEP key in place of X...X

Now we need to modify the networking configuration to use DHCP (this should apply for most people):

root@OpenWrt:~# vi /etc/config/network

Scroll down and look for the LAN configuration section, and edit it to look like this (note the dhcp option in bold, also comment out the last two lines as shown):

#### LAN configuration
config interface lan
      option type     bridge
      option ifname   "eth0.0"
      option proto    dhcp
      #option ipaddr   192.168.1.1
      #option netmask  255.255.255.0

Lastly, verify that resolv.conf is set correctly.

root@OpenWrt:~# vi /etc/resolv.conf

You should see the following line (this assumes the router will get a valid DNS server address via DHCP, if not, you can set it manually here):

nameserver 127.0.0.1

Then execute the following command:

root@OpenWrt:/# /etc/init.d/network restart

After a moment, if everything is working, the AIR light on the router should turn on and you should be able to ping some servers by name.

root@OpenWrt:/# ping www.google.com
PING www.google.com (74.125.19.104): 56 data bytes
64 bytes from 74.125.19.104: seq=0 ttl=240 time=20.113 ms

If you made it this far, congratulations!  You now have a working embedded Linux device on your WiFi network!

That concludes part four of this series.  In part five, I’ll cover installing addon packages using opkg.  If we’re lucky, we’ll get the router to play some tunes!

Update: Part five is now available.

Update 2: There is a new Wifi Radio Discussion Forum, hop over there to ask questions about the project or see what other people are working on!  (4/12/09)

Onward…

In part one, I discussed the merits of streaming internet radio and the motivations for my Wifi Radio project.  Now it’s time to start looking at what hardware can make this project a reality.  Before we get started, let’s review the requirements list from last time.

Requirements:

• Wireless connectivity through existing Wifi network
• Audio output (preferably 44kHz, 16 bit stereo)
• An integrated amplifier and speaker(s)
• Shoutcast/MP3 streaming audio decode
• Several builtin station presets
• A display to indicate the station and currently playing song
• Simple user interface, using standard radio controls (volume, tune, etc)
• 110VAC operation

There are two additional requirements that I implied in the first post but forgot to include explicitly:

• Cheap, priced below a commercial streaming radio – target < $100.
• Small size so it can be portable (no desktop PC’s allowed!)

Selecting the hardware:

How do these requirements translate into hardware?  Let’s take a stab at what features we’d like in an embedded platform.

• A wireless interface
• Audio output
• Sufficient system resources (CPU, memory, etc.) to decode MP3s
• Some extra IO for a control panel and display
• Low cost
• Small size
• Ease of development

The size and cost aspects pushed me towards an embedded system instead of a small form factor PC like any of Shuttle’s XPC offerings or a nano-ITX board.  To me, “Ease of development” equals Linux, so I wanted something well supported by Linux and an active open source development community.

There are quite a few embedded Linux platforms out there, with a wide variety of prices and features.  I looked at a few of them, including:

• The Tin Can Tools Hammer – very impressive ARM9-based board with USB, lots of RAM and flash, lots of IO, and best of all the footprint of a 40-pin DIP package (breadboard compatible!).  No wireless and relatively steep pricetag ($160).

• TI‘s Beagle Board – Incredible featureset including DVI output and a 600MHz ARM Cortex core.  No wireless and price is stunning for what you get, but overkill for this project ($150).  (Must keep in mind for future projects!)

• Consumer wireless routers like the Asus WL-500gP v2 and WL-520GU – builtin wireless (yay!), USB, 240MHz Broadcom 5354 core, decent RAM and flash, cheap. Newegg has the WL-520GU for an incredible $26 after rebate (normally $50). The higher end WL-500g has more memory and flash and an integrated USB 2.0 hub (2 external ports).  Newegg has the WL-500g Premium V2 for $50 after rebate (normally $80). Both versions are a steal for what you get.

Tiny, under $50 and with built-in wireless, the Asus WL-520GU is the clear winner for this project.  The downside?  Since this router was never intended to do anything other than, well, route, we’re going to have to crack it open, modify it, and void the warranty.  In addition, there is no tech support and we’re going to have to spend some extra time hacking around to get it to do what we want.

Here it is in all it’s glory:

Here’s a sneak peak of the inside:

This router is supported by OpenWRT, an open source Linux distribution for small embedded devices.  Ignore the work-in-progress designation, it works, trust me!

Although the router lacks builtin audio, that is easily solved with an $8 SYBA SD-CM-UAUD USB Stereo Audio Adapter. There have been reports that the WL-520GU only supports USB 1.1 reliably, but USB audio doesn’t require USB 2.0 so it’s not an issue for us.  For full USB 2.0 support, look at the WL-500gP v2 instead.

So far we have $58 into the project ($38 if you are lucky enough to get the rebate) and we have an embedded Linux computer, a wireless interface, and an audio output.  Not bad!

That’s it for part two!  In part three I’ll install a serial port on the router and get ready to reflash the stock firmware with OpenWrt.  At that point we’ll be able to start listening to some tunes!

Update: I posted detailed specs for the WL-520GU and a couple more photos here.

Update 2: I posted some images of the $8 USB-Audio Adapter I am using as well.

Update 3: Part three is now available.

Update 4: There is a new Wifi Radio Discussion Forum, hop over there to ask questions about the project or see what other people are working on!  (4/12/09)

Comments and (constructive) criticism are welcome. Click here to post a comment.

Table of Contents:

1. Building a Wifi Radio – Part 1, Introduction (you are here)
   
2. Building a Wifi Radio – Part 2, Choosing an Embedded Platform
3. Building a Wifi Radio – Part 3, Hacking the Asus WL-520GU
4. Building a Wifi Radio – Part 4, Installing OpenWrt
5. Building a Wifi Radio – Part 5, Let’s Make Some Noise!
6. Building a Wifi Radio – Part 6, A Conversation with Mpd
7. Building a Wifi Radio – Part 7, Building an LCD Display
8. Building a Wifi Radio – Part 8, Adding a Tuning Control
9. Building a Wifi Radio – Part 9, A Few Odds and Ends
10. Building a Wifi Radio – Part 10, Building the Box

Some background:

According to Wikipedia, in 1993 the first internet radio program began distribution.  At that time, radio programs were manually downloaded to be played later on the user’s home computer; the user experience was far from that of listening to a traditional broadcast radio receiver.  It was not until several years later that streaming radio became common, giving birth to internet radio stations that could be listened to much like traditional radio, but with several advantages.  Most notably, internet radio stations were (and still are for the most part) largely devoid of on-air advertising, and stations anywhere on the globe could be received by anyone with access to the internet.  Over time, improvements in audio compression (such as MP3) and larger end user bandwidth improved the fidelity and reliability of internet radio.  The birth of common standards like Shoutcast made it possible to listen to many stations with a single player program, like Winamp.

Today, most music playback software supports streaming radio in some way.  iTunes features thousands of streaming radio stations and even supports Shoutcast streams so that users can easily add additional stations of their own.

The beautiful thing about streaming radio is the huge diversity in programming that is available.  Many college radio stations have a streaming server, like KDVS.  Digitally Imported hosts many electronic and dance music streams that give the listener the choice to listen to specific genres like ambient or gabber hardcore (whoa).  Broadcast radio usually lumps all electronic dance music into one category, much to the dismay of their listeners (who probably tuned out during the commercial break, anyway).  Gems like Slay Radio specialize in music you would never hear on broadcast FM, like Commodore 64 remixes.

In the past couple years, products have started to appear that mimic the form and function of a traditional radio, but play internet radio instead.  Good examples of these are the Roku SoundbridgeRadio and the ASUS Internet Air.  Remote speaker devices, such as the Apple Airport Express, require a PC to receive and relay streaming radio but achieve a similar end result (but don’t really look much like a radio).

The Wifi Radio project:

I have been wanting to build a streaming radio for some time.  I frequently work in my garage, where I occasionally use my Macbook to play music through a small amplifier and bookshelf speakers.  The problem is that my laptop is not always set up in the garage, and greasy fingers are not a good thing to have around a white laptop, period.  I could simply buy an internet radio, but I couldn’t stomach the $150-$300 price tag on most players for such a luxury.

So I decided to build one instead.

I started the design process by drafting an outline of desired features, and then breaking them down into wants and needs, while trying to keep the project scope under control.

Requirements:

• Wireless connectivity through existing Wifi network
• Audio output (preferably 44kHz, 16 bit stereo)
• An integrated amplifier and speaker(s)
• Shoutcast/MP3 streaming audio decode
• Several builtin station presets
• A display to indicate the station and currently playing song
• Simple user interface, using standard radio controls (volume, tune, etc)
• 110VAC operation

Optional features:

• Line output (to connect to a receiver/amplifier)
• Web server for configuration/management
• Ability to play files off a USB stick or iTunes server

Definitely won’t be a feature:

• Any kind of over-the-air radio tuner
• Commercials
• Pledge season
• Morning DJ’s
• “Blah, blah, blah.”

Now that we’ve defined the project…  it’s time for a commercial break.  That’s it for part 1 of this series.  Stay tuned for part 2, where I’ll talk about choosing an embedded platform for the design and why Linux is so awesome!

Update: Part two is now available, click here to see it!

Update 2: There is a new Wifi Radio Discussion Forum, hop over there to ask questions about the project or see what other people are working on!  (4/12/09)

Update 3 (6/1/09): I finally added a table of contents to the top of this post to help everyone (including me) navigate the series!