ESP32 erkennt eine Drohne, dekodiert aber kein Video

Wo ESP32 tatsächlich geeignet ist

Ich würde diese Idee sofort in zwei grundverschiedene Aufgaben trennen: eine Drohne erkennen und ihren Videostream empfangen. Stand Oktober 2026 ist ESP32 vor allem als Basis für einen passiven Detektor sinnvoll. Im ursprünglichen Beitrag auf X schreibt Michal Schwarz über Experimente mit dem Board und die Möglichkeit, frühere Arbeiten zum Reverse Engineering von DJI-Firmware und -Protokollen anzuwenden.

Für einen Detektor reichen die Fähigkeiten des Boards aus: Es kann WLAN und BLE scannen, nach Remote ID suchen, Hersteller-OUIs, SSID-Muster und Servicefelder abgleichen und anschließend RSSI-Änderungen verfolgen. Die Dokumentation von Drone-Detector-V2 beschreibt sechs solcher Erkennungsebenen sowie das Durchlaufen der Kanäle 1 bis 13 im 2,4-GHz-Band. Das ist bereits mehr als ein einfacher Indikator für Funkaktivität, sondern eine Grundlage zur Klassifizierung beobachteter Sender.

Eine weitere praktische Quelle, Open Drone ID Core C, enthält Werkzeuge zum Kodieren und Dekodieren von Open-Drone-ID-Nachrichten sowie Beispiele für ESP32-Empfänger. Die Projekte DroneRX und PK_SkySpy zeigen denselben Architekturgedanken: ESP32 ist dort praktisch, wo die Drohne selbst Identifikationsdaten über einen kompatiblen Broadcast-Mechanismus aussendet.

Bei Video verläuft die Grenze deutlich strenger. Fortschrittliche DJI-Funkstrecken nutzen eigene OFDM-Varianten in den Bereichen 2,4 und 5,8 GHz; veröffentlichte Untersuchungen beschreiben 20 MHz breite Downlink-Kanäle. In einzelnen Messungen belegten DroneID-Signale ungefähr 9,38 bis 10,91 MHz. Das erfordert präzise Erfassung und Synchronisation, nicht gewöhnliches WLAN-Sniffing.

Ein Detektor ist möglich, ein Universalempfänger nicht

Das praktische Fazit ist einfach: ESP32 kann zu einem günstigen passiven Sensor für die Anwesenheit von Drohnen werden, aber nicht zu einem vollwertigen DJI-Videoempfänger. Für tiefe Arbeit auf der physikalischen Schicht braucht es SDR-Erfassung, Frequenzsteuerung und eine eigene Implementierung der Protokolldemodulation. Firmware-Reverse-Engineering ist dabei hilfreich, ersetzt aber keine geeignete Funkkette.

Ich würde vor der Reichweite zunächst die Vollständigkeit der Erkennung beim Kanalwechsel prüfen. Während ESP32 einen Teil des Bandes abhört, kann ein kurzes Paket auf einem anderen erscheinen; auch RSSI und eine OUI-Übereinstimmung können ein gewöhnliches Gerät fälschlich als Drohne klassifizieren. Ein belastbarer Prototyp sollte deshalb mehrere Merkmale kombinieren, statt nur einer MAC-Adresse oder SSID zu vertrauen.

Das Interessanteste ist nicht der Versuch, ein preiswertes Board die Arbeit eines SDR erledigen zu lassen. Der technische Wert liegt gerade in der ehrlichen Trennung der Ebenen: ESP32 erkennt und klassifiziert verfügbare Broadcast-Merkmale, während spezialisierte Funktechnik das proprietäre Signal analysiert. Diese Grenze entscheidet darüber, ob ein nützlicher Sensor oder nur ein verrauschter Spektrumanzeiger entsteht.

Wir haben auch den Fall Codex 5.2 auf Raspberry Pi untersucht und erläutert, wie sich technische Demos auf realer Hardware prüfen lassen. Das knüpft an das Reverse Engineering von DJI-Protokollen an, bei dem Schlussfolgerungen auf Messungen und reproduzierbaren Tests beruhen müssen.