Sensor+ configuration

---

Sensor+ offers advanced integrations with third-party servers.

TAK (Tactical Awareness Kit)

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)

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. Scheme is also part of the URL. Default is udp:// but if you select secured communication in the following tab, it changes to tcp:// because UDP cannot be secured natively. Only if you want a unsecured TCP connection then you must use the tcp:// prefix in URL.

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.

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

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

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

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.

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).

---

Sapient

Scout uses strictly version "BSI Flex 335 v2.0". The connection is always over a TCP client and can be optionally encrypted using SSL as any other TCP connection.

Currently, Scout does not support any commands but will, in future releases, support basic sets of commands (start, stop) as well as changes in detections diameter.

Heartbeat

Heartbeat is reported every 60s by a standard StatusReport message.

Drones

Scout reports two kind of messages for RemoteID messages

• classification "Air vehicle", subtype "UAV rotary wing" or "UAV fixed wing" for the drone
• classification "EM transmitter", subtype "UAS control station" for the pilot/operator

The operator message is associated to the drone message via associated_detection as type SIBLING.

Both messages have the same object_info:

• Technology: possible values WB (Wifi Beacon), WN (Wifi NaN), B4 (Bluetooth 4), B5 (Bluetooth LE)
• Operator ID: applicable in US and EU regions e.g. FIN87astrdge12k8
• UAS ID: serial number of the drone or attached RemoteID transmitter e.g. MFR1C123456789ABC

Aviation

If your Scout has aviation modules and you enable aviation to be sent to Sapient server then DetectionReport with classification "Air vehicle" -> "Manned fixed wing" or "Manned rotary wing" will be used together with object_info:

• Technology: possible values AL (ADS-L), AB (ADS-B), OG (OGN), UT (UAT), FL (FLARM)
• ICAO ID: 24bit number assigned by ICAO to every manned air vehicle
• Flight number: string assigned to the current flight of the airplane