|RE: [chrony-users] kernel PPS troubleshooting|
[ Thread Index |
| More chrony.tuxfamily.org/chrony-users Archives
On Thursday, November 28, 2013 6:15 AM Miroslav Lichvar wrote:
>On Wed, Nov 27, 2013 at 04:06:58PM -0500, Battocchi, Scott L. wrote:
>> I ran the GPS while connected to a handful of ntp servers and saw that my gps offset (originally 0.180) was too low, so I bumped it up to 0.530 for the next two tests. I've attached plots of the offset as recorded in the statistics.log file, if there are other metrics that would be useful I'm happy to graph them and send them out.
>> ntp.png is with 5 pool servers and the GPS set to noselect (PPS is not
>> locked to anything, but is selectable) gps.png is after the ntp test but back to just using the GPS and PPS, it looks like sometimes GPS gets selected as the source forcing the PPS signal to look like it is drifting relative to the system.
>That looks similar to what I see with with a Garmin 18x LVC. This is a capture 30 hours long I did some time ago (the NMEA source's offset value was set to 0.5):
>Since gpsd has added support for kernel PPS, I think it's better to use the SHM 1 or SOCK source instead of PPS. Let it handle the HW details and pair the PPS and NMEA samples.
I could not see how to get GPSD to associate a kernel PPS source (our /dev/pps1 is driven by the PPS-GPIO kernel module and does not come in through the serial port's DCD line) with a NMEA source. Without a PPS signal coming into GPSD I didn't seem to get any data into chrony through the SOCK interface even though GPSD did see and successfully connect to it according to the GPSD debug output.
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.