Re: [gpsd-dev] GPS week wraparound

[Andy Walls]

Hi:

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:

[snip]

> > 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-
second.

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


Harlan:

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?

Regards,
Andy