True story:

Last May I was at the Dayton Hamvention -- that's the biggest annual gathering for amateur radio operators in North America -- and one afternoon a guy came up to me and said, "I'm from the US Government, and I'm here to help you!"

He was already shaking my hand, so it was pretty awkward when I immediately tried to back away from him. (Remember, this *is* a true story.)

He laughed, and said, "No, really, I'm from FEMA..." and started talking.

The reason I was in Dayton was, first, I'm a ham (AB2KT), and second, I was there along with my friend Bob McGwier (N4HY), both of us as volunteer authors of a body of program code that implements a Software Defined Radio (SDR), to be found at http://dttsp.sourceforge.net. That code is the software heart of a commercial radio which was being featured at the Hamvention.

There are other software radios -- what that means, I'll get to in a second -- but the SDR-1000 is the first radio of its kind in a number of ways, not the least of which is that *all* the software is GPL and freely downloadable, much of which was written by unpaid volunteers like us. It also happens to be a very fine two-way radio indeed, one of the best currently available.

Now, what is Software Defined Radio? The concept is truly simple and thus easily missed. When we say Radio, we're really talking about any sort of wireless communications, one-way or two-way. The Software Defined part simply means that most of the radio functions are carried out not by circuits and components like resistors and transistors, but instead by program code. This is not such a radical idea. Anybody who's lived through the transition from vinyl records to compact discs has first-hand experience with the same kind of replacement of hardware by software. What it means to you is also simple. It's like substituting a computer for a typewriter. You gain a vast range of new capability because what it does, it does through program code, not physical parts. A Software Defined Radio can easily be many different kinds of radio, often several different types at once.

Our project is different from most other SDRs in that the programs are meant to run on a desktop computer. Your computer, plus some additional hardware in front of it. Most other SDRs embed their program code in dedicated devices, usually DSP chips, and closed up operating environments. This defeats much of the advantage of SDRs. (It also suppresses many of the fears that conventional manufacturers harbor about future SDRs.) Our project, however, runs on conventional OSes -- Linux, Windows, soon the BSDs and OSX -- so it's open to the four winds of modification and extension.

Now, back to Dayton. What the FEMA guy was telling me was this.

They, along with the three other major operational agencies under the Department of Homeland Security, rely on shortwave radios for two-way communications in the field. In other words, they use HF -- HF standing for "High Frequency," as opposed to, say, VHF, for "Very High Frequency" -- for many of their tactical communications needs. That's pretty common, since HF, done right, performs better than other bands in rough or mountainous terrain. The military and many relief organizations worldwide use it extensively.

The agencies' tactical communications rely on voice and digital data both: they regularly pass critical time-sensitive email and documents over these channels. It's important to realize that the *outer* protocols for these systems are all MIL/FED standards, adhered to worldwide for the most part. But everything else is proprietary.

All of the DHS operational agencies were worried. Owing to their different legacies and procurement processes, they all had their own distinct communications systems. The systems had all been developed and manufactured by large government contractors, and they were all closed in the tightest possible senses, both hardware and software. The systems were incompatible with one another. The software they used for handling email and documents was buggy and inadequate, and it ran on obsolete versions of Windows. It was virtually impossible to coordinate the user ends of the machines on a LAN. The vendors were completely unresponsive.

What's more, there were technological advances they'd desperately like to exploit, but couldn't, because of vendor lock-in. For example, using a technique called diversity reception, it would be possible to achieve much higher data rates over their HF channels under adverse conditions. But it was questionable whether their various systems could be rigged to use the small selection of components available to them for that purpose.

In short, the operational agencies under DHS understood their needs were not being met by their existing systems, and there was no way to remedy the situation since their systems were closed. There was also no expectation of a fix from the vendors. They realized that what they needed was open systems, now and in the future.

The only system on the horizon that might possibly fill the bill was ours. Because most of the radio is in software, it could be customized and made interoperable across agencies. Because most of the software runs not on dedicated hardware like DSP chips, but on general-purpose desktop computers running Linux, it would be easier to customize and to integrate into more expansive networking facilities off the shelf. And all of the software is GPL.

So, was there something that could be done? Not so much to help us, but to help them?

Let me stress that there is a fair amount of excellent SDR software around. Probably the most conspicuous is the gnuradio project, which is also GPL, as the name would imply. Gnuradio is a first-rate piece of work, and its leaders, Eric Blossom and Matt Ettus, are worthy of the highest respect both for the quality of their work and their tireless devotion to promoting the cause of software radio. However, gnuradio is not really designed to be embodied as-is in a production system. Their goals and ours were considerably different. From the start, we intended to have a compact, portable SDR core that could comfortably be embedded in any number of different hardware environments.

In the event, we agreed to pursue the matter further, and have been doing so. Unfortunately events have a way of overtaking good intentions. I do not know first-hand whether the problems we talked about had a certifiably negative impact on rescue and relief efforts in the Gulf Coast. I do know that the policy of seeking open systems, from hardware down through the most elemental software, has the potential for tremendous improvements in efficiency, when situations like New Orleans arise again.

The general issue of Software Defined Radio, its connection to open systems and protocols, and its potential threat to conventional telecommunications providers and manufacturers, is a large topic, one which deserves more attention from the general community concerned with FOSS development. But the larger picture is a story for another time. For now, it's enough to note that the people on the ground, the ones actually responsible for anticipating and preparing for emergencies, want their systems open, merely to be able to do their jobs.

Frank Brickle describes himself as a longtime Groklaw camp follower. He's a composer with a day job. The day job involves work in the strange area where computers, radios, and cryptology intersect; for a sample of this, a product of close collaboration with mathematician Robert McGwier, see the DttSP project. DttSP is an open source project started by Dr. Frank Brickle and Dr. Robert McGwier of the DTTS Microwave Society to provide code to be used in various DSP projects with an emphasis on Software Defined and Cognitive Radio. You can hear some recent musical work -- an opera for puppets, "The Creation of the World" based on the Townley Mystery Plays -- at the Weill Recital Hall at Carnegie Hall in New York City on December 22.