My Long-Shelved uSDX Project: From a Blank MCU to a Working Receiver

I recently pulled a uSDX V1.02 board back out of the drawer — one I had eagerly assembled years ago and shelved after powering it up and seeing nothing on the display. The uSDX is Guido PE1NNZ’s design, an ATmega328P-based HF QRP SDR transceiver. My PCB is Barbaros Aşuroğlu’s (WB2CBA) V1.02 version. This post is the story of how I brought the board I once gave up on back to life using nothing but a UNI-T UT89X multimeter and a NanoVNA. No oscilloscope in sight — just plenty of trial and error, and stubbornness. Maybe it will be useful to someone in a similar spot.

First Crisis: No Display, Because the MCU Is Blank

I apply power, the LCD backlight comes on, but the display shows nothing. I had three ATmega328P chips on hand, set aside years ago with a “I probably broke these” verdict.

I dropped the chips one by one into a socketed Arduino Uno and tried uploading code the normal way, over USB. All three gave the classic not in sync error. But getting that error doesn’t actually mean the chip is fried. A factory-fresh chip with no Arduino bootloader on it produces exactly the same error. So the root cause might not be a dead chip, but a completely blank one. And that, it turns out, was the real reason the board had spent years in a drawer: I had been trying to run the radio with a processor that had no firmware on it!

To be sure, I set up a second Arduino Uno as an “Arduino as ISP” programmer, connected to the chip, and tried reading its signature:

Device signature = 1E 95 0F (ATmega328P)

Yes — the chip was perfectly healthy, just completely empty. (The other two really were dead; they returned nonsense signatures.)

Rather than fussing with a bootloader, I flashed the radio’s firmware directly over ISP, and sorted out the fuse settings to match the uSDX’s 20 MHz crystal:

avrdude -c stk500v1 -P /dev/cu.usbserial-110 -b 19200 -p m328p \
  -U flash:w:uSDX_25mhz.hex:i \
  -U efuse:w:0xFD:m -U hfuse:w:0xDF:m -U lfuse:w:0xFF:m

One small detail here: you need to check whether the crystal on your Si5351 module is 25 MHz or 27 MHz. Flash the wrong firmware and all the frequencies shift. My module was a 25 MHz one, so I flashed accordingly. Chip back in its socket, the display came alive, and the encoder started changing the frequency. The digital side was done.

Can You Even Have a Receiver Without an Antenna?

In the uSDX V1.02 design, the filters and the power amplifier (PA) live on a separate plug-in module. I didn’t have an assembled module at hand. While studying the KiCad schematics I realized that the receiver’s signal path also runs through this module! In other words, with no module fitted, the antenna input is simply left hanging. That empty background hiss I heard in the headphones wasn’t a fault — it was the design itself.

As a temporary workaround, I bridged the antenna pin on the module socket (U9) to the RX input with a short piece of wire. Signal started flowing through the circuit — unfiltered, but flowing. Of course, this makes the radio incredibly wideband; it hears anything and everything. And one more thing: never press PTT while this bridge is in place, otherwise the PA module (not that there is one) has nowhere to push its power into.

Testing the Local Oscillator with a Multimeter

My multimeter’s (UT89X) frequency counter can measure up to 10 MHz. Since the Si5351’s outputs run at the same frequency as the dial, I pulled a little trick: I tuned the radio to 3.500 MHz and touched the meter’s probe to the CLK0 pin. Seeing 3.500 MHz on the display made me sure of three things: the I2C communication is working, the oscillator is producing a signal, and the firmware I had just flashed is correct.

Even if you don’t have a frequency counter, you can still get a rough idea of whether the clock signal is there using a DC voltmeter. A 3.3 V square wave shows up as an average of about 1.5–1.7 V on the meter. Seeing that voltage at the output is proof that, at the very least, something is running there.

Using the NanoVNA as a Signal Generator

To test the receiver I needed a weak RF source, and I remembered that the NanoVNA turns into a great little test transmitter in CW (continuous wave) mode. I did fall into a small trap, though: the NanoVNA boots into “sweep” mode by default. With the frequency constantly changing, you hear nothing at all on the radio. You have to pin it to a single frequency (say, 5.000 MHz) via STIMULUS -> CW FREQ in the menu.

With the radio set to 4.999.00 USB, I heard that famous ~1 kHz CW whistle in the headphones. Audio was coming through, but it was incredibly weak — the S-meter on the display sat around -116 dBm. With a strong source like the NanoVNA connected directly, losing more than 100 dB is not normal. Clearly the signal was breaking somewhere along the path and only reaching the receiver by leaking through stray capacitance.

Culprit Found: Pin 9 of the FST3253

To find where the signal was breaking, I touched the NanoVNA’s tip to the test points on the schematic one by one (TP4, TP3, and the antenna). The audio was equally weak at all three. That pointed to the QSD side — the switching IC.

Measuring the voltages on the board settled it. Normally the op-amp outputs should sit steady and balanced at mid-rail (about 2.5 V); mine were wandering anywhere between 0 and 3.6 V as they pleased. I caught the real problem while probing the FST3253’s legs: pin 9, the one corresponding to the antenna input, read 3.6 V while the trace on the PCB showed 5 V. The solder had never taken — the leg was floating in the air!

Apparently I had already tried to rework other legs of the same IC back in the day; clearly this is one of the most miserable parts of the board to solder. After refreshing the solder on pin 9 with the iron, all the voltages obediently settled around 2.5 V. When I hooked the NanoVNA back up, the audio coming out of the headphones was positively booming!

The Final Touch: Frequency Calibration

With everything working, all that remained was making the dial frequency accurate. Si5351 crystals can be slightly off frequency, and that gets corrected in the firmware via the Ref freq parameter.

With the NanoVNA emitting 5 MHz, I tried to bring the tone of the signal from the radio down to zero (zero-beat). But at 5 MHz, those subtle differences the ear can’t hear can be misleading. Doing this test at 14 MHz makes much more sense, because the error grows with the frequency and the adjustment gets easier. After a few attempts I settled on a reference value of 24999700. The crystal was only 12 ppm below nominal — not bad at all.

What’s Next?

Bringing the receiver back to life was a joy. The job doesn’t end here, of course: I need to look into the background noise when running on battery, wind the filter module for the 20m band and test it with the NanoVNA, and build my own dummy load out of 50-ohm resistors so I can tune up the transmit (TX) side. Those will probably be the subject of the next post.