Every counter-drone product on the market will tell you it receives Remote ID. That is the easy half. The FAA rule that made broadcast Remote ID mandatory also created a far more interesting signal: the drones that are flying near you and not broadcasting it. A receiver that only logs compliant aircraft is, by construction, blind to exactly the ones worth looking at. This is how the GridDown Secure Messenger firmware handles both — and you can flash it onto a handheld radio, from your browser, in about a minute.
What broadcast Remote ID actually is
ASTM F3411 — the standard behind the FAA's broadcast Remote ID requirement — is deliberately humble technology. A drone transmits a short, unencrypted, self-describing message over ordinary 2.4 GHz radio. No subscription, no network, no cooperation from the operator required to receive it. Anyone within range with the right receiver can read it.
The messages are fixed-size and structured. Each one is exactly 25 bytes, and the type is carried in the high nibble of the first byte:
- Basic ID — the UAS serial number or session identifier
- Location — position, altitude, height above takeoff, speed, heading
- Authentication — optional signature data
- Self ID — a free-text operator description of the flight
- System — the operator or takeoff location
- Operator ID — the registered operator identifier
- Message Pack — several of the above bundled into one frame
Those messages arrive over four different transports, and a receiver that only listens to one of them will miss aircraft: Wi-Fi beacon frames, Wi-Fi NAN, Bluetooth LE legacy advertisements, and BLE long-range coded PHY. Different manufacturers made different choices. A serious receiver watches all four.
The signal everyone else discards
Here is where a Remote ID receiver stops being a compliance logger and starts being a sensor.
Most consumer and prosumer drones fly on a control link in the 900 MHz band, separate from the 2.4 GHz Remote ID broadcast. Those are two independent observations of the same aircraft, and comparing them produces three distinct situations rather than one:
- Remote ID only — a compliant aircraft, identity known, nothing unusual. This is the case every product on the market handles.
- Correlated — a Remote ID broadcast and a 900 MHz control link that agree. Two independent sensors confirming each other, which raises confidence in both.
- No Remote ID — a 900 MHz control link present with no corresponding Remote ID broadcast at all.
That third case is the one the firmware escalates as the highest-interest condition, and it is worth being precise about why. It does not prove hostile intent. It means one of a small set of things is true: the aircraft predates the requirement, its Remote ID module has failed, the operator has disabled it, or the aircraft was never meant to be identifiable. Every one of those is more interesting than a compliant flight, and none of them is visible to a receiver that only counts Remote ID packets.
The logic is a straightforward consequence of hearing both bands at once. A device that only listens on 2.4 GHz cannot form the comparison, because the absence of a Remote ID broadcast is indistinguishable from an empty sky. You need a second, independent observation to know that something is up there.
Sharing the radio honestly
There is an engineering problem hiding in this. The same handheld device is also an encrypted LoRa messaging radio, and that is its primary job. Remote ID scanning cannot be allowed to starve it.
The firmware duty-cycles the scan and — this is the part that matters — reports the duty cycle it achieved alongside the one that was requested. On a small embedded device the two are not always the same: a BLE scan window can come back shorter than asked for when the radio is busy. Reporting only the requested figure would be a comfortable lie. Tracking up to 16 concurrent aircraft, on four transports, while keeping a mesh messaging link alive, requires knowing when you are actually falling behind.
Read the code, then flash it
All of the above is verifiable, because the firmware is free software under the GNU General Public License v3.0 or later and the complete source is public. The parser, the correlation logic, the duty-cycle accounting — all of it is there to be read, audited, criticised, or forked. There is no licence key, no account, and no paid tier.
Two things make that claim more than a gesture. The host test harness compiles the actual Remote ID parser rather than a re-implementation of it, so a passing test suite is evidence about shipping code rather than about a convenient copy. And because the source is published, the firmware is released from the Export Administration Regulations under 15 CFR §§ 734.3(b)(3) and 734.7 — anyone, anywhere, can obtain and build it.
The cryptography is standard and published throughout: AES-256-GCM, SHA-256, HMAC-SHA256, PBKDF2, HKDF, and ECDH on NIST P-256, all via mbedTLS. No proprietary algorithms, nothing unpublished, nothing you have to take on faith.
Why this is a radio and not an appliance
A dedicated Remote ID receiver is a box you carry in addition to everything else. This is firmware on a device you would already be carrying for encrypted off-grid messaging — which also does 900 MHz drone scanning, acoustic gunshot detection, and RF jamming detection. Detections bridge into a map alongside team positions, so an aircraft with no Remote ID shows up in the same picture as everything else rather than on a separate screen nobody is watching.
Remote ID is a genuinely well-designed regulation from a sensing perspective: it created a free, open, unencrypted, cooperative signal that anyone can receive. The interesting question was never whether you can read it. It is what you conclude when it is missing.
Flash It Yourself
The GridDown Secure Messenger firmware is live, free, and open source. Read the source on GitHub, or write it to a supported handheld over USB straight from your browser — no toolchain, no account, no waitlist.
See the Secure Messenger