gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Time autonomy


From: Hal Murray
Subject: Re: [gpsd-dev] Time autonomy
Date: Thu, 28 Nov 2013 11:33:51 -0800

Looks good to me.

Note that we have already had 1 week rollover so you can test most of the 
code by building with constants set to long ago.

I think the NMEA vs binary devices area needs clarification.

At least one NMEA sentence gives a 4 digit year.  With a 4 digit year you can 
compute the epoch directly, at least until 3000.  With a 2 digit year, it 
only works until 2100.  I'm assuming they will use the build-date trick so 
the year will be correct for 20 years after the device (or its firmware) is 
built, or much longer when the 13 bit week gets implemented.

Assuming you compute an epoch from the NMEA date, I think there are several 
cases:
  If gpsd build epoch == NMEA epoch:  simple case, use it
  if gpsd epoch < NMEA epoch:
    new NMEA, use future epoch from NMEA
  if gpsd epoch > NMEA epoch:
     old NMEA lies, bump epoch from NMEA (maybe multiple times)

Do binary devices provide any info that can be used to derive the epoch?  
Perhaps a firmware date or hardware manufacturing date?


> This will yield nearly correct time provided the device is on continuously
> on from a date during its build era (e.g. before the first rollover after
> BUILD_EPOCH), and gets at least one valid fix per week. 

[Typo: two "on"s.]

I think it's better than that, or at least more complicated.

GPS receivers have a clock.  That will do the right thing for multi-week 
periods without a valid fix.

Most devices have battery backed clocks and storage that will cover modest 
amounts of "off" time.  Details depend on the device but days or weeks are 
reasonable.

Some devices have a way to tell them the date/time.  Perhaps we should 
document the gpsctl incantations someplace.

----------

> To upgrade so the algorithm can handle shutdown periods, add two steps: 
[/var/run/gps-epoch...]

Without that, it works for 20 years past the build date, including shutdown 
periods.

Is that good enough?  Is working for more than 20 years worth the complexity 
of what happens when a file gets mangled and documenting things so admins can 
debug it and ...?

----------

An alternative source of the epoch is the file system.  I think some OSes 
running on systems that don't have have a battery-backed RTC/TOY use that to 
set the initial time.  I think there is something like a last-update-date on 
the mount point for the root file system that gets updated frequently.  I 
don't know how well that works in practice.



-- 
These are my opinions.  I hate spam.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]