Bald Yak 14, choices and software flexibility

Foundations of Amateur Radio

Let's start with an observation, I'm a geek, have been all my life. Since my early teenage years that evolved as a predilection for computing. As you might already know, I became a radio amateur to essentially get away from computing. The reality turned out to be something else entirely.

I discovered that the time of combining radio and computing had already begun when I joined the community. Like the evolution from spark-gap, through valves, transistors and integrated circuits, radio has come to encompass software, least of which through SDR, or Software Defined Radio.

Why least?

Over the years I've attempted to explain some of my fascination and wonder with software, but one aspect I've been unable to convey succinctly is the scope of software. I'm not talking about the fact that you find software inside your microwave oven, your car, your bathroom scales, but that hints at what underlies the phenomenon.

If you're not familiar with spreadsheets, imagine a blank piece of paper with a grid drawn on it. Inside each square, or cell, you can put anything you want, a number, a label, a picture, a web address, a formula, a colour, borders, you name it. Your imagination is pretty much the only limiting factor.

Now, here's where it gets fun.

Once you have filled in the first cell, the next one follows. What this means is that once you've made the first decision, the next one becomes a little easier. Every time you make a decision, the number of options you have open to you become less and less, or to use another word, constrained.

So what, you ask?

Well, unlike a sheet of paper with a grid, a spreadsheet allows you to add rows and columns, at any point in your document. Doing that reduces the constraints, you have more options open to you. You can also add sheets, or even start a completely separate document.

In other words, you have a playground open to you that is infinitely flexible.

Writing software is like that, with bells on.

Now, I'm not going to tell you to start learning how to write software, though truth be told, there's lots of things to like, and admittedly, frustration, that comes with doing so.

Let's talk about that frustration.

Once you make the first decision, the next one is more constrained. So, if you start with a blank sheet, you have infinite possibilities. Writing software is exactly like that. Here's the frustration. What's the first thing you should decide, because once you do, your options become reduced.

So .. Bald Yak, 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.

That little phrase hides a lot of complexity, but it already contains some constraints. GNU Radio is one, distributed is another and so-on.

Let me share with you what my semi-blank piece of paper looks like.

I've been quietly working on an idea to use my Pluto SDR to listen to amateur radio repeaters. Not just one, all of them, across 2m and 70cm. I came up with this idea as a real-life project that I'd like to implement with whatever Bald Yak is, or becomes. It has all the bits I care about right now, multiple frequencies, something that goes well and truly beyond what my Yaesu FT-857d can do, it taxes my skill set, it gives me something to make tangible and it hopefully moves the needle on the Bald Yak project.

So, here's some variables to consider.

The Pluto SDR has a computer on-board. There are reports that people have run GNU Radio programs on the Pluto itself. This is attractive since the amount of data involved with monitoring 2m and 70cm simultaneously is likely to exceed that of the USB port on the device.

However, what I don't know is how much actual computing resources doing this will take to achieve and if a Pluto could actually do this.

To give you an example. Imagine a massive fire-hose of data coming into my software and then processing that. Between memory and CPU constraints, I can't just decode the stream for each repeater, likely duplicating a whole bunch of calculations.

While that consideration is on the table, decoding a dozen narrowband FM streams implies a dozen copies of the FM decoder software. Ideally this would be one actual piece of software, used a dozen times, rather than a dozen separate copies that will individually be maintained if something changes. For example, once I've built this, I might realise that I need to implement FM de-emphasis, a technique implemented in FM broadcasting to, among other reasons, manage artefacts associated with transmitting a signal over FM, perhaps a topic for another day.

When you write software you do not want to have copies of the same software in multiple places. To use a spreadsheet equivalent, it's like putting a Tax rate in multiple places across your document, rather than storing it in a cell and referring to it in other formulas. That way, you can change it once and all the calculations will automatically be correct. Same deal with writing software, especially if that software is intended to be used for more than a once off.

While that's going on, let me introduce another variable. I have a Pluto SDR, but the whole point of Bald Yak is that I cannot assume that you have one. It's one of the reasons I chose GNU Radio as the basis of this project.

While it's unreasonable to expect that a traditional amateur radio transceiver can decode more than one repeater, the same system could potentially be used to decode multiple Morse code signals, something that should be more than possible, essentially replacing the FM decoder with a Morse decoder.

Which brings up an example of another variable.

How wide do you make the channels? How do you define them? How do you make it possible to modify these without having to update the software, so an end-user can modify something on their screen and see the result?

At this point you might notice a couple of things.

I have not got any answers, I also don't have all the questions. It's unlikely I'll ever have all the questions, let alone answers, since the nature of this software thing is flexibility.

Now, to bring this in full circle, when I say that SDR, or Software Defined Radio isn't just the box that you connect to an antenna, it's the possibilities that this brings, the sheer volume of options that this opens you up to.

Now it's your turn. What questions does this bring for you? What sense of wonder can you bring to the table and what opportunities does this expose you to?

I'm Onno VK6FLAB