Beagleboard + Icom PCR-100
UPDATE: I no longer use the PCR-100 and have found a more sensible and A LOT cheaper approach to hobbyist reception that is good enough: the RTL2832 usb dongle!
The Icom PCR-100 (or PCR-1000, which I don't have but will work just as well with this setup) is a computer controlled radio receiver that will receive radio signals in the bands between 0-1300MHz and will demodulate AM/NFM/WFM. A very nice toy, radio wise. And all computer controllable!
The Beagleboard is an inexpensive development board, packed with an ARM Cortex-A8 running at 600MHz, 256MB RAM and 256MB NAND flash, along with a DSP and video decoder blocks and expansion headers and audio i/o as well as DVI-D (and S-video) video. And it only costs about $149 plus shipping. And of course it runs linux!
The last few years I've had the PCR-100 hooked up to a standard PC, running a radio server that would listen to requests from a web form to tune the PCR-100 to a specific frequency, adjust squelch and so on. It also streamed the audio from the PCR-100 to an Icecast server, allowing me to tune the radio and listen to what it picked up from wherever I was, without actually being there. And all that with only 2 seconds latency!
Sadly, a few months ago that old PC gave up. The site at which the radio is stationed and my current residence is not the same place, and I still wanted to use the PCR-100 but was unable to set it up at my home. And another PC was just not that much fun. They're expensive, noisy and draw a lot of power. What's the alternative?
The Beagleboard is small, it draws about 1.5W of power and it has a certain coolness factor to it. I had experimented with one (a rev C2 board, for those interested) for a while, and at work I was working with similar platforms. I was in need of something to run the radio at my remote radio site, and decided to try and make the Beagleboard work with the PCR-100. So I got to it!
First step out, decide what to run on the board. I like embedded linux, and the most active project with regards to the Beagleboard is the Ångström Distribution. So I went with that, downloaded openembedded and configured it to build Ångström. Transferred the rootfs to the SD card (the kernel was there allready, after some earlier experimentation) It booted snuggly, as expected.
The next step was to get the beagleboard to communicate with the PCR-100. It's a standard RS-232 serial interface, and it shouldn't be too difficult to get it up and running. The Beagle has one RS-232 header for debug on the board, and if needed another UART is available on the expansion header (though a level shifter and something like a MAX232 is needed). The board also has USB, so if everything else would fail, then I would only have to plug that in.
Right..
First, I decided that I needed the RS-232 header for debug, and I didn't want to start soldering with level shifters and whatnot without knowing that it actually worked. So, I plugged in a USB to RS-232 adaptor and..watched it die.
It appears that the beagleboard's USB is a tad bit unstable.. After a few hours of debugging and googling I decided to drop USB, and decided to try the RS-232 header. I knew that the CTS/RTS pins needed for flow control weren't connected, but after some trial and error with timings and delays in the server code it worked! For a whole 20s, then it just..died. I found the explaination after some more googling. The PCR-100 will monitor the DTR and RTS pins and if they go low (or ARE low) the device will power down after 20s. Since the pins needed are not connected on the beagle rs232-header this required some thinking.. and soldering!
So, I took the lazy approach. Since the PCR-100 would enable the DSR pin (pin 6) when ready for data, I did just solder pin 6 to pin 4 (DTR) and pin 7 (RTS). Problem solved. At least as far as the radio-going-to-sleep-problem was concerned.
Picture showing my handy soldering..
So, the radio was working. Now network and streaming was needed! After some
more debugging with regards to USB, I found that the latest Ångström kernel
had the necessary patches needed to get the ECHI to work. I bought a cheap
USB to Ethernet adapter that was linux compatible (Asix chipset) and configured
Ångström accordingly. After some fighting with /etc/defaults/usb*
the beagle configured itself nicely and was communicating with the rest of the
world without a hitch!
Now, for streaming.. I used darkice before to stream the audio from the pcr to the icecast server, so I decided to try it on the beagle too. I found that there didn't exist any openembedded build recipe for darkice, so I had to make one. It's a trivial exercise to make one, but I haven't commited the package to the openembedded repository due to lack of time and iterest, but if anyone is interested drop an e-mail and I'll send you the relevant files.
Once darkice was in place, the only thing needed was to configure it and set up the mixer levels in ALSA with alsamixer (remember to include it when building the distribution!) and it worked! CPU load is about 50% with 32kbit mp3, mono with LAME quality set to 0.6. Good enough for what I capture.
The setup as it is right now is one PCR-100 with a nice big discone antenna, connected to the beagleboard via the RS-232 debug header (IDC10 to DSUB-9 cable and then a standard RS-232 cable). Audio connected from the speaker out to the audio in on the beagleboard. Ethernet connected via a USB hub (not strictly needed, but convenient). Power provided either from a USB->5V cable connected to the USB hub, or from an external 5V power supply.
I would like to share the stream (the end result, if you will) with the world, but due to limited bandwitdth (and swedish law..) I can't share the audio stream, or the tuning capability with you. The code to communicate with the PCR-100 was in parts borrowed from the QtPCR project, but I can't seem to find the homepage of that project anymore. Future plans includes rewriting the radio server to use something like icomlib or write my own implementation (because the QT dependency is NOT that nice, no matter how much Nokia will tell me it is) and I don't like C++). And I'm drawn towards making the DSP encode the MP3 bits, thus offloading the ARM core, leaving it free to do other tasks. I'll hopefully update this page if I do something interesting.
Henrik Persson <root@fulhack.info>
2009-12-02