Configure TAKserver Connection

The TAK plugin provides a port driver for connecting to the XML-protocol port of a TAKserver, which is configured similarly to other YAAC port drivers.

The parameters required for a TAK server connection are:

• The "mission package" containing your authentication information. A mission package is a ZIP file containing an XML file with a .pref file type; this XML file specifies the network listening port and domain name for the TAKserver, and the identity of your authorization private/public key pair and the TAKserver's truststore if using SSL/TLS encrypted communication (almost always done for TAK; these files will be included in the ZIP file as PKCS#12 keystores). Note that each TAKserver runs its own private Certificate Authority (CA), rather than depending on the standard public Internet CAs. This permits reduced cost, reduced credential issuing latency, and greater flexibility in both granting and revoking access to the TAKserver. When you are authorized to connect to a TAKserver, the TAKserver administrator will issue you your mission package.
• The callsign for your TAK client station. Note this does not need to be an AX.25/APRS standard 6-character callsign plus an optional SSID number; it can be any short string, and is commonly your mission tactical name.
• Your team color. This can be used to identify separate teams sharing a common TAK network for inter-team coordination.
• Your role within your team. This is a generic role, where your callsign will identify your specific tactical instance of the role. Note that some of the standard roles show the military origins of TAK.
• Whether your YAAC APRS station is allowed to send data into the TAK network. By default, you will only receive TAK traffic. If you are enabled for transmit, your APRS beacon (as selected from one of possible multiple beacons) will be translated into a corresponding TAK CoT message, using a MIL-STD-2525 or CoT type code corresponding to your APRS symbol, plus the position information normal in a YAAC beacon.
• For transmit-capable TAK ports, whether other APRS traffic received by your station (e.g., from a Serial_TNC or APRS-IS port) will be translated into TAK CoT messages and forwarded to the TAK network. At the present time, only APRS position reports (standard text, compressed text, Mic-E, and Maidenhead locators) and object/item reports will be translated into TAK targets.

  Also note that there is no present means to export TAK data to the APRS network. Since there is no way to control or restrict who can be listening on an APRS net, this was felt to be the only safe way to keep TAK network traffic under control of the TAK network authority.

• Whether your station should processed received CoT t-x-d-d tasking messages. Normally, CoT targets should be removed from the local database when the stale time for the last received message from or about the target is reached without receiving an updated message; note that CoT targets can be explicitly deleted by sending a CoT message with the stale time earlier than the CoT message's start time. However, the ATAK client (for Android) does not honor CoT stale times, and instead sends a t-x-d-d message when an ATAK operator deletes a target. Enabling this option permits YAAC to interoperate with ATAK.
• How long should YAAC retry to connect to the TAKserver if the connection is lost. By default, YAAC only retries for a limited number of times before giving up reconnecting, but you can choose to keep retrying forever (or until it succeeds or you shut down YAAC).
• There are alarm message CoT types defined, which map to the ALARM event type in YAAC (reportable through the YAAC Sounds plugin). You can choose not to convert these CoT messages into YAAC alarms, as they may be repeated extremely frequently.
• Which one of potentially several YAAC beacons should be sent as your station's TAK CoT position target.