Open Drone ID Core C Library

The opendroneid-core-c library supports multiple regional Remote ID standards. Developers should choose the implementation based on the target operating region:

United States

Follows ASTM F3411 (v1.0 and v1.1) and the ASTM F3586 Means of Compliance (MoC). The FAA accepts the F3586 MoC as an acceptable means of demonstrating compliance. Key requirements include mandatory transmission of UA dynamic position, track direction, and horizontal speed.

European Union

Complies with ASD-STAN prEN 4709-002 Direct Remote Identification, which is designed to meet EU Commission Regulations 2019/945 and 2019/947. It is compatible with ASTM F3411 v1.1.

Japan

Requires broadcast Remote ID. Key characteristics include:

• Mandatory use of both Serial Number and a Civil Aviation Authority provisioned ID.
• Mandatory transmission of two Basic ID messages.
• Mandatory Authentication messages (signatures).
• Bluetooth 5 Long Range is a mandatory transmit method.

China

Uses the GB 46750-2025 standard, which is an independent protocol and is not wire-compatible with ASTM F3411.

• It requires both a 20-character serial number and an 8-character real-name registration ID (UIN).
• Mandatory operator/GCS location and GNSS accuracy levels.
• Implementation is found in the libopendroneidcn/ repository.

GB 46750-2025 is not wire-compatible with ASTM F3411. If you are building a receiver or transmitter, you must implement the specific protocol requirements for the target standard.

Key architectural differences include:

• Wire Format: ASTM F3411 uses 6 message types with 25-byte fixed lengths. GB 46750-2025 uses a single variable-length packet with a flag-bitmask chain.
• Identity: ASTM F3411 uses either a Serial Number or Session ID. GB 46750-2025 requires both the Serial Number (SN) and the Unique Identification Number (UIN/registration ID).
• Operator Location: Optional in ASTM F3411, but mandatory in GB 46750-2025 (including GCS position, type, and altitude).
• Accuracy Reporting: GB 46750-2025 defines 4 specific accuracy levels (horizontal, vertical, speed, and timestamp).
• Broadcast Transport: ASTM F3411 supports BT4, BT5, Wi-Fi NaN, and Wi-Fi Beacon. GB 46750-2025 supports Bluetooth 5.0+ and Wi-Fi (2.4 GHz / 5.8 GHz).
• Coordinate Systems: ASTM F3411 uses WGS-84 only. GB 46750-2025 supports both WGS-84 and CGCS2000.
• Drone Classification: GB 46750-2025 mandates drone classification (Micro to Large).

GB 46750-2025 broadcast-mode RID packets use a flag-bitmask chain structure rather than TLV tags. The packet is composed of a header, a variable-length flag region, and a data region.

Packet Layout

Flag Chain Rules

• Content Flags: Bits 1–7 of each flag byte signal the presence of specific fields.
• Extension Flag: Bit 0 (LSB, 0x01) of a flag byte indicates if the chain continues. 1 means the next byte is also a flag byte; 0 means the flag region has ended.
• Data Mapping: Omitted fields (where the flag bit is 0) consume zero bytes in the data region.

┌──────────┬──────────┬──────────┬───────────────────┬──────────────────────┐
│  Type    │ Version  │ DataLen  │   Flag Bytes      │     Data             │
│  1 byte  │ 1 byte   │ 1 byte   │   1–3 bytes       │   N bytes (≤200)     │
│  0xFF    │          │  1–200   │                   │                      │
└──────────┴──────────┴──────────┴───────────────────┴──────────────────────┘

The SDK operates using two distinct types of data structures: nominal (non-encoded) structures and encoded structures.

1. Nominal Data (*_data): These are the human-readable/logical representations of the information (e.g., ODID_BasicID_data). You populate these structures with the actual information you want to transmit.
2. Encoded Data (*_encoded): These are the serialized formats ready for transmission (e.g., ODID_BasicID_encoded).

Workflow for Transmitters: Populate a *_data structure $\rightarrow$ Call an encode* function $\rightarrow$ Transmit the resulting *_encoded data over a broadcast method (Bluetooth, Wi-Fi, etc.).

Workflow for Receivers: Receive *_encoded data $\rightarrow$ Call a decode* function $\rightarrow$ Access the information via the resulting *_data structure.

// Example workflow logic
ODID_BasicID_data myData = { ... };
ODID_BasicID_encoded myEncoded;

// Encoding for transmission
int status = encodeBasicIDMessage(&myEncoded, &myData);

// Decoding after reception
ODID_BasicID_data receivedData;
status = decodeBasicIDMessage(&receivedData, &myEncoded);