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

[Eric S. Raymond]

Sanjeev Gupta <address@hidden>:
> Even with a 12-bit counter, if someone installs gpsd, and does not update
> it for 19 years, and has no network access, and buys a GPS device that
> refuses to give us century info, and has a poor antenna placement such that
> we cannot build a full almanac due to dropouts, and has a partial view of
> the sky that no satellite is visible for 12.5 minutes continuously, etc,
> what can I say, but:
> 
>    "What are you doing building a Safety-of-Life application?"
> 
> Or:
>    "You keep using that word.  I do not think it means what you think it
> means"
> 
> Eric, Gary, Greg, et al, how much can you save me from my poor design
> choices?

Your point is valid.  However, by exerting the effort required to
handle even nasty cases correctly, we also tend to armor-plate the
software so that it is much less likely to fail under less extreme
conditions.

I think this is good practice for safety-of-life software, which is
why I spend so much time thinking about the SBC-a-thousand-miles-at-sea
case.

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.

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.  We'd use the confidence level to
control (a) whether gpsd ships to NTP, and (b) how it sets time 
uncertainty in output JSON.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>