Testing Ideas with Hardware

There has always been something about Software Defined Radio that I never quite understood.

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.