Foundations of Amateur Radio

A little while ago I discussed a lovely article by programmer, artist, and game designer "blinry" called "Fifty Things you can do with a Software Defined Radio". This week it occurred to me that I could use their article as a framework to further explore my Bald Yak project. If you're unfamiliar, the Bald Yak project aims to create a modular, bidirectional and distributed signal processing and control system that leverages GNU Radio.

For that to happen, I need a solid understanding of GNU Radio and its ecosystem. While I've been playing with it off and on for a decade or so, I have yet to build anything substantial for the simple reason that there was a puzzle piece missing.

Last week I discovered it .. by accident.

One of the fundamental things I'm attempting to achieve is the creation of a system that doesn't care which radio device you're using. In case you're wondering, I'm doing this because there is a proliferation of device specific software that cannot keep up with the influx of new hardware, doesn't consider the growing use of network connected radios, forced by increased RF noise levels in many communities across the world, not to mention, connecting increasingly expensive computing hardware to lightning rods.

If everything goes to plan, it should be possible to use the project with any radio device. This is easier said than done.

In GNU Radio this complex issue is addressed by having different blocks that represent different devices. You'll find receiver specific source blocks and equivalent sink blocks representing transmitters.

While that's all fine and usable, it means that if I were to publish, say an FM receiver flowgraph, essentially a collection of blocks representing software that implements an FM receiver, I have to decide how I want to deal with the specific device. Do I select an RTL-SDR dongle as the device in my flowgraph and let you figure out how to make it work on the HackRF or the PlutoSDR sitting in your shack, or do I make it completely hardware agnostic, requiring you to wire it all together for your specific situation?

Neither is desirable, or simple.

Added to this is the problem that trying to make this work using a traditional analogue radio would cause more issues, since there isn't a Yaesu FT-857d block, nor is there one for an Icom IC-7400, let alone something from last century.

Someone with some GNU Radio experience might point out that there are source and sink blocks for an audio device, which would allow you to plug one of those radios into a sound card and access the receiver, or transmitter, that way.

While that would work, it requires that the radio is physically connected to a computer that's running GNU Radio. It would also give you all manner of headaches attempting to change frequency in the same way as you could using an RTL-SDR dongle.

There are several ways to get remote radio control working across a network. For example, using 'rigctld' and 'Hamlib', we can change frequency on over 300 analogue radios, but even if you do, you'll discover that getting the audio across the network creates a whole range of new issues, not to mention that GNU Radio doesn't talk to Hamlib compatible radios. This is why many remote radio solutions are implemented as remote desktop sessions to a computer that is physically connected to the radio.

While attempting to solve a completely unrelated challenge last week, I came across 'SoapySDR', described as a vendor and platform neutral SDR support library. Essentially it's a project that allows an application to interact with different devices without needing to support individual radios. This allows an application developer to write their software to support SoapySDR and from then on benefit from its ability to talk to lots of radios in a variety of different ways.

For example, one of the in-built features is called 'SoapyRemote' which allows you to connect to a SoapySDR radio and interact with it across a network. Specifically, you can send and receive, as well as control the radio, essentially bundling together both the audio and control signals.

SoapySDR also includes a tool called 'soapy-audio'. While documentation is sparse, it appears to support Hamlib, which means that you can, at least theoretically, connect a low powered computer, like for example a $5 Raspberry Pi Zero, to your analogue radio and access and control it across the network.

Best part?

It's supported by GNU Radio and many other applications.

I've started creating a repository with the "Fifty Things you can do with a Software Defined Radio", one directory per thing, that will contain the bits needed to run inside GNU Radio and across the network to any SoapySDR compatible hardware.

Now, before you get as excited as I am, there's a few hurdles. I'm not yet sure of the status of soapy-audio, but it looks promising. I have the bits sitting on my computer and I'm working through them. For example, I'm not sure if the current implementation supports transmit. I also have anecdotal evidence that Hamlib support is incomplete, but I don't yet know to what extent. I anticipate some coding in my future. I suspect it will be the equivalent of building a new SoapySDR module, but time will tell.

I can tell you that I'm running an RTL-SDR dongle connected to a low-power computer and I can connect to it across the network with GNU Radio on my workstation and run a proof of concept FM receiver flowgraph. There's no reason for either computer to be in the same room, let alone the same country.

You'll find the project on my VK6FLAB GitHub page. I plan to work my way through the 50 items and discover what I don't know about GNU Radio. Feel free to play along.

I'm Onno VK6FLAB