Re: [gpsd-dev] Time autonomy

[Hal Murray]

> I guess if gpsd saved a copy of the GPS week every time it rolled over we
> could detect an epoch roll over.  Then gpsd only needs a good GPS lock, and
> write, every epoch.

You have to do the save slightly more often than once per rollover period.  
I'd probably do it at 1/2 rollover.

One of the nasty cases in the leap-second discussion is a board sitting on 
the spares shelf.  After you plug it in, it takes a while to get the data 
with the leap-second offset from the satellites.  Leap seconds happen more 
frequently than week rollover so if you need UTC and quick start, this is the 
limiting factor.

10 bits of week is roughly 20 years.  The data format from the satellites 
have added a few more bits.  I don't know if manufacturers have updated their 
binary protocols and/or if they got lucky and allocated something like 2 
bytes for the week.  Clearly, that only works if the firmware on the device 
is new enough to process the extra bits.  Somebody should make a list of 
devices known to support the extra bits.

We should consider not doing any saves.  When would it break?  I think it's 
the last of:
  20 years after gpsd is compiled
  20 years after the device firmware is compiled (assuming it does the right 
thing)
  long long time if the device supports the extra bits.
Is the complexity of saves and the what-ifs if things get corrupted worth the 
effort?

You don't have to "save" any info specific to gpsd if you can get some 
cooperation from the OS.  The file system is usually full of dates.  You have 
to beware of chicken-egg problems.  Booting a setup that has been on the 
shelf for 20 years won't work.  (The clock starts when the OS was created, 
not when you put it on your shelf.)


-- 
These are my opinions.  I hate spam.