Bogus results from NMEA/WNRO tangle

[Gary E. Miller]

Yo Hal!

On Wed, 26 Jan 2022 19:05:17 -0800
Hal Murray <halmurray at sonic.net> wrote:

> Thanks.
> 
> Gary said:
> >> We need 2 pivot dates, one for the 2 digit year fixup, another for
> >> the WNRO fixup.  
> 
> > More than 2, as WKRO happens every 1024 weeks.  
> 
> I don't understand how you are counting.  I see one pivot date for
> WNRO.  The fixup may have to take multiple steps but there is only
> one date to compare against.

The first roll over of the GPS broadcast week counter was:
August 2, 1999.

The second roll over of the GPS broadcast week counter was:
August 7, 2019.

Or, another way to look at it, today is GPS week 2194.  Modulo 1024
that is 146, with two roll overs.

So that is two roll overs, so far..

> Note that the dates we see may not pivot at a GPS pivot date.  The
> firmware in the GPS unit may have its own fixup code pivoting around
> its own release date.

Yup.  Many examples in the gpsd regression data.

> >> We need to add a pivot date to the release recipe -- something to
> >> replace the build-date that we removed to make builds predictable.
> >>  
> 
> > Maybe use the latest release data?  Then we still get predictable
> > builds.  
> 
> I'm setting things up so there is a header file that gets updated
> with a manual edit.  It needs to be done a bit before the actual
> release rather than when editing VERSION.  The catch is that the
> testing stuff has some tests that may need fixing if the pivot date
> changes.  I think the release announcement is a good time.  Anytime
> between releases is also OK.

I handle the regressions in gpsd so no need to fix them up.  They
have always had a line:

# Date: yyyy-mm-dd

gpsd uses that to override the built-in roller.

> >> I'm a bit surprised that Eric's early code removal effords didn't
> >> spot the calendar code.  
> 
> > Few GPS had rolled over then, so not a well understood issue.   
> 
> No, that's not the problem.  There is just a lot of code doing
> calendar conversions when Unix/POSIX already does almost what we
> need.  It's the sort of thing that Eric likes to clean up.

When some of that was written, POSIX functions was not always 
available.  Better now.

> Things like WNRO fixup can be done by adding 1024*7*86400.  There is
> no need for any calendar conversions.

That is not a calendar conversion?

> The refclocks need to convert things like YYYY-MM-DD to seconds.
> POSIX should provide that, but doesn't.  See next chunk.

POSIX mktime() does that.

> >> One problem with my current code is that Posix doesn't provide a
> >> UTC version of mktime.  
> 
> Garbage typo of mine.  That should have been:
> 
> One problem with my current code is that POSIX doesn't provide a
> reverse of gmtime.  localtime is the reverse of mktime but they both
> use the local time zone.  gmtime uses UTC, but there is no reverse.

Why is UTC not good enough?  What GPS does not use UTC?

> timegm is in Linux and BSDs.  If we want to run on a system without
> it, we can grab a copy form the web.

I don't understand why not mktime()?

> >> It needs to handle the case where the GPS time and system time
> >> cross day boundaries.  That is unlikely to get tested.  
> 
> > Just once a day...  
> 
> Maybe.  But if the system time is close to correct and the GPS
> sentence comes in at a significant offset from the second tick, then
> they will both be in the same second and hence same day.

Lost me.  Isn't that why gpsd does everything in time_t?  Doesn't ntpd
do the same?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20220126/51a6a4c8/attachment.bin>