[time-nuts] ACAM GP22 Chip

[Bob Camp]

Hi

The issue of “technology to back this up” is not a trivial point at all. There is a 
lot of detailed knowledge in each of these areas. There is also a lot of gear
that is specific to this or that kind of work. The gear is fairly easy to take care
of and to estimate. The “how long will the learning curve be” part is often the
biggest issue.

Bob


> On Nov 26, 2015, at 5:12 AM, Thomas Allgeier <th.allgeier at gmail.com> wrote:
> 
> 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,
> Thomas.
> 
> 
> 
> -----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)?
> 
> /tvb
> _______________________________________________
> 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. 
> _______________________________________________
> 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.