Re: [gpsd-dev] Planning a 3.11 snap release

[Hal Murray]

address@hidden said:
> GPSD is, in cold fact, that special.  It's used in life-critical navigation
> and IFF systems.  This justifies extraordinary measures to get something as
> basic as the time right. 

Then it's important to not set expectations that you can't fulfill.  I think 
that means documenting the limitations rather than pretending that you have 
covered all the weird cases.

In the past few weeks, we've been discussing two areas:  leap seconds and the 
epoch.

The GPS epoch is 1024 weeks which is about 20 years.

The trick of using the build time (or install time) of the code is a good 
one, but it only works for 20 years.  I'll bet some old reliable legacy gear 
will still be running 20 years after it gets built.

Note that the battery backup typical on GPS receivers remembers the date and 
time until the battery runs down so it's likely to get the right answer most 
of the time even after 20 years.  This is a mixed blessing.  It makes the 
problem less likely to happen, but makes it harder to debug and less likely 
that people will know about it when troubleshooting.

The software in the Motorola GPS board in my Z3801A says 13 JUL 1995.  2 more 
years to go.  :)

That's an old board.  It probably didn't use the software-build-date trick.  
I had to tell it the date to get it going correctly.  I've seen at least one 
similar report on the time-nuts list.

------

I'm not worried about getting the right century from NMEA devices.  Plugging 
in 2000 will work for another 86 years.  Somewhere in there we can use the 
build-date trick.

------

The similar trick of compiling in the current leap-second offset doesn't work 
as well.  They happen too often and using a default masks the problem.

I haven't seen any good suggestions in this area.  Suppose you really need to 
know if/when your time is accurate.  The only way I can see to do that is to 
make a list of devices that provide that information, and double check each 
one very carefully.  To do this right probably needs a GPS simulator to test 
the nasty cases.  Note that you have to repeat the tests every time they 
update the firmware.

------

The context for this discussion was fetching things at build time.

As a developer, I find it slightly annoying that every time I build gpsd, it 
wastes time fetching data that hasn't changed.  I'd be happy with a local 
copy that was assumed valid for a day or week.  Ideally, it would be stored 
in git so one fetch would apply to all the developers and git-pull or scons 
-c didn't blow it away.







-- 
These are my opinions.  I hate spam.