[time-nuts] Divide by five

[Bob Camp]

Hi

> On Nov 9, 2014, at 11:18 AM, Chris Albertson <albertson.chris at gmail.com> wrote:
> 
> On Sat, Nov 8, 2014 at 11:13 PM, Neil Schroeder <gigneil at gmail.com> wrote:
> 
>> 
>> At one point I was considering phase locking all of them together - but
>> again that seemed less than straightforward.  You can do it PLL back to
>> back, but is there a way to have a loop that contains multiple clocks?  I
>> would think the "telephone game" would apply.
>> 
> 
> 
> NTP does this but on a MUCH lower frequency and longer time scale.   But I
> think NTP's general method could apply.   NTP will accept any number of
> reference clocks.  (Yes sone people run NTP using just one GPS receiver as
> a reference but best practice is to use five references.)  NTP compares the
> set of ref. clocks with each other and first tries to find the subset of
> clocks that track each other, assuming the outliers are "wrong".  It
> continuously checks this and maintains a set of "true tickers".  From these
> it computes a consensus time using a weighted average of the "true"
> clocks.  The weights are based on the jitter and other quality measuring
> statistics.  Using this method reference clocks can be taken on and off
> line without need to re-start NTP.

That may (or may not) give you the best ADEV on the output. My guess is that the filtering algorithm will need to be a bit more complex. NTP’s aim is mainly to throw out bad clocks and pick one as best. We would more likely want to combine the outputs and use all of the good clocks we have. The idea is to improve on the ADEV of the *best* source you have available. 

> 
> You could do the same thing with a set of local oscillators.    Divide each
> down to 1PPS then every second you compare their phases.  Keep statistics
> on drift and standard deviation relative to your "consensus phase".   You
> then discipline an OCXO (or several OCXOs) to output that consensus.
> Like NTP you might accept reference from any number of GPSes or Rb or other
> standards.   You controller might pick the best OCXO in real time as the
> output.
> 
> I figure the first generation where we are now, where we build a GPSDO
> using just one GPS and one OCXO and next generation would use multiples of
> each.

You *do* need a way to do this with pretty high precision. The 10 ns number I tossed around earlier is sort of an upper bound. The closer you get to 0.1 ns, the better things might get.

> 
> There is not a lot of fancy electronics required.  Just some phase
> comparators that can run once per second.  The once pre second data rate is
> so slow that ANY $5 micro controller could keep up with even a dozen
> reference clocks.  I'd likely us one of the ARM based Arduinos because they
> are easy enough to program that the barrier to entry is low enough others
> might be able to contribute.  (Think about this if you want to make your
> design public.  If the technology is exotic,no one but you will contribute
> to further development.)
> 
> If you like those FPGA boards then you can usually synthesize a CPU and run
> the controller code on that.

I would very much avoid an FPGA based CPU. You likely will need to add both flash and ram to the FPGA. Once you are done, you have a $30 gizmo that replaces a $1 chip. You also have a tool chain for your code that is far from “low barrier to entry”. It’s a great solution for something like video processing that needs TONS of bandwidth. We are very much on the other end of that stick.

Bob

> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.