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 connects).
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.
Simon.