On Thu, Jun 3, 2010 at 7:29 UTC, "Rob" wrote: > NMEA should not be trusted for time messages. The time in an > NMEA message is the "time of fix", i.e. the time at which the last > fix calculation was made in the receiver, and at which moment the > position values in the message were valid. There is no guarantee > that this is the CURRENT time, as the fix may be transmitted to > the outside world delayed by an unspecified amount of time. > And indeed, there often is a noticable and variable delay between > the time in the message and the moment it is sent. In certain situations > the delay may be more than a second, and you see the "off by a > second" problem.
I think the off by a second problem has other, simpler roots most often. Every NMEA sentence that provides time that I know of has 1 second resolution in the timecode. A receiver which is providing a timecode from over a second ago as part of a once-per-second NMEA blast is not something readers are likely to encounter in the real world. > For the binary protocol this situation often is a bit better. There > usually exist special messages to send the current time, and the > delay between fix and message may be specified better. Also, the > bitrate is often higher (rather than the default 4800 bps for NMEA). For a long time, ntpd insisted on 4800 bps for NMEA unless you patched the source. Now any rate your PC and GPS share is likely supported via "mode" bits 4, 5, and 6. The bitrate doesn't really matter much, though, except in terms of fitting more sentences in each one-second cycle, or keeping the timecode end-of-line timestamp with 0.4s of the PPS. Cheers, Dave Hart _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
