On Mon, Sep 11, 2017 at 3:39 PM Denny Page <dennyp...@me.com> wrote:
> A few things come to mind:
> - You didn’t include any information about your gpsd configuration.
The GPS device is a UBlox LEA 6S connected via a CP210X UART-to-USB bridge
to a USB port and is mounted as /dev/ttyUSB0. The daemon starts with 'gpsd
/dev/ttyUSB0 -n' (the -n flag starts decoding messages before a client
The PPS is wired into a GPIO pin and is mounted as /dev/pps0. When the GPS
is discovered by gpsd, it creates a second PPS source as /dev/pps1 (using
the line discipline driver), but because this source is backed by USB, it
never pulses. I have confirmed that /dev/pps0 is the correct source for the
GPIO pin, as the ppstest log shows, and that /dev/pps1 times out. It is
/dev/pps0 that is in the chrony.conf.
- With the approach you are taking, you have to start gpsd before you start
> chronyd. Are you?
I've experimented with changing the order in which gpsd and chronyd start
with no success. If I remove the 'noselect' option from the NMEA refclock,
chrony will synchronise to the GPS time, but the PPS refclock is never
polled (reach = 0). I've let chrony synchronise the system time to NMEA,
killed the chronyd daemon, and then restarted it with the 'noselect' option
restored (to discard the possibility that the large time delta from
1970-01-01T00:00:00 may be confusing chrony), but no success.
> - Are you sure you are looking at the right PPS device? There may be PPS
> devices for other PPS sources such as network interface cards.
I can see the PPS working as expected with ppstest and have ensured both
gpsd and chronyd are configured with the right devices.
Are there any more debugging options I can invoke to get a better
understanding as to why chrony is ignoring the PPS pulses? Thanks.