RTCM 3.x Explained: The Language of RTK Corrections

What is inside an RTCM stream, which message types matter, and why compatibility is rarely a problem.

What RTCM 3.x actually carries

RTCM 3.x is the open standard that moves RTK from theory to interoperability: a compact binary format, defined by the Radio Technical Commission for Maritime Services, that packages everything a rover needs to compute a differential solution. Inside a healthy stream you will find observation messages — today usually MSM (Multiple Signal Messages), which carry raw multi-constellation, multi-frequency measurements — plus the base's own position and antenna description. The rover differences its observations against the base's, resolves carrier-phase ambiguities, and reports FIX. Every serious RTK device of the last decade speaks it: DJI aircraft, Emlid, CHCNAV, South, Trimble, and Leica receivers, auto-steer terminals, machine control ECUs.

The format's genius is what it excludes: no vendor extensions required for core operation, no negotiation, no session state. A base broadcasts; anything within reach that understands RTCM 3.x participates.

The message types worth knowing by number

A handful of numbers explain most configuration screens. 1005 / 1006 — stationary base position (1006 adds antenna height): without one of these, rovers have nothing to difference against. 1074 / 1084 / 1094 / 1124 — MSM4 observations for GPS, GLONASS, Galileo, and BeiDou respectively; the 7-series (1077, 1087, 1097, 1127) are MSM7, the full-resolution variants. 1033 — receiver and antenna descriptors, which help rovers apply correct phase-centre models. 1230 — GLONASS biases. A base emitting MSM4 or MSM7 for the major constellations plus 1005/1006 at 1 Hz is compatible with essentially everything sold since the mid-2010s. Legacy 1004/1012 messages (GPS/GLONASS only) still appear from older networks and remain widely understood, but new deployments should be MSM-first.

Compatibility in the real world

Cross-brand pairing questions dissolve once RTCM is understood. Can a UAV Mate base feed a DJI Matrice 4? Yes — Pilot 2's Custom Network RTK is an RTCM 3.x client. An Emlid Reach RS3 rover? Yes. A CHCNAV i93, South Galaxy rover, Trimble R780, Leica GS18? Yes, yes, yes, yes — they are all consumers of the same stream, simultaneously if you like, because broadcast has no pairing. The rare genuine incompatibilities are configuration, not protocol: a base emitting GPS-only messages to a rover configured to require Galileo; MSM7 toward a very old firmware that only parses 1004; or radios matching on frequency but not on over-the-air protocol (TrimTalk vs Satel vs transparent). Each is fixed in a settings menu, not a purchasing decision.

This is also why “works with any RTCM 3.x rover” is the single most load-bearing line on a base station's spec sheet — it is the difference between buying a correction source and buying into an ecosystem.

RTCM, NTRIP, and radios: layers, not rivals

Confusion often merges the payload with its transport. RTCM 3.x is the payload — the correction bytes. NTRIP is one transport (RTCM over internet streaming); UHF radio is another (RTCM over the air, wrapped in a link protocol like TrimTalk 450S or transparent serial); a drone RC link is a third. The same base can emit the identical RTCM simultaneously over all three, and rovers on different transports compute identical solutions. When debugging, separate the layers: correction age and stream health diagnose transport; solution status with healthy corrections diagnoses payload configuration or sky conditions (triage order here).

Configuring a base stream: sensible defaults

For a mixed fleet in 2026: MSM4 for GPS, GLONASS, Galileo, BeiDou at 1 Hz; 1005 (or 1006) every few seconds; 1033 and 1230 for completeness. Step up to MSM7 if your rovers are modern and the link has headroom — the extra resolution costs bandwidth that only matters on constrained radio links. Avoid the temptation to blast every message type at maximum rate: radios have finite airtime, and a lean stream is a reliable stream. A well-configured base is boring — which is precisely the compliment its RTCM output deserves (how these streams anchor whole sites: one datum for machines and drones).

Reading a stream like a pro

Free tools make RTCM inspectable. RTKLIB's rtkconv and str2str, SNIP's decoder view, or the message monitor built into many receivers will list message types and rates live: you should see your MSM set ticking at 1 Hz and 1005/1006 every few seconds. Silence on a constellation your rover expects, or a missing base-position message, leaps out immediately. This five-minute inspection habit converts “the rover won't fix” from vendor-support ping-pong into a settings change — and it is brand-agnostic, because the stream is.

Two numbers to memorize while inspecting: correction age at the rover (healthy: 1–2 s) and stream bandwidth (a lean MSM4 multi-constellation stream runs a few kB/s). Anything wildly off either number is your fault line.

A brief history, for context

RTCM 2.x carried the DGPS era — code corrections, metre-class. RTCM 3.0 (2004) rebuilt the format for carrier-phase RTK; 3.2 introduced MSM, generalizing observations across constellations and signals, which is why Galileo and BeiDou slot in without new message families; 3.3 refined it. The standard's slow, conservative evolution is a feature: a base bought today emits messages a 2015 rover parses, and a 2030 rover almost certainly will. Few protocols in any industry age that gracefully.

What RTCM does not do — and what fills the gaps

Knowing the format's edges prevents mis-blame. RTCM carries corrections, not coordinates policy: the datum of the solution follows the base position message, so frame mistakes are configuration, not protocol (frames explained). It carries no authentication or encryption — security lives in the transport layer (NTRIP credentials, radio obscurity), which is why casters use passwords at all. It does not command rovers: correction consumers decide their own masks, constellations, and solution logic. And it is one-directional — nothing about the rover travels back to the base, which is why one broadcast serves a thousand rovers as cheaply as one. Vendors layer proprietary extras (network RTK residual messages, brand telemetry) on adjacent channels, but the interoperable core — observations plus base position — is deliberately, durably plain.

One-line takeaway

RTCM 3.x with MSM observations plus a 1005/1006 base position at 1 Hz is the entire interoperability contract of modern RTK — insist on it leaving your base, and every rover brand you will ever meet becomes a five-field configuration exercise.

Further reading

How these streams travel — internet, UHF radio, or the drone's own control link — is the subject of the transport comparison; what the numbers mean when a rover consuming a healthy stream still refuses to FIX is covered in the troubleshooting checklist.

Frequently asked questions

Is RTCM 3.x backward compatible with RTCM 2?

No — different formats. RTCM 2.x is legacy DGPS-era; modern RTK is 3.x. Some bases can emit 2.x for antique rovers, but new workflows should be 3.x/MSM throughout.

Do I need MSM7 or is MSM4 enough?

MSM4 suffices for centimetre RTK with contemporary rovers. MSM7 adds resolution and extra fields useful for some processing, at higher bandwidth — choose it when the link is generous.

Why does my rover want message 1006 instead of 1005?

1006 includes antenna height above the marker; some rovers prefer it for automatic height handling. Bases typically let you choose either.

Can multiple brands share one RTCM stream at once?

Yes — broadcast has no session per rover. A single base can feed DJI drones, Emlid and Trimble rovers, and auto-steer terminals simultaneously.