CORRECTION (September 2026): an earlier version of this guide implied a standard RTL-SDR Blog V4 dongle could receive 2.4 GHz and 5.8 GHz drone bands directly. It cannot (manufacturer specification: up to 1.766 GHz). The guide now states the additional RF hardware required.
An ESP32 hears Bluetooth for an afternoon. A Raspberry Pi plus a software-defined radio turns drone listening into a permanent, searchable log — and once you add the correct RF front-end for the 2.4/5.8 GHz bands, it hears the Wi-Fi-NAN broadcasts the ESP32 cannot touch and, with dedicated tools, the DJI-specific transmissions that predate standardised Remote ID. This is the build we recommend when “weekend toy” becomes “I want a permanent sensor on my roof”.
The architecture in one paragraph
A common RTL-SDR dongle tops out near 1.766 GHz, so it cannot tune the 2.4 GHz and 5.8 GHz bands most drones use directly. Hearing those bands takes additional RF front-end hardware — a downconverter or a purpose-built receiver — and that extra link is where most DIY builds fail. This guide walks through the architecture with that limitation stated up front. Different decoders pull different layers out of the same antenna: Wi-Fi NAN Remote ID broadcasts, and — with dedicated tools — the DJI drone-to-controller protocol that carries DroneID data. The Pi logs everything with timestamps, so you build a searchable record of your local airspace rather than a scrolling console.
Parts and software
- Raspberry Pi 4 (2 GB is plenty) + power + SD card — $55–75
- RTL-SDR Blog V4 dongle — around $40; covers up to 1.766 GHz only
- Required for the 2.4/5.8 GHz drone bands: an RF front-end — a downconverter or a purpose-built 2.4 GHz receiver. Pricing varies by hardware; budget it as its own line item, because this is the cost most DIY builds forget
- Decoders: the dji_droneid project decodes DJI DroneID from SDR samples; the WarDragon ecosystem documents full reference builds combining hardware and software
- Optionally: a preamp and a proper 2.4 GHz antenna — the single biggest range upgrade
The honest part: what this build asks of you
This is a tinkerer’s project, not an appliance. The SDR decoders are research-grade: they need specific sample rates, they are sensitive to dongle drift and temperature, and decoding works best on DJI OcuSync-era links — newer links and other manufacturers shift the goalposts. Expect to read GitHub issues, adjust gain staging, and accept that some flights decode and some do not. Our failure-mode shortlist, from community experience and our own bench time: RTL-SDR counter drift killing FC32 decoding after warm-up (thermal, not software); USB ports on the Pi sharing bandwidth with the dongle — use a powered hub; and scheduling: decoding is CPU-hungry, so a Pi 4 with active cooling beats a Pi 3 by a mile.
Making it a 24/7 sensor
- Run the decoder as a systemd service so it survives reboots and crashes
- Log detections to SQLite or JSON lines with a timestamp — after a month you will have the most interesting dataset on your street
- Push detections over MQTT to Home Assistant — our MQTT output doc shows the payload shape and a working automation
- Put the Pi on a UPS hat; SDR decoders hate dirty shutdowns
| Compared to the ESP32 build | Raspberry Pi + SDR |
|---|---|
| Broadcasts heard | Bluetooth (via co-process) + Wi-Fi NAN + DJI protocol |
| Duty cycle | 24/7 logging, unattended |
| Skill required | Linux command line comfort |
| Base cost (excl. 2.4/5.8 GHz front-end) | Roughly $100–150; the required front-end is priced separately |
References: proto17/dji_droneid (541 stars, DJI DroneID decoding) · OpenDroneID · WarDragon ecosystem documentation. All community projects, checked 2026-09-11 — capabilities move fast, read their current READMEs.
Research-grade decoders: results vary by link type and firmware. Not a security product.