Bald Yak 11, the goo between hardware and software

Foundations of Amateur Radio

Recently I received a question in relation to the Bald Yak project. If you're not familiar, "The Bald Yak project aims to create a modular, bidirectional and distributed signal processing and control system that leverages GNU Radio."

I know that I've said that several times now and I suspect I'm going to say it several more times before we're done. I was asked about a specific radio and if this project could make it use a frequency that the supplied software didn't cover.

The answer is deceptively simple and if you know me at all, you know what's coming: "It depends". As with many things, what it depends on is not fixed. I'll come back to the question, but I'm making a diversion past a magical place, the local hardware store. You can buy everything you need to build a house with the caveat that some assembly is required. GNU Radio is similar for building a signal processing system, but, wait for it, some assembly is required.

In the context of GNU Radio this means that you'll need to collect all the bits and wire them together, fortunately you're unlikely to need Personal Protective Equipment or access to a First Aid Kit, unless of course the idea of playing with computers gives you palpitations, in which case I'd recommend that you go see your doctor.

One of the less obvious things you'll come across with GNU Radio is how to bring signal processing into the physical realm, in other words, how do you get a signal into your computer, known as a "source", and get it out, called a "sink".

The ability to talk to physical hardware arrives in roughly three different ways. Let's call them, "native", "library", and "abstraction". Native access requires that GNU Radio already knows about the hardware out of the box. Library access requires that the hardware manufacturer has provided software libraries, also known as drivers, allowing GNU Radio to communicate, and finally, abstraction is where a third party has written a library that knows how to talk to hardware from different manufacturers.

The distinction between these is almost arbitrary, for example abstraction might require a driver from a hardware manufacturer. Similarly, because all this software is open source, native can include software from other projects, like the RTL-SDR blocks from Osmocom, Open Source Mobile Communications, and UHD blocks written by Ettus Research, which in turn can be seen as an abstraction.

As I said, some assembly required.

I will point out that this provides a great deal of flexibility, albeit at the cost of complexity, there's still no such thing as a free lunch.

At this point you might shake your head and run away. I get that, it can be daunting. Before you do, consider the scenario where you have a working system and you upgrade your hardware. In a GNU Radio world you'll need to figure out how to configure the new hardware and then all your other stuff will continue to work.

The alternative is upgrading each of your applications to connect to your new radio and in doing so, run the risk of making your old radio obsolete, even if you are collecting them .. let's say for posterity rather than hoarding .. because radio amateurs never hoard anything .. right?

Back to the original question. Can GNU Radio make a radio use frequencies that the software that came with the radio cannot? As I said, "it depends".

First of all, the hardware needs to actually be able to support the frequency. Then someone needs to have written a library to use that frequency, then GNU Radio needs to be able to use that library.

That said, the chances of that happening are much higher than the chance of the hardware manufacturer rolling out this feature within your lifetime. Before you start yelling at me, yes, this is manufacturer dependent, some provide open source tools, many still don't.

There are alternative ways to access different frequencies.

The PlutoSDR is a computer and radio in a box. You can connect to it, change some settings and have it access a whole lot more frequencies. In some ways it's like adding or removing jumpers on a traditional circuit-board.

Another approach is to use an up- or down-converter. Essentially a piece of hardware connected between antenna and radio that translates frequencies to different bands. A down-converter allows you to use the 23cm band on a radio that's only capable of 70cm. Similarly, an up-converter allows your 70cm radio to hear HF signals. If you see a symmetry here, you didn't imagine it. You need both to transmit and receive, sold together in the same box as a transverter.

Just so we're clear, the radio is still using the 70cm band, but the RF coming in and out of the antenna connected to the transverter is on a different band entirely. It's why my Yaesu FT-857d has three menu options, 89, 90 and 91, to adjust the display to show the actual RF frequency. As an aside, you could use this functionality if your radio is off frequency by a known amount.

As I've said before, GNU Radio is a powerful tool. It contains many different moving parts, the system is complex and unwieldy, but with it comes the promise of doing some amazing stuff.

The whole point of the Bald Yak project is to make this all accessible to the wider amateur community, not just computer geeks and software radio nerds.

If you have questions, feel free to drop me a line.

I'm Onno VK6FLAB