- 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?
- 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.
- How can I verify that my NTPD (or just the
ppstestprogram) is reading the PPS data from LinuxPPS?
- 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=125which is ok if PPS duty cycle is 50% and the linux's clock (
HZvariable) 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.
- OK, I see
/sys/class/pps, but I thought there also was supposed to be an entry in
/proc. I don't see anything there! Why?
/procsupport for Linux 2.6. It's deprecated!
- There is an entry in
serial0what is this? The actual name of the device is in
namethere is the driver's name while into
paththere is the device's path name.
- Who can fix that wiki documentation for me?
- Please email Udo via the LinuxPPS mailinglist.