RTCM SC-104

RTCM SC-104 is a communication protocol for sending differential GPS (DGPS) to a GPS receiver from a secondary source like a radio receiver.
The standard is named for the Special Committee 104 of the Radio Technical Commission for Maritime Services (RTCM) that created it.
The format does not define the source of the messages and has been used with systems as varied as longwave marine radio, communications satellite broadcasts, and internet distribution.

The first widely used version of the format was released in 1990 and was based on the 30-bit long packet used by the GPS satellites, known as a "frame". Each message started with standardized two-frame header and then one or more data frames following. The frames were designed to be similar to GPS to make integration in GPS receivers easier, but had the disadvantage of having low channel efficiency and limiting the number of messages that could be sent in a given time.

A completely new message format was introduced in 2003 for version 3 of the standard which used a variable-length format to improve efficiency and increase the number of messages that could be sent, which was important for real-time GPS corrections. The new standard also greatly increased the number of possible message types. As part of the standards process, the naming of the standard was changed, and version 3.1 became RTCM Standard 10403.1. , the latest version is 3.3, or 10403.3, with Amendments 1 and 2.

RTCM SC-104 is not the only standard for DGPS; Trimble introduced the Compact Measurement Record (CMRx) format for the same basic purpose and there are several other similar standards used for special purposes. Most of these have fallen into disuse with the introduction of 10403.1.

Description

Version 1

The original SC-104 work was published as a preliminary standard in 1985, but never widely adopted. It was replaced by Version 2, which is very similar.

Version 2

RTCM Version 2 was released in January 1990 and last updated to 2.3 released in August 2001.

RTCM Version 2 is based on a set of fixed-length 30-bit "words" which are strung together into longer messages known as "frames". All words end with a 6-bit "parity" code using the same algorithm as the GPS signals, based on Hamming codes. This leaves 24 bits available for data. The format was deliberately modelled on that of the actual GPS messages, in order to maintain familiarity. Data within the 24-bit payload is extracted into individual data and then encoded for local transmission as strings of 6-bits of data with a leading 1 start bit and trailing 0 stop bit to form a single 8-bit value suitable for use on ASCII-based serial links and similar. The data is encoded in most significant bit format, as opposed to ASCII's LSB, so some decoding is required to return it to its original format after reception.

All of the frames start with a standard two-word header. The first word starts with a magic number, the 8-bit "preamble" which always contains 01100110. The next six bits encode the message type, 0 to 64. This is followed by a 10-bit station ID. The second header word begins with a 13-bit version of the z-count, the unit of time in GPS, a 3-bit sequence number to ensure frames can be sorted if they arrive out-of-order, a five-bit length that counts the total number of words in the frame, including the header, and a three-bit "station health" code, where 111 indicates the station is not working properly.

A total of 64 message types were allowed, although a number of these were deliberately left unused for future expansion, or formats that were rarely used and later abandoned. The original standard includes six message formats, 1 for correction data, 2 for updating previous corrections, 3 that provided the location of the measuring station, 6 as a null message to fill unused slots, 16 which included an arbitrary 90 ASCII characters for sending test messages, and 59, for proprietary messages used by the equipment vendors.

Type 1 was a complete DPGS correction set that would be broadcast by a ground station for all of the satellites in its view. The data for a single satellite's correction required 40-bits, so to efficiently encode the data into 24 bits of payload, the corrections for three satellites were folded into five words. A single satellite's correction started with the 1-bit "scale factor" (S) and 2-bit "user differential range error" (UDRE), then the satellite's 5-bit identifier. The correction itself was in two parts, the 16-bit "pseudorange correction" (PRC) and 8-bit "range-rate correction" (RRC), and finally an 8-bit "issue of data" number.

This tended to make Type 1 messages fairly long, for instance; a frame for a station with five visible satellites uses eleven 30-bit words, leaving 16 bits empty at the end of the last word. These bits are filled with alternating 1's and 0's to avoid confusion with the preamble. Shorter messages are the purpose of message Type 2, which is used to send periodic updates to existing corrections in a more compact form. Type 3 is used to periodically send out the location of the ground station, allowing receivers to pick suitable sites.

In 1992 the group met to consider input from users working with phase-comparison GPS (RTK) that produces accuracy on the order of . New message types were suggested and standardized as version 2.1 in 1994, including types 18 and 19 for raw pseudo-range measurements, or 20 and 21 as corrections. A new Type 9 provided an alternative to Type 1 and 2 and became one of the most widely used formats. Version 2.2 of 1997 added Types 31 through 37 for GLONASS support, with Type 31 and 32 being the equivalent of Type 1 and 2 for GPS. The final update, 2001's 2.3, added more messages like antenna ID and description in Type 23, its height in Type 24, and several other fields for use with Loran-C and radio beacons.

As a consequence of its fixed-width packets and significant error-correction overhead, version 2 was not particularly efficient. While this was not a problem for most DGPS uses, it made it a poor choice for RTK which has a relatively high message load. For this reason, Trimble introduced its own Compact Measurement Record (CMR) format in 1996, and an updated CMR+ the next year. Additionally, a number of features of the packet format, notably the way the parity system relied on the words arriving in order, made it unsuited to some distribution systems, notably the internet, and the introduction of new systems like Galileo and BeiDou meant the format was running out of possible message formats.

Version 3

RTCM Version 3, initially released in February 2004, is the current and continually evolving version of the RTCM standard. In contrast to 2.3, version 3.x uses a variable-length message format and a single 24-bit cyclic redundancy check (CRC) on the entire message as opposed to a 6-bit parity for every 30-bit word. Like the earlier versions, the message format begins with a preamble extended to 8-bits, followed by a 6-bit reserved area, and then a 10-bit message length that allows up to 1,024 bytes of data. The message, each one with its own privately defined header and data, follows the header and is then capped with the CRC. The savings in data, especially in the case of RTK, is significant, a version 3 RTK correction set is generally half as long as version 2.

Additionally, version 3 groups messages together with related data instead of sending separate messages to accomplish the same task. For instance, in version 2, sending a complete RTK message required message Type 18 for corrections and 19 for pseudo-range measurements, whereas in version 3 this information is combined in the single Type 1003. Multiple message types are defined for the same types of information to further improve efficiency; Type 1001 has GPS data only on the L1 frequency, while 1002 adds various additional information, while 1003 and 1004 do the same with both L1 and L2 data for those stations that can take advantage of the second carrier.

The original 3.0 release defined 13 message types, 1001 through 1013. 1002 contained details for L1 GPS measurements, while 1004 was both L1 and L2. 1010 and 1012 were the equivalents for GLONASS. 1013 contained various system details, including the GPS week number. 1005, 1006 and 1007 contain details about the station, with 1007 adding the antenna height. Positional messages, either 1002 or 1004 and 1010 or 1012, are sent from any particular station about once a second. Station details are on the order of 20 to 30 seconds.

The set was soon expanded to include 1019 containing the GPS ephemeris, which provides orbit updates and can be used to more rapidly lock-on to GPS signals. 1020 is the equivalent GLONASS ephemeris. These tend to be rare, as the same information is also periodically sent by the satellites themselves. Much later additions added ephemerides for Galileo F (1045) and I (1046), QZSS (1044) and BeiDou (1042). Another major addition to the system are the State Space Representation (SSR) which are used to periodically update information on the satellites, and the Multiple Signal Messages (MSM) which allow data from different sets of satellites to be combined using a single data format. MSM also allows basic receivers to add Doppler corrections, which is mostly used to remove ambiguity when using L1 signals by moving receivers.

See also

*NMEA 0183

References

Citations

Bibliography

*
*
*
*
*
*
*
* {{cite conference
, first1= Alexey , last1= Boriskin
, first2= Dmitry , last2= Kozlov
, first3= Gleb , last3= Zyryanov
, title= The RTCM Multiple Signal Messages: A New Step in GNSS Data Standardization
, conference= Proceedings of the 25th International Technical Meeting of the Satellite Division of The Institute of Navigation
, date= 17–21 September 2012
, pages= 2947–2955
, url=https://www.ion.org/publications/abstract.cfm?articleID=10473

Satellite navigation