[ntp:questions] Re: Garmin GPS 18 firmware update -> 200ms offset

David Schwartz davids at webmaster.com
Wed Nov 30 01:32:05 UTC 2005

"Patrick Klos" <pklos at osmium.mv.net> wrote in message 
news:dmic5q$s7e$1 at pyrite.mv.net...

> In article <dmiah2$27i$1 at nntp.webmaster.com>,

> David Schwartz <davids at webmaster.com> wrote:

>>    Ack! I do not recommend using a GPS for a timing application unless 
>> the
>>relationship between the NMEA time strings and the actual UTC second
>>boundary is specified by the manufacturer.

> You cannot get accurate timing without using the PPS signal.  There's no
> way to get accurate timing with JUST the NMEA strings.

    Equally true, you can't get accurate timing with just the PPS signal.

> The relationship is supposed to be this:  The PPS is aligned with the 
> actual
> start of a second, and the NMEA messages that follow it (during that 
> second)
> specify the data for that PPS (i.e. the time that PPS represented).  With
> GARMIN GPS's (and possibly others), the load on the internal processor 
> will
> effect when those NMEA messages actually start being transmitted.  We've
> observed that the messages sometimes get delayed by more than a second
> which causes confusion.

    I would not use a GPS for timing unless it had a guaranteed relationship 
between the NMEA timestamps and the UTC second boundary. This is in addition 
to the very obvious requirement that the PPS pulse have a guaranteed 
relationship to the UTC second boundary.

    An interesting question is how good a guaranteed relationship for the 
NMEA data is good enough. I would argue "90% of the time, the NMEA data will 
follow within 600mS of the corresponding PPS pulse" is good enough. However, 
you really do want something to be guaranteed by the manufacturer. 
Otherwise, it's "well, I hope it works, it seems to" with the NMEA data.


More information about the questions mailing list