Přeskočit na hlavní obsah

Sensor configuration

On this page you will find a detailed description on how to configure forwarding and heartbeat functionality of the Scout in the Sensor mode. For full description of the capabilities and concept please refer to the Sensor mode page.

Scout Dronetag Forwarding

Forwarders​

Scout can run multiple Forwarders in parallel. Each Forwarder instance pushes telemetry to its own destination using its own protocol/format settings. If the given instance is not processing the data sent to it fast enough only that instance is affected. The Scout has two pre-defined forwarders available in the configuration UI each can be disable if not desired.

The Dronetag Forwarder can be used simultaneously with any other forwarder this is mainly intended for the Cloud/On-premise for further details on how to operate the Scout in Cloud/On-premise refer to this page.

The Local Map Forwarder is builtin as quick way on how to check the data received by the Scout. This data are visualized by the Sample Map in the Sensor mode described bellow.

Sample Map for Scout in Sensor Mode​

Scout Local Map

The Sample Map is a built-in demonstration tool used to visualize detection data from the Dronetag Scout in Sensor Mode. It offers a quick way to verify that the Scout is properly receiving and processing nearby drone data.

This tool is also available as an open-source reference project on GitHub:
👉 scout‑sensor‑demo‑map

It is not intended for production use, as it lacks advanced features like:

  • Alerts or notifications
  • Persistent historical data
  • Export capabilities

All data is stored in memory and is cleared when the webpage is closed.

note

This map is intended as a development reference and a basic visualization tool. It displays the real-time positions and trajectories of detected drones along with the Scout’s own location.

warning

This demo map will be deprecated in future releases and replaced by a full-featured application running directly on the Scout—DroneScanner. DroneScanner will be a part of Sensor+ Mode, offering persistent history, data export, and advanced scanning features.

Pre‑defined Forwarders​

ForwarderDescription
Dronetag ForwarderUses Dronetag’s protobuf-based format for on‑prem or Cloud ingestion.
Local Map ForwarderPublishes json+odid to a sample map served at http://<SCOUT_IP>/map.
Scout Forwarding

Currently, we support specification of additional two forwarders in our UI. Each forwarder can specify a protocol, URL and Format. In the future, we might add an option on how to specify more, if needed.

  1. Select Protocol from the combobox
  2. Enter URL in format described bellow
  3. Select desired payload format from the combobox
  4. (Optionally) Select desired batching options
  5. Apply the forwarder by clicking on the Update Forwarding button

Batching Behavior​

Forwarders support configurable batching to reduce load and network overhead:

  • Default batch size: 100 entries
  • Default timeout: 0.1 seconds

This means data is buffered until either:

  • 100 messages are collected, or
  • 0.1 seconds have elapsed since the last batch was sent

...whichever happens first. Both parameters are configurable per forwarder.

Supported Protocols & URL Schemes​

The HTTP/HTTPS protocol sends the selected payload format via a POST method to the URL. THe HTTP/HTTPS URL is capable of adding a custom headers. This can be leveraged to implement a basic authorization against your sever in form of static tokens or HTTP/HTTPS basic authorization.

URL format

http(s)://[[header-name:header-value][,other-header:other-value...]@]host:port/path

Static HTTP headers can be embedded in the user‑info part of the URL, separated by commas.

Example

http://Authorization:Bearer jlsadoHIO@nkad=@myserver.cz:8081/dronetag/odid
warning

Dynamic authentication mechanisms (e.g. OAuth 2) are not supported yet.

Custom/Internal Trust​

Some of the protocols, described above, needs for its operation a trusted certificate authority. Generally common issues, traditionally available on the internet, are included. For use with Custom or Internal authorities in tightly controlled enviroment, that do not have access to internet, refer to the System Configuration for adding a trusted CA.

Payload Formats​

All JSON-based forwarders (e.g., json+dronetag, json+odid) use the JSON Lines (JSONL) format. This means:

  • Each entry is a standalone JSON object placed on a separate line
  • The overall payload is not wrapped in an array; it is newline-delimited for easy streaming and processing

Example​

{"sn": "1000033", "rssi": -57, "tech": "B5", ...}
{"sn": "1000044", "rssi": -60, "tech": "B4", ...}

Top-Level 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​

{
  "rssi": -92,
  "tech": "B5",
  "recv_id": 2,
  "module_id": 0,
  "module_type": 11,
  "msg_type": 15,
  "odid": {
    "BasicID": [{"UAType": 0, "IDType": 1, "UASID": "1596F359746167260079"}],
    "Location": {
      "Status": 1,
      "Direction": null,
      "SpeedHorizontal": null,
      "SpeedVertical": null,
      "Latitude": null,
      "Longitude": null,
      "AltitudeBaro": -23.5,
      "AltitudeGeo": null,
      "HeightType": 0,
      "Height": 0.0,
      "HorizAccuracy": 0,
      "VertAccuracy": 0,
      "BaroAccuracy": 0,
      "SpeedAccuracy": 0,
      "TSAccuracy": 0,
      "Timestamp": "2025-04-06T06:22:58"
    },
    "SelfID": null,
    "System": {
      "OperatorLocationType": 0,
      "ClassificationType": 1,
      "OperatorLatitude": null,
      "OperatorLongitude": null,
      "AreaCount": 1,
      "AreaRadius": 0,
      "AreaCeiling": null,
      "AreaFloor": null,
      "CategoryEU": 1,
      "ClassEU": 0,
      "OperatorAltitudeGeo": null,
      "Timestamp": "2025-04-06T07:22:58"
    },
    "OperatorID": {
      "OperatorIdType": 0,
      "OperatorId": ""
    }
  }
}
{
  "rssi": -75,
  "tech": "B4",
  "recv_id": 2,
  "module_id": 0,
  "module_type": 11,
  "msg_type": 1,
  "odid": {
    "BasicID": [],
    "Location": {
      "Status": 1,
      "Direction": null,
      "SpeedHorizontal": null,
      "SpeedVertical": null,
      "Latitude": null,
      "Longitude": null,
      "AltitudeBaro": -22.5,
      "AltitudeGeo": null,
      "HeightType": 0,
      "Height": 0.0,
      "HorizAccuracy": 0,
      "VertAccuracy": 0,
      "BaroAccuracy": 0,
      "SpeedAccuracy": 0,
      "TSAccuracy": 0,
      "Timestamp": "2025-04-06T06:22:59"
    },
    "SelfID": null,
    "System": null,
    "OperatorID": null
  }
}
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.

  • Recommended: ignore Bluetooth legacy (B4) messages unless you will be composing manually using the mac address as identifier
  • 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.
Scout Heartbeat configuration

Heartbeat​

Scout currently supports one configured Heartbeat endpoint to which it sends JSON messages every 10 s. The heartbeat has the same protocols and URL format as described above. These messages contain:

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

⚠️ Note: In a future release, Heartbeat will be merged with Forwarders so every Forwarder endpoint will receive Scout status information. At the moment, Heartbeat is limited to a single, separately‑configured endpoint.

Example Heartbeat message:

{
  "sn": "D1031854C53D1B8BD0",
  "timestamp": 1750441875,
  "gnss_position": null,
  "gnss_satellites": 0,
  "last_observation": 0,
  "receivers": 0
}
warning

Due to the implementation constrains the heartbeat is pre-configured to sent the information to the Local Demo map, when changed the Scout will not be visible in the Demo map.

📄 Full protocol & format specification​

Download PDF (v2.0)