Re: [chrony-users] gpsd with no rtc and no network

[Brian Kuschak <bkuschak@xxxxxxxxx>]

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-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.