The evolution of software in radio ...

Foundations of Amateur Radio

The amateur community is nothing if not entertaining. Look at any discussion about a mode like FT8 and you'll discover people who describe it as the dehumanising end of the hobby. In the same thread you'll find an amateur who's been licensed longer than I have been alive who welcomes it using words like revitalising, more active, and the like.

If you're not familiar, FT8 is one of many weak signal digital modes that gained popularity over the past years during the most recent solar minimum when long distance HF propagation was challenging.

That example discussion was about the visible end of a mode like FT8, but there's an often overlooked all but invisible aspect of these modes that is much more significant, namely the popularisation of signal processing in software.

In many ways amateur radio is more about receiving than transmitting. This might not be obvious, but what's the point of transmitting if you cannot receive? Using software to do the listening makes for an interesting evolution that might be hard to grasp if I start digging into the fundamental algorithms that make this happen, instead let me describe a process that is easier to explain.

Imagine that there's a piece of software that knows how to decode digital signals. As the user of that decoding software, or decoder, you send audio into one end and callsigns and grid-squares come out the other end. How it does this isn't important right now.

We measure the quality of this decoder by how many times it correctly does this, in other words, how many times a correct callsign and grid-square comes out. The decoder can be improved by changing the way that the decoding process works. If the number of correct callsign and grid-squares that come out increases, the quality of the decoder is improved.

Now imagine that the decoder spits out the callsign 7N5EC with the grid-square OF78. This particular combination emerged as a WSPR decode on the 10th of December 2022. It was reported by AA7NM as a 100 Watt signal, 14,882 km away on the 40m band. The signal report was -30 dB.

If you know where OF78 is, you'll immediately spot a potential problem, if not, I'll help you out, OF78 is located near Perth in Western Australia. It's unlikely that a transmitted callsign in that part of the world starts with anything other than VK6. Mind you, a weather balloon with an odd callsign could theoretically be overhead in that location, but I've not yet heard of a 100 Watt transmitter on 7 MHz that someone hung from a weather balloon.

Another problem is that 7N5EC is a callsign that appears to be Japanese. It starts with 7N which is part of the Japanese callsign block, but the next symbol is the number 5 and at least according to the research I was able to do is not actually a currently valid callsign. The prefix 7N4 is allocated to the Kanto region on Honshu island, the largest island in Japan. 7N5 doesn't seem to be valid as a prefix. Ironically, that callsign will now exist on the Internet as soon as this article is published, but that's a whole other problem.

Either way, the chances of the combination of the callsign 7N5EC with the grid-square OF78 is unlikely to be correct. It gets even less likely if you consider that the callsign was reported only once in fifteen years and over 500 million WSPR decodes, I checked.

That means that if you updated the software to ignore that particular decode, you'd have improved the decoder by removing an incorrect combination. You could keep doing this by checking callsigns against grid-squares and against allocated callsigns and you'd have made a higher quality decoder.

Before you start arguing that this isn't fair, it's exactly the same process as the super check partial list does for people operating in a contest. The idea being that if you only recognise known contesting callsigns, you've got a better chance of making contact.

Think of it as a way of filtering out potentially incorrect callsigns. It still leaves the operator having the option to ignore the suggested callsigns and listen to what's actually coming in.

I realise that this is not how you would realistically improve a digital signal processing decoder, but it's an example of how changing the software can change the quality of a decoder and that was the point of this example. In reality you'd attempt to discover how this decode happened and what caused it to be wrong.

If you want to consider a more signal centric example, consider a decoder that starts with a first attempt at making a decode. With a single decode, it can then remove that known signal from the original audio and start another decoding cycle. You can repeat this as many times as you want until you end up with gibberish. Essentially this is an example of how a modern decoder can improve its performance.

This is why signal processing in software is so powerful and important and why FT8 and the rest of the digital firmament are here to stay. I should point out for those wondering, FT8 and WSPR are examples of simple messages, but there's nothing stopping us from using digital messages like this to exchange little bits of audio, or video, or something else. It's how mobile phones work today and at some point amateur radio is going to extend the envelope and come up with the next thing, it always has.

So, FT8, it's changing amateur radio, but not because we're glued to a screen having our computer talk to another one, but because it represents digital signal processing in software and it's just the beginning.

I'm Onno VK6FLAB