Remote ID, ESP32s, and the Packet Trail to Friend or Foe

The talk opens with an Android airspace app that failed to pick up the presenters' own DJI drone. Investigating Remote ID showed that this drone did not broadcast it, so the team fell back on Wi-Fi SSIDs and manufacturer OUIs as weaker clues. They built a simulator to test detection against known traffic and found that Remote ID arrives as several separate packets, so partial captures are common.

The sensor work moved to ESP32 boards. A C5 was dropped because switching to 5 GHz added delays too long for continuous scanning, so the team standardized on ESP32-S3 nodes. Firmware updates over a single USB link failed on one board, which turned out to be a loose pin, and the hardware later moved to a locally fabricated PCB. A nightly AI-assisted search grew the signature list to hundreds of manufacturers. Bluetooth signal strength proved unreliable for triangulation, so the scoring favored agreement across several packets and sensors, with confidence that expires over time.

The main takeaway is that one packet, one SSID or one OUI should not drive an alert, since those fields can be spoofed and captures are often incomplete. A live demo showed the badges and the Android app detecting a real drone. The presenters also noted that some commercial tools missed certain drone types, and said the hardware and code are planned for public release after the conference.