An open networked SDR platform for HAM radio experimenters

Over the past year I have been working on a personal SDR project that has gradually grown into something much larger than I originally intended. What started as experiments with STM32 microcontrollers, Tayloe detectors, Ethernet streaming, and DSP on the MacBook has evolved into a complete open protocol suite and SDR ecosystem, published under the name SDR-SLC.

The project is still under active development and many parts are not yet finished, polished, or documented to the level I would like. Nevertheless, enough pieces are now working together that it makes sense to publish the architecture, specifications, software, and hardware designs so that other HAM radio experimenters can follow along and eventually build on top of it themselves.

The central idea behind SDR-SLC is relatively simple:

Keep the radio hardware simple. Push the DSP processing to the host computer.

Modern laptops have enormous processing capability available for FFTs, filtering, demodulation, waterfall rendering, digital modes, and signal analysis. Instead of embedding all DSP functionality into expensive FPGA-based hardware, SDR-SLC moves as much processing as possible into software running on the host system.

The radio hardware itself therefore mainly becomes an RF frontend, I/Q sampling, Ethernet transport, and timing and synchronization. Everything else happens on the client.

SDR-SLC protocol suite

The first part is the protocol suite itself. This defines how all components interoperate: device discovery, control plane, stream lifecycle management, VITA-49 I/Q transport, and timing and synchronization. It is intentionally designed to be implementable on relatively small hardware platforms such as STM32 microcontrollers and Raspberry Pi systems.

The specifications cover the overall architecture, service discovery, the control plane, and VITA-49 transport. The protocols are open and intended for experimentation and interoperability. See the Specifications page for the current documents.

STM32-based SDR transceiver hardware

The second component is the SDR transceiver hardware. The current prototype consists of an STM32H753 Nucleo board, a Tayloe quadrature detector, several analogue op-amp stages, and an SI5351 clock generator. The goal is not to build the smallest possible SDR, but rather something that is understandable, hackable, and reproducible by experimenters.

The STM32 firmware is written in C and handles Ethernet networking, SDR-SLC discovery, control-plane processing, VITA-49 packet generation, ADC sample handling, and stream transport. This hardware continues to evolve as the RF and firmware experiments continue. See HF transceiver for schematics and firmware.

Native macOS SDR client

The third component is a native SDR client written in Swift for macOS. It implements automatic SDR-SLC device discovery, control-plane communication, VITA-49 reception, waterfall and spectrum display, and host-side DSP processing.

The client is already capable of communicating with working SDR-SLC devices, displaying live spectrum and waterfall data, and decoding SSB, AM, FM, WFM and CW. See the client for the current release.

Optional PTPv2/GPS clock

One optional component in the network is a realtime PTPv2 clock, currently implemented using a Raspberry Pi, a uBlox GPS receiver, and Linux PTP software. The purpose is to experiment with precise network timing, synchronized SDR receivers, accurate timestamps, and future distributed SDR experiments. This component is entirely optional but forms part of the larger architectural vision.

RTL-SDR reference implementation

To make experimentation easier, I have also written a Linux daemon that lets a standard low-cost RTL-SDR USB dongle, connected to a Raspberry Pi or Linux machine, appear as a fully networked SDR-SLC device. It implements SDR-SLC discovery, the control plane, VITA-49 streaming, and RTL-SDR tuner integration.

This means experimenters can already start testing the SDR-SLC ecosystem without requiring custom hardware. See Daemons for the current reference implementations.

Everybody seems to agree that SDR moves signal processing into software, yet when you look at many designs they still contain an impressive amount of analogue hardware. More filters, more gain stages, more switching, more AGC, more… well… hardware. That made me wonder whether we were actually solving the right problem.

Instead of asking “what hardware do I need to build an SDR?” I started asking a different question.

What is the absolute minimum amount of hardware I need before software becomes the better place to solve the problem?

Those are two completely different questions. The first usually ends with another schematic. The second forces you to justify every component. I honestly didn’t know whether that approach would work. There was only one sensible thing to do.

I built the simplest receiver I could think of.

Looking back at this prototype now, it looks unfinished. That’s because it was. I wasn’t trying to build a radio. I was trying to answer a question.

Could I receive a piece of HF spectrum, generate I/Q signals, send those samples over Ethernet to a MacBook and let the computer do the rest?

If the answer turned out to be “no”, there would be very little point in designing a proper PCB. Fortunately, the answer was “yes”.

The architecture worked almost immediately. The STM32 streamed the I/Q samples over Ethernet, the MacBook received them and all further signal processing happened in software. That was actually the most important result of the entire prototype. It meant I could stop worrying about the overall concept and start looking at the details. Those turned out to be far more interesting.

The first thing I discovered was that I had been a little too optimistic about the analogue gain before the Tayloe detector. My reasoning had been simple enough: once the signal reached the computer, software would take care of the rest. Reality turned out to be less forgiving.

If there isn’t enough signal before the detector, there simply isn’t enough information left for the DSP to work with.

Software can’t recover information that never reached the ADC. Looking back, that sounds almost embarrassingly obvious. It certainly wasn’t obvious before I built the prototype.

The second lesson came from the I/Q outputs. I had deliberately kept the circuitry after the Tayloe detector extremely simple, just a basic instrumentation amplifier and very little filtering. Again, that wasn’t because I believed this would be the final design. I simply wanted to discover how much analogue circuitry was actually necessary.

The answer was: more than this.

Strong stations outside the receive bandwidth still found their way into the sampled spectrum. The software faithfully processed everything it received, including signals that should never have been there in the first place. That was another useful lesson.

Some problems really do belong in hardware. Not because software isn’t capable enough, but because preventing unwanted signals before they reach the ADC is fundamentally easier than trying to remove them afterwards.

By then I had learned everything I needed from this prototype. Interestingly, none of those lessons changed the overall architecture.

• The Ethernet interface stayed.
• The STM32 stayed.
• The Tayloe detector stayed.

The idea of moving as much functionality as possible into software stayed.

What changed was the implementation. The next prototype added considerably more gain ahead of the Tayloe detector, proper low-pass filtering for the I and Q channels and, finally, transmit capability.

This second prototype looked much more like the radio I originally had in mind. Not because I had redesigned the architecture, but because I had stopped guessing. The first prototype had already answered the architectural questions, so the second one could focus entirely on engineering.

Only after those experiments did it make sense to draw a proper schematic.

Looking at the schematic today, I don’t really see a radio. I see three fairly independent building blocks:

• An RF front-end.
• An analogue I/Q processing stage.
• A digital processing platform.

That separation was intentional from the very beginning. Once the interfaces between those blocks were defined properly, improving one block no longer meant redesigning the entire system. I like architectures that behave like that.

What I find interesting is that this project taught me very little about radio. It taught me much more about engineering. The first prototype wasn’t a failed radio. It was a successful experiment. It answered exactly the questions it was supposed to answer, and no schematic or simulation could have done that.

Whenever I start a new project, I still catch myself asking the same question.

What is the simplest thing I can build that answers the question I actually have?

Because that’s really what prototypes are for. Not to prove that you’re right, but to discover where you’re wrong.

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.

My name is Ivo van Ling (PA2IX). I have spent more than 30 years designing communication systems, telecom platforms and critical infrastructure. Amateur radio has been my playground for almost as long. This project brings those two worlds together.

Over the past few years I have been designing an open Software Defined Radio ecosystem. It includes RF hardware, embedded firmware, desktop software and, perhaps most importantly, the communication protocols that allow those building blocks to work together.

The hardware is only one part of the system. Long before designing PCBs, I spent a considerable amount of time thinking about the interfaces between those components. If those interfaces are designed well, the hardware, firmware and software can evolve independently without breaking the overall architecture.

That philosophy runs throughout the project. Rather than inventing proprietary solutions, the SDR ecosystem builds on established technologies wherever possible. I/Q samples are transported using the VITA-49 standard. Radio discovery uses mDNS. Control and status information are exchanged using simple JSON messages over TCP/IP. The goal is not to create yet another SDR protocol, but to define a system that is easy to understand, extend and integrate.

Open systems begin with open interfaces.

The complete protocol specifications, hardware designs, firmware and software are published openly. They are not included merely as documentation of this project, they are intended to be used. Whether you want to build compatible hardware, experiment with your own DSP software or simply understand how the system fits together, everything starts with clearly defined interfaces.

The articles that follow tell the story behind those design decisions. They are not build logs. They explain why the architecture looks the way it does, why certain responsibilities ended up where they did and, just as importantly, why others didn’t.

If you’re interested in the engineering decisions that shaped the architecture, start with The First Design Decision Had Nothing to Do with Radio.