Nyan Box · Volume 6
Nyan Box Volume 6 — Drone RemoteID Detection
The FAA/EASA RemoteID broadcast spec, ASTM F3411, how the nyanBOX detects it, what is and isn't detectable, the RemoteID-watch workflow
Contents
1. About this volume
Drone RemoteID detection is one of the two capabilities nothing else in tjscientist’s lineup covers (the other is hidden-camera detection, Vol 7). This volume is the engineer-grade reference for it: what RemoteID actually is, the broadcast standard underneath it, how the nyanBOX picks it up, and — critically — the honest boundaries of what a small handheld can and can’t see.
RemoteID is sometimes oversold as “drone radar”. It is not. It’s a cooperative-broadcast detection system: it sees drones that choose to comply by broadcasting their ID. This volume is careful about that line throughout.
2. What RemoteID is — the regulatory backdrop
Remote Identification (RemoteID) is a regulatory requirement that most drones broadcast identifying information while flying — informally, “a digital license plate for drones.”
2.1 The rules
| Jurisdiction | Rule | Status |
|---|---|---|
| United States | FAA 14 CFR Part 89 — Remote Identification of Unmanned Aircraft | In force; compliance required for most drones operated in US airspace |
| European Union | EASA — Direct Remote Identification under EU 2019/945 + 2019/947 | In force; required for most classes |
| Other jurisdictions | Various — many following the FAA/EASA pattern | Patchwork; expanding |
2.2 What a compliant drone broadcasts
A RemoteID-compliant drone, while airborne, periodically broadcasts:
- Drone ID — a unique identifier (serial number or session ID)
- Drone position — latitude, longitude, altitude
- Drone velocity — speed + direction
- Operator/control-station position — where the pilot is (this is the privacy-sensitive part)
- Emergency status — if the drone is in an emergency state
- Timestamp
2.3 Two ways to comply
| Method | What it is | Detectable by nyanBOX? |
|---|---|---|
| Standard RemoteID | The drone broadcasts directly from the aircraft | Yes — this is what the nyanBOX detects |
| Broadcast Module | A separate add-on module broadcasts on behalf of a non-RID-native drone | Yes — same broadcast transports |
| (Network RemoteID — proposed/varies) | Reporting via internet rather than RF broadcast | No — there’s no RF to detect |
The nyanBOX detects the RF broadcast forms. It cannot detect a drone that complies purely via a network/internet method (where one exists), and it cannot detect a drone that isn’t broadcasting at all (non-compliant, or RemoteID disabled — see § 7).
3. ASTM F3411 — the broadcast standard
The technical standard underneath RemoteID is ASTM F3411 (“Standard Specification for Remote ID and Tracking”). The FAA’s Part 89 and EASA’s requirements both reference it. F3411 defines:
- The message format — the structure of the broadcast data (§ 5)
- The broadcast transports — Wi-Fi and Bluetooth methods (§ 4)
- The broadcast rate — typically ~1 Hz (once per second) minimum while airborne
- The data fields — exactly what’s in each message type
RemoteID — the layer cake
═══════════════════════════
┌─────────────────────────────────────────┐
│ FAA Part 89 / EASA 2019/945 │ ← the LAW
│ ("drones must broadcast RemoteID") │
├─────────────────────────────────────────┤
│ ASTM F3411 │ ← the STANDARD
│ (message format + transports + rate) │
├─────────────────────────────────────────┤
│ Wi-Fi Beacon │ Wi-Fi NAN │ BT4 │ BT5 │ ← the TRANSPORTS
│ (the actual RF the nyanBOX listens to) │
└─────────────────────────────────────────┘
The nyanBOX operates at the bottom layer — it listens
to the RF transports and decodes the F3411 message
format. It doesn't "know about" the law; it knows
about the packets.
The key engineering fact: RemoteID rides on ordinary Wi-Fi and Bluetooth transports. It’s not a new radio. That’s exactly why an ESP32 (which has Wi-Fi + BT) can detect it — and exactly why a generic Wi-Fi scanner sees the frames but doesn’t decode them as RemoteID unless it’s specifically built to (the nyanBOX is).
4. The four broadcast transports
ASTM F3411 defines (broadly) four ways the broadcast can be carried. All four are 2.4 GHz (and 5 GHz for some Wi-Fi modes, but the common case is 2.4 GHz):
| Transport | Carrier | How it works | nyanBOX detects? |
|---|---|---|---|
| Wi-Fi Beacon | 802.11 beacon frames | RemoteID data is embedded in vendor-specific information elements in beacon frames | Yes — ESP32 monitor mode |
| Wi-Fi NAN | Wi-Fi Neighbor Awareness Networking | RemoteID data in NAN service-discovery frames | Yes — ESP32 monitor mode (NAN is 2.4 GHz) |
| Bluetooth 4 Legacy | BT4 legacy advertising | RemoteID data in BLE legacy advertisement PDUs | Yes — ESP32 BLE |
| Bluetooth 5 Long Range | BT5 extended/coded-PHY advertising | RemoteID data in BT5 extended advertisements (coded PHY for range) | Partially — see § 7.3 |
The four transports, where they live in 2.4 GHz
═════════════════════════════════════════════════
2400 ──────────────────────────────────── 2483 MHz
│ │
BT advertising: ▲(2402) ▲(2426) ▲(2480) ch37/38/39
│ │ │
Wi-Fi beacon: └─ ch1 ─────┴─ ch6 ─────┴─ ch11 (+ others)
Wi-Fi NAN: mostly ch6 (2437) — the NAN "social channel"
A drone might use ANY of these. A complete RemoteID
watch needs to monitor Wi-Fi beacons across channels
AND BT advertising across ch37/38/39 — concurrently.
That's why the ESP32's dual Wi-Fi+BT radio matters.
4.1 Why the ESP32-WROOM-32U is the right radio for this
RemoteID detection needs Wi-Fi monitor mode AND Bluetooth advertising scan, ideally concurrent. The ESP32 (original, in the nyanBOX) has:
- Wi-Fi 2.4 GHz with monitor mode → catches Wi-Fi Beacon + NAN RemoteID
- Bluetooth 5.0 (BLE + Classic) → catches BT4 Legacy + (partially) BT5 Long Range RemoteID
It is, almost by accident, a near-ideal RemoteID-detection radio. The firmware time-slices Wi-Fi and BT (the single ESP32 radio can’t truly do both at the same instant), but the slice is fast enough to catch the ~1 Hz RemoteID broadcast rate.
5. The RemoteID message set
ASTM F3411 defines several message types. The ones that matter for detection:
| Message type | Contents | Why it matters |
|---|---|---|
| Basic ID | The drone’s unique ID (serial or session ID) + UA type | Identifies which drone |
| Location/Vector | Drone lat/lon/alt, speed, heading, vertical rate | Where the drone is + where it’s going |
| Authentication | Cryptographic auth data (optional) | Verifies the broadcast is genuine |
| Self-ID | Free-text description / operation intent | Operator-supplied context |
| System | Operator/control-station lat/lon, area of operation | Where the pilot is — privacy-sensitive |
| Operator ID | Operator registration ID | Who the operator is (registered) |
A RemoteID broadcast — what you actually receive
══════════════════════════════════════════════════
┌─ Basic ID ──────────────────────────────────────┐
│ UA Type: Quadcopter │
│ ID Type: Serial Number │
│ ID: 1581F4F7F1A2B3C4D5E6 (example) │
├─ Location/Vector ───────────────────────────────┤
│ Lat: 40.7128 Lon: -74.0060 (example) │
│ Alt: 120 m Speed: 8 m/s Heading: 245° │
│ Status: Airborne │
├─ System ────────────────────────────────────────┤
│ Operator Lat: 40.7115 Lon: -74.0048 │
│ → the PILOT is ~150 m southeast of the drone │
├─ Operator ID ───────────────────────────────────┤
│ Operator ID: FA3ABC123XYZ (example) │
└─────────────────────────────────────────────────┘
The nyanBOX OLED can't show all of this at once —
it shows the highlights (ID, drone position, operator
bearing) and lets you scroll. The full message set is
in RAM; pull it over USB-serial (Vol 9) for the
complete record.
5.1 The operator-position field is the consequential one
Most of RemoteID is “there’s a drone over there.” The System message’s operator position is different — it tells you where the human pilot is standing. For situational awareness / counter-surveillance, that’s the high-value field: if a drone is watching a site, RemoteID can tell you where the person controlling it is.
This is also the privacy-debated part of RemoteID — the rule deliberately exposes the operator’s location, and that’s controversial. The nyanBOX just decodes what’s broadcast; the ethics of acting on operator position is Vol 11 § 5 and § 9 below.
6. How the nyanBOX detects RemoteID
6.1 The detection pipeline
nyanBOX RemoteID detection pipeline
═════════════════════════════════════
┌──────────────────────────────────────────┐
│ ESP32 radio — time-sliced: │
│ Wi-Fi monitor mode (beacon + NAN) │
│ ↕ fast slice │
│ BT advertising scan (ch37/38/39) │
└────────────────┬─────────────────────────┘
│ raw frames
▼
┌──────────────────────────────────────────┐
│ RemoteID frame filter: │
│ - Wi-Fi: look for the RemoteID vendor- │
│ specific IE / NAN service ID │
│ - BT: look for the RemoteID service UUID │
│ / AD structure in advertisements │
└────────────────┬─────────────────────────┘
│ candidate RemoteID frames
▼
┌──────────────────────────────────────────┐
│ ASTM F3411 message decoder: │
│ parse Basic ID / Location / System / │
│ Operator ID message types │
└────────────────┬─────────────────────────┘
│ decoded drone records
▼
┌──────────────────────────────────────────┐
│ OLED display + RAM log: │
│ drone list, per-drone detail, operator │
│ bearing, RSSI trend │
└──────────────────────────────────────────┘
6.2 What the nyanBOX adds over a generic scanner
A generic Wi-Fi/BT scanner sees the frames. The nyanBOX:
- Knows the RemoteID frame signatures — the specific IEs, service UUIDs, AD structures
- Decodes the F3411 message format — turns raw bytes into “drone ID, position, operator location”
- Presents it as a drone watch — a purpose-built UI, not a raw frame dump
That decode-and-present layer is the entire value. It’s not new radio hardware; it’s the firmware knowing what RemoteID looks like.
6.3 RSSI as a proximity cue
The nyanBOX shows RSSI per detected drone. RSSI isn’t range (multipath, antenna orientation, drone TX power all corrupt it) — but RSSI trend is useful: a drone whose RSSI is rising is getting closer. Combined with the triple-NRF24 triangulation principle (Vol 3 § 8 — though RemoteID detection uses the ESP32 radio, not the NRF24s), you get a rough “warmer/colder” sense.
[FIGURE SLOT — Vol 6, § 6] Photo of the nyanBOX OLED running RemoteID watch, showing a detected drone with ID, position, and operator bearing. Source: vendor product page. Caption when filled: “Figure 6.1 — RemoteID watch detecting a compliant drone.”
7. What is and isn’t detectable
This is the honest-boundaries section. RemoteID detection is real and useful, but it is cooperative-broadcast detection, and the limits matter.
7.1 What the nyanBOX WILL detect
| Detectable | Why |
|---|---|
| RemoteID-compliant drones broadcasting nearby | They’re broadcasting on Wi-Fi/BT exactly to be detected |
| Drones with a Broadcast Module add-on | Same transports |
| The drone’s ID, position, velocity | It’s in the broadcast |
| The operator/pilot position | It’s in the System message |
| Multiple drones at once | The firmware lists all it hears |
7.2 What the nyanBOX will NOT detect
| Not detectable | Why |
|---|---|
| Non-compliant drones | If a drone isn’t broadcasting RemoteID at all, there’s no RF to hear. Older drones, DIY drones, deliberately-non-compliant drones — invisible. |
| Drones with RemoteID disabled / spoofed | RemoteID is enforced by regulation, not by physics. A drone that’s been modified to not broadcast (illegal, but possible) is invisible. |
| Network-RemoteID-only drones | If a jurisdiction allows internet-based reporting instead of RF broadcast, there’s no RF. |
| Drones beyond RF range | RemoteID broadcasts are low-power; a drone high up or far away may be below detection threshold. You detect cooperative and close, not regional surveillance. |
| Whether the broadcast is truthful | Position fields can be spoofed by a determined adversary. The Authentication message helps, but it’s optional and not always present. |
7.3 The BT5 Long Range partial-detection caveat
The original ESP32 (in the nyanBOX) has Bluetooth 5.0, but its support for BT5 extended advertising on the coded PHY (the “Long Range” mode) is limited compared to newer silicon (ESP32-C3/S3/C6). RemoteID broadcasts that use BT5 Long Range coded PHY may be partially or not detected by the nyanBOX. Wi-Fi Beacon, Wi-Fi NAN, and BT4 Legacy RemoteID are solidly detectable; BT5 Long Range is the soft spot. Verify the firmware’s actual BT5 coverage on the unit.
7.4 The honest summary
What RemoteID detection IS and ISN'T
══════════════════════════════════════
IS: "Is there a compliant drone broadcasting near me
right now, and if so, what's its ID and where's
the operator?"
ISN'T: "Is there ANY drone anywhere near me?"
(non-compliant drones are invisible)
ISN'T: "Drone radar / regional airspace surveillance"
(it's near-field, cooperative-broadcast only)
ISN'T: "Provably truthful drone tracking"
(position fields can be spoofed)
It's a genuinely useful situational-awareness tool
within those boundaries. Sold as more than that, it's
overhyped. The nyanBOX deep dive states the boundary
plainly so the capability is used for what it is.
8. The RemoteID-watch workflow
8.1 Stationary watch
1. Position the nyanBOX (antenna clear, ideally elevated)
2. Enter Drone RemoteID mode
3. The firmware time-slices Wi-Fi + BT, watching for
RemoteID broadcasts
4. Detected drones appear in a list — ID, RSSI, position
5. Select a drone → detail view: full position, velocity,
operator location, operator ID
6. Watch RSSI trend to sense approach/departure
7. (For a record: pull the RAM log over USB-serial —
the EEPROM can't store a long watch; Vol 9 § 4)
Battery: ~13.5 hours on the 2500 mAh cell (Vol 2 § 5.4) — a genuine all-day stationary watch.
8.2 Mobile sweep
Walk a site with RemoteID mode running — useful for “is anything watching this area” sweeps. RSSI trend as you move gives a rough bearing toward any detected drone.
8.3 Cross-referencing detections
A detected drone’s ID can be cross-referenced:
- Serial-number IDs → in some jurisdictions, against a registration database (the FAA’s, where accessible)
- Operator ID → against operator-registration records
- Position history → logged over time, shows the drone’s flight path
The nyanBOX gives you the detection; the cross-referencing is host-side work with the data you pulled off the device.
8.4 What the workflow is good for
| Use case | Fit |
|---|---|
| ”Is a drone surveilling this site?” | Good — for compliant drones |
| Privacy / counter-surveillance audit | Good — within the cooperative-detection limit |
| Situational awareness at an event/site | Good |
| Airspace enforcement / regulatory | Partial — you see compliant drones, not violators |
| Comprehensive drone defense | No — non-compliant drones are the threat, and those are invisible |
9. Legal + ethical posture
9.1 Receiving RemoteID is legal
RemoteID broadcasts are intentionally public — the entire regulatory point is that anyone can receive them. Detecting and decoding RemoteID is legal; it’s a designed-in capability. The nyanBOX’s RemoteID tool is passive RX — no transmission, no legal RF concern.
9.2 The ethical line is what you DO with it
The data includes the operator’s location. That’s a real person standing somewhere. Detecting that a drone’s pilot is at a given location is legal; what’s done next is an ethics question:
| Use | Posture |
|---|---|
| Situational awareness — “there’s a drone, operator’s that way” | Fine |
| Privacy audit — “is this venue being surveilled” | Fine |
| Logging for a security report | Fine, with appropriate data handling |
| Confronting / approaching the operator | Caution — that’s a human-interaction decision, not a technical one; de-escalation, not vigilantism |
| Harassing / interfering with a lawful operator | Not OK — and interfering with the drone itself (jamming) is illegal (Vol 11 § 3) |
9.3 The nyanBOX-specific note
The nyanBOX’s education framing presents RemoteID detection as a passive awareness tool — and that’s the right framing. It’s a “know what’s in your airspace” capability, not a “hunt the pilot” capability. Vol 11 § 5 carries the full posture.
10. Resources
RemoteID — regulatory + standard
- FAA Remote ID rule (14 CFR Part 89): https://www.faa.gov/uas/getting_started/remote_id
- FAA RemoteID overview: https://www.faa.gov/uas/getting_started/remote_id/drone_pilots
- EASA drone regulations: https://www.easa.europa.eu/en/domains/civil-drones
- ASTM F3411 (the broadcast standard): ASTM International — https://www.astm.org/f3411-22a.html
RemoteID — technical / community
- OpenDroneID (open-source RemoteID reference implementation — the canonical technical resource): https://github.com/opendroneid
- OpenDroneID receiver apps + protocol docs: https://github.com/opendroneid/receiver-android
ESP32 BT5 capability context
- ESP32 vs ESP32-C3/S3 Bluetooth 5 feature comparison: Espressif documentation
Sibling + cross-tool
- Hack Tools shared legal/ethics:
../../../_shared/legal_ethics.md - Vol 11 of this series — operational posture
End of Vol 6. Next: Vol 7 is the hidden-camera detection deep dive — the RF-fingerprinting theory, the 20+ camera-brand signature database, the false-positive landscape, and the sweep methodology.