Concept · RTK Fundamentals
RTCM is the universal language that RTK correction services and receivers use to communicate. Choosing the wrong version does not stop corrections from flowing — but choosing the right one gives you faster Fix and better accuracy.
On this page
RTCM stands for Radio Technical Commission for Maritime Services — the organisation that defined the standard format for transmitting GNSS correction data between a reference station and a rover. Despite the maritime origin, RTCM is used everywhere: surveying, agriculture, drones, autonomous vehicles and construction.
When your RTK receiver connects to an NTRIP server, the server streams a continuous series of RTCM messages. Each message contains correction data for a specific satellite system (GPS, GLONASS, Galileo, BeiDou) or for specific information types (satellite orbits, clock errors, phase biases). Your receiver reads these messages and applies the corrections to its own satellite observations to compute a centimetre-accurate position.
RTCM is an open standard. This means any receiver that claims RTCM support will work with any RTCM-compatible correction service — regardless of brand.
There are two major versions of the RTCM standard. The difference matters for older equipment.
Which version do you have?
If your receiver was manufactured after 2010 and supports multi-constellation GNSS, it uses RTCM3. You do not need to think about RTCM2 unless you are working with genuinely old hardware.
Within RTCM3, the most important message type for modern RTK is MSM — Multiple Signal Messages. MSM messages carry satellite observations in a compact, extensible format that supports all constellations and multiple frequencies simultaneously.
There are several MSM levels. The three you will encounter in NTRIP sourcetables are MSM4, MSM5 and MSM7.
| Type | Data included | Bandwidth | Best for |
|---|---|---|---|
| MSM4 | Pseudorange + carrier phase (compressed) | Low | Recommended Most receivers — Emlid, u-blox, generic NTRIP clients |
| MSM5 | MSM4 data + Doppler observations | Medium | DJI required DJI drones and some high-rate applications |
| MSM7 | Full precision pseudorange + carrier phase (extended) | High | High-end Trimble, Leica, Septentrio and survey-grade receivers |
| MSM6 | MSM5 data at extended precision | Medium-high | Rare — not commonly offered by NTRIP services |
| 1004 / 1012 | Legacy GPS + GLONASS observations (pre-MSM) | Low | Legacy Old receivers that do not support MSM |
MSM4 contains everything a modern dual-frequency RTK receiver needs to compute a Fix. It includes pseudorange measurements and carrier phase observations for all tracked satellites across all constellations — GPS, GLONASS, Galileo, BeiDou, QZSS. The compressed format keeps bandwidth low, which matters for mobile data connections in the field.
If you are unsure which MSM level to use, start with MSM4. It works correctly with Emlid, u-blox ZED-F9P, Ardusimple and most generic NTRIP clients.
MSM5 adds Doppler observations to the MSM4 data. DJI's RTK implementation specifically requires Doppler data to initialise correctly. Using MSM4 with a DJI drone will result in Float or no Fix even when the connection appears successful. Always use MSM5 or higher for DJI.
MSM7 provides the same observations as MSM4 but at extended precision — the measurements are stored with more decimal places. For Trimble, Leica and Septentrio receivers that work at sub-centimetre level, MSM7 squeezes out the last bit of accuracy. The bandwidth cost is roughly twice that of MSM4, which is acceptable on modern mobile connections but worth knowing in bandwidth-limited environments.
Wrong MSM type causes Float, not an error
If you use MSM4 with a DJI drone, the correction stream flows normally and the connection shows as successful — but the drone stays on Float. There is no error message. The only sign something is wrong is the absence of Fix. If your DJI device never reaches Fix, switching from MSM4 to MSM5 is the first thing to try.
Select your device to see the recommended mountpoint:
When you connect to an NTRIP server without specifying a mountpoint, the server returns a sourcetable — a list of all available correction streams. Understanding how to read it helps you choose the right stream.
A typical sourcetable entry looks like this:
STR;RTCM3_NL;Netherlands;RTCM 3.3;1004,1006,1008,1012,1019,1020,1033,1042,1045,1046,1077,1087,1097,1107,1127;2;GPS+GLO+GAL+BDS+SBAS;RTKsub;NLD;52.37;4.89;1;1;GEODNET;none;B;N;0;
The key fields to read:
You do not need to decode sourcetables manually
Most NTRIP clients have a "Get Mountpoints" button that downloads and displays the sourcetable in a readable format. Use that instead of reading raw entries. The table above is for reference if you ever need to inspect the raw data.