[LinuxPPS] test of 2.6.20-g15c540a8

[gnu not unix]

In message <20070222223154.GE13924 at enneenne.com> you write:

>Time to enable debugging messages...

>First of all we should verify that the PPS signal arrives well then we
>can continue to investigate.

Well the gps/pps hardware and the motherboard all were
working fine with a previous linuxpps version. 

Anyways here's what the results of turning on debugging show.

A ppstest run:

root at boomer.wraith.sf.ca.us[516] ./ppstest 
found PPS source #0 "serial0" on "/dev/ttyS0"
assert 0.000000000, sequence: 0 - clear  1172194987.489511876, sequence: 11
assert 0.000000000, sequence: 0 - clear  1172194988.489516066, sequence: 12
assert 1172194989.485581045, sequence: 1 - clear  1172194988.489516066, sequence: 12
assert 1172194989.485581045, sequence: 1 - clear  1172194989.486946465, sequence: 13

Hm, and here's the corresponding debug:

8250: serial8250: PPS clear event at 4294966547 on source #0
pps_core: start sending reply to ID 1283...
pps_core: ... reply sent (180)
pps_core: New message from PID 1283 (flags 0)
pps_core: PPS_FETCH: source 0
pps_core: capture clear seq #12 for source 0
8250: serial8250: PPS clear event at 4294966647 on source #0
pps_core: start sending reply to ID 1283...
pps_core: ... reply sent (180)
pps_core: New message from PID 1283 (flags 0)
pps_core: PPS_FETCH: source 0
pps_core: capture assert seq #1 for source 0
8250: serial8250: PPS assert event at 4294966746 on source #0
pps_core: start sending reply to ID 1283...
pps_core: ... reply sent (180)
pps_core: New message from PID 1283 (flags 0)
pps_core: PPS_FETCH: source 0
pps_core: capture clear seq #13 for source 0


The assert shows up.

And ntpd seems to think things are sort of ok:

Feb 23 02:02:20 boomer ntpd[1617]: 
    refclock_nmea: found PPS source "/dev/ttyS0" at id #0 on "serial0"
Feb 23 02:02:20 boomer ntpd[1617]: 
    refclock_nmea: time_pps_kcbind failed: Operation not supported
Feb 23 02:02:20 boomer ntpd[1617]: 
    refclock: found PPS source #0 "/dev/ttyS0" on "serial0"
Feb 23 02:02:21 boomer ntpd[1617]: 
    frequency initialized -0.566 PPM from /var/ntp/ntp.drift

Here's what dmesg shows shortly after ntpd started:

8250: serial8250: PPS assert event at 128048 on source #0
pps_core: capture clear seq #165 for source 0
8250: serial8250: PPS clear event at 128048 on source #0
pps_core: New message from PID 1617 (flags 0)
pps_core: PPS_FETCH: source 0
pps_core: start sending reply to ID 1617...
pps_core: ... reply sent (180)
pps_core: New message from PID 1617 (flags 0)
pps_core: PPS_FETCH: source 0
pps_core: start sending reply to ID -4098...
pps_core: ... reply sent (180)
pps_core: capture assert seq #137 for source 0
8250: serial8250: PPS assert event at 128148 on source #0
pps_core: capture clear seq #166 for source 0
8250: serial8250: PPS clear event at 128148 on source #0

An ntpd run seems to show events ok:

root at boomer.wraith.sf.ca.us[580] ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+SPECTRACOM(0)   .WWVB.           0 l   28   64  377    0.000   -0.824   4.089
+GPS_NMEA(0)     .GPS.            0 l    4   64  377    0.000   -1.431   0.008
oPPS(0)          .PPS.            0 l    1   16  377    0.000   -0.066   0.008
xWWV_AUDIO(0)    .WV2.            0 l  107   64  364    0.000  -28.239  24.931
-wraith.wraith.s .PPS.            1 u    2   16  377    0.147   -0.070   0.008
-ring.wraith.sf. .GPS.            1 u    1   16  377    0.120   -0.056   0.008
-thrall.wraith.s .GPS.            1 u    2   16  377    0.200   -0.026   0.035
-smidge.wraith.s .GPS.            1 u    1   16  377    0.270   -0.036   0.008

The nmea offset is bad, though. It should be the same, or within 
a couple of microseconds, as the pps refclock.

../Steven