[ntp:questions] Adjusting PPS offset

A C agcarver+ntp at acarver.net
Sun Sep 4 19:13:31 UTC 2011


On 9/4/2011 11:15, Chris Albertson wrote:
> On Sat, Sep 3, 2011 at 10:27 PM, unruh<unruh at wormhole.physics.ubc.ca>  wrote:
>> On 2011-09-04, Chris Albertson<albertson.chris at gmail.com>  wrote:
>>> On Sat, Sep 3, 2011 at 4:34 PM, A C<agcarver+ntp at acarver.net>  wrote:
>>>
>>>> What I meant was what method is the best way to determine the value of
>>>> time1.
>>>
>>>
>>> That is what I meant above when I said, setting it is easy.  Knowing
>>> what to set it the is the hard part.  The simplest way is to connect
>>> with a few pool servers then "Fudge" your GPS' time for best match to
>>> the Internet servers.
>>
>> Since the pool servers are a few orders of magnitude worse than PPS,
>> that would not be a vary useful way.
>
> There are two kinds of accuracy  One is what I think NTP calls
> "jitter". This is the randomness about the "tick".   The other is the
> absolute phase of the PPS.    A directly connected GPS will have very
> low jitter but there is zero reason to assume its absolute phase is
> "better" or more accurate then an Internet pool server.    In fact on
> a newly connected GPS I'd suspect the phase is not correct, not until
> I measure it.
>
> There are a few reasons a GPS might have the phase as wrong as 1/2 second.
> (1) Your GPS unit was not designed to have PPS fall on the exact UTC
> second.  I think many navigation GPS are like this.  Read the user
> manual.  Many don't even have this in their specification.  These
> units claim to have a pure every second but make no claim about WHEN
> current the second to pulse occurs..  READ the user manual carfully.
> (2) You may have the polarity backwards.  Remember that RS232 uses
> different convention for the control pins as from the serial data
> pins.  One uses positive voltage for "1" the other is negative.  If
> you get this wrong the phase of the PPS will be "off" by whatever the
> pulse width is.
> (3) smaller error comes from delays in the cables.  But this is likely
> less than NTP can measure although important in precision timing
> (where nanoseconds count)

The pulse polarity is fine now.  At first PPS didn't work at all (ntpd 
ignored it completely).  I set flag2 when I was able to put the pulse on 
a scope to discover it was inverted.  After setting flag2 ntpd was able 
to use the PPS signal even though the OS is able to capture both edges 
of the pulse.

The pulse itself is 100ms negative going and 900ms positive (hence 
flag2).  However, the pulse is stable over time both in duty cycle and 
in overall cycle timing.  This receiver was intended to time a CDMA 
cellular telemetry system so it used PPS for timing.  It does have NMEA 
and SIRF output but the telemetry CPU used those only once in a while to 
correct time (I think in SIRF mode).  In NMEA mode the sentences drift 
relative to the PPS signal (even when only emitting GPRMC and turning 
all others off) but I'm not using the NMEA output right now (in fact 
NMEA + PPS doesn't work at all but I haven't tracked down the reason 
yet, something to do with the interaction between ntpd's PPS routines, 
the kernel PPS routines, and the kernel serial port routines).


> As for internet servers beiing "worse" than your GPS.  I disagree.
> Those severs are likely using GPSes.   What's worse is only the
> communications path.  There is more jitter in the path from the server
> than from a local GPS.    But we can average over a day or so and
> determine the average difference in phase. GPS calls this "offset".
> If you run your GPS and several Internet servers for a day or so NTP
> will compute a good "offset number".

Most of the other servers aren't using GPS directly, they are pulling 
from some other system.  I posted ntpq -pn just a bit ago.  Take a look 
at that and let me know what you think.

> If multiple servers all agree on an offset from your GPS you have to
> make a decision:  Is your GPS correct and all the other servers are
> wrong by the same amount or is your system the one that is offset from
> true UTC time.

> The pool servers likely will not all have identical offset.  The
> "spread" will limit how accuracy you will be able to use this method.
>   The best you can do is adjust your NTP server so is sees on average
> zero offset with most other servers but you wil never get to exactly
> zero.  It will bounce around.    As I sad above in another email.  You
> need a trusted clock.  This can be done but some specialized hardware

I'm not using all pool servers.  I'm using two pool servers but the 
other four are not pool members though I happened to notice a couple of 
them have managed to vote the same upstream servers as their reference 
clocks.



More information about the questions mailing list