Q1) Running my NTPD driver I see in the log messages:
[ntpd] refclock_nmea: time_pps_kcbind failed: Operation not supported
Is that an implementation bug?
A1) No. The function time_pps_kcbind() is defined as “optional” into RFC 2783 and, simply, LinuxPPS doesn't implement it! :)
Userland programs which wish to use it should take this fact into account.
Q2) How can I verify that my NTPD (or just the ppstest program) is reading the PPS data from LinuxPPS?
A2) If you enable the kernel debugging messages you should see something as follow:
pps_core: capture assert seq #292 for source 0 8250: serial8250: PPS assert event at 420817
This is the capture event from the GPS and saved by LinuxPPS.
pps_core: capture clear seq #292 for source 0 8250: serial8250: PPS clear event at 420942
This is the clear event from the GPS and saved by LinuxPPS. Also we can see that 420942-420817=125 which is OK if PPS duty cycle is 50% and the Linux's clock (HZ variable) is set to 250 ticks per second.
pps_core: New message from PID 5205 (flags 0) pps_core: PPS_FETCH: source 0
Here the userland application with PID 5205 (NTPD or ppstest) is reading PPS data from LinuxPPS.
Note: sometimes (and especially for serial ports) you may need to keep opened the serial line in order to enable kernel interrupts registration, in order to do that you may use the command cat /dev/ttyS0 on a different terminal.
Q3) OK, I see /dev/lp0 and/or /dev/ttyS0 down in /sys/class/pps, but I thought there also was supposed to be an entry in /proc. I don't see anything there! Why?
A3) Because the procfs (/proc directory) support in latest kernel releases is deprecated and LinuxPPS doesn't use it.
Q4) There is an entry in /sys/class/pps/pps0/name of serial0 what is this? The actual name of the device is in path.
A4) Into name file there is the driver's name while into path one there is the device's path name.
Q5) Who can fix that wiki documentation for me?
A5) Please email Udo van den Heuvel via the LinuxPPS mail list.