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:

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.

Ubuntu Hams!

Are you into software development, Ubuntu Linux, Amateur Radio? Then you need to know about Ubuntu Hams!

Yet another clock program

So I was grumping to myself that my nice, big, cheap Timex digital clock wasn't doing the best job for the ham station. I had modified it for 24 hour time, but the 10 hours digit could only provide a squiggle and not a proper "2" for 20-23 hours. That, and it is physically in the wrong place (away from my computer screen) and it doesn't show civil (local) time along with UTC. I've searched for a good hardware solution with no luck.

Then I looked at some of the many Linux clock options out there. None of those was exactly right for me. I wanted digits I could read across the room, but that would fit onto my crowded Linux desktop. Anyway, it's always more fun to use software you build yourself. I pulled out my Python and wxWidgets (wxPython) references and set to it. As with designing and building your own hardware, half the reward is the stuff you learn along the way.

So here is the product. If it looks like it might be useful to you, it should run on any recent Linux system with no hassles. I also checked it on Windows XP and Windows 7 for good measure. It works there, but you will have to download Python and wxPython from the web. (Linux systems like Ubuntu provide these as part of their repository system.) MacOS will likely also support this program.

This is free (as in beer) and open source software, distributed under the GNU General Public License. That means you can download it and modify it to your taste, as long as you are willing to make your improved source available to the community if and when you distribute your new version.

In a future version, it might be worth working on desktop space efficiency. You notice that nearly half the window area is wasted on Gnome's frame decorations and menus. That could be reduced by using "shaped" frames at the cost of complicating the code and creating non-standard window behavior.

Why Linux/OSS for Amateur Radio?

How to explain to a non-computer-geek ham what Open Source Software and Linux are all about? OSS and Linux are important to software users the same way a good repair manual and schematics are important to hams. Not every ham knows what to do with schematics, but those who are inclined to open up, understand, repair, and modify their equipment certainly do. Without being able to see what's inside and what connects to what, there is very little you can do. That's exactly why you need to be able to access and work with source code when it comes to software.

These issues will directly affect relatively few hams. Many are "appliance operators" when it comes to software, just as for hardware. For them, a proprietary OS may be a good choice because of its familiarity and the huge choice of available software.

We can admire the dedicated hams who build their own stations and who are on the cutting edge of new hardware technologies. It's the same with software. With software becoming increasingly central to amateur radio (in SDR, digital modes, etc.), competence in coding is getting to be just as important as operating a soldering iron.

While you can roll your own software from scratch, it can be far more efficient (and -- as we like it -- cheaper!) to build your code in the OSS "ecosystem", making use of many libraries and tools that are free for the download. OSS really pays off when you give the fruits of your labor back to the community to spur further development.

These are a few of my open source thoughts!

(a comment on a Linux Journal blog)