Previously I’ve talked about a piece of software called SoapyAudio. It’s part of the toolkit called SoapySDR which in turn is part of a whole ecosystem called the Pothos framework, coordinated by Pothosware, founded by Josh Blum. I’m mentioning this for two reasons, first to give credit to Josh and the many contributions he has made to the Software Defined Radio ecosystem and second, to indicate that there’s several moving parts here.

SoapyAudio is a module that connects an audio device, like a microphone or a speaker, more on that in a moment, to a tool called SoapySDR. This allows you to connect to that device, either directly, or over the network, from within any Soapy compatible SDR tool, like Cubic SDR, SDRangel, Quisk and SDR++ to name a few.

Said differently, you can use the SoapyAudio module to pretend that your sound card is a Software Defined Radio, and use the associated SDR tools to use it. While interesting in and of itself, the idea comes into focus if you consider that you could connect your analogue radio to the sound card and now you have actual radio frequencies coming into your card, which you can use as an SDR.

This works because SoapyAudio also includes Hamlib support, which in turn means that you can send commands like: Set the Frequency, or Set the Mode, to your radio using Hamlib, better yet, if you do this within your SDR software, all this happens behind the scenes.

Now, before I dig in too much more, I mentioned a microphone and speaker. When you connect your radio to a computer, the microphone or line-in socket is used to receive audio from the radio, it leaves the radio and enters the computer via the microphone and gives you the ability to receive audio, alternatively, when you connect the computer speaker to the radio, it leaves the computer and enters the radio, to transmit audio. Right now I see no evidence that SoapyAudio supports the ability to transmit, and the ecosystem overview shows the module in a different location than the other radio modules.

It might well transpire that none of this is going to work long-term, but the point of this is to learn how it works and to get an understanding of how data flows back and forth. Ideally, I’d end up with a module that would integrate into GNU Radio using the existing SoapySDR integration, but I’m nowhere near that, and my ongoing computing challenges keep banging me in the face, so small steps.

If you’re not quite sure how this is supposed to work, your radio is connected to your computer using audio in and out, as well as a serial or USB connection. The computer is running SoapyAudio which uses Hamlib to control the radio and uses SoapySDR to send and receive both control and radio signals through a tool called soapy-server, which I think will all run on a cheap Raspberry Pi which is in turn is connected to the network to another more beefy computer running GNU Radio and the SoapySDR module, allowing you to both control the radio over the network as well as receive and transmit.

Well … at least that’s the plan.

In order to bring that grand idea closer to fruition, I’ve just spent the past two days putting together a set of instructions, in the form of a Dockerfile, to attempt to help make that happen. I’ll note upfront that this is a work in progress and there were plenty of trips to the local Yak Shaving compound to sharpen my blades, but I think by now you’ll understand that this is par for the course.

I’m sharing all this with you because in amateur radio and in any complex endeavour, progress is made by making small incremental improvements. We’re up to the 19th, or 20th, if you count the introduction of my Bald Yak series and so far I have only very little tangible assets to show you. I suspect that this is going to be the case for some time to come.

Perhaps my journey should be viewed as a way to pursue the things you’re interested in and document your progress along the way, rather than a journey towards a product that you can install tomorrow morning after you’ve had your morning coffee.

If all that made your head explode, don’t worry, you’re in good company. I embarrassed myself in front of all the HamSci community the other day when I proposed to use a spectrogram to capture and understand Ionosonde data, rather than raw IQ. I still don’t know what I was thinking.

I’m Onno VK6FLAB