Re: Buggy WNRO fixup
Thanks for testing. > With these changes I see no WNRO messages thus far... Would you please check again. I expect 1 each time you start ntpd. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
Yo Udo! On Sat, 12 Feb 2022 12:35:43 +0100 Udo van den Heuvel wrote: > On 12-02-2022 07:36, Gary E. Miller via devel wrote: > > A capture of the raw NMEA would be helpful. > > The other gps18x does not show the wrong date. > So would a reset of the 'wrong date' gps18x work? > Powerdown/up? You need to ask just to power cycle? My guess is, no. What firmware versions are your two devices? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@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 pgp1yasiQZpzx.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
On 12-02-2022 08:37, Hal Murray wrote: Please try git head. I fixed my test case. Updated git again a few minutes ago. With these changes I see no WNRO messages thus far... If this was the intended behaviour: THANKS! Udo ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
On 12-02-2022 07:36, Gary E. Miller via devel wrote: A capture of the raw NMEA would be helpful. The other gps18x does not show the wrong date. So would a reset of the 'wrong date' gps18x work? Powerdown/up? Udo ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
On 12-02-2022 08:37, Hal Murray wrote: Please try git head. I fixed my test case. Feb 12 12:17:10 plnksrf ntpd[148641]: INIT: ntpd ntpsec-1.2.1: Starting Feb 12 12:17:10 plnksrf ntpd[148641]: INIT: Command line: /usr/sbin/ntpd -u ntp:ntp -x -N -p /var/run/ntpd.pid Feb 12 12:17:10 plnksrf ntpd[148642]: INIT: precision = 0.908 usec (-20) Feb 12 12:17:10 plnksrf ntpd[148642]: INIT: successfully locked into RAM Feb 12 12:17:10 plnksrf ntpd[148642]: CONFIG: readconfig: parsing file: /etc/ntp.conf Feb 12 12:17:10 plnksrf ntpd[148642]: AUTH: authreadkeys: reading /etc/ntp/keys Feb 12 12:17:10 plnksrf ntpd[148642]: AUTH: authreadkeys: added 0 keys Feb 12 12:17:10 plnksrf ntpd[148642]: CONFIG: restrict nopeer ignored Feb 12 12:17:10 plnksrf ntpd[148642]: CONFIG: restrict nopeer ignored Feb 12 12:17:10 plnksrf ntpd[148642]: CONFIG: 'monitor' cannot be disabled while 'limited' is enabled Feb 12 12:17:10 plnksrf ntpd[148642]: INIT: Using SO_TIMESTAMPNS(ns) Feb 12 12:17:10 plnksrf ntpd[148642]: IO: Listen and drop on 0 v6wildcard [::]:123 Feb 12 12:17:10 plnksrf ntpd[148642]: IO: Listen and drop on 1 v4wildcard 0.0.0.0:123 Feb 12 12:17:10 plnksrf ntpd[148642]: IO: Listen normally on 2 lo 127.0.0.1:123 Feb 12 12:17:10 plnksrf ntpd[148642]: IO: Listen normally on 3 eth0 192.168.10.70:123 Feb 12 12:17:10 plnksrf ntpd[148642]: IO: Listen normally on 4 lo [::1]:123 Feb 12 12:17:10 plnksrf ntpd[148642]: IO: Listening on routing socket on fd #21 for interface updates Feb 12 12:17:10 plnksrf ntpd[148642]: SYNC: Found 15 servers, suggest minsane at least 3 Feb 12 12:17:10 plnksrf ntpd[148642]: INIT: MRU 10922 entries, 13 hash bits, 65536 bytes Feb 12 12:17:10 plnksrf ntpd[148642]: INIT: OpenSSL 1.1.1l FIPS 24 Aug 2021, 101010cf Feb 12 12:17:10 plnksrf ntpd[148642]: NTSc: Using system default root certificates. Feb 12 12:17:10 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:10 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:10 plnksrf ntpd[148641]: 2022-02-12T12:17:10 ntpd[148641]: INIT: ntpd ntpsec-1.2.1: Starting Feb 12 12:17:10 plnksrf ntpd[148641]: 2022-02-12T12:17:10 ntpd[148641]: INIT: Command line: /usr/sbin/ntpd -u ntp:ntp -x -N -p /var/run/ntpd.pid Feb 12 12:17:11 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:11 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:12 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:12 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:13 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:13 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:14 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:14 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: DNS lookup of time.cloudflare.com:1234 took 0.023 sec Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: connecting to time.cloudflare.com:1234 => 162.159.200.123:1234 Feb 12 12:17:15 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: Using TLSv1.3, TLS_AES_256_GCM_SHA384 (256) Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: certificate subject name: /C=US/ST=California/L=San Francisco/O=Cloudflare, Inc./CN=time.cloudflare.com Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: certificate issuer name: /C=US/O=DigiCert Inc/CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1 Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: certificate is valid. Feb 12 12:17:15 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: read 750 bytes Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: Using port 123 Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: Got 7 cookies, length 100, aead=15. Feb 12 12:17:15 plnksrf ntpd[148642]: NTSc: NTS-KE req to time.cloudflare.com:1234 took 0.140 sec, OK Feb 12 12:17:16 plnksrf ntpd[148642]: NTSc: DNS lookup of ntpmon.dcs1.biz took 0.084 sec Feb 12 12:17:16 plnksrf ntpd[148642]: NTSc: connecting to ntpmon.dcs1.biz:4460 => 203.123.48.219:4460 Feb 12 12:17:16 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:16 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:17 plnksrf ntpd[148642]: NTSc: connect_TCP_socket: connect failed: Connection refused Feb 12 12:17:17 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 12 12:17:17 plnksrf ntpd[148642]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 12 12:17:17 plnksrf ntpd[148642]: NTSc: DNS lookup of pi4.rellim.com took 0.241 sec Feb 12 12:17:17 plnksrf ntpd[148642]: NTSc: connecting to pi4.rellim.com:4460 => 204.17.205.24:4460 Feb 12 12:17:18 plnksrf
Re: Buggy WNRO fixup
Please try git head. I fixed my test case. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
> A capture of the raw NMEA would be helpful. But don't work too hard on it. I have a test case. Fix soon. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
Yo Udo! A capture of the raw NMEA would be helpful. On Sat, 12 Feb 2022 06:52:47 +0100 Udo van den Heuvel via devel wrote: > On 12-02-2022 06:45, Hal Murray wrote: > > > > devel@ntpsec.org said: > >> Is this an effect? I get loads of these: > >> Feb 6 00:00:28 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date > >> advanced by 0 weeks, WNRO > > > > That's a bug. Looks like it's alternating between 0 and 1024. > > > > Which sentence(s) are you using? What's your server line? (the > > mode part) I'm guessing you don't have one. Try adding "mode 1" > > > > > > Thanks for the report. > > ##NMEA zonder PPS > refclock nmea unit 0 mode 7 flag3 1 flag2 0 flag1 0 time1 0.0006 > time2 0.260 baud 4800 > # > ## PPS van dezelfde NMEA GPS > refclock pps unit 0 flag2 0 > > # vuurmuur > server 192.168.10.98 minpoll 4 iburst > > > Udo > ___ > devel mailing list > devel@ntpsec.org > https://lists.ntpsec.org/mailman/listinfo/devel RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@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 pgplrFIIqFXwM.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
On 12-02-2022 06:45, Hal Murray wrote: devel@ntpsec.org said: Is this an effect? I get loads of these: Feb 6 00:00:28 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO That's a bug. Looks like it's alternating between 0 and 1024. Which sentence(s) are you using? What's your server line? (the mode part) I'm guessing you don't have one. Try adding "mode 1" Thanks for the report. ##NMEA zonder PPS refclock nmea unit 0 mode 7 flag3 1 flag2 0 flag1 0 time1 0.0006 time2 0.260 baud 4800 # ## PPS van dezelfde NMEA GPS refclock pps unit 0 flag2 0 # vuurmuur server 192.168.10.98 minpoll 4 iburst Udo ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
devel@ntpsec.org said: > Is this an effect? I get loads of these: > Feb 6 00:00:28 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 0 > weeks, WNRO That's a bug. Looks like it's alternating between 0 and 1024. Which sentence(s) are you using? What's your server line? (the mode part) I'm guessing you don't have one. Try adding "mode 1" Thanks for the report. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
On 20-12-2021 21:51, Hal Murray via devel wrote: I have a NMEA unit that's off by 1024 weeks. Somebody is fixing it twice. Anybody know where that fixup code is located? I took a quick scan in the NMEA driver but didn't find it. Is this an effect? I get loads of these: Feb 6 00:00:28 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 6 00:00:29 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 6 00:00:29 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 6 00:00:30 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Feb 6 00:00:30 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 0 weeks, WNRO Feb 6 00:00:31 srfplnk2 ntpd[510014]: REFCLOCK: NMEA(0) date advanced by 1024 weeks, WNRO Udo ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
Yo Hal! On Wed, 29 Dec 2021 13:31:44 -0800 Hal Murray via devel wrote: > Gary said: > >> The code I was expecting doesn't know anything about leaps. > >> It would be close to: > >> while (t < PIVOT) t += 1024*7*86400 > > > Which will break after 1024 weeks. Which sounds like a lot, but > > there are a lot of GPS that are more than 1024 weeks old since > > their firmware was cut. > > Your code has similar problems. Right? Only a few of the problematic drivers have the problem. As lone as the NMEA reports the correct year, all is good. > That's 1024 weeks after ntpsec is released. I'm willing to assume > that ntpsec gets updated more often than that. Not 100%, but close. > We could add a config option to sepcify the pivot date but that > doesn't seem worth the effort. Maybe for testing, but anyone using a 1024 week old ntpd will not have read the man page in a long time. > Do we have any place to collect documentation for quirks like this? Prolly best in the NMEA doc. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@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 pgpjTiSu9ahyZ.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
Gary said: >> The code I was expecting doesn't know anything about leaps. >> It would be close to: >> while (t < PIVOT) t += 1024*7*86400 > Which will break after 1024 weeks. Which sounds like a lot, but there are a > lot of GPS that are more than 1024 weeks old since their firmware was cut. Your code has similar problems. Right? That's 1024 weeks after ntpsec is released. I'm willing to assume that ntpsec gets updated more often than that. We could add a config option to sepcify the pivot date but that doesn't seem worth the effort. It would only be useful for cases where a modern ntpsec that couldn't be updated was being used with an old GPS unit. Do we have any place to collect documentation for quirks like this? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
Yo Hal! On Wed, 29 Dec 2021 03:02:00 -0800 Hal Murray via devel wrote: > Gary said: > > Basically, if the GPS reports more the 17 leap seconds, then the > > time has to be aster 1 Jan 2017. > > Thanks. > > I assume the leap second tangle is so avoid breaking some very old > test cases by bumping them into the current epoch. Only the not so very old test cases. The very old test cases needed a different fix. For those, the "# Date:" header in the regression test is used. > The code I was expecting doesn't know anything about leaps. > > It would be close to: > while (t < PIVOT) t += 1024*7*86400 Which will break after 1024 weeks. Which sounds like a lot, but there are a lot of GPS that are more than 1024 weeks old since their firmware was cut. > Are there any GPS units old enough to need to get bumped twice? Yes. A few. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@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 pgpYlrAk3qCi3.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
rlaa...@wiktel.com said: > This is what you're thinking of (slightly trimmed): ... Thanks. I wonder how long it would have taken me to find that. Gary said: > Basically, if the GPS reports more the 17 leap seconds, then the time has to > be aster 1 Jan 2017. Thanks. I assume the leap second tangle is so avoid breaking some very old test cases by bumping them into the current epoch. The code I was expecting doesn't know anything about leaps. It would be close to: while (t < PIVOT) t += 1024*7*86400 Where PIVOT would be the release date in seconds. -- Are there any GPS units old enough to need to get bumped twice? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
On 12/28/21 3:35 PM, Hal Murray via devel wrote:
Is there any magic not-before date in the ntpsec environment?
I think we used to have the build date in the version string but that was
removed to make builds reproducable. I thought we added something in a
#define someplace with the idea that it would get updated with each release,
but I can't find it.
This is what you're thinking of (slightly trimmed):
commit f76af8b7f4080ce7c1334f24c74c7259b84dc899
Author: James Browning
Date: Thu Dec 31 11:34:06 2020 -0800
Remove --build-epoch and replace it with arbitrary --build-desc text.
Passing '--build-desc=$(date -u +%Y-%m-%dT%H:%M:%Sz)' restores the
previous default extended version.
The build epoch has been replaced with a hardcoded timestamp which will
be manually updated every nine years or so (approx 512w). This makes
the binaries reproducible by default.
--- a/libntp/ntp_calendar.c
+++ b/libntp/ntp_calendar.c
@@ -38,7 +38,7 @@ ntpcal_get_build_date(
struct calendar * jd
)
{
-time_t epoch = (time_t)BUILD_EPOCH;
+time_t epoch = (time_t)1577836800; // 2020 Jan 01 -> 1863820800
- 2029 Jan 23
struct tm epoch_tm;
ZERO(*jd);
--
Richard
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
Yo Hal!
On Tue, 28 Dec 2021 13:35:33 -0800
Hal Murray wrote:
> > That is the important part. gpsd handles that just fine:
>
> Is there anything tricky about the fixup code?
Nope. gpsd/timebase.c, line 322.
Here is the meat:
/* sanity check unix time against leap second.
* Does not work well with regressions because the leap_sconds
* could be from the receiver, or from BUILD_LEAPSECONDS.
* Leap second 18 at 1 Jan 2017: 1483228800
* (long long) for 32-bit systems */
if (17 < session->context->leap_seconds &&
1483228800LL > t.tv_sec) {
long long old_tv_sec = t.tv_sec;
t.tv_sec += 619315200LL;// fast forward 1024 weeks
Basically, if the GPS reports more the 17 leap seconds, then the time
has to be aster 1 Jan 2017.
The regression tests are dealt with elsewhjere.
> I was expecting a few lines of code. The existing code is much much
> more complicated than that.
I assume you are talking about the NTPsec code. THat does look excessive.
> Is there any magic not-before date in the ntpsec environment?
gpsd has BUILD_LEAPSECONDS, and BUILD_CEDNTURY.
> I think we used to have the build date in the version string but that
> was removed to make builds reproducable. I thought we added
> something in a #define someplace with the idea that it would get
> updated with each release, but I can't find it.
Ditto for gpsd.
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@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
pgpA3gsgPVUNr.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
> That is the important part. gpsd handles that just fine: Is there anything tricky about the fixup code? I was expecting a few lines of code. The existing code is much much more complicated than that. --- Is there any magic not-before date in the ntpsec environment? I think we used to have the build date in the version string but that was removed to make builds reproducable. I thought we added something in a #define someplace with the idea that it would get updated with each release, but I can't find it. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
Yo Hal!
On Fri, 24 Dec 2021 12:01:50 -0800
Hal Murray wrote:
> >> I have a NMEA unit that's off by 1024 weeks. Somebody
> >> is fixing it twice.
> > How do you know that?
>
> The time on that system got set to Nov 4 2023
>
> The "twice" part was sloppy, but something strange was going on.
>
> The log message says -4096 weeks which just adds to my confusion.
> 20 Dec 12:22:32 ntpd[40363]: NMEA(1) Changed GPS epoch warp to -4096
> weeks
Odd. Plus, or minus, 4096 sems way off.
Today, 24 Dec 2021, is GPS Week 2189 day 358.
From: https://www.ngs.noaa.gov/CORS/Gpscal.shtml
> The code is in ntpd/ntp_wrapdate.c
>
> refclock_nmea calls it in at least 2 places:
>
> case NMEA_GPRMC:
> rc_date = parse_date(, , 9, DATE_1_DDMMYY)
> && unfold_century(,
> lfpuint(rd_timestamp));
You are seeing $GPRMC.
> case NMEA_PGRMF:
> rc_date = rc_date
> && gpsfix_century(, ,
> >century_cache);
Garmin private, so you can ignore that.
> rd_reftime = eval_gps_time(refclock_name(peer), , ,
>(peer->cfg.mode &
> NMEA_DATETRUST_MASK), >epoch_warp, _timestamp);
That looks nothing like gpsd does...
> > Can you send this list a few seconds of your NMEA?
>
> $GPRMC,195031.000,A,3726.0713,N,12212.2560,W,0.00,344.40,100502,,,A*74
That is the important part. gpsd handles that just fine:
{"class":"TPV","device":"stdin","mode":3,"time":"2021-12-24T19:50:31.000Z"...
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@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
pgpSj2MC59z5o.pgp
Description: OpenPGP digital signature
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
>> I have a NMEA unit that's off by 1024 weeks. Somebody >> is fixing it twice. > How do you know that? The time on that system got set to Nov 4 2023 The "twice" part was sloppy, but something strange was going on. The log message says -4096 weeks which just adds to my confusion. 20 Dec 12:22:32 ntpd[40363]: NMEA(1) Changed GPS epoch warp to -4096 weeks >> Anybody know where that fixup code is located? I took a >> quick scan in the NMEA driver but didn't find it. > I don't think ntpd adjusts NMEA years. gpsd does, by looking at the leap > second. The code is in ntpd/ntp_wrapdate.c refclock_nmea calls it in at least 2 places: case NMEA_GPRMC: rc_date = parse_date(, , 9, DATE_1_DDMMYY) && unfold_century(, lfpuint(rd_timestamp)); case NMEA_PGRMF: rc_date = rc_date && gpsfix_century(, , >century_cache); rd_reftime = eval_gps_time(refclock_name(peer), , , (peer->cfg.mode & NMEA_DATETRUST_MASK), >epoch_warp, _timestamp); > Can you send this list a few seconds of your NMEA? $GPRMC,133400.000,A,3726.0851,N,12212.2614,W,0.00,12.81,070502,,,A*4C $GPGGA,133401.000,3726.0851,N,12212.2614,W,1,5,1.40,38.9,M,-25.7,M,,*5A $GPGSA,M,3,18,23,10,32,081.68,1.40,0.93*0E $GPGSV,2,1,08,10,64,019,26,32,64,192,27,23,37,060,16,08,37,293,31*73 $GPGSV,2,2,08,18,23,121,14,24,18,061,,21,17,312,,35,,,*45 $GPRMC,133401.000,A,3726.0851,N,12212.2614,W,0.00,12.81,070502,,,A*4D $GPGGA,133402.000,3726.0851,N,12212.2614,W,1,5,1.40,38.9,M,-25.7,M,,*59 $GPGSA,M,3,18,23,10,32,081.68,1.40,0.93*0E $GPGSV,2,1,08,10,64,019,26,32,64,192,27,23,37,060,16,08,37,293,31*73 $GPGSV,2,2,08,18,23,121,14,24,18,061,,21,17,312,,35,,75,24*74 $GPGSV,3,2,10,07,33,250,30,26,25,048,22,06,15,282,16,30,04,243,*7A $GPGSV,3,3,10,02,01,324,,49,,,*43 $GPRMC,195030.000,A,3726.0713,N,12212.2560,W,0.00,344.40,100502,,,A*75 $GPGGA,195031.000,3726.0713,N,12212.2560,W,1,7,1.15,43.8,M,-25.7,M,,*57 $GPGSA,M,3,26,03,04,06,09,07,16,,1.45,1.15,0.89*06 $GPGSV,3,1,10,04,70,030,28,16,50,086,26,09,49,314,26,03,48,175,23*73 $GPGSV,3,2,10,07,33,250,30,26,25,048,22,06,15,282,16,30,04,243,*7A $GPGSV,3,3,10,02,01,324,,49,,,*43 $GPRMC,195031.000,A,3726.0713,N,12212.2560,W,0.00,344.40,100502,,,A*74 -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
[The lists have a 2 day delay. Please be sure to cc me if you have anything helpful to contribute.] The code is in ntpd/ntp_wrapdate.c Is anybody familiar with that code? I've looked a bit but haven't figured out what is supposed to happen and/or what is going wrong. Does anybody have a device where that code is working correctly? It seems a bit strange that I'm the first one to try it so I'm wondering what I'm doing that's different/interesting. The code has a useful logging message, but that got lost with the date jumping around. logrotate moved the log file where I was looking out from under me. 20 Dec 12:22:32 ntpd[40363]: NMEA(1) Changed GPS epoch warp to -4096 weeks >From clockstats: 60252 73357.789 127.127.20.1 $GPRMC,202237.000,A,3726.0794,N,12212.2674,W,0.00, 300.06,060502,,,A*71 60252 73421.789 127.127.20.1 $GPRMC,202341.000,A,3726.0892,N,12212.2540,W,0.00, 93.98,060502,,,A*42 The "02" in 060502 is the year. That's about 20 years ago. I haven't figured out if it has wrapped once or twice but 4 is clearly wrong. The bad date is Nov 4 2023. 1024 weeks is 19.6 years. Mid 2002 +19.6 is late 2021 or early 2022. So we are close to the border between 1 and 2. There is some fudging in the code that may be getting confused in that case. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Buggy WNRO fixup
Yo Hal! On Mon, 20 Dec 2021 12:51:53 -0800 Hal Murray via devel wrote: > I have a NMEA unit that's off by 1024 weeks. Somebody is fixing it > twice. How do you know that? > Anybody know where that fixup code is located? I took a quick scan > in the NMEA driver but didn't find it. I don't think ntpd adjusts NMEA years. gpsd does, by looking at the leap second. Can you send this list a few seconds of your NMEA? RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@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 pgpBJE0o7Nx3j.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
