RTK Correction Formats, NMEA, and Update Rates
A guide to RTK correction protocols (RTCM, CMR, CMRx, etc.), NMEA messaging, and the recommended update frequencies for different GNSS applications - from surveying to precision agriculture and machine control.
What Are RTK Corrections?
Real-Time Kinematic (RTK) corrections are messages generated by a GNSS base station (or network) that describe the errors affecting satellite observations. These messages enable a rover receiver to correct its raw pseudorange and carrier-phase measurements in real time to achieve centimeter-level accuracy.
Correction formats define how this data is packaged, transmitted, and interpreted. Compatibility between base, network, and rover depends on using the same or compatible formats.
| Format | Developer | Type | Constellation Support | Notes |
|---|---|---|---|---|
| RTCM 3.x (3.0–3.4) | RTCM | Modern MSM observation format | GPS, GLONASS, Galileo, BeiDou, QZSS | Compact, multi-constellation, efficient for NTRIP |
| RTCM 2.x | RTCM (public standard) | Legacy differential corrections | GPS-only (limited GLONASS) | Older systems; limited data rate and precision |
| CMRx | Trimble | Extended proprietary format | Multi-GNSS | Optimized for internal Trimble systems |
| CMR / CMR+ | Trimble | Proprietary binary format | Primarily GPS | Efficient for Trimble UHF workflows, limited interoperability |
RTCM (Radio Technical Commission for Maritime Services) — the de-facto open standard
RTCM has evolved from legacy 2.x messages to the modern, flexible 3.x family used by most networks and receivers today.
RTCM 3.x (modern family - 3.0 → 3.4)
RTCM 3.x is modular, efficient, and extensible. It introduced compact binary encodings and message sets such as MSM (Multiple-Signal Messages) that support multiple constellations and multiple frequencies.
- RTCM 3.3 / 3.4: broader MSM support (GPS, GLONASS, Galileo, BeiDou, QZSS), carrier-phase and pseudorange observation messages, and new messages for SSR (State Space Representation) and enhanced integrity.
- Key message types (conceptual):
- Observation messages (MSM): deliver satellite pseudorange & carrier-phase, signal strength, and other observation metadata.
- Ephemeris/clock messages: updated or precise satellite orbit & clock data.
- DGNSS corrections: pseudorange corrections for single/differential GNSS.
- SSR messages (corrections for satellite orbit, clock, biases) used in PPP/PPP-RTK.
- Why use RTCM 3.x: multi-GNSS, multi-frequency support; compact encoding (lower bandwidth), standardized (vendor-neutral), futures proof (new messages can be added).
- RTCM 3.0 / 3.1 / 3.2: incremental improvements; many networks moved to 3.x for performance.
RTCM 2.x (legacy)
- Overview: Older, widely adopted in the 1990s and 2000s. Message sizes and types are limited; primarily GPS L1 pseudorange and limited carrier corrections.
- Use today: Legacy receivers and older radio networks. Not recommended for new installations where multi-GNSS and multi-frequency observations are required.
- Limitations: Limited support for GLONASS/BeiDou/Galileo, single-frequency centric, less efficient encoding.
Bottom line: if you operate or design a new RTK network or NTRIP service, prefer RTCM 3.x (3.3/3.4) for best multi-GNSS and multi-frequency support.
Trimble CMR, CMR+, CMRx and other proprietary formats
Many receiver vendors historically created their own compact correction formats with the goals of reducing bandwidth and maintaining feature parity with their receiver firmware. Trimble's CMR family is the most widely known of these.
CMRx (newer Trimble format)
- Purpose: Designed to support modern constellations and signals in a more extensible Trimble-native encoding.
- Context: Proprietary, used in Trimble ecosystems where full-featured RTCM may not be available or where Trimble-specific features are needed.
CMR+
- Improvements: Extended message set, additional carrier & pseudorange corrections, support for more observables in Trimble ecosystems.
- Compatibility: Mainly supported by Trimble rovers and some legacy networks; network operators sometimes offer CMR+ mountpoints for legacy users.
CMR (Compact Measurement Record)
- Format: Binary, compact representation of corrections and observations originally optimized for Trimble equipment and UHF links.
- Use: Common in older Trimble radio workflows where bandwidth was constrained.
- Limitations: Vendor proprietary, limited or no support for multi-GNSS/multi-frequency compared with modern RTCM MSM.
Other vendor formats
- NovAtel: OEM-specific binary corrections (e.g., "OEM4" style messages, proprietary INSPVAX logs, etc.).
- Leica / Topcon / Septentrio: each has legacy and modern formats or provide RTCM as preferred standard.
Practical note: Proprietary formats like CMR/CMR+/CMRx are fine if your entire ecosystem (base radios, rover receivers, network caster) supports them. For cross-vendor interoperability and NTRIP network services, RTCM 3.x is the safest choice.
Other correction types & advanced concepts
- RTCM SSR (State Space Representation): sends corrections for satellite orbit, clock and biases used in PPP and PPP-RTK networks.
- CMRnet / RTNet / vendor network formats: network operators sometimes use optimized internal representations and then output RTCM or vendor formats to clients.
- RTK via NTRIP: mountpoints typically stream RTCM (or possibly CMR) over HTTP/TCP from a caster to rovers using cellular or Ethernet backhaul.
- Raw observation streaming: some solutions stream raw RINEX-like observations (e.g., for post-processing) rather than compact RTK corrections.
How to choose a correction format - practical guidance
- Receiver support: always match what the rover supports. New receivers typically accept RTCM 3.x and may optionally accept legacy/proprietary formats.
- Network or base: if you use NTRIP/network, see which mountpoint formats the caster provides (RTCM3 is almost always supported).
- Bandwidth & radios: if using low-bandwidth UHF links, compact formats help - but modern RTCM MSM messages are efficient and designed for multi-GNSS in modest bandwidths.
- Interoperability: for mixed fleets, prefer RTCM 3.x to avoid vendor lock-in.
- Future-proofing: RTCM 3.4 and MSM messages support additional constellations and signals, so they are best for future compatibility.
RTK Correction Update Rates and Latency
The frequency at which a base station transmits corrections - often measured in Hertz (Hz) — determines how "fresh" the data is at the rover. Faster update rates improve the ability to maintain RTK fix solutions during movement or rapid satellite geometry changes but require more bandwidth.
| Application | Typical Correction Rate | Rationale / Notes |
|---|---|---|
| Conventional Surveying / Static Setup | 1 Hz (once per second) | Sufficient for static or slow rover setups where user pauses to record each point. Conserves bandwidth and compatible with most radio/NTRIP setups. |
| Topographic Survey / Walking Rover | 1–2 Hz | Faster updates help maintain smooth position transitions while walking or traversing terrain. |
| Machine Control (Dozers, Graders, Excavators) | 5–10 Hz | High update rate required for rapid blade or bucket response and to avoid latency in machine guidance. Typically delivered via UHF or high-bandwidth digital radios. |
| Precision Agriculture (Tractors, Sprayers) | 5–20 Hz (depending on system) | Continuous motion and real-time steering demand high-frequency updates; often combined with predictive filtering. |
| Marine / Dynamic Applications | 5–20 Hz | Vessel motion and wave dynamics benefit from high-rate updates and low latency. |
| Network RTK (VRS / NTRIP) | 1 Hz (typical) | Caster networks usually transmit RTCM streams at 1 Hz due to cellular bandwidth limits, but rover firmware can interpolate between epochs. |
Rule of thumb: Match your correction rate to how fast your platform moves and how quickly positional changes matter.
Static survey → slow rate; high-speed motion → fast rate.
In all cases, the receiver's internal update rate (often 10–20 Hz) can be higher than the correction rate - the rover interpolates between correction epochs using its own clock model and carrier-phase tracking.
NMEA - Position Output and Status Sentences
The National Marine Electronics Association (NMEA) format is an ASCII text standard used by GNSS receivers to output position, time, and quality data. It's not a correction format - rather, it's a way to communicate real-time position and diagnostic information to external devices.
| Sentence | Meaning | Example |
|---|---|---|
| GGA | Fix data: time, lat/lon, altitude, fix type, satellites used | $GPGGA,123519,4807.038,N,01131.000,E,4,12,0.9,545.4,M,46.9,M,,*47 |
| RMC | Recommended minimum navigation data: position, speed, track, date | $GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A |
| GSA | GNSS DOP and active satellites (fix mode and precision) | $GPGSA,A,3,04,05,...,29,1.8,1.0,1.5*33 |
| GSV | Satellites in view with elevation, azimuth, and signal-to-noise | $GPGSV,2,1,08,01,40,083,46,02,17,308,41,...*7A |
| VTG | Course over ground and ground speed | $GPVTG,054.7,T,034.4,M,005.5,N,010.2,K*48 |
| GLL | Time, lat/lon, status, position validity | $GPGLL,4916.45,N,12311.12,W,225444,A,*1D |
| ZDA | UTC time, day/month/year, local zone offset | $GPZDA,201530.00,04,07,2002,00,00*60 |
Tip: NMEA sentences are commonly sent once per second (1 Hz) in survey equipment, but can be output at higher rates (up to 10–20 Hz) for dynamic applications.
Tip: Modern multi-GNSS receivers often use the GN talker (e.g., $GNGGA) to indicate multi-constellation solutions rather than satellite-specific talkers.
How Corrections and NMEA Work Together
- Corrections in: Rover receives RTCM/CMR data via radio, NTRIP, or IP stream.
- Corrections applied: Rover solves carrier-phase ambiguities and computes corrected position.
- NMEA out: Rover outputs corrected coordinates to data collectors or machines along with fix quality (e.g., 4 = RTK Float, 5 = RTK Fixed on some firmware), number of satellites, HDOP, etc.
This division allows corrections and output to operate independently - for example, receiving RTCM3 at 1 Hz while outputting NMEA GGA at 10 Hz.
Practical examples & compatibility checklist
When setting up an RTK link or NTRIP service, follow this checklist:
- Verify rover supports the correction format(s) provided by your caster/base (RTCM3, CMR+, CMRx, etc).
- Prefer RTCM 3.x for multi-GNSS, multi-frequency support and future compatibility.
- If operating a legacy Trimble fleet, you may need CMR/CMR+ mountpoints; consider providing both RTCM and CMR streams if possible.
- Transport: NTRIP over cellular/ethernet is universal for wide-area coverage; UHF radios are common for local base→rover links where internet is unavailable.
- Check message latency and bandwidth — MSM/RTCM3 messages are compact, but SSR/PPP messages may require more throughput.
Final notes & best practices
- Interoperability: RTCM 3.x is the best cross-vendor choice; proprietary formats may be needed for legacy hardware.
- Future-proofing: choose equipment and networks that support MSM/RTCM 3.4 and SSR if you plan on PPP/PPP-RTK or full multi-GNSS signal use.
- Monitoring: combine NMEA (GGA/GSA/GSV) with receiver-specific status messages and quality flags to judge solution health, not just the presence of corrections.
If in doubt: consult receiver vendor documentation for supported correction message types and NTRIP caster/mountpoint configurations before deploying a mixed-fleet network.