Bald Yak, week 2

During the week an interesting question was put to me. Am I going to make this into a GNU Radio tutorial? In short, no and yes. At this point I know enough about what I’m attempting, to recognise that I’ll be deep diving into the bowels of GNU Radio and the inevitable idiosyncrasies that a large project like that has and as a result I’ll likely have to explain the context in which something broke, which will no doubt result in me having to walk you through the details.

So, this means that there will be trips into how this thing works, but I’m not currently planning a GNU Radio course, not only because that’s not what Bald Yak is about, but because I like to know what I’m talking about, even if the peanut gallery might at this point call out: “Why start now?” – yes, from time to time, what I’m talking about here is based on something I’m still in the process of learning and obviously I make mistakes.

Now, if you haven’t been playing along, let me state the purpose of why I’m here.

“The Bald Yak project aims to create a modular, bidirectional and distributed signal processing and control system that leverages GNU Radio.”

In the pursuit of happiness, I’ve been resisting making a table with the various communication protocols in use to extract data and control the data stream within the software defined radio world. I’ve been avoiding this because I don’t feel like I know the landscape well enough. Of course, making the table will create a better understanding, chicken and egg.

I do have a handle on what functionality is required. So, in the spirit of writing it down or it didn’t happen, here’s what I know.

This thing needs to be bi-directional because it needs to be able to receive and transmit. I don’t yet know if this functionality needs to be symmetric. What I mean by that is that I don’t know if both directions need the same functionality.

Consider for example a distributed receiver decoder.

Imagine a device that spits out bytes at a particular rate. These bytes represent received radio signal. How and what they are specifically I’ll leave alone for the moment. This information needs to be read and processed. The processing could happen on the same computer, or it could be a separate computer connected to the local network, or a remote network across the internet. There could be more than one computer doing the work.

We could choose to send the whole stream of bytes, our radio signal, to every computer. This is how YouTube works when multiple people watch the same video - and yes, I’m ignoring caching for the moment. It requires a boatload of network bandwidth and hardware.

You could send part of the signal to a receiver, this is how WebSDR works. This requires a mechanism to select and control each part of the data stream.

A third option is to use a networking technique called multicast. It provides a way to send a data intensive stream, like our radio signal, to multiple computers simultaneously. NASA uses this to distribute radio signals all over the place. I used it in the early 1990’s to broadcast a live radio show I hosted, Online Computing Radio, across the globe with listeners in Sweden, Switzerland and Greenland whilst I was in a radio studio in Perth, Western Australia. This only to say that multicast has been around for a long time. Another way to look at this is that a radio transmission is a multicast signal. As long as you’re within range, anyone can receive the same signal.

To keep track of what we were talking about, this is discussing how a digitised received radio signal is distributed to various computers for processing.

Each of those three methods can be combined in interesting ways depending on requirements. For example, a spectrum logging tool might expect the entire stream, but an FM decoder might only want one little slice, a RTTY decoder might want a different slice and an FT8 decoder yet another.

Before I go on, let me come up with some terms. No doubt these will get refined, but for now, I’m going to define a receiver as a computer that acts as a destination, or sink, for a stream of radio bytes across the network. Similarly, I’ll define a computer that generates a source of radio bytes as a transmitter. I’m not yet sure what to call the computer that’s physically connected to the antenna, but I’ll start with using the term “antenna node”. This isn’t strictly accurate, since there’s more than an antenna there, but I have to start somewhere.

I note that GNU Radio calls a transmitter a source and calls a receiver a sink. With that nomenclature, our “antenna node” would be considered both a sink and a source, which doesn’t really help us here.

Back to the receiver. All of this needs some form of control intelligence, as-in, a receiver needs to be able to control where the signal comes from, or said differently, you need to be able select an antenna node. Not only that, you need to be able to tell the antenna node specifically what data you want and perhaps in what form.

Now, on the reverse side of this, the transmit chain, do we need the same functionality? Does an antenna node need to be able to accommodate multiple transmitters? Does such a thing exist? Do we want it to exist? How would we get one data stream from the transmitter to the antenna node? How would we do this with multiple streams? Is the same control system required?

At this point you’re likely to realise that this isn’t trivial. We can pick something and just start, but I’d like to spend at least a little amount of time considering the options.

With over 40 years in the computing field I’m leaning towards making the transmit and receive identical because we don’t yet know what we don’t know and besides I can sort of see how multiple transmitters might use the same antenna node and what the real world applications of this might be.

Something else to wrap your head around, what if the transmit logic was the reverse of the receive logic, as-in, the same thing, just swapping sink and source around. It has a certain elegance about it, even if I don’t yet know how this might be achieved.

I’d also like to take a moment to thank Kevin VE7ZD, Nick VA3NNW and Mark W1MM for their thoughts and suggestions. Keep them coming.

I’m Onno VK6FLAB