[time-nuts] ACAM GP22 Chip

Tom Van Baak tvb at LeapSecond.com
Wed Nov 25 19:02:48 EST 2015


>> In order to evaluate the chip I was planning to replicate John A’s
>> experiment with the coaxial delay line from the HP5370b 
> For those wondering: "John A" is John Ackermann and the experiment
> in question is documented at http://www.febo.com/pages/hp5370b/

Maybe I misunderstand, but I would not suggest testing a time interval counter by using a fixed ns delay -- that's almost never how the real world works and those tests tend to produce bogus ADEV plots that have -1 slope forever (a clue that something's wrong with the test).

A selection of fixed delays is slightly better. But best, and much easier, is to use uncorrelated A, B, and LO (ext ref) signals. A fixed delay may land on a sweet spot or honey bucket. Linear sweeping the range covers all spots, and gives you best case / worst case / rms statistics as a bonus. In other words, what you want is a set of random (but known, or knowable) delays; not a set of hardcoded delays.


> of the GP22 I need a delay of 500 ns or more (actually 1 µs sounds a better start).

Are you sure you want a hardcoded delay of N ns or N us? Or is a variable or even varying delay sufficient?

What I use in cases like this is two stable oscillators that slowly drift apart (i.e., close, but not the same frequency). For example, if they differ in frequency by 1e-12 your signals drift 1 ps/s. Or if they differ by 1e-10 your signals drift by 1 ns / 10 s. You get an uncorrelated, very low-noise, linear phase sweep "for free".

This sort of slow varying phase relationship is ideal when making counter tests; much better than a fixed delay. You can use a laboratory counter to monitor their exact phase difference in parallel with your DUT. That is, you then compare TIC "truth" against what your DUT reports.


> We want to use this chip to measure the period of a square wave, of around 13 kHz i.e. in the 70 µs range.
> As the application is potentially high-accuracy we need to know the period to within 1 ns or better.

I may have missed it in the thread -- but how quickly do you need your measurements? Is one measurement every 1 or 10 or 100 seconds ok? (in which case an ACAM chip is total overkill). Or is this some sort of sub-second real-time application that require both modest resolution (1 ns / 70 us = 15 ppm, easy) and fast response (hard)?

/tvb


More information about the time-nuts mailing list