PicoRX turns a cheap microcontroller into a 30 MHz software defined radio

Crystal radio nostalgia, with a microcontroller in the middle

The project starts with a memory. The author's first step into electronics was a crystal radio, the kind that needs no batteries, and hearing faint sounds through the earphone convinced them that building a radio could be simple. The question the project asks is whether that sense of awe can be recreated with today's parts.

The answer is a device armed with just a Raspberry Pi Pico, an analogue switch and an op-amp, described as a capable SDR receiver covering the LW, MW and SW bands, with the ability to receive signals from halfway around the globe.

That is the whole parts list, more or less, and it is the crux of the project. A conventional software defined radio needs a host computer to do the decoding and a wideband front end to feed it. PicoRX does the signal path on the microcontroller itself, with the analogue switch picking which part of the band reaches the op-amp and the Pico doing the rest in software.

The naming follows the pattern too. The title is Pi Pico Rx, a crystal radio for the digital age, and the README sits in a repository called PicoRX. The author is candid that while it may not be quite as straightforward as the crystal radio, it is still a remarkably simple solution.

What the finished set is specified to do

The feature list is short and concrete, which is a good sign for a hardware project. Coverage runs from 0 to 30 MHz, and the receiver has a 250 kHz bandwidth. It handles CW, SSB, AM and FM reception, and there is an OLED display with a simple spectrum scope. Output is through headphones or a speaker, and the set keeps 500 general purpose memories.

Two entries in that list tell you what kind of device this is. A 250 kHz bandwidth and a simple spectrum scope describe a receiver built for voice and CW, with a narrow view. It is not a panoramic receiver that can show a whole band at once, and it is not a replacement for a waterfall display.

The power figures are equally specific. It runs on three AAA batteries and draws less than 50 mA. For a device that is meant to be carried and listened to, that combination is the design constraint that shapes the whole thing, since the Pico's own current draw is a large part of that budget.

The memory count is worth a second look for a different reason. 500 general purpose memories means the receiver is meant to be a working instrument that you return to the same stations, not a demonstration you run once.

The build has three board targets, and they are not interchangeable

The build system is CMake against the Raspberry Pi Pico C/C++ SDK, and the documentation gives three separate invocations because the firmware differs by target silicon.

For the original Pico, with the RP2040:

  mkdir build
  cd build
  cmake -DPICO_BOARD=pico -DPICO_SDK_PATH=~/pico/pico-sdk ..
  make

For the Pico 2 with the RP2350 in ARM mode:

  mkdir build
  cd build
  cmake -DPICO_SDK_PATH=~/pico/pico-sdk -DPICO_BOARD=pico2 -DPICO_PLATFORM=rp2350-arm-s ..
  make

And for the Pico 2 in RISC-V mode:

  mkdir build
  cd build
  cmake -DPICO_SDK_PATH=~/pico/pico-sdk -DPICO_BOARD=pico2 -DPICO_PLATFORM=rp2350-riscv ..
  make

The difference between the last two is one flag, and it is a meaningful one, because the RP2350 can boot either architecture and the firmware has to be built for the one your part actually runs. The repository mirrors that split at the top level with separate prebuilt binary archives for the RP2040 Pico and for the RP2350 Pico 2 in both flavours, binaries-rp2040-pico.zip, binaries-rp2350-pico2.zip and binaries-rp2350-riscv-pico2.zip.

Those archives matter more than they look, because the alternative to using them is installing the Pico SDK.

Prebuilt binaries, or the full SDK path

There are two ways to get the code onto the board.

The quick one is a precompiled binary from the releases page, and the release names confirm that is the intent: v0.1.1-alpha and v0.0.1 are both labelled Pre-Built Binaries for Pi Pico Rx, dated 2025-09-30 and 2024-12-05. No SDK, no toolchain, no CMake configuration.

The other is to build from the C++ source. That starts with the repository itself, and the submodule steps matter because the project pulls in libraries:

  sudo apt install git
  git clone https://github.com/dawsonjon/PicoRX.git
  cd PicoRX
  git submodule init
  git submodule update

Then the SDK. The documentation points at the Raspberry Pi Pico getting started guide for installing the C/C++ SDK, and the shell version of that is:

  sudo apt install wget #if wget not installed
  wget https://raw.githubusercontent.com/raspberrypi/pico-setup/master/pico_setup.sh
  chmod +x pico_setup.sh
  ./pico_setup.sh

For Windows users the documentation points at the Raspberry Pi Pico Windows installer, which it says makes the process much simpler. Given that the build targets three different silicon configurations, the prebuilt binaries are the sensible starting point for anyone who just wants a receiver.

The source tree shows a receiver built from signal processing pieces

The top level of the repository reads like a description of the signal chain, which is the clearest evidence of how the receiver works. There is fft.cpp and fft_filter.cpp for the fast Fourier transform and the filtering around it, nco.cpp and nco.h for the numerically controlled oscillator that moves the tune frequency, cic_corrections.cpp for cascaded integrator comb corrections, and noise_reduction.cpp.

Two PIO programs sit alongside them, quadrature_encoder.pio and nco.pio, which is the tell that real-time work is happening on the Pico's programmable input output blocks rather than in the C++ loop.

The display side has ili934x.cpp and ili934x.h for the ILI934X display driver, plus a pwm_audio_sink.cpp for the audio output path, and the buttons and rotary encoder are handled by button.cpp, button_encoder.cpp and encoder.h. Memory handling is split into memory.cpp, memory_loader and autosave_memory.cpp, which is where the 500 stored channels live.

The directory listing also shows the hardware side of the project sitting in the repository: a PCB directory for the board design, an enclosure directory, codecs, a grc directory, images, and a build_all script alongside the cmake_build directory and BUILD.rst. The build_all script is a hint that building all three board variants is a supported operation rather than three manual invocations.

Community contributions, and a project at the prototyping stage

The project is described as currently at the experimental prototyping stage, but it does work, with the technical details in the linked documentation. That combination is the honest summary of where the project sits, and it is worth weighing against the alternative of a finished commercial receiver.

The credits are extensive and specific. The project uses the Universal 8-bit Graphics Library by olikraus, the pico_ssd1306 display library by David Schramm, and the ILI934X display driver by Darren Horrocks. Mariusz Ryndzionek is credited with IQ imbalance correction, a de-emphasis filter, USB audio, u8g2 integration, synchronous AM demodulation and many other enhancements. Penfold42 is credited with gain calibration, frequency scanning, spectrum zoom, multiple home screen views, an animated splash screen, and support for multiple displays and configurations.

That list reads like a project with an active contributor community rather than a single author with a repository. Robert Nickels and Jim Reagan are credited for their support and for the effort they put into testing, debugging, feedback and suggestions.

The maintenance picture is quiet but current. The last push was on 2026-09-05, the newest release tag is v0.1.1-alpha from 2025-09-30, and the previous one is v0.0.1 from 2024-12-05. The version numbers stay below 0.2 and carry an alpha suffix, so the firmware interface should be treated as unstable if you are writing your own code against it. The licence is a custom one, recorded in COPYING.txt at the top of the repository, and it is worth reading before you build a commercial product on it.

Editorial conclusion

Adopt PicoRX if you enjoy hardware and want a working shortwave receiver on a board that costs pocket money, and you are willing to solder, tune and accept an experimental design. Do not adopt it if you need a commercial receiver, a wideband SDR with a laptop for the waterfall, or a device that will sit unattended for years, since the project describes itself as being at the experimental prototyping stage. Before you order parts, check three things: the three build targets, since the firmware differs across the RP2040 Pico, the RP2350 Pico 2 in ARM mode and the Pico 2 in RISC-V mode, the prebuilt binaries, which are published per board and save you installing the Pico SDK at all, and the licence file, because the repository carries a COPYING.txt that is a custom licence the platform does not classify.

Frequently asked questions

Official sources

1. dawsonjon/PicoRX on GitHub
2. Issues
3. README
4. Releases