Raspberry/Beagle/Core Benchmarks

Measured the other day using iPython:

iPython's "timeit" function is hardly the last word in benchmarking, but it can be very useful if you're thinking about Python applications.  Raspberry Pi is very powerful compared to Arduino, say, but very slow compared to modern desktop machines.   No surprises, but I haven't seen relative benchmarks before.

Interesting Little Boards

Shortly, I'll have three little computer boards to understand, play with, and possibly (just possibly) build into some useful projects.

The Arduino Uno is "slow" (16 MHz) ATmega328, has limited RAM and OS support, but is very flexible for interfacing and control applications. Easy C-style programming for simple applications. $27 at Digikey.

The Raspberry Pi is fast (700 MHz ARM) with 256 MB RAM, Fedora Linux, etc., and it's amazingly cheap ($35 US at Allied Electronics, if you can get one!).

As a full-blown Linux system, the Raspberry (and BeagleBoard, below) will require somewhat more software sophistication to get in the game.

The BeagleBoard XM is fastest (800-1000 MHZ ARM) with 512 MB RAM and full set of peripheral connections, running Ubuntu Linux, Android, and others. $149 at DigiKey.

This board has the makings of a DIY netbook computer or tablet, even including a camera interface.

You get extra points if you can program the built-in TMS320 DSP processor.  Usually for audio and video codecs, the DSP development environment is complicated. (To be charitable)

I've mostly been working the the BeagleBoard XM, and I use a lot of its I/O capabilities.  (This is the only board of the three that seems to directly support audio input.)  It provides all the fun and frustration of working in a full Linux environment (including video display, mouse and keyboard if you want), but there are few extra headaches dealing with the embedded aspect.  (E.g., configuring GPIO pins and boot files.)

The rule seems to be: use the simplest board that will support your project without elaborate daughter cards, etc.  In a one-off project it's really easy to use many hours and dollars to shoehorn a project onto a board that doesn't quite fit.  On the other hand, if all you need is blinking lights of one sort or another (even a complex Morse keyer) the Arduino's easy programming system can really save time.

These are all open source boards, making it possible to do your whole project in an open style (software and hardware), a big plus for Amateur Radio DIY work.  There is a huge amount of online information and help forums for all these boards.

The Beagle Barks!

Our Beagleboard-based remote rig control project passed a little milestone today. (See previous posting.)

The BB was set up here in Branford CT on my LAN and connected to a Ten-Tec Orion transceiver.  We accessed it from the ARRL Lab in Newington.

The new audio transport software uses PortAudio and the Speex codec, along with grig and hamlib for rig control, we were able to demonstrate remote receiver operation.

There are many other existing remote control schemes, but our project has a number of features:

• Low-cost ($150 for the BB at Digikey)
• Low power (~5 W)
• Full-fledged Ubuntu Linux software environment
• Lots of I/O and CPU options for future expansion
• All open source (even the Beagleboard itself)

The demonstration was fine, but more integration and packaging are needed before we can share the details.

The fan would not be necessary, except that our board is overheating.  It is going back to the Beagle Hospital for some TLC soon.

Update: It turned out the BB hardware was fine.  I was running an Ubuntu kernel that was somehow configuring the board improperly.  With a new kernel, the board runs very cool, with no fan needed.

We Need a Few Good Codecs

audio waveform image by Jesse-lee Lang
from Fotolia.com via eHow.com

Software audio codecs for ham radio? What's the best? Lots is known about telephone voice codecs, but we have noisy voice with QRM, and we also have CW and various digimodes that we want to transmit from a remote RX via digital links. Each scenario might need a separate codec for optimum results. Give up and send linear/uncompressed? Inquiring minds...

This question comes up as I'm trying to work out a strategy for a remote receiving station using the BeagleBoard XM card running Ubuntu.  Lots of fun, but there are many details to work out, including the audio transmission problem.

Update: Beagles on the mind.  I'm using the BeagleBoard XM, not the BeagleBone, which was just announced.