Welcome to the Developers section of the Dronetag Help Website.

This area is dedicated to providing you with the developer resources and technical guidance. Here, you can access detailed API documentation, which will help you establish connections with our Remote ID solutions.

In addition to the APIs, you'll find guidelines, best practices, and other supporting information that are essential for building reliable integrations. Whether you're working on connecting our products to your existing platforms or experimenting with new ideas, this section offers the tools and knowledge base to support your development efforts.

Dive in to explore how Dronetag can fit into your systems and unlock new possibilities.

Terms of Service​

Using our API is subject to our Terms of Service.

Dronetag provides several integration options to allow access to data from our devices, focusing primarily on Remote ID data. This guide will help you choose the most suitable method for integrating Dronetag into your systems, whether you are working with UTM platforms or building custom solutions.

I Want to Use Existing Integrations​

If you prefer to work with established platforms, Dronetag supports several ready-made integrations:

The integrations currently implemented by Dronetag include:

Data Push can also deliver Dronetag's own formats, including DUMP JSON, DUMP JSON Typed, and Dronetag Legacy JSON. These are useful when you are building a custom integration instead of connecting to one of the platforms listed above. See Protocols and Formats for recommended combinations.

I Want to Build My Own Integration​

For custom solutions or new integrations, we provide multiple options for building the integrations:

If you're unsure which integration method is right for you, check out our guide on Choosing the Right Integration Method for more information and guidance.

Integrating via our API provides a straightforward way to exchange information programmatically with third-party systems or services. We offer two primary methods to facilitate this integration.

Pull Data from Our API​

By pulling data from our API, you can easily retrieve up-to-date information as needed. We provide an HTTP REST API for standard requests, as well as Socket.io for real-time data access. This method is ideal for server-client integrations, personal scripts, and other applications.

Let Our Systems Push Data to Your API​

For a more permanent approach, you can set up a data flow that allows our systems to push real-time traffic directly to your API as soon as it arrives on our servers. This method ensures continuous updates without the need for constant requests, making it an excellent choice for server-to-server integrations.

Our cloud platform supports InterUSS services, enabling the exchange of flight data with distributed UTM systems. If your system already implements the InterUSS protocol, it is likely capable of exchanging data with our platform, ensuring a smooth integration process.

Operating within the same Distributed Situational Awareness (DSS) instance as our system facilitates seamless data exchange between both platforms, enhancing operational coordination.

To learn more, visit the InterUSS Platform Official Website.

Currently Supported Services:

• Remote ID
• Strategic Deconfliction
• Geo-awareness

If you need to integrate our hardware directly without relying on cloud services, there are several options available to achieve this.

On-board Integration with Existing Systems​

Some of our products are specifically designed for integration with existing systems. For detailed instructions, please refer to the user manuals for each product:

• Integration Manual for Dronetag DRI
• Integration Manual for Dronetag BS

Integration via Bluetooth​

All Dronetag devices utilize standard Remote ID data formats that comply with the FAA's Remote Identification of Unmanned Aircraft Systems (UAS) rule and the ASTM F3411-22 standard, ensuring seamless interoperability and regulatory compliance.

If you're interested in receiving Remote ID data directly via Bluetooth, you can create your own Remote ID application to decode the signals transmitted by our devices according to the standard.

Please note that we do not provide an SDK for Remote ID decoding or documentation for our proprietary Bluetooth characteristics. If you have a specific project you’d like to discuss with us, please don’t hesitate to contact us for further assistance.

The REST API is best for retrieving absolute current & historical telemetry data, accessing account data such as assets, devices, aircraft and more. Because you need to request data manually, it's not very suitable for real-time data streaming. For real-time data, we recommend looking at using our Socket.io endpoints.

Obtaining API Credentials​

To access our API, you’ll need to authenticate. There are two ways to do this:

1. Personal Token: Use your personal token to access data on your Dronetag account. This can be created in our app or using API.
2. OpenID Connect: Use OIDC for more advanced authentication methods and allowing your application to access other users' private data.

Consuming the API​

Once you have your credentials, you’re ready to start using the API. We recommend familiarizing yourself with the API documentation, which outlines all available endpoints and the data structures you’ll be working with.

Understanding DUMP data format​

Our API uses a variety of data schemas, each designed for a specific API resource. One of them is used more consistently across our services, and that is the Dronetag Unified Message Protocol (DUMP) format. If you're dealing with Remote ID data, this protocol will be particularly important to understand.

To help you better understand, we've created a detailed guide that breaks down the structure of DUMP messages and explains how to work with them effectively:

Conditions for Telemetry Request Parameters​

Keep in mind that when making telemetry requests to our airspace endpoints (/v2/airspace/*), you must specify both a time range (from and to) and a geographical region (bbox).

There are a few exceptions to this requirement:

• If you provide an operation_id, no other parameters are needed.
• If you specify a uas_id, you can omit the bbox geographical region, but the time range is still required.

Please note that the bbox size is limited and intended for moderately sized regions. It is not possible to use bbox to cover large areas such as entire countries, continents, or the world.

If this condition poses a challenge, we recommend exploring our data push methods.

Additional Guides​

We offer several other guides to help you navigate common use cases with our API. Whether you’re looking to retrieve current airspace information or historical data, these resources will give you the tools you need:

Explore more guides through the left sidebar to enhance your API usage.

The Socket.io API is designed for real-time telemetry data streaming, offering only live updates (no historical or absolute data). Data you miss while disconnected are not replayed — to get the current state or fill gaps after a reconnect, use the REST API. This guide will walk you through setting up a real-time connection between Dronetag and your application using Socket.io.

Connection Parameters​

To establish a connection, use the following configuration parameters in your Socket.io client:

• Host: https://api.dronetag.app
• Path: /v2/airspace/socket.io
• Client Version: v3 or v4

Choosing a Socket.io Client​

Socket.io is supported by many libraries across various programming languages. You can find the full list of supported client implementations here.

Authenticating Your Session​

You can authenticate your Socket.io session using the same access token that you use for REST API requests. Refer to the API credentials guide for details on obtaining your access token.

Authentication is optional. A session without a token receives only publicly available data, while an authenticated session also receives the data your account has access to.

If the token you send is not valid, the server refuses the connection and your client receives a connect_error with the message unauthorized.

Native Socket.io Authentication​

For clients that support native Socket.io authentication, you can pass the access token directly in the auth configuration option.

let socket = io("https://api.dronetag.app", {
  path: "/v2/airspace/socket.io",
  auth: "eyJhbGciOiJSUzI1NiIsInR5c...",
});

More information on using Socket.io authentication can be found in the Socket.io documentation.

Using a Bearer Token in the Handshake Request​

If your client does not support the auth option, you can send the access token as an Authorization header in the handshake request:

let socket = io("https://api.dronetag.app", {
  path: "/v2/airspace/socket.io",
  extraHeaders: { Authorization: "Bearer eyJhbGciOiJSUzI1NiIsInR5c..." }
});

The header value must be in the form Bearer <token>, otherwise the connection is refused with the message wrong bearer token format.

This approach is also handy when using tools like Postman for testing, which typically don’t support native authentication. You can simply add the Authorization header in the Headers tab of Postman.

Authenticating an Existing Connection​

You can also authenticate an already established connection by sending the access token in the authenticate event. The server acknowledges it with {"result": "ok"}. If the token is not valid, the server responds with {"result": "not_authenticated"} and the connection stays open as unauthenticated, receiving only publicly available data.

Subscribing to Events​

Once connected, you can listen for the following events:

• serverinfo – Sent once, right after the connection is established. Contains information about the server, such as server_version, environment and your_sid (your session ID as seen by the server).
• telemetry_ua – Unmanned Aircraft telemetry
• telemetry_operator – Operator telemetry
• telemetry_system – System telemetry
• operation – Operation updates

Each telemetry_ua, telemetry_operator, telemetry_system and operation event carries an array of DUMP messages, not a single message. Telemetry events are limited to the viewport you set (see below), while operation events are not limited by the viewport. The operation event carries OperationUpdate messages, which contain only recent changes of an operation, not its full state.

For the most up-to-date and comprehensive list of available events, their payloads and responses, refer to our AsyncAPI documentation.

Setting and Updating the Viewport​

Just as with the REST API, you must specify the geographical region your application is interested in.

After connecting, your client must send an initial viewport event to define the geographical area it wants to monitor. Additionally, the client must update this area by sending new viewport events whenever the region of interest changes. Each viewport event replaces the previously set viewport. If you don't set a viewport, your session won't receive telemetry for any area.

The viewport is bound to a single connection. Whenever your client connects or reconnects, it must send the viewport again.

The viewport is a string in the format lon_min,lat_min,lon_max,lat_max — longitude and latitude in degrees, separated by commas without spaces. For example, to set the viewport to Prague, you may use something like emit("viewport", "14,49.9,15,50.3").

For example, in Dronetag’s own applications, the map moves dynamically based on user interactions. After establishing a connection, the app sends the initial viewport, and as the user moves the map, the viewport is updated. We recommend debouncing these updates, so that your client does not send a new viewport on every small map movement.

Always set your viewport carefully. It is important to cover the whole area of your interest. On the other hand, do not set viewports too large, as it could provide data you do not want and also cause performance issues. It is recommended to add a sufficient margin of a few kilometers (or miles, if you wish) on each side. The maximal supported viewport area is around 6 million square kilometers, but try avoiding such extreme values.

The server acknowledges each viewport event with one of these responses:

• {"result": "ok"} – The viewport was set.
• {"result": "invalid-param", "messages": [...]} – The viewport is not in the expected format or its values are out of range.
• {"result": "bbox_area_too_large", "messages": [...]} – The viewport area exceeds the maximal supported area. The previously set viewport stays in effect.

To read the response, pass an acknowledgement callback when emitting the event, for example socket.emit("viewport", "14,49.9,15,50.3", (response) => console.log(response)).

Ordering Telemetry​

By default, telemetry within each event is ordered by time in ascending order. You can change the ordering for each telemetry event by sending the ordering event. Its payload must be a JSON-encoded string mapping the event names to one of these values:

• time – ascending order (default)
• -time – descending order

socket.emit("ordering", JSON.stringify({
  telemetry_ua: "-time",
  telemetry_operator: "time",
  telemetry_system: "time",
}));

The server acknowledges the event with {"result": "ok"}, or with {"result": "invalid-param", "messages": [...]} if the payload is not valid. Like the viewport, the ordering is bound to a single connection.

Example Code Snippets​

Below are some quick examples to help you get started with Socket.io in different programming languages:

const { io } = require('socket.io-client');

const socket = io('https://api.dronetag.app', {
  path: '/v2/airspace/socket.io',
  auth: 'eyJhbGciOiJSUzI1NiIsInR5c...'
});

socket.on('connect', () => {
  // The viewport must be sent after every (re)connect
  socket.emit('viewport', '14,49.9,15,50.3', (response) => {
    console.log('Viewport response:', response);
  });
});

socket.on('connect_error', (err) => {
  console.error('Connection error:', err.message);
});

socket.on('telemetry_ua', (batch) => {
  for (const telemetry of batch) {
    console.log('UA telemetry received:', telemetry);
  }
});

import socketio

sio = socketio.Client()

@sio.event
def connect():
    # The viewport must be sent after every (re)connect
    sio.emit(
        'viewport',
        '14,49.9,15,50.3',
        callback=lambda response: print(f'Viewport response: {response}'),
    )

@sio.event
def connect_error(data):
    print(f'Connection error: {data}')

@sio.event
def telemetry_ua(batch):
    for telemetry in batch:
        print(f'UA telemetry received: {telemetry}')

sio.connect(
    'https://api.dronetag.app',
    socketio_path='/v2/airspace/socket.io',
    auth='eyJhbGciOiJSUzI1NiIsInR5c...'
)

sio.wait()

Here, you will learn how to authenticate your requests to access resources available on Dronetag accounts.

We offer two authentication methods: Personal Access Tokens (PATs) and OpenID Connect. Each method serves different use cases, so please read on to determine which is best suited for your project.

Using Personal Access Tokens (PATs)​

If you plan to work with personal data from your own Dronetag account, such as post-processing data, creating a personal command-line interface (CLI) tool, or integrating data into other software, Personal Access Tokens (PATs) are available for easy and straightforward access to the API.

These tokens provide a simple to use, although less secure, method for accessing your resources via our API services. For more robust integrations intended for public access, we recommend considering the OpenID Connect method instead.

Creating a new token​

{
    "password": "hunter2",
    "expires_at": "2025-09-09"
}

After you issue a new Personal Access Token, be sure to store this token securely. You won't be able to retrieve this token again.

Using tokens to authorize requests​

You can now use the token in X-Personal-Access-Token HTTP header when making requests.

Example request with PAT​

POST /v2/airspace/telemetry/ua HTTP/1.1
Host: api.dronetag.app
Accept: */*
X-Personal-Access-Token: 4c5250130bbce349.b0dc901facd944e999b32ebf984c5250130bbce349b0dc901facd944e999b32e

Implementing OpenID Connect​

By implementing Sign in with Dronetag, you can allow users to access their data through your application. This method is more reliable and offers a standardized approach to authentication.

Understanding OpenID Connect (OIDC)​

Our implementation is based on OpenID Connect (which should not be confused with OpenID). OIDC allows you to leverage existing libraries and may already be supported by your application. Learn more on the OpenID Foundation website.

To utilize OIDC in your application, you will need your own client ID and secret. If you have not yet received these credentials, please contact us for assistance.

Implement authentication in your application​

curl -X POST "https://auth.dronetag.app/realms/dcp/protocol/openid-connect/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=password" \
-d "client_id=<your-client-id>" \
-d "client_secret=<your-client-secret>" \
-d "username=<your-username>" \
-d "password=<your-password>"

{
    "access_token": "eyJhbGc...",
    "expires_in": 1200,
    "refresh_expires_in": 604800,
    "refresh_token": "eyJhbGc...",
    "token_type": "Bearer",
    "not-before-policy": 0,
    "session_state": "35d764ee-c27c-4763-bc05-5ffa2e2b822e",
    "scope": "email"
}

The table above assumes your application has been assigned its "Client ID" and "Client Secret". For testing purposes, you may use a generic Client ID of dronetag-integration-test with no secret needed. For production use, each individual application should be assigned its own unique Client ID. Otherwise, limits on the volume of pulled data may be applied. Contact Dronetag support to get your credentials.

Using Access Tokens​

Both Personal Access Tokens and access tokens retrieved using OIDC can be added as a Bearer token in the Authorization header to authenticate your API requests.

Example Request​

POST /v2/airspace/telemetry/ua HTTP/1.1
Host: api.dronetag.app
Accept: */*
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICItQllNT2...

Refreshing Tokens​

Access tokens issued as JWTs are short-lived and require refreshing upon expiration. We recommend reviewing the following resources for more information on refresh tokens and their secure usage:

• What Are Refresh Tokens and How to Use Them Securely - Auth0
• Understanding Refresh Tokens, Access Tokens, and ID Tokens in OIDC Protocol - Logto
• Refresh Access Tokens and Rotate Refresh Tokens - Okta

One way to access telemetry data from Dronetag devices is by letting our servers initiate the connection and push the data to yours. You can manage these connections through our Integration Portal, where you can configure everything yourself. This portal gives you full control over the integration settings, allowing you to select connection protocols like HTTP webhooks, MQTT, TCP, or UDP. You can for example easily switch between your testing and production environments and adjust other settings as needed.

How to Access the Integration Portal​

To set up Data Push integration, you'll need access to the portal, which is available for users subscribed to our Pro plan or for business partners participating in our cooperative projects. If you're interested in gaining access, reach out to us.

Access the portal at https://integrations.dronetag.app.

The user-friendly web interface makes it simple to configure your integration in just a few steps.

What Can You Configure?​

Our integration framework is designed to be highly flexible, allowing you to customize many parameters for each integration without needing our help. Here’s what you can configure:

• Connection Protocol: Choose between HTTP webhooks, MQTT, TCP, or UDP.
• Target Address: Direct the data to your production or staging API endpoint—it’s your call.
• Output Format: Besides our standard JSON format, we support various UTM systems. See Protocols and Formats for recommended combinations.
• Traffic Throttling: To avoid overloading your servers, you can limit the number of requests at the cost of some latency.
• Authentication: Choose from various authentication methods, including HTTP Basic Authentication, custom HTTP headers, OAuth 2.0, and more.
• ... and more

Setting Up Your First Distribution Target​

To start transferring data, you'll need to create a distribution target. This represents the service where you want to send your data. You can create multiple targets, but there is a limit. Once a target is created, our system will automatically distribute data until you deactivate or remove it.

1. Log in to the Integration Portal with your Dronetag account, or create a new one.
2. On the main page, you’ll see all the distributions you’ve created.
3. Create a new distribution target by clicking the Add New button.
4. Fill out the form to configure your target. The following sections on this page will help guide you through the setup.
5. Save the target and allow a few minutes for the changes to take effect.
6. You can check for communication or configuration errors by viewing the server logs. Find your newly created distribution on the main page and click View & Edit.

Pausing or Stopping the Distribution​

To temporarily stop the data from being sent to your services, you can pause the distribution by marking it as inactive. If you no longer need the distribution, you can permanently delete it.

What’s Next?​

• After setting up your integration, check if it's working properly.
• Learn more about our DUMP JSON format.
• If this integration method doesn’t suit your needs, check out our guide for choosing the best integration method.

Each Data Push distribution combines two separate choices:

• Connection protocol - how Dronetag sends the data to your system.
• Output format - how each telemetry message is encoded.

Most formats are technically transport-independent, but not every combination is useful in practice. Choose the protocol based on how your system receives data, then choose a format that your target system can parse.

Recommended Combinations​

Compatibility Matrix​

Product Names​

Some integrations are better known by the product or ecosystem name than by their protocol and format:

Portal Names and Security Options​

The Integration Portal uses these connection labels:

You can also leave authentication empty when your receiver does not require it. In this table, HTTPS, MQTT over TLS, and TLS/mTLS are transport security options, and AES data encryption is a payload encryption option, not a login method. The portal label HTTP Basic Authentication is also used for MQTT username/password credentials.

mTLS settings are shown in the portal only for TCP Socket distributions. The portal accepts either separate PEM files or PKCS#12 .p12 bundles:

• PEM: CA certificate, client certificate, client private key, and optional client key passphrase.
• PKCS#12: truststore .p12 with one or more certificates used to verify the server, and client .p12 with the client certificate and matching private key. Each bundle can have its own optional password. The portal converts both bundles to PEM before the integration uses them.
• Verify host checks the server hostname against the TLS certificate.

The selected Data Source controls which messages a distribution target may receive before protocol or format conversion. See Message Coverage for details about which message types each output format can send.

The portal also exposes delivery controls:

• Keep reliable controls behavior when messages cannot be delivered.
• Throttle messages limits how often Dronetag sends data to your receiver.
• Allow mixed content allows multiple message types in one request where the selected output format supports it.
• Send empty payloads sends an empty request at the throttle interval even when no new telemetry is available. It requires throttling to be enabled.

Common Setting Bundles​

HTTP Webhooks API​

Use this for custom APIs, webhooks, and most partner API integrations.

Typical settings:

• Target URL starts with https://.
• Authentication is HTTP Basic Authentication, OAuth 2.0, a partner-specific method, or custom HTTP headers.
• Additional headers can carry API keys, tenant identifiers, or environment selectors.

MQTT Client​

Use this when your infrastructure expects telemetry on MQTT topics.

Typical settings:

• Target URI and port point to your MQTT broker.
• Transport is tcp or websockets, depending on your broker.
• Username/password authentication is configured when the broker requires it.
• Topic can include {msgtype} for DUMP JSON routing.
• QoS is usually 0 or 1, depending on whether low latency or delivery acknowledgement is more important.

TAK / CoT​

Use this for TAK Server, ATAK, WinTAK, iTAK, or TAK-compatible middleware.

Typical settings:

• Output format is Cursor on Target XML.
• Protocol is usually TCP or UDP socket.
• TCP is preferred when you need connection state and better delivery behavior.
• UDP is common for simple CoT feeds where occasional packet loss is acceptable.
• mTLS can be enabled for TCP when your TAK Server requires client certificates.

SAPIENT​

Use this only for systems that explicitly implement SAPIENT.

Typical settings:

• Protocol is TCP Socket.
• Output format is SAPIENT.
• TCP protocol mode is sapient.
• Heartbeat interval is configured when required by the receiving node.
• TLS or mTLS is enabled if required by the SAPIENT deployment.

Protocol Notes​

HTTP Webhooks​

HTTP is the best option when your system exposes an API endpoint. Dronetag sends POST requests to your target URL. The URL must start with http:// or https://.

Use plain HTTP only for development and testing. For production environments, HTTPS is strongly recommended.

HTTP can include metadata as headers, such as content type, message type, integration client ID, and public data visibility. You can also configure additional HTTP headers for your distribution.

Use HTTP for partner-specific API formats such as Altitude Angel, ASTRA, Highlander, and similar integrations.

MQTT Client​

MQTT is the best option when your system already operates an MQTT broker and expects telemetry on topics. Dronetag connects as an MQTT client and publishes converted messages to the configured topic.

MQTT works well with JSON payloads. If you use DUMP JSON, you can include {msgtype} in the topic name to route UA telemetry, operator telemetry, system telemetry, and operation updates to separate topics.

TCP Socket​

TCP is useful when the target system expects a persistent socket connection. It is also the recommended protocol for SAPIENT and one of the recommended protocols for TAK Server.

For SAPIENT, configure the TCP protocol mode as sapient. This enables the SAPIENT registration flow and length-prefixed binary messages.

TCP can also use TLS or mutual TLS when your target requires certificate-based security.

UDP Socket​

UDP is useful for simple fire-and-forget delivery, especially when integrating with systems that already accept UDP feeds, such as some TAK deployments.

Because UDP does not provide delivery confirmation, use TCP or HTTP when your integration requires stronger delivery guarantees.

Metadata​

HTTP sends metadata as request headers. MQTT, TCP, and UDP can optionally embed metadata into the payload for formats where that is useful.

Embedded metadata wraps the payload in an object with data and metadata fields. Use it only if your receiver is built to parse that wrapper.

When Unsure​

For custom integrations, start with:

1. HTTP Webhooks + DUMP JSON if your service can expose an HTTPS endpoint.
2. MQTT + DUMP JSON if your infrastructure already uses MQTT.
3. TCP + Cursor on Target XML if you are integrating with TAK Server.
4. TCP + SAPIENT if your target system explicitly requires SAPIENT.

While configuring your integration distribution in our integration portal, you will encounter the field "data source". This article provides a detailed explanation of what data sources are and how they can be utilized in your integration.

The data source controls which messages are eligible for a distribution target. The selected output format can further limit which eligible message types are actually sent. See Message Coverage for details.

My Account​

Requirements: None
Data shared: Only the data associated with the distribution owner account

This data source is available to anyone using the integration portal. It is primarily intended for initial testing and evaluation. When selected, it provides access only to the data associated with the same account as the account creating the distribution (owner). Only devices registered to this account are visible, ensuring privacy and isolation from other users' data.

Device Group​

Requirements: Existing device group related to an order of Dronetag devices
Data shared: All data, regardless of privacy settings or registration status

Device Group is intended for customers who have entered into a partnership with Dronetag and have purchased a group of devices. These devices are assigned to a pre-defined static group, which can be selected as a data source. The group membership is fixed and can only be changed upon request. Device groups are not visible or accessible to regular Dronetag users.

Partner Integration​

Requirements: Partnership registration with Dronetag
Data shared: Opt-in by users, all data regardless of privacy settings

Partner Integrations are visible and accessible to users, who have full control over which integrations can access their data.

Users can allow or deny access to their data for each integration via the Dronetag App, in the "Integrations" section. This means that users can choose to share their data with specific integrations while keeping it private from others.

Partner Integrations can be configured to prompt users for an arbitrary token, identifier, or authorization value when enabling the integration in the Dronetag App. This allows users to enter credentials or identifiers required by the third-party service, which can reliably associate Dronetag users with their own user accounts or authorization systems.

The partner integration approach increases transparency and user awareness, allowing users to remain in private mode while still enabling third-party integrations. This is the recommended approach for most integrations.

Each partner integration requires the following information to be provided, which is then displayed in the Dronetag App 'Integrations' section:

• Full/display company/app name
• Logo URL (optional) – horizontal logo to improve brand recognition
• Description (optional) – short text describing your company/app/platform
• Website URL - link to your website
• Manager account – Dronetag account that will be allowed to select this partner integration as a data source in the integration portal
• Client ID configuration (optional) - a preference if you wish to require users to enter identification before enabling the integration

All Public Data (Deprecated)​

Previous requirements: None
Data shared: All public data of all Dronetag users (but not private data)

This data source previously allowed all public data available in the Dronetag App to be shared with any third party via the integration portal.

To enhance user experience and privacy, this option has been deprecated and is no longer available.

The most common distribution type uses HTTP protocol to distribute the data.
For each telemetry message, a new HTTP request is created and sent to your service's HTTP server.

Specific configuration​

Currently, only additional HTTP headers can be set using the specific configuration.

Example specific configuration​

Following is an example of configuration JSON where custom headers are used to send a Bearer token with each request.

{
  "target_additional_http_headers": {
    "X-My-Custom-Id": "12345"
  }
}

If your service is equipped with an MQTT Broker Server, you can use the MQTT Client type to connect to your server and publish the data.

Specific configuration​

Example specific configuration​

Following is an example of configuration JSON.

{
  "mqtt_dist_client_id": "dronetag_0001",
  "mqtt_dist_transport": "tcp",
  "mqtt_dist_tls": false,
  "mqtt_dist_json_datastream_topic": "dronetag/telemetry/{msgtype}",
  "mqtt_dist_publish_qos_default": 0
}

Using {msgtype} in topic name​

If you use Dronetag DUMP format and you'd like to send different types of messages to different topics, you can use the {msgtype} placeholder in the topic name. It will be replaced with the actual message type before sending. For example, if the message type is "UA telemetry", the topic dronetag/telemetry/{msgtype} will become dronetag/telemetry/tele-ua.

Available message types are:

• tele-ua - UA telemetry messages
• tele-operator - Operator telemetry messages
• tele-system - System telemetry messages
• operation-update - Operation update messages

Refer to the 'Understanding DUMP' page for more information about the message types.

Configuration recommendations​

• Usually a valid Target Port is required to be set.

This distribution type uses plain TCP or UDP socket to distribute the data.

Specific configuration​

Example specific configuration​

Following is an example of configuration JSON

{
  "embed_metadata": true
}

Configuration recommendations​

• The 'Target port' must be set
• We recommend using the AES cipher authorization type to keep the traffic secure

Data Push uses two separate filters before sending data to your target:

1. The Data Source setting controls which messages are eligible for the distribution target.
2. The Output Format setting controls which eligible message types can be represented and sent.

For example, a target using the My account data source can receive only messages accessible to that account. If the same target uses a partner-specific UAV-position format, only eligible aircraft position messages are sent because that format cannot represent operator position, system telemetry, or operation updates.

Message Types by Output Format​

DUMP JSON and DUMP JSON Typed are the best choices when your target needs the complete Data Push message set.

System telemetry can be disabled for a target with the distribute_system_telemetry connection setting.

After setting up your first distribution, your next step will likely be monitoring to ensure it's working correctly. You can do this in several ways.

Check the Status in the Integration Portal​

To view the current status of your distribution, visit the Integration Portal and confirm that your distribution is enabled and configured correctly.

Click on the View & Edit link to see details such as uptime and statistics for the last 24 hours. You'll also see a small chart that provides a quick overview of how many messages were sent through this distribution during that period.

Monitor the Status with Prometheus / OpenTelemetry​

If you want more advanced monitoring, including historical data and alerts, you can integrate Prometheus to scrape metrics from our system. This feature is available for all integration portal users and provides detailed data for each running integration.

To visualize the data, we recommend using Grafana.

Getting the Metrics URL​

1. Log in to the Integration Portal with your Dronetag account, or create a new one.
2. Find the distribution target you're interested in and click View & Edit.
3. Click the Get Prometheus Metrics button.
4. You’ll see the metrics in Prometheus/OpenMetrics format.
5. Use your preferred tool to scrape this URL periodically (see the next section for more details).

The URL format will look like this:

https://relay.dronetag.app/metrics/[[your_distribution_id]]

Make sure to note your distribution ID.

Scraping Metrics with Prometheus​

Prometheus is an open-source monitoring system that can scrape our metrics export. To learn more and find installation instructions, refer to the official Prometheus documentation.

Here’s a recommended configuration to start scraping our metrics:

global:
  scrape_interval: 10s
scrape_configs:
  - job_name: 'dronetag_distribution_metrics'
    scrape_interval: 10s
    metrics_path: '/metrics/[[your_distribution_id]]'
    static_configs:
      - targets: ['relay.dronetag.app']

This configuration will scrape metrics every 10 seconds from the URL: https://relay.dronetag.app/metrics/[[your_distribution_id]].

Available Metrics​

Visualizing Data with Grafana​

Grafana is an open-source monitoring and analytics tool that works with Prometheus as a data source.

Check out the guide 'Get started with Grafana and Prometheus' to learn how to install Grafana and set up Prometheus as a data source.

Example Grafana Dashboard​

We provide a basic Grafana dashboard example. You can import the JSON file into your Grafana instance and modify it to suit your needs.

{ "annotations": { "list": [ { "builtIn": 1, "datasource": { "type": "grafana", "uid": "-- Grafana --" }, "enable": true, "hide": true, "iconColor": "rgba(0, 211, 255, 1)", "name": "Annotations & Alerts", "target": { "limit": 100, "matchAny": false, "tags": [], "type": "dashboard" }, "type": "dashboard" } ] }, "editable": true, "fiscalYearStartMonth": 0, "graphTooltip": 0, "id": 47, "links": [ { "asDropdown": false, "icon": "cloud", "includeVars": false, "keepTime": false, "tags": [], "targetBlank": false, "title": "Dronetag Integration Portal", "tooltip": "", "type": "link", "url": "https://integrations.dronetag.app" } ], "liveNow": false, "panels": [ { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "fieldConfig": { "defaults": { "color": { "mode": "thresholds" }, "mappings": [], "thresholds": { "mode": "absolute", "steps": [ { "color": "dark-purple", "value": null } ] }, "unit": "string" }, "overrides": [] }, "gridPos": { "h": 3, "w": 16, "x": 0, "y": 0 }, "id": 3, "options": { "colorMode": "value", "graphMode": "none", "justifyMode": "auto", "orientation": "horizontal", "reduceOptions": { "calcs": [ "lastNotNull" ], "fields": "/^relay_distribution_name$/", "values": false }, "text": { "valueSize": 40 }, "textMode": "value" }, "pluginVersion": "10.1.1", "targets": [ { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "editorMode": "code", "expr": "relay_messages_read_created{distribution_id=\"$distribution_id\"}", "format": "table", "instant": false, "legendFormat": "__auto", "range": true, "refId": "A" } ], "transformations": [], "type": "stat" }, { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "fieldConfig": { "defaults": { "color": { "mode": "thresholds" }, "mappings": [], "thresholds": { "mode": "absolute", "steps": [ { "color": "green", "value": null }, { "color": "dark-blue", "value": 80 } ] }, "unit": "dateTimeFromNow" }, "overrides": [] }, "gridPos": { "h": 3, "w": 8, "x": 16, "y": 0 }, "id": 2, "options": { "colorMode": "value", "graphMode": "none", "justifyMode": "center", "orientation": "horizontal", "reduceOptions": { "calcs": [ "lastNotNull" ], "fields": "/^Created$/", "values": false }, "textMode": "value_and_name" }, "pluginVersion": "10.1.1", "targets": [ { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "editorMode": "code", "expr": "relay_messages_read_created{distribution_id=\"$distribution_id\"}", "format": "time_series", "instant": false, "legendFormat": "Created at", "range": true, "refId": "A" } ], "transformations": [ { "id": "calculateField", "options": { "alias": "Created", "binary": { "left": "Created at", "operator": "*", "reducer": "sum", "right": "1000" }, "mode": "binary", "reduce": { "reducer": "sum" }, "replaceFields": true } } ], "type": "stat" }, { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "description": "Average rates of sent (distributed) messages. Dotted line shows source input rate, which can be higher if there are filters applied (such as filter to specific device group).", "fieldConfig": { "defaults": { "color": { "mode": "palette-classic" }, "custom": { "axisCenteredZero": false, "axisColorMode": "text", "axisLabel": "", "axisPlacement": "auto", "barAlignment": 0, "drawStyle": "bars", "fillOpacity": 100, "gradientMode": "none", "hideFrom": { "legend": false, "tooltip": false, "viz": false }, "insertNulls": false, "lineInterpolation": "linear", "lineWidth": 0, "pointSize": 5, "scaleDistribution": { "type": "linear" }, "showPoints": "never", "spanNulls": false, "stacking": { "group": "A", "mode": "none" }, "thresholdsStyle": { "mode": "off" } }, "mappings": [], "thresholds": { "mode": "absolute", "steps": [ { "color": "green", "value": null }, { "color": "red", "value": 80 } ] }, "unit": "mps" }, "overrides": [ { "matcher": { "id": "byName", "options": "Input rate" }, "properties": [ { "id": "custom.lineWidth", "value": 1 }, { "id": "custom.lineStyle", "value": { "dash": [ 2, 6 ], "fill": "dot" } }, { "id": "color", "value": { "mode": "fixed" } }, { "id": "custom.drawStyle", "value": "line" }, { "id": "custom.fillOpacity", "value": 0 } ] } ] }, "gridPos": { "h": 8, "w": 24, "x": 0, "y": 3 }, "id": 1, "interval": "15s", "maxDataPoints": 128, "options": { "legend": { "calcs": [], "displayMode": "list", "placement": "bottom", "showLegend": true }, "tooltip": { "mode": "single", "sort": "none" } }, "targets": [ { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "editorMode": "code", "expr": "sum(rate(relay_messages_distributed_total{distribution_id=\"$distribution_id\"}[$__rate_interval])) by (distribution_id)", "instant": false, "legendFormat": "Distributed rate", "range": true, "refId": "A" }, { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "editorMode": "code", "expr": "sum(rate(relay_messages_read_total{distribution_id=\"$distribution_id\"}[$__rate_interval])) by (distribution_id)", "hide": false, "instant": false, "legendFormat": "Input rate", "range": true, "refId": "B" } ], "title": "Average distribution rate", "type": "timeseries" }, { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "description": "The duration of how long it takes to convert the source input data to the output format. Includes filtering or other data pre-processing.", "fieldConfig": { "defaults": { "color": { "mode": "fixed", "seriesBy": "last" }, "custom": { "axisCenteredZero": false, "axisColorMode": "text", "axisLabel": "", "axisPlacement": "auto", "barAlignment": 0, "drawStyle": "line", "fillOpacity": 0, "gradientMode": "none", "hideFrom": { "legend": false, "tooltip": false, "viz": false }, "insertNulls": false, "lineInterpolation": "linear", "lineWidth": 1, "pointSize": 5, "scaleDistribution": { "type": "linear" }, "showPoints": "auto", "spanNulls": false, "stacking": { "group": "A", "mode": "none" }, "thresholdsStyle": { "mode": "line" } }, "mappings": [], "thresholds": { "mode": "absolute", "steps": [ { "color": "blue", "value": null } ] }, "unit": "s" }, "overrides": [] }, "gridPos": { "h": 8, "w": 12, "x": 0, "y": 11 }, "id": 4, "interval": "15s", "options": { "legend": { "calcs": [], "displayMode": "list", "placement": "bottom", "showLegend": true }, "tooltip": { "mode": "single", "sort": "none" } }, "targets": [ { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "editorMode": "code", "expr": "sum(rate(relay_message_conversion_seconds_sum{distribution_id=\"$distribution_id\"}[$__rate_interval]) / rate(relay_message_conversion_seconds_count{distribution_id=\"$distribution_id\"}[$__rate_interval])) by (distribution_id)", "instant": false, "legendFormat": "__auto", "range": true, "refId": "A" } ], "title": "Average conversion duration", "type": "timeseries" }, { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "description": "The duration of how long it takes to distribute the data. The largest part is usually the server latency. Some distribution types can be missing a support for this metric.", "fieldConfig": { "defaults": { "color": { "mode": "thresholds", "seriesBy": "max" }, "custom": { "axisCenteredZero": false, "axisColorMode": "text", "axisLabel": "", "axisPlacement": "auto", "barAlignment": 0, "drawStyle": "line", "fillOpacity": 0, "gradientMode": "none", "hideFrom": { "legend": false, "tooltip": false, "viz": false }, "insertNulls": false, "lineInterpolation": "linear", "lineWidth": 1, "pointSize": 5, "scaleDistribution": { "type": "linear" }, "showPoints": "auto", "spanNulls": false, "stacking": { "group": "A", "mode": "none" }, "thresholdsStyle": { "mode": "dashed" } }, "mappings": [], "thresholds": { "mode": "absolute", "steps": [ { "color": "blue", "value": null }, { "color": "dark-orange", "value": 0.7 }, { "color": "semi-dark-red", "value": 1 } ] }, "unit": "s" }, "overrides": [] }, "gridPos": { "h": 8, "w": 12, "x": 12, "y": 11 }, "id": 5, "interval": "15s", "options": { "legend": { "calcs": [], "displayMode": "list", "placement": "bottom", "showLegend": true }, "tooltip": { "mode": "single", "sort": "none" } }, "targets": [ { "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "editorMode": "code", "expr": "sum(rate(relay_message_distribution_seconds_sum{distribution_id=\"$distribution_id\"}[$__rate_interval]) / rate(relay_message_distribution_seconds_count{distribution_id=\"$distribution_id\"}[$__rate_interval])) by (distribution_id)", "instant": false, "legendFormat": "__auto", "range": true, "refId": "A" } ], "title": "Average distribute duration", "type": "timeseries" } ], "refresh": "", "schemaVersion": 38, "style": "dark", "tags": [ "dronetag" ], "templating": { "list": [ { "current": { "selected": false, "text": "cc2129b7-30e4-469e-8b13-92e7e097d528", "value": "cc2129b7-30e4-469e-8b13-92e7e097d528" }, "datasource": { "type": "prometheus", "uid": "aRT0ZzYnk" }, "definition": "label_values(relay_messages_read_total,distribution_id)", "hide": 0, "includeAll": false, "label": "Distribution ID", "multi": false, "name": "distribution_id", "options": [], "query": { "query": "label_values(relay_messages_read_total,distribution_id)", "refId": "PrometheusVariableQueryEditor-VariableQuery" }, "refresh": 1, "regex": "", "skipUrlSync": false, "sort": 0, "type": "query" } ] }, "time": { "from": "now-1h", "to": "now" }, "timepicker": { "nowDelay": "", "refresh_intervals": [ "5s", "10s", "30s", "1m", "5m" ] }, "timezone": "", "title": "Dronetag Single Distribution Monitoring", "uid": "f2370455-bdac-4098-baf5-ea8857bc199d", "version": 5, "weekStart": "" }

If you're encountering issues with your Data Push integration or distribution setup, this guide will help you identify and resolve common problems.

Common Issues and Solutions​

1. Distribution Not Sending Data​

If your distribution has been set up but no data is being sent, try the following steps:

• Check Distribution Status: Log in to the Integration Portal and make sure your distribution is active and properly configured. Look for errors or warnings in the logs.
• Verify Target Address: Ensure that the target address (API endpoint, MQTT broker, etc.) is correct. Test the connection to make sure your service is reachable.
• Firewall or Network Restrictions: Confirm that no firewall or network rules are blocking incoming data from our servers. Make sure the necessary ports are open (especially when using custom ports for TCP/UDP).

2. Data Delays or High Latency​

If data is delayed or experiencing high latency, the issue might be related to:

• Traffic Throttling: Check if you've configured traffic throttling in the Integration Portal. Highly throttled set-ups can increase latency.
• Network Performance: Analyze your server's network performance and response times. High latency can sometimes be due to slow processing on your server. You can use our Prometheus metrics monitoring to check the request latency against your servers.

3. Authentication Failures​

If your distribution is failing due to authentication errors:

• Check Authentication Method: Verify that the correct authentication method (HTTP Basic Authentication, OAuth 2.0, custom headers, etc.) is configured in the Integration Portal.
• Credentials: Ensure your API credentials or tokens are up-to-date and correctly set in your target service.

4. Failed Message Delivery​

If the system is failing to deliver messages, or if you notice a lower count of distributed messages compared to input messages:

• Check Filters: The system may be filtering out certain messages based on your configuration. Review the Data Source configuration item.
• Review Server Logs: Look at the distribution server logs for any error messages or warnings. You can access these through the Integration Portal by clicking View & Edit on the distribution.
• Connection Issues: If the target service is down or unreachable, the system will not be able to deliver messages. Make sure your service is online and available.

5. Prometheus Metrics Not Showing Up​

If you're using Prometheus to scrape metrics but aren't seeing any data:

• Metrics URL: Double-check the metrics URL in the Prometheus configuration. Ensure it's in the correct format: https://relay.dronetag.app/metrics/[[your_distribution_id]].
• Prometheus Configuration: Review your prometheus.yml configuration file to confirm that the metrics path is correct and that Prometheus is scraping at the correct interval.
• Distribution Errors: If distribution cannot start properly or is failing, the metrics endpoint can usually be empty. Check the distribution server logs if it's running properly.

Need More Help?​

If these steps don’t resolve your issue, feel free to contact our support team for assistance. Make sure to include any relevant details, such as error logs or screenshots, to help us quickly diagnose the problem.

This guide is for our customers and partners looking to integrate Dronetag solutions into their systems. Below, you’ll find helpful resources and links tailored to your specific integration needs.

Before proceeding, it's important to clarify your integration requirements:

• What type of data do you need, and in what formats? What protocols does your system prefer?
• What environment will the integration operate in—client-side, server-side, or both?
• Do you prefer to initiate the data exchange from your system, or would you rather have Dronetag stream data directly to you?

One-Time Data Import into Another Application​

“I want to just import my flight data to another application.”

If real-time access and continuous data collection aren’t required, you can export data from our apps in open formats such as CSV, KML, or GPX.

Learn more about the Dronetag app here.

Scripting to Collect Historical Flight Data​

“I want to write a script to collect all my flight data from last week in KML format.”

For automated collection of historical data, our REST API allows exporting in multiple formats. By default, we use our JSON format, but you can also request CSV, KML, GPX, or GeoJSON by specifying the desired MIME type in your Accept header.

Since you'll be accessing your own devices under your account, Personal Access Tokens are the most straightforward authentication method for you.

Refer to our guide on obtaining telemetry data or explore our API documentation for more details.

Accessing Real-Time Data for All Your Devices​

“I want to display my Dronetag devices in real-time in different software.”

If real-time data is your priority, we recommend using either an existing integration, or a combination of our REST API and Socket.io real-time API.

Check our getting started page, which lists the currently available existing integrations with our partners and third-party software.

If such integration is not available, you're given an option to integrate with our REST API and Socket.io API. Since you'll be accessing your own devices under your account, Personal Access Tokens are the most straightforward authentication method for you.

See our guide on retrieving real-time data or check out the API documentation.

Displaying User Data in a Client-Side Application​

“I have a web application and I want to allow Dronetag users to display their data in my application and manage their Dronetag assets.”

To allow your users to view their Dronetag data within your client-side application, we recommend integrating OpenID Connect. This enables seamless login using Dronetag accounts directly from your application.

Learn more about API authentication.

Sharing User Telemetry to a Server-Side Solution​

“I have a cloud solution and I would like to collect data from Dronetag devices from other users.”

If you have a server-side application and want to give your users access to their telemetry data in it, we suggest using our integration portal. You can establish a persistent connection between the Dronetag Cloud Platform and your server. Users will then be able to authorize your integration through the Dronetag App, allowing telemetry data from their devices to be sent to your servers.

Start with the Data Push Getting Started guide.

Integrating U-Space Data​

If you need to integrate with U-Space services, we also support U-Space reporting via InterUSS. We can send data to several DSS (Discovery and Synchronization Service) instances. If your system already implements the InterUSS protocol, we may be able to work with your existing DSS or include your DSS instance.

For more details on U-Space integration, refer to our InterUSS section.

Can’t Find What You Need?​

We provide a robust real-time API available for general use. However, if your integration requirements are more complex, we offer dedicated support as part of our Enterprise subscription plan. Contact us to discuss your needs further.

This detailed guide will show you how to retrieve flight data from our API after completing flights with your Dronetag devices.

There are two main approaches depending on what flight details you have. You can either retrieve a list of past flights, select one, and gather all available data for that specific flight, or if you only know the general time frame and location, you can pull a segment of the airspace history. Both options are supported via our REST API.

Retrieving Telemetry for a Single Flight​

This method allows you to retrieve the full telemetry history for one specific flight from a single device. The API response will provide data collected by that device.

1. Authenticate Your API Requests​

   Before proceeding, ensure you have access to the necessary resources. Visit the authentication guide for instructions on how to authenticate your API requests.

2. List Available Flights​

   get/v1/flights/ see API docs »

   Retrieve a list of available flights associated with your authenticated Dronetag account. Take note of the id of the flight you’re interested in.

3. Request the Flight's Telemetry Data​

   get/v2/airspace/telemetry/ua see API docs »

   Use the flight’s id as the operation_id query parameter. This will give you the telemetry data for the selected flight without needing to specify time ranges or geographical areas.

   Our telemetry endpoints support multiple output formats. Choose your preferred format and set it in the Accept header of your request.

   You can also access additional telemetry streams for tracking the UA operator or the RID system.
   For more details, check out the DUMP guide.

   Note

   You may notice a /v1/flights/{id}/telemetry endpoint. However, we recommend using the v2 endpoint, as v1 is planned for deprecation.

Retrieving Airspace History​

This method allows you to pull historical airspace data for a defined location and time period.

1. Authenticate Your API Requests​

   Ensure you have access to the necessary resources. Visit the authentication guide for instructions on how to authenticate your API requests.

2. Choose Your Parameters​

   Based on the information you have, you can retrieve airspace history by either:

   • Specifying a time range (from, to) and geographical region (bbox), or
   • Specifying a time range (from, to) and UAS ID (device serial number, uas_id).

3. Request the Airspace Telemetry Data​

   get/v2/airspace/telemetry/ua see API docs »

   Select your preferred output format and set it in the Accept header of your request.

   You can also access additional telemetry streams for tracking the UA operator or the RID system.
   Learn more about these telemetry types in the DUMP guide.

4. Request Operation Details​

   get/v2/airspace/operation/{operation_id} see API docs »

   While the previous request provides telemetry data, it does not include all the information about the flight, such as the UA's identification and type. To gather additional details, use the Operation API endpoint to retrieve more comprehensive operation information.

This guide explains how to access and visualize real-time telemetry, typically by using a combination of the REST API and real-time Socket.io to monitor airspace activity in real-time.

1. Authenticate Your API Requests​

   Make sure you have the required access to the necessary resources. For detailed instructions, refer to the authentication guide.

2. Set Your Observation Parameters​

   Decide whether you want to monitor a specific geographical area (bbox) or a particular device (uas_id).

   Note: The geographical region has limitations. Large areas such as continents or countries cannot be observed. For details, see the REST API guide.

3. (Optional) Make an Initial Request to Get the Airspace State​

   get/v2/airspace/telemetry/ua?from=-00:05:00&bbox=... see API docs »

   Before starting real-time updates, we recommend fetching the initial airspace state. This helps initialize your application’s state. For example, retrieve the last 5 minutes of airspace data to create a starting point for real-time monitoring.

4. Receive Real-Time Telemetry Updates​

   Option 1: Connect to Socket.io for Real-Time Updates​

   wswss://api.dronetag.app/v2/airspace/socket.io telemetry_ua see API docs »

   Using Socket.io allows you to receive real-time updates with low latency, without needing to worry about time range query parameters. This is the preferred option for responsive applications.

   Option 2: Poll the REST API for Updates​

   get/v2/airspace/telemetry/ua?from=$last_date&bbox=... see API docs »

   Alternatively, you can periodically poll the API for updates. However, this approach is less efficient for applications that need frequent updates.

   If you choose this option, ensure you use the Date header (needs to be converted to ISO 8601) from the last response for the from parameter in subsequent calls, to avoid receiving duplicate data.

   Not Recommended

   Polling is generally not suitable for high-frequency updates. Polling this endpoint with high frequency (> 1 per second) can result in rate limiting errors.

5. Retrieve Operation Details​

   While telemetry data provides real-time flight information, it may not include essential details such as UA identification and type. You can retrieve additional information about the operation itself.

   Option 1: Listen for Operation Updates via Socket.io​

   wswss://api.dronetag.app/v2/airspace/socket.io operation see API docs »

   With Socket.io, you can listen to the operation channel for updates when a new operation is created or existing operations are modified. However, network interruptions can cause data loss, so it's best to combine this with occasional HTTP requests to ensure your application remains in sync.

   Option 2: Use HTTP Requests as Needed​

   get/v2/airspace/operations/{operation_id} see API docs »

   When necessary, you can request the operation details via the Operation API using the operation_id. This will give you the stored information about the airspace operation.

6. Keep Your Viewport Up-to-Date​

   If your application displays a dynamic map or the area of interest changes over time, ensure you update the bbox query parameter in your API requests or send viewport events when using Socket.io.

   For more information, refer to the API documentation and the Socket.io guide.

You can also access additional telemetry streams for tracking the UA operator or the RID system in real time. For more details, see the DUMP guide.

This guide explains how you can monitor the real-time status of your Dronetag device, such as battery charge, LTE, and GNSS signal strengths, and other key metrics. You can retrieve this data using either the REST API or the real-time Socket.io API.

Key Differences from Other Telemetry Types​

Unlike other telemetry data such as Telemetry-UA or Telemetry-Operator, which are sent frequently, telemetry related to the device’s system status (Telemetry-System) is generally sent at lower intervals—typically every 10 to 15 seconds or more.

Learn more about all telemetry types in the DUMP guide.

Monitoring a Specific Device Using UAS ID​

To retrieve the status of your Dronetag device in real-time, you must use the device’s UAS ID, which is equivalent to the serial number of the Dronetag device. Unlike other telemetry types that allow observation based on a geographical region (via bbox), this endpoint does not support monitoring by geographical region. Instead, you’ll need to specify the UAS ID to access data for a particular device.

1. Authenticate Your API Requests​

   Ensure you have access to the necessary resources by authenticating your API requests. You can find more details on the authentication process in the authentication guide.

2. Identify the Device by UAS ID​

   Before making any requests, confirm the UAS ID (serial number) of the device you wish to observe. You can find the UAS ID on the physical Dronetag device, within your account settings in the Dronetag App, or in other API responses.

3. Request Real-Time System Status Data​

   Option 1: Retrieve Data via REST API​

   To access the device's real-time status data through the REST API, use the following endpoint:

   get/v2/airspace/telemetry/system see API docs »

   Set the uas_id query parameter to the serial number of the Dronetag device, and define a time range using the from parameter, or both from and to.

   Option 2: Real-Time Updates via Socket.io API​

   Not available yet

   This option is not yet available

   wswss://api.dronetag.app/v2/airspace/socket.io telemetry_system see API docs »

   For real-time updates, connect to the telemetry_system channel via Socket.io. This method delivers lower-latency updates compared to REST polling.

All of our cloud-connected Dronetag products can be integrated with TAK Server by using our integration portal and can stream their Drone Remote ID data in the Cursor on Target (CoT) format directly to your TAK server in real-time.

Network Remote ID (NRI) devices (such as Dronetag Mini) can stream their UA positions. Direct Remote ID (DRI) receivers (such as Dronetag RIDER or Dronetag Scout) can additionally stream the operator location, and the location of the receiver itself.

Prerequisites​

Before you begin, ensure you have:

• Dronetag account (create at https://dronetag.app/signup)
• Supported Dronetag product(s) registered on your account
  • Supported are Dronetag Mini, Dronetag Mini 4G, Dronetag RIDER, or Dronetag Scout
• Active Pro or Enterprise subscription plan (required for integration portal access)
• TAK Server instance
  • With publicly accessible TAK Server endpoint (IP address or domain name)

How to Set-up​

1. Configure your TAK Server​

   Before setting up the integration, ensure your TAK Server is ready:

   1. Open the required port on your firewall
   2. Configure TAK Server to accept data feeds on this port
   3. Note your connection details:
      • Server IP or domain (e.g., tak.yourcompany.com or 203.0.100.200)
      • Port number (e.g., 8087)

   If unfamiliar with TAK Server configuration, refer to the official TAK Server documentation.

2. Access the Integration Portal​

   Visit https://integrations.dronetag.app and sign in using your account credentials

3. Create New Distribution​

   Create a new distribution using the following configuration:

   Required Settings​

   • Connection type — TCP or UDP Socket
   • Target URI — Your TAK Server address (e.g., tak.yourcompany.com or 203.0.100.200)
   • Target port — Your TAK Server port (e.g., 8087)
   • Output format — Cursor on Target XML

   Leave the other options to default values, or customize to your preferences. Please note that not all options are relevant to TCP+XML integration.

   Data Source Selection​

   Take note of the selected data source. The default, "My account", streams data from all devices registered to your account. Other options include "Device Groups" (a static list of devices) and "Partnered Integration" (allows any Dronetag user to share data to your TAK server). Contact us for details.

   Optional mTLS Authentication​

   If your TAK Server requires mutual TLS authentication, enable the mTLS option and upload the necessary client certificate and private key files in PEM format. This option is available only for TCP connections.

4. Verify the Connection​

   • Allow 2-3 minutes for the integration to initialize and establish connection
   • Turn on your Dronetag device and ensure it's actively transmitting
   • Open your TAK client (ATAK, WinTAK, or iTAK), look for the drone icon appearing on your map at the device's location
   • Verify position updates are occurring in real-time

Troubleshooting​

If you're experiencing issues, try these steps in order:

1. Verify TAK Server connectivity — Ensure your TAK Server IP/domain is correct and publicly accessible. Check that firewall rules allow incoming connections on the specified port.

2. Check device status — Confirm your Dronetag device is powered on, has GNSS lock, shows as "Online" and is visible on the map in your account at https://dronetag.app.

3. Review integration portal logs — Check the "Server logs" section in the integration portal and refresh the view several times (logs are not real-time). Look for connection errors or status messages.

4. Allow time for initialization — The integration needs 2-3 minutes to establish connection. If issues persist beyond this, restart the distribution in the integration portal by disabling and re-enabling the distribution.

If problems persist, contact support with your server logs and configuration details.

Relevant Resources​

• Getting started with Data Push integrations
• TAK Server Official Documentation Resources
• Contact Dronetag Support

When using our API, you will encounter three distinct altitude values related to flight telemetry data points. This section provides an overview of what these values represent, how they are obtained, and how you can utilize them in your applications.

Altitude Values​

• WGS84 HAE (Height Above Ellipsoid) — Altitude above the WGS84 ellipsoid, in meters

  • This is the raw altitude reported directly by the internal GNSS sensor onboard Dronetag devices.
  • It represents the height above the ellipsoid (not the geoid or Mean Sea Level). This is sometimes mistakenly interpreted as MSL, but it’s important to note that WGS84-HAE refers to the ellipsoid height, not sea level.
  • This altitude can have variable accuracy depending on GNSS signal conditions and the limitations of the earth model stored in GNSS receivers.
  • In APIs available as HAE-WGS84

• QNE (Pressure Altitude) — Altitude calculated from barometric pressure, in meters

  • This value is derived from the onboard barometer using a standard sea-level pressure of 1013.25 hPa (QNE).
  • It is highly accurate for relative measurements, such as comparing altitudes of nearby drones, but it may not represent an accurate absolute altitude compared to the ground.
  • Often used in aviation for standard altitude readings, especially when flying at higher altitudes where atmospheric pressure decreases predictably.
  • In APIs available as PA-QNE

• ATO (Above Takeoff Level) — Altitude above takeoff point, in meters

  • This value is calculated as the difference between the current QNE (pressure altitude) and the pressure altitude at the moment of takeoff.
  • It provides a relative height above the initial takeoff point, which can be useful for determining altitude changes during a flight.
  • ATO values are sensitive to atmospheric pressure changes over time, meaning accuracy may degrade during longer flights or significant weather changes.
  • This altitude can sometimes be perceived as AGL (Above Ground Level) when the environment remains consistent and flight has taken off at ground.
  • In APIs available as ATO

Frequently Asked Questions​

Why isn’t there a reliable AGL (Above Ground Level) altitude?​

The device telemetry has no AGL altitude because our devices do not have sensors capable of directly measuring the distance to the ground or terrain at all locations globally. Without consistent and accurate ground-level pressure or elevation data, calculating true AGL altitude is unreliable.

However, users can calculate their own AGL estimates if they have access to reliable ground-level pressure data from their region. Using the raw pressure values reported by the device, you could compare them to known ground-level pressure to estimate the altitude.

Flight and detection exports do include an estimated AGL. Dronetag calculates it from the sea-level altitude and a terrain model and states how accurate it is. Over forest and in towns it can read low. See Altitudes Explained.

Why does my ATO altitude sometimes show negative values?​

The ATO field is calculated relative to the recorded pressure altitude at takeoff. There are two key factors that can cause negative values:

1. Takeoff Pressure: If you start tracking your flight when the drone is already airborne (e.g., 10m above the ground), the takeoff pressure will reflect that height. When the drone lands, the height will then show a negative value (e.g., -10m) because it's now below the original takeoff point.

2. Pressure Changes Over Time: Atmospheric pressure changes throughout the day due to weather conditions. If you're tracking a long flight that spans hours, the height might gradually drift because the reference pressure from takeoff no longer matches the current ground pressure. This can lead to incorrect readings, especially for long-duration flights.

Why does my commercial drone show AGL altitudes, but Dronetag does not?​

Most commercial drones do not actually show AGL altitude; instead, they use a method similar to our ATO (height above takeoff). The drone's controller records the takeoff pressure and subsequently displays the difference between the takeoff altitude and the current altitude. This is presented as the drone's height above ground, even though it's technically just height relative to the takeoff point, not true AGL.

The DUMP (Dronetag Unified Message Protocol) is Dronetag's internal messaging format, used consistently across all our services. Whether you are interacting with our REST API, Socket.io, or integrating through our portal, you can rely on DUMP to be the standard data exchange format.

The current version is DUMP v1.

DUMP supports the following message types:​

• Operation ⏺︎
• OperationUpdate ⏺︎
• Telemetry-UA ⏺︎ (often shortened as TELE-UA)
• Telemetry-Operator ⏺︎ (TELE-Operator)
• Telemetry-System ⏺︎ (TELE-System)

The details of these message types, including when and how they are used, are explained further below.

DUMP Message Types​

Operation (or OperationUpdate)​

📋 See the full JSON schema in our API documentation

An Operation message contains static information about a specific flight. The purpose of separating this data into an operation object is to avoid repeating unchanged information, such as the drone’s serial number or the Remote ID (RID) module’s ID, in every telemetry message.

It’s important to understand that a single operation may not always correspond directly to a single flight. In cases where a flight is recorded using multiple systems—like a combination of Network Remote ID and ground-based Direct Remote ID receivers—the flight might be divided into multiple operations.

The difference between Operation and OperationUpdate is significant. The Operation message represents the full state of the flight at the time of the request and is returned when you query through the REST API. On the other hand, OperationUpdate messages represent partial updates, sent primarily in real-time scenarios (e.g., via Socket.io or our integration portal). OperationUpdate only includes recent changes, not the entire state.

Example​

{
  "id": "a45cb00e-b600-4111-bd52-42537c28feb3",
  "status": "current",
  "uas_operator_id": "FIN87astrdge12k8",
  "ua_classification": "class1",
  "ua_classification_type": "open",
  "ua_identifiers": [
    {
      "type": "serial_number",
      "value": "15968AB92D361"
    },
    {
      "type": "caa_assigned",
      "value": "JA.JU12345ABCDE"
    }
  ],
  "authentication": [],
  "descriptions": []
}

Telemetry-UA​

📋 See the full JSON schema in our API documentation

The Telemetry-UA message is the primary data object for Remote ID. It provides a snapshot of the unmanned aircraft’s (UA) geographical position, status, and other relevant information required by Remote ID regulations.

Each Telemetry-UA message is associated with an Operation through the operation_id field. Every Remote ID-enabled device generates Telemetry-UA messages during operation.

Example​

{
  "operation_id": "a45cb00e-b600-4111-bd52-42537c28feb3",
  "timestamp": "2024-10-05T10:15:06.100Z",
  "timestamp_accuracy": 0.1,
  "operational_state": "airborne",
  "location": {
    "latitude": 50.073873, "longitude": 14.466586, "accuracy": 50
  },
  "altitudes": [
    { "type": "WGS84", "value": 192.5, "accuracy": 10 },
    { "type": "QNE", "value": 323.1, "accuracy": 0.5 },
    { "type": "AGL", "value": -10.0, "accuracy": 0.5 }
  ],
  "velocity": {
    "heading": 92, "horizontal_speed": 9.72, "vertical_speed": 1.22, "speed_accuracy": 0.5
  },
  "air_pressure": 1017.712
}

Telemetry-Operator​

📋 See the full JSON schema in our API documentation

The Telemetry-Operator message tracks the operator’s location. Some UAV systems report the pilot’s real-time position through their control equipment. Standard Remote ID drones can provide operator tracking, while Remote ID modules typically only supply the takeoff location.

Example​

{
  "operation_id": "a45cb00e-b600-4111-bd52-42537c28feb3",
  "timestamp": "2024-10-05T10:15:06.100Z",
  "timestamp_accuracy": 0.1,
  "location": {
    "latitude": 50.073873, "longitude": 14.466586, "accuracy": 50
  },
  "altitude": { 
    "type": "WGS84", "value": 202.5, "accuracy": 10
  },
  "source_type": "take_off"
}

Telemetry-System​

📋 See the full JSON schema in our API documentation

The Telemetry-System message provides information about the status of the Remote ID module itself, rather than the aircraft. It includes details on battery charge, GNSS connectivity, LTE signal, and other system parameters. Currently, only Dronetag devices generate Telemetry-System messages.

Example​

{
  "operation_id": "a45cb00e-b600-4111-bd52-42537c28feb3",
  "timestamp": "2024-10-05T10:15:06.100Z",
  "timestamp_accuracy": 0.1,
  "system_type": "rid_module",
  "system_status": "operational",
  "power_source": {
    "type": "battery",
    "input_voltage": 4.11,
    "charge_percentage": 90,
    "is_being_charged": false
  },
  "lte_connectivity": {
    "status": "connected",
    "rsrq": -10,
    "rsrp": -97,
    "snr": 9,
    "tac": "291E",
    "cell_id": "555CA02"
  },
  "gnss_connectivity": {
    "status": "connected",
    "satellites": 12
  }
}

The Dronetag ATAK Plugin connects a Dronetag RIDER to ATAK (Android Team Awareness Kit) over a USB-C cable or Bluetooth LE — no cellular data or cloud connectivity required. Every drone (and pilot) detection decoded by RIDER appears as a live track on the ATAK map and is shared with the rest of your TAK network via CoT (Cursor on Target).

Because it works entirely over USB or Bluetooth, the plugin keeps working in terrain with poor or no cellular coverage — exactly where RIDER and ATAK are most often used together.

Prerequisites​

Before you begin, make sure you have:

• ATAK-CIV installed, version 5.6.0 or later (check under Settings → About ATAK)
• Android 11 or later
• A Dronetag RIDER, with a USB-C cable or paired over Bluetooth LE

Installing the plugin​

The plugin is distributed through the Play Store, under the Dronetag developer account:

Install it like any other Android app. Because it's an ATAK plugin, not a standalone app, it won't appear with its own icon on your home screen — opening it always happens from inside ATAK.

Checking that the plugin loaded​

The first time a new plugin is installed, ATAK requires you to approve it before it loads. Open Settings → Tool Preferences → Package Management:

Look for Dronetag ATAK Plugin in the list:

• Loaded (green, checked) — the plugin is active and ready to use.
• Unloaded / unchecked — tap the checkbox next to it to load it.

Main UI​

Once loaded, the plugin adds a Dronetag tile to ATAK's tools menu (the hamburger icon in the top toolbar → Tools). It sits near the end of the tools grid, after the built-in tools:

Tapping it opens the Dronetag side panel, which is your main interface — a running list of all current detections, and a Device Manager button in the top-right corner to manage your RIDER connection:

Connecting your RIDER​

Open Device Manager (top-right of the Dronetag panel) to manage connections:

• USB cable — turn this on and plug your RIDER in with a USB-C cable. ATAK will prompt for USB permission the first time.
• Test beacon — see Using the test device below.
• Scan for devices — searches for nearby RIDERs over Bluetooth LE and lists any found so you can connect:

Information displayed​

Tap any entry in the detections list to open its detail page:

This shows everything decoded from the drone's Remote ID broadcast: status, UID, serial number, callsign, affiliation, the technology used (Bluetooth or Wi-Fi), signal strength, position, altitude, height above ground, speed, vertical speed, heading, and when it was first/last seen. If the broadcast includes a pilot location, a separate pilot marker appears on the map linked to the same drone.

From this page you can also:

• Callsign — set a custom callsign for this detection, overriding the default name:

  

• Details — look up the maker, model, and specifications of the aircraft, when identifiable from its serial number

• Show on map — center the map on this detection

• Back — return to the detections list

Using the test device​

The Test beacon, toggled on from Device Manager, simulates a synthetic drone orbiting your own location — no real RIDER or real drone required. It's useful for:

• Verifying connectivity: confirming the full pipeline (plugin → ATAK → CoT → your TAK server) works before you need it in the field
• Demonstrating the plugin: showing a team how detections look and behave without waiting for real air traffic

It behaves exactly like a real detection — it appears in the list, has a position and heading, and can be renamed or inspected the same way — so it's a safe way to learn the UI before your first real deployment.

Settings​

The plugin's own settings live under Settings → Tool Preferences → Specific Tool Preferences → Dronetag ATAK Plugin:

Detections

• Mark stale after — how long a detection can go without an update before it's shown as stale on the map
• Remove after — how long before a stale detection is removed from the list and map entirely

Callsigns — see below.

Working with the Callsign list​

Instead of naming detections one at a time, you can bulk-assign callsigns and affiliations from a CSV file:

1. Prepare a CSV with one row per known drone:

   SN,Callsign,{friendly,hostile,neutral}
   

   For example:

   1596M0170424A1234,Patrol 1,friendly
   1596M0170424A5678,Unknown Contact,hostile
   

2. Go to Settings → Tool Preferences → Specific Tool Preferences → Dronetag ATAK Plugin → Callsign CSV file, and pick the file using ATAK's file browser.
3. The plugin matches detections to rows by serial number, applying the callsign and affiliation from the matching row.

A few things worth knowing:

• The CSV is reloaded automatically whenever the file changes — no need to reselect it after an edit.
• A manual callsign set from a detection's detail page (see Information displayed) always takes priority over the CSV for that detection.
• If a detection's serial isn't in the CSV, it falls back to a generated name (Drone <last 4 characters of serial>).
• Clear callsign CSV stops using the file entirely — all detections fall back to their default names and affiliations.

Dronetag provides a simulation tool called Mocker that lets you test your integration during development without a physical device. With Mocker, you can create virtual flights and verify that your system correctly receives and processes Dronetag data.

👉 https://mocker.dronetag.app

Prerequisites​

• Dronetag account — create one for free if you don't have one
• Virtual Mocker device registered to your account (see below)
• Access to the Mocker application — typically granted along with your first virtual device

Obtaining virtual devices​

To get a virtual device, contact us with your Dronetag account details. We are generally happy to provide virtual devices for testing and development purposes. Once a virtual device is registered to your account, you can use it to simulate flights and test your integration.

Creating a simulation​

Mocker supports two simulation engines depending on the type of device you want to simulate:

NRI device simulation (nri_via_live)​

An NRI simulation mimics a device that reports its own position to the network. Only one identifier is needed because the simulated device reports itself.

1. Open the Mocker application and sign in
2. Tap anywhere on the map to place a new simulation
3. Select the nri_via_live engine
4. Choose a flight scenario
5. Under UAS Identifier, select one of your Mocker devices — it will act as the NRI device
6. Configure any remaining parameters for your chosen scenario and click Create

DRI receiver device simulation (dri_via_funnel)​

A DRI receiver simulation mimics a device that detects and reports nearby Remote ID aircraft. This requires two identifiers: one for the receiver and one for the detected aircraft.

1. Open the Mocker application and sign in
2. Tap anywhere on the map to place a new simulation
3. Select the dri_via_funnel engine
4. Choose a flight scenario
5. Under UAS Identifier, enter any valid Remote ID ANSI serial number — this represents the aircraft that your receiver detects
6. Under Sensor ID, select one of your Mocker devices — it will act as the DRI receiver
7. Configure any remaining parameters for your chosen scenario and click Create

Controlling simulations​

Once created, the simulated device appears on the map and in the left sidebar. From the sidebar you can:

• Pause the simulation
• End the simulation gracefully
• Force kill the simulation — use this only to test a lost-connection scenario

Dronetag exports flights and detections in a few file formats. The formats are the same wherever you export from, for example the Dronetag App, the Dronetag Export service or your own software through the Dronetag API. This section describes the files. What you can choose in each place is described on that place's own page, such as Exporting Data in the Dronetag App.

This page helps you pick a format.

A flight is reported by a Dronetag device on your own drone. A detection is a drone that one or more of your receivers heard, for example a Dronetag Scout. Flights and detections use the same file formats. A detection fills in a few extra fields, such as which receiver heard it.

Pick a Format​

KML is the same map as KMZ, but without the icons and the colour legend. Google Earth shows its own default pins instead. Choose KML only if a tool can't open KMZ.

With Tracks or Summary​

JSON and CSV come in two versions. You pick one when you export.

• With tracks has every recorded position. This is the default.
• Summary has one entry per flight or detection, without the positions.

The figures in a Summary are still calculated from the whole track. Choose Summary when you export many flights. For 80 flights, a Summary is a few hundred kilobytes and With tracks is tens of megabytes.

Units and Times​

JSON and CSV always use metres, metres per second, degrees and seconds. Their times are in UTC.

KMZ and PDF use metric units, or imperial ones where the place you export from lets you choose. Their times are also in UTC, marked "(UTC)".

File Names​

Detections say operations or operation instead of flights or flight. A Summary ends in -summary instead of -telemetry. A zip has the same name with the extension .zip. Dates and times in file names are in UTC.

Format Versions​

JSON, CSV Telemetry and CSV Summary are all version 1.0, and each has its own version. When something is only added, the second number goes up. When something is removed, renamed or changes meaning, the first number goes up. If your software reads JSON, read schema_version and check the first number before you read the rest.

When You Get a Zip File​

A CSV can arrive in a zip together with a file called ATTRIBUTION.txt. This happens when heights in the CSV were calculated from terrain data that must be credited. Keep the two files together when you pass the data on. See Terrain Data and Attribution.

Some places also put several formats, or a large selection split into parts, into one zip.

Files Safe to Share Publicly​

Some places can make a file that is safe to share publicly. The file then leaves out the pilot's name and ID, the pilot's positions and the take-off point. It also leaves out the callsign, the Self-ID text, the return-to-home point and the receivers that heard a detection.

Serial numbers keep their first four and last four characters. Registration numbers and operator IDs are hidden completely. The drone's own track stays in the file.

Example Files​

The examples on these pages come from these files. They are synthetic. Every name, serial number, receiver and registration in them is invented.

In a real download the file names follow the pattern under File Names, and each of these CSVs would arrive in a zip with its ATTRIBUTION.txt.

CSV Telemetry is the CSV you get with With tracks. It has one row for every recorded position. The file name ends in -telemetry.csv.

Flights and detections use the same 15 columns in the same order. A column that one kind never fills stays empty.

Columns​

The five altitude columns are explained in Altitudes Explained.

An empty cell means the value wasn't reported and Dronetag couldn't calculate it. A real zero, such as the speed of a hovering drone, is written as zero and never left empty.

CSV has no accuracies. If you need to know how exact a value is, use JSON.

Facts about the aircraft and the pilot are in CSV Summary. Its id column holds the same value as operation_id, so you can join the two files.

Example​

The first row of the example flight and of the example detection (synthetic data):

operation_id,timestamp,serial_number,sensor_id,operational_state,latitude,longitude,horizontal_speed,vertical_speed,heading,alt_hae_wgs84,alt_ato,alt_pressure,alt_msl,alt_agl
3f6b1c2e-8d4a-4b7f-9e21-5a0c7d3e9b14,2026-09-17T07:42:13.350390Z,1596CEXAMPLE00001,,,49.1679989,16.4950113,0.0,0.0,,327.1,0.08,255.81,282.13207082568454,0.43031044931819906
6d2f8a41-93c7-4e0b-b5d2-1f7a9c3e8b60,2026-09-22T15:31:04.048000Z,1581FEXAMPLE00000004,SCT-EXAMPLE-01,grounded,49.9599978,14.4999964,0.0,0.0,0.0,400.3,0.0,327.7,354.9,1.0917571914229143

The flight row has no receiver and no state. The detection row has both.

Opening It in Excel​

A CSV is written in one of two styles. Some places let you choose the style when you export.

• Decimal point writes 1.5 and separates columns with commas. It suits English-language Excel, Numbers and LibreOffice.
• Decimal comma writes 1,5 and separates columns with semicolons. It suits Czech, German and most other European set-ups.

When the style matches your Excel, double-click the file and it opens in columns. Accents and the degree sign display correctly.

If everything lands in one column, the file was written in the other style. Import it instead.

1. In Excel, choose Data → From Text/CSV and pick the file.
2. Set the delimiter to comma or semicolon.
3. If numbers come out as text, choose Transform Data, select the columns and use Change Type → Using Locale.

Numbers keep every digit the source reported. Format the cells in Excel if you want fewer decimals.

Reading It in a Program​

The file is UTF-8 with a byte order mark. In Python, open it with encoding="utf-8-sig". Lines end in CRLF and times end in Z (UTC). Numbers have full precision and no thousands separators. The header always has the same 15 columns.

If You Get a Zip File​

When alt_msl or alt_agl came from terrain data that must be credited, the CSV arrives in a zip with ATTRIBUTION.txt. Keep the two files together. See Terrain Data and Attribution.

CSV Summary is the CSV you get with Summary. It has one row for each flight or detection. It doesn't contain the positions. The file name ends in -summary.csv.

Flights and detections use the same 37 columns in the same order. The figures are calculated from the whole track, exactly as in a With tracks export.

Columns​

The Who column says which kind fills the column. F means flights, D means detections.

Identity​

Aircraft and Operator​

When​

Where​

The first and last positions are where the record starts and ends. They are often not the take-off and landing, because a receiver starts hearing a drone when it comes into range.

How Far and How Fast​

operator_track_kind tells you what the pilot position is. operator is the pilot's real position. take_off means the drone sent only its take-off location, so the distances are measured from there. mixed is some of each.

Altitudes​

There are no minimums. See Altitudes Explained.

Status Values​

Only in JSON​

CSV Summary keeps to the fields most people need. These are only in JSON:

• Accuracies.
• Start and end times as the source states them. These can differ from the first and last position.
• The return-to-home point and the declared operation area of a flight.
• Rare identifiers, the Self-ID text and the flight's colour.

Example​

One example flight and one example detection (synthetic data):

id,status,sensor_ids,serial_number,callsign,caa_assigned,aircraft_manufacturer,aircraft_model,aircraft_category,ua_classification,uas_operator_id,pilot_id,pilot_name,message_count,duration,time_first_telemetry,time_last_telemetry,take_off_latitude,take_off_longitude,first_latitude,first_longitude,last_latitude,last_longitude,min_latitude,max_latitude,min_longitude,max_longitude,point_count,total_distance,max_horizontal_speed,operator_track_kind,max_operator_distance,operator_movement_extent,transmission_technologies,max_alt_ato,max_alt_msl,max_alt_agl
3f6b1c2e-8d4a-4b7f-9e21-5a0c7d3e9b14,finished,,1596CEXAMPLE00001,EXAMPLE-FLIGHT-1,,,DJI Matrice 350 RTK,,,CZEexampleoper01,9b6b1c2e-8d4a-4b7f-9e21-5a0c7d3e9b14,Tomáš Example,,260.963047,2026-09-17T07:42:13.350390Z,2026-09-17T07:46:34.313437Z,49.1679989,16.4950113,49.1679989,16.4950113,49.168003,16.4949982,49.167991,49.1699201,16.4949881,16.4979653,262,1373.6529667703585,10.14401301260995,,,,,80.33,364.0258824461374,83.32078650204227
6d2f8a41-93c7-4e0b-b5d2-1f7a9c3e8b60,past,SCT-EXAMPLE-01|SCT-EXAMPLE-02,1581FEXAMPLE00000004,,OK-UAS-EXAMPLE-4,DJI,DJI Mavic 3,rotorcraft,open class_1,CZEexampleoper04,,,194,192.977,2026-09-22T15:31:04.048000Z,2026-09-22T15:34:17.025000Z,,,49.9599978,14.4999964,49.9599977,14.4999876,49.9599864,49.9620193,14.4999838,14.5036452,194,973.7599886011964,12.16,operator,261.9408504975598,44.46384785221796,wifi_beacon|wifi_nan,95.1,449.4,97.37793678299658

The same columns for three flights. The detection-only columns stay empty.

Joining It With CSV Telemetry​

id here and operation_id in CSV Telemetry hold the same value. Put both files in one workbook, with the summary on a sheet called Summary. In the telemetry sheet, add a column with this formula:

=XLOOKUP(A2, Summary!A:A, Summary!H:H)