1<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> 2<html><head> 3 <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"><title>Generic NMEA GPS Receiver</title> 4 <!-- Changed by: Pearly &, 04-Feb-2019 --> 5 <link href="scripts/style.css" type="text/css" rel="stylesheet"> 6 <style type="text/css"> 7 table.dlstable { font-size:85%; } 8 td.ttf{ font-family:Courier; font-weight:bold; } 9 </style></head> 10 11 12 13 <body> 14 <h3>Generic NMEA GPS Receiver</h3> 15<p>Last update: 16 <!-- #BeginDate format:En2m -->17-Oct-2020 16:00<!-- #EndDate --> 17 UTC</p> 18 <hr> 19 <h4>Synopsis</h4> 20 21 <p> 22 Address: 127.127.20.<i>u</i><br> 23 Reference ID: <tt>GPS</tt><br> 24 Driver ID: <tt>GPS_NMEA</tt><br> 25 Serial Port: <tt>/dev/gps<i>u</i></tt>; 4800 - 115200 bps, 8-bits, no parity<br> 26 Serial Port: <tt>/dev/gpspps<i>u</i></tt>; for just the PPS signal (this 27 is tried first for PPS, before <tt>/dev/gps<i>u</i></tt>)<br> 28 Serial Port: <tt>/dev/gps<i>u</i></tt>; symlink to server:port (for nmead)<br> 29 Features: <tt>tty_clk</tt> 30 </p> 31 32 <h4>Description</h4> 33 34 <p> 35 This driver supports GPS receivers with 36 the <tt>$GPRMC</tt>, <tt>$GPGLL</tt>, <tt>$GPGGA</tt>, <tt>$GPZDA</tt> 37 and <tt>$GPZDG</tt> NMEA sentences by default. Note that Accord's 38 custom NMEA sentence <tt>$GPZDG</tt> reports using the GPS timescale, 39 while the rest of the sentences report UTC. The difference between 40 the two is a whole number of seconds which increases with each leap 41 second insertion in UTC. To avoid problems mixing UTC and GPS 42 timescales, the driver disables processing of UTC sentences 43 once <tt>$GPZDG</tt> is received. 44 <br> 45 <strong>Caveat:</strong> Please see <a href="#talkerids">Talker 46 IDs</a> when using non-GPS or multi-system receivers. 47 </p> 48 <p> 49 The driver expects the receiver to be set up to transmit at least one 50 supported sentence every second. 51 </p> 52 <p> 53 The accuracy depends on the receiver used. Inexpensive GPS models are 54 available with a claimed PPS signal accuracy of 55 1 μs or better relative to the broadcast 56 signal. However, in most cases the actual accuracy is limited by the 57 precision of the timecode and the latencies of the serial interface and 58 operating system. 59 </p> 60 <p> 61 If the Operating System supports PPSAPI 62 (<a href="http://www.ietf.org/rfc/rfc2783.txt">RFC 2783</a>), fudge flag1 63 1 enables its use. 64 </p> 65 <p> 66 The various GPS sentences that this driver recognises look like this:<br> 67 (others quietly ignored) 68 </p> 69 70 <p><table class="dlstable" border="1"> 71 <caption>Accepted NMEA sentences</caption> 72 <tbody><tr> 73 <th>Sentence</th> 74 <th>Vendor</th> 75 </tr><tr> 76 <td class="ttf">$GPRMC,UTC,POS_STAT,LAT,LAT_REF,LON,LON_REF,SPD,HDG,DATE,MAG_VAR,MAG_REF*CS<cr><lf></td> 77 </tr><tr> 78 <td class="ttf">$GPGLL,LAT,LAT_REF,LON,LON_REF,UTC,POS_STAT*CS<cr><lf></td> 79 </tr><tr> 80 <td class="ttf">$GPGGA,UTC,LAT,LAT_REF,LON,LON_REF,FIX_MODE,SAT_USED,HDOP,ALT,ALT_UNIT,GEO,G_UNIT,D_AGE,D_REF*CS<cr><lf></td> 81 </tr><tr> 82 <td class="ttf">$GPZDA,UTC,DD,MM,YYYY,TH,TM,*CS<cr><lf></td> 83 </tr><tr> 84 <td class="ttf">$GPZDG,GPSTIME,DD,MM,YYYY,AA.BB,V*CS<cr><lf></td> 85 <td>Accord</td> 86 </tr><tr> 87 </tr><tr> 88 <td class="ttf">$PGRMF,gpsWk,gpsTow,DATE,UTC,LEAPS,LAT,LAT_REF,LON,LON_REF,TYPE,MODE,SPD,HDOP,TDOP*CS<cr><lf></td> 89 <td>Garmin</td> 90 </tr><tr> 91 <td class="ttf">$PUBX,04,UTC,DATE,utcTow,utcWk,LEAPS,clkBias,clkDrift,tpGran,*CS<cr><lf></td> 92 <td>UBLOX</td> 93 </tr> 94 </tbody></table></p> 95 96 <p><table class="dlstable" border="1"> 97 <caption>NMEA data items</caption> 98 <tbody><tr> 99 <th>Symbol</th> 100 <th>Meaning and Format</th> 101 </tr> 102 103 <tr> 104 <td class="ttf">ALT</td> 105 <td>Antenna Altitude</td> 106 </tr><tr> 107 <td class="ttf">ALT_UNIT</td> 108 <td>Altitude Units (Metres/Feet)</td> 109 </tr><tr> 110 <td class="ttf">DATE</td> 111 <td>Date (ddmmyy)</td> 112 </tr><tr> 113 <td class="ttf">DD</td> 114 <td>Day of the month (1-31)</td> 115 </tr><tr> 116 <td class="ttf">D_AGE</td> 117 <td>Age of last DGPS Fix</td> 118 </tr><tr> 119 <td class="ttf">D_REF</td> 120 <td>Reference ID of DGPS station</td> 121 </tr><tr> 122 <td class="ttf">FIX_MODE</td> 123 <td>Position Fix Mode (0 = Invalid, >0 = Valid)</td> 124 </tr><tr> 125 <td class="ttf">GEO</td> 126 <td>Geoid/Elipsoid separation</td> 127 </tr><tr> 128 <td class="ttf">GPSTIME</td> 129 <td>Time of day on GPS timescale. Hours, minutes and seconds [fraction (opt.)] (hhmmss[.f])</td> 130 </tr><tr> 131 <td class="ttf">gpsTow</td> 132 <td>GPS week time, seconds since start of GPS week (0..604799)</td> 133 </tr><tr> 134 <td class="ttf">gpsWk</td> 135 <td>Week number in the GPS time scale (may exceed 1024)</td> 136 </tr><tr> 137 <td class="ttf">G_UNIT</td> 138 <td>Geoid units (M/F)</td> 139 </tr><tr> 140 <td class="ttf">HDG</td> 141 <td>Heading/track made good (degrees True) (x.x)</td> 142 </tr><tr> 143 <td class="ttf">HDOP</td> 144 <td>Horizontal Dilution of Precision</td> 145 </tr><tr> 146 <td class="ttf">LAT</td> 147 <td>Latitude (llll.ll)</td> 148 </tr><tr> 149 <td class="ttf">LAT_REF</td> 150 <td>Latitude direction (N = North, S = South)</td> 151 </tr><tr> 152 <td class="ttf">LEAPS</td> 153 <td>Leap seconds or difference between GPS time scale and UTC</td> 154 </tr><tr> 155 <td class="ttf">LON</td> 156 <td>Longitude (yyyyy.yy)</td> 157 </tr><tr> 158 <td class="ttf">LON_REF</td> 159 <td>Longitude direction (E = East, W = West)</td> 160 </tr><tr> 161 <td class="ttf">MAG_REF</td> 162 <td>Magnetic variation (E = East, W = West)</td> 163 </tr><tr> 164 <td class="ttf">MAG_VAR</td> 165 <td>Magnetic variation (degrees) (x.x)</td> 166 </tr><tr> 167 <td class="ttf">MM</td> 168 <td>Month of the year (1-12)</td> 169 </tr><tr> 170 <td class="ttf">POS_STAT</td> 171 <td>Position status. (A = Data valid, V = Data invalid)</td> 172 </tr><tr> 173 <td class="ttf">SAT_USED</td> 174 <td>Number of Satellites used in solution</td> 175 </tr><tr> 176 <td class="ttf">SPD</td> 177 <td>Speed over ground. (knots) (x.x)</td> 178 </tr><tr> 179 <td class="ttf">UTC</td> 180 <td>Time of day on UTC timescale. Hours, minutes and seconds [fraction (opt.)] (hhmmss[.fff])</td> 181 </tr><tr> 182 <td class="ttf">YYYY</td> 183 <td>Year</td> 184 </tr><tr> 185 <td class="ttf">WEEK</td> 186 <td>GPS week (0-1023)</td> 187 </tr><tr> 188 <td class="ttf">WSEC</td> 189 <td>Seconds since start of week (0-604799)</td> 190 </tr><tr> 191 <td class="ttf">LEAP</td> 192 <td>GPS leap seconds, that is, seconds ahead of UTC</td> 193 </tr><tr> 194 <td class="ttf">AA.BB</td> 195 <td>Denotes the signal strength (should be < 05.00)</td> 196 </tr><tr> 197 <td class="ttf">V</td> 198 <td>GPS sync status<br> 199 '0' => INVALID time,<br> 200 '1' => accuracy of +/- 20ms,<br> 201 '2' => accuracy of +/- 100ns</td> 202 </tr><tr> 203 <td class="ttf">CS</td> 204 <td> Checksum</td> 205 </tr><tr> 206 <td class="ttf"><cr><lf></td> 207 <td>Sentence terminator.</td> 208 </tr> 209 </tbody></table></p> 210 211 212 <h4><a name="talkerids"/>NMEA Talker IDs</h4> 213 214 <p> 215 GNSS receivers use a distinct talker ID for the GNSS they 216 process. Receivers capable of tracking different systems at the same time 217 can emit <tt>$GPRMC</tt> (GPS), <tt>$GLRMC</tt> (GLONASS), 218 <tt>$GARMC</tt> (Galileo), <tt>$GNRMC</tt> (generic/combined) and others 219 all in one data stream. 220 </p><p> 221 The driver supports this to a certain degree by ignoring the 222 talker ID on the standard sentences RMC, GLL, GGA, ZDA and ZDG. (It 223 possibly should not do that on the latter, but for now, that's the way 224 it is.) So whenever <tt>$GPRMC</tt> is mentioned in this document, 225 substitute any possible talker ID your receiver might emit -- it will 226 still match. 227 </p><p> 228 This approach has a drawback. It is easy to use for single-system 229 receivers, but it cannot separate the data streams for multi-system 230 receiver modules. It is therefore undefined which GNSS actually 231 provides the data, and this can lead to strange behavior. This is 232 especially true if the different GNSS provide very different signal 233 quality to the receiver; the driver is not able to cherry-pick the best 234 source and might actually end up in using the worst available. It is 235 therefore recommended to set up such a receiver to either use just a 236 single GNSS (which would defeat its purpose) or to emit only the 237 combined data, which usually has the <tt>GN</tt> talker ID defined by 238 the NMEA standard. 239 <p> 240 241 242 <h4>The 'mode' byte</h4> 243 244 <p> 245 Specific GPS sentences and bitrates may be selected by setting bits of 246 the 'mode' in the server configuration line:<br> <tt>server 247 127.127.20.x mode X</tt> 248 </p> 249 250 <table border="1"> 251 <caption>mode byte bits and bit groups</caption> 252 <tbody><tr> 253 <th align="center">Bit</th> 254 <th align="center">Decimal</th> 255 <th align="center">Hex</th> 256 <th align="left">Meaning</th> 257 </tr> 258 259 <tr> 260 <td align="center">0</td> 261 <td align="center">1</td> 262 <td align="center">1</td> 263 <td>process <tt>$GPRMC</tt></td> 264 </tr><tr> 265 <td align="center">1</td> 266 <td align="center">2</td> 267 <td align="center">2</td> 268 <td>process <tt>$GPGGA</tt></td> 269 </tr><tr> 270 <td align="center">2</td> 271 <td align="center">4</td> 272 <td align="center">4</td> 273 <td>process <tt>$GPGLL</tt></td> 274 </tr><tr> 275 <td align="center">3</td> 276 <td align="center">8</td> 277 <td align="center">8</td> 278 <td>process <tt>$GPZDA</tt> or <tt>$GPZDG</tt></td> 279 </tr><tr> 280 <td rowspan="6" align="center">4-6</td> 281 <td align="center">0</td> 282 <td align="center">0</td> 283 <td>linespeed 4800 bps</td> 284 </tr><tr> 285 <td align="center">16</td> 286 <td align="center">0x10</td> 287 <td>linespeed 9600 bps</td> 288 </tr><tr> 289 <td align="center">32</td> 290 <td align="center">0x20</td> 291 <td>linespeed 19200 bps</td> 292 </tr><tr> 293 <td align="center">48</td> 294 <td align="center">0x30</td> 295 <td>linespeed 38400 bps</td> 296 </tr><tr> 297 <td align="center">64</td> 298 <td align="center">0x40</td> 299 <td>linespeed 57600 bps</td> 300 </tr><tr> 301 <td align="center">80</td> 302 <td align="center">0x50</td> 303 <td>linespeed 115200 bps</td> 304 </tr><tr> 305 <td align="center">7</td> 306 <td align="center">128</td> 307 <td align="center">0x80</td> 308 <td>Write the sub-second fraction of the receive time stamp to the 309 clockstat file for all recognised NMEA sentences. This can be used to 310 get a useful value for fudge time2.<br><strong>Caveat:</strong> This 311 will fill your clockstat file rather fast. Use it only temporarily to 312 get the numbers for the NMEA sentence of your choice.</td> 313 </tr> 314 </tr><tr> 315 <td align="center">8</td> 316 <td align="center">256</td> 317 <td align="center">0x100</td> 318 <td>process <tt>$PGRMF</tt></td> 319 </tr><tr> 320 <td align="center">9</td> 321 <td align="center">512</td> 322 <td align="center">0x200</td> 323 <td>process <tt>$PUBX,04</tt></td> 324 </tr><tr> 325 <td align="center">10-15</td> 326 <td align="center"></td> 327 <td align="center">0xFC00</td> 328 <td>reserved - leave 0</td> 329 </tr><tr> 330 <td align="center">16</td> 331 <td align="center">65536</td> 332 <td align="center">0x10000</td> 333 <td>Append extra statistics to the clockstats line. 334 Details below.</td> 335 </tr><tr> 336 <td align="center">17</td> 337 <td align="center">131072</td> 338 <td align="center">0x20000</td> 339 <td>"Silent PPS" mode. Use the PPS channel (if enabled with 340 fudge flag 1) to get precise receive time stamps. 341 Do <em>not</em> set the PPS flag in the clock status, so the 342 clock is not considered as PPS peer. 343 </td> 344 </tr><tr> 345 <td align="center">18</td> 346 <td align="center">262144</td> 347 <td align="center">0x40000</td> 348 <td>Trust the date delivered via NMEA. Do this only if 349 you <em>really</em> trust the receiver! 350 See <a href="#datetrust">below</a>. <strong>Caveat:</strong> 351 This (hitherto undocumented) bit has moved! 352 </td> 353 </tr><tr> 354 <td align="center">19</td> 355 <td align="center">524288</td> 356 <td align="center">0x80000</td> 357 <td>Ignore receiver status, assume time is always good as long 358 as it is present at all. A possible option for receivers 359 with a good hold-over characteristic, but most likely 360 harmful in general. Use at own risk. 361 </td> 362 </tr> 363 </tbody></table> 364 365 366 <p> 367 The default (mode 0) is to process all supported sentences at a linespeed 368 of 4800 bps, which results in the first one received and recognised in 369 each cycle being used. If only specific sentences should be 370 recognised, then the mode byte must be chosen to enable only the selected 371 ones. Multiple sentences may be selected by adding their mode bit 372 values, but of those enabled still only the first received sentence in a 373 cycle will be used. Using more than one sentence per cycle is 374 impossible, because 375 </p><ul> 376 <li>there is only <a href="#fudgetime2">fudge time2</a> available to 377 compensate for transmission delays but every sentence would need a 378 different one and 379 </li><li>using more than one sentence per cycle overstuffs the internal data 380 filters. 381 </li></ul> 382 The driver uses 4800 bits per second by default, but faster bitrates can 383 be selected using bits 4 to 6 of the mode field. 384 </p> 385 386 <p> 387 <strong>Caveat:</strong> Using higher line speeds does not necessarily 388 increase the precision of the timing device. Higher line speeds are 389 not necessarily helpful for the NMEA driver, either. They can be 390 used to accomodate for an amount of data that does not fit into a 391 1-second cycle at 4800 bps, but high-speed high-volume NMEA data is likely 392 to cause trouble with the serial line driver since NMEA supports no 393 protocol handshake. Any device that is exclusively used for time 394 synchronisation purposes should be configured to transmit the relevant 395 data only, e.g. one <tt>$GPRMC</tt> or <tt>$GPZDA</tt> per second, at a 396 linespeed of 4800 bps or 9600 bps. 397 </p> 398 399 <h4><a name="datetrust"/>About distrusting NMEA date stamps</h4> 400 <p> 401 Trusting the calendar dates delivered via NMEA is a risky thing, and by 402 default these dates are handled with a huge dose of skepticism. Many 403 receivers deliver a correct calendar date for a period of just 1024 weeks, 404 with a starting point baked somewhere into their firmware. Beyond that, 405 they warp back to the begin of their era and simply provide wrong date 406 information. To battle this widely observed effect, the date delivered is 407 by default reduced to GPS time again and then (re-)mapped according to the 408 base date, either the implicit value or the value set via "tos basedate". 409 If the receiver can <em>really</em> be trusted to deliver the right date 410 (which is not impossible, just more expensive for the manufacturer), then 411 mode bit 18 can be used to bypass the era mapping. Setting this bit is 412 not needed under most circumstances, and setting it with an unreliable 413 receiver can have severe effects. Handle with care. 414 </p><p> 415 <strong>Note:</strong> This functionality was available for some time as 416 undocumented feature, with a different bit value. It was moved in the 417 process of becoming officially acknowledged to avoid excessive scattering 418 of the mode bit mask. 419 </p> 420 421 422 <h4>Monitor Data</h4> 423 424 <p>The last GPS sentence that is accepted or rejected is written to the 425 clockstats file and available with <code>ntpq -c clockvar</code>. 426 (Logging the rejected sentences lets you see/debug why they were rejected.) 427 Filtered sentences are not logged.</p> 428 429 <p> 430 If the 0x10000 mode bit is on and clockstats is enabled, several extra 431 counters will be appended to the NMEA sentence that gets logged. 432 For example: 433<pre> 43456299 76876.691 127.127.20.20 $GPGGA,212116.000,3726.0785,N,12212.2605,W,1,05,2.0,17.0,M,-25.7,M,,0000*5C 228 64 0 0 64 0 435</pre> 436 </p> 437 438 <table border="1"> 439 <caption>Clockstats</caption> 440 <tbody><tr> 441 <th align="center">Column</th> 442 <th align="center">Sample</th> 443 <th align="left">Meaning</th> 444 </tr> 445 446 <tr> 447 <td align="center">1</td> 448 <td align="center">56299</td> 449 <td>MJD</td> 450 </tr><tr> 451 <td align="center">2</td> 452 <td align="center">76876.691</td> 453 <td>Time of day in seconds</td> 454 </tr><tr> 455 <td align="center">3</td> 456 <td align="center">127.127.20.20</td> 457 <td>IP Address from server config line</td> 458 </tr><tr> 459 <td align="center">4</td> 460 <td align="center">$GPGGA,...0*5C</td> 461 <td>NMEA Sentence</td> 462 </tr><tr> 463 <td align="center">5</td> 464 <td align="center">228</td> 465 <td>Number of sentences received</td> 466 </tr><tr> 467 <td align="center">6</td> 468 <td align="center">64</td> 469 <td>Number of sentences accepted and used for timekeeping</td> 470 </tr><tr> 471 <td align="center">7</td> 472 <td align="center">0</td> 473 <td>Number of sentences rejected because they were marked invalid (poor signal)</td> 474 </tr><tr> 475 <td align="center">8</td> 476 <td align="center">0</td> 477 <td>Number of sentences rejected because of bad checksum or invalid date/time</td> 478 </tr><tr> 479 <td align="center">9</td> 480 <td align="center">64</td> 481 <td>Number of sentences filtered by mode bits or same second</td> 482 </tr><tr> 483 <td align="center">10</td> 484 <td align="center">0</td> 485 <td>Number of PPS pulses used, overrides NMEA sentences</td> 486 </tr> 487 </tbody></table> 488 489 Sentences like $GPGSV that don't contain the time will get 490 counted in the total but otherwise ignored. 491 492 <p> 493 <a href="https://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks">Configuring 494 NMEA Refclocks</a> might give further useful hints for specific hardware 495 devices that exhibit strange or curious behaviour. 496 </p> 497 498 <p> 499 To make a specific setting, select the corresponding decimal values from 500 the mode byte table, add them all together and enter the resulting 501 decimal value into the clock configuration line. 502 </p> 503 504 <h4>Setting up the Garmin GPS-25XL</h4> 505 506 Switch off all output with by sending it the following string. 507 <pre>"$PGRMO,,2<cr><lf>"</pre> 508 <p>Now switch only $GPRMC on by sending it the following string.</p> 509 <pre>"$PGRMO,GPRMC,1<cr><lf>"</pre> 510 511 <p>On some systems the PPS signal isn't switched on by default. It can be 512 switched on by sending the following string.</p> 513 <pre>"$PGRMC,,,,,,,,,,,,2<cr><lf>"</pre> 514 515 <h4>Fudge Factors</h4> 516 517 <dl> 518 <dt><tt>time1 <i>time</i></tt></dt> 519 <dd>Specifies the PPS time offset calibration factor, in seconds and fraction, with default 0.0.</dd> 520 <dt><a name="fudgetime2"><tt>time2 <i>time</i></tt></a></dt> 521 <dd>Specifies the serial end of line time offset calibration factor, in seconds and fraction, with default 522 0.0.</dd> 523 <dt><tt>stratum <i>number</i></tt></dt> 524 <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.</dd> 525 <dt><tt>refid <i>string</i></tt></dt> 526 <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with 527 default <tt>GPS</tt>.</dd> 528 <dt><tt>flag1 0 | 1</tt></dt> 529 <dd>Disable PPS signal processing if 0 (default); enable PPS signal processing if 1.</dd> 530 <dt><tt>flag2 0 | 1</tt></dt> 531 <dd>If PPS signal processing is enabled, capture the pulse on the rising edge if 0 (default); capture on the 532 falling edge if 1.</dd> 533 <dt><tt>flag3 0 | 1</tt></dt> 534 <dd>If PPS signal processing is enabled, use the <tt>ntpd</tt> clock discipline if 0 (default); use the kernel 535 discipline if 1.</dd> 536 <dt><tt>flag4 0 | 1</tt></dt> 537 <dd>Obscures location in timecode: 0 for disable (default), 1 for enable.</dd> 538 </dl> 539 540 <p>Additional Information</p> 541 <p><tt>flag1</tt>, <tt>flag2</tt>, and <tt>flag3</tt> are ignored under Windows.</p> 542 <p><a href="../refclock.html">Reference Clock Drivers</a></p> 543 <hr> 544 <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script> 545 </body></html> 546