Přeskočit na hlavní obsah

Sensor configuration

Scout Dronetag Forwarding

Integrations control where and how the Scout send telemetries. Scout can run multiple Forwarders in parallel. If any instance is not processing the data fast enough, other instances are not affected.

There are two basic forwarders:

  • Dronetag forwarders (one for Cloud and one for On-Premise) that can be only enabled/disabled and very basically configured
  • JSON forwarders are versatile and intended for user's integration.

See the data format description at the bottom of this page.

Dronetag Forwarders​

Scout Dronetag Forwarding

Dronetag Cloud is the only (user-visible) permanent forwarder. It cannot be deleted but can be disabled. By disabling the cloud forwarder, you will not be able to see the Scout nor its detections in Dronetag App.

You can add an On-Premise Dronetag integration to have full control of your data with all benefits of our cloud backend.

The Dronetag Forwarder can be used simultaneously with any other forwarders. For further details on how to operate the Scout in Cloud/On-Premise, please refer to this page.

JSON Forwarders​

JSON forwarders are intended for user integration.

All custom forwarders can be secured and support compression and batching.

Scout Dronetag Forwarding Basic MQTT Settings

It is better to specify port into URL, otherwise 1883 is used. For plane MQTT(s) protocol, only host:port is necessary. If you are going to use WebSockets then you can specify path as well, otherwise / will be used.

  • MQTT over WebSockets: Connect to MQTT broker using WebSockets instead of native MQTT protocol. Useful when you can only use HTTP/WebSocket connections (e.g., behind restrictive firewalls).
  • Drones Topic: MQTT topic for drone detections. Topics are like directories in a filesystem. Template: use {sn} for full serial or {sn4} for last 4 digits. Example: myorg/receivers/scout1/drones
  • Aviation Topic: Separate MQTT topic for aviation data. If empty, aviation data is sent to the Drones Topic.
  • Status Topic: Separate MQTT topic for Scout status/heartbeat. If empty, status is sent to the Drones Topic.

Here follows common options no matter the basic protocol (HTTP/MQTT).

Basic Settings​

These are the fundamental options required for every forwarder:

  • Enabled: Turn this forwarder on or off. When disabled, no data is sent through this forwarder.
  • URL: The destination where to send the data. Please, do not try to guess protocol - use clickable options to enable secured connection, mTLS and/or change the protocol to web sockets.
  • Sources: Select which types of data to forward: drones (detected drone telemetry), aviation (manned aircraft data from aviation module), status (Scout health and position updates). Please note that drones and aviation is restricted by global filter on altitude and radius.
  • Client Timeout: How long (in seconds) to wait for the server to respond before considering the connection broken. Default is 15 seconds. Increase this if your connection is not reliable or slow.

Batching​

Batching groups multiple messages before sending them. This reduces network traffic and server load but adds slight delay. Here you control those delays and how the data are formatted.

  • Enable Batching: Turn message batching on or off. Useful for high-volume scenarios.
  • Batch as JSON Array: When enabled, messages are grouped as [msg1, msg2, ...]. When disabled, messages are joined with a separator.
  • Items Separator: Character(s) between messages when batching is enabled: nothing (no separator), \r\n (carriage return + newline), or \n (newline).
  • Batch Size: Maximum number of messages to group before sending. Leave at 0 to disable, or set to a number like 100.
  • Batch Timeout: Maximum seconds to wait before sending a batch, even if it's not full. Example: 0.1 sends batches every 100ms. Disabled if set to 0.

Example: With Batch Size = 100 and Timeout = 0.1 seconds, batches are sent when either 100 messages arrive OR 0.1 seconds pass, whichever happens first.

Compression​

  • Compression: Reduce bandwidth usage by compressing data before sending. Beware that for HTTP the data is optionally compressed only when it makes sense. The compression is then noted in Content-Encoding header (with value "gzip"). If selected for MQTT, the data are compressed always because there is no way how to hint on data compression.

Security Settings​

Scout Dronetag Forwarding Security Settings

Configure how the Scout securely communicates with your server.

TLS/SSL Server Encryption​

This section relates ony to verification of server certificate. This is the most common part of security and you most likely need to get this right.

  • Secured: Enable TLS encryption for the connection. If your server uses HTTPS or MQTTs, enable this.
  • Verify Server Cert: Check if the server's certificate is valid and not expired. Disable only for testing with self-signed certificates. Warning: Disabling this makes you vulnerable to man-in-the-middle attacks.
  • Verify Server Domain/IP: Check if the certificate's hostname (CN field) matches the server you're connecting to. Enable this to prevent connection to impostor servers.
  • Server CA Certificate: Your custom CA certificate in PEM format (.pem or .crt file). This tells the Scout which certificate authority to trust. Typically needed when your organization has its own internal CA. Beware that it has to be the top-level CA in the server's certificate. Not an intermediate one.

Client Certificates​

This section allows you to specify your client certificates for mTLS. Quite usual in the MQTT world but more and more in HTTP also.

  • Client Certificate: Upload a certificate to authenticate the Scout to your server. Required if your server checks client certificates (mutual TLS). File format: PEM.
  • Client Private Key: The private key corresponding to your client certificate. Only needed if your key isn't embedded in the certificate file.
  • Client Key Password: If your private key is encrypted, enter the password here.

Authentication Settings​

For servers that require login credentials:

  • Username: Username for HTTP Basic Auth or MQTT authentication. Leave empty if using token-based authentication.
  • Password/Token: Password for Basic Auth or API token. Stored securely. For MQTT, this can be your password or token depending on your broker's configuration.

Sensors Range and Altitude Limiting​

Air Traffic Sensor Thresholds

You can select thresholds for drones and aviation data:

  • ignore thresholds (radius, altitude): object farther OR higher then the limits will be silently dropped
  • tracking thresholds (radius, altitude): objects closer AND lower then the limits will be tracked

Tracking means that the messages will not be rate limited. Every message will be forwarded. Rate-limiting means that only one message per (configurable) X seconds per object will be sent. Good limits are especially useful for aviation where average data consumption near a mid-sized airport with no limits is around 150MB/day.

Default limits​

By default, rate limiting and ignore is turned of for drones by settings all values to 0.

Aviation is limited by default because the air traffic visibility is on long distances that are not useful for normal operations. Hence the aviation traffic is limited to 100km radius and no altitude. Aviation tracking happens for any traffic within 10km radius and 1000m altitude (landing objects).

Formats​

All JSON-based forwarders support two formats: dri and odid. DRI format contains raw OpenDroneID message (as bytes) as it was received by the antenna. ODID message is parsed and transformed OpenDroneID message so it is more pleasant to work with.

Each message is sent separately unless Batching is configured. See above details about batching messages.

JSON ODID Fields​

KeyTypeExampleDescription
snstr1000033Serial number
macstrMAC in format XX:YY:ZZ:AA:BB:CC
counterint13Counter of received messages
rssiint-57Signal strength
techstr[2]B5Receiving tech: B4, B5, WN, WB
recv_idintReceiver ID
module_idint2Antenna/module number
module_typeint11Internal module type
msg_typeint15ODID message type
odiddict-This contains a preprocessed payload of the protocol. Regrading the possible values and message structure refer to ODID Library. Also for more details see the full protocol description bellow
warning

Textual JSON format with raw fields parsed from ODID sources bellow is just a representation formatted for clear understanding the format sent will additionally be:

  • No indentation the object will be always a single line since its send in JSONL
  • All Invalid fields are processed and converted to null (Example: Lat,Lon 0,0 is converted to null)

Example JSON ODID Messages​

{
    "sn": "D11234567812345678",
    "mac": "ab:ab:bc:bc:de:de",
    "counter": 24,
    "rssi": -83,
    "tech": "B4",
    "recv_id": 0,
    "module_id": 0,
    "module_type": 10,
    "msg_type": 1,
    "noise_floor": null,
    "odid": {
        "BasicID": [
            {
                "UAType": 15,
                "IDType": 1,
                "UASID": "159112345678"
            }
        ],
        "Location": {
            "Status": 2,
            "Direction": 202.0,
            "SpeedHorizontal": 16.5,
            "SpeedVertical": 0.0,
            "Latitude": 50.0835017,
            "Longitude": 14.4328954,
            "AltitudeBaro": 95.0,
            "AltitudeGeo": 0.0,
            "HeightType": 1,
            "Height": 163.0,
            "HorizAccuracy": 0,
            "VertAccuracy": 0,
            "BaroAccuracy": 0,
            "SpeedAccuracy": 0,
            "TSAccuracy": 0,
            "Timestamp": "2026-06-01T09:49:11",
            "TimestampEstimated": false
        },
        "SelfID": null,
        "System": null,
        "OperatorID": {
            "OperatorIdType": 0,
            "OperatorId": "d6lE0m0Hi2iNx"
        }
    }
}
warning

Bluetooth Legacy Eg. tech=B4 sends each message type (System, Location...) separately. PACKED messages are not supported over B4. Aggregation may be introduced later. Aggregation was introduced in ScoutOS 2026.05.29. Bluetooth Legacy messages are aggregated until a valid Location message arrives and then the whole aggregate is sent further as PACKED message. The aggregate is then dumped with every updated Location message because other fields rarely change.

  • Note: This behavior can be similar with the other technologies it depends on the implementation of the transmitter. Generally Wifi Beacon, Wifi NaN and Bluetooth 5 Long range sends all of the information in single pack but it is not guaranteed. We do not know any transmitter that would do so but it is possible. So take into account that not all of the information has to be valid when processing to prevent unnecessary crashes.

Heartbeat/Status​

If you select status source for your forwarder, you will receive status message every *60 s These messages contain:

  • Basic device information
  • GNSS position (when GNSS is enabled)
  • LTE network status (when an LTE modem is present)
  • Sensors details

Example Heartbeat message:

{
    "sn": "D11234567812345678",
    "timestamp": 1780310741,
    "receivers": 2,
    "last_observation": 1780310741,
    "gnss_available": true,
    "gnss_position": [
        50.073992633,
        14.466609883
    ],
    "gnss_satellites": 6,
    "gnss_altitude": 262.5,
    "gsm": {
        "enabled": true,
        "state": "connected",
        "quality": 100,
        "tech": "lte"
    },
    "sensors": [
        {
            "id": "RW1",
            "uid": 2,
            "source": "wifi/dri_wlp1s0u1u2",
            "state": "ok",
            "timestamp": 1780310741.7995672,
            "tech": "RemoteID",
            "messages": 0,
            "filtered": 0,
            "last_message_at": 0,
            "last_status_at": 0,
            "extras": {
                "module_type": 10,
                "module_type_name": "RW1",
                "module_revision": 0
            }
        },
        {
            "id": "ADS-B",
            "uid": 18873,
            "source": "18873",
            "state": "ok",
            "timestamp": 1780310741.7998254,
            "tech": "ADS-B",
            "messages": 32588,
            "filtered": 32588,
            "last_message_at": 1780310741,
            "last_status_at": 0,
            "extras": {
                "export_running": false,
                "export_size": 0
            }
        }
    ]
}

Datasheet download​

Download PDF (v2.4)