RTCM Unpacked: The Binary Protocol Your RTK Fix Actually Depends On

RTCM is the correction-data layer behind an RTK fix: NTRIP often transports it, NMEA reports the result, but RTCM is the binary stream that gives the rover the reference observations needed for centimeter-level positioning.

If you've built an RTK system, you likely already speak NMEA — the readable ASCII stream telling you where you are. You've probably configured an NTRIP client to pull correction data over the internet. But have you ever looked inside the binary payload NTRIP is actually carrying?

That payload is RTCM. It contains the satellite observations from a reference station, encoded into a compact binary format. Your receiver consumes this data to move from meter-level standalone positioning toward centimeter-level RTK. If NMEA is the final answer your receiver gives you, RTCM is the input it needs to make that answer precise.

In this volume of the Kalmix GNSS Handbook, we crack open the RTCM binary stream. We will cover what's inside it, which messages actually matter, how to choose between MSM4 and MSM7, and what to check when your rover stubbornly refuses to reach Fixed.

Where RTCM Fits in the RTK Data Chain

Every RTK system relies on two data flows moving in opposite directions:

• RTCM flows in: carrying correction data from the reference station to the rover.
• NMEA flows out: carrying the computed position, status, and fix quality from the receiver to your host controller.

NTRIP is the delivery truck; RTCM is the cargo. Your receiver takes the base station's RTCM observations, differences them against its own, and resolves carrier-phase ambiguities to produce centimeter-level coordinates.

RTCM vs. NMEA: Inputs and Outputs

If you read our NMEA 0183 guide, you already know the receiver-output side of the positioning stack. RTCM is the opposite side: compact, binary, and intended for machines rather than humans.

RTCM's binary encoding is roughly 5–10x more bandwidth-efficient than ASCII-style data. This is why it survives on constrained serial radio links where every byte counts.

A Brief History of RTCM 3

Modern RTK work should be built around RTCM 3.x. The older versions explain the standard's origin, but they are not where most current multi-constellation RTK systems should start.

Versions 1 and 2 were built in the 1980s and 1990s for maritime DGPS. They used rigid, 30-bit words that were not well suited for the higher data volumes of modern RTK. In most current rover integrations, you can treat them as legacy. For the official standards body behind the protocol, see the Radio Technical Commission for Maritime Services.

The modern era began with Version 3 in 2004, featuring variable-length frames and robust 24-bit CRCs. The structural shift came with V3.2 in 2013, which introduced Multiple Signal Messages, or MSM.

Before MSM, legacy messages such as MT1001–1012 were hard-coded mainly for GPS and GLONASS. The standard had no clean multi-constellation structure for Galileo or BeiDou. MSM fixed this architectural dead-end with a constellation-agnostic matrix design.

In practice, using legacy observation messages on a modern receiver caps the receiver's ability to use today's multi-constellation sky.

For the field-level frame and message reference, use the companion document AN-002: RTCM SC-104 v3.3 Frame Structure & Message Type Reference.

Inside the Packet: Frame Structure

Every RTCM 3.x frame follows the same envelope:

┌──────────┬──────────┬──────────┬──────────┬──────────┐
│ Preamble │ Reserved │  Length  │ Payload  │ CRC-24Q  │
│  8 bit   │  6 bit   │  10 bit  │ Variable │  24 bit  │
│  0xD3    │  000000  │ 0–1023   │ (binary) │          │
└──────────┴──────────┴──────────┴──────────┴──────────┘

Unlike NMEA, there are no newline characters. You cannot just "read a line." You must synchronize on 0xD3, read the length field, extract exactly that many payload bytes, and verify the CRC.

Here is the canonical pattern in Python:

"""
RTCM 3.x frame sync & extraction from a TCP/serial stream.

CRITICAL:
TCP delivers arbitrary byte chunks. Never assume one recv()
equals one complete RTCM frame. Always buffer.
"""

CRC24Q_POLY = 0x1864CFB

def crc24q(data: bytes) -> int:
    crc = 0
    for byte in data:
        crc ^= byte << 16
        for _ in range(8):
            crc <<= 1
            if crc & 0x1000000:
                crc ^= CRC24Q_POLY
    return crc & 0xFFFFFF

def extract_frames(buf: bytearray):
    frames = []

    while True:
        # 1. Find preamble
        try:
            start = buf.index(0xD3)
        except ValueError:
            buf.clear()
            return frames

        # Drop noise before preamble
        if start > 0:
            del buf[:start]

        # Need at least 3 header bytes
        if len(buf) < 3:
            return frames

        # 2. Validate reserved bits and parse payload length
        if buf[1] & 0xFC:
            del buf[0]
            continue

        length = ((buf[1] & 0x03) << 8) | buf[2]
        frame_len = 3 + length + 3

        if len(buf) < frame_len:
            return frames

        frame = bytes(buf[:frame_len])

        # 3. Verify CRC-24Q
        received_crc = int.from_bytes(frame[-3:], "big")
        computed_crc = crc24q(frame[:-3])

        if received_crc == computed_crc:
            frames.append(frame)
            del buf[:frame_len]
        else:
            # False sync. Advance one byte and rescan.
            del buf[0]

The Message Groups and the Two Silent Killers

RTCM 3.x defines many message types, but an RTK rover only needs a practical subset for most field work.

While observation messages are obvious, developers often lose time on two missing message types that fail less visibly:

• MT1005/1006, Base Station Identity: these carry the base station's physical coordinates. Without them, your rover cannot compute a baseline vector. No station coordinates means no baseline, and no baseline means no Fix.
• MT1230, GLONASS Interoperability: GLONASS uses FDMA, which creates hardware biases between different receiver brands. MT1230 carries the code-phase bias compensation. Without it, your rover may see GLONASS satellites but refuse to use them in the RTK solution.

The MSM Dilemma: Which Version?

MSM, or Multiple Signal Messages, is the RTCM 3.2+ observation-message family introduced in 2013 to replace legacy single-constellation messages such as MT1001–1012. Each MSM message ID encodes both the constellation family and the payload richness level.

MSM numbers are logical. The prefix identifies the constellation, such as 107x for GPS and 112x for BeiDou. The last digit, from 1 to 7, indicates payload richness.

The Format Landscape: RTCM vs. The Rest

RTCM is the interoperability default for RTK correction streams, but you will encounter other correction or logging formats in the field.

Beyond RTCM, the GNSS correction and logging format landscape is generally categorized into proprietary bandwidth-saving protocols like CMRx, state-space representation (SSR) models like SPARTN for mass-market PPP-RTK, and raw receiver-independent logging formats like RINEX:

• CMRx, Trimble proprietary: created to save bandwidth. It can be smaller than RTCM MSM, but it ties the workflow to Trimble hardware. For cross-manufacturer interoperability, RTCM remains the safer choice.
• SPARTN, openly specified: built for mass-market PPP-RTK and low-bandwidth satellite or IP broadcasts. While RTCM OSR sends base-station observations for local differencing, SPARTN SSR sends modeled error components such as orbit, clock, and atmosphere corrections.
• RINEX: a receiver-independent logging format used for post-processing. It is not normally the real-time correction stream, but it matters when you need PPK fallback or forensic analysis.

The Developer’s Debugging Checklist

When your rover — whether it is a custom board or a field-ready receiver like the Kalmix SCOUT PRO — refuses to reach Fixed, inspect the incoming stream before assuming the GNSS hardware or parser is wrong. Tools such as RTKLIB's str2str can help verify what the rover is actually receiving.

Common RTK debugging patterns share a single principle: when the rover refuses to Fix, the failure is usually in what the rover is receiving — not in what it is computing. The five most frequent symptoms below all point to specific upstream gaps.

• GGA Fix Quality stuck at 1 You may be missing MT1005/1006. The rover cannot identify the base station position and therefore cannot compute a baseline.
• GLONASS visible in GSV but not used in GSA You may be missing MT1230. Switch to a mountpoint that includes it, or disable GLONASS to reduce processing load if your correction service does not support it.
• Correction Age climbing steadily The TCP, radio, or cellular correction link is stale or dropped. Implement reconnection logic and monitor correction age in your host application.
• Fix is very slow, or Correction Age jumps erratically You may be bandwidth-choked. Full-constellation MSM7 over a slow radio link can overflow the link. Drop to MSM4, reduce constellations, or lower the correction update rate.
• Position offset is stable but wrong by meters This is likely not an RTCM decoding issue. Check coordinate frame and datum alignment. See Beyond WGS84 for why a technically precise fix can still land in the wrong map frame.

Conclusion

RTCM is not a protocol most developers need to hand-write. It is a correction stream your system must route, validate, and monitor correctly.

Verify that your receiver supports RTCM 3.x MSM. Select a mountpoint broadcasting MSM observations, MT1005/1006 station coordinates, and MT1230 if GLONASS is part of your solution. Monitor NMEA GGA Fix Quality and Correction Age. If Correction Age climbs, the problem is upstream in the input chain, even if the receiver keeps outputting position sentences.

For a complete field-by-field breakdown of binary frame structure, CRC-24Q, and MSM mask handling, read the companion reference: AN-002: RTCM SC-104 v3.3 Frame Structure & Message Type Reference.

Frequently Asked Questions