> TOFF
> <dictwrapper: {u'clock_sec': 1570384595, u'class': u'TOFF', u'device':
> u'/dev/ttyUSB0', u'real_sec': 1570384595, u'clock_nsec': 109164451,
> u'real_nsec': 249441}>
Looking good, you just need the PPS.
Some further progress today. Instead of two separate serial ports (one for data, one for PPS) I now wired the 1PPS to the DCD-pin of the data port.
With one single serial port with data+pps there is no need for creating the pps-device manually (ldattach), as Gary noted before.
But how do I now check the PPS using ppswatch/ppstest? I don's see a /dev/pps0 or similar.
This helped, and gpsd now also reports a PPS JSON-message, containing the qErr from UBX-TIM-TP.
2019-10-08 15:49:34.000544 PPS real: 1570549774 . 0 clock: 1570549774 . 95427 qerr: 3682
2019-10-08 15:49:34.272920 PPS real: 1570549774 . 0 clock: 1570549774 . 95427 qerr: 3682
2019-10-08 15:49:34.274857 RAW 1570549774
2019-10-08 15:49:34.275353 TPV 2019-10-08T15:49:34.000Z
2019-10-08 15:49:34.275527 TOFF real: 1570549773 . 999885061 clock: 1570549774 . 272994215
2019-10-08 15:49:35.000579 PPS real: 1570549775 . 0 clock: 1570549775 . 105716 qerr: -226
2019-10-08 15:49:35.272838 PPS real: 1570549775 . 0 clock: 1570549775 . 105716 qerr: -226
2019-10-08 15:49:35.275126 RAW 1570549775
2019-10-08 15:49:35.275743 TPV 2019-10-08T15:49:35.000Z
2019-10-08 15:49:35.275961 TOFF real: 1570549774 . 999884667 clock: 1570549775 . 272936300
--and so on, with occasional SKY----
The PPS-message appears repeated (with identical content), both close to the inter-second boundary, and at around +270ms (the length of the electrical pulse should be 100ms, as before)
This might be related to the cycle-start detector warning I see on gpsd?
gpsd:WARN: cycle-start detector failed.
(repeated once per second)
any ideas?
if it makes any difference, ntpq-output is below, with zero fudge in ntp.conf. The machine is synchronized to many stratum-1/2 servers.
gpspipe -w only shows one PPS-message per second. I don't understand why gpspipe -w and my python code give different results (1 vs 2 PPS JSON messages per second)
$ gpspipe -wPt | grep PPS
2019-10-08 16:09:41: {"class":"PPS","device":"/dev/ttyUSB1","real_sec":1570550981,"real_nsec":0,"clock_sec":1570550981,"clock_nsec":88924,"precision":-10,"qErr":2193}
2019-10-08 16:09:42: {"class":"PPS","device":"/dev/ttyUSB1","real_sec":1570550982,"real_nsec":0,"clock_sec":1570550982,"clock_nsec":99353,"precision":-10,"qErr":-1399}
2019-10-08 16:09:43: {"class":"PPS","device":"/dev/ttyUSB1","real_sec":1570550983,"real_nsec":0,"clock_sec":1570550983,"clock_nsec":90260,"precision":-10,"qErr":3584}
2019-10-08 16:09:44: {"class":"PPS","device":"/dev/ttyUSB1","real_sec":1570550984,"real_nsec":0,"clock_sec":1570550984,"clock_nsec":115234,"precision":-10,"qErr":184}
I am now collecting time-interval-counter data together with qErr data, to see how they line up and if correcting the counter data with qErr will work.
Anders
$ gpsd -V
gpsd: 3.19.1~dev (revision release-3.19-661-g66c711e09)
----------------------
$ ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.28.0 .GPS. 0 l 7 8 377 0.000 -272.74 2.305
127.127.28.1 .PPS. 0 l 6 8 377 0.000 -0.105 0.011