"The ESP32's hidden IQ mode: how a Wi-Fi chip became an SDR"

The ESP32's hidden IQ mode: how a Wi-Fi chip became an SDR

The ESP32 sells for a few dollars because its Wi-Fi modem is a fixed-function block: firmware hands it a frame, the modem decodes it, done. Nothing in the datasheet says you can watch the raw radio signal underneath. That turned out to be wrong. In September 2026, two groups working independently, the ESPARGOS antenna-array team and a Reddit user, h0m3us3r, discovered an undocumented mode in the ESP32 family that dumps raw IQ baseband samples straight out of the modem's ADC chain, turning the chip into a receive-only software-defined radio at up to 80 MSa/s. Hackaday picked it up on 3 October, and the comparison to the RTL-SDR story is obvious: another cheap consumer chip with an unstated capability, found by people who poked at it.

This post unpacks how the mode works, how it was reverse engineered, what you can and cannot do with it, and why it matters to defenders as much as experimenters.

How the mode works

Every ESP32 with radio support, from the original Tensilica-core parts to the current line, shares the same receive architecture: RF front-end, ADC, then a fixed-function Wi-Fi modem. The normal path is one-way and locked. The undocumented mode taps the signal between the ADC and the modem.

The mechanism, documented in detail on ESPARGOS's ESP-SDR page, is a debug/dump engine intended for the fab: special debug registers tell the modem's sampler to write raw IQ samples directly into the chip's internal SRAM instead of into the Wi-Fi pipeline. On the ESP32-C61, the dump engine writes into two SRAM banks arranged as a ping-pong ring buffer, the modem owns one bank while it streams samples, the CPU drains the other and ships it to the host. At 80 MSa/s and 32 bits per sample, that's 2.56 Gbit/s written into SRAM; getting samples off the chip is the real bottleneck, which is why throughput varies by model.

Each 32-bit dump word packs useful metadata alongside the sample:

So you get the complex baseband sample plus the receiver's gain state, enough to undo AGC scaling in software. Tuning is the modem's own synthesiser, so you get the 2.4 GHz ISM band on every supported chip, 5 GHz on parts that have that radio, and, because the front-end tunes wider than the official spec, captures beyond it: the ESP32-C61 demonstrably samples LTE band 7 / 5G NR n7 traffic around 2.6 GHz.

Two hard limits: receive only (there is no transmit path in the dump mode), and no Bluetooth-only or radio-less variants (the ESP32-P4 has nothing to tap).

How it was found

The starting point was librftest, Espressif's own RF test library used for factory and modem validation. Buried in it is an adctrig function that configures the hardware to capture raw ADC data. The ESPARGOS team reverse engineered that function, with LLM assistance for the disassembly legwork, to work out which debug registers the function touched and what the sample format was. That is a classic firmware-RE workflow that deserves more attention than the headline: no exploits, no JTAG tricks, just reading vendor test code that ships inside the SDK and asking what it does.

Independently, h0m3us3r posted raw IQ streaming from an ESP32-S3 at 80 MSa/s to r/esp32. Two independent discoveries landing in the same window suggests the capability was genuinely findable, the vendor test path leaks enough surface that patient people were converging on it.

What you can do with it

It is not a general-purpose SDR, frequency range is bounded by the modem's front-end, and sensitivity is whatever a Wi-Fi chip's receive chain gives you. But inside the 2.4 GHz ISM band, which is where an enormous amount of wireless life happens, the uses are concrete:

• Spectrum monitoring and interference hunting. A waterfall of the 2.4 GHz band from a $10 chip is genuinely useful for finding jammers, misbehaving baby monitors, or a neighbour's access point stomping your channel plan. The ESPARGOS demo streams into Gqrx via their open-source SoapyESPSDR driver, so the samples land in the standard toolchain, Gqrx for eyeballing, GNU Radio for demodulation experiments.
• Non-Wi-Fi 2.4 GHz signals. Zigbee, Thread, BLE advertising, nRF24-style traffic: anything the fixed modem refuses to decode, you can now record and analyse in software. This is the biggest research win. Previously, capturing raw Zigbee needed dedicated CC2531/CC1352 dongles; now any ESP32 board on the shelf works for narrow-band analysis at lower sample rates.
• Phase-coherent capture. The ESPARGOS One is an eight-antenna array of synchronised ESP32s. With IQ access, the array does phase-coherent capture, direction finding and augmented-reality RF visualisation that used to need multi-thousand-dollar synchronised SDRs.
• Cheap education. You cannot beat a board you already own for learning what a spectrum, a constellation, or an OFDM symbol actually looks like. Compare it with our RTL-SDR V4 kit (A$55): the RTL-SDR covers roughly 500 MHz to 1.7 GHz and remains the better all-round first SDR; the ESP32 mode wins on 2.4 GHz coverage, and on the fact that every dev kit in the drawer already has the hardware.

For Australian buyers, hardware availability is a non-issue: any ESP32 dev board works, including our ESP32 dev starter kit (A$45.45), stock is local, no grey-market ordering.

The legal line in Australia

Receive-only matters here. Under the ACMA's framework, receiving radio transmissions in free spectrum like the 2.4 GHz ISM band is not itself licensed activity; class licences govern transmitters, not listeners. Passively observing your own spectrum environment, interference hunting, Wi-Fi surveys, BLE traffic analysis, is lawful and is exactly what tools like wardriver firmware and SDR packages exist for.

Two boundaries to keep bright. First, the Telecommunications (Interception and Access) Act makes intercepting the content of communications on a carrier network an offence, the ESP32's out-of-band reach into LTE band 7 does not create a licence to demodulate someone's cellular traffic, and in practice a 10-bit, ~20 MSa/s sampler can't do that properly anyway. Treat those frequencies as out of scope. Second, anything beyond observation, transmitting, jamming, protocol replay against equipment you don't own, moves into ACMA interference-enforcement territory and criminal law. The ACMA has never treated "it was just a test on my bench" as a defence for interference complaints it receives.

Why defenders should care

An undocumented receive mode in one of the world's most deployed IoT SoCs reads both ways:

• Your devices are watchers too. Anything in an office with an ESP32 inside, smart plugs, displays, sensor hubs, can now passively observe the local 2.4 GHz spectrum, which is arguably a lesser concern than its normal packet-decoding behaviour, but it belongs on the risk register for secure facilities. The defence for both is the same: device inventory, network segmentation, and treating cheap Wi-Fi hardware as untrusted endpoints in sensitive spaces.
• Vendor test code is attack/research surface. The capability came from librftest, shipped in the SDK. Any vendor library marked "for factory testing" deserves the same scrutiny as production code. If your product's firmware bundles test libraries you didn't audit, they are undocumented features you didn't know you shipped, precisely how the RTL-SDR and ESP32 discoveries happened. The fix is procedural: audit what the SDK links in, strip test modes from production builds where you can, and document the ones you can't.
• Fuzzing the modem got easier. With raw IQ access, researchers can craft 802.11 baseband inputs against the fixed-function modem instead of working from mac80211 up. Fixed-function DSP blocks that never saw fuzzing now can. Vendors building Wi-Fi into safety-adjacent products should expect that work and budget response capacity accordingly.
• Bounty-grade testing for teams with small budgets. A security team that could not justify a few hundred dollars of synchronised SDR hardware can now run spectrum-hygiene checks, rogue transmitters, unexpected BLE advertising, interference sources, with parts-bin hardware. That closes a real gap in Australian small-business security practice, where RF is usually the layer nobody tests at all.

Espressif has not yet published a statement on the mode at time of writing. Given it is receive-only and rooted in fab-test hardware, it is closer to a feature accidentally documented by the community than a vulnerability, but products that assume the modem is a sealed box should revisit that assumption.

Getting started

1. Grab any ESP32 with a radio (S3, C3, C6, C61, check ESPARGOS's compatibility notes; Bluetooth-only and P4 variants are out).
2. Flash the ESP-SDR capture firmware, then run the browser-based IQ viewer, or install SoapyESPSDR for the Gqrx/GNU Radio path on the Ethernet-capable boards.
3. Start with the waterfall on 2.4 GHz and find your own devices, it's the fastest way to build intuition for what the spectrum around you actually contains.

Keep it receive-only and keep it on your own network's airspace, that is both the law here and the spirit of the tool.

Sources: Hackaday, "The ESP32, An SDR In Itself", 3 October 2026, ESPARGOS ESP-SDR documentation, SoapyESPSDR driver, h0m3us3r's ESP32-S3 IQ streaming post. This article is general information, not legal advice.

← All posts