Bald Yak 23: It makes noise!

Foundations of Amateur Radio

The shaving of the Yak progresses, it's now making noise! Before you get too excited, the noise is one-way, it's barely distinguishable from hash and it's fragile, so keep that in mind as we dive into the world of .. something.

If you have no idea what I'm talking about, you're in good company, half the time I'm struggling, but today I'm working on a project to bring software defined radio to the masses, well, radio amateurs who haven't dipped their toes yet and I'm calling this effort Bald Yak.

In case you're unfamiliar, the Bald Yak project aims to create a modular, bidirectional and distributed signal processing and control system that leverages GNU Radio. It's called Bald Yak because by the time I'm done, the Yak is likely well and truly shaved.

So, last time we congregated around the campfire I discovered that what I need to build is something that has a collection of things that talk to each other across a network. Seems pretty obvious now that I say it, but it wasn't always that way, remember, I'm inventing this from scratch, or so I tell myself. I will note that the deeper I dig, the more it looks like a lack of documentation, which really comes with no surprise, but I persist, if only to determine that it can be done, that I can do it, and that I understand how it works.

The underlying drive for all this is for me to gain a deep understanding of the whole ecosystem, since I firmly believe that we're well and truly committed to software driven radio.

So, what did I discover? First of all, thank you to all of you who sent messages with your own ideas on how to make two devices talk to each other. I explored at least a dozen of them.

I'll give you some highlights. First cab off the rank is OpenWebRX, radio in a web browser, very popular. I installed it, ran it, configured it, got noise, was able to pick a band across the network and decoded plenty of stuff. Looked like a contender until I discovered two significant issues. One is that it expects a menu entry for each slice of frequency range, with 2.4 MHz being the widest possible for an RTL-SDR dongle, so its 1.7 GHz range would need 708 entries. Someone made a good start, but if you want to tune to something that overlaps two entries, you need another menu entry. Then there's the weird flex that it doesn't decode FM Broadcast in stereo. There's a whole description on why not, but I lost interest. I also tried OpenWebRX+ which adds a bunch of functionality, but not enough to overcome those fundamental problems.

I explored several other web based tools, one looked really promising right until it demanded that I install some random binary off the Internet .. hard pass.

I didn't go down the path of AllStarLink across the room, mainly because I have no desire to start the rounds of configuration, or manage the lack of ability to change frequency, to name two issues.

I did fire up RTL-TCP and managed to connect to it from my Mac using SDR++, it even worked, but boy, the SDR++ user interface is hard work, too many buttons and not enough consistency, like why do I need to set the gain for each mode, and why doesn't it support SoapySDR on MacOS?

RTL-TCP is a tool that essentially puts an RTL-SDR dongle on the network. It's excellent, once you figure out how to make it work inside Docker, has great documentation, talks to GNU Radio, everything you'd want, except that it's only one-way and it only talks to RTL-SDR dongles.

I started comparing SoapySDR to RTL-TCP and then landed back with SoapySDR, since it does the same job, with a bonus that I discovered by accident, since the documentation is .. let's call it .. challenged.

One of the things that people who contacted me missed, probably because it was obvious to me, was the notion that I want to use automatic service discovery, something that has myriad names, ZeroConf, Bonjour, Avahi, mDNS and plenty others. I tried many of them as search terms with GNU Radio and found nothing.

Then I tried the same with SoapySDR and discovered that it s