Skip to main content

ESP32 SDR projects make the data-transfer path the deciding limit

Raw radio samples are accessible, but a browser capture, an S31 stream and an S3 FPGA assembly have different requirements. Start with the experiment you need.

TechKili3 min read
A copper loop on a black base with a blurred cyan wave in the background
TechKili · AI-generated illustration with Cloudflare FLUX
Share this article:
In this article

Open ESP32 projects are turning supported Wi-Fi chips into experimental software-defined radio receivers, without adding a separate radio front end. The useful distinction is whether a board can briefly capture raw samples or keep delivering them to a computer. Hackaday reported the projects on October 3, 2026; eSpDR's public repository was created on September 25. This is emerging project documentation, not an announcement of a new ESP32 chip.

A spectrum view can have gaps

The ESPARGOS ESP-SDR documentation describes access to the modem's raw I/Q samples. Those samples preserve amplitude and phase information for software processing, rather than exposing only decoded Wi-Fi packets. That does not make a supported chip a receiver for every radio band.

Its browser tool can display a spectrum and waterfall from supported ESP32 devices, but the serial transfer path has a very low duty cycle: reception occurs in short captures, with gaps between them. A signal appearing in one capture does not prove that packets arriving during the gaps will be received. An impressive capture rate is therefore a poor substitute for knowing the continuous data path.

Continuous reception uses a different hardware chain

SoapyESPSDR specifies an ESP32-S31 Function-CoreBoard for continuous streaming, with documented rates up to 20 MSa/s over high-speed USB and 40 MSa/s over Gigabit Ethernet. These are project-reported capabilities, not TechKili measurements. Its streaming firmware profile is distinct from the browser-capture profile; a flashing or debug connection is not automatically the required stream interface.

The eSpDR proof of concept takes another route: an ESP32-S3 passes an 80 MSa/s stream through an Alchitry Au FPGA and an Ft USB bridge using an FT600. That is a hardware assembly with a breakout, not an ordinary S3 development board delivering that rate through its own USB connector.

Both repositories describe receive-only prototypes. SoapyESPSDR also flags remaining signal-quality limitations, including a DC peak and aliasing when the sample rate is lowered without additional filtering. It should not be treated as a calibrated power meter. The engineering interest is access to raw radio data with these chips; dependable reception still requires attention to transport and signal quality.

Match the experiment to the board

If you already own a supported ESP32 board, the browser path is a reasonable starting point for intermittent spectrum exploration. Use the project's compatibility list and correct firmware rather than assuming all ESP32 variants provide the same features. A continuous-reception requirement points instead to the specified S31 setup or the substantially more involved eSpDR assembly.

For someone who needs an S3 board for the browser path, Espressif documents the ESP32-S3-DevKitC-1-N8R8 and its exact module configuration. It is a related experimentation option, not the S31 receiver and not a complete 80 MSa/s system. TechKili's assessment is to settle the capture-versus-continuous requirement before buying hardware; retaining an existing compatible board can be enough.

Related products on Amazon

Affiliate disclosure: As an Amazon Associate I earn from qualifying purchases. Links in this section may earn TechKili a commission without changing the purchase price.

  • Espressif ESP32-S3-DevKitC-1-N8R8: An ESP32-S3 alternative for the project's low-duty browser captures if you need a board. It is not the S31 streaming board and does not include eSpDR's FPGA/USB-bridge hardware.

Sources

#esp32#software-defined-radio#espsdr#esp32-s31#esp32-s3