ESP32 Can Detect a Drone, but It Cannot Decode Its Video

Where ESP32 can genuinely help

I would separate this idea into two fundamentally different tasks from the start: detecting a drone and receiving its video feed. As of October 2026, ESP32 is a sensible platform for a passive detector. In the original post on X, Michal Schwarz mentions experiments with the board and the possibility of applying earlier work on reversing DJI firmware and protocols.

The board has enough capabilities for detection: it can scan Wi-Fi and BLE traffic, look for Remote ID, compare manufacturer OUIs, SSID patterns and service fields, then track RSSI changes. The Drone-Detector-V2 documentation describes six such detection layers and channel hopping across channels 1 through 13 in the 2.4 GHz band. This is already more than a simple RF activity indicator; it is a basis for classifying observed transmitters.

Another practical source, Open Drone ID Core C, includes tools for encoding and decoding Open Drone ID messages, as well as ESP32 receiver examples. DroneRX and PK_SkySpy illustrate the same architectural idea: ESP32 works well when a drone broadcasts identification data through a compatible broadcast mechanism.

The boundary is much stricter for video. Advanced DJI radio links use proprietary OFDM variants in the 2.4 and 5.8 GHz bands, while published research describes 20 MHz downlink channels. In some measurements, DroneID signals occupied roughly 9.38 to 10.91 MHz, which calls for precise capture and synchronization rather than ordinary Wi-Fi sniffing.

A detector is feasible; a universal receiver is not

The practical conclusion is straightforward: ESP32 can become an inexpensive passive sensor for drone presence, but not a full DJI video receiver. Deep physical-layer work needs SDR capture, frequency control and a separate protocol demodulation implementation. Firmware reversing is useful here, but it cannot replace the appropriate RF front end.

I would test detection completeness during channel hopping before testing range. While ESP32 listens to one portion of the band, a short packet can appear elsewhere; RSSI values and OUI matches can also falsely classify an ordinary device as a drone. A robust prototype should therefore combine several signals instead of trusting one MAC address or SSID.

The most interesting part is not trying to make an inexpensive board perform SDR work. The engineering value lies in honestly separating the layers: ESP32 detects and classifies accessible broadcast indicators, while specialized RF hardware analyzes the proprietary signal. That boundary determines whether the result is a useful sensor or merely a noisy spectrum indicator.

We also examined the Codex 5.2 case on Raspberry Pi and how to validate technical demos on real hardware. This parallels DJI protocol reverse engineering, where conclusions must rely on measurements and reproducible tests.