Re: [gpsd-dev] GPS week wraparound

[Magnus Danielson]

On 09/27/2013 07:14 PM, Andy Walls wrote:
>
> 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.
Notice that the leap second insertion occurs only the last minute of the
UTC month, with preference for end of each half year. You can do a
hold-down the last 15 min of each month where new devices is not trusted.
>> 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".
I agree. This is not by any means available in all.

Cheers,
Magnus