Radio's Next Generation: Radii

See how Linux can be used to prototype a sophisticated Internet appliance.
The Operating System

We chose Linux from the start for many reasons. The primary reason is that most distributions are configured with many of the tools we thought we might use, such as mpg123, XMMS, Perl and compilers. It also helped us stay on budget because it's free. Linux makes prototyping easy, because many applications and utilities have retained their command-line interface, allowing their use from scripts, such as the one written for Radii and described below.

Installation and configuration of the OS was straightforward, except for audio support. Because our laptop was so old, most installers were not able to detect the audio hardware. In an unscientific way, we tried many different Linux distributions until we found one that installed easily on our machine. We wound up installing Fedora Core 2 with ALSA (Advanced Linux Sound Architecture) support.

To get sound working for your particular machine, it is most important to identify your sound hardware. In our case, we were able to determine the sound hardware by Googling on the model number for this laptop. Once we determined which sound hardware we had, we were able to locate and install the appropriate ALSA driver for our machine, the ES1879 ESS Audio Driver, from the ALSA Project site. You may need to tweak some of the default ALSA parameters by using the alsamixer utility.

Software Components

With the hardware in place and the OS working, it all came down to finding or creating the required software components. We had simple requirements:

  • An audio stream player.

  • An LCD controller.

  • An application to process operator-induced signals from the serial port and interact with the stream player and LCD.

The Audio Stream Player

We needed a way to play streaming audio that we could control from our application. We initially dismissed XMMS because it is a GUI application, but we later re-examined it and discovered that XMMS can be manipulated from the command line.

The XMMS application provides many handy options that can be used to control an already-running instance of itself. It can be stopped by issuing the -s argument. The playlist can be updated by using -p <playlist> and the playlist argument can be the URL of a stream. Use xmms -h for complete details.

For example, you ask XMMS to switch from its current selection to the AM 1710 Antioch Internet station (old-time radio), by issuing the command:

xmms -p http://66.54.65.226:9022

To stop, use xmms -s and so on.

XMMS completely covered our needs for a player, but it introduced a problem as well. XMMS is a GUI application, so it requires a running X11 server. Rather than tax the available resources on our low-powered laptop, we used the X Virtual Frame Buffer, Xvfb. Xvfb provides a lightweight X11 server that can be used to provide X11 resources to applications that require them, but it does nothing else— it is invisible.

The LCD Controller

We required a CLI application that would display a string on our parallel port LCD. After Googling for this, we found a FOSS application called lcd-info. lcd-info displays system performance information on an HD44780-compatible LCD connected to the system parallel port. It was not quite what we needed, but after studying its source for a few minutes, we found that it could be adapted easily for our purpose.

lcd-info is written in C and compiles into a CLI application. We compile our simpler application with a trivial invocation of GCC:

% gcc -o setlcd setlcd.c iolcd.c

The low-level routines that control the LCD are in iolcd.c, which was borrowed without modification from the lcd-info Project. setlcd.c is the Radii-specific piece that uses functions found in iolcd.c. We called our binary setlcd, and it is run like so:


% setlcd <string to display>

Building the cable to interface the LCD to the parallel port was more time consuming than was adapting lcd-info. It seems that there should be an appropriate off-the-shelf cable, but the pinout on the LCD-side of the cable varies with the manufacturer/model. Rather than finding exactly the right cable/LCD pair, we elected to make our own cable for the LCD we had acquired based on price.

The Radii Application

We built the Radii application using Perl. We chose Perl because it's a language we know well, it has many supporting packages and the update/compile/debug cycle is fast.

The first thing to do is read the input from the PIC development board connected to the serial port. We used the Device::SerialPort package. Here is the beginning of our application, which shows how to initialize the serial port using the Device::SerialPort module:

#!/usr/bin/perl
use Device::SerialPort;

use strict;

# Set up the port.
# All port settings must match the PIC settings.
my $port = new Device::SerialPort("/dev/ttyS0");
$port->baudrate(9600);
$port->parity("none");
$port->databits(8);
$port->stopbits(1);
$port->handshake('none');
$port->write_settings;

Then we needed to handle the following messages sent from the PIC development board based on user input:

Msg Meaning
--- -------
U   The station encoder rotated one unit up
D   The station encoder rotated one unit down
s   The select button was pressed
u   The band encoder rotated one unit up
d   The band encoder rotated one unit down

while ( 1 )
{
  while (! ($code = $port->input))
  {
     select undef, undef, undef, 0.075;
  }
}

The outer while loop keeps the application running until it is killed or dies. The inner while loop attempts to read from the serial port. If there is nothing to read, it sleeps for a short time, 0.075 seconds, and then tries again. This sleep is important to keep the application from spinning too hard and consuming a lot of CPU time. Any messages that arrive while the loop is sleeping accumulate on the port and are available the next time we read.

When an input message is received, the application always should respond by updating the LCD. It sometimes should respond by changing the current station, that is, when the selection button is pressed.

When we get a Station Up (U) or Station Down (D) message, we need to display the next station on the LCD, but we don't want the station to change until the user sends a select signal. This brings us to the LCD message display. As previously noted, we use the setlcd command, but now we call it from the Perl script using the Perl system command:

system("setlcd",
       "Sel:$radiiStn{$curBand}{$choice}{name}");

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Woah, love the idea of this.

Luc's picture

Woah, love the idea of this. There are quite a few stations I like to listen to that are forgien so obviously don't boradcast within a few 1000 miles of where I live. This would be a great way to listen to them around the house. So when does production start?

Great Prototype

Dave's picture

A very interesting article. Your prototype now allows you to show people the concept,something they can get their hands on.

Never OO embedded devices

James's picture

Gentlemen,

On the surface, your homespun project looks impressive. However,
as an embedded expert, your 'project' demonstrates everthing
wrong with many if not most product development efforts.
1. OO programming for embedded devices, is doom to failure
for a variety of reasons: security, maintainance, portabilty
but mostly costs.
2. You project could be implemented on a $5 x86 embedded CPU, avoiding
the pc mobo and the PIC all together. You have to have hardware and
firmware engineers minimize the hardware design before you start
coding.
3. Features that are missing are killers. Traditional AM/FM radio
support must be added, using a chip that costs a few dollars so as
to attract the tradition radio market. Upon using the AM/FM radio
features, as a comfortable commodity, you can then attact them
to Internet radio. NTP and the ability to filter out commercials
over traditional AM/FM broadcast would make your product much more
financially viable.

I could go on and on, but I hope you start to see clearly. The
problem with product development, is it starts with expertise
in hardware and firmware. Embedded linux is fantastic, but, you
never, never, never use a distro espcially pocket PR or Fedora,
as all of that excess baggage wastes critical resoures and leads
to unstable products that are expensive to maintain.

Last, if you are going to build embedded products, LEARN ASSEMBLER
mixed in with ansi C. Leave OO on the destops, where it belongs..

sincerely,
James Horton, BSEE, MSCS PE.

Some do and some talk

K2TQN's picture

I think this is a great project just as it is. It's a great new idea and it has been implemented. I put them in the same league with Bell, Edison, the Wright Brothers, Marconi, DeForest, Mauchly and Eckert, Woz and Jobs, and all the others who forged ahead and were first!

Of course everything can be improved, but they did it, and did it first.

Congratulations.

John Dilks, K2TQN
Personal Computing Pioneer (1976)

I agree completely if this were a final product

Dan Rasmussen's picture

Hi James,

You are universally correct in your assesment of the device as a final product and I am glad your brought it up. One of the points of the article that may not have been made well is, as a prototype, our primary goal was to minimize effort/cost get it done as quickly as possible.

Had we done all of the things you mentioned, it would have taken much much longer than the month or two that it did take (and much of that time was spent soldering). Prototyping is extremely important in the development of any software or system and we needed to have a prototype to have any hope of getting funded and this was it.

Had we received funding for the idea, the device was to include some of your suggestions and many other features not mentioned. Our fist technical task after receiving funding would have been to get it on an embedded system (we were considering Gumstix - http://www.gumstix.com - as the next step but not necessarly the final platform - we still had lots of work to do).

Prototyping is about getting something together that looks complete but doing it as quickly/cheaply/easily as possible. Optimization comes when you have the time/money/resources to do that. Some of that message may have been lost as the article went through its many revisions (We had to get rid of lots of words).

Thanks for the comments.

Dan Rasmussen

still pursuing the Internet Radio project?

Tracy R's picture

Hello .. I came across your article regarding your Internet Radio device while I was doing a search for exactly that type of product. If you (..or any one else out there) ever needs cheap(free!), quality labor designing this product, feel free to contact me any time (trcal_2000@yahoo.com). I have 20+ years in New Product Development for many different products. Let's do it!
Thanks,
Tracy R.

Assembler not always needed

Barton's picture

While I agree with most of your comments I don't think that assembly language is needed very often. I have done many embedded applications and very seldom need to fall back on assembly language. Even when doing DSP projects the C compilers are very capable of creating very optimized code. If one does need a little bit of assembly it can usually be added in line with a C extension like asm {} or the like. With DSP's one does usually need a little bit of start up assembly but it is only a page of code. Assembly language is hard to code, hard to maintain, and hardest still to port to other processors. When ever possible I try to make do with ANSI C. I agree that OO and C++ are usually overkill for an embedded application unless it has an OS to fall back on. An embedded system using one of the embedded Linux products could support OO if the project was real big. Most of the time however the embedded projects I work on don't need any OS and must fit into small spaces. PIC's and DSP projects for hardware control usually don't need the extra overhead of an OS.

Of course that's my opinion, I could be wrong.

next step ?

ben ciceron's picture

wow ! great.
let's find a linux friendly palmtop or mp3 player and we might have winner...

When and where, I'd buy!

Ed O&#039;Neil's picture

You've got a GREAT idea. Broadcast radio reception where I live isn't that great so a device like yours is very atractive. In the mean time, I will continue to use an inexpensive ($15-20) FM transmitter to re-broadcast from my PC to all of the radios in my home. You could intigrate something similar in yours so that the listener could roam the house and hear the same station. If you need a beta tester...

Retro Radio

Frank Daley's picture

There IS a market for something like this. Just look at the huge success that Chrysler had with their retro PT Cruiser:

http://www.chrysler.com/pt_cruiser/

There are even some interesting similarities between the two. Surely there is at least one VC company with some vision!!

Good luck, it would be a winner if it went to production.

Uhhhh. The PT Cruiser is a h

Anonymous's picture

Uhhhh. The PT Cruiser is a hacked Neon. Not in the least bit retro.

Internet radio and Music servers

Anonymous's picture

very interesting project, I was actually looking at some music servers that offer Internet radio, such as the musica from www.olive.us and the sonos from www.sonos.com , if end not purchasing a music server, and this product becomes a reality, I may end up getting one

One thing I didn't understand

Dave's picture

One thing I didn't understand was how the consumer uses it. It looks like they select a genre from the dial, then how does the radio know what stations to list? Does the user have to enter them somehow? Will it work wireless (using a hot spot)? Over-all it seems very cool!

Dave,

Radii

Dan Rasmussen's picture

Hi Dave,

Thanks for the positive comments. Possibly not explained well was that there is a genre dial and a turner dial. Twiddle the genre dial and the LCD will update to the new genre. Once you get the the desired genre, twiddle the station dial and the LCD updates with new selections from the genre.

Dan

XML station identification

Glider's picture

The XML configure script allows for the storing of radio stations.

I don't see where the authors allow for this lsit to be updated except for someone with command line access editting the configuration file. However I could see where it could be set up to populate radio stations from the web using an RSS feed or something similar.

Great article!

-G-

XML station builder script

Dan Rasmussen's picture

Hello -G-,

Yes, you are correct, there is no mention of how this file gets generated. If you take a look at the resources page it will lead you to a page that gives a little bit of an explanation but it goes like this: yes there is a script that will generate the xml config file (well, sort of, it still needs a bit of hand editing). It does this by querying a well known station list keeper (that actually limits your daily queries - based on IP). At the same site (http://www.retro-tronics.com/radii) You will also find a stale xml station file along with all of the associated source. The station gen scrip is not yet posted but everything else is. I need to clean it up a bit first.

Thanks for the positive comments.

Dan

script?

ken Scharf's picture

Well it's now December 27 and you STILL havn't put the station list generater scrpit up on your web site.

Also I have an optical encoder switch that has a push button switch built in. I can see rewriting the interface so the single dial could switch between 'bands' and 'stations' with the push button selecting which menu and making the selection. (quick push changes menus, long push makes selection.)

Well written and inspiring. A

jh's picture

Well written and inspiring. Almost makes me regret having become a software-only geek :-)

Great Job!!

Richard Kut's picture

Wow! Great job! Any plans on selling some of these to guys like me?

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState