A complete list of all adopted RTCM 2 Messages with brief commentary.
The official release of the standard at this time is called:
RTCM 10402.3 RTCM Recommended Standards for Differential GNSS (Global Navigation Satellite Systems) Service, Version 2.3 with Amendment 1 (May 21, 2010)
Buy a complete copy here.
Comments
In the below table the term “Retired” should be read to mean: “should not be used for new work” but there are a great many older devices that still do use such messages (for example the early RTK message types 18/19). The term “Tentative” should be understood as the message which is in development/testing at this time. Several RTCM 2.x messages have been in this state for many years due to a lack of deployment interest in the message. In theory such message definitions could be revised and issued by RTCM as “Permanent” (the term which used by RTCM to indicate that the content are stable). The table below takes small liberties with those messages that are both Tentative and have little known deployment to mark them also as Retired. As always, consult the published standards for precise current information.
Often RTCM2.x messages are referred to with the word “Type” in front of them, as in a Type-9 message. By design all permanent RTCM 2.x message and RTCM 3.x message do not have overlapping numerical value assignments. However, the RTCM 3.x message standard does provide a range of experimental values (1~100) where such confusion could occur.
If you are interested in the messages you are more likely to encounter in the real world, there is a list of them in our popular RTCM 3 cheat sheet summary.
The text below is taken from the pop-up tool tips that SNIP will display when decoding various messages from an NTRIP stream. Unlike most NTRIP Casters, SNIP has the ability to decode and process the RTCM messages to provide additional functionality.
The Message List
All RTCM 2.x messages are encoded using an arcane system of 30 bit words with a 6-bit parity field that spans from one message to the next. When expressed in a format of octets (as you are likely to see in any NTRIP data feed) the 30 raw bits are expressed over 5 octets (bytes) with a mark/space added to the upper two bits. If you are decoding these messages by hand, it is vital to understand the effect of bit shifts that the different presentation formats may present.
This rather bizarre encoding comes from a early desire of the RTCM SC-104 members to follow the original sub-frame encoding which is still used in the GPS 50bps data steam. Like the RTCM3.x encoding, SNIP manages these details when displaying such messages, hiding the encoding details from the user.
| Msg# | Message Name & Usage Commentary |
| #1 | Differential GPS Corrections The primary code bias correction message for GPS. Each message contains multiple GPS code corrections take at the same point in time (RTCM 2.x uses modified Z-counts for time). See also message Type-9, although the use of that message is not preferred. This message is the most common way to send DGPS style code corrections for GPS. |
| #2 | Delta Differential GPS Corrections (Retired) A set of delta updates values from a prior set of GPS code corrections (Type-1 message) used during the hand over periods when the IOD changes. This message is no longer used. |
| #3 | GNSS Reference Station Parameters The location of the GPS reference base station, expressed in ECEF terms with 1cm precision. Typically this is expressed in an ITRF frame, but users need to confirm that as well as which one. See also message Type-22 and Type-24. This message (along with Type-1 (DGPS) or with Types-18/19 (RTK) is very commonly found. While Type-24 offer some additional advantages, this remains the dominate way that the ECEF values are sent. |
| #4 | Reference Station Datum The datum used with the location of the reference base station in a short text string, rarely sent. Consult the data sender for local conventions. For example, in the US some network still use NAD-83 (rather than IRTF datums). |
| #5 | GPS Constellation Health A message which can convey the “health” status of selected GPS SVs as well as the locally tracked C/No for that SV. And it provides simple means to indicate that an SV is going off line or becoming unhealthy. This message not often found in use. |
| #6 | GPS Null Frame A filler message intended for GPS GNSS systems (but useable for any need). Sent when using a synchronous channel where the time alignment of the messages is of importance. Not sent in more modern packet style systems such as TCP/IP connections. |
| #7 | DGPS Radiobeacon Almanac (Retired) A message to support coordination between nearby radio beacons (often in common networks) by sending the location and other detail about nearby stations. The rover devices can use this information to select the optimum station to use. See also Type-27 intended to replace it (RTCM recommends that message senders migrate to Type-27 which provides some additional data). Not seen with TCP/IP style data feeds (NTRIP, or the Internet) but often found with radio based NDGPS systems. |
| #8 | Pseudolite Almanac (Retired) A tentative message with location data for use with pseudolites (a GPS transmitter typically placed at the end of an airport runway). On the whole this concept never took off and this message is no longer used. |
| #9 | GPS Partial Correction Set Where “Partial” implies several messages are required to send the same data found in one Type-1 message. The term “lower latency” in this context refers to the fact that each message contains a sub-set of the corrections and those data items placed in the first message can be used before the remainder are send in subsequent messages. Taken as a whole the delivery of a full set of updates by means of the Type-9 message requires more time and bandwidth than Type-1. A great deal of effort has gone into the scheduling schemes to exploit this when transmission bandwidth was very tight (~50bps). The use of Type 9 also implies a suitably stable time base, which is less of an issue in modern GNSS devices. Unless sending on a very restricted bandwidth channel, Type-1 is to be preferred over Type-9. |
| #10 | P-Code Differential Corrections (Retired) This message was originally intended to support p-code user needs for L1/L2 corrections, but (in light of the common codeless L2 designs) was never developed. [The p-code was developed for U.S. military use and most GNSS devices cannot decode it] |
| #11 | C/A-Code L1, L2 Delta Corrections (Retired) A tentative message to provide code corrections for the L2 signal of GPS. It was never developed and this mission was performed by Types 19 and 21, and then by RTCM 3.x messages such as 1004. See also the new Type-41 message. |
| #12 | Pseudolite Station Parameters (Retired) A tentative message to provide station parameter information for pseudolites (a GPS transmitter typically placed at the end of an airport runway) which had not been developed. |
| #13 | Ground Transmitter Parameters (Retired) An alternative message to Type-3 which is also used to send the location of the data link transmitter (not the Base Station location). It was never widely deployed and is rarely seen. |
| #14 | GPS Time of Week A message which provides a wider span of time than the modified Z-count which is used as the time stamp in RTCM2.x messages. Briefly, the Z-count system dates from early GPS and uses a 0.6 second step value modulo to within the current hour. This message allows resolving the current Z-count to the current GPS week and time of week (TOW) values. |
| #15 | Ionospheric Delay Message A message which provides per-SV ionospheric delay and delay change rates for either GPS or GLONASS GNSS systems. This data is applied to the rover measurement for each SV (along with Type-3 data) to obtain an iono-free corrections for further use. The type of GNSS system is indicated with a bit, so all SVs in any single message relate to one type. See also the newly developed Type-41 and Type-42 messages which provide this data as well. |
| #16 | GPS Special Message A message which provides the ability to send short textual messages (up to 90 ASCIIchars). While defined as a “GPS” GNSS type, there in nothing in the message that is uniquely GPS-centric. A similar message (Type-36) exists for GLONASS. |
| #17 | GPS Ephemerides A message which provides the ability to send GPS orbital data for a single SV. When used, care must be taken by the rover devices regarding the IODC and IODE during periods when an ephemeris update occurs. Observe that there is not a similar message type for GLONASS. |
| #18 | RTK Uncorrected Carrier Phases (Retired) An early message used to send uncorrected GPS carrier phase observations from a local Base Station for use in RTK navigation filters. Now overcome by RTCM 1004 messages. Also called the “GPS Kinematic” message in some places. There exist today many older rover deployments that still use this message and many NTRIP Casters provide such streams for legacy users. Its use is not recommended for new work. |
| #19 | RTK Uncorrected Pseudoranges (Retired) An early message used to send uncorrected GPS pseudorange observations from a local Base Station for use in RTK navigation filters. Now overcome by RTCM 1004 messages. Also called the “GPS Kinematic” message in some places. There exist today many older rover deployments that still use this message and many NTRIP Casters provide such streams for legacy users. Its use is not recommended for new work. |
| #20 | RTK Carrier Phase Corrections (Retired) An early message used to send corrected GPS carrier phase observations from a local Base Station for use in RTK navigation filters. Now overcome by RTCM 1004 messages. Also called the “GPS Kinematic” message in some places. There exist today many older rover deployments that still use this message and many NTRIP Casters provide such streams for legacy users. Its use is not recommended for new work. |
| #21 | RTK/Hi-Accuracy Pseudorange Corrections (Retired) An early message used to send corrected GPS pseudorange observations from a local Base Station for use in RTK navigation filters. Now overcome by RTCM 1004 messages. Also called the “GPS Kinematic” message in some places. There exist today many older rover deployments that still use this message and many NTRIP Casters provide such streams for legacy users. Its use is not recommended for new work. |
| #22 | Extended Reference Station Parameters (Retired) This message provides additional precision (+-127/255th cm) regarding the location of the reference base station antenna format that is found in message Type-3, as well the height above the ARP for L1 and a delta L2 phase center value. Never widely used, see message Type-24 for a preferred single message. |
| #23 | Antenna Type Definition Record This message provides textual strings and serial numbers for the antenna used in a base station. This data can be used to look up additional bias correction information. |
| #24 | Antenna Reference Point (ARP) The location of the reference base station antenna ARP, expressed in ECEF terms with 0.01 cm precision as well as a height above the point representing the L1 phase center. Typically this is expressed in an ITRF frame, but users need to confirm that as well as which one. This message is preferred over the use of message Type-3 and Type-22. |
| #25-#26 | Undefined at this time, reserved for RTCM use |
| #27 | Extended Radiobeacon Almanac A message to support coordination between nearby radio beacons (often in common networks) by sending the location and other detail about nearby stations. The rover devices can use this information to select the optimum station to use. See also Type-7, which was developed for the same need first. Not seen with TCP/IP style data feeds (NTRIP, or the Internet) but often found with radio based NDGPS systems. |
| #28-#30 | Undefined at this time, reserved for RTCM use |
| #31 | Differential GLONASS Corrections (Tentative) The primary code bias correction message for GLONASS (similar toe Type-1 for GPS). Each message contains multiple GLONASS code corrections taken at the same point in time (RTCM 2.x uses modified Z-counts for time). See also message Type-34, although the use of that message is not preferred. This message is the most common way to send DGPS style code corrections for GLONASS. However it has known issues during ephemeris changes. The newly devised Type-41 message is to be preferred in this regard. |
| #32 | GLONASS Reference Station Parameters (Tentative) The location of the GLONASS reference base station, expressed in ECEF terms with 1cm precision. Typically this is expressed in the Russian PZ-90.11 reference frame, but users need to confirm that. While Type-24 offers some additional advantages, this message and Type-3 remain the dominant ways that the ECEF values are sent. Essentially it is a dupe of the Type-3 message which need not be sent if both GPS and GLONASS are supported. |
| #33 | GLONASS Constellation Health (Tentative) A message which can convey the “health” status of selected GLONASS SVs as well as the locally tracked C/No for that SV. And it provides simple means to indicate that an SV is going off line or becoming unhealthy. This message is not often found in use. |
| #34 | GLONASS Partial Differential Correction Set (n>0) Where “Partial” implies several messages are required to send the same data found in one Type-31 message. The term “lower latency” in this context refers to the fact that each message contains a subset of the corrections and those data items placed in the first message can be used before the remainder are send in subsequent messages. Taken as a whole the delivery of a full set of updates by means of the Type-34 message requires more time and bandwidth than Type-31. A great deal of effort has gone into the scheduling schemes to exploit this when transmission bandwidth was very tight (~50bps). The use of Type 34 also implies a suitably stable time base, which is less of an issue in modern GNSS devices. Unless sending on a very restricted bandwidth channel, Type-31 is to be preferred over Type-34. |
| #34 | GLONASS Null Frame (Tentative, Retired n=0) A filler message intended for GLONASS GNSS systems (but useable for any need). Sent when using a synchronous channels where the time alignment of the messages is of importance. Not sent in more modern packet style systems such as TCP/IP connections. |
| #35 | GLONASS Radiobeacon Almanac (Tentative) A message to support coordination between nearby radio beacons (often in common networks) by sending the location and other details about nearby stations. The rover devices can use this information to select the optimum station to use. Not seen with TCP/IP style data feeds (NTRIP, or the Internet) but often found with radio based NDGPS systems. |
| #36 | GLONASS Special Message A message which provides the ability to send short textual messages. While defined as a “GLONASS” GNSS type, there is nothing in the message that is uniquely GLONASS centric. A similar message (Type-16) exists for GPS. |
| #37 | GNSS System Time Offset A message which provides the time offset between GPS and GLONASS differential corrections measurements. |
| #38-#40 | Undefined at this time, reserved for RTCM use |
| #41 | Generic GNSS Basic Differential Corrections (Tentative) The message type allows sending code corrections for multiple GNSS systems (one GNSS system type per message). It is expected to supplant the current Type-1 and Type-31 message in time. A common set of values is used to first select a single GNSS type, and also a set of frequencies, and then provide corrections for multiple SVs in one message. Corrections for different GNSS types are handled in their own message and broadcast sequentially. Field deployment of this message is very small (i.e. none), as it is still undergoing testing. |
| #42 | Generic GNSS Partial Basic Corrections (Tentative) TBD, see Type-41. |
| #43 | Generic GNSS Nav Data Validity & Signal Health (Tentative) TBD, see Type-41. |
| #44-#63 | Undefined at this time, reserved for RTCM use |
To sum up: for DGPS uses Type-1 is sent for GPS while Type-31 is sent for GLONASS.
[Unless you want to use the new Type-41 message which is still being adopted and tested at this time. For RTK uses, use the various RTCM 3 messages.]
See Also
These related message sets may also be of interest to you.
A cheat sheet of the most popular RTCM 3 Messages.
A complete list of all adopted RTCM 3 Messages with commentary.
A complete list of all adopted SAE DSRC J2735 Messages with commentary.
Common NMEA-183 messages of interest to GNSS NTRIP users Site-1 and Site-2.
The only way to truly understand the details of the RTCM 2.x message set is to purchase a copy for yourself from RTCM, please do so if you have interest. Here is the web page with the standards you would need to do RTK or DGPS work.
SNIP is a robust NTRIP Caster, but it also has built in utilities useful for message decoding
Need to see the internal contents of these messages? Use SNIP‘s RTCM3 Decoder feature.
Need to use these messages in a navigation solution? Use SNIP‘s Graphical Display feature
Need to quickly plot the ECEF location of a base station? Use SNIP‘s Mapping feature.
Download your own copy of SNIP today
Note:
Please do not copy the text of this article, or any other on this site, and place it on your own web page or product support guidelines passing it off as your firm’s own work. Like all materials found here, its copyright is held by SubCarrier Systems Corporation (SCSC). If you are a commercial concern, we may allow you to use with with suitable attribution (please contact us). It better to simply link to it. If your professor told you to come here and the use is for your paper; that is considered educational fair use. Don’t worry, just cite the page source. In all cases, the best solution includes buying a copy of the source stds from RTCM to help defray the costs of further development.