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

[Eric S. Raymond]

Sanjeev Gupta <address@hidden>:
> > 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?: :-)

The build process.  And we *compute* the GPS week from NTP time. That's
trivial.

> > 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.

That is why we pay attention to firmware versions.

Besides, I don't think u-blox is going to do that. Ever. The place is run by
Swiss-German engineers from the Zurich region, mostly former ETH faculty.
Certain implications follow - this is the heart country of the precision
timepiece, and these are people who by instinct consider quality compromises
to be approximately as odious as murdering a close relative.

(Distant kin of mine, by the way.  I'm largely Zuricher Swiss myself from my
mother's side of the family. Precision engineering is in my blood. No joke.)
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>