Bogus results from NMEA/WNRO tangle

[Gary E. Miller]

Yo Hal!

On Fri, 28 Jan 2022 22:19:15 -0800
Hal Murray <halmurray at sonic.net> wrote:

> > I handle the regressions in gpsd so no need to fix them up.  They
> > have always had a line:   
> 
> Good. But that doesn't get the refclock drivers in ntpd.  I've been
> discussing refclock_nmea.
> 
> > So that is two roll overs, so far..  
> 
> Right.  But only one pivot date.

gpsd does not use a pivot date, Why does anyone need a pivot date?

gpsd just checks if the date fro mthe receiver is less than the
build data and if so, adds 1024 until it is not.

> >> 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?   
> 
> There is no year/month/day.  The code I fixed was using struct
> calendar from ntp_calendar.h

Yet another calendar struct?  Why not use the standard one?

Sre looke like a year/month/day:

struct calendar {
        uint16_t year;          /* year (A.D.) */
        uint16_t yearday;       /* day of year, 1 = January 1 */
        uint8_t  month;         /* month, 1 = January */
        uint8_t  monthday;      /* day of month */
        uint8_t  hour;          /* hour of day, midnight = 0 */
        uint8_t  minute;        /* minute of hour */
        uint8_t  second;        /* second of minute */
        uint8_t  weekday;       /* 0..7, 0=Sunday */
};


> >> 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.   
> 
> mktime uses the local time zone.  We need UTC.

So use tzset() to change mktime() to use UTC.

> > Lost me.  Isn't that why gpsd does everything in time_t?  Doesn't
> > ntpd do the same?   
> 
> The context is converting GPS HH-MM-SS without YYYY-MM-DD to a time_t.

Which is what mktime() does.

> So we assume the system time is close to right, get the time_t for
> the start of today and add on the seconds-this-day from GPS.

Bad assumption.  On nstatup a RasPi thinks it is 1969, again.

> The case that needs a 1 day fixup is when system time is 23:00:00 and
> GPS says 01:00:00.  The time_t for start-of-today from the system
> clock needs to be bumped forward by a day.

Only if you make the bad assumption above about system time.

> Each of the refclocks is slightly different.  The final result is
> that they need the offset between the refclock sample and the system
> time.  Some of the code uses struct calendar and code in
> ntp_calendar. I'm trying to eliminate that.

Please do.  That prolly predates the POSIX struct tm.

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/20220129/8dc9dffc/attachment.bin>