The First Design Decision Had Nothing to Do with Radio
When I started thinking about this project, I wasn’t looking at mixers, filters or ADCs. I was trying to answer a much simpler question.
What exactly is the radio?
That may sound like a strange place to start, but I have found over the years that many engineering problems become much easier once you decide where the system boundaries are. Before choosing components, I wanted to understand what responsibilities belonged inside the radio, and just as importantly, which ones didn’t.
Architecture starts by deciding where responsibilities belong.
At first glance this may seem like an odd question. After all, a software-defined radio receives RF signals, processes them and presents them to the user. That’s what every SDR does. The interesting question is where those functions actually take place.
Many commercially available SDRs perform most of the signal processing inside the radio itself. The client application running on the PC is largely responsible for presenting the results. That’s a perfectly sensible architecture. It creates a self-contained appliance with predictable behaviour, regardless of which computer is connected to it. It’s clearly optimised for a very different set of design goals than mine.
My goal wasn’t to build a commercial appliance. My goal was to understand how little intelligence actually needed to live inside the radio.
I already had a powerful computer on my desk. Why would I build another one inside the radio?
That question changed almost every design decision that followed.
Instead of designing a sophisticated SDR, I started thinking about a very simple network appliance. Its job would be limited to interacting with the analogue world: receive RF signals, generate I/Q samples, accept I/Q samples for transmission, and put those samples onto the network. Nothing more.
Everything else would happen on the computer, the DSP, the user interface, the waterfall display, recording, and experimenting with new algorithms. Those things all benefit from fast processors, plenty of memory and a mature software environment. A modern desktop computer already provides all of that. It seemed unnecessary to duplicate those capabilities inside the radio.
Once I had reached that conclusion, something interesting happened. The discussion was no longer about Ethernet versus USB. It was about what kind of system I was building.
A USB SDR is, by definition, a peripheral. It extends a computer with radio functionality. There is absolutely nothing wrong with that model; in fact, it has made SDR accessible to thousands of radio amateurs. It simply wasn’t the system I wanted to build.
I wanted the radio to become an independent appliance that provided a service over the network. The computer became just another client. Today that client might be a MacBook. Tomorrow it could be a Linux workstation, another computer elsewhere in the house, or perhaps something that doesn’t even exist yet. The radio shouldn’t care.
USB connects a device to a computer. Ethernet connects independent systems.
Once I looked at it that way, Ethernet wasn’t really a technology choice anymore. It became the natural consequence of the architecture.
Only then did I start looking for hardware.
Interestingly, finding the right processor turned out to be much harder than I expected. I wasn’t looking for the fastest CPU or the most impressive benchmark numbers. I wasn’t planning to run sophisticated DSP algorithms inside the radio, so raw processing power wasn’t particularly interesting. What I needed was something much more mundane: a processor that could reliably move I/Q data between the analogue hardware, memory and an Ethernet interface without getting in the way.
Eventually I settled on the STM32H753, using ST’s Nucleo development board. Not because it was the “best” processor, but because it matched the responsibilities I had already assigned to it. The processor didn’t have to be clever. It had to be dependable.
I didn’t choose the processor because of what it could calculate. I chose it because of what it didn’t have to calculate.
Looking back, I think that first architectural decision has survived almost every hardware revision that followed. The analogue circuitry changed. The filtering improved. Transmit capability was added. The PCB layout became considerably cleaner. But the system boundary never really moved.
The little box next to the antenna still has exactly the same responsibility as it had in the very first sketch: interact with the analogue world, and leave everything else to the machine that is already much better equipped to deal with complexity.
The next question, of course, was whether that idea would actually work. There was only one way to find out. I built the simplest prototype I could think of.