[ntp:questions] very confusing results though using pps and nmea

Unruh unruh-spam at physics.ubc.ca
Tue Aug 12 03:13:02 UTC 2008

nb at komeda-berlin.de (Nicola Berndt) writes:


>Some might recall I asked some questions here and disappeared before 
>getting my hands dirty. - Sorry for that, I had to go to hospital for a 
>while and didn't touch the ntp-server project since. So now I'm back and 
>everything is fine!

>First of all I am trying to understand what is actually happening inside 
>the computer, time-wise.

>So I set up a nmea-driver using a u-blox usb-gps-device with the 
>standard nmea driver and I set up a pps-device via the serial port using 
>the atom driver and the linuxpps kernel-patch found in the enneenne wiki 
>here: http://wiki.enneenne.com/index.php/LinuxPPS_support

>Now using the following ntp.conf I can see that things are working, but 
>not as expected. I would expect the pps clock to take over, no matter 
>what happens, since I understand it is either there or not and it can't 
>be wrong. Instead my system randomly marks either of these a false 
>ticker every now and then..

Actually the pps CAN have noise on the line. I have found with my Garmin
18LVM that sometimes the interrupt fires of 6 or 7 hits in a few
milliseconds,-- some sort of line noise coming in. Now, it is I admit a bit
of a kludge and I have not bothered to track down the problem-- bad solder
joint, TV interference,.....-- but it happens. 

What is best if you can record say a days worth of interrupt timings
without haing the pps discipline your clock, and look at, or rather plot (
since looking at 86400 entries is liable to fry your brain) to see if you
are getting glitches-- noise tends to occur randomly so plotting
t_{i+1}-t_i over the day will show you if glitches have occured. If they
differ from 1 second according to your computer clock ( and you have left
your computer clock just rinning and not resetting it suddenly-- even ntp
running on the outside sources is fine since it shifts the time slowly)
then you have noise. 
Note that serial port nmea is liable to be out by up to 1/2 sec and to have
a lot ( 10s of msec) jitter on it, since the end of the string received by
a slow serial port ( eg at 4800Bd, it takes an nmea sentence of about 60
characters 1/8 of a second to be delivered and will have a jitter of few
characters in length-- or about 10ms jitter).

>Here the ntp.conf:
># PPS
>server minpoll 4 maxpoll 4
>fudge flag2 0

># NMEA GPS driver for u-blox receiver
>server prefer minpoll 4
>fudge flag3 0 flag2 0 time1 0.0

>server 0.debian.pool.ntp.org iburst
>server 1.debian.pool.ntp.org iburst

>The output of ntpq -p changes offset and jitter values in large ranges 
>for every source, also something that I can't believe to be true..

>      remote           refid      st t when poll reach   delay   offset 
>  jitter
>xPPS(0)          .PPS.            0 l    6   16   77    0.000  258.904 
>*GPS_NMEA(0)     .GPS.            0 l    7   16  377    0.000  -263.23 
>xnetzwerkteufel.   2 u    7   64  177   23.019  -159.57 
>xceres.sternbaue    2 u   59   64   77   48.554  -133.36 

>What am I doing so badly wrong? Can anyone help?

>Best regards,
>../nico berndt

More information about the questions mailing list