Here's more information.  As you both suggested, gpsd is feeding bad time to 
chronyd.

Starting chrony with the -s option, it still sets the clock to 1999-08-22. 
Presumably the drift file had the time set incorrectly in a previous run: 
$ cat /var/lib/chrony/chrony.*
72.210307        196.256213
1 946684999 11404807.826058 -20.250

Before getting a lock, ublox NMEA strings are reporting no fix, and V (void) 
status, as expected. 

Plug in antenna. Momentarily ublox reports incorrect time (with status=void so 
it should be ignored.)  It looks like gpsd accepts this invalid time as valid, 
and passes it along through the SHM to chronyd.  
{"class":"VERSION","release":"3.11","rev":"3.11-3","proto_major":3,"proto_minor":9}
{"class":"DEVICES","devices":[{"class":"DEVICE","path":"/dev/ttyS4","driver":"u-blox","subtype":"1.00
 
(59842)","activated":"1999-08-22T00:05:50.163Z","flags":1,"native":1,"bps":9600,"parity":"N","stopbits":1,"cycle":1.00,"mincycle":0.25}]}
{"class":"WATCH","enable":true,"json":true,"nmea":true,"raw":0,"scaled":false,"timing":false,"split24":false,"pps":false}
<snip>
$GPRMC,000000,V,0000.0000,S,00000.0000,W,0.0000,0.000,000000,,*35
$GPGSA,A,1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,*32
{"class":"TPV","tag":"0x0106","device":"/dev/ttyS4","mode":1}
$GPRMC,000000,V,0000.0000,S,00000.0000,W,0.0000,0.000,000000,,*35
$GPGSA,A,1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,*32
{"class":"TPV","tag":"0x0106","device":"/dev/ttyS4","mode":1}
$GPRMC,000928,V,0000.0000,S,00000.0000,W,0.0000,0.000,220899,,*3E
$GPGSA,A,1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,*32
{"class":"TPV","tag":"0x0106","device":"/dev/ttyS4","mode":1,"time":"1999-08-22T00:09:28.000Z","ept":0.005}
$GPRMC,000929,V,0000.0000,S,00000.0000,W,0.0000,0.000,220899,,*3F
$GPGSA,A,1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,*32
{"class":"TPV","tag":"0x0106","device":"/dev/ttyS4","mode":1,"time":"1999-08-22T00:09:29.000Z","ept":0.005}
<snip>
$GPRMC,000946,V,0000.0000,S,00000.0000,W,0.0000,0.000,181216,,*33
$GPGSA,A,1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,*32
{"class":"TPV","tag":"0x0106","device":"/dev/ttyS4","mode":1,"time":"2016-12-18T00:09:46.000Z","ept":0.005}
$GPRMC,000947,V,0000.0000,S,00000.0000,W,0.0000,0.000,181216,,*32
$GPGSA,A,1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,*32
{"class":"TPV","tag":"0x0106","device":"/dev/ttyS4","mode":1,"time":"2016-12-18T00:09:47.000Z","ept":0.005}
<snip>
$GPRMC,001001,V,0000.0000,S,00000.0000,W,0.0000,0.000,181216,,*38
$GPGSA,A,1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,*32
{"class":"TPV","tag":"0x0106","device":"/dev/ttyS4","mode":1,"time":"2016-12-18T00:10:01.000Z","ept":0.005}
$GPZDA,001001.96,18,12,2016,00,00*66
$GPGGA,001001,4112.0521,S,17402.1451,E,1,03,99.99,-1.51,M,16.510,M,,*46
$GPRMC,001001,A,4112.0521,S,17402.1451,E,0.0146,180.000,181216,,*36
$GPGSA,A,2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,100.0,100.0,100.0*32
{"class":"TPV","tag":"0x0106","device":"/dev/ttyS4","mode":2,"time":"2016-12-18T00:10:01.964Z","ept":0.005,"lat":-41.XXXXXXXXX,”lon":174.XXXXXXXXX,”track":180.0000,"speed":0.008,"eps":1.05}

$ sudo chronyd -d
2000-01-01T00:01:29Z chronyd version 2.4 starting (+CMDMON +NTP +REFCLOCK +RTC 
-PRIVDROP -SCFILTER -SECHASH +ASYNCDNS +IPV6 +DEBUG)
2000-01-01T00:01:29Z Setting filter length for PPS to 1
2000-01-01T00:01:29Z Setting filter length for NMEA to 2
2000-01-01T00:01:29Z Frequency 72.210 +/- 196.256 ppm read from 
/var/lib/chrony/chrony.drift
2000-01-01T00:01:29Z Using right/UTC timezone to obtain leap second data
2000-01-01T00:01:36Z Selected source NMEA
2000-01-01T00:01:36Z System clock wrong by -11404807.826524 seconds, adjustment 
started
1999-08-22T00:01:28Z System clock was stepped by -11404807.826524 seconds
1999-08-22T00:01:34Z System clock wrong by -0.025077 seconds, adjustment started
1999-08-22T00:01:38Z Can't synchronise: no selectable sources


Even though time from GPS can be accurate to within a few seconds prior to 
getting a fix (for example when tracking only one SV), for my application it 
would be safer to require that mode >= "2D fix" before accepting the time as 
valid. It seems like this would have to be done in gpsd, not in chrony. Only 
gpsd knows the validity of the timestamp prior to putting it in SHM. 

I'm happy to patch the gpsd code to do this, but it feels like there should be 
another way to handle this. If I were using only the $GPZDA messages (which 
come out only after 2D fix) then that might get around the problem.  But for 
this application, I do need position data as well, so that doesn't work.

--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Reply via email to