1RTCM-104(5) GPSD Documentation RTCM-104(5)
2
6 rtcm-104 - RTCM-104 dump format emitted by GPSD tools
7
9 RTCM-104 is a family of serial protocols used for broadcasting
10 pseudorange corrections from differential-GPS reference stations. This
11 manual page describes some aspects of the RTCM protocol, mainly in
12 order to explain the RTCM-104 dump formats emitted by gpsdecode(1). It
13 describes that dump format completely.
14 RTCM-104 comes in two major and incompatible flavors, 2.x and 3.x. Each
16 major flavor has minor (compatible) revisions.
17 The applicable standard for RTCM Version 2.x is RTCM Recommended
19 Standards for Differential NAVSTAR GPS Service RTCM Paper 194-93/SC
20 104-STD. For RTCM 3.1 it is RTCM Paper 177-2006-SC104-STD. Ordering
21 instructions for both standards are accessible from the website of the
22 Radio Technical Commission for Maritime Services[1] under
23 "Publications".
24
26 Differential-GPS correction stations consist of a GPS reference
27 receiver coupled to a low frequency (LF) transmitter. The GPS reference
28 receiver is a survey-grade GPS that does GPS carrier tracking and can
29 work out its own position to a few millimeters. It generates range and
30 range-rate corrections and encodes them into RTCM104. It ships the
31 RTCM104 to the LF transmitter over serial rs-232 signal at 100 baud or
32 200 baud depending on the requirements of the transmitter.
33 The LF transmitter broadcasts the the approximately 300khz radio signal
35 that differential-GPS radio receivers pick up. Transmitters that are
36 meant to have a higher range will need to transmit at the slower rate.
37 The higher the data rate the harder it will be for the remote radio
38 receiver to receive with a good signal-to-noise ration. (Higher data
39 rate signals can't be averaged over as long a time frame, hence they
40 appear noisier.)
41
43 An RTCM 2.x message consists of a sequence of up to 33 30-bit words.
44 The 24 most significant bits of each word are data and the six least
45 significant bits are parity. The parity algorithm used is the same
46 ISGPS-2000 as that used on GPS satellite downlinks. Each RTCM 2.x
47 message consists of two header words followed by zero or more data
48 words, depending upon message type.
49 An RTCM 3.x message begins with a fixed leader byte 0xD3. That is
51 followed by six bits of version information and 10 bits of payload
52 length information. Following that is the payload; following the
53 payload is a 3-byte checksum of the payload using the Qualcomm CRC-24Q
54 algorithm.
55
57 For each message, the header is listed first, followed by zero or more
58 lines containing the specific data for that message, followed by a
59 trailing sentinel line containing a single dot. The general format is a
60 line beginning with a capital letter, followed by a tab, followed by
61 the fields of the message separated by tabs, terminated by a newline.
62 Header message (H)
64 H <message type> <reference station id> <modified z_count> <sequence number>
65 <message length> <station health> [T <useful length>]
66 Here is an example:
68 H 9 268 249.6 1 5 0
70 S 13 0 3 249.6 -26.120 0.068
71 S 2 0 73 249.6 1.220 -0.080
72 S 8 0 22 249.6 23.760 0.030
73 .
74 <message type> is one of
76 1
78 full corrections - one message containing corrections for all
79 satellites in view. This is not common.
80 3
82 reference station parameters - the position of the reference
83 station GPS antenna.
84 4
86 datum — the datum to which the DGPS data is referred.
87 5
89 constellation health — information about the satellites the beacon
90 can see
91 6
93 null message — just a filler.
94 7
96 radio beacon almanac — information about this or other beacons.
97 9
99 subset corrections — a message containing corrections for only a
100 subset of the satellites in view.
101 16
103 special message — a text message from the beacon operator.
104 <reference station id> is the id of the GPS reference receiver. The LF
106 transmitters also have (different) id numbers.
107 <modified z_count> is the reference time of the corrections in the
109 message in seconds within the current hour. Note that it is in GPS
110 time, which is some seconds ahead of UTC (see the U.S. Naval
111 Observatory's table of leap second corrections[2]).
112 <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
117 the message.
118 <station health> indicates the health of the beacon as a reference
120 source. Any nonzero value means the satellite is probably transmitting
121 bad data and should not be used in a fix. 6 means the transmission is
122 unmonitored. 7 means the station is not working properly. Other values
123 are defined by the beacon operator.
124 If the message contains a parity error after the header but before the
126 end of the message, then the extra fields [T <useful length>] are
127 appended to indicate a truncated message.
128 Here is an example:
130 H 9 687 331.8 1 5 0 T 4
132 <useful length> indicates the number of useful words before the parity
134 error. Depending on the message type, useful information may still be
135 extracted.
136 Correction data (S)
138 One or more of these follow the header for type 1 or type 9 messages.
139 Here is the format:
140 S <satellite> <udre> <iod> <modified z_count> <range error>
142 <range error rate>
143 Here is an example:
145 S 7 0 199 331.8 -12.160 0.288
147 <satellite> is the PRN number of the satellite for which this is
149 correction data.
150 <udre> is User Differential Range Error with the following values:
152 0 1-sigma error <= 1m
154 1 1-sigma error <= 4m
155 2 1-sigma error <= 8m
156 3 1-sigma error > 8m
157 <iod> is Issue Of Data, matching the IOD for the current ephemeris of
159 this satellite, as transmitted by the satellite. The IOD is a unique
160 tag that identifies the ephemeris; the GPS using the DGPS correction
161 and the DGPS generating the data must use the same orbital positions
162 for the satellite.
163 <modified z_count> is just a copy of the same field from the header.
165 <range error> is the pseudorange error in meters for this satellite as
167 measured by the beacon reference receiver at the epoch indicated by
168 <modified z_count>
169 <range error rate> is the rate of change of pseudorange error in
171 meters/sec for this satellite as measured by the beacon reference
172 receiver at the epoch indicated by <modified z_count>. This is used to
173 calculate pseudorange errors at other epochs, if required by the GPS
174 receiver.
175 Reference Station Parameters (R)
177 Here is the format:
178 R <X-coordinate> <Y-coordinate> <Z-coordinate>
180 Here is an example:
182 R 3746729.40 -5086.23 5144450.67
184 The coordinates are the position of the station, in meters to two
186 decimal places, in Earth Centred Earth Fixed coordinates. These are
187 usually referred to the WGS84 reference frame, but may be referred to
188 NAD83 in the US (essentially identical to WGS84 for all except
189 geodesists), or to some other reference frame in other parts of the
190 world.
191 Datum (D)
193 Here is the format:
194 D <dgnss type> <dat> <datum name> [ <dx> <dy> <dz> ]
196 Here is an (artificial) example:
198 D GPS 0 ABC12 25.8 30.5 33.0
200 <dgnss type> is either GPS or GLONASS.
202 <dat> is 0 or 1 and indicates the sense of the offset shift given by
204 dx, dy, dz. dat = 0 means that the station coordinates (in the
205 reference message) are referred to a local datum and that adding dx,
206 dy, dz to that position will render it in GNSS coordinates (WGS84 for
207 GPS). If dat = 1 then the ref station position is in GNSS coordinates
208 and adding dx, dy, dz will give it referred to the local datum.
209 <datum name> is a standard name for the datum.
211 <dx> <dy> <dz> are offsets to convert from local datum to GNSS datum or
213 vice versa. These fields are optional.
214 Constellation Health (C)
216 One or more of these follow the header for type 5 messages — one for
217 each satellite.
218 Here is the format:
220 C <sat> <iodl> <health> <snr> <hlth en> <new data> <los warning>
222 <time to unhealthy>
223 Here is an example:
225 C 29 0 0 53 0 0 0 0
227 <sat> is the PRN number of the satellite.
229 <iodl> is 1 bit. 0 indicates that this information relates to the
231 satellite information in an accompanying type 1 or type 9 message.
232 <health> 0 indicates that the satellite is healthy. Any other value
234 indicates a problem (coding is not known).
235 <snr> gives the carrier/noise ratio of the received signal in the range
237 25 to 55 dB(Hz).
238 <health en> is 1 bit. If set to 1 it indicates that the satellite is
240 healthy even if the satellite navigation data says it is unhealthy.
241 <new data> is 1 bit. a 1 indicates that the IOD for this satellite will
243 soon be updated in type 1 or 9 messages.
244 <los warning> is 1 bit. a 1 indicates that the satellite will shortly
246 go unhealthy. The healthy time remaining is given in the <time to
247 unhealthy> field.
248 Radio Beacon Almanac (A)
250 Here is the format:
251 A <latitude> <longitude> <range> <frequency> <health> <station id>
253 <bitrate>
254 Here is an example:
256 A 54.1176 -0.0714 100 302.5 0 447 2
258 <latitude> and <longitude> give the position, in degrees, of the LF
260 transmitter antenna for the station for which this is an almanac. North
261 and East are positive.
262 <range> is the published range of the station in km.
264 <frequency> is the broadcast frequency in kHz.
266 <health> is the health of the station for which this is an almanac. If
268 it is non-zero, the station is issuing suspect data and should not be
269 used for fixes. The ITU and RTCM104 standards differ about the mode
270 detailed interpretation of the <health> field and even about its bit
271 width.
272 <station id> is the id of the transmitter. This is not the same as the
274 reference id in the header, the latter being the id of the reference
275 receiver.
276 <bitrate> indicates the transmitted bitrate.
278 Special Message (T)
280 Here is the format:
281 T <text>
283 Here is an example:
285 T THLS TRIAL SERVICE
287 <text> is just a text message sent by the beacon operator.
289 Null (N)
291 This just indicates a null message. There are no fields.
292 Unknown message (U)
294 This is used to dump message words in hexadecimal when the message type
295 field doesn't match any of the known ones.
296 Here is the format:
298 U <hex-literal>
300 Here is an example:
302 U 0x76423055
304 The <hex-literal> will represent 32 bits of information, after parity
306 checks and inversion. The high two bits should be ignored.
307 Null (N)
309 This just indicates a null message. There are no fields.
310
312 Fields are dumped in the order and with the conversions described
313 above, except that they are wrapped in a single JSON object per message
314 and appear as attributes of that object. Arrays of satellite, station,
315 and constellation statistics become arrays of JSON sub-objects.
316 (One exception: The zcount field included in the Sager-format
318 per-satellite reports in type 1 and 9 messages is omitted from the JSON
319 version, as it is redundant with the zcount attribute of the parent
320 object.)
321
323 The support for RTCM104v3 dumping is still incomplete and buggy. Anyone
324 interested in it should read the source code.
325
327 gpsd(8), gps(1), libgps(3), libgpsd(3), gpsprof(1), gpsfake(1).
328
330 In versions of the RTCM2 dump format prior to gpsd 2.28, there was no
331 trailing sentinel line after each stanza of the Sager-format dump.
332
334 Much of the portion of this text describing RTCM2 was originally
335 written by John Sager john.sager@btinternet.com in association with his
336 RTCM2 decoder. Other material comes from the GPSD project. There is a
337 project page for gpsd here[3].
338
340 1. Radio Technical Commission for Maritime Services
341 http://www.rtcm.org/
342 2. table of leap second corrections
344 ftp://maia.usno.navy.mil/ser7/tai-utc.dat
345 3. here
347 http://gpsd.berlios.de/
348The GPSD Project 27 Aug 2009 RTCM-104(5)