Bogus results from NMEA/WNRO tangle

[Gary E. Miller]

Yo Hal!

Sorry for the dealy, my inbox got full.


On Mon, 17 Jan 2022 22:41:36 -0800
Hal Murray via devel <devel at ntpsec.org> wrote:

> I think I've figured out what was going on.  There are 2 stages of
> fixup.  One is for the 2 digit year.  The other is for the WNRO.  The
> trick is that the year fixup has to let through known-bad years so
> the WNRO has the correct data to work with.

Interesting.

> If the GPS unit puts out xx20 for the year, and the pivot date is
> 2021, that shouldn't be bumped up to 2120.

Yup.

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

> 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 think I have refclcok_nema working without using any of the
> calendar stuff. It needs more testing.

Never enough testing.

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

> One problem with my current code is that Posix doesn't provide a UTC
> version of mktime.  Linux and BSDs have timegm.  I propose we treat
> this the same way we handle the BSD string routines -- provide an
> implementation if the environment doesn't.

According to the Linux mktime() man page:

CONFORMING TO
       POSIX.1-2001.  C89 and C99 specify asctime(), ctime(), gmtime(), local‐
       time(),  and  mktime(). 

> There is code to use the current date for the NMEA sentences that
> provide time without any date.  That's GPGGA and GPGLL.  Is there a
> good reason to support that?

Yes.  A lot of receivers on output GPGGA, or GPGLL, and nothing else.

> Is there any GPS unit that doesn't
> support a sentence with the date or any reason not to use it?

"support" is not the issue, "default" is.  ntpd does repgrogram the
receiver to what it needs.

> It's not a big deal, just some minor clutter with a few lines of
> slightly trickly code.  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...

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/20220121/324a541b/attachment.bin>