Re: [gpsd-dev] Time autonomy

[Hal Murray]

I would divide the problem into two parts: EPOCH and LEAP.  There are 
probably different solutions for NMEA and binary.

> This is me engineering for the SBC-a-thousand-miles-at-sea case. Besides, if
> we're going to take the role of feeding NTP seriously, it's circular to rely
> on NTP. 

I assume that "thousand-miles-at-sea" means no internet and no maintainance 
(aka software fixes).

The 10 bit week rollover is roughly 20 years.  If that's not good enough, I 
suggest requiring a modern receiver that supports the extra bits.  That would 
be 150 years.  (Many of us have old gear in our toy collection, but working 
gear that old is pretty rare.  Harrison's H4 is on display, but I don't think 
it's running.)

If you are using NMEA, the 2 digit year format covers 100 years.
  GPZDA has a 4 digit year.
  GPGGA has time, no date.
  GPRMC has 2 digit year.

I don't know a simple/clean way to tell if a NMEA device has valid leap 
offset info.  With binary packet formats, I'd expect the offset field to be 
zero until the receiver gets the data from the satellites.  There is still 
the problem with a unit being in storage for a long time but being "smart" 
enough to know the previous leap offset.  Wait an hour is the best approach I 
can think of, but it has problems.

-- 
These are my opinions.  I hate spam.