[LinuxPPS] PPS Setup problems

Fri Feb 15 11:20:22 CET 2008

Hi,
I have been trying to get NTP+PPS working on a new machine, using the info
on wiki.enneenne.com
(Garmin GPS module with PPS output + Centos 5 x86_64).
I've previously had the GPS hardware & PPS working perfectly on a rather
older system, which is now defunct.

My first attempt was some weeks ago, based on the 2.6.23.1 kernel (& NTP
4.2.4p2).

I followed all instructions carefully, had good NMEA data on ttyS1 and the
ppstest shows a valid PPS signal.

Everything appeared to work, except there was never any sign that the PPS
signal was being used - ntptime always showed 'status 0x1 (PLL)' 
The offset and jitter settled to 1uS and stayed there, but I thought the
ntptime output should show a change when the PPS system was in lock.

The only minor oddity on that setup was that the GPS was on ttyS1 rather
than ttyS0 which the examples use. (I had a UPS on ttyS0). 

Earlier this week I reconfigured things & exchanged the ports, which seemed
to mess it up completely - no 'reach' although minicom & ppstest showed the
appropriate data was present.

I started again from scratch with kernel 2.6.24.2 & the appropriate patch
from the wiki.

Note for docs: Using my previously 'working' kernel config [via make
oldconfig] which had the PPS stuff built in, I no longer got the PPS device.
Switching to modules so everything exactly matched the Wiki examples fixed
this.

I get NMEA data on ttyS0 and ppstest shows the PPS signal.

All the include links to the new kernel & the timepps.h file set up as per
the docs.

NTP rebuilt from a clean source & patched with nmea.patch (still 4.2.4p2 as
that's the latest mentioned in relation to the patch).

It almost works...
NTPD runs and appears to be pulling into lock; the error & jitter steadily
reduce for some hours.
(I know the maxpoll 4 is not a good idea for actual operation, that is
purely for testing.)
(Local hostnames replaced with IPs; others are uk.pool.ntp.org servers)

Around seven hours after starting:

ntptime
ntp_gettime() returns code 0 (OK)
  time cb5f4b06.ffaf0000  Thu, Feb 14 2008 23:19:34.998, (.998764),
  maximum error 7181 us, estimated error 1 us
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -2.000 us, frequency 94.075 ppm, interval 1 s,
  maximum error 7181 us, estimated error 1 us,
  status 0x1 (PLL),
  time constant 4, precision 1.000 us, tolerance 512 ppm,

ntpq -c peers
     remote           refid      st t when poll reach   delay   offset
jitter
============================================================================
==
*GPS_NMEA(0)     .PPS.            0 l   15   16  377    0.000   -0.003
0.001
 192.168.0.5     192.168.0.1      2 u   17   16  376    0.152   -0.123
0.019
 192.168.0.6     192.168.0.1      2 u    5   16  377    0.185    0.146
0.022
+dns1.rmplc.co.u 131.188.3.221    2 u   10   64  377   34.968    1.046
0.888
-cobra.first4it. 130.88.200.6     3 u   54   64  377   40.110    5.738
1.126
+ntp4.ja.net     .DCFa.           1 u   37   64  377   31.889    0.867
0.308

It then seems to hit some critical point where is should be in PPS lock, and
loses it..

ntptime
ntp_gettime() returns code 0 (OK)
  time cb5fba07.f96c8000  Fri, Feb 15 2008  7:13:11.974, (.974312),
  maximum error 1331 us, estimated error 16 us
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 307.000 us, frequency 92.900 ppm, interval 1 s,
  maximum error 1331 us, estimated error 16 us,
  status 0x1 (PLL),
  time constant 4, precision 1.000 us, tolerance 512 ppm,

ntpq -c peers
     remote           refid      st t when poll reach   delay   offset
jitter
============================================================================
==
*GPS_NMEA(0)     .PPS.            0 l    3   16  377    0.000    0.309
0.008
 192.168.0.5     192.168.0.1      2 u   13   16  376    0.150    0.302
0.071
 192.168.0.6     192.168.0.1      2 u   11   16  377    0.216   -0.206
0.025
+dns1.rmplc.co.u 195.66.241.3     2 u   64   64  376   34.956    1.952
102.456
-cobra.first4it. 130.88.200.6     3 u   28   64  377   40.025    5.289
90.079
+ntp4.ja.net     .DCFa.           1 u   28   64  377   33.308    1.865
74.438

and a bit later

ntptime
ntp_gettime() returns code 0 (OK)
  time cb5fcc6b.ca461000  Fri, Feb 15 2008  8:31:39.790, (.790132),
  maximum error 4774 us, estimated error 1260 us
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 492.000 us, frequency 93.468 ppm, interval 1 s,
  maximum error 4774 us, estimated error 1260 us,
  status 0x1 (PLL),
  time constant 4, precision 1.000 us, tolerance 512 ppm,

ntpq -c peers
     remote           refid      st t when poll reach   delay   offset
jitter
============================================================================
==
*GPS_NMEA(0)     .PPS.            0 l    8   16  377    0.000    0.506
0.143
 192.168.0.5     192.168.0.1      2 u    9   16  376    0.201   -1.013
0.064
 192.168.0.6     192.168.0.1      2 u   13   16  376    0.137   -4.034
0.105
+dns1.rmplc.co.u 195.66.241.3     2 u   54   64  377   35.057    1.886
28.252
-cobra.first4it. 130.88.200.6     3 u   45   64  377   40.153    6.976
9.687
+ntp4.ja.net     .DCFa.           1 u   18   64  377   32.946    2.052
54.804 

This is the same hardware that ran for weeks with both offset & jitter 0.001
so it's presumably the PPS / NTP setup.
Note - I could not get the udev setup to work with pps & 8250 built as
modules, so these are loaded & symlinks set etc. in rc.local
I'm manually starting NTPD so I can verify PPS & NMEA data are present
beforehand.

I rebuilt the whole lot again from scratch yesterday in case I'd missed
something, and ended up with the same result as earlier in the week.

Any ideas please?

Thanks,
Robert.