ATAK / TAK compatibility

Android Team Awareness Kit (ATAK) and related TAK clients (WinTAK, iTAK, etc.) exchange situational data primarily as Cursor on Target (CoT) events — usually XML over UDP (multicast or unicast) on a loopback or LAN interface.

LowMesh does not speak CoT on the mesh air interface. For this specification revision, ATAK integration is defined only for paths tethered to a Client node: a companion (phone, tablet, or laptop) talks to the radio over BLE or USB (see USB & BLE hex API), decodes the same framed bytes the Client firmware exposes, and translates mesh position and identity into CoT for a TAK client on that host.

Out of scope (for now)

The following are not specified or supported here; implementations SHOULD NOT describe themselves as “LowMesh ATAK-compatible” if they rely solely on these:

• Gateway-hosted bridges — no CoT generation from a Gateway observing or decrypting mesh backhaul for ATAK.
• Infrastructure mesh taps — no TAK Server plugin, federation hop, or datacenter pipeline that ingests mesh traffic without a direct session to a Client-class node the operator controls.

These may be revisited later; interoperable field mappings below still apply whenever a Client-tethered companion is the source of CoT.

Supported integration architecture

Path	Description
Companion + Client (BLE)	Android/iOS app pairs with the user’s Client radio. It receives frames via GATT, maps GPS_FIX / adverts to CoT, and sends UDP to 127.0.0.1 so ATAK on the same device ingests tracks (typical “mesh radio + ATAK phone” setup).
Companion + Client (USB)	Same translator logic over USB CDC (helpful for lab bring-up or WinTAK on a laptop cabled to the Client device).

The mesh link uses AES-256-CCM-4 for all channelHash values, including default community and private channels; the companion only sees what the paired Client exposes after its stack decrypts (or originates) traffic. Loopback CoT is the baseline trust model: avoid broadcasting translated CoT onto a shared LAN unless a deployment explicitly opts in and understands the exposure.

Source data on LowMesh

LowMesh source	Use for ATAK
GPS_FIX (0x51)	Primary position track: lat/lon, altitude, speed, heading, timestamp. See GPS & group location.
Optional GPS in NODE_ADVERT	Low-rate “presence” on the map when full GPS_FIX is not sent.
NODE_ADVERT / NODE_INFO	Callsign / label: map long name or short name to CoT contact attributes. See Node identity.

Ignore or down-rank stale fixes: use timestampUtc from GPS_FIX to set CoT time / start, and compute stale as start + max(30s, 3 × nominal_update_interval) when the mesh schedule is known.

CoT event shape (recommended)

Emit well-formed CoT with at least:

• uid — Stable per LowMesh source. Recommended:
  • LOWMESH- + 8 hex digits of nodeId32 (on-air srcId, LE uint32), e.g. LOWMESH-A1B2C3D4, or
  • LOWMESH- + 16 hex digits of nodeIdentity64 when the companion knows the stable NVM identity. Do not recycle UIDs across different physical nodes.
• type — Default a-f-G-U-C (friendly ground unit) unless you operate under a local SOP that mandates another type hierarchy.
• how — m-g (machine generated) is appropriate for companion-generated events.
• point — lat, lon, hae (height above ellipsoid in meters). Map from latitudeE7, longitudeE7, and altitudeDm (decimeters → meters).
• track — course in degrees (0–360) from headingCdeg / 100; speed in m/s from speedCms / 100.

Altitude and vertical datum

ATAK commonly displays HAE. If a node only provides ellipsoidal height, set hae and avoid claiming a geoid-corrected MSL unless the device firmware supplies it.

Example (informative)

<event version="2.0" uid="LOWMESH-A1B2C3D4" type="a-f-G-U-C"
       how="m-g" time="2026-04-19T12:00:00Z" start="2026-04-19T12:00:00Z"
       stale="2026-04-19T12:02:00Z">
  <point lat="37.7749" lon="-122.4194" hae="12.3" ce="10.0" le="10.0"/>
  <detail>
    <contact callsign="LM-CLIENT-01"/>
    <remarks>LowMesh via Client-tethered companion</remarks>
  </detail>
</event>

Exact XML schema versioning should follow the CoT spec your TAK clients are built against; the example illustrates field usage, not a normative schema.

Identity and deconfliction

• Prefer contact@callsign from the node’s human-entered short name when present; otherwise derive a short label from the long name or from the last 4 hex digits of nodeId32.
• If multiple mesh channels map to different tactical groups, encode the channel in remarks or a custom detail extension — do not assume ATAK groups map 1:1 to LowMesh channelHash without explicit product configuration.

Rate limiting

Mesh GPS updates should respect the same duty cycle and battery constraints as any other payload. The companion SHOULD deduplicate and rate-limit CoT emissions (e.g. cap at 1 Hz per remote nodeId32 unless a higher rate is explicitly configured) so the UI does not amplify traffic beyond what the Client radio actually carried.

Reverse path (informative)

To push CoT into the mesh from ATAK:

1. Companion receives CoT on loopback UDP.
2. Map to supported mesh payloads (Payloads) — typically UTF-8 text or application-specific binary types agreed out-of-band — and emit frames only over the BLE/USB session to the paired Client.

See also

• GPS & group location — GPS_FIX, schedules, phone-assist
• Device roles — Client vs gateway/repeater (ATAK path is Client-tethered companion only)
• USB & BLE hex API — transport verbs for companions