Since 2024 in the EU and 2023 in the US, every drone over 250 g operating beyond visual line of sight has to broadcast Remote ID — an electronic licence plate identifying the operator and the drone. That covers every Overwatch mission. We've made Remote ID a first-class setting in the app so operators can't forget to configure it.

What Remote ID is, briefly

Remote ID is a drone's live broadcast of its identifying information while in flight. The broadcast includes the operator's registered ID (from EASA or FAA registration), the drone's UAS serial number, position, altitude, velocity, and takeoff location. Anyone with a standard Remote ID receiver app (including the regulator's inspection app) can read the broadcast from a few hundred metres away and identify who is operating the drone.

The regulatory framework covers:

  • EU: Class C1–C3 drones under EU 2019/945 and 2019/947 must broadcast Direct Remote ID (DRI) over WiFi or Bluetooth. Enforcement started January 2024. Covers most commercial drones.
  • US: FAA Part 89 requires Remote ID for any drone requiring FAA registration (>250 g or operated commercially). Enforcement started September 2023.
  • UK: CAA is adopting the EU model broadly; specifics being finalised.

Operating a covered drone without Remote ID is a legal violation. For gov/defence/SAR customers, that's not a risk they can take — the reputational and operational cost of a regulator finding out they flew non-compliant is much higher than the cost of configuring the feature correctly.

How it works on our two platforms

Parrot ANAFI UKR (AirSDK): Remote ID broadcast is built into the drone's firmware. The operator ID is configured via the Parrot app or injected through the mission package at build time. Overwatch's mission packager passes the operator ID through when it generates the AirSDK archive.

PX4 custom drones (Holybro X500 V2): PX4 supports Direct Remote ID via the flight controller's built-in WiFi/Bluetooth broadcast. The ADSB_RID_* parameters are configured at drone commissioning time with the operator's registered ID. For regions where PX4's built-in DRI doesn't satisfy local regulator requirements, an external beacon module (uAvionix pingRID, Dronetag Beacon) plugs into the Pixhawk's UART and takes over the broadcast.

In both cases, the drone is doing the actual broadcasting. What Overwatch needs to do is make sure the operator ID is configured correctly before anything flies.

The setting

In Overwatch's Settings panel (Cmd+,), there's a section labelled Remote ID (Regulatory) with two fields:

  • Operator ID (EASA / FAA) — the unique ID from your UAS operator registration. Format varies by regulator; EASA uses a country-prefixed alphanumeric string, the FAA uses a numeric registration number.
  • UAS Serial Numbers (drone-id=serial, one per line) — maps each drone in your fleet to its UAS serial number. The mission packager uses this for AirSDK builds; PX4 fleets pull the serial from the Pixhawk at commissioning time.

Values are persisted encrypted via macOS safeStorage (backed by Keychain). On app restart, they're loaded into AppState and pushed to the server process as environment variables for the mission packager.

Below the fields there's a reminder link: "Register at FAA DroneZone (US) or your national UAS registry (EU)." The operator has the information they need to get the ID if they don't already have one.

The pre-flight check

Configuring the setting isn't enough — operators have to remember to do it, and a legal-compliance feature that relies on the operator remembering is a feature that regularly fails. Remote ID is therefore one of the eight health checks in the Pre-Flight Health Panel.

Before the Launch button can be clicked, the panel reads the configured Operator ID:

  • If blank or whitespace: check shows red with message "no Operator ID — see Settings"
  • If configured: check shows green with message "op <your-operator-id>"

A red Remote ID check blocks the Launch button. The operator can override (the panel's OVERRIDE field) if they have a documented reason, but the override is audit-logged and a supervisor reviewing the log will see it.

The idea is to turn a legal-compliance requirement into an operational habit. Operators launch a mission — the panel shows them what's not configured — they fix it once. Next mission, the panel's still there, still checking, so the chance of someone eventually flying with a blank operator ID is close to zero.

What Overwatch doesn't verify

Overwatch verifies that the Operator ID is configured and that the correct ID is handed off to the drone via the mission package or PX4 parameters. It does not verify that the ID itself is valid — that is, it can't tell that a typo'd operator ID wouldn't be recognised by the regulator's inspection app.

That verification is drone-by-drone, at commissioning time, with an actual Remote ID receiver. A second phone or a laptop running an OpenDroneID receiver app, positioned within ~10 m of the flying drone, reading the broadcast and confirming the operator ID matches what's in Settings. It's a five-minute test per drone; done once per commissioning, then the Settings-configured ID is the source of truth for every subsequent flight.

What's next — Network Remote ID

The EU is moving toward a Network Remote ID model in addition to Direct Remote ID — drones registering their broadcasts with a central server so regulators can monitor airspace remotely, not just by walking to the drone with a receiver. Overwatch is agnostic to this; the operator-hosted broadcast server is a small Phase C addition when the regulatory framework requires it. For now, Direct Remote ID covers every jurisdiction we operate in.

If your deployment has a specific regulatory constraint we haven't captured — a local CAA rule, a national UAS registry integration, a hardware beacon we should validate against — get in touch. Compliance is drone-by-drone and jurisdiction-by-jurisdiction; we want to hear about the specific rules that apply to your operation.