Re: [gpsd-dev] GPSD's assumptions about time

[Sanjeev Gupta]

On Wed, Nov 27, 2013 at 2:27 AM, Eric S. Raymond <address@hidden> wrote:

So far two ideas have come to me from this discussion, both of which I
think are worth implementing.

1. Compile the GPS week of the build into the build

The obvious place tp put this is in timebase.h. Not too expensive;
will typically cause extra work once per seven days.  The benefit is that
we can compare received week to the compiled-in week and if the latter
is less know that a rollover has occurred.

Would you (ESR) update timebase.h, or would the build process?

If former, this seems fragile, and I suggest this need not be done every week, only as a release item.

If the latter, than how do we ensure the build machine has a good GPS?: :-)

 

2. Track gpsd's confidence in the GPS time it's seeing.

This would increase when we see a leap-second offset or get GPZDA from
the device, decrease when we detect a rollover.  Some devices that are
known to deliver high-quality time (notably u-blox GPSes) would peg the
confidence measure at a high level.

Till u-blox makes a really cheap GPS, that goofs up, but still speals u-blox-ese fluently.

 

 We'd use the confidence level to
control (a) whether gpsd ships to NTP, and (b) how it sets time
uncertainty in output JSON.

Ack.

--
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane