1RTCM-104(5) RTCM-104(5)
2
6 rtcm-104 - RTCM-104 dump format emitted by GPSD tools
7
9 RTCM-104 is a serial protocol used for broadcasting pseudorange correc‐
10 tions from differential-GPS reference stations. This manual page
11 describes some aspects of the RTCM protocol, mainly in order to explain
12 the RTCM-104 dump format emitted by rtcmdecode(1). It describes that
13 dump format completely.
14 The applicable standard is RTCM Recommended Standards for Differential
17 NAVSTAR GPS Service RTCM Paper 194-93/SC 104-STD. Ordering instructions
18 are accessible from the website of the Radio Technical Commission for
19 Maritime Services: http://www.rtcm.org/ under "Publications".
20
23 Differential-GPS correction stations consist of a GPS reference
24 receiver coupled to a low frequency (LF) transmitter. The GPS reference
25 receiver is a survey-grade GPS that does GPS carrier tracking and can
26 work out its own position to a few millimeters. It generates range and
27 range-rate corrections and encodes them into RTCM104. It ships the
28 RTCM104 to the LF transmitter over serial rs-232 signal at 100 baud or
29 200 baud depending on the requirements of the transmitter.
30 The LF transmitter broadcasts the the approximately 300khz radio signal
33 that differential-GPS radio receivers pick up. Transmitters that are
34 meant to have a higher range will need to transmit at the slower rate.
35 The higher the data rate the harder it will be for the remote radio
36 receiver to receive with a good signal-to-noise ration. (Higher data
37 rate signals can't be averaged over as long a time frame, hence they
38 appear noisier.)
39 An RTCM message consists of a sequence of up to 33 30-bit words. The 24
42 most significant bits of each word are data and the six least signifi‐
43 cant bits are parity. The parity algorithm used is the same as that
44 used on GPS satellite downlinks.
45 Each message consists of two header words followed by zero or more data
48 words, depending upon message type.
49
52 For each message, the header is listed first, followed by zero or more
53 lines containing the specific data for that message. The general format
54 is a line beginning with a capital letter, followed by a tab, followed
55 by the fields of the message separated by tabs, terminated by a new‐
56 line.
57 Header message (H)
60 H <message type> <reference station id> <modified z_count> <sequence no>
61 <message length> <station health> [T <useful length>]
62 Here is an example:
66 H 9 687 337.2 4 5 0
69 <message type> is one of
73 1 full corrections - one message containing corrections for all
76 satellites in view. This is not common.
77 3 reference station parameters - the position of the reference
80 station GPS antenna.
81 4 datum -- the datum to which the DGPS data is referred.
84 5 constellation health -- information about the satellites the
87 beacon can see
88 6 null message -- just a filler.
91 7 radio beacon almanac -- information about this or other beacons.
94 9 subset corrections -- a message containing corrections for only
97 a subset of the satellites in view.
98 16 special message -- a text message from the beacon operator.
101 <reference station id> is the id of the GPS reference receiver. The LF
104 transmitters also have (different) id numbers.
105 <modified z_count> is the reference time of the corrections in the mes‐
108 sage in seconds within the current hour. Note that it is the current
109 hour in GPS time, which is several seconds ahead of UTC (14 as of Janu‐
110 ary 2006).
111 <sequence no> is a number which increments, modulo 8, for each message
114 transmitted.
115 <message length> is the number of words after the header that comprise
118 the message.
119 <station health> indicates the health of the beacon as a reference
122 source. Any nonzero value means the satellite is probably transmitting
123 bad data and should not be used in a fix. 6 means the transmission is
124 unmonitored. 7 means the station is not working properly. Other values
125 are defined by the beacon operator.
126 If the message contains a parity error after the header but before the
129 end of the message, then the extra fields [T <useful length>] are
130 appended to indicate a truncated message.
131 Here is an example:
134 H 9 687 331.8 1 5 0 T 4
137 <useful length> indicates the number of useful words before the parity
141 error. Depending on the message type, useful information may still be
142 extracted.
143 Correction data (S)
146 One or more of these follow the header for type 1 or type 9 messages.
147 Here is the format:
148 S <satellite> <udre> <iod> <modified z_count> <range error>
151 <range error rate>
152 Here is an example:
156 S 7 0 199 331.8 -12.160 0.288
159 <satellite> is the PRN number of the satellite for which this is cor‐
163 rection data.
164 <udre> is User Differential Range Error with the following values:
167 0 1-sigma error <= 1m
170 1 1-sigma error <= 4m
171 2 1-sigma error <= 8m
172 3 1-sigma error > 8m
173 <iod> is Issue Of Data, matching the IOD for the current ephemeris of
177 this satellite, as transmitted by the satellite. The IOD is a unique
178 tag that identifies the ephemeris; the GPS using the DGPS correction
179 and the DGPS generating the data must use the same orbital positions
180 for the satellite.
181 <modified z_count> is just a copy of the same field from the header.
184 <range error> is the pseudorange error in meters for this satellite as
187 measured by the beacon reference receiver at the epoch indicated by
188 <modified z_count>
189 <range error rate> is the rate of change of pseudorange error in
192 meters/sec for this satellite as measured by the beacon reference
193 receiver at the epoch indicated by <modified z_count>. This is used to
194 calculate pseudorange errors at other epochs, if required by the GPS
195 receiver.
196 Reference Station Parameters (R)
199 Here is the format:
200 R <X-coordinate> <Y-coordinate> <Z-coordinate>
203 Here is an example:
207 R 3746729.40 -5086.23 5144450.67
210 The coordinates are the position of the station, in meters to two deci‐
214 mal places, in Earth Centred Earth Fixed coordinates. These are usually
215 referred to the WGS84 reference frame, but may be referred to NAD83 in
216 the US (essentially identical to WGS84 for all except geodesists), or
217 to some other reference frame in other parts of the world.
218 Datum (D)
221 Here is the format:
222 D <dgnss type> <dat> <datum name> [ <dx> <dy> <dz> ]
225 Here is an (ertificial) example:
229 D GPS 0 ABC12 25.8 30.5 33.0
232 <dgnss type> is either GPS or GLONASS.
236 <dat> is 0 or 1 and indicates the sense of the offset shift given by
239 dx, dy, dz. dat = 0 means that the station coordinates (in the refer‐
240 ence message) are referred to a local datum and that adding dx, dy, dz
241 to that position will render it in GNSS coordinates (WGS84 for GPS). If
242 dat = 1 then the ref station position is in GNSS coordinates and adding
243 dx, dy, dz will give it referred to the local datum.
244 <datum name> is a standard name for the datum.
247 <dx> <dy> <dz> are offsets to convert from local datum to GNSS datum or
250 vice versa. These fields are optional.
251 Constellation Health (C)
254 One or more of these follow the header for type 5 messages -- one for
255 each satellite.
256 Here is the format:
259 C <sat> <iodl> <health> <snr> <hlth en> <new data> <los warning>
262 <time to unhealthy>
263 Here is an example:
267 C 29 0 0 53 0 0 0 0
270 <sat> is the PRN number of the satellite.
274 <iodl> is 1 bit. 0 indicates that this information relates to the
277 satellite information in an accompanying type 1 or type 9 message.
278 <health> 0 indicates that the satellite is healthy. Any other value
281 indicates a problem (coding is not known).
282 <snr> gives the carrier/noise ratio of the received signal in the range
285 25 to 55 dB(Hz).
286 <health en> is 1 bit. If set to 1 it indicates that the satellite is
289 healthy even if the satellite navigation data says it is unhealthy.
290 <new data> is 1 bit. a 1 indicates that the IOD for this satellite will
293 soon be updated in type 1 or 9 messages.
294 <los warning> is 1 bit. a 1 indicates that the satellite will shortly
297 go unhealthy. The healthy time remaining is given in the <time to
298 unhealthy> field.
299 Radio Beacon Almanac (A)
302 Here is the format:
303 A <latitude> <longitude> <range> <frequency> <health> <station id>
306 <bitrate>
307 Here is an example:
311 A 54.1176 -0.0714 100 302.5 0 447 2
314 <latitude> and <longitude> give the position, in degrees, of the LF
318 transmitter antenna for the station for which this is an almanac. North
319 and East are positive.
320 <range> is the published range of the station in km.
323 <frequency> is the broadcast frequency in kHz.
326 <health> is the health of the station for which this is an almanac. If
329 it is non-zero, the station is issuing suspect data and should not be
330 used for fixes. The ITU and RTCM104 standards differ about the mode
331 detailed interpretation of the <health> field and even about its bit
332 width.
333 <station id> is the id of the transmitter. This is not the same as the
336 reference id in the header, the latter being the id of the reference
337 receiver.
338 <bitrate> indicates the transmitted bitrate.
341 Special Message (T)
344 Here is the format:
345 T <text>
348 Here is an example:
352 T THLS TRIAL SERVICE
355 <text> is just a text message sent by the beacon operator.
359 Null (N)
362 This just indicates a null message. There are no fields.
363 Unknown message (U)
366 This is used to dump message words in hexadecimal when the message type
367 field doesn't match any of the known ones.
368 Here is the format:
371 U <hex-literal>
374 Here is an example:
378 U 0x76423055
381 The <hex-literal> will represent 32 bits of information, after parity
385 checks and inversion. The high two bits should be ignored.
386 Null (N)
389 This just indicates a null message. There are no fields.
390
393 gpsd(8), gps(1), libgps(3), libgpsd(3), gpsprof(1), gpsfake(1).
394
397 Much of this text was originally written by John Sager
398 <john.sager@btinternet.com> in association with his RTCM decoder. Other
399 material comes from the GPSD project. There is a project page for gpsd
400 here: http://gpsd.berlios.de/.
401 RTCM-104(5)