Re: [gpsd-dev] GPS week wraparound

[Andy Walls]

On Fri, 2013-09-27 at 09:39 -0700, Hal Murray wrote:
> address@hidden said:
> > Before the almanac is received, the device is working with the leap-seconds
> > correction before the June 30,2012 leap- second. 
> 
> Thanks for the heads up on that one.  Harlan: Should we file a bug to track 
> it?
> 
> I think we can catch some of that with logic similar to the GPS week rollover 
> fixes.  That is we compile a constant into the code and either reject the 
> time or fix it up if it used an earlier leap second offset.  The fix-it 
> approach only works until another leap second is added, but we might be able 
> to get a recent offset from the file system.

I do have a problem if the memory-less GPS device is powered on in the
12.5 minute (GPS worst case almanac download time) window before a
scheduled leap second occurs.  It would be nice if NTPD could do
something about it.

My other option is to hack up my GPSD to indicate alarm status to NTPD,
until I know the UTC leap-second correction is correct.  But that leaves
NTPD without an indication that the time might be close.


> Does NMEA provide a standard way to get the number of leap seconds?  I don't 
> think so, but I might have missed it.

It will be very device specific, if it provides it at all.

The Trimble Condor device (MediaTek MT-3329 based?) that I have uses a
proprietary NMEA sentence to report it:  $PMTK.... => Proprietary,
MediaTek


The way I have to check to see if the UTC leap-second correction the
device is using is valid is either:

a) query the device periodically to check if the almanac has been
downloaded yet, or

b) monitor the $GPGLL sentence from the device until that specific
sentence from the device has valid data.

Both methods are very device specific.
 
>   How many NMEA devices have their own 
> way?

The best answer I can give is "Not all of them can report the UTC
leap-seconds correction in use".

Regards,
Andy