Integrating sensors into ATAK: from rangefinders to SDR receivers

A rangefinder knows the distance to a target. A radio knows who is on the net. An SDR receiver knows which frequencies are active and where the emitters sit. None of that knowledge is useful until it appears on the operator's map as a shared, time-stamped object that the rest of the team can see and act on. That translation – from a raw sensor reading to a marker in the common operating picture – is exactly what a well-built ATAK sensor integration plugin does. This article walks through the patterns for connecting field sensors to ATAK, normalizing their wildly different outputs, and publishing clean detections to the COP without flooding it with noise.

The integration problem: many sensors, one picture

Field sensors are not designed to interoperate. A laser rangefinder emits range, azimuth, and inclination over a Bluetooth serial profile in its own proprietary sentence format. A tactical radio exposes position reports and net membership through a software-defined interface or a serial gateway. An SDR receiver produces direction-finding bearings and signal classifications as a stream of structured records over a network socket. Each speaks a different transport, a different framing, a different unit system, and a different coordinate convention.

ATAK provides the one thing they all need: a shared spatial-temporal data model. Every object on the ATAK map is a Cursor on Target (CoT) event – an XML message describing what was observed, where, when, and with what confidence. The job of a sensor plugin is therefore narrow and well-defined: receive the sensor's native output, normalize it into a canonical measurement, convert that measurement into one or more CoT events, and inject those events onto ATAK's internal bus. Once a measurement is a CoT event, ATAK renders it, persists it, and federates it over TAK Server to every connected client with no further plugin involvement.

Getting that pipeline right is mostly about discipline at the boundaries. The sensor side is messy and device-specific; the CoT side is uniform. A good plugin keeps those two worlds strictly separated by a normalization layer, so that supporting a new sensor means writing one adapter rather than reworking the publishing path.

Plugin architecture: the three layers

A production sensor integration plugin separates cleanly into three layers, each with a single responsibility.

1. The sensor service layer. This layer owns the physical or logical connection to the device. For a Bluetooth rangefinder it manages the serial port profile socket; for a USB device it uses the Android USB host API with a USB-serial driver; for an SDR bridge it holds a TCP client to a companion computer. The defining rule of this layer is that it never touches the UI thread. All device I/O runs on a dedicated background thread or an Android Service, structured as an explicit connect / read / reconnect / disconnect state machine. Raw bytes are framed into discrete readings and handed off – never parsed for meaning here, only for boundaries.

2. The normalization layer. Each sensor type has an adapter that converts its raw reading into a single internal measurement model. That model uses fixed units throughout: WGS84 degrees for position, meters for range and altitude, true-north degrees for azimuth, and UTC for timestamps. The adapter performs unit conversion (mils to degrees, magnetic to true heading using a declination model), datum transforms where the device reports in a non-WGS84 datum, and confidence estimation. Everything downstream consumes only the normalized model, which is what makes the architecture extensible.

3. The CoT publishing layer. This layer maps normalized measurements onto Cursor on Target events and injects them into ATAK. It decides the event geometry (point, line, or polygon), the CoT type code, the UID strategy for tracked versus one-shot measurements, and the stale time. It is the only layer that knows about ATAK's APIs, which keeps the sensor and normalization layers portable and independently testable.

Why the normalization layer earns its keep

It is tempting, when integrating a single sensor, to skip normalization and convert the device output straight to CoT. That shortcut collapses the moment a second sensor arrives – and in the field there is always a second sensor. With an explicit measurement model, the declination correction, datum handling, and confidence logic live in one place and are unit-tested once. Adding a new rangefinder model becomes a 100-line adapter, and a brand-new sensor class becomes a new adapter plus a single new CoT mapping rule. Without it, every new device drags edits through the publishing path and risks regressing the sensors that already work.

Rangefinders: the canonical point sensor

A laser rangefinder is the simplest and most common ATAK sensor integration, and it sets the template for everything else. The operator lases a target; the device reports slant range, magnetic azimuth, and inclination angle. Combined with the operator's own position from ATAK's GPS, those three numbers resolve to a single target coordinate.

The geometry is a polar-to-Cartesian projection from the operator's location: convert magnetic azimuth to true azimuth by applying local declination, project the slant range across the inclination angle to a ground distance and altitude delta, and offset from the known sensor position to obtain the target's WGS84 coordinate. The result is published as a CoT point event with a hostile, friendly, or unknown affiliation chosen by the operator, and a stale time long enough to be useful but short enough that an abandoned lase does not linger on the map.

Two implementation details cause most field failures. The first is declination: a rangefinder reports magnetic heading, and using it as true heading produces a target error that grows with range – at 5 km, a few degrees of uncorrected declination places the marker hundreds of meters off. The plugin must apply a declination model for the operator's location and date. The second is the Bluetooth read loop: rangefinders pair over the serial port profile and emit a sentence per shot, but if the read runs on the UI thread the whole ATAK interface stutters whenever the device reconnects. The read must live in the background sensor service.

Radios: position reports and network state

Tactical radios contribute two kinds of data to the picture: the positions of the radios themselves and the state of the network. Modern software-defined radios and data-capable handhelds expose position reports over a serial or IP gateway, and the integration pattern closely mirrors the broader practice of connecting tactical radios to software. Each report becomes a CoT position event with a stable UID derived from the radio's identifier, so ATAK displays a moving friendly-force marker rather than a trail of disconnected points.

Network state is the subtler contribution. Whether a node is reachable, what its link quality is, and when it last reported are all operationally meaningful. A capable radio plugin surfaces this as marker styling – a node that has not reported within its expected interval is visually aged or greyed – and optionally as a CoT detail field so that downstream tools can reason about link health. The plugin should never delete a stale node outright; it should let the CoT stale time express uncertainty so the operator understands the difference between "confirmed gone" and "not heard from recently."

SDR receivers: bearings, fixes, and the companion-computer pattern

Software-defined radio receivers are the most demanding sensor class to integrate, because the heavy signal processing rarely runs on the Android device itself. The standard deployment puts the SDR platform and its detection or direction-finding pipeline on a companion computer, with the ATAK plugin acting as a thin consumer over a local network socket.

The SDR pipeline produces three useful product types. A single direction-finding bearing maps to a CoT line drawn from the sensor's position along the measured azimuth, optionally with an angular uncertainty wedge. A multi-sensor or moving-baseline fix maps to a CoT point with an error ellipse expressing geolocation confidence. A signal classification – emitter type, modulation, frequency – attaches as CoT detail so the operator sees not just where an emitter is but what it likely is. Because the SDR side runs asynchronously and at high rate, the plugin must rate-limit and deduplicate before publishing; a raw bearing stream at tens of hertz would overwhelm both the map and the TAK Server federation.

Publishing to the COP without drowning it

Once measurements are normalized, the publishing layer's discipline determines whether the plugin helps or hurts. Three rules govern good behavior. First, assign a stable UID to anything that should be tracked – a radio, a persistent emitter – so updates replace the existing marker instead of spawning new ones; assign a fresh UID only to genuinely independent one-shot events like a single lase. Second, match the CoT stale time to confidence: a confirmed, repeatedly observed track can persist for a minute or more, while a single uncertain detection should stale within seconds so it self-clears. Third, deduplicate and rate-limit at the source, before the event reaches the bus, so federation carries signal rather than noise.

Equally important is honesty about link state. A field sensor plugin must assume the network – and sometimes the sensor link itself – will drop. Measurements are written to a local queue the instant they are captured, stamped with capture time rather than publish time, and flushed to CoT when connectivity returns. The plugin panel should always show sensor link status, the age of the last reading, and any publish backlog. A plugin that silently stops updating when a sensor disconnects is worse than no plugin at all, because it presents a stale picture as a live one. The same offline-first discipline applies whether the feed is a handheld rangefinder or a drone telemetry stream.

Testing and field validation

Sensor plugins fail in ways that bench testing rarely catches. Bluetooth devices renegotiate connections unpredictably; GPS drifts under tree cover; declination changes with location; firmware revisions silently alter output formats. A representative validation pass runs the plugin on the actual rugged Android hardware the unit deploys, with the real sensor, under intermittent connectivity, and with the touch behavior expected from gloved hands. Capture real device output early – datasheets lie, and the only reliable source of truth for an output sentence is the device in hand. Confirm that target coordinates from a rangefinder lase land where a surveyed control point says they should, and that the picture degrades gracefully, not deceptively, when a sensor drops.