[ntp:questions] garmin 18x and linux

unruh unruh at wormhole.physics.ubc.ca
Sat Sep 10 17:22:23 UTC 2011

On 2011-09-10, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
> On 9/9/2011 6:38 PM, unruh wrote:
>> On 2011-09-09, Chris Albertson<albertson.chris at gmail.com>  wrote:
>>>>> What we are talking about when we say "accuracy" is the amount of uncertainty.
>>>> No we mean how closely the gps absolute time agrees with the utc
>>>> absolute time (modulo leap seconds).
>>> Accuracy is always expressed as an uncertainty.  For example I might
>>> say  "the voltage is 6.32V plus or minus my meter's 2% error"  This
>>> means I'm un-certain of the true voltage in the wire but think the
>>> value I gave is within 2% of "truth"
>> Actually there are two kinds of errors-- systematic and random. Thus,
>> the troposphere causes a delay in the signal of about
>> 8.1ns/sin(elevation) where elevation is the angle above the horizon of
>> the sattelite. The ionisphere has an error of about 9ms/sin(theta) but
>> with an random error of about plus or minus 4.5ns.
>> The MT12+ also apparently has a delay of a few 10s of ns in sending out
>> the pulse. Are these uncertainties? If yo udo not know about them, they
>> are. If you know about them you can subtract out the systematic errors,
>> but you cannot do that for the random errors.
>> Note that this means that the Oncore is far far from being within 2ns of
>> the "truth" (ie UTC) More like 30ns.Plus the onboard trigger mechanism
>> in the gps produces another 30-60ns of sawtooth error, which you can
>> eliminate if you happen to be able to read and use the messages the unit
>> can send out. Bbecause the noise
>> depends on the elevation of the sattelites, and because the reported
>> time is an "average" over many different elevations, those are also not
>> possible to correct for.
>>> When we buy a UT+ and read that it has 55nS accuracy what that is
>>> saying is roughly that about 2/3 of the time the true UTC time will be
>>> no more than 55nS from what the GPS says.    In other words Motorola
>>> claims there will be an error that you can't know but does tell you
>>> the statistical properties of the error.    I used the word
>>> "uncertainty" to describe an known error.
>> And what are unkown errors?
>> Surely they also affect the accuracy with which you know the time.
>>> Again this is all pretty much moot for NTP.  Once your GPS has an
>>> error of less than a microsecond you are as good as "perfect" for NTP.
>> Well, one can certainly use ntp to control the clock to the ns level.
>> For most computers who receive their signal via an interrupt line, that
>> would agreed be useless since the interrupt cannot be serviced faster
>> than a few usec. However, ntp can be used for a hardware clock which can
>> timestamp the pulse edge to ns precision as well.
> Dream on!  You *may* have a PPS signal with an edge that might be within 

?? Pls read. What I refered to was a special hardware clock which would
timestamp the edge of the pulse as it came in-- obviously using a
special onboard clock, not the computer's clock, which the computer
would also refer to to get the time. 
I agree perfectly that the computer's clock itself cannot be discplined
to better than about 1us, but that piece of hardware can use ntp to
discipline the clock on that piece of hardware itself. 

ntp is a clock discipline procedure. ntpd is a piece of software running
on a personal computer which impliments the ntp protocol. 

> 50 nanoseconds.  Can you even begin to time the steps between the 
> arrival of the PPS in your GPS receiver and the updating of the 
> computer's clock?

With the right hardware? Sure.
> There are damned few hobbyists who can time anything at the nanosecond 
> level!

More information about the questions mailing list