Field Applications

Blue force tracking on Android military devices: ATAK, CoT and network architecture

By Corvus Intelligence Engineering Team · About the team →

June 25, 2026 11 min read

Blue force tracking (BFT) is one of the most consequential capabilities a dismounted unit can carry: the ability to see, in near-real time, where every friendly element is on the map. For years this capability was the exclusive domain of expensive purpose-built terminals. Android-based platforms running ATAK (Android Team Awareness Kit) have changed that equation — a ruggedized smartphone or tablet with a MANET radio now delivers persistent BFT at a fraction of the legacy hardware cost, with an open plug-in architecture that allows custom sensor feeds, AI overlays, and mission planning tools to coexist with the tracking layer. This article covers the full BFT stack: CoT position event schema, ATAK SA configuration, TAK Server feed management, MANET radio transport integration, update rate vs battery profiling, and the behaviour of the system when connectivity is lost.

BFT requirements for tactical units

Before touching software configuration, a BFT deployment requires an explicit requirements baseline. The parameters that drive every subsequent decision are position accuracy, update frequency, display latency, and the constraints imposed by the devices and radios in use.

Position accuracy. Dismounted infantry BFT targets a circular error probable (CEP) of 10 metres or better — sufficient for deconfliction in urban terrain where building-level resolution matters. Vehicle-mounted BFT typically accepts CEP 50 m. Android devices with multi-constellation GNSS (GPS + GLONASS + Galileo) achieve 3–5 m CEP in open terrain; dense canopy or urban canyons degrade this to 15–30 m without augmentation. SBAS (WAAS/EGNOS) assists GNSS receivers in ATAK-compatible devices, further tightening accuracy in supported geographic areas.

Update frequency. Position update rate determines how current the tracks on adjacent units' maps are. 5–10 second intervals are standard for units in direct contact or conducting close-proximity operations. 30–60 second intervals are adequate for units in support or reserve positions. Update rate directly multiplies channel load: every doubling of units or halving of the update interval doubles bandwidth consumption on the shared radio network.

Display latency. End-to-end display latency — from position event generated on the source device to track appearing on all connected displays — must remain under 3 seconds for operations where deconfliction depends on real-time position. Latency contributions include GPS fix time, CoT event generation, radio transmission, server processing, and client rendering. On a well-configured MANET with local TAK Server, total latency typically falls in the 500 ms–1.5 s range. Satellite-backhaul configurations add 600 ms–1.2 s of one-way delay.

Device and radio constraints. Ruggedized Android devices used for BFT — Samsung XCover Pro, Kyocera DuraForce Pro 2, Getac PS336 — carry batteries sized for 8–16 hour shifts, but GPS and radio transmissions draw heavily on that capacity. MANET radios typically connect over USB OTG or Wi-Fi hotspot; the hotspot connection itself adds antenna and RF load. Thermal limits in hot environments reduce sustainable transmit power on both the Android device and the radio, potentially reducing effective range and therefore requiring shorter update intervals to compensate for increased packet loss.

Cursor on Target (CoT) position events

The CoT standard defines an XML event schema that every element in the BFT network speaks. Understanding the schema is essential for diagnosing BFT failures and for writing custom plug-ins that inject or consume position data.

CoT XML schema for SA events

A minimal friendly ground unit position event looks like this:

<?xml version="1.0" standalone="yes"?>
<event version="2.0"
  uid="ANDROID-BFT-ALPHA-1"
  type="a-f-G-U-C"
  time="2026-06-25T08:30:00.000Z"
  start="2026-06-25T08:30:00.000Z"
  stale="2026-06-25T08:30:45.000Z"
  how="m-g">
  <point lat="49.8391" lon="24.0297"
         hae="320.0" ce="9.0" le="999999.0"/>
  <detail>
    <contact callsign="ALPHA-1"/>
    <uid Droid="ALPHA-1"/>
    <group name="Cyan" role="Team Member"/>
    <status battery="72"/>
    <track speed="1.4" course="045.0"/>
    <precisionlocation geopointsrc="GPS" altsrc="GPS"/>
  </detail>
</event>

The key fields for BFT are:

uid — unique identifier for the track. Must remain stable across position updates; ATAK uses the device IMEI or a generated UUID.
type — CoT type code (see below) encoding affiliation, dimension, and platform type.
time / start — event generation timestamp in ISO 8601 UTC. Clock accuracy here is critical: clock skew causes stale-rejection on the receiving server.
stale — timestamp after which the event is considered expired. ATAK sets stale to time + (update interval × 3) by default, giving three missed updates before the track is ghosted.
how — entry method for the position: m-g (machine GPS), h-g-i-g-o (human-entered GPS), m-g-i (inferred GPS).
point — WGS84 coordinates: lat/lon in decimal degrees, hae (height above WGS84 ellipsoid) in metres, ce (circular error) and le (linear error) in metres.

CoT type codes for friendly, hostile, and neutral

CoT type codes follow a hierarchical scheme: a-[affiliation]-[battle dimension]-[function]. For BFT the affiliation character is the critical discriminator:

Type prefix	Affiliation	ATAK icon colour	Example
`a-f-`	Friendly	Blue	`a-f-G-U-C` — friendly ground unit, combat
`a-h-`	Hostile	Red	`a-h-G-U-C` — hostile ground unit, combat
`a-n-`	Neutral	Green	`a-n-G-E-V-C` — neutral ground vehicle, civilian
`a-u-`	Unknown	Yellow	`a-u-G-U` — unknown ground unit

Stale timeout management

The stale timestamp is the primary mechanism for cleaning tracks off the COP. ATAK's default stale multiplier is 3× the configured SA update interval: at a 10-second update rate, stale is set 30 seconds in the future. If three consecutive position events are lost (packet loss, radio blackout, device shutdown), the track enters stale state and ATAK renders it with a faded icon. After an operator-configurable grace period (default 5 minutes in most deployments), the stale track is removed from the map entirely.

For BFT in high-packet-loss environments (dense urban, jungle canopy, SATCOM-backhauled links), increase the stale multiplier to 6–10× to avoid excessive track ghosting. This is configured per-device in ATAK under Settings → Network → SA Reporting → Stale Timer. On the TAK Server side, the server's own stale threshold (default 600 seconds) controls how long the server retains a track in its database before expiring it — newly connecting clients will not receive tracks that have exceeded the server stale threshold.

ATAK as a BFT client

ATAK handles BFT entirely through its SA (situational awareness) subsystem. No additional plug-in is required for basic BFT — the capability is built into the core ATAK application. Plug-ins extend BFT with custom data sources, display overlays, and transmission paths beyond the standard server and multicast options.

SA configuration in ATAK

The primary BFT configuration controls are under Settings → Network → Reporting Preferences:

Reporting Rate (Moving) — CoT transmission interval when the device is in motion. Set to 5–10s for dismounted infantry, 3–5s for vehicle-mounted with external power.
Reporting Rate (Stationary) — interval when the device has not moved beyond the motion threshold. Set to 30–120s to conserve battery during static phases.
Dynamic SA Reporting — when enabled, ATAK switches automatically between moving and stationary rates based on the accelerometer. This is the recommended mode for all operational BFT deployments.
My Team — assigns the device to a group (Cyan, Magenta, Yellow, etc.), which determines the icon colour other units see for this track and controls server-side group filtering.
My Role — sets the function sub-type in the CoT type code (Team Member, Team Leader, HQ, Medic, Forward Observer, etc.).

Network connection types

ATAK supports three network connection types for BFT data delivery:

TCP/TLS to TAK Server (port 8089). This is the standard operational mode. ATAK establishes a persistent TLS connection authenticated with a PKCS#12 client certificate. The server delivers all subscribed tracks to the client over this connection and receives the client's position events for distribution. TCP provides reliable delivery and supports large message payloads (mission packages, data packages) in addition to CoT events.

UDP multicast. ATAK can broadcast and receive CoT events on a UDP multicast address (default 239.2.3.1:6969). This mode operates without any server infrastructure — devices discover each other through the shared multicast group. It is suitable for peer-to-peer BFT on local network segments (Wi-Fi hotspot or MANET radio local IP space) but does not support federation, filtering, or persistent track history. Packet loss in multicast mode is not retransmitted: a missed position event simply does not appear.

TCP streaming (legacy). An older unencrypted XML stream mode, now deprecated in favour of TLS. Do not use in any operational deployment.

Plug-in architecture for custom BFT feeds

ATAK's plug-in API allows third-party applications to inject CoT events into the local ATAK map without routing through the server. A custom BFT plug-in can receive position data from a proprietary radio waveform, a hardware tracker device (via USB serial), or an AI-derived position estimate and inject it as a standard CoT event visible on the ATAK display. The plug-in communicates with the ATAK core via the CotMapComponent intent interface, posting com.atakmap.android.maps.COT_RECEIVER broadcast intents with the CoT XML payload. See our guide on ATAK integration field operations for a detailed plug-in development walkthrough.

TAK Server SA feed management

The TAK Server is the hub that aggregates BFT position events from all connected ATAK clients and distributes them to subscribers. Correct server configuration is as important as the client settings for reliable BFT.

Server federation for cross-unit SA

When BFT must span multiple independent TAK Server instances — for example, a company server and a battalion server, or a forward and rear echelon — TAK server federation setup provides the interconnection. Federation forwards selected CoT types across the server boundary in near real time. For BFT, configure the federation filter to pass a-f- (friendly atom) events bidirectionally. Do not pass a-h- (hostile) across federation boundaries unless the classification handling at both ends is verified — hostile position intelligence is frequently more sensitive than friendly position data.

SA feed subscription and group isolation

TAK Server manages which clients receive which tracks through its group system. When an ATAK client connects with a certificate assigned to group "PLATOON-1", it automatically receives all CoT events from other clients in the same group plus any groups that PLATOON-1 is configured to see (e.g., "COMPANY-HQ"). This group-based subscription model eliminates the need for any per-client track subscription configuration — group membership determines the entire SA picture.

User group isolation is also the mechanism for classification separation. Assign SECRET-network ATAK clients to a group with no visibility overlap with UNCLASSIFIED groups. The server will never route SECRET tracks to UNCLASSIFIED clients regardless of CoT type or content. For hard classification boundaries, run entirely separate TAK Server instances on physically separate network segments with no federation link between them.

CloudTAK SA feed configuration

# Create a user group for BFT population
curl -s -X POST https://tak.yourdomain.com:8443/api/groups \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "PLATOON-1",
    "direction": "BOTH",
    "description": "1st Platoon BFT group",
    "bitpos": 0
  }'

# Assign a user certificate to the group
curl -s -X PUT https://tak.yourdomain.com:8443/api/users/alpha-1/groups \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '["PLATOON-1", "COMPANY-HQ"]'

The direction field controls whether the group is an input group (events flow IN from this client), an output group (events flow OUT to this client), or BOTH. Setting BOTH is standard for BFT — each device both contributes and receives tracks within its assigned groups.

Mesh radio transport for BFT

The radio link is the most operationally constrained element in the Android BFT stack. MANET radios provide the peer-to-peer IP network that connects ATAK devices when Wi-Fi infrastructure and cellular coverage are unavailable. Understanding how ATAK integrates with MANET hardware is critical for predictable BFT performance in dismounted operations. Our article on military mesh network MANET covers the underlying network layer in detail; this section focuses on the ATAK integration specifically.

MANET radio integration with ATAK

Harris RF-7800W (Falcon III). The RF-7800W connects to the Android device via USB OTG, exposing a RNDIS (USB Ethernet) network interface. The radio's IP address on this interface is typically 192.168.100.1. ATAK treats the RNDIS interface as a standard network interface — no special driver or companion app is required. Configure ATAK's server connection to point to the TAK Server's IP address as reachable via the radio's mesh network. For local peer-to-peer BFT without a server, configure ATAK's UDP multicast output on the RNDIS interface address.

Persistent Systems MPU5. The MPU5 operates as a Wi-Fi access point or as a USB RNDIS device. In access point mode, the Android device connects to the MPU5's Wi-Fi SSID; the radio's management IP is accessible at 10.168.1.1 by default. Persistent Systems provides a companion Android application (Wave Relay Mobile) that integrates with ATAK to expose waveform status, node map, and link quality metrics as a native ATAK overlay. ATAK CoT events flow over the standard TCP or UDP path through the MPU5's IP mesh.

Bandwidth allocation for SA traffic

Quantifying the BFT bandwidth budget before deployment prevents overloading the mesh at the worst possible moment. A single CoT position event with full detail block is 800–1200 bytes. At a 10-second update interval for a 12-person squad:

Units:          12
Event size:     1000 bytes
Update rate:    10 seconds
Raw BFT load:   12 × 1000B / 10s = 1200 B/s ≈ 9.6 kbps

With TCP/TLS overhead (≈15%): ~11 kbps
With zlib CoT compression (≈50% reduction): ~5.5 kbps

MPU5 capacity (typical multi-hop mesh):  500 kbps–5 Mbps
RF-7800W capacity (typical):             200–500 kbps

BFT as % of RF-7800W at 200 kbps:        ~5.5% — acceptable
BFT as % of HF/SATCOM backhaul (32 kbps): ~17% — significant

At company scale (100+ units at 10-second intervals), raw BFT load exceeds 80 kbps before overhead — a meaningful fraction of any HF or SATCOM backhaul. In these environments, increase stationary update intervals to 120+ seconds and rely on motion-triggered bursts to keep aggregate load under 20 kbps on the backhaul link.

Position update rate vs battery life

The position update rate is the single most impactful BFT configuration parameter for battery life. GPS acquisition and radio transmission are the two largest power draws on a ATAK BFT device; both scale directly with update frequency.

Battery profiling under operational conditions

On a Samsung Galaxy XCover Pro (4050 mAh battery) running ATAK with GPS continuous lock:

Update rate	GPS draw	Radio draw (MPU5 hotspot)	Estimated BFT life
5 s (aggressive)	~120 mA	~180 mA	~8–9 h
10 s (standard)	~120 mA	~120 mA	~10–12 h
30 s (patrol)	~90 mA	~60 mA	~15–18 h
120 s (static)	~60 mA	~20 mA	~22–26 h

GPS draw is relatively stable regardless of update rate because ATAK keeps the GPS receiver in continuous tracking mode to ensure position is always current when an update fires. The variable is the radio transmission duty cycle: at 5-second intervals, the radio is active nearly continuously; at 120-second intervals, transmission bursts occupy only 1–2% of the duty cycle.

Adaptive update rate strategies

ATAK's Dynamic SA Reporting mode implements a two-rate adaptive strategy. A more sophisticated approach uses ATAK plug-ins or server-side push commands to adjust update rates based on operational context:

Motion-based rate switching — accelerometer-triggered: if device has moved more than 10 m since last transmission, transmit immediately regardless of scheduled interval. ATAK implements this natively in Dynamic SA mode.
Geofence-triggered update bursts — when a unit crosses a defined geofence boundary (objective area entry, phase line crossing), trigger a 5-second burst update rate for 60 seconds, then revert to background rate. Configure geofence triggers via ATAK geofencing plug-ins or the TAK Server geofence API.
Contact-driven rate escalation — when the TAK Server detects a hostile track within a defined radius of a friendly unit, it sends a push notification to the friendly unit's ATAK client via the server-to-client CoT channel, triggering the client to switch to its fast update rate. This requires a custom server-side plug-in or an AI integration layer.
Battery threshold rate reduction — a device management agent (MDM profile or ATAK plug-in) monitors the device battery and automatically raises the SA interval when battery drops below 30%, trading position currency for continued operation through a critical phase.

Disconnected-mode situational awareness

No MANET radio network operates perfectly across an entire operational area. Terrain masking, electronic warfare, radio failure, and deliberate emcon (emission control) all produce periods of disconnected operation. A robust BFT design must define exactly what the system does when the radio link is absent.

Last-known position display

When ATAK loses connectivity to the TAK Server (or loses multicast reception in peer-to-peer mode), it continues to display all tracks at their last received positions. The visual differentiation between current and stale tracks is controlled by the CoT stale timestamp: once a track's stale time passes, ATAK renders it with a transparency overlay and a timestamp annotation showing how long ago the position was last received. Tracks persist in this stale state until they reach the ATAK map's stale removal threshold (configurable per-deployment; default 5 minutes).

Operators must be trained to recognise and act on stale track indicators. A track position 3 minutes old for a dismounted unit moving at infantry pace could represent 180–360 metres of actual displacement — enough to cause fratricide risk if treated as current. SOP should specify that stale tracks are used for general area awareness only, not for fire support deconfliction.

Dead reckoning display integration

ATAK supports dead reckoning track extrapolation through the track detail element in CoT events, which carries speed and course. When a track goes stale, a dead reckoning plug-in can project the track's estimated current position forward from the last known fix using the reported speed and course vectors. The projected position is displayed with a distinct icon (typically an open/dashed symbol) to distinguish it from a GPS-confirmed position.

Dead reckoning accuracy degrades rapidly for dismounted infantry (speed and course change constantly) and is more reliable for vehicles on known road networks. Implement dead reckoning display only when operators understand its limitations and the SOP clearly distinguishes projected from confirmed positions.

Reconnect and SA reconciliation

When ATAK reconnects to the TAK Server after a disconnected period, the server performs a full SA state push: it delivers the current (or most recent) CoT event for every track in the client's subscribed groups. This burst update overwrites the stale last-known positions on the client map with current server-held data. The reconciliation process completes within 1–3 seconds for typical unit sizes (under 200 tracks).

# Verify reconnection burst via CloudTAK events WebSocket
# (Use wscat or a browser WebSocket client for testing)
# wss://tak.yourdomain.com:8443/api/events?groups=PLATOON-1
#
# On reconnect, expect a rapid burst of CoT events — one per known
# track — within the first 2–3 seconds of the WebSocket session.
# Monitor the event count to confirm all expected tracks are delivered.
#
# If the burst is partial, check server-side stale threshold:
# GET /api/config/cot-stale-seconds
# Default: 600s — tracks older than 10 min are not pushed to reconnecting clients

One edge case to plan for: if the disconnected period exceeds the server's stale threshold (default 600 seconds for CloudTAK), the server has already expired the stale tracks from its active store. On reconnect, those tracks will not appear in the burst update and will only reappear when the source devices transmit new position events. For operations where reconnects may follow multi-hour communications blackouts, increase the server stale threshold to match the expected maximum blackout duration.

Implement BFT for Your Unit or Organisation

We design and deploy ATAK-based blue force tracking systems for defense and government organisations — including TAK Server configuration, MANET radio integration, TAKpilot AI copilot, and mission-specific plug-in development.

TAKpilot AI Copilot → Book a Briefing

This analysis was prepared by Corvus Intelligence engineers who build mission-critical software for defense and government organizations. Learn about our team →

Frequently Asked Questions

What is blue force tracking on Android military devices?

Blue force tracking (BFT) on Android military devices refers to the real-time display and transmission of friendly unit positions on a shared digital map. ATAK (Android Team Awareness Kit) is the primary BFT client: it reads GPS position from the device, packages it as a Cursor on Target (CoT) XML event, and transmits that event to a TAK Server or directly to peer devices over multicast or MANET radio. The server aggregates position events from all connected units and broadcasts them to every ATAK client, so each soldier sees all friendly tracks simultaneously. Update rates, map symbology, and connectivity paths are all configurable within ATAK's SA settings.

What is Cursor on Target and how is it used for BFT?

Cursor on Target (CoT) is an XML-based message format originally developed by the US Air Force for sharing tactical position and status data between disparate systems. For BFT, the key CoT event type is the 'atom' event (type prefix 'a-'), which carries a point element with lat/lon/hae coordinates, a stale timestamp indicating when the position expires, and a detail block containing callsign, team color, and role. ATAK generates these events automatically from the device GPS at a configurable interval (typically every 5–30 seconds) and transmits them to the TAK Server, which re-broadcasts them to all subscribed clients. The stale timestamp ensures that if a unit stops transmitting, its track automatically fades from other units' displays after the defined expiry window.

What update rate should I configure for ATAK BFT in tactical operations?

The optimal BFT update rate depends on mission type, radio bandwidth, and battery constraints. For dismounted infantry in contact, a 5–10 second update rate provides adequate position currency; for vehicle-mounted units with external power, 3–5 seconds is practical. On bandwidth-constrained MANET links, increase the interval to 30–60 seconds for non-maneuvering units and rely on motion-triggered bursts (geo-fence departure events) for immediate updates when a unit moves. ATAK's adaptive SA reporting feature can switch between a slow background rate and a fast contact rate automatically based on movement speed detected by the device accelerometer.

How does ATAK connect to a TAK Server for BFT?

ATAK supports three primary connection types for BFT: (1) TCP streaming — a persistent TCP/TLS connection to TAK Server port 8089, used for reliable unicast delivery with certificate-based authentication; (2) UDP multicast — CoT events broadcast on a multicast address within a local network segment, suitable for LAN or MANET environments without server infrastructure; and (3) Streaming XML — a legacy TCP mode using unencrypted XML streams, now deprecated. For operational deployments, TCP/TLS to a TAK Server is standard. ATAK's network settings accept a server hostname, port, and PKCS#12 certificate bundle for mutual TLS authentication.

What MANET radios integrate with ATAK for BFT?

ATAK integrates with MANET radios through Android USB OTG or the radio's companion Android application. Commonly integrated radios include Harris RF-7800W (Falcon III series), Persistent Systems MPU5, Domo Tactical PRC-ACM, and Silvus StreamCaster. Each radio exposes a virtual network interface or a CoT relay service that ATAK recognizes as a TAK data link. The radio handles IP routing over the mesh, and ATAK sends standard CoT UDP multicast or TCP packets to the radio's local IP address. Some radios also expose a waveform management API that ATAK plug-ins can query to monitor link quality and adapt SA transmission parameters accordingly.

How does TAK Server manage SA feeds for BFT?

TAK Server maintains an in-memory CoT event store for all connected clients. When a new CoT position event arrives, the server: (1) writes the event to the persistent database; (2) evaluates group and filter rules to determine which clients should receive it; (3) pushes the event to all subscribed client connections. For BFT specifically, the server tracks the most recent position event per UID and serves it to newly connecting clients so they receive a current common operating picture immediately on connection. SA feed subscriptions are managed via the server's group system — clients assigned to the same group automatically share BFT tracks without manual subscription configuration.

How do I prevent BFT tracks from appearing on classified and unclassified ATAK instances simultaneously?

Classification separation in a TAK BFT environment is achieved through a combination of server-side group isolation and physical network separation. On TAK Server, assign classified units to a group that is not visible to unclassified clients (e.g., a 'SECRET' group with no federation or subscription to the 'UNCLASSIFIED' group). For hard separation, run two entirely separate TAK Server instances — one on a classified network segment and one on an unclassified segment — with no federation link between them. Never rely solely on software group filters for classification separation; physical or cryptographic network separation is required to meet information assurance standards.

What happens to BFT tracks when ATAK loses connectivity to the TAK Server?

When ATAK loses server connectivity, it enters disconnected mode. The map continues to display the last received positions for all tracks, visually differentiated by a stale indicator (typically a faded icon or timestamp annotation) once the track's CoT stale time passes. ATAK also continues to transmit its own position over any available local broadcast path (UDP multicast, MANET radio). When connectivity is restored, ATAK automatically reconnects and the server pushes the current state of all tracks as a burst update, overwriting the stale last-known positions. Administrators should set stale timeouts appropriate to their tactical tempo — a 10-minute stale window prevents track ghosting in poor-connectivity environments.

How much bandwidth does BFT over ATAK consume on a MANET link?

A single ATAK CoT position event (CoT XML with detail block) is approximately 800–1200 bytes. At a 10-second update interval for a 20-unit platoon, total BFT traffic is approximately 20 × 1000 bytes / 10s = 2 kB/s or about 16 kbps. This is well within the capacity of modern MANET radios (MPU5 provides 1–10 Mbps per node), but accumulates quickly in large formations. For a 100-unit company at 10-second intervals, raw BFT traffic approaches 80 kbps — manageable but significant on HF or satellite backhaul links. CoT compression (zlib over the TCP stream) typically reduces payload size by 40–60%, and adaptive update rates can reduce load by an order of magnitude during static phases.

What Android devices are certified for military BFT with ATAK?

ATAK MIL (the military variant distributed through TAK.gov) runs on a range of ruggedized Android devices. Commonly used platforms include the Samsung Galaxy XCover Pro, Getac PS336, Kyocera DuraForce Pro 2, and Dell Latitude Rugged tablets. For BFT specifically, device selection criteria include GPS chipset sensitivity (for urban canyon and foliage penetration), battery capacity (or hot-swap capability), operating temperature range, and MIL-STD-810 shock and water resistance. Devices with multi-constellation GNSS (GPS + GLONASS + Galileo) provide more reliable position fixes in degraded environments compared to GPS-only chipsets.