The GPS on 100m seems to be acting weird. It has
...
has signal lock,
...
currently
...
slowing
...
9
...
or
...
10
...
satellites:
rs G
connecting to inet:localhost.localdomain:30002
connected to inet:localhost.localdomain:30002
sent:"/var/tmp/gps_pty0
"
line="OK"
parameters: 4800 none 8 1 "\n" 1 0 prompted=false
$GPRMC,152515,A,4003.0021,N,10500.2309,W,000.0,240.5,010415,008.9,E*68\r\n
$GPGGA,152515,4003.0021,N,10500.2309,W,2,10,1.0,1690.0,M,-18.0,M,,*46\r\n
$GPRMC,152516,A,4003.0021,N,10500.2309,W,000.0,240.5,010415,008.9,E*6B\r\n
$GPGGA,152516,4003.0021,N,10500.2309,W,2,09,1.0,1690.0,M,-18.0,M,,*4D\r\n
$GPRMC,152517,A,4003.0021,N,10500.2309,W,000.0,240.5,010415,008.9,E*6A\r\n
$GPGGA,152517,4003.0021,N,10500.2309,W,2,08,1.9,1690.0,M,-18.0,M,,*44\r\n
...
But its NTP offset has been wandering around. I added 50m as an NTP server for it, and its the GPS clock on 100m is disagreeing with 50m:
| Code Block | ||
|---|---|---|
| ||
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.0.5 .GPS. 1 u 45 64 377 0.946 118.340 33.872
LOCAL(0) .LOCL. 10 l 64 64 3 0.000 0.000 0.031
oGPS_NMEA(0) .GPS. 0 l 15 16 377 0.000 -849.69 347.187 |
...
On flux, chronyc shows that the clock for 100m is off from the others:
| Code Block | ||
|---|---|---|
| ||
chronyc sources 210 Number of sources = 6 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* 50m 1 10 377 321 -125ns[ +15us] +/- 733us ^- 100m 1 6 77 35 +90ms[ +90ms] +/- 1570ms ^+ 150m 1 10 377 535 +6715ns[ +20us] +/- 619us ^+ 200m 1 10 377 476 -4792ns[+9000ns] +/- 831us ^+ 250m 1 10 377 497 +4392ns[ +18us] +/- 857us ^+ 300m 1 10 377 252 +2000ns[+2000ns] +/- 656us |
...
Comparing the output of "data_dump i 2,10 A" on 100m with that from 50m shows intermittent data gaps of 1.269 seconds, whereas with 50m the two GPS records ($GPRMC, and $GPGGA) are reporting at 1 Hz, with quite consistent delta-Ts close to 0.85 and 0.15.
...
| Code Block |
|---|
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
+192.168.0.5 .GPS. 1 u 61 64 377 0.941 -0.204 0.056
LOCAL(0) .LOCL. 10 l 42m 64 0 0.000 0.000 0.000
oGPS_NMEA(0) .GPS. 0 l 4 16 377 0.000 -0.118 0.031
|
So it appears that the serial data from the 100m GPS (which provides the time label for the precise pulse-per-second) was late from time to time, resulting in NTP having to struggle to figure out what time it is. So, for data up to today, I would not rely on the 100m data to have time-tags with any accuracy below 1 second. D'oh...