[time-nuts] Low-long-term-drift clock for board level integration?

[Chris Albertson]

On Sun, Feb 19, 2012 at 5:48 PM, Bill Woodcock <woody at pch.net> wrote:
..
> So that's something I've been having a hard time understanding…  If that's the amount of inaccuracy _per oscillation_, then at the time-scales I'm dealing with, it would quickly accumulate and become unuseful…

I think you have it right.

There are two things (1) the RATE of a clock and (2) the PHASE of a clock.

The phase is the time between a "true UTC per second tick" and the
tick on your clock.  When you see that your wrist watch is 5 seconds
different from another, that is five seconds of phase.  Phase is
measure in units of duration, like 1 uSec or 5 seconds

Rate is is always "per unit time".   A perfect clock runs at one
second per second.


 Sorry if this is to obvious.  That is my point.  It's not rocket
science.    (See Below, I think NTP might work for you if you are
willing to push the state of the art forward with some purpose built
hardware.

Now about GPS and NTP.  It's huge advantage is that if you average
over enough time it runs at one second per second rate, exactly

The trouble is the noise in the phase.  NTP over the Internet has
"tens of milliseconds" on uncertainty in the phase.  It is useless for
what you want.  You need uS not mS.

GPS also has some uncertainty in the "phase" on the order of about
between 1uS and 10nS depending at the type of GPS and how much care
was used in setting it up.  You need a good site survey and time for
an OXCO to reach equilibrium to get good time data.   Turn on your
basic consumer level Garmin and you get time to about 1/2 second.  Yes
it really can be that poor.

You are correct if the rate is wrong by "X" the phase will drift at X
per unit time and soon can be very far off.  What you do with NTP or
GPS is work the other way:  NTP tells you the time (plus or minus say
1 mS)  So you wait 1,000 seconds and get the time again.   Now you now
your RATE to within 2mS per 1,000 seconds or to within 2uS per second.
  In theory you could wait 1,000,000 seconds and get better rate
determination but what kills you is that we must assume the local
clock's rate is constant for this to work.  It is maybe "constant
enough" over 1,000 seconds but certainly not over 10K seconds unless
you spend that $300 budget on a good local oscillator.   If you do
then NTP can use a very long time constant in it's loop.    Typical
NTP software can't use such a long time constant because typical local
clocks are cheap ($2 or less) 20PPM crystals.   If you can afford
20PPB (1000 times better) you just might, maybe be able to get uSecond
level time from NTP over a network.  But how long would that take?
Can your users wait 100,000 seconds?   You will be pushing the current
state of the art.  Most everyone finds it is easier to simply connect
to GPS.

GPS is the same as NTP but has less uncertainty so you can get good
rate determination with a MUCH shorter integration time.

If you are willing to build a custom motherboard around an OCXO and
modify some system software and right a custom NTP driver you just
might get to 100X better than is typical.

It sure would be a fun experiment to have NTP try and discipline a
Rubidium oscillator

New TOPIC:    Mmaybe there is a better way?  Sounds like your system
uses absolute time to measure time intervals.   Better maybe to use
relative time.    Maybe for example your units all "ping" each other
at some rate.   then you measure time relative to the ping rate.   All
your units know the ping rate and don't need to know the wall clock
time as they have their own time unit.  later you can figure out the
conversion for ping rate to seconds.   It could be very accurate.
If say you want to measure the time to do one HTTP request then you
send 1000 HTTP requests and you see that you got 13,500 pings per 1000
HTTPs, the ratio is 13.5:1.  Just make up your own unit of time

Chris Albertson
Redondo Beach, California