Re: ✘GPS WKRO workaround

[Gary E. Miller]

Yo Greg!

On Fri, 06 Dec 2019 20:55:36 -0500
Greg Troxel <address@hidden> wrote:

> > gpsd now takes the current GPS leap second, falling back to the 
> > compiled in (currently wrong) leap second, and uses that to
> > disambiguate the correct GPS epoch, and thus the current date.

> How are you getting "current GPS leap second"?

The base layer is that gpsd is compiled in with a starting leap
second value.  Right now that comes from timebase.h, which is created
by leapsecond.py.  The value there is 19, but the correct current value
is 18.  leapsecond.py must die.

Once the GNSS receiver is talking, many of them will then send the
current leap second.

No standard NMEA sentence sends the current leap second.

The Garmin $PGRMF sentence sends GPS Week, Time of Week and leap second.

I think all the binary protocols can, and usually do, send the current
leap second.

The results is that pretty much all the binary regressions contain
the correct leap seccond for the moment of capture.  The NMEA
have to default to the compiled in value.

> If it's from the receiver, I don't follow why the tests break.

Since no standard NMEA sends the current leap second, the compiled in
value of 19 (soon to be 18) is used.

Once the leap second is known for the data stream, it is used to
check the UTC date from the GNSS receiver.

If the leap seecond is 18, or more, but the date is less than 2017,
then the GPS epoch is short by one (or two).  To fix that, 1024 weeks
of time are added to the time frm the receiver.

So a regression test from 2009, that has no leap second, gets "corrected"
to 2029.  Not a terrible thing for the regression.

The good part is that a Garmin 18x, or other old receiver, that currently
reports 2000, will now be corrected to the proper year of 2019, with time
exact to the second.

So we no longer need to tell people to throw away their receviers with the
GPS Week Number Roll Over (WKRO) bug away.

> If it's from the current system clock, maybe there needs  to be a
> synthetic system clock with the tests, read from a meta file.

The system clock is never used by gpsd for any GNSS data.  Only a things
like start time use the system clock.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpLe6h986p12.pgp
Description: OpenPGP digital signature