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.

Software Defined Radio for Every Purpose

"Right now, most people probably couldn't imagine why they'd want software-defined radio hardware in their homes. But people said the same thing about microcomputers in the 1970s."

 Interesting overview of SDR vs the communications world at Ars Technica, featuring USRP and Phi.

Amateur Radio and Innovation in an Age of Austerity

Eben Moglen

Why would I watch an 88 minute YouTube speech by Eben Moglen?  It was John Naughton's hearty recommendation for  his talk given at F2C:Freedom to Connect 2012, Washington DC on May 22.

In a nutshell, Moglen gives an eloquent and provocative story about how what will save us all, economically, is innovation, and innovation in these economic times (austerity all around) will only succeed if we promote free (as in free speech) software and place tools for experimentation in the hands of young people around the world. (Jabbed for their closed nature: Apple, Facebook, etc.)  We need control of our own servers. (and logs!) Powerful stuff that folks in the Linux / GNU camp can all believe in.

So should everybody go spend an hour and a half on this?  Maybe not, but there were several comments at the end of the Q&A session that were related to Amateur Radio.   An unexpected reward for persevering!

Some folks brought up the Maker Movement as an example of a community that is developing along the lines Moglen is describing.   Then (at about 1:17:00), Doc Searls confessed that he had started out in life as a radio amateur, and he called on an audience member, Dwayne Hendricks (WA8DZP), to give a short spiel on Amateur Radio - no, it's not dead, and in fact it provides a great platform for open technology development.

Dwayne relates some of his work, suggesting among other things that hams can develop platforms for non-hams to use.  (This raises some questions for me!)  He also takes an unfortunate dig at the ARRL in these comments to this professional internet/computing audience.  (In another setting, his point about ARRL's stance vis-a-vis innovation deserves discussion.)

For your convenience, here is the full video:

QST & digital QST

The new digital QST edition is now on the web, accessible to ARRL members.  It's a good effort -- at least if you like the new web magazine reading experience.   It is being provided to members as a no-extra-cost addition to the traditional print version.

I hope the pdf version won't go away completely.  That's the format that appears on the annual publications CDROM and on the QST web archives up through 2011. The new format is fine (well, if you like it!) for on-line reading and limited off-line reading, too, but it is a proprietary and DRM-restricted format that probably won't be convenient (if readable at all) 50 years from now.

I was interested in the new QST logos that are cropping up.  There are several variations. One is at the top of this post (I understand it is for the iOS app), and here is another:

 

But I like to look through the QST archives to how QST presented itself in the very earliest days.  The first "logo", from 1915, was this neoclassical marvel:

 

Then, in the late teens and into the twenties, you might have seen this one.  (Color added.)

This is the classical logo for me.  Its block lettering and at least some of the lightning bolts continue into the modern era.  The slogan now says "Amateur Radio" instead of "the Wireless Amateur".  I like this old graphic, but I'm pleased that there is so much continuity in today's version.

Finally, take a look at the first digital QST cover (June, 2012):

Bold and hyperactive design, and presented twice for good measure!

Adventures in Platform Independence

So I have this nice program developed that will allow us to transmit compressed communications audio over an Internet link.  It will be part of a remote Internet receiver that will support W1HQ, the club station at ARRL, Newington, CT.

The program came together fairly easily, using old-fashioned Linux / C programming, together with the Speex and Portaudio libraries.  The sending program runs on an ARM-based Beagleboard card, and the receiving side should run on any Linux box running Ubuntu or your favorite Linux distro.

Along with the audio software, there is an independent rig control function using Python, wxWidgets, and Hamlib.  That should run nicely on Linux, Windows, or what-have-you.

Since our W1HQ crew really needs to keep their Windows station computer, we do need to make the audio receive software run under Windows, along with rig control.  That's where today's lesson begins.

Porting to Windows!

The problem of porting Linux C code to Windows is the subject of a lot of Internet discussion.  It needs to be done frequently, but the process is not simple.  For one thing, the programming tools are rather different.  While the basic principles are the same, all the details are different.  In Windows you generally code within a complex IDE system (Interactive Development Environment).  Managing libraries, dealing with the graphic user interface, and even finding useful "help" files are all a challenge. But the killer, for me, is the unavoidable fact that the underlying operating system just does things differently from Linux.  This shows up in many ways, but my problem specifically was dealing with Internet communications (sockets).

I looked at 3 approaches, before finding a solution that might work for us:

1. Visual C++ and Visual Studio.  This is Microsoft's preferred development system, using the big IDE model.  Fortunately, there is a free "express" version that might work for us.  I could get the Portaudio and Speex libraries to compile, but the socket programming model seems to require serious recoding work.  It would be possible, but it's almost like starting from scratch.  Furthermore, we'd end up with  Windows source code and Linux source code that would have to be maintained in parallel.
2. Cygwin.  Cygwin is software that runs under Windows and provides a Linux command line interface.  Compiling with gcc works in Linux style, so that's good.  However, there is no support for Linux sockets model, so it's no help in the end.
3. MinGW.  MinGW does not provide a full Linux run environment, but it has a number of features that help you compile Linux code to run under Windows.  Compiling the libraries is no problem, but still there is no sockets compatibility.

Not Porting to Windows!

The only solution I've found that won't require investing time in Windows C programming, is to virtualize the problem.  That is, set up a virtual Linux PC inside our Windows box using the free Oracle VirtualBox.  A good modern PC should have enough horsepower for this.  (We'll see about the W1HQ machine!)  Once this is set up, you can run all the code the way it was meant to be run.  The price to be paid is 4-8 GB of disk space and 300-500 MB of RAM.  Since our needs on the Linux side are very modest, we may be able to pare down the memory requirements substantially.

VirtualBox runs the audio software fine under Windows 7 on my home machine.

Update 9/8/2012:  VirtualBox works nicely, but it has a large footprint on any average size computer, so it's probably too much to run at W1HQ without an upgrade.  RAM upgrades are cheap, but it's probably worth another look at Windows coding.  I've simplified the audio transport to use UDP, so there's probably less OS dependency.  We'll see.

ABCs of SDR

The new book is out.  It's a concise low-math (almost zero math) description of what SDR (software defined radio) is all about, for the general ham radio audience.

The short message:  It's the main technology at the core of about every HF radio you can buy these days.  If a radio has "IF DSP" it normally has an SDR back end.  Front ends vary, from minimal ("pure" SDR) to conventional, but the digitization and digital signal processing is mostly the same.

Order from ARRL or your favorite bookseller.

Post your QSL?

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.