Přeskočit na hlavní obsah

Sensor+ configuration

Sensor+ offers advanced integrations with third-party servers.

TAK (Tactical Awareness Kit)​

TAK logo

TAK offers unsecured and secured communication. Secured communication uses certificates that come in three possible ways to the Scout client

  • as separate PEM files (one for CA - the server certificate, one for client certificate, and one for client's private key);
  • as P12 bundle - this file contains all three mentioned PEM files bundled together;
  • from enrollment process (will be described later)
note

If your Scout runs in Cloud Mode, you don't need this integration to get drone tracks into TAK - the Dronetag cloud can stream them to your TAK server for you over the integration portal. Use that route whenever you don't need the direct data flow from the Scout itself; the Sensor+ integration described here is what you want when the Scout must reach the TAK server on its own, without any cloud in the path. See Using Scout with the Dronetag App for a video walkthrough of the cloud route.

Basic settings​

TAK Basic Settings

URL: specify host (e.g. tak.example.com) or ip (e.g. 10.1.1.25). If your server uses standard ports (8088 unsecured, 8089 secured) then you don't need to specify the port. If you want to use unsecured UDP version, use "Force UDP" switch.

SOURCES: you should keep drones and status messages. The only meaningful change is (un)checking aviation if you don't want to see surrounding airplanes in your TAK.

Force UDP: if your server supports only UDP protocol then check this option. UDP cannot be secured nor verified ( connection failure will never be reported).

Security settings​

TAK Security Settings

The suggested setup is to have all security features enabled (security, verify server cert, verify server domain). This will ensure server certificate is enforced and thoroughly checked. If the server certificate doesn't have its domain/IP correctly filled in, then you can disable the domain/IP check to accept even such certificate and keep your comms secured. In this case, either your server needs to use globally recognized CA such as Let's Encrypt or you need to supply your CA's certificate into the first field "Server CA Certificate" in PEM format. There is the option to use p12 bundle with "P12 Trust Bundled RootCA" that will take CA certificate from the last certificate from the bundle.

CERTIFICATE VERIFY FAILED​
TAK Security Server Cert Not Trusted

The image on the right shows the error when Scout cannot verify server's certificate. Please note that the CA certificate must be server's root CA. It cannot be an intermediate CA. You have a few solutions

  1. If you are using p12 bundle and the server's certificate has the same RootCA as the certificate in the bundle then use "P12 Trust Bundled RootCA". This will extract the top-level certificate from the p12 bundle and use it as trusted certificate for verifying the server.
  2. If you are using p12 bundle (and have "P12 Trust Bundled RootCA" to "No") or not using the p12 at all - in both cases the "Server CA Certificate" will be used in you have checked "Verify Server Cert". Make sure it is the top-level rootCA.
  3. As a temporary fix, you can uncheck "Verify Server Cert" and "Verify Server Domain/IP" in case of problems and the client will simply accept any certificate that the server gives you. This is not secure at all of course.

Client Certificates​

TAK Security P12 Bundle

For secured communication from client to server, you must specify "Client Certificate" and "Client Key" either as separate PEM files or in a P12 bundle. If you upload both PEM and P12, only the P12 will be used. Optionally, PEM Key can be password protected. In this case use the "Client Key Password" field. Keys in P12 must not be password protected. Usually the bundle itself is protected hence the field "P12 Bundle Password".

If any of those displayed errors appear that means your client certificates were rejected by the server or are outright invalid.

  • [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error
  • [SSL: TLSV13_ALERT_CERTIFICATE_REQUIRED] tlsv13 alert certificate required

ENROLLMENT​

TAK Security Authorization/Enrollment

If you don't have certificates but you were given username, password and optionally a passphrase then you should use those in the authentication section together with setting Enroll to "yes". Those credentials are used in standard enrollment process using Marti API on port 8446. We currently do not support custom certificates for secured communication during enrollment but it will be part of the next release. If your enrollment server is running at a different port or even url then use provided Enrollment URL.

TAK Settings​

Friendlies: here you can define friendly drones one-per-line by their serial number or MAC address in standard colon-delimited format. You can optionally add callsign under which they will appear on the map. Separate the callsign by a comma. Example:

1596F319B877381F1BBF, blue1
1596F33DEC76E5C15FD3

TAK Data​

Scout sends following messages to the server:

Heartbeat​

Scout is sending heartbeat every 60s as a friendly ground sensor a-f-G-E-S instead of usual t-x-d-d. This will place Scout on the map with callsign "SCOUT-<last-4-digits-of-serial-number>" while the uid of those messages is "<serial-number>-sensor".

Drones​

Scout by default marks drones as Unknown affiliation. If the drone's serial number or MAC address were specified in the friendly settings, then they will be marked as Friend. Scout also distinguishes between fixed-wing and rotary drones. So the possible COT types reaching the server are one of

  • a-u-A-C-F-q resp. a-f-A-C-F-q for unknown fixed-wing drone resp. friendly one
  • a-u-A-C-H-q resp. a-f-A-C-H-q for unknown rotary drone resp. friendly one

Drone's callsign is [UA]snxxxx where snxxxx is the last 6digits of drone's serial number. If the serial number is not available then drone's MAC address is used instead (will have ":" inside).

Drone Operator​

Operator is visually linked to their drone by their callsign [OP]snxxxx that shares the drone's serial number. Operator is also linked to their drone on COT level by the link_to element. Operator's COT type is a simple ground unit a-u-G-U resp. a-f-G-U if the operator's drone is defined as friendly.

Example​

A single Remote ID detection produces up to two CoT events: the UAV track (from the drone's broadcast location) and a separate operator marker (from the drone's broadcast system message). The operator event references the drone via its <link> element, so the two appear connected on the map. Below is a real event pair emitted by a Scout with serial D19D2405DD799BF9B5 for a rotary drone broadcasting UAS ID MJJE3G894BIQV0Z:

<event version="2.0" type="a-u-A-C-H-q" uid="D19D2405DD799BF9B5-UAS-MJJE3G894BIQV0Z" how="m-g" time="2026-07-23T05:10:57.263681Z" start="2026-07-23T05:10:57.263717Z" stale="2026-07-23T05:11:27.263725Z">
  <point lat="-48.8766700" lon="-123.3933300" le="3.0" hae="403.0" ce="10.0"/>
  <detail>
    <_flow-tags_ pytak-scout="2026-07-23T05:10:57.263739Z"/>
    <contact callsign="[UA]BIQV0Z"/>
    <track track="86.0" speed="0.0"/>
  </detail>
</event>
<event version="2.0" type="a-u-G-U" uid="D19D2405DD799BF9B5-OP-MJJE3G894BIQV0Z" how="m-g" time="2026-07-23T05:10:57.264431Z" start="2026-07-23T05:10:57.264448Z" stale="2026-07-23T05:12:57.264454Z">
  <point lat="-48.8766192" lon="-123.3933311" le="10.0" hae="405.5" ce="5.0"/>
  <detail>
    <_flow-tags_ pytak-scout="2026-07-23T05:10:57.264468Z"/>
    <contact callsign="[OP]BIQV0Z"/>
    <link relation="p-p" type="a-u-A-C-H-q" uid="D19D2405DD799BF9B5-UAS-MJJE3G894BIQV0Z"/>
  </detail>
</event>

Aviation​

If your Scout has aviation modules and you enable aviation to be sent to the TAK integration the airplanes will appear as civilian fixed-wings a-u-A-C-F resp. helicopters a-u-A-C-H. In the UI, you should see their reported flight number (e.g. EJU39FN). If the flight number is not available then ICAO ID is used (which is a number).