Integrating Garmin inReach with ATAK Part 1 - INRCOT
Garmin inReach is a closed loop designed for the Garmin ecosystem. At its core, it is a family of products that are satellite communicators that use the Iridium network to move small amounts of data globally. That includes GPS position reports, preset messages, free-form text messages, and SOS signaling. Everything routes through Garmin’s infrastructure. Devices transmit up to the satellite network, Garmin processes that data, and then exposes it through their web portal, mobile apps, and SMS relay system. Garmin even owns the phone number pool that handles text messaging to and from inReach devices, which keeps the entire experience contained inside their system.
That design is intentional. It prioritizes reliability and simplicity over flexibility. From a consumer standpoint, it works well. You turn it on, it gets a signal almost anywhere on earth, and your location and messages are accessible without needing to think about networks, routing, or infrastructure.
Android Team Awareness Kit operates on a completely different model. It is not a closed system, but rather designed to be as agnostic as possible. It is aggressive about discovering usable network paths, especially anything that supports UDP multicast for transmitting and receiving data. It is built around aggregating inputs from multiple sources into a shared operational picture. If something can be expressed as Cursor on Target, ATAK can ingest and display it.
That difference is where the gap exists. inReach data lives inside Garmin’s ecosystem, while ATAK expects data to be injected into its own. INRCOT is what bridges that gap. Credit to Greg Albrecht for building and maintaining it. The project is available here: https://github.com/snstac/inrcot
INRCOT is a Linux-based application, and in its simplest form it runs on the same machine as your TAK Server. It does not require separate infrastructure. It runs as a lightweight service that converts Garmin KML exports and injects CoT directly into the local server. It lives where your TAK data already lives and feeds into it.
At a high level, INRCOT takes a KML export feed from Garmin and converts it into Cursor on Target. Garmin already provides access to tracking data through their portal, which can be exported as a KML file via the link they provide in the MapShare portal. INRCOT reads that file, extracts position data, and translates it into a CoT map marker. Once converted, ATAK treats it like any other entity on the map.
There is no direct integration with Garmin and no persistent satellite feed into TAK. This is not a real-time bridge. It is simply taking data Garmin already provides and making it usable inside a different system. Garmin remains a closed loop and ATAK remains an open system. The result is still extremely useful as a BLOS PLI solution across a team using ATAK, regardless of whether they are connected over WAN, MANET, WiFi, or any other transport into the TAK Server.
In testing, update timing is predictable once you understand the constraints. Garmin limits tracking intervals, with the fastest rate at 10 minutes. If INRCOT is set to check for updates every 60 seconds, the end result is a position update inside ATAK roughly every 11 minutes once everything is factored in. That is not real-time, but it is consistent. For beyond line of sight ground force tracking, it is enough to maintain accountability and awareness when nothing else is available.
That position shows up in ATAK as a map marker that is automatically updated as new data is ingested. Anyone connected to the TAK Server, whether over WAN, MANET, WiFi, or local network, can see that PLI is populated and updated as it comes in.
What it does not do is behave like a normal TAK user. There is no direct interaction, no chat, and no way to treat it like a peer on the network. It is a one-way injection of position data. That limitation matters, and it is something we will address in Part 2 when we cover INRCHAT.
