[time-nuts] ACAM GP22 Chip

Thomas Allgeier th.allgeier at gmail.com
Thu Nov 26 05:12:26 EST 2015

Hello Tom,

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.

Best regards,

-----Original Message----- 
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 mailing list