ESP32 detectará un dron, pero no decodificará su vídeo

Dónde ESP32 sí puede funcionar

Conviene separar esta idea desde el principio en dos tareas muy distintas: detectar un dron y recibir su vídeo. En octubre de 2026, ESP32 parece una base razonable precisamente para un detector pasivo. En la publicación original en X, Michal Schwarz menciona experimentos con la placa y la posibilidad de aplicar trabajos previos de ingeniería inversa del firmware y los protocolos de DJI.

Para un detector, las capacidades de la placa son suficientes: puede escanear Wi-Fi y BLE, buscar Remote ID, comparar OUI de fabricantes, patrones de SSID y campos de servicio, y después seguir los cambios de RSSI. La documentación de Drone-Detector-V2 describe seis niveles de detección de este tipo y el recorrido de los canales 1 a 13 de la banda de 2,4 GHz. Ya no es un simple indicador de actividad de radio, sino una base para clasificar transmisores observados.

Otra fuente práctica, Open Drone ID Core C, incluye herramientas para codificar y decodificar mensajes Open Drone ID, además de ejemplos de receptores para ESP32. Los proyectos DroneRX y PK_SkySpy muestran la misma idea arquitectónica: ESP32 resulta útil cuando el propio dron transmite datos de identificación mediante un mecanismo de difusión compatible.

Con el vídeo, el límite es mucho más estricto. Los enlaces de radio avanzados de DJI usan variantes propietarias de OFDM en las bandas de 2,4 y 5,8 GHz, y las investigaciones publicadas describen canales descendentes de 20 MHz. En algunas mediciones, las señales DroneID ocuparon aproximadamente entre 9,38 y 10,91 MHz, algo que exige captura y sincronización precisas, no un simple sniffing de Wi-Fi.

El detector es viable; un receptor universal, no

La conclusión práctica es sencilla: ESP32 puede convertirse en un sensor pasivo y económico de presencia de drones, pero no en un receptor completo de vídeo DJI. Para trabajar a fondo en la capa física se necesita captura SDR, control de frecuencia y una implementación independiente de la demodulación del protocolo. La ingeniería inversa del firmware ayuda, pero no sustituye una cadena de radio adecuada.

Antes que el alcance, yo comprobaría la cobertura de detección durante el salto entre canales. Mientras ESP32 escucha una parte de la banda, un paquete corto puede aparecer en otra; el RSSI y las coincidencias de OUI también pueden clasificar erróneamente un dispositivo normal como dron. Por eso, un prototipo sólido debe combinar varias señales y no confiar en una única dirección MAC o SSID.

Lo más interesante no es intentar que una placa barata haga el trabajo de un SDR. El valor de ingeniería está en separar honestamente las capas: ESP32 detecta y clasifica indicadores de difusión accesibles, mientras un equipo de radio especializado analiza la señal propietaria. Esa frontera decidirá si el resultado es un sensor útil o solo un indicador de espectro ruidoso.

También analizamos el caso de Codex 5.2 en Raspberry Pi y cómo validar demostraciones técnicas sobre hardware real. Esto se relaciona con la ingeniería inversa de protocolos DJI, donde las conclusiones deben basarse en mediciones y pruebas reproducibles.