ESP32 SDR: from failed 433 MHz experiments to live phone decoding

An ESP32-S3 investigation, updated with live Android decoding and physical tests on 17 October 2026.

An ESP32-S3 can expose real radio samples. The question is how far that capability carries toward useful applications. Conceptual illustration.

I wanted to turn an ESP32 into something more ambitious than another Wi-Fi gadget: a small radio instrument that could capture a remote-control transmission, send the recording to a phone, decode it and eventually reproduce it.

The starting point was the ESPARGOS esp-sdr project, which exposes raw radio samples from hardware already inside supported ESP32 chips. That is an exciting capability. It also raises an easy-to-misunderstand question: if software can ask the chip to tune to a frequency, can the chip actually receive useful information there?

We tested that question through firmware changes, controlled radio transmissions, independent receivers and a Flutter phone app. We tried GPS, broadcast FM, 433 MHz remote-control signals, native-band transmission, Bluetooth packets and tools for investigating unknown protocols. A later visit to the bench tested continuous USB recording, additional antennas and lower-frequency reception claims.

We now have a working receive-and-decode phone prototype: the ESP32-S3 streamed real radio samples, and the Android app filtered and decoded our test transmissions live near 2.0 and 2.2 GHz, with a 2.437 GHz control. A laptop still bridges the USB connection. The phone can save and reopen those recordings, but dependable ESP32-only 433 MHz capture and replay remains unfinished, along with GPS and general-purpose monitoring. The result is useful, with a much narrower scope than the radio tool we originally imagined.

What the published project actually offered

A software-defined radio moves some of the work of understanding a radio signal into software. Raw I/Q samples are paired measurements that preserve information about a waveform's changing strength and phase. They give software more to work with than a finished Wi-Fi packet.

The attraction here was access to those measurements through an undocumented capture path in an inexpensive chip. However, the revision used in our earlier controlled receiver campaign described receive firmware and warned that accepting an extended tuning command did not guarantee reception or frequency lock. A setting labelled 433 MHz was not a promise of a working 433 MHz radio.

Our board was an ESP32-S3, whose documented wireless functions are in the 2.4 GHz band. That specification provides context; it does not, by itself, prove what every undocumented mode can or cannot do. The experiments still had to answer the question. Espressif's ESP32-S3 datasheet describes the supported radio.

This article concerns one board and the firmware and app paths we tested. It is not a verdict on every ESP32 variant or every future version of esp-sdr.

The first lesson was to test our own tests

Some work began in an earlier LLM-assisted session. The inherited notes included promising plots, register experiments and confident explanations. We kept the records, but checked their claims against the code and subsequent measurements.

Initial checks established functioning spectrum and raw-sample modes, but one capture path sometimes returned nearly fixed extreme values while another retained useful signal variation. Even a clean transfer could carry unusable measurements.

Several early successes did not survive that review. Startup transients and unrelated radio activity had been mistaken for transmissions from the ESP32. One capture script examined a recording interval that ended before the intended transmitter started. Another firmware command accepted parameters without actually applying them.

Even our reference remote-control waveform needed correction: its original frame boundary produced a 23-bit interpretation where a 24-bit frame was intended. Matching a fragment of an expected code was also much weaker evidence than independently recovering a complete frame.

There was an error in the opposite direction, too. An early transmission sequence failed even at the chip's normal operating frequency. Its failure at 433 MHz therefore could not establish that all possible transmission approaches were impossible.

We tightened the method: demonstrate a known working case first, compare transmitter-off and transmitter-on captures, discard startup disturbances, verify that recording and transmission overlap, and require the observed signal to change when the source changes. Where possible, a separate receiver checked the transmitted waveform.

This was one of the most useful outcomes of the investigation. A frequency command saying “OK,” a clean data transfer, a spectral peak and a correctly decoded packet are different levels of evidence.

The earlier phone workflow separated the transmitter, actual over-air reception, retained samples and decoding. A successful independent witness did not automatically validate ESP32 reception. Continuous USB analysis first ran on the laptop; the new live phone path appears later in this article.

GPS and FM did not become working applications

The early work included GPS signal-search software and tests with four antenna configurations, including a GPS-labelled antenna. Numerically inserting a GPS-like signal into saved samples showed that the search algorithm could recognize its test signal. It did not show that the ESP32 could receive a satellite through its antenna.

No live satellite acquisition or position fix was demonstrated. Later source review also found limitations in one frequency-search configuration. The defensible conclusion is that our GPS experiment did not succeed; we did not establish a calibrated sensitivity limit or isolate the exact internal hardware cause.

An exploratory broadcast-FM attempt likewise produced no useful station or audio demonstration. Some original analysis mixed frequency units, so its strongest numerical claims should not be treated as proof that the chip was completely deaf in that band.

Broader frequency surveys were similarly inconclusive. Occasional changes in a graph did not establish usable reception at every frequency on an early “capability map.”

Could new firmware add transmission?

Yes, within a narrower scope than we originally wanted. After replacing the incomplete setup sequence with the fuller native radio test setup, we obtained a reproducible carrier near 2.437 GHz.

We then timed changes in that carrier to encode a synthetic pulse message using on-off keying, or OOK. After correcting initialization and measurement timing, the final three runs produced 60 independently decoded frames out of 60 transmitted test frames, with no matching frames in six surrounding transmitter-off controls.

That was real internal-radio transmission. It was also a custom experiment beyond the upstream receive-only firmware, with residual energy in the nominally low state. It did not provide arbitrary waveform transmission, simultaneous reception and transmission, or 433 MHz remote replay.

For 433.92 MHz, we tried direct retuning, a receiver-style tuning sequence, gain and calibration changes, clock reinitialization and alternative frequency calculations. The native-band controls worked; repeated measurements around the requested 433 MHz output stayed near the off-state baseline.

We also investigated whether an undocumented divider might move the radio into that band. Code and register analysis, broad spectrum sweeps and small frequency-step tests did not reveal a working route. One retuned state produced a drifting feature around 2.8 GHz. It did not follow the requested 433 MHz adjustments as a correctly tuned transmitter should.

That behaviour was consistent with an unsuccessful frequency-synthesis state. It was not a direct measurement of every internal circuit, and it does not prove that nobody could ever discover another configuration. It does explain why we could not claim usable 433 MHz transmission from these tests.

The harder question: could it at least receive 433 MHz?

Our main target was a Princeton-format remote-control recording at 433.92 MHz. To avoid relying on a remote button press happening at the right moment, we used a HackRF as a controlled radio source. A Flipper Zero independently confirmed valid reference transmissions.

The more rigorous receiver campaign also used steady tones. Those avoided the excuse that a very short ESP32 snapshot simply missed an on-off pulse. We compared the original and a then-current upstream receiver revision, with different tuning and gain conditions, and moved the source across five nearby frequencies.

Across 90 randomized on/off trials and 360 raw captures, no receiver condition produced a qualifying persistent tone that tracked the controlled source. This was a negative result for our setup, with uncalibrated antenna coupling and sensitivity. It was not a universal claim of zero possible response.

We also built a longer envelope capture mode, which records the signal's strength over time rather than retaining every raw sample. A one-second trial delivered 31,267 strength measurements with valid transport checks and no reported gaps or drops. The independent source check recovered ten matching frames; the ESP32 path recovered none.

The same general approach did recover synthetic Princeton-format messages near 2.4 GHz, including three decoded observations in a physical-phone test. That was a useful positive control: the decoder could work when the capture contained a suitable signal.

So the problem was not merely that we had forgotten to make a long enough recording. A longer capture representation was tried, and the controlled 433 MHz decoding result still failed.

A phone can interpret samples, but it cannot replace missing evidence

We built a Flutter app to take over the heavier analysis: frequency plots, waveforms, waterfall displays, decoding, and saving, reopening, renaming and exporting recordings. The phone pipeline did receive actual ESP32 samples.

Making that pipeline work took its own engineering. Wi-Fi communication and SDR capture had to be coordinated; early versions encountered memory and radio-restoration failures. Other test runs used a USB bridge through the computer. Those are different transports, not independent demonstrations of radio reception.

Our earlier full-rate phone path normally retained 6,144 complex samples at 16 million samples per second. That sounds substantial until it is converted into time: 0.384 milliseconds. The corrected Princeton reference frame lasted about 50.165 milliseconds, over 130 times longer.

An earlier saved capture format lasted 0.768 milliseconds, still shorter than one complete bit in that particular remote-control waveform. Tiny expected-pattern matches inside those snippets could not establish a decoded transmission.

The earlier phone path: one full-rate snapshot compared with one reference frame. This is not a limit on all ESP32-S3 recording modes. The continuous USB results below came from a different capture path.

Software can extract information that is present but difficult to see. It cannot recover an arbitrary transmission from intervals that were never recorded, or turn an unrelated waveform into evidence that the intended signal reached the receiver. The same distinction applies to data integrity: a valid checksum on the USB or Wi-Fi transfer proves that bytes arrived intact, not that they contain a valid radio packet.

The longer USB recording path worked

On 17 October, we tested a capability we had not validated in the earlier phone workflow: the upstream continuous, decimated USB I/Q mode. “Decimated” means that the firmware filters and reduces the stream before sending it out. It records a narrower slice of radio bandwidth for much longer.

The S3 delivered ten-second recordings at 62,500, 125,000 and 250,000 complex samples per second. Frame checks, sample indices and terminal counters agreed, with no detected gaps in those runs. That is a bounded measurement, not a guarantee of indefinite loss-free streaming.

The samples also contained useful radio information. Near 2.4 GHz, a received tone moved as we changed the transmitter frequency and stood well above the transmitter-off controls. In one three-second Princeton-format recording, the unchanged Python and Dart application decoders each recovered ten complete matching messages. A separately implemented decoder confirmed those observations. The expected word was compared after decoding, rather than being given to the decoders as a pattern to find.

An actual native-band message recovered from the continuous USB recording. The application decoder recovered ten matching observations in this capture. This was measured radio data, analyzed offline on the computer.

This changed the short-window part of the story. The ESP32-S3 could supply a useful continuous recording path at these settings. At that stage, the Dart application decoder still ran on the laptop against saved samples. Connecting the stream to the physical phone was the next step. A longer recording also did not automatically expand the chip's radio-frequency coverage.

Longer recordings and different antennas did not finish the 433 MHz application

We repeated the 433.92 MHz tests with an antenna believed to be for that band, swapped to the original Wi-Fi antenna, and returned to the first one. In the first two stages, a Flipper Zero repeatedly decoded the synthetic source while the ESP32 produced no complete matching message. We also varied the receiver's requested frequency, gain and capture mode, and checked steady tones that should have moved when the source moved. No qualifying source-tracking carrier emerged in the tested 433 MHz settings.

Actual recordings from the same campaign: native-band peaks followed controlled source changes; the shown 433 MHz traces did not produce a qualifying tracked carrier. The scales are uncalibrated sample measurements, not sensitivity or antenna-port power.

The antenna comparison had an important limitation. After we returned to the first antenna, the Flipper reference checks became weak or failed. We preserved those runs, but could not present the whole sequence as an equally controlled antenna comparison. The first antenna's model and tuning were also unconfirmed.

We then reversed the source and witness roles. Flipper transmitted at 433.92 MHz while HackRF and the ESP32 recorded. The HackRF recording independently yielded eight distinct complete matching messages; the concurrent five-second S3 recording yielded none. That separate success confirmed a real reference transmission, without repairing the earlier failed reference checks.

A further test used another antenna taken from an ESP32 device, again with an unknown frequency rating. Three separate Flipper-transmit trials each produced eight complete matching messages in the HackRF recordings and none in the S3 recordings. Source-off recordings before and after produced no matching messages in either receiver. Native-band reception still worked: in the final native-band test, four application-decoded messages passed the stricter check of the gaps surrounding each complete message.

Those results strengthen the negative finding for our intended 433 MHz application. They do not measure antenna efficiency or sensitivity, prove that no RF energy reached the chip, or establish what every possible configuration could do. Device placement was not calibrated, and we did not isolate the precise internal hardware cause. The original phone-prototype firmware was restored and verified after that earlier campaign; the subsequent live phone tests used the continuous USB firmware.

We found working reception below 2.4 GHz

The lower-band tests changed the conclusion further. Upstream documents an experimental lower-frequency receive mode that changes how the receiver derives its tuning frequency. We tested it near 1.85, 2.0 and 2.2 GHz using the same S3 and the unidentified antenna.

Near 2.0 and 2.2 GHz, the received tone followed controlled changes in the transmitter frequency. Moving the receiver's tuning independently also moved the tone by the amount expected for the documented conversion mode. Checks at different sample rates helped distinguish a real source response from a misleading digital artifact. These were successful measurements at specific frequencies, not a qualification of every frequency between them.

Actual lower-band measurements. The top plots show the response to transmitter changes; the lower plots show a separate receiver-tuning check with the transmitter fixed. The amplitudes are uncalibrated.

Recovering a message took another step. Feeding the original whole-band amplitude into the decoder produced no complete messages. We then used a separate steady-tone recording to choose one fixed channel, before attempting the supplementary decode. Shifting that measured carrier to the center and applying a low-pass filter with a 6 kHz cutoff selected a nominally 12 kHz-wide slice of the complex recording. The source word was still withheld from the decoder.

After that preprocessing, the unchanged Python and Dart application decoders recovered 54, 53 and 52 complete source-matching messages in three trials near 2.0 GHz. Near 2.2 GHz, the counts passing the same full-message and surrounding-gap checks were 19, 13 and 17. All four transmitter-off controls at each frequency remained at zero. A separate decoder confirmed message recovery; its counts differed, so we did not add the results together or turn them into a delivery percentage.

The same measured 2.0 GHz recording before and after the fixed filter. The bars report the independent decoder's complete-message counts; the text reports the application decoder's counts. They overlap and are not additional packets.

This was a working radio-to-samples-to-software proof of concept outside the normal Wi-Fi band. It also showed why a failed first decoder pass should not always end the investigation: the original I/Q contained a recoverable message once the intended channel was isolated. This first processing pass ran offline on the laptop, including the actual Dart decoding code. These were our own synthetic pulse messages carried at those frequencies; no cellular or DECT traffic was decoded.

The 1.85 GHz tests produced no qualifying source-linked tone under the tested settings, including the additional high-gain check. No second GHz receiver independently witnessed that emission, so the failed detection does not isolate whether the source, tuning or receiver caused it. It remains an unresolved reception result at that point, not a failed message decoder or proof that the documented lower limit is impossible on every board. Antenna tuning, sensitivity and range were not calibrated.

The phone finally decoded the continuous stream live

We then integrated continuous recording and channel filtering into the Flutter app and tested it on a Samsung Galaxy S23 Ultra. The ESP32's native USB connection fed a Mac bridge, which forwarded the raw bytes to the phone through Android's USB debugging connection. The phone selected the channel, filtered the samples and decoded the pulse messages while reception was still running.

The validated live pipeline. ESP32 firmware filters and decimates the I/Q stream; the required Mac bridge forwards raw bytes to the phone, which selects the channel, decodes messages and saves recordings for later analysis. Conceptual diagram.

The distinction matters: the laptop did not send the phone a decoded answer or the expected message. Separate tone recordings established the channel settings before message decoding. Fresh synthetic 24-bit Princeton-style words were then transmitted over the air by HackRF, and the phone's results were compared with the source only afterward.

All three complete source-on trials near 2.0 GHz recovered the exact transmitted word, with 41, 42 and 44 qualified observations. Near 2.2 GHz, the three counts were 25, 27 and 33. The native-band controls near 2.437 GHz recovered 10 and 8. All ten complete transmitter-off controls returned zero. Each complete capture lasted about three seconds.

These are repeated observations of test messages, not unique devices, a packet-delivery percentage or a comparison with the earlier offline counts. In all six lower-band source-on trials, a host check confirmed that reception was still active after the phone reported its first message, roughly 0.95 seconds after the receive command. This establishes live processing; it is not a measurement of the decoder's processing time alone.

The retained acceptance run passed all 19 test cases: eighteen complete captures and one deliberate early Stop. The stopped capture correctly remained incomplete and provisional. The app checks transfer integrity and recording continuity before confirming final results, so an interrupted stream cannot quietly become a clean recording.

Actual phone screenshot of the Continuous I/Q setup screen. It shows the required Mac bridge, available capture settings and default values. The displayed defaults are not the exact calibrated channel settings used in every RF test.

The app offers three-, five- and ten-second captures and three output sample rates. The live acceptance campaign validated the three-second path at selected rates; it did not test every combination. Four selected lower-band recordings, including source-on and source-off cases, were saved, reopened through the phone library, recomputed and exported. Their raw bytes and results matched the retained originals.

Actual phone screenshot after reopening a saved 2.2 GHz recording: 750,215 samples, 1,466 valid transport frames, no reported breaks or issues, and 25 decoded observations. The visible word is a synthetic test value. This screen was captured after the live RF tests, not during transmission.

Independent checks found that the phone's raw recordings exactly matched the USB data retained on the laptop. The physical RF and navigation tests ran in an Android profile/AOT build. A release build using the same runtime code was subsequently installed and launched; it did not receive a separate RF sweep.

Which frequencies have we actually demonstrated?

We cannot conclude that every other frequency fails. The new phone workflow establishes three tested points. Earlier unsuccessful tests and frequencies we have not tested belong in different categories.

Frequency	Observed result	What it establishes
Near 2.0 GHz	Live phone decode: 3 of 3 source-on trials	Working controlled receive and decode at this point
Near 2.2 GHz	Live phone decode: 3 of 3 source-on trials	Working controlled receive and decode at this point
Near 2.437 GHz	Both live source-on controls decoded	Working native-band control for the same pipeline
433.92 MHz	Earlier controlled tests found no usable ESP32 message reception	The intended 433 MHz application remains unsuccessful
Near 1.85 GHz	No qualifying source-linked tone in the earlier tests	Unresolved; the source, tuning and receiver causes were not isolated
Other frequencies	Not validated with this live phone workflow	Untested, rather than ruled out

The successful source frequencies were nominally 2000.0965, 2200.105 and 2437.112 MHz, close to the rounded receiver settings above. They do not establish continuous coverage between those points. Upstream describes an experimental lower-frequency conversion range of approximately 1842–2209 MHz, but a documented tuning range is not a measured reception guarantee. The pinned receive-control documentation makes that qualification explicit.

What still limits the live prototype?

The laptop is still required. Direct Android USB/OTG support and a continuous wireless transport are not implemented in this path. Our app deliberately makes finite recordings; the three-second live trials and earlier ten-second USB tests do not establish unlimited loss-free operation.

Channel selection is another practical constraint. We used separately measured channel centers and a fixed filter with a 6 kHz cutoff on each side. The app did not discover arbitrary signals automatically. The unidentified antenna, signal strength, distance and receiver sensitivity were not calibrated, so this is not a range or weak-signal benchmark.

Finally, the new live test proves one controlled pulse protocol. It does not turn the phone into a general cellular, DECT or keyboard decoder, and it adds no ESP32 transmission capability. Saved recordings can be analyzed again; that is different from retransmitting them over the air.

The earlier complete remote-replay chain also stopped at the ESP32 stage

Before that follow-up, we had tested the intended workflow explicitly: a saved reference transmission played through HackRF, received by the ESP32, decoded on the phone, then sent through a LilyGO device with a CC1101 radio for a Flipper to hear.

The independent source checks worked. In the USB-driven run, the phone completed five one-second captures, including three transmitter-on gain settings and off-state controls, but produced no decoded Princeton frame.

The LilyGO's separate CC1101 transmitter could send the original reference file, and the Flipper decoded it at the higher programmed CC1101 amplifier setting. That proved the downstream transmitter and reference file were usable. It did not complete the chain: there was no ESP32-decoded phone record to forward.

The test replayed the supplied source, not a newly captured ESP32 result. No physical barrier operation was demonstrated. This distinction matters because combining several individually successful devices can make an incomplete end-to-end test look more successful than it was.

Native-band packet decoding did work

We then tested shorter signals in the radio's normal frequency neighbourhood. A HackRF transmitted controlled Bluetooth Low Energy packets over the air, the ESP32 captured them, and the phone decoded the samples.

Across a retained host-bench campaign, 96 snapshots yielded nine valid Bluetooth packets, with agreement between independent Python and Dart decoders. Transmitter-off and deliberately corrupted-checksum controls produced no accepted test packets. This established more than a peak on a chart: actual packet structure and integrity survived the path.

The keyboard demonstration went further. We constructed a staged trace using standard Bluetooth HID keyboard reports, including an A key, Shift+B and release events. The phone recovered all fourteen intended stages.

The cost of that success is revealing: 407 capture attempts were needed for fourteen advancing stages. The fourteen saved snapshots contained only 3.584 milliseconds of retained radio observation. The source repeated stages to help the receiver catch them.

That was a genuine over-air protocol demonstration, but it was not a live retail keyboard connection. It did not establish continuous capture of channel hopping, decryption of protected traffic or reliable monitoring of everyday typing.

We also tested recognition of reference advertising formats associated with Nordic's HID sample and a ZMK Corne keyboard configuration. The phone's positive batch contained 72 captures, seven valid packets and two advertised profile matches. Those were controlled reference-format transmissions, not proof that we could identify or inspect every commercial keyboard.

Investigating unknown protocols was useful, but uneven

The app grew a Protocol Lab: tools to inspect amplitude and frequency changes, try OOK or two-frequency decoding, adjust timing assumptions, compare repeated bit patterns and save notes alongside raw evidence.

To make the test more meaningful, new source payloads were generated after the decoders were fixed for that test. The expected message was used afterward to score the result, rather than being supplied to the decoder as a pattern to find.

Results varied by source and capture. With manual settings in the historical build 7 phone test, one frequency-shift-keyed source yielded the exact 64-bit payload in seven of twelve snapshots and a complete 128-bit frame in four. Another source yielded neither. An OOK source yielded five exact payloads but no complete frames.

Historical build 7 manual phone results. Each source had twelve snapshots. These are recovery counts from intermittent captures, not measured packet-loss rates or final receiver-v2 performance.

A later decoder revision reduced excessive rejection of sample regions around capture metadata. Reprocessing the same saved data improved the first source from seven to nine exact payload recoveries, and the second from zero to two, out of twelve each. Complete-frame counts remained four and zero.

Fresh phone tests with two new source payloads each recovered one complete frame in twelve snapshots under both decoder versions. Off-state controls produced no matching source payloads. The improvement on retained data was real, but it did not establish dependable capture in fresh phone runs.

The app therefore became a useful investigation aid. It did not automatically infer field meanings, reverse engineer arbitrary checksums or determine whether an unknown keyboard link was encrypted. A later experimental scanner was started, but it did not receive the controlled validation needed to count as an achieved capability.

What the investigation leaves us with

We finished several things: a repeatable native-band transmission experiment, real raw-sample capture, ten-second continuous USB recording, live phone filtering and message decoding near 2.0 and 2.2 GHz, a native-band control, recording storage and reopening, controlled Bluetooth decoding, staged keyboard-report decoding and a basic protocol investigation tool. These were distinct experiments, not one universal radio mode.

We did not finish the applications that motivated the broader experiment: dependable 433 MHz remote capture and replay through the ESP32's own radio, GPS reception, broadcast-FM listening or robust monitoring of arbitrary devices.

The reasons differed by experiment. A tuning command did not establish usable reception at the requested frequency. Our earlier phone captures covered very short intervals; the later USB path overcame that constraint without solving 433 MHz decoding. Some capture paths and analysis scripts needed correction. Protocol decoding required more than visual similarity, and successful staged demonstrations did not establish reliable observation of uncontrolled transmissions.

The published project gave us a working way to record controlled radio signals and recover messages in software, including at two frequencies below the normal Wi-Fi band. The phone integration now makes that a usable bench prototype: receive, filter, decode, save and reopen. It still needs a computer, selected settings and a known test protocol. That is a narrower achievement than a dependable general-purpose monitor or the 433 MHz product we originally wanted, but it is a practical result worth building on.

For me, the most durable result was the method: preserve the failed runs, keep positive and negative controls, and revise our claims when the evidence changes. AI assistance helped us produce firmware, analysis and an app quickly. Independent measurements were still what determined which parts of the story were true.

---

Evidence and scope: This account draws on retained code, raw recordings, reports and handovers from several sessions, reviewed on 7 October and extended by physical tests on 17 October 2026. Claims concern one ESP32-S3 and the tested settings. Counts are not sensitivity, range or packet-delivery benchmarks. Diagrams are explanatory; plots use actual measurements. The two new app images are unaltered screenshots of setup and a reopened recording. Transport integrity, independent source checks and phone decoding were verified separately. Real access-control keys and private device identifiers are excluded.