[LinuxPPS] gps_nmea error

Hal V. Engel hvengel at astound.net
Fri Aug 8 23:56:07 CEST 2008 

On Friday 08 August 2008 01:05:25 pm Ritter, Nicholas wrote:
> I checked today and the pulse was set to 45ms....so I set it to 200 ms
> per the docs at qnan.org. 

200 milliseconds is more than long enough.  Many refclocks like the Motorola 
OnCore only have a 200 millisecond pulse and it can't be changed.  Some 
refclocks only have a 100ms pulse.  The pulse just needs to be long enough 
that it will always cause an interupt when it pulls the DCD line high or low 
(depending on how you have this setup).

> I also corrected the ntp.conf item that was
> noted by Hal (the minpoll 4 setting.) 

This was a very minor thing and was not affecting how this was wroking.

> 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

Your offset is fairly close to 200 milliseconds and it is my understanding 
that the pulse widths of the PPS signals from most of these devices are 
typically not very accurate.   I know for my refclock that the vendors docs 
warn about this.   It could very well be that the pulse is actually around 178 
milliseconds when set to 200 which is about an 11% error.  In addition, the 
difference between your refclock and the external time servers has increased 
from around 25ms when you had the pulse width set to 30ms to about 178ms with 
a 200ms settings which I think confirms that you are triggering on the wrong 
edge of the pulse.  That is the offset is amost = the pulse width for two very 
different pulse widths.   For my refclock I can set which edge of the pulse it 
uses by setting either ASSERT or CLEAR in the config file for the refclock to 
correct for things like the pulse being inverted.  I don't know if your 
refclock driver has something like this.

One way to check this would be to stop ntpd and use ppstest to have a look at 
your PPS signals.  These will come through time stamped so you can see what 
these look like.  If the CLEAR is about 200 milliseconds before the next 
ASSERT then it is inverted.  If it is not inverted then you will see the 
ASSERT about 200ms before the next CLEAR.

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

If you are running kernel 2.6.26-rc8 or later it is a nanokernel and the 
status line above should say (PPL, NANO) and precision should say 0.001 us.  
My guess is that ntp was not built correctly for this setup.  This is probably 
not the cause of the 178.xxx millisecond offset but you should fix it.  There 
are notes on the list archive that give details on how to get ntp built 
correctly with a nanokernel.

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

It should have the correct time figured out in a few minutes but it can take 
some for the clock to stabilize.  My machine will have an offset of perhaps 10 
microseconds (0.010) one hour after start up as long as the clock was only a 
few milliseconds off at ntpd start up and the machine is not being loaded up 
and temperatures are stable. But even under the worst conditions at the 1 hour 
point it will have an offset well under 0.2 millisecond.  So your 178ms offset 
is definitely a problem.

>
> Should I set the PPS length on the GPS to 300ms? 

200ms is more than long enough.   Although if you changed it to 300ms and your 
offset increased by about 100ms it would confirm that you are using the wrong 
edge of the pulse.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.enneenne.com/pipermail/linuxpps/attachments/20080808/2e84498b/attachment-0001.htm

More information about the LinuxPPS mailing list