rtcm-104 5 12 Jul 2005 rtcm-104 RTCM-104 dump format emitted by GPSD tools RTCM-104 is a family of serial protocols used for broadcasting pseudorange corrections from differential-GPS reference stations. This manual page describes some aspects of the RTCM protocol, mainly in order to explain the RTCM-104 dump format emitted by rtcmdecode1. It describes that dump format completely. RTCM-104 comes in two major and incompatible flavors, 2.x and 3.x. Each major flavor has minor (compatible) revisions. The applicable standard for RTCM Version 2.x is RTCM Recommended Standards for Differential NAVSTAR GPS Service RTCM Paper 194-93/SC 104-STD. For RTCM 3.1 it is RTCM Paper 177-2006-SC104-STD. Ordering instructions for both standards are accessible from the website of the Radio Technical Commission for Maritime Services under "Publications". Differential-GPS correction stations consist of a GPS reference receiver coupled to a low frequency (LF) transmitter. The GPS reference receiver is a survey-grade GPS that does GPS carrier tracking and can work out its own position to a few millimeters. It generates range and range-rate corrections and encodes them into RTCM104. It ships the RTCM104 to the LF transmitter over serial rs-232 signal at 100 baud or 200 baud depending on the requirements of the transmitter. The LF transmitter broadcasts the the approximately 300khz radio signal that differential-GPS radio receivers pick up. Transmitters that are meant to have a higher range will need to transmit at the slower rate. The higher the data rate the harder it will be for the remote radio receiver to receive with a good signal-to-noise ration. (Higher data rate signals can't be averaged over as long a time frame, hence they appear noisier.) An RTCM 2.x message consists of a sequence of up to 33 30-bit words. The 24 most significant bits of each word are data and the six least significant bits are parity. The parity algorithm used is the same ISGPS-2000 as that used on GPS satellite downlinks. Each RTCM 2.x message consists of two header words followed by zero or more data words, depending upon message type. An RTCM 3.x message begins with a fixed leader byte 0xD3. That is followed by six bits of version information and 10 bits of payload length information. Following that is the payload; following the payload is a 3-byte checksum of the payload using the Qualcomm CRC-24Q algorithm. For each message, the header is listed first, followed by zero or more lines containing the specific data for that message, followed by a trailing sentinel line containing a single dot. The general format is a line beginning with a capital letter, followed by a tab, followed by the fields of the message separated by tabs, terminated by a newline. H <message type> <reference station id> <modified z_count> <sequence no> <message length> <station health> [T <useful length>] Here is an example: H 9 268 249.6 1 5 0 S 13 0 3 249.6 -26.120 0.068 S 2 0 73 249.6 1.220 -0.080 S 8 0 22 249.6 23.760 0.030 . <message type> is one of 1 full corrections - one message containing corrections for all satellites in view. This is not common. 3 reference station parameters - the position of the reference station GPS antenna. 4 datum — the datum to which the DGPS data is referred. 5 constellation health — information about the satellites the beacon can see 6 null message — just a filler. 7 radio beacon almanac — information about this or other beacons. 9 subset corrections — a message containing corrections for only a subset of the satellites in view. 16 special message — a text message from the beacon operator. <reference station id> is the id of the GPS reference receiver. The LF transmitters also have (different) id numbers. <modified z_count> is the reference time of the corrections in the message in seconds within the current hour. Note that it is in GPS time, which is some seconds ahead of UTC (see the U.S. Naval Observatory's table of leap second corrections). <sequence no> is a number which increments, modulo 8, for each message transmitted. <message length> is the number of words after the header that comprise the message. <station health> indicates the health of the beacon as a reference source. Any nonzero value means the satellite is probably transmitting bad data and should not be used in a fix. 6 means the transmission is unmonitored. 7 means the station is not working properly. Other values are defined by the beacon operator. If the message contains a parity error after the header but before the end of the message, then the extra fields [T <useful length>] are appended to indicate a truncated message. Here is an example: H 9 687 331.8 1 5 0 T 4 <useful length> indicates the number of useful words before the parity error. Depending on the message type, useful information may still be extracted. One or more of these follow the header for type 1 or type 9 messages. Here is the format: S <satellite> <udre> <iod> <modified z_count> <range error> <range error rate> Here is an example: S 7 0 199 331.8 -12.160 0.288 <satellite> is the PRN number of the satellite for which this is correction data. <udre> is User Differential Range Error with the following values: 0 1-sigma error <= 1m 1 1-sigma error <= 4m 2 1-sigma error <= 8m 3 1-sigma error > 8m <iod> is Issue Of Data, matching the IOD for the current ephemeris of this satellite, as transmitted by the satellite. The IOD is a unique tag that identifies the ephemeris; the GPS using the DGPS correction and the DGPS generating the data must use the same orbital positions for the satellite. <modified z_count> is just a copy of the same field from the header. <range error> is the pseudorange error in meters for this satellite as measured by the beacon reference receiver at the epoch indicated by <modified z_count> <range error rate> is the rate of change of pseudorange error in meters/sec for this satellite as measured by the beacon reference receiver at the epoch indicated by <modified z_count>. This is used to calculate pseudorange errors at other epochs, if required by the GPS receiver. Here is the format: R <X-coordinate> <Y-coordinate> <Z-coordinate> Here is an example: R 3746729.40 -5086.23 5144450.67 The coordinates are the position of the station, in meters to two decimal places, in Earth Centred Earth Fixed coordinates. These are usually referred to the WGS84 reference frame, but may be referred to NAD83 in the US (essentially identical to WGS84 for all except geodesists), or to some other reference frame in other parts of the world. Here is the format: D <dgnss type> <dat> <datum name> [ <dx> <dy> <dz> ] Here is an (artificial) example: D GPS 0 ABC12 25.8 30.5 33.0 <dgnss type> is either GPS or GLONASS. <dat> is 0 or 1 and indicates the sense of the offset shift given by dx, dy, dz. dat = 0 means that the station coordinates (in the reference message) are referred to a local datum and that adding dx, dy, dz to that position will render it in GNSS coordinates (WGS84 for GPS). If dat = 1 then the ref station position is in GNSS coordinates and adding dx, dy, dz will give it referred to the local datum. <datum name> is a standard name for the datum. <dx> <dy> <dz> are offsets to convert from local datum to GNSS datum or vice versa. These fields are optional. One or more of these follow the header for type 5 messages — one for each satellite. Here is the format: C <sat> <iodl> <health> <snr> <hlth en> <new data> <los warning> <time to unhealthy> Here is an example: C 29 0 0 53 0 0 0 0 <sat> is the PRN number of the satellite. <iodl> is 1 bit. 0 indicates that this information relates to the satellite information in an accompanying type 1 or type 9 message. <health> 0 indicates that the satellite is healthy. Any other value indicates a problem (coding is not known). <snr> gives the carrier/noise ratio of the received signal in the range 25 to 55 dB(Hz). <health en> is 1 bit. If set to 1 it indicates that the satellite is healthy even if the satellite navigation data says it is unhealthy. <new data> is 1 bit. a 1 indicates that the IOD for this satellite will soon be updated in type 1 or 9 messages. <los warning> is 1 bit. a 1 indicates that the satellite will shortly go unhealthy. The healthy time remaining is given in the <time to unhealthy> field. Here is the format: A <latitude> <longitude> <range> <frequency> <health> <station id> <bitrate> Here is an example: A 54.1176 -0.0714 100 302.5 0 447 2 <latitude> and <longitude> give the position, in degrees, of the LF transmitter antenna for the station for which this is an almanac. North and East are positive. <range> is the published range of the station in km. <frequency> is the broadcast frequency in kHz. <health> is the health of the station for which this is an almanac. If it is non-zero, the station is issuing suspect data and should not be used for fixes. The ITU and RTCM104 standards differ about the mode detailed interpretation of the <health> field and even about its bit width. <station id> is the id of the transmitter. This is not the same as the reference id in the header, the latter being the id of the reference receiver. <bitrate> indicates the transmitted bitrate. Here is the format: T <text> Here is an example: T THLS TRIAL SERVICE <text> is just a text message sent by the beacon operator. This just indicates a null message. There are no fields. This is used to dump message words in hexadecimal when the message type field doesn't match any of the known ones. Here is the format: U <hex-literal> Here is an example: U 0x76423055 The <hex-literal> will represent 32 bits of information, after parity checks and inversion. The high two bits should be ignored. This just indicates a null message. There are no fields. RTCM104v3 messages are too complex to be dumped in a fully invertible form without a structural markup at least as complex as XML or YAML. Accordingly, the dump format has been designed to be its own documentation at the expense of reparsability, and is not described here. gpsd8, gps1, libgps3, libgpsd3, gpsprof1, gpsfake1. In versions of the RTCM2 dump format prior to gpsd 2.28, there was no trailing sentinel line after each stanza of the dump. Much of the portion of this text describing RTCM2 was originally written by John Sager john.sager@btinternet.com in association with his RTCM decoder. Other material comes from the GPSD project. There is a project page for gpsd here.