1 <?xml version="1.0" encoding="ISO-8859-1"?>
3 This file is Copyright (c) 2010 by the GPSD project
4 BSD terms apply: see the file COPYING in the distribution root for details.
6 <!DOCTYPE refentry PUBLIC
7 "-//OASIS//DTD DocBook XML V4.1.2//EN"
8 "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
9 <refentry id='rtcm104.5'>
10 <refentryinfo><date>27 Aug 2009</date></refentryinfo>
12 <refentrytitle>rtcm-104</refentrytitle>
13 <manvolnum>5</manvolnum>
14 <refmiscinfo class="source">The GPSD Project</refmiscinfo>
15 <refmiscinfo class="manual">GPSD Documentation</refmiscinfo>
17 <refnamediv id='name'>
18 <refname>rtcm-104</refname>
19 <refpurpose>RTCM-104 dump format emitted by GPSD tools</refpurpose>
22 <refsect1 id='overview'><title>OVERVIEW</title>
24 <para>RTCM-104 is a family of serial protocols used for broadcasting pseudorange
25 corrections from differential-GPS reference stations. This manual
26 page describes some aspects of the RTCM protocol, mainly in order to
27 explain the RTCM-104 dump formats emitted by
28 <citerefentry><refentrytitle>gpsdecode</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
29 It describes that dump format completely.</para>
31 <para>RTCM-104 comes in two major and incompatible flavors, 2.x and
32 3.x. Each major flavor has minor (compatible) revisions.</para>
34 <para>The applicable standard for RTCM Version 2.x is <citetitle>RTCM
35 Recommended Standards for Differential NAVSTAR GPS Service</citetitle>
36 RTCM Paper 194-93/SC 104-STD. For RTCM 3.1 it is <citetitle>RTCM Paper
37 177-2006-SC104-STD</citetitle>. Ordering instructions for both
38 standards are accessible from the website of the <ulink
39 url='http://www.rtcm.org/'>Radio Technical Commission for Maritime
40 Services</ulink> under "Publications".</para>
43 <refsect1 id='wire-format'><title>RTCM WIRE TRANSMISSIONS</title>
45 <para>Differential-GPS correction stations consist of a GPS reference
46 receiver coupled to a low frequency (LF) transmitter. The GPS
47 reference receiver is a survey-grade GPS that does GPS carrier
48 tracking and can work out its own position to a few millimeters. It
49 generates range and range-rate corrections and encodes them into
50 RTCM104. It ships the RTCM104 to the LF transmitter over serial rs-232
51 signal at 100 baud or 200 baud depending on the requirements of the
54 <para>The LF transmitter broadcasts the the approximately 300khz radio
55 signal that differential-GPS radio receivers pick up. Transmitters
56 that are meant to have a higher range will need to transmit at the
57 slower rate. The higher the data rate the harder it will be for the
58 remote radio receiver to receive with a good signal-to-noise ration.
59 (Higher data rate signals can't be averaged over as long a time frame,
60 hence they appear noisier.)</para>
63 <refsect1 id='rtcm-wire-format'><title>RTCM WIRE FORMATS</title>
65 <para>An RTCM 2.x message consists of a sequence of up to 33 30-bit
66 words. The 24 most significant bits of each word are data and the six
67 least significant bits are parity. The parity algorithm used is the
68 same ISGPS-2000 as that used on GPS satellite downlinks. Each RTCM
69 2.x message consists of two header words followed by zero or more data
70 words, depending upon message type.</para>
72 <para>An RTCM 3.x message begins with a fixed leader byte 0xD3. That
73 is followed by six bits of version information and 10 bits of payload
74 length information. Following that is the payload; following the
75 payload is a 3-byte checksum of the payload using the Qualcomm CRC-24Q
79 <refsect1 id='sager-dump-format2'><title>SAGER RTCM2 DUMP FORMAT</title>
81 <para>For each message, the header is listed first, followed by zero
82 or more lines containing the specific data for that message, followed
83 by a trailing sentinel line containing a single dot. The general format is a
84 line beginning with a capital letter, followed by a tab, followed by
85 the fields of the message separated by tabs, terminated by a
88 <refsect2><title>Header message (H)</title>
91 H <message type> <reference station id> <modified z_count> <sequence number>
92 <message length> <station health> [T <useful length>]
95 <para>Here is an example:</para>
97 <informalexample><literallayout>
99 S 13 0 3 249.6 -26.120 0.068
100 S 2 0 73 249.6 1.220 -0.080
101 S 8 0 22 249.6 23.760 0.030
103 </literallayout></informalexample>
105 <para><message type> is one of</para>
110 <listitem><para>full corrections - one message containing corrections for
111 all satellites in view. This is not common.</para></listitem>
116 <listitem><para>reference station parameters - the position of the
117 reference station GPS antenna.</para></listitem>
122 <listitem><para>datum — the datum to which the DGPS data is
123 referred.</para></listitem>
128 <listitem><para>constellation health — information about the
129 satellites the beacon can see</para></listitem>
134 <listitem><para>null message — just a filler.</para></listitem>
139 <listitem><para>radio beacon almanac — information about this or other beacons.</para></listitem>
144 <listitem><para>subset corrections — a message containing corrections
145 for only a subset of the satellites in view.</para></listitem>
150 <listitem><para>special message — a text message from the beacon
151 operator.</para></listitem>
155 <para><reference station id> is the id of the GPS reference receiver. The
156 LF transmitters also have (different) id numbers.</para>
158 <para><modified z_count> is the reference time of the
159 corrections in the message in seconds within the current hour. Note
160 that it is in GPS time, which is some seconds ahead of UTC (see the
161 U.S. Naval Observatory's <ulink
162 url="ftp://maia.usno.navy.mil/ser7/tai-utc.dat">table of leap second
163 corrections</ulink>).</para>
165 <para><sequence no> is a number which increments, modulo 8, for each
166 message transmitted.</para>
168 <para><message length> is the number of words after the header that
169 comprise the message.</para>
171 <para><station health> indicates the health of the beacon as a
172 reference source. Any nonzero value means the satellite is probably
173 transmitting bad data and should not be used in a fix. 6 means the
174 transmission is unmonitored. 7 means the station is not working
175 properly. Other values are defined by the beacon operator.
178 <para>If the message contains a parity error after the header but before
179 the end of the message, then the extra fields [T <useful length>]
180 are appended to indicate a truncated message.</para>
182 <para>Here is an example:</para>
184 <informalexample><literallayout>
185 H 9 687 331.8 1 5 0 T 4
186 </literallayout></informalexample>
188 <para><useful length> indicates the number of useful words before the
189 parity error. Depending on the message type, useful information
190 may still be extracted.</para>
193 <refsect2><title>Correction data (S)</title>
195 <para>One or more of these follow the header for type 1 or type 9
196 messages. Here is the format:</para>
199 S <satellite> <udre> <iod> <modified z_count> <range error>
200 <range error rate>
203 <para>Here is an example:</para>
205 <informalexample><literallayout>
206 S 7 0 199 331.8 -12.160 0.288
207 </literallayout></informalexample>
209 <para><satellite> is the PRN number of the satellite for which this is
210 correction data.</para>
212 <para><udre> is User Differential Range Error with the following
216 0 1-sigma error <= 1m
217 1 1-sigma error <= 4m
218 2 1-sigma error <= 8m
219 3 1-sigma error > 8m
222 <para><iod> is Issue Of Data, matching the IOD for the current
223 ephemeris of this satellite, as transmitted by the satellite. The IOD
224 is a unique tag that identifies the ephemeris; the GPS using the DGPS
225 correction and the DGPS generating the data must use the same orbital
226 positions for the satellite.</para>
228 <para><modified z_count> is just a copy of the same field from
231 <para><range error> is the pseudorange error in meters for this satellite
232 as measured by the beacon reference receiver at the epoch indicated
233 by <modified z_count></para>
235 <para><range error rate> is the rate of change of pseudorange error in
236 meters/sec for this satellite as measured by the beacon reference
237 receiver at the epoch indicated by <modified z_count>. This is
238 used to calculate pseudorange errors at other epochs, if
239 required by the GPS receiver.</para>
242 <refsect2><title>Reference Station Parameters (R)</title>
244 <para>Here is the format:</para>
247 R <X-coordinate> <Y-coordinate> <Z-coordinate>
250 <para>Here is an example:</para>
252 <informalexample><literallayout>
253 R 3746729.40 -5086.23 5144450.67
254 </literallayout></informalexample>
256 <para>The coordinates are the position of the station, in meters to two
257 decimal places, in Earth Centred Earth Fixed coordinates.
258 These are usually referred to the WGS84 reference frame, but may
259 be referred to NAD83 in the US (essentially identical to WGS84 for
260 all except geodesists), or to some other reference frame in other
261 parts of the world.</para>
264 <refsect2><title>Datum (D)</title>
266 <para>Here is the format:</para>
269 D <dgnss type> <dat> <datum name> [ <dx> <dy> <dz> ]
272 <para>Here is an (artificial) example:</para>
274 <informalexample><literallayout>
275 D GPS 0 ABC12 25.8 30.5 33.0
276 </literallayout></informalexample>
278 <para><dgnss type> is either GPS or GLONASS.</para>
280 <para><dat> is 0 or 1 and indicates the sense of the offset
281 shift given by dx, dy, dz. dat = 0 means that the station coordinates
282 (in the reference message) are referred to a local datum and that
283 adding dx, dy, dz to that position will render it in GNSS coordinates
284 (WGS84 for GPS). If dat = 1 then the ref station position is in GNSS
285 coordinates and adding dx, dy, dz will give it referred to the local
288 <para><datum name> is a standard name for the datum.</para>
290 <para><dx> <dy> <dz> are offsets to convert from
291 local datum to GNSS datum or vice versa. These fields are
295 <refsect2><title>Constellation Health (C)</title>
297 <para>One or more of these follow the header for type 5 messages — one
298 for each satellite.</para>
300 <para>Here is the format:</para>
303 C <sat> <iodl> <health> <snr> <hlth en> <new data> <los warning>
304 <time to unhealthy>
307 <para>Here is an example:</para>
309 <informalexample><literallayout>
311 </literallayout></informalexample>
313 <para><sat> is the PRN number of the satellite.</para>
315 <para><iodl> is 1 bit. 0 indicates that this information relates to the
316 satellite information in an accompanying type 1 or type 9 message.</para>
318 <para><health> 0 indicates that the satellite is healthy. Any other value
319 indicates a problem (coding is not known).</para>
321 <para><snr> gives the carrier/noise ratio of the received signal in the
322 range 25 to 55 dB(Hz).</para>
324 <para><health en> is 1 bit. If set to 1 it indicates that the
325 satellite is healthy even if the satellite navigation data says it is
328 <para><new data> is 1 bit. a 1 indicates that the IOD for this
329 satellite will soon be updated in type 1 or 9 messages.</para>
331 <para><los warning> is 1 bit. a 1 indicates that the satellite
332 will shortly go unhealthy. The healthy time remaining is given in the
333 <time to unhealthy> field.</para>
336 <refsect2><title>Radio Beacon Almanac (A)</title>
338 <para>Here is the format:</para>
341 A <latitude> <longitude> <range> <frequency> <health> <station id>
345 <para>Here is an example:</para>
347 <informalexample><literallayout>
348 A 54.1176 -0.0714 100 302.5 0 447 2
349 </literallayout></informalexample>
351 <para><latitude> and <longitude> give the position, in
352 degrees, of the LF transmitter antenna for the station for which this
353 is an almanac. North and East are positive.</para>
355 <para><range> is the published range of the station in km.</para>
357 <para><frequency> is the broadcast frequency in kHz.</para>
359 <para><health> is the health of the station for which this is an
360 almanac. If it is non-zero, the station is issuing suspect data and
361 should not be used for fixes. The ITU and RTCM104 standards differ
362 about the mode detailed interpretation of
363 the <health> field and even about its bit width.
365 From itu p.9 just under the type7 msg figure:
367 *** Radiobeacon health:
368 00 (0) Radiobeacon operation normal
369 01 (1) No integrity monitor operating
370 10 (2) No information available
371 11 (3) Do not use this radiobeacon
372 RTCM104, in the other hand, makes it 3 bits wide.
374 The Sager documentation said health has the same meaning as in the header.
375 but this cannot be true unless the field is 3 bits wide.
379 <para><station id> is the id of the transmitter. This is not the same
380 as the reference id in the header, the latter being the id of
381 the reference receiver.
382 <!-- John Sager noted: "However I know of at least one station
383 that gets it wrong." --></para>
385 <para><bitrate> indicates the transmitted bitrate.</para>
388 <refsect2><title>Special Message (T)</title>
390 <para>Here is the format:</para>
396 <para>Here is an example:</para>
398 <informalexample><literallayout>
400 </literallayout></informalexample>
402 <para><text> is just a text message sent by the beacon operator.</para>
405 <refsect2><title>Null (N)</title>
407 <para>This just indicates a null message. There are no fields.</para>
409 <refsect2><title>Unknown message (U)</title>
410 <!-- The Sager decoder didn't have this -->
412 <para>This is used to dump message words in hexadecimal when the
413 message type field doesn't match any of the known ones.</para>
415 <para>Here is the format:</para>
418 U <hex-literal>
421 <para>Here is an example:</para>
423 <informalexample><literallayout>
425 </literallayout></informalexample>
427 <para>The <hex-literal> will represent 32 bits of information,
428 after parity checks and inversion. The high two bits should be
432 <refsect2><title>Null (N)</title>
434 <para>This just indicates a null message. There are no fields.</para>
438 Decoder Status Messages (M)
442 M <type>: <information>
446 M state change: NO_SYNC -> WORD_SYNCING
449 <type> indicates textually the type of message. There are
450 only the two types shown above.
453 For <type> = state change it describes the internal state
454 transition of the decoder when it changes state as a result
455 of the incoming data.
457 For <type> = sync_bit this indicates the bit position in the
458 serial data stream which is a word boundary.
462 <refsect1 id='json-dump-format2'><title>JSON RTCM2 DUMP FORMAT</title>
464 <para>Fields are dumped in the order and with the conversions
465 described above, except that they are wrapped in a single JSON
466 object per message and appear as attributes of that object. Arrays of
467 satellite, station, and constellation statistics become arrays of
468 JSON sub-objects.</para>
470 <para>(One exception: The zcount field included in the Sager-format
471 per-satellite reports in type 1 and 9 messages is omitted from the
472 JSON version, as it is redundant with the zcount attribute of the
473 parent object.)</para>
476 <refsect1 id='dump-format3'><title>RTCM3 DUMP FORMAT</title>
478 <para>The support for RTCM104v3 dumping is still incomplete and
479 buggy. Anyone interested in it should read the source code.</para>
482 <refsect1 id='see_also'><title>SEE ALSO</title>
484 <citerefentry><refentrytitle>gpsd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
485 <citerefentry><refentrytitle>gps</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
486 <citerefentry><refentrytitle>libgps</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
487 <citerefentry><refentrytitle>libgpsd</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
488 <citerefentry><refentrytitle>gpsprof</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
489 <citerefentry><refentrytitle>gpsfake</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
493 <refsect1 id='compatibility'><title>COMPATIBILITY NOTE</title>
495 <para>In versions of the RTCM2 dump format prior to gpsd 2.28, there was
496 no trailing sentinel line after each stanza of the Sager-format dump.</para>
499 <refsect1 id='maintainer'><title>AUTHOR</title>
501 <para>Much of the portion of this text describing RTCM2 was originally
502 written by John Sager <email>john.sager@btinternet.com</email> in
503 association with his RTCM2 decoder. Other material comes from the GPSD
504 project. There is a project page for <application>gpsd</application>
505 <ulink url="http://gpsd.berlios.de/">here</ulink>.</para>