[LinuxPPS] test of 2.6.20-g15c540a8

[Rodolfo Giometti]

On Thu, Feb 22, 2007 at 07:03:22PM -0800, gnu not unix wrote:
> 
> Well the gps/pps hardware and the motherboard all were
> working fine with a previous linuxpps version. 

I know it, but we have to be sure about the software settings.

> 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

It seems ok... all PPS events are correctly reported.

> 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.

Offsets are reported in microseconds?

With a previous version of LinuxPPS did you get the same numbers of
assert and clear events?

It seems that for a sort of strange reason the interrupt reporting is
misconfigured... :-/

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127