[LinuxPPS] gps_nmea error

[Ritter, Nicholas]

I checked today and the pulse was set to 45ms....so I set it to 200 ms
per the docs at qnan.org. I also corrected the ntp.conf item that was
noted by Hal (the minpoll 4 setting.) I also removed one ntp server on
the net as a sync source.

My current output is still having a problem because the ntp server is
not using data from the GPS for some reason, assuming I am looking at
the follow data correctly:


"ntpq -q" (on the ntp server with the GPS attached)
[root at RMSQSN1001 pps]# ntpq -p          
     remote           refid      st t when poll reach   delay   offset
jitter
========================================================================
======
xGPS_NMEA(0)     .GPS.            0 l   13   64  377    0.000  178.581
0.001
 truechimer.cso. .INIT.          16 u    -  512    0    0.000    0.000
0.000
+bonehed.lcs.mit .CDMA.           1 u   83  128  377   29.888   -4.168
1.365
*nist.netservice .ACTS.           1 u   97  128  377   12.992    2.094
0.248


"ntptime" (on the ntp server with the GPS attached)
[root at RMSQSN1001 pps]# ntptime
ntp_gettime() returns code 0 (OK)
  time cc4723c4.01875000  Fri, Aug  8 2008 14:57:56.005, (.005971),
  maximum error 239749 us, estimated error 993 us
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 289.000 us, frequency -8.123 ppm, interval 1 s,
  maximum error 239749 us, estimated error 993 us,
  status 0x1 (PLL),
  time constant 7, precision 1.000 us, tolerance 500 ppm,


"ntpdc -c kern" (on the ntp server with the GPS attached)
[root at RMSQSN1001 pps]# ntpdc -c kern
pll offset:           0.000248 s
pll frequency:        -8.123 ppm
maximum error:        0.396249 s
estimated error:      0.000993 s
status:               0001  pll
pll time constant:    7
precision:            1e-06 s
frequency tolerance:  500 ppm


running ntpd with the -d option, I see nmea gpsread lines, etc. And
don't see any "clock GPS_NMEA(0) event 'clk_fault' (0x03)" lines.

As I understand it, the ntp server will need to take time to figure out
the correct time and then additional time to sync to the correct time.
The output above is noted on the ntp server after nearly 60 minutes of
operation.

Should I set the PPS length on the GPS to 300ms? NTP troublehshooting
docs also mentioned something about using tickadj to fix the offset
issue.

Throughout all my changes, this issue has stay the same, and the offset
has always been about 178.5

BTW - Thanks for all your help thus far, and for such great software.

Nick




-----Original Message-----
From: linuxpps-bounces at ml.enneenne.com
[mailto:linuxpps-bounces at ml.enneenne.com] On Behalf Of Udo van den
Heuvel
Sent: Tuesday, August 05, 2008 9:53 AM
Cc: linuxpps at ml.enneenne.com
Subject: Re: [LinuxPPS] gps_nmea error

Ritter, Nicholas wrote:
> Aug  5 09:33:05 RMSQSN1001 ntpd[29716]: refclock_nmea: time_pps_kcbind
> failed: Operation not supported
>  
> what does this error mean?

http://wiki.enneenne.com/index.php/LinuxPPS_support#FAQs

> When I do an "ntpq -p" on the PPS/GPS ntp server I see the following:
(...)
> Am I understanding correctly that the GPS source is working, but 
> something about the PPS source is not?

Possibly.
I assume you set the PPS pulse to 300 ms?

> Am I also correct in assuming
> that it could be a config problem in ntp.conf, or is it somewhere
else?

Could be. Please verify reception first.
Then verify PPS using minicom. (assume pps on DCD) Check polarity, maybe
inverse or change config for up/down edge.

Udo

_______________________________________________
LinuxPPS mailing list
LinuxPPS at ml.enneenne.com
http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support