Android RTK Architecture & Data Flow

The SCOUT Series connects to Android through a single USB Type-C cable for power and serial communication.

This page explains how an Android app turns that connection into an RTK workflow, then compares two ways to use the corrected position: consume it inside the same app, or publish it through Android Mock Location for other apps. The distinction matters whether you use an existing Android tool or build your own integration.

Why USB connection alone is not enough

Common assumption

Plugging in the receiver makes every app accurate

The receiver starts producing GNSS data as soon as it is powered, but Android does not automatically reinterpret an incoming USB serial stream as a system location source.

What actually happens

A compatible Android app must turn serial data into a usable RTK workflow

The app opens the USB connection, reads NMEA output, obtains correction data, writes RTCM back to the receiver, and decides how the corrected position should be consumed.

1. Enumerate the USB device Android detects the connected receiver in USB Host mode.

2. Grant application access The user authorizes a compatible app to communicate with the device.

3. Open the serial channel The app starts reading and writing GNSS data over USB.

Hardware plug-and-play and application-ready positioning are different things. On Android, a compatible app handles USB serial access. No Bluetooth pairing is required for the standard SCOUT Series USB workflow.

High precision requires NTRIP corrections

Uncorrected GNSS is typically meter-level. To reach an RTK Fix solution, the receiver must continuously receive RTCM correction data from an NTRIP caster, a correction-service network, or a local base station.

The SCOUT Series does not contain its own cellular or Wi-Fi connection. A compatible Android app therefore acts as the NTRIP client: it obtains correction data over the network, sends a GGA position upstream when required by the service, and writes RTCM back to the receiver through USB.

This correction loop is shared by every Android RTK workflow. For a deeper explanation of the transport layer and correction format, see Inside NTRIP and RTCM Unpacked.

The common RTK data loop

Before any app can use the final position, every workflow passes through the same loop. The architectural split happens only after the Android app already holds an RTK-capable solution.

Android RTK data loop showing a SCOUT Series USB Type-C receiver exchanging NMEA and RTCM data with an Android NTRIP client app and an NTRIP correction service. — Fig. 1: The common Android RTK data loop shared by every integration path.

SCOUT Series → NMEA → Android app → GGA when required → NTRIP caster → RTCM → Android app → RTCM write-back → SCOUT Series → RTK Fix NMEA → Android app

The real architecture decision starts here: once the app has received the corrected solution, does it use that position internally, or publish it to the Android system for other apps?

Two ways to consume the RTK solution

The difference between the two architectures is not how corrections reach the receiver. The difference is who consumes the corrected position after the common loop is complete.

Architecture A · In-app direct use

Use the RTK solution inside the same app

The business app manages USB and NTRIP, then consumes the corrected NMEA result internally for surveying, mapping, collection, or navigation. Android Mock Location is not required.

Correction service ⇄ RTK-capable business app ⇄ SCOUT Series

Shortest application path and no system-level injection dependency.
Best when one mature app already covers the complete field workflow.
The corrected position is primarily available inside that app.

SW Maps

Representative direct-use workflow

SW Maps supports external GNSS receivers over USB-OTG and includes an NTRIP client. The RTK solution can be consumed directly inside the same GIS and surveying app without relying on Android Mock Location.

Review SW Maps documentation →

Other direct-use implementations

The same pattern also applies to dedicated field-collection, mapping, navigation, and control applications that manage the RTK workflow and business logic inside one app.

Architecture B · System-level injection

Publish RTK position through Mock Location

A bridge app manages USB and NTRIP, then publishes corrected coordinates through Android Mock Location. Compatible apps reuse the injected system location without implementing USB or NTRIP.

SCOUT Series ⇄ Bridge app → Mock Location → Compatible apps

One bridge app can expose the same high-precision position to multiple compatible apps.
Downstream apps do not need to implement USB, NTRIP, or RTCM handling.
Best when the goal is to activate an existing Android application ecosystem.

Kalmix Scope

Official bridge app for the SCOUT Series

Kalmix Scope connects the receiver over USB Type-C, manages NTRIP corrections, writes RTCM data back to the receiver, and publishes high-precision coordinates through Android Mock Location.

GNSS Master

Validated third-party bridge app

GNSS Master has been validated with the SCOUT Series over USB Type-C. It provides USB serial access, NTRIP corrections, RTCM write-back, and Android Mock Location output.

Review GNSS Master documentation →

System-level injection with Android Mock Location

Android exposes a developer option named Select mock location app. A designated bridge app can use that mechanism to publish a corrected position to the system location layer. Compatible apps that rely on Android system location can then consume the injected coordinates.

Android Mock Location architecture showing a SCOUT Series USB Type-C receiver connected to an Android bridge app, exchanging NMEA and RTCM data with an NTRIP caster, and publishing RTK positions through Android system location to compatible apps. — Fig. 2: A bridge app publishes the RTK solution through Android Mock Location so compatible apps can reuse the high-precision system location.

Keep the boundary clear: Mock Location is the distribution mechanism, not the correction source. NTRIP obtains RTCM; Mock Location publishes the corrected coordinates to other apps.

Compare the two architectures

This table compares how the final RTK solution is consumed. It does not mix in the separate implementation choice of using an existing app or building your own.

Dimension	Architecture A · In-app direct use	Architecture B · Mock Location injection
Who manages NTRIP	The business app itself.	A bridge app or middleware layer.
Uses Android Mock Location	No.	Yes.
Who consumes the RTK solution	The same app that manages the RTK workflow.	Compatible apps that read Android system location.
Downstream app changes	Not applicable: the primary workflow remains inside one app.	No SDK or USB integration is required in compatible downstream apps.
Main advantage	Shortest path and direct control inside one application.	One bridge app can activate a broader Android app ecosystem.
Update path	Receiver → business app.	Bridge app → Mock Location → Android system location → downstream apps.
Representative tools	SW Maps.	Kalmix Scope; GNSS Master.
Best fit	A mature app already covers the full field workflow.	Several existing apps need to reuse one high-precision location source.

Implementation choice is a separate decision

The architecture choice and the software-ownership choice are different dimensions. You can use an existing tool or build your own implementation on top of either architecture.

Use an existing app: SW Maps is a representative in-app direct-use workflow. Kalmix Scope is the official SCOUT Series bridge app, and GNSS Master is a validated third-party bridge alternative.

Build your own app: a custom all-in-one RTK app follows Architecture A; a custom bridge app that publishes Mock Location follows Architecture B.