On 25/01/2021 16:33, Jim Pennino wrote: []
But the PPS has a lot of jitter. Note the xPPS(0) in the ntpq line.
[]> The default for NTP is 4800 baud, but I am running at 9600 and there is
no loss of data. It doesn't make any difference if I run the 20 driver in mode 1 (lower bits) or 13, it still has the uncorrectable offset problem. Right now, having been running for a little over 12 hours, ntpq shows: x127.127.20.0 .GPS. 0 l 14 16 335 0.000 -761.21 307.138 *127.127.28.0 .SHM. 0 l 12 16 377 0.000 -30.575 35.029 o127.127.22.0 .PPS. 0 l 3 16 377 0.000 -0.378 0.034 I'm going to let it run for several days without disturbing anything. I doubt it will keep the 28 clock selected with that high jitter.
If the PPS has a lot of jitter I would try to check it with an oscilloscope. Possibly there is a poor connection, or if you are using a very long cable (unlikely) there could be capacitive coupling between signals. How did you correct the problem for your "over 12 hours" ntpq report? I would suggest a much higher baud rate, and disabling sentences other than $GPRMC. You don't then need any lower bits set. Are you sure that the type 20 and type 28 driver can co-exist? I note that minicom can't access ttyAMA0 when gpsd is using it. From data I'm recording from another GPS I see offsets between -100 and +100 milliseconds from a nominal, with an older Skylab SKG16B device running at 9600 baud. Cheers, David -- SatSignal Software - Quality software for you Web: https://www.satsignal.eu Email: [email protected] Twitter: @gm8arv _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
