Glossary

D

DGNSS (Differential GNSS): DGNSS is a positioning method that applies real-time pseudorange corrections from a fixed base station to a rover, reducing common-mode errors and delivering sub-meter to meter-level accuracy without the need for carrier-phase ambiguity fixing.

Working Setup:

Base Station (Static): Known coordinates, broadcasts corrections
Rover (Mobile): Receives and applies pseudorange corrections

How It Works:

The base computes pseudorange correction data (e.g. RTCM messages 1005/1006 for station coordinates, 1012 for extended observations)
Corrections are broadcast at ~1 Hz via radio or NTRIP
The rover adds these pseudorange corrections to its own GNSS measurements

Results:

0.5–2 meter accuracy
Simple processing
Tolerant of multi-second latency

Key Similarities with RTK:

Both rely on a static base station distributing RTCM streams
Both use radio or IP/NTRIP transport
Both employ standard RTCM messages for correction delivery

Key Differences from RTK:

Measurements Used: DGNSS uses pseudorange only; no carrier-phase
Accuracy: DGNSS ⇒ 0.5–2 meters; RTK ⇒ 1–3 cm
Latency Tolerance: DGNSS works with seconds of delay; RTK needs < 0.1 seconds
Complexity: DGNSS has no ambiguity resolution, making it easier to implement but less precise

G

Galileo High Accuracy Service (GAL HAS) is a free, global correction service that broadcasts precise point positioning corrections directly via the Galileo E6-B signal (and over the Internet via NTRIP). Its goal is to give single-receiver users better than 20 cm horizontal accuracy with convergence in minutes—no local base station required.

GAL HAS is a free, global correction service that broadcasts PPP corrections via the Galileo E6-B signal and NTRIP, targeting <20 cm horizontal accuracy with fast convergence and no local base station.

Comparison with PPP and RTK:

PPP: Global corrections, single receiver, 10–30 min convergence
RTK: Requires base+rover, cm-level accuracy, instant fix

What GAL HAS Offers:

Global Broadcast: SL1 (orbit/clock/bias), SL2 (adds atmospherics over Europe)
Fast Convergence: <300 s (SL1), <100 s (SL2)
Single Receiver: No base station needed
Free & Open: Via Galileo E6-B + NTRIP
High Accuracy: 95% within 20 cm horizontal, 40 cm vertical

How It Works:

Ground Segment computes real-time satellite data and models
Corrections sent via Compact-SSR RTCM (e.g. 1057/1058, 1065, 1230/1240)
Broadcast over E6-B channel (448 bps/satellite) and NTRIP
User receiver applies SSR corrections to own pseudorange + carrier-phase

N

Networked Transport of RTCM via Internet Protocol (NTRIP):

In basic terms, NTRIP is a protocol through which users can receive RTCM messages for corrections. It uses the Internet for communication. There are two types of NTRIP: one is the ‘caster’, which broadcasts the correction data, and the other is the ‘client’, which receives these corrections.

The NTRIP client service takes the corrections from the user side and uses this data to perform the Real-Time Kinematic (RTK) process, which is the most common use today. However, this is not the only purpose of these messages; they are also used for various tasks such as creating the ionospheric VTEC map of the world. This includes Single Point Positioning (SPP), and Precise Point Positioning (PPP). Some of the data flowing here is updated continuously, while others are updated at certain intervals.

Here are some examples of common messages:

RTCM message 1004: An observation type message. This message contains information about the transmitter that broadcasts, so it is constantly updated.
RTCM message 1019: The navigation message of GPS satellites. Such messages are renewed every 2 hours.
Ionospheric messages: The duration may vary from 15 minutes to 1 hour, depending on the situation.

These examples are given to establish a general understanding. NTRIP is the main source of detailed information transfer, not just a flat protocol for a single purpose, but a dynamic system used for positioning tasks and for every piece of data obtained by satellites.

P

Precise Point Positioning (PPP): It is a GNSS technique that allows a single, standalone receiver to determine its position with decimeter-level accuracy by applying globally distributed correction data rather than relying on a nearby reference station. In PPP, the receiver uses precise satellite ephemerides and clock products—together with modeled biases (code and carrier-phase offsets) and atmospheric corrections—to refine its raw pseudorange and carrier-phase measurements against the true satellite orbits and signal delays. These correction streams are typically delivered via Internet protocols (e.g., NTRIP) or, in the case of modern services, embedded directly in GNSS signals.

Unlike RTK, which requires a two-way link between a base and a rover and solves integer ambiguities in real time for centimeter-level fixes, PPP operates on a one-way broadcast of state-space corrections and resolves floating ambiguities on the user side. Classical PPP convergence can take 10–30 minutes as the receiver refines its bias and atmospheric estimates; however, advanced PPP-SSR services (such as those on Galileo E6-B) shorten convergence to a few minutes by providing real-time orbit, clock, and atmospheric models. The result is a simpler, globally available positioning solution—no local infrastructure required—that trades slightly longer initial convergence for easy deployment and broad coverage.

R

Radio Technical Commission for Maritime Services (RTCM): RTCM is a standardized binary protocol—often called “RTCM SC-104”—made for sending GNSS correction and extra data in real time. Just as NTRIP carries those RTCM streams over the Internet, RTCM itself specifies how a reference station neatly packs:

Raw Observations:
- Pseudorange: The receiver’s rough distance to each satellite, calculated from the time delay of the GNSS signal.
- Carrier phase: The fine-tuned measurement of the signal’s wave phase, used for centimeter-level accuracy once ambiguities are resolved.
- Signal quality: Metrics like signal-to-noise ratio that tell you how reliable each measurement is.
Satellite Ephemerides and Clock Corrections
Base-Station Coordinates and Antenna Metadata
Auxiliary Models: (Ionospheric, tropospheric, network topology, meteorology)

The data is packed into compact messages. Here’s how each message is built, in the simplest terms:

Preamble: A tiny, fixed bit pattern at the very start—like a “flag”—so the receiver knows, “A new message begins here.”
Length Field: A small number right after the preamble that tells you exactly how many bytes of data are coming next.
Payload: The core of the message—the actual correction data, ephemerides, coordinates, or models—packed in a predefined order.
CRC (Cyclic Redundancy Check): A short checksum at the end; the receiver recalculates it to verify that nothing got garbled in transit.

On the sender side, a GNSS reference receiver gathers its computed corrections and metadata, wraps them into these RTCM packets, and broadcasts them—either over radio or via network services (for example, an NTRIP caster). On the receiver side, an RTK/PPP rover or software acts as the RTCM client, unpacks those messages, checks their CRC, and applies the corrections to achieve precise positions or feed advanced models.

Because RTCM uses one uniform, manufacturer-neutral format—from simple DGPS corrections to modern state-space streams—it guarantees that any compliant equipment or software can work together and reach centimeter-level accuracy in surveying, agriculture, autonomous systems, and more.

R

Real-Time Kinematic (RTK): It is an augmentation technique in GNSS positioning where a fixed reference station and a mobile rover share real-time measurements to achieve centimeter-level accuracy. The reference station broadcasts both pseudorange and carrier-phase corrections, and the rover applies an integer-ambiguity resolution to those corrections on the fly.

Working Setup

Base Station (Static): Installed at a precisely surveyed location.
Rover (Mobile): Mounted on a vehicle or handheld unit.

How It Works

Both base and rover collect raw pseudorange and carrier-phase observations.
The base packages these corrections into RTCM streams (e.g., messages 1002/1004 for observations, 1012 for carrier-phase) and broadcasts them via radio or NTRIP.
The rover receives the RTCM packets, performs integer ambiguity resolution on the carrier-phase data, and applies corrections to its own measurements.

Results: 1–3 cm horizontal accuracy, update rates up to 20 Hz, latency < 100 ms.

Key Similarities with DGNSS

Both use a static base station to generate RTCM-formatted correction streams.
Both transport corrections via radio links or IP/NTRIP.
Both employ the same RTCM message framework for observations and station coordinates.

Key Differences from DGNSS

Measurements Used: RTK uses carrier-phase + pseudorange; DGNSS uses pseudorange only.
Accuracy: RTK ⇒ cm-level; DGNSS ⇒ 0.5–2 m.
Latency Requirement: RTK demands < 0.1 s; DGNSS tolerates seconds.
Complexity: RTK requires ambiguity-resolution algorithms; DGNSS is simpler.