[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] GPS week wraparound

From: Andy Walls
Subject: Re: [gpsd-dev] GPS week wraparound
Date: Fri, 27 Sep 2013 09:01:46 -0400


On Fri, 2013-09-27 at 10:08 +0000, Harlan Stenn wrote:
> --
> "Eric S. Raymond" writes:
> > Harlan Stenn <address@hidden>:
> > > OK.  Does GPSD address this problem?  I'm thinking that the NTP GPS
> > > refclocks should handle this the same way GPSD does.
> > 
> > From the header of timebase.c:


> > 5) Another source *may* be available - the GPS leap second count, if we can
> > get the device to report it. The latter is not a given; SiRFs before
> > firmware rev 2.3.2 don't report it unless special subframe data reporting
> > is enabled, which requires 38400bps. Evermore GPSes can't be made to
> > report it at all.

This is not reliable.  I have a GPS unit that reports the leap second
count when queried.  

But without battery hold-up, the device steps time sometime *after*
start-up to insert another leap second after the GPS almanac is loaded:

After startup:
UTC Correction Query:    $PMTK457
UTC Correction Response: $PMTK557,15.0*03

After a second is repeated/inserted
UTC Correction Query:    $PMTK457
UTC Correction Response: $PMTK557,16.0*00

Before the almanac is received, the device is working with
the leap-seconds correction before the June 30,2012 leap-

It is obvious the GPS unit has an initial, hard-coded leap second count
that is out of date. 


On a related note, what is the best way to have NTPD accept the jump in
time and not mark my GPS clock (and PPS source) as false tickers?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]