AN-002: RTCM SC-104 Frame Structure & Message Type Reference

Part 1 — Protocol Architecture & Parsing Fundamentals

1.1 Data Type Conventions

RTCM 3.x payloads are encoded as a continuous, non-byte-aligned bit stream in big-endian (MSB first) order. All field positions and widths in this document are specified in bits, not bytes. Developers must use bit-level extraction functions (see Appendix A) to read fields that span byte boundaries.

RTCM 3.x payloads use non-byte-aligned bit streams constructed from three base binary data types:

Scale Factor Rule: Many DF fields encode physical quantities as scaled integers. The conversion is:

Physical Value = Extracted Integer × Resolution

Resolution values are specified in the Notes column of each field table throughout this document.

Invalid Value Convention: Certain DF fields use a designated bit pattern (typically all-ones or a specific hex value) to indicate that the observation is missing or invalid. These are marked in the Notes column of each field table (e.g., 255 = invalid, 0x4000 = invalid).

1.2 General Frame Structure

Every RTCM 3.x message is encapsulated in a fixed-format binary frame. Unlike NMEA 0183's ASCII sentences delimited by $ and <CR><LF>, RTCM frames have no human-readable delimiters. Frame boundaries must be established programmatically through preamble detection, length parsing, and CRC verification.

An RTCM 3.x frame has a fixed byte-level wrapper around a variable-length payload; a parser should validate the preamble, declared payload length, and CRC before dispatching the message type:

The byte-level RTCM 3.x frame wrapper consists of the following fields:

1.3 CRC-24Q Algorithm

The CRC-24Q is computed over all bytes from Preamble through the end of Payload. If the computed CRC does not match the 3-byte CRC field appended to the frame, the entire frame must be discarded.

RTCM 3.x uses CRC-24Q to protect the frame header and payload; parser implementations should reject the frame before decoding any message fields when the CRC check fails.

C language reference implementation:

#define CRC24Q_POLY 0x1864CFB

unsigned int crc24q(const unsigned char *buf, int len) {
    unsigned int crc = 0;
    int i, j;
    for (i = 0; i < len; i++) {
        crc ^= (unsigned int)buf[i] << 16;
        for (j = 0; j < 8; j++) {
            crc <<= 1;
            if (crc & 0x1000000) crc ^= CRC24Q_POLY;
        }
    }
    return crc & 0xFFFFFF;
}

1.4 Frame Synchronization

RTCM 3.x frames contain no line-ending characters or inter-frame delimiters. When reading from a TCP socket or serial port, incoming bytes arrive as an arbitrary continuous stream. The parser must implement a state machine to locate frame boundaries:

A streaming RTCM parser should be implemented as a byte-level state machine because TCP, USB, and UART reads do not preserve RTCM frame boundaries:

*Remark: On CRC failure, do not skip the entire frame — the 0xD3 byte that triggered this attempt may have been a coincidental data byte, and a real preamble may exist within the bytes already consumed. Robust implementations rescan from preamble_position + 1.

TCP/Serial Buffer Handling: TCP delivers data in arbitrarily-sized chunks. A recv() call may return a partial frame, multiple frames, or a frame split across two calls. The parser must maintain a persistent ring buffer or byte queue across read operations and never assume a single read contains a complete frame.

Part 2 — Multiple Signal Messages (MSM), MT1071–MT1137

2.1 Constellation Assignment

MSM messages use a systematic numbering scheme: each constellation is assigned a block of 7 message types (MSM1 through MSM7). RTCM 3 Multiple Signal Messages group satellite observations by constellation, mapping message types MT1071 through MT1137 to specific GNSS signal families and time epochs:

2.2 MSM Type Definitions (Last Digit → Content)

RTCM MSM message numbers use the last digit to identify the observation content level, while the first three digits identify the constellation family:

*Reference note: this table identifies payload content for parser implementation. For deployment-level MSM selection, see RTCM Unpacked.

2.3 MSM Payload Architecture

Every MSM message payload is organized in three consecutive segments. The Header is fixed-structure (though Cell Mask length varies). The Satellite Data and Signal Data segments have lengths determined dynamically by the mask values parsed from the Header.

An MSM payload is decoded in layers: fixed header fields first, then satellite and signal masks, then variable-length observation data derived from the active cell mask:

The number of Satellite Data blocks (N_sat) and Signal Data blocks (N_cell) cannot be known until the three mask fields in the Header have been read and decoded. See Section 2.5 for the dynamic length calculation algorithm.

2.4 MSM Header (DF Field Reference)

The MSM header is a fixed field sequence followed by variable masks. Start Bit values in this table are measured from the first bit of the RTCM message payload, starting at DF002, not from the outer 0xD3 frame header:

*Remark: Start Bit values in this table are measured from the first bit of the RTCM message payload, starting at DF002, not from the outer 0xD3 frame header. The fixed MSM header portion from DF002 through DF418 is 73 bits. After the 64-bit Satellite Mask and 32-bit Signal Mask, the Cell Mask begins at bit 169. Total MSM header length is 169 + (N_sat × N_sig) bits.

2.5 The Mask Matrix & Dynamic Length Calculation

The three mask fields in the MSM Header form a two-dimensional matrix that determines how many data blocks follow, and in what order. Incorrect mask handling is the primary source of buffer overrun and data misalignment bugs in RTCM parsers.

Step-by-step algorithm:

// Step 1: Count satellites with data in this frame
N_sat = popcount(Satellite_Mask);   // number of set bits in 64-bit mask

// Step 2: Count signal types present in this frame
N_sig = popcount(Signal_Mask);      // number of set bits in 32-bit mask

// Step 3: Read the Cell Mask (variable length)
Cell_Mask = read_bits(N_sat * N_sig);

// Step 4: Count actual observation cells
N_cell = popcount(Cell_Mask);       // total signal data blocks to parse

// Satellite Data segment: N_sat blocks, each containing per-satellite fields
// Signal Data segment:    N_cell blocks, each containing per-cell fields

Data ordering rules:

• Satellite Data blocks are ordered by the set-bit positions in the Satellite Mask, from the lowest bit index to the highest.
• Signal Data blocks are ordered in satellite-major order: iterate through each satellite (in Satellite Mask bit order), and within each satellite, iterate through its signal types (in Signal Mask bit order), including only cells where the corresponding Cell Mask bit is 1.

Worked example:

Satellite Mask: bits 2, 5, 11 are set  →  N_sat = 3  (PRN 3, 6, 12)
Signal Mask:    bits 1, 4 are set       →  N_sig = 2  (e.g., L1 C/A, L2C)

Cell Mask (3 × 2 = 6 bits):  read in transmission order →

MSM payload length is data-dependent because the Cell Mask determines how many satellite-signal observation cells are present in the message.

N_cell = popcount(Cell_Mask) = 5
Signal Data contains 5 blocks, transmitted in the Cell order shown above.

*Critical Limit: The RTCM standard dictates that N_sat × N_sig ≤ 64. If the product of set bits in the Satellite Mask and Signal Mask exceeds 64, the Cell Mask is invalid and the frame must be discarded. Parsers must check this boundary before attempting to allocate memory or read the Cell Mask to prevent severe buffer overflows.

2.6 MSM Satellite Data Fields

One block of Satellite Data fields is transmitted per satellite (repeated N_sat times). Not all fields are present in every MSM type — the "Present in" column indicates which MSM types include each field.

*Important: Within each MSM frame, all values for a given DF are transmitted contiguously before the next DF begins. For example, in MSM7 with N_sat = 3: all three DF397 values are sent first, then all three DF398, then all three DF399, then all three DF404.

Satellite data fields are transmitted once per active satellite and provide rough range, phase range, and range-rate information before per-cell signal observations are decoded.

2.7 MSM Signal Data Fields

One block of Signal Data fields is transmitted per observation cell (repeated N_cell times). As with Satellite Data, all values for a given DF are transmitted contiguously across all cells before the next DF begins.

Signal data fields are transmitted per active observation cell and carry the fine pseudorange, fine carrier phase, lock time, half-cycle, and CNR values used by a rover decoder.

*Remark on DF404: The RTCM standard reuses the DF404 identifier for two distinct Doppler fields at different data layers. In the Satellite Data segment (Section 2.6), DF404 is a 14-bit rough estimate at 1 m/s resolution. In the Signal Data segment (this section), DF404 is a 15-bit fine-resolution field at 0.0001 m/s. Parser implementations must extract the correct bit width depending on the payload segment currently being decoded.

2.8 Common MSM Signal IDs (RTKLIB Index & Mask Position)

Each MSM Signal Mask entry maps to a constellation-specific signal code. To avoid off-by-one ambiguity, the tables below show both the zero-based RTKLIB C array index and the equivalent one-based Signal Mask position:

*Indexing note: these compact tables follow the RTKLIB current-master msm_sig_*[32] arrays as an open-source implementation reference. RTKLIB Index is the zero-based C array slot used by decoder code; 1-Based Mask Position is RTKLIB Index + 1. The RTCM SC-104 standard remains the normative source for production implementations.

*Signal naming note: this section maps common RTCM MSM signal IDs to RTKLIB/RINEX-style observation codes. For the GNSS frequency background behind L1/L2/L5, E1/E5, B1/B2, QZSS, NavIC, and SBAS signals, see GNSS Signals Explained.

GPS Signal Codes

GLONASS Signal Codes

*GLONASS note: G1/G2 use FDMA, so each satellite transmits on a channel-dependent frequency. MT1230 Code-Phase Biases (Part 3.4) help rovers handle inter-manufacturer bias differences on FDMA signals.

Galileo Signal Codes

BeiDou Signal Codes

*BeiDou mapping note: this compact table follows RTKLIB current-master msm_sig_cmp[] for parser validation. BeiDou signal-code naming can differ across RTCM/RINEX revisions and decoder implementations; use the RTCM SC-104 revision required by your product as the normative source.

QZSS, NavIC, and SBAS MSM Families

QZSS, NavIC/IRNSS, and SBAS use dedicated MSM message ranges in RTCM 3.3+. In parser code, treat them as separate constellation families with their own epoch rules and signal-mask interpretation, even when some signal names overlap with GPS-style L1/L2/L5 notation.

Part 3 — Base Station & Interoperability Messages

3.1 Station Coordinates — MT1005

Transmits the Antenna Reference Point (ARP) position in ECEF coordinates. This message is mandatory for RTK operation — without base station coordinates, the rover cannot compute a baseline vector and will never achieve a fixed solution regardless of observation data quality.

MT1005 defines the reference station coordinate payload; these ECEF fields establish the base-station position used by downstream RTK solvers.

*Remark: Total payload: 152 bits (19 bytes). The three ECEF coordinate fields (DF025/026/027) together consume 114 of 152 bits — 75% of the message is coordinate data. The int(38) type provides a range of approximately ±13,744 km from the Earth's center, sufficient for any terrestrial antenna position.

3.2 Station Coordinates + Antenna Height — MT1006

Identical to MT1005 with one additional field appended:

MT1006 extends MT1005 by adding antenna height, allowing a rover or post-processing tool to reconstruct the antenna reference point more precisely.

*Remark: Total payload: 168 bits (21 bytes). MT1006 is preferred over MT1005 when the antenna is mounted on a known survey marker and the height tie is measured.

3.3 Receiver & Antenna Descriptors — MT1033

Carries human-readable text descriptions of the base station's receiver and antenna hardware. This message uses variable-length ASCII string fields, each preceded by a length indicator.

Field sequence (in transmission order):

MT1033 describes receiver, antenna, and serial-number metadata; it is useful for logging, traceability, and mixed-equipment base-station identification.

*Remark: The Antenna Descriptor string provides the antenna model name needed for Phase Center Offset (PCO) corrections. However, the rover must have a built-in antenna calibration database (e.g., derived from NGS/IGS calibration files) to act on this information. Low-cost GNSS modules without such a database will receive MT1033 but cannot apply PCO corrections from it.

3.4 GLONASS Code-Phase Biases — MT1230

GLONASS uses Frequency Division Multiple Access (FDMA), causing inter-frequency code-phase biases between receivers from different manufacturers. MT1230 provides bias correction values that enable the rover to compensate for these hardware differences.

MT1230 carries GLONASS code-phase bias information; decoders should parse it separately from MSM observations because it affects GLONASS interoperability rather than observation-cell layout.

*Critical: Without MT1230 in the correction stream, the rover will observe GLONASS satellites but exclude them from the RTK solution without an explicit parser error because the inter-frequency biases cannot be resolved. This often appears in mixed-vendor base-rover combinations. Verify MT1230 whenever GLONASS satellites are visible but do not contribute to the fixed solution.

*Output validation note: if GLONASS satellites are visible but not used in the RTK solution, check both the RTCM MT1230 input and the receiver's NMEA output fields. For SCOUT PRO output behavior, see the SCOUT PRO protocol knowledge base.

Part 4 — Quick Reference Tables

4.1 Legacy Observation Messages (MT1001–MT1012)

Legacy observation messages predate the MSM framework and are limited to GPS and GLONASS on L1/L2 bands only. No message type numbers exist for Galileo or BeiDou in the Legacy scheme — this is a structural limitation of the standard, not a versioning gap, and is the fundamental reason MSM was created.

*Remark: Legacy messages are still encountered in production, particularly from state CORS networks and older base stations. Some correction services (e.g., Swift Navigation Skylark) provide RTCM 3.1 fallback mountpoints using MT1004/1012. However, new deployments should use MSM (Part 2) for multi-constellation support.

4.2 Ephemeris Messages

Broadcast ephemeris data relayed from the base station's GNSS receiver. These messages duplicate information the rover can acquire directly from satellite signals.

Ephemeris messages carry satellite orbit and clock data; many real-time RTK links rely on rover-side navigation data, but parsers should still dispatch these message types correctly.

*Remark: Ephemeris decoding is handled by the GNSS receiver's firmware. Developers typically do not need to parse these messages manually. Primary use cases: reducing Time-To-First-Fix (TTFF) for cold-start rovers, and providing ephemeris data in raw RTCM logs for Post-Processed Kinematic (PPK) workflows.

4.3 SSR Messages (Overview)

State Space Representation (SSR) messages carry modeled error components for Precise Point Positioning (PPP) and PPP-RTK. These are not used in standard Observation Space Representation (OSR) RTK workflows.

SSR message types are used for state-space correction workflows rather than conventional OSR RTK streams, so AN-002 lists them only as a parser-recognition reference.

*Remark: Standard OSR RTK correction streams (e.g., from CORS networks or services like Point One Polaris, Swift Skylark) do not contain SSR messages. SSR data is delivered via dedicated channels, often using the SPARTN format (e.g., u-blox PointPerfect) rather than RTCM encoding.

4.4 Common RTCM Stream Profiles for Parser Validation

Common RTCM stream profiles are listed here for parser test coverage and log inspection, not for selecting a production RTK mountpoint. These profiles often appear in NTRIP mountpoints and base-station output streams; deployment choices such as MSM4 versus MSM7 should be handled in RTCM Unpacked:

*Critical: MT1230 is marked as required (not optional) whenever GLONASS MSM messages are included. Omitting it will cause the rover to discard GLONASS observations from the RTK solution without an explicit parser error.

4.5 Bandwidth Estimation

Approximate data rates for common message configurations at 1 Hz update rate. Actual values vary with satellite count and signal count.

RTCM stream bandwidth depends on constellation count, signal count, message rate, and MSM level; the table below gives practical parser/logging expectations rather than fixed protocol limits.

*Remark: 9600 bps (common for UHF radio links) provides a theoretical maximum throughput of 960 bytes/second, factoring in 8-N-1 serial framing overhead (10 bits per byte on the wire). In practice, protocol overhead reduces usable bandwidth to approximately 900 B/s. For 9600 baud deployments, GPS + GLONASS MSM4 is the practical upper limit.

4.6 RTCM ↔ RINEX 3

RTCM 3.x and RINEX 3 encode the same observation data in different representations: RTCM is a compact binary format designed for real-time streaming, while RINEX 3 is a human-readable text format designed for offline archival and post-processing.

MSM message structure was designed for conversion to and from RINEX 3 observation records. The signal-mask indices listed in Section 2.8 map to RTKLIB/RINEX-style observation codes, and the RTKLIB convbin utility performs this conversion.

*Remark: RINEX 2 does not support multi-constellation observation encoding and cannot represent the full range of MSM signal types. Always use RINEX 3.0x or later when converting from MSM data. A standard PPK workflow is: record raw RTCM stream → convert to RINEX 3 via convbin → process with PPK engine (e.g., RTKLIB rnx2rtkp).

4.7 Open-Source Reference Implementations

The following RTKLIB components serve as the open-source implementation references for RTCM 3.x parsing and are useful for parser comparison or debugging:

Open-source RTCM implementations are useful for cross-checking parser behavior, CRC handling, and field scaling against known decoder code paths.

*Remark: RTKLIB's MSM decoding logic is concentrated in decode_msm_head() (mask parsing, Section 2.5) and decode_msm4() through decode_msm7() (observation extraction, Sections 2.6/2.7). Reading these functions is the most direct path to understanding how the Mask Matrix operates in practice.

*Reference-stream note: when comparing your parser against rtcm.c, capture repeatable binary input from known hardware before changing decoder logic. For module-level testing, see the Kalmix GUIDE Module.

Appendix A — Bit-Level Extraction Reference (C Language)

RTCM 3.x payloads are non-byte-aligned bit streams. The following two functions extract unsigned and signed integers of arbitrary bit width from any bit offset in a byte buffer. These are adapted from the RTKLIB open-source implementation and serve as the low-level primitives for all DF field extraction described in this document.

*Note: These functions handle byte-boundary crossing internally. Callers should not perform additional endianness conversions — the big-endian bit ordering of the RTCM stream is resolved within the extraction logic.

/* Extract unsigned integer of 'len' bits starting at bit position 'pos' */
unsigned int getbitu(const unsigned char *buff, int pos, int len) {
    unsigned int bits = 0;
    int i;
    for (i = pos; i < pos + len; i++) {
        bits = (bits << 1) + ((buff[i / 8] >> (7 - i % 8)) & 1u);
    }
    return bits;
}

/* Extract signed integer (Two's Complement) of 'len' bits */
int getbits(const unsigned char *buff, int pos, int len) {
    unsigned int bits = getbitu(buff, pos, len);
    if (len <= 0 || 32 <= len || !(bits & (1u << (len - 1)))) {
        return (int)bits;
    }
    return (int)(bits | (~0u << len));  /* sign extension */
}

Usage example — extracting the Message Type (DF002) from a frame payload:

/* payload points to the first byte of the RTCM payload (after the 3-byte header) */
unsigned int msg_type = getbitu(payload, 0, 12);   /* DF002: bits 0-11 */
unsigned int sta_id   = getbitu(payload, 12, 12);  /* DF003: bits 12-23 */
unsigned int epoch    = getbitu(payload, 24, 30);   /* DF004: bits 24-53 */

Part 5 — Frequently Asked Questions