[time-nuts] ACAM GP22 Chip
th.allgeier at gmail.com
Thu Nov 26 05:12:26 EST 2015
One of the problems here (embarrassingly) is that we have a lack of kit in
this particular respect. And I am not yet prepared to throw too much money
at it before I can judge the real potential.
(Our forte so far is high precision in terms of voltage and current, which
is what you traditionally need for strain gauge measurements, which is what
we have been traditionally doing. nV instead of ns or ps so to speak.) Hence
the low-tech approach, and having read the tests on the HP5370 I thought
"hey, I can do that".
Anyway we need the results a lot quicker than 1 Hz, ideally at least every
10 ms or so. The reason is that in weighing much is achieved by filtering
and if you want a reasonable response time after the filter then you have to
feed in the raw stuff quite quickly. The GP22 seems to be pretty much what
is needed, and we happen to buy from ACAM already.
I played with it last night and I think I should shortly be in a positions
to share "early" findings.
From: Tom Van Baak
Sent: Thursday, November 26, 2015 12:02 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] ACAM GP22 Chip
>> 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)?
time-nuts mailing list -- time-nuts at febo.com
To unsubscribe, go to
and follow the instructions there.
More information about the time-nuts