This repository provides a C-code function library for encoding and decoding (packing/unpacking) Open Drone ID messages, as the format is defined in the ASTM F3411 Remote ID and the ASD-STAN prEN 4709-002 Direct Remote ID specifications. See further details in the specifications section below.
Please note that both specifications have been updated during the first half of 2021. The ASD-STAN specification has been published but the ASTM specification is still being finalized (December 2021). The code available in this repository is already compliant with these updates.
The opendroneid-core-c code is meant for implementations that will broadcast the Remote ID information via Bluetooth or Wi-Fi. If you are looking for code related to Network Remoted ID (via the internet), please take a look at https://github.com/interuss and https://github.com/uastech/standards.
Work is ongoing by the IETF DRIP (Drone Remote ID Protocol) task force to define how security could be supported in the context of the ASTM Remote ID specification: https://datatracker.ietf.org/wg/drip/documents/ and https://github.com/ietf-wg-drip.
MAVLink messages for drone ID are available at https://mavlink.io/en/messages/common.html#OPEN_DRONE_ID_BASIC_ID and documentation on how to use them is available at https://mavlink.io/en/services/opendroneid.html.
For an example Android receiver application supporting Bluetooth and Wi-Fi, see https://github.com/opendroneid/receiver-android.
Currently there is no open source iOS receiver application for Apple devices. However, reception of Bluetooth 4 Legacy Advertising drone ID signals have been demonstrated to work on iOS. Apple currently does not expose suitable APIs to receive any other transmission method for drone ID signals than BT4 legacy advertising. I.e. current versions of iOS (up to and including 15) do not support receiving BT5 Long Range + Extended Advertising, Wi-Fi NaN nor Wi-Fi Beacon.
Examples on how to use the WireShark PC application to pick up and dissect open drone ID messages are available here: https://github.com/opendroneid/wireshark-dissector.
The ESP32 transmitter example code also contains code for receiving drone ID signals on ESP32 HW.
An example library for transmitting Open Drone ID signals from ESP32 HW can be found at https://github.com/sxjack/uav_electronic_ids. The implementation supports simultaneous transmission via Bluetooth Legacy Advertising, Wi-Fi NaN and Wi-Fi Beacon.
Please note that the ESP32 HW only supports transmitting Bluetooth Legacy Advertising signals. Bluetooth Long Range and Extended Advertising are not supported. Please check if this is sufficient to comply with the rules that apply in the area in which you are flying (most likely it is not. See below). The ESP32-C3 and ESP32-S3 chips will both support Long Range and Extended Advertising, but these have not yet been tested.
A Wi-Fi NaN transmitter implementation for Linux is available here. Better documentation is needed on what exact HW + SW environment this is functional. Functions for creating suitable Wi-Fi Beacon frames have been added to wifi.c, but those are currently not used by the sample sender application.
A simple application for sending static drone ID data via Bluetooth 4 and 5 and via Wi-Fi Beacon is available here. This has tested to work reasonably okay on one CometLake motherboard and partly okay on RaspberryPi 3B and 4B HW.
Transmitter implementations for Bluetooth 4 and 5, based on either the TI CC2640 or the nRF52480 SoCs are known to exist, but so far none have been open sourced. Please open an issue if you have an implementation you are willing to share. A new repository under opendroneid can be made.
To build the library and the sample app on Linux:
sudo apt-get install libgps-dev libnl-genl-3-dev
git submodule update --init
mkdir build && cd build
cmake ../.
make
The outputs will be libopendroneid/libopendroneid.so and the test/odidtest sample application.
The sample application will do a test encode/decode, then continuously generate sample messages.
The intended architecture is to take whatever input you wish, and to put it into the nominal structures as defined in libopendroneid/opendroneid.h.
Some embedded systems might require a smaller memory footprint than what by default is used by opendroneid-core-c. The following compile time options exists for reducing the memory consumption:
-
ODID_AUTH_MAX_PAGES is by default configured to support 16 pages/messages of authentication data. See the beginning of opedroneid.h. If authentication messages are not used, this value can be configured between 1 and 16, e.g. by adding
-DODID_AUTH_MAX_PAGES=1when calling cmake. -
When including MAVLink in the build (see below), if MAVLink's virtual channel functionality is not used, some memory can be saved by defining MAVLINK_COMM_NUM_BUFFERS to be equal to 1, before including mavlink_types.h See further details in the beginning of mav2odid.c.
MAVLink OpenDroneID support is included by default.
To disable, use the BUILD_MAVLINK parameter, i.e.:
cmake -DBUILD_MAVLINK=off .
MAVLink support requires the mavlink_c_library_v2 to be installed in the respective folder
The Wi-Fi NaN example implementation is built by default.
To disable, use the BUILD_WIFI parameter, i.e.:
cmake -DBUILD_WIFI=off .
It requires the libgps, libnl-3 and libnl-genl-3 support. Install the dependencies on your build host, e.g. on Debian/Ubuntu use
sudo apt-get install libgps-dev libnl-genl-3-dev
If available, the Wi-Fi reference implementation will link against libnl-tiny instead of libnl*-3 if available.
These are nominal (non-encoded) structures:
ODID_BasicID_data
ODID_Location_data
ODID_Auth_data
ODID_SelfID_data
ODID_System_data
ODID_OperatorID_data
ODID_MessagePack_data
The SDK functions will encode to (or decode from) the following structures:
ODID_BasicID_encoded
ODID_Location_encoded
ODID_Auth_encoded
ODID_SelfID_encoded
ODID_System_encoded
ODID_OperatorID_encoded
ODID_MessagePack_encoded
Once you have the encoded data, then you are ready to assemble and transmit over any of the acceptable broadcast methods in Open Drone ID.
The primary SDK calls are the following:
int encodeBasicIDMessage(ODID_BasicID_encoded *outEncoded, ODID_BasicID_data *inData);
int encodeLocationMessage(ODID_Location_encoded *outEncoded, ODID_Location_data *inData);
int encodeAuthMessage(ODID_Auth_encoded *outEncoded, ODID_Auth_data *inData);
int encodeSelfIDMessage(ODID_SelfID_encoded *outEncoded, ODID_SelfID_data *inData);
int encodeSystemMessage(ODID_System_encoded *outEncoded, ODID_System_data *inData);
int encodeOperatorIDMessage(ODID_OperatorID_encoded *outEncoded, ODID_OperatorID_data *inData);
int encodeMessagePack(ODID_MessagePack_encoded *outEncoded, ODID_MessagePack_data *inData);
int decodeBasicIDMessage(ODID_BasicID_data *outData, ODID_BasicID_encoded *inEncoded);
int decodeLocationMessage(ODID_Location_data *outData, ODID_Location_encoded *inEncoded);
int decodeAuthMessage(ODID_Auth_data *outData, ODID_Auth_encoded *inEncoded);
int decodeSelfIDMessage(ODID_SelfID_data *outData, ODID_SelfID_encoded *inEncoded);
int decodeSystemMessage(ODID_System_data *outData, ODID_System_encoded *inEncoded);
int decodeOperatorIDMessage(ODID_OperatorID_data *outData, ODID_OperatorID_encoded *inEncoded);
int decodeMessagePack(ODID_UAS_Data *uasData, ODID_MessagePack_encoded *pack);
Specific messages have been added to the MAVLink message set to accommodate data for Open Drone ID implementations:
https://mavlink.io/en/messages/common.html#OPEN_DRONE_ID_BASIC_ID
The functions in mav2odid.c can be used to convert these MAVLink messages into suitable opendroneid.h data structures and back again. See the example usages in test/test_mav2odid.c.
Recommendations on how to utilize the MAVLink messages for UAS internal distribution of Open Drone ID data of an Unmanned Aircraft System (UAS) can be found here: https://mavlink.io/en/services/opendroneid.html
The ASTM F3411 Specification for Remote ID and Tracking has been defined to specify how Unmanned Aircraft (UA) or Unmanned Aircraft Systems (UAS) can publish their ID, location, altitude etc., either via direct broadcast (Bluetooth or Wi-Fi), or via an internet connection to a Remote ID server.
Version 1.0 (F3411-19) of the specification is currently available. An updated version 1.1 (F3411-21?) is in the final stages of being finalized (December 2021). It contains smaller changes/additions to make the message content etc. better suited to meet the rule defined by the FAA (Federal Aviation Administration) for UAS flights in the United States. Additionally, a Means of Compliance document (MoC) is being drafted by the ASTM, containing further implementation requirements and test specifications. Together, the two documents will allow manufacturers of UAS and remote ID broadcast modules/Add-ons (for retro-fit on UAs without built-in remote ID support) to implement remote ID support and create the necessary Declaration of Compliance (DoC) document, which must be submitted to the FAA for approval.
To meet the European Commission Delegated Regulation 2019/945 and the Commission Implementing Regulation 2019/947, ASD-STAN has developed the prEN 4709-002 Direct Remote Identification specification. It specifies broadcast methods for Remote ID (Bluetooth and Wi-Fi) that are compliant with the ASTM F3411 v1.1 specification. The final version of the standard has been published here. See also the summary whitepaper and the recording of this webinar.
A comparison of some of the more detailed parts of each specification and rule is given in the table below. If a field is left blank, nothing specific is mentioned in the particular document related to that part.
The rules are what is defined by law and must be followed (the FAA rule in the United States and the EU rule in the European Union). The ASTM Means of Compliance (MoC) document overrides certain parts of the ASTM specification to meet the FAA rule requirements.
| FAA rule | ASTM v1.1 | ASTM MoC | EU rule | ASD-STAN DRI | |
|---|---|---|---|---|---|
| Serial ANSI/CTA-2063-A | M1 | M1 | M1 | M | M |
| Session ID | M1 | M1 | M1 | O | |
| UA dynamic position | M | M | M | M | |
| UA altitude WGS-84 | M | M | O | ||
| UA altitude AGL/Take-off | O | M | M | ||
| Timestamp | M | M | M | M | |
| Operational/Emergency status | M2 | O | M2 | M2 | M2 |
| Track direction | M | M | M | M | |
| Horizontal speed | M | M | M | M | |
| Vertical speed | M | M | O | ||
| Operator registration ID | O | M | M | ||
| EU Category & Class | O | R | |||
| Operator dynamic position | M3 | O | M3 | M3 | M3 |
| Operator altitude WGS-84 | M | O | M | O | |
| Transmission interval4 (seconds) | 1 | 1 or 3 | 1 | 1 or 3 | |
| Transmission time | Take-off to shutdown | Take-off to shutdown | When airborne | ||
| BT4 Legacy Advertising | M5 | M6, 7 | O | ||
| BT5 Long Range | O | M6, 7 | M5 | ||
| Wi-Fi NaN 2.4 GHz | M5 | M5 | |||
| Wi-Fi NaN 5 GHz | O | M5 | |||
| Wi-Fi Beacon 2.4 GHz8 | M5 | M7 | M5 | ||
| Wi-Fi Beacon 5 GHz8 | M5 | M7 | M5 |
M: Mandatory. O: Optional. R: Recommended
- Either the Serial Number or the Session ID must be transmitted. Add-ons are not allowed to use Session ID.
- Not required for Add-ons.
- For Add-ons under EU rule: the Take-off location can be used instead. For Add-ons under FAA rule: The Take-off location is required instead.
- Concerns only the Basic ID, Location and System messages. Location is always with 1 second intervals. Basic ID and System intervals can be 3 seconds in the specifications.
- Only one of the Mandatory broadcast methods is required.
- Both BT4 and BT5 must be transmitted simultaneously.
- Only Bluetooth (BT4 + BT5 simultaneously) or Wi-Fi Beacon (2.4 GHz or 5 GHz) are allowed.
- If any other channel than Channel 6 on 2.4 GHz or Channel 149 on 5 GHz is used, a faster transmission rate of 5 Hz is required.