Communication: NTRIP, Radio, and Internet Correction Delivery

Introduction

"Corrections must reach the rover in real time - communication is a critical part of GNSS systems."

In an RTK GNSS system, the communication link between base station and rover is not a secondary consideration - it is a core engineering requirement. If corrections do not arrive at the rover continuously, in the correct format, and with low enough latency, RTK positioning fails. The communication subsystem deserves the same design attention as the antenna and receiver. Engineers who neglect this layer routinely encounter mysterious positioning failures that are, in fact, simply communication problems.

What Is Being Transmitted?

The data being transmitted consists of RTCM (Radio Technical Commission for Maritime Services) correction messages. These messages encode the base station's raw satellite observations - pseudoranges, carrier phases, and satellite metadata - along with base station position information. The rover uses this data to compute differential corrections and resolve carrier phase ambiguities.

RTCM messages are compact but require consistent delivery. A typical correction stream for GPS+GLONASS transmits approximately 300–400 bytes per epoch at 1 Hz. Multi-constellation streams supporting GPS, GLONASS, Galileo, and BeiDou can be significantly larger. The communication link must reliably support this data rate continuously throughout the survey or operation.

NTRIP: Internet-Based Correction Delivery

Architecture

NTRIP (Networked Transport of RTCM via Internet Protocol) is the standard protocol for delivering GNSS correction data over the internet. It is built on top of HTTP/1.1, using a client-server architecture with three roles.

• NTRIP Server (Base): The base station software that connects to the caster and pushes the correction data stream continuously. A base station running NTRIP server software encapsulates its RTCM output and streams it to the caster over a standard internet connection.
• NTRIP Caster: The central hub or relay server. It receives streams from one or more NTRIP servers, manages authentication, and serves the streams to connecting clients. Each individual stream is identified by a unique name called a mountpoint. The caster does not process or modify the corrections - it is purely a relay. Casters conventionally operate on TCP port 2101.
• NTRIP Client (Rover): The rover-side application that connects to the caster, authenticates, selects a mountpoint, and receives the correction stream. This can be built into the GNSS receiver firmware, a field controller application, or a software processing engine.

Mountpoints and Sourcetables

A mountpoint is a named correction stream on a caster. Each mountpoint advertises its format (RTCM 2.x, RTCM 3.x, CMR+), the constellations it covers, whether it requires the client to send NMEA GGA position data, and other metadata. The caster's sourcetable - retrieved by requesting the root path of the caster - lists all available mountpoints and their properties. Rover operators must select the most appropriate mountpoint for their location and receiver capability.

VRS and Network RTK via NTRIP

Many NTRIP services operate as network RTK systems - corrections come not from a single physical base, but from a network of CORS stations. In Virtual Reference Station (VRS) mode, the rover sends its approximate position to the caster via NMEA GGA messages, and the network software synthesises corrections that behave as if a virtual base station exists at or near the rover's location. This removes baseline-length degradation and provides consistent accuracy across wide areas.

UHF Radio Links

Before NTRIP became ubiquitous, and still today in areas without reliable mobile internet, UHF radio is the standard correction link for RTK surveys. The base station's correction output is connected to a UHF radio transmitter, and the rover carries a matching radio receiver. Radios typically operate in the 410–470 MHz band and can achieve effective ranges of 3–10 km under line-of-sight conditions.

Data Rate Requirements for RTK Radio Links

RTK requires a minimum of approximately 2,400 bits per second updated at least twice per second. At 1 Hz with a multi-constellation RTCM stream, 4,800 bps is often the practical minimum, and higher update rates or more constellations demand more bandwidth. Radio duty cycle - the proportion of time the radio is actively transmitting - increases with the number of satellites tracked and the update rate. High duty cycles generate heat and reduce radio lifespan; designers should plan for 25 kHz channel widths and efficient RTCM message selection to manage this.

Latency: The Hidden Accuracy Killer

Latency in the correction stream - the "age of corrections" - is a critical parameter. When corrections are delayed, the rover must use older atmospheric and satellite data to correct its current measurements. This introduces temporal mismatch errors that grow with time. For standard RTK, a correction age under 2 seconds is the target. As latency increases beyond 3–5 seconds, positioning accuracy degrades noticeably. Receivers will often display the correction age and flag a warning when it exceeds threshold.

Vital Points

• Communication failure equals RTK failure - a lost correction link immediately degrades the rover to single-point accuracy.
• Internet (NTRIP) and radio are complementary technologies with different strengths; choose based on the operational environment.
• Low latency is essential - correction ages above 3–5 seconds degrade accuracy and should trigger a fallback strategy.
• Always design a fallback: raw data logging for PPK, a backup radio link, or a secondary SIM card are practical options for operational resilience.