Today, it seems to be working.  I can talk to the AVRISP with avrdude and program devices.  Cool!

I’m not sure what I changed.  I’m using Virtualbox 3.2.10 r66523, running on a Windows 7 64-bit host.  The VM/client OS is Ubuntu 10.10.  I created a USB filter for the AVRISP in the Virtual Machine settings; it doesn’t seem to work without it.  That might be what I was missing before.

To avoid having to run avrdude with root priveledges, I created the file /etc/udev/rules.d/10-avrisp2.rules with the contents:

SUBSYSTEM=="usb", SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2104", GROUP="adm", MODE="0666"

Pretty simple.

Oh, I should add that there is no guarantee other combinations of host/client OS will work.   If you’re getting different results, leave a comment.

Mitch Altman and I are in the process of writing a book about Making Cool Things with Microcontrollers (for people who know nothing.)

The book features several DIY projects that use AVR microcontrollers.  We’re aiming to teach absolute beginners how to solder, basic electronics, and the process of turning a cool idea into reality by using microcontrollers.

I wrote these instructions about setting up a working avr-gcc environment in Windows, Mac OS X, or Linux.  Mitch and I felt that they could use some beta testing in the real world before bring included in the book, so we decided to make them available here.  We also felt that they might help some people get started with AVRs before the book is available.

We want to make the process of writing and compiling code for the AVR simple and accessible, so we’re not using any fancy IDEs (eg. no AVR Studio).  We also wanted to use the same software on all three operating systems, so Windows-only tools were out.  Instead, we’re using avr-gcc, the compiler behind WinAVR, CrossPack, and Arduino.

I would appreciate any feedback on these instructions.

Here they are:

Windows

Mac OS X

Linux

Update: I totally rewrote this post after getting feedback that I didn’t properly identify my target audience and explain why I chose avr-gcc.  Sorry!

After installing a new D-Link Gigabit Ethernet Switch, I wanted to check the throughput to see if I was actually getting gigabit speeds – particularly because the house is wired with CAT-5e cable (and not the recommended CAT-6).

There are many ways to measure network throughput.  In the past I have usually copied a file across the network and used a stopwatch to get a relative sense of speed.  However, due to file sharing protocol overhead I always got disappointing results and never knew maximum capability of my network.

This time, based on the advice of a more network-savvy friend, I decided to use a command-line tool called iperf.

iperf is a command-line tool to measure network performance.  It is very powerful, but also easy to use for simple tests.  For a more complete overview of what iperf is and what it can be used for, check out this tutorial or the iperf page on Wikipedia.  iperf has a lot of options, and I won’t cover the majority of them here.  For more usage information, consult the iperf manual.

If you run Debian or Ubuntu (Linux), iperf can be installed by executing

sudo apt-get install iperf

I did these tests with OS X on the Mac since both of my Macs have gigabit ethernet ports and my older PCs don’t.  A package for iperf is conveniently available from Macports.  It can be installed via the graphical package manager Porticus or opening a Terminal window and typing

sudo port install iperf

In my case, all I wanted was a quick test of TCP/IP network performance.  This is easy to do, but it requires two computers, a client and a server, both connected to the network under test.  Ideally, there should be no other network traffic during the test, as this will affect the results.

On the first computer, launch the iperf server by executing

iperf -s

You should see something like this:

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------

On the 2nd computer (the client), open a Terminal window and run

iperf -c <IP address or hostname of server> -i 1

Within a few seconds, you should start to see reports coming in on both the client and server terminal windows:

------------------------------------------------------------
Client connecting to mini.home, TCP port 5001
TCP window size:   129 KByte (default)
------------------------------------------------------------
[  3] local 192.168.24.135 port 65142 connected with 192.168.24.77 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec    110 MBytes    924 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  1.0- 2.0 sec    101 MBytes    850 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  2.0- 3.0 sec    109 MBytes    914 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  3.0- 4.0 sec    100 MBytes    841 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  4.0- 5.0 sec    111 MBytes    927 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  5.0- 6.0 sec    102 MBytes    853 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  6.0- 7.0 sec    110 MBytes    923 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  7.0- 8.0 sec    102 MBytes    858 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  8.0- 9.0 sec  79.4 MBytes    666 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  9.0-10.0 sec  93.6 MBytes    785 Mbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1018 MBytes    854 Mbits/sec

The last report (for the interval 0.0-10.0 sec) is the average throughput for the entire test.  I’m more than happy with 854 Mbits (927 Mbits/sec peak!) given my fairly long runs of CAT-5e cable and other machines using the network.   Contrast this with my results over 802.11g wireless:

[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  24.9 MBytes  20.9 Mbits/sec

As installed by the avrdude package on Ubuntu, avrdude needs root priveledges to work properly with the Adafruit USBTinyISP AVR programmer.  This gets annoying pretty fast because to program an AVR you need to run avrdude (or make) with sudo every time or log in as root (not recommended).  Without sudo, avrdude will return an error:

avrdude: error: usbtiny_transmit: error sending control message: Operation not permitted

avrdude: initialization failed, rc=-1

 Double check connections and try again, or use -F to override

 this check.

avrdude: error: usbtiny_transmit: error sending control message: Operation not permitted
avrdude done.  Thank you.

LadyAda points out in her avrdude tutorial that there is a way around this behavior by setting up some udev rules for the USBTinyISP.  However, I found that the rules given in her tutorial did not work with my stock Ubuntu 9.10 installation.  The problem arises because the user Ubuntu creates on install is not part of the “users” group.

The fix:

Create a file called 10-usbtinyisp.rules in directory /etc/udev/rules.d

 SUBSYSTEM=="usb", SYSFS{idVendor}=="1781", SYSFS{idProduct}=="0c9f", GROUP="adm", MODE="0666"

Then execute:

 sudo restart udev

That’s it.  Unplug and replug in the USB cable to your USBTinyISP programmer.  Now avrdude should be able to access the USBTinyISP without root privileges.

If your account is part of another group, just change the GROUP= flag to that group instead.  New users in Ubuntu are assigned to a group named after their username by default, so that is another option (ie. GROUP=”yourusername”).  Interestingly, new users are not assigned to the “users” group, for reasons that escape me (and no doubt some of our more Linux-savvy readers can enlighten us about).

If you want to see the radio in person, stop by Expo Hall Booth 166 at the Maker Faire in San Mateo, CA this weekend.  I’ll be there to demonstrate the radio and answer questions!

This is the ninth 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 eight, we added a tuning control for the radio.  Now we can change to any of ten preset stations on the radio by adjusting the position of a potentiometer connected to our AVR microcontroller.   The LCD display we built in part seven lets us know what stream we’re listening to and the artist and title of the current song.  This project is coming together very nicely!

Before we put the final touches on this project in part ten, there are a few miscellaneous chores to take care of:

Fixing /etc/config/wireless:

Last time, we tweaked /etc/config/network to assign a static IP address to the LAN (ethernet) ports of the router.  This allowed us to directly connect a computer to the router via an ethernet cable and get a shell prompt, regardless of the state of the serial console or the wireless connection of the router.  Unfortunately, I made an omission in the setup instructions which may prevent this from working correctly.

To fix this, modify /etc/config/wireless as follows (changes are in bold, use your wireless network information in place of my example):

config wifi-device  wl0
    option type     broadcom
    option channel  3

    # REMOVE THIS LINE TO ENABLE WIFI:
    # option disabled 1

config wifi-iface
    option device   wl0
    option network  wan
    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

The only change is to set “option network” to “wan” instead of “lan”.  This minor change tells the router to separate the wireless interface of the router from the LAN/ethernet interface and allows the router to acquire two separate IP addresses, one for each interface.

Launching mpd automatically at startup:

Manually launching mpd every time the router boots is a drag.  You can automate this by creating a symbolic link to /etc/init.d/mpd from the /etc/rc.d directory, as follows:

root@OpenWrt:~# ln -s /etc/init.d/mpd /etc/rc.d/S93mpd

Now every time the router boots, mpd will be started automatically as part of the boot process.  (That was easy!)

Boot script for the user interface:

Assuming we want a dedicated internet radio that doesn’t require user intervention to operate, the scripts for the LCD display and tuning control should also be launched at startup.  This will ensure that upon applying power, the radio will boot into a state where a stream is playing and the user interface is active.

First, we need to create a simple boot script.  Create the file /etc/init.d/AVR with the following contents:

#!/bin/sh /etc/rc.common
# Copyright (C) 2008 OpenWrt.org

START=99
start() {
sleep 5    # make sure boot process is done, no more console messages
/root/interface.sh
}

To launch the script at boot, create a symbolic link as follows:

root@OpenWrt:~# ln -s /etc/init.d/AVR /etc/rc.d/S99AVR

Every time the router boots, the user interface will automatically start, mpd will start playing the selected stream based on the tuner position, and the AVR microcontroller (assuming it is still connected to the serial port) will update the LCD display and watch the potentiometer for any changes in position.

Tweaking the firewall configuration:

This is actually optional, but it can be pretty useful while hacking on the router.  As presently configured, the router blocks incoming requests on the WAN, which now includes the wireless interface.  This prevents us from using ssh or telnet to log into the router over our wireless network.  While we can still get a shell by connecting an ethernet cable to one of the LAN ports on the router, it is often more convenient to access the router across your wireless network.

The file /etc/config/firewall controls the firewall settings.  We’ll be modifying this file.

Open the file in vi and scroll down to this section:

config zone
    option name        wan
    option input    REJECT
    option output    ACCEPT
    option forward    REJECT
    option masq        1

Edit the “option input” line so that it looks like this:

config zone
    option name        wan
    option input    ACCEPT
    option output    ACCEPT
    option forward    REJECT
    option masq        1

Now restart the firewall (or just reboot the router):

root@OpenWrt:~# /etc/init.d/firewall restart

You should now be able to ssh or telnet into the router over your wireless network.

Enable SSH:

By the way, if you want to access the router with ssh instead of telnet, just set a root password.  The telnet daemon will be disabled (for security reasons) and replaced with an SSH daemon instead.  You can do this with the “passwd” command.

root@OpenWrt:~# passwd
Changing password for root
New password: *****
Retype password: *****
Password for root changed by root
root@OpenWrt:~#

Log out of your telnet session and use ssh to log back in with your favorite ssh client (don’t forget to tell the client to use the username “root”).

Stay tuned!

That’s it for now.  Stay tuned for the final part in this series, part ten, in which I’ll talk about what it took to turn this Sketchup model into a real wooden case for the radio!

Update: Part ten (the final part in the series) is now online.

The BYOES classes were primarily focused on the Beagle Board, an ARM Cortex-A8 based single board computer developed by engineers at Texas Instruments.

When I picked up my conference registration on-site, I also received a Beagle Board dev kit which included a 2GB SD card, a Class 1 Bluetooth USB adapter, and a tiny box containing a brand new Rev C2 Beagle Board.  This was pretty exciting, given that the C2 boards haven’t even hit Digikey yet, making me one of a select group to have a C2 board!

Here’s a photo of the kit as provided by ESC.

The classroom was full of LCD monitors, keyboards, mice, and USB hubs – but no computers.  This is where the Beagle Board comes in.

The first step was to plug the peripherals into the board, as shown below.  The HDMI interface for the LCD is at the upper right of the board, while the SD card and USB host port is on the left.  The bottom of the board has a DC power jack and the USB OTG port which we used later.  The whole board is actually powered via USB – the other end of the cable with the DC plug goes into the USB hub, and the hub powers everything.  Pretty cool.

The classes were fantastic.  I saw lots of really impressive demos, including some really neat 3D graphics using the onboard OMAP35x SGX 2D/3D graphics accelerator.

I particularly enjoyed the Monday morning class, led by Beagle Board designers Jason Kridner and Gerald Coley.  Jason gave an overview of both the impressive feature list of the board and the large development community behind beagleboard.org.  Gerald talked about the hardware development process, including some of the difficulties with the OMAP3 processor, which uses PoP technology.  The system memory chip is soldered to pads on top of the CPU, which is then soldered to the PCB.  Not surprisingly, this process took some optimization to get right.

Some observations:

• While the Beagle Board was developed by engineers at Texas Instruments, TI does not officially support the board, which is more of a technology demonstration.  Instead, people using the board can go to the beagleboard.org community for support, where there is a vibrant community of volunteer developers.
• The philosophy behind the hardware is “Bring your own”.  The board contains a minimum set of peripherals and you attach what you want.  Apparently most eval boards contain a lot of features people never use (cameras, wireless interfaces, etc.) and tend to force desigers into using only the “supported devices”.
• The hardware is open source.  You can download gerbers, Allegro files, schematics, etc from their site.  (Sadly, no Eagle files, although the 6 layer PCB wouldn’t be supported by the cheap/free versions of the Eagle anyway.)    You can develop products based on the Eagle board and just stick copies of the design into your own PCB, or develop your own design.
• The Beagle Board is not recommended/supported for use in production hardware.  It’s for evaluation only.  If you develop a product, you’re supposed to handle your own PCB builds, etc.  The good news is, you can call up their contract manufacturer (CircuitCo) directly and get a batch of Beagle Boards made if you want to use the hardware as-is.
• The communiy is very good about having mutliple avenues for discussion and collaboration.  They are leveraging lots of old and new technologies: IRC, a wiki, a mailing list, delicio.us social bookmarking, RSS, etc etc etc.  All of these are accessible from beagleboard.org.

You can download the class slides and an SD card image at http://beagleboard.org/esc

Lastly, the Beagle Board runs Android.  It also runs Linux distros like Angstrom and MontaVista, among others!

It doesn’t matter if it was inspired by my project or developed independently – I’d love to hear from you!

I’m putting together a talk for NOTACON and I’d like to feature as many projects as I can to spread the word about how powerful, flexible, and affordable these routers are, especially when coupled with a Linux package (DD-WRT, Tomato, OpenWrt, etc.) and USB devices.

If you’d like to have your project included in the talk, leave a comment or contact me directly.

www.flickr.com More in Asus Wireless Router Hacks pool

Flickr: Asus Wireless Router Hacks

Hacking the Asus WL-520GU Wireless Router:

In the last part of this series, I selected the Asus WL-520GU wireless router as a suitable embedded platform for my Wifi Radio project.  I have since posted some detailed specs on this impressive low-cost router, revealing it’s powerful Broadcom BCM5354 core, 4MB flash, and 16MB SRAM.  Granted, there are many more powerful routers out there that have USB support, will run Linux in various forms, and have built-in WiFi.  However, the WL-520GU does almost everything we need to build a streaming internet radio and costs under $50 (I have seen them for as little as $26 after rebate), which is very impressive indeed.

To convert this router into a powerful embedded system, we need to make a couple modifications.  First, we need to throw out the stock firmware. It turns out that this router, like many others, runs Linux from the factory.  However, because it was designed to be a wireless router and not much else, the stock firmware doesn’t include a very wide set of features (and certainly was not intended to be accessed by the customer).  Thankfully, there are several open source Linux distributions available that support this router, including my favorite, OpenWrt.  In addition, Asus has made it fairly straightforward replace the stock firmware with our own custom Linux build which can include all the programs, drivers, and utilities we can cram into 4MB of flash.

Warning:

Before we start hacking the router, there are a couple things I should mention:

• From this point onward, your warranty is toast. Don’t even THINK about trying to send a modified router back to Asus for warranty service.  In the end it hurts people like us, because Asus will try to make it harder for people to perform the same modifications in future products.
• You may inadvertently destroy your router. If you are not comfortable with the fact that a misstep during the reflash or a stray solder bridge could ruin your hardware, stop now.  Sorry.  If you really take a wrong turn, you could damage your PC as well, but this is extremely unlikely.  If you do somehow damage your router or PC doing these modifications, I assume no responsibility for any damages!

This tutorial assumes that you have already established the router is basically working by assembling it, plugging it in and checking for it’s wireless signal and internal webserver.  The user manual does a good job of leading you through this process, but don’t use the supplied CD – follow the advanced/manual instructions instead.

Accessing the internal serial port:

The OpenWrt install will be easier if we can find a way to access the internal serial port of the router.  The built-in serial port gives us a way to view Linux boot and status messages and get shell access as well.  The serial port will also come in handy later when we want to add a user interface to the radio.

You will need:

• A desktop or laptop computer with an open USB and Ethernet port.
  
• Your shiny new ASUS WL-520GU wireless router (R1.02)
• A strip of breakaway 0.1″ male header
• A FTDI-232-3V3 USB to serial adapter cable ($20 @ Adafruit) or some other means of connecting a 3.3V level serial port to your PC
• A small scrap of perfboard and a strip of female 0.1″ header (not strictly necessary, see below)

-and-

• A basic electronics workbench with ample light, a temperature controlled soldering iron, a solder sucker, solderbraid, wirecutters, and pliers.  Servo Magazine recently held a contest to see who could build the best electronics workbench for under $100, the results should be helpful for anyone just starting out.  If you’re uncomfortable soldering, find someone else to help you with this part at your local hackerspace.

Step 1 – Open the router

Remove the power cord and antenna (the base unscrews).  Flip the router over and look at the bottom.  You should see something like this:

Note there are four screws that hold the router together, two are hidden underneath the rubber feet.  The feet are stuck on really well, but persistent prying with a fingernail will get them off eventually.  Remove the four screws and set them aside.  The top cover should come off without too much trouble.

Now that the router is open, you should see something like this:

Step 2 – Add a serial port header

Remove the PCB from the plastic enclosure by gently pulling it up and towards you (ethernet ports facing away).

Just to the left of the ASUS logo in the photo below, you will see a 4-pin header that I have installed to access the internal serial port of the router, the router ships without this header.  Instead, you will see four solder filled vias in a row in the same spot.

You will need to use your soldering iron and a solder sucker to remove most of the solder so that the header can be installed.  A higher power soldering iron will help with removing solder from the first via on the left (mine is a 60W Weller WTCPT).  This via connects to a ground plane which sucks heat away from the iron and makes the job more difficult.  Be patient and persistent and you should be able to wick any remaining solder away with some soldering braid if necessary.

Break a 4-pin chunk of male header off the strip.  Pop the header into the board and carefully solder it into place.  If it doesn’t fit, chances are there is still some solder left in the vias.  You should end up with something like this:

The pin functions are, from left to right in the photo:

GND   TX   RX   3.3V

Step 3 – Connect your PC

The FTDI-232-3V3 USB to serial adapter cable provides a handy way to add a 3.3V TTL level serial port to a PC or laptop.  The cable has a flat connector on the serial end that can plug directly onto 0.1″ male headers like the one we are using on the router.  Unfortunately, the pinout of the FTDI cable (given in the datasheet) does not match that of the router.  To resolve this, you have two options:

• Use a tiny screwdriver to pull out the pins from the housing at the cable and rearrange them.  Do not connect anything to the 3.3V pin on the router, and swap the TX/RX so that the TX on the router feeds RX on the cable, and vice-versa.  Don’t forget to connect the grounds!  The downside of this is that now you can’t use the FTDI cable for things like the Boarduino without swapping the pins back.

-or-

• Fabricate an adapter board using a small piece of perfboard and some headers, shown below (click for a larger version):

Here is a schematic of the adapter board:

Shown here are the cable and adapter installed on the router.  Make sure the ground side of the cable is connected to the pin on the header that is opposite from the fat angled trace (the 3.3V line).  Ground is the black wire, on my adapter I marked this with a black dot so I won’t forget and plug it in backwards.

Step 4 – Test the connection

Plug the cable into your PC (you may need some drivers) and open your favorite terminal program.  (I like Zterm for the Mac or Hyperterminal on the PC.)   Using the terminal program, open the serial port corresponding to the FTDI cable (something like usbserial-FTDQ23LB on the Mac or COM3 on the PC, but your setup may be different.)   Set the port options to 115200 baud, 8N1.

Connect the antenna and power supply to the router and plug it in.  You should see something like this appear in your terminal program:

Decompressing..........done

CFE version 1.0.37 for BCM947XX (32bit,SP,LE)

Build Date: Thu Mar  6 10:05:04 CST 2008 (root@localhost.localdomain)

Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.

Initializing Arena

Initializing Devices.

Boot partition size = 131072(0x20000)

et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 4.130.31.0

Total memory: 16384 KBytes

CPU type 0x29029: 240MHz
...

If you do, congratulations, your serial port is working!

The lines that scroll by are boot messages from the Linux kernel of the stock firmware on the router.  These messages give you a lot of information about the hardware in addition to information about the operating system and software drivers.  Here is a complete transcript of the boot log from my router.  If you wait a couple minutes for the router to finish booting and hit enter, you should see a command prompt.  From here you can explore and play around with the stock firmware, there is really not much to do here until we reflash the router with OpenWrt.

That’s it for part three.  In part four, I’ll talk about installing OpenWrt and connecting the router to your wireless network.

Update: Part four 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)

I am using this tiny USB-audio adapter as part of my Wifi Radio project.  It’s a ridiculously cheap $8 at Newegg.com and contains a C-Media CM119 chip targeted at VoIP applications.  I have no idea why they chose to use a VoIP chip for this application because it contains a lot of bells and whistles that are not being used in this device, such as support for a matrix keypad!

Unfortunately, I have not been able to locate a datasheet for the CM119 so for now I will be using it only for it’s intended application – adding an audio output to a wireless router with USB.  Come to think of it, that is probably not it’s intended application, but it’s close enough.  Hooray for embedded Linux!

In my previous post about the Wifi Radio project I’m working on, I concluded that the Asus WL-520GU wireless router was the perfect choice for an embedded wireless platform, thanks to its builtin 802.11g WiFi, Linux support, and extremely low cost. (In fact, the price after rebate has dropped since my last post – now would probably be a good time to buy one if you’re thinking about hacking it into something eventually).

Here are the specs on this router, based on an inspection of the hardware and the stock firmware Linux kernel boot log (the complete log is here).

• CPU: Broadcom BCM5354KFBG SoC @ 200MHz (240MHz?)
  • Builtin 802.11g wireless transceiver
  • Builtin 10/100 ethernet switch
  • Core supports 2 serial ports, only 1 is available on the PCB (installed 4 pin header shown in photo above)
• RAM: 16MB Samsung K4S281632I SRAM
• Flash: 4MB MX 29LV320CB
• One USB 1.1 port (USB 2.0 support is broken according to the folks at OpenWRT)
• SiGe Semiconductor 2528L discrete RF Power Amplifier IC
• One external TX/RX whip antenna (RPSMA), internal diversity RX antenna on PCB
• Internal 3.3V DC-DC converter
• PCB Dimensions: 4.0″ x 5.6″
• Supply: 5V @ <2A

Here are some images of the PCB, click for a larger version.

Here’s a closeup of the Broadcom BCM5354 SoC – the brains of the router.  It is surrounded by a 4MB MX flash chip above and a Samsung 4MB SRAM chip on the right.

Overall this is a great little router and an even better platform to build an embedded Linux system, provided you don’t need USB 2.0 support.  If you do, look at the WL-500gP v2 instead, it has two working USB 2.0 ports (in addition to much more flash storage and RAM).

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!

Earlier this year I replaced my desktop PC, a Dell Dimension 4700, with a Mac Mini as part of my effort go 100% Mac for my home computing.  OS X is a terrific platform for the desktop power user because it looks great, feels great, is well supported by open source projects.  It also runs on a variant of Unix giving you full shell access and lots of other great stuff.

Since then, the Dell has been sitting by my desk, waiting for a good use.  I already have a Linkstation Live that I use for a low power home server (print server, mt-daapd, subversion, samba, etc.) so I didn’t have an immediate need for another PC around the house.

Last week I started playing with OpenWRT as part of a neat new project that will be an upcoming feature on this blog.  I suddenly needed a Linux environment and some extra computing power to help build custom OpenWRT images.  Debian to the rescue!

Before anyone says anything, I don’t really have anything against the incredibly popular desktop Linux distro Ubuntu.  The real reason I choose Debian is that I know Debian, and Debian just works.  My new server runs headless and I use ssh to login and compile from my Mac, so the advanced graphical features of Ubuntu would be lost on me.

Installing Debian is a breeze.  Within 30 minutes of burning the Debian quick start CD, I was up and running.  After installing a few addon packages, I was compiling OpenWRT images.

Instant development server.  Awesome.