Tag Archives: Streaming Radio

Building a Wifi Radio – Part 8, Adding a Tuning Control

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).

Wifi Radio User Interface Schematic
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).

Tuner control on breadboard

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.

Building a Wifi Radio – Part 7, Building an LCD Display

This is the seventh part of an ongoing series about building a low cost, open source streaming internet radio.  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 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:

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):

Wifi Radio LCD Display Schematic

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).

Wifi Radio LCD Display

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.

Wifi Radio LCD Display

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).

Wifi Radio LCD Display

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

Wifi Radio LCD Display

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)

Building a Wifi Radio – Part 6, A Conversation with Mpd

This is the sixth part of an ongoing series about building a low cost, open source streaming internet radio.  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.

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 5, Let’s Make Some Noise!

This is the fifth part of an ongoing series at mightyOhm about building a low cost, open source streaming internet radio.  If you haven’t already, check out the previous parts below for some background about the project.

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.

Building a Wifi Radio – Part 4, Installing OpenWrt

This is the fourth part of an ongoing series about building a low cost, open source streaming internet radio.  If you haven’t already, check out parts one, two, and three for some background about the project.

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:

WL-520GU Restore Button Closeup

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)