[time-nuts] ADEV dead time w/ HP 53131A & TimeLab

Tom Van Baak tvb at LeapSecond.com
Mon Apr 9 15:01:34 UTC 2018


Dave,

> My research concerns oscillator drift on time scales of ~1ms to ~10s, so
> I'm guessing the 53131A with its 5-130ms of dead time isn't suitable for
> what I'm trying to measure.

True. Try a fancy TIA (time interval analyzer) or MDA (modulation domain analyzer) instead.

Or consider a high-res (tens of ps) timestamping counter capable of 1000 samples per second. The Pendulum CNT-91 may work. Also look into the Agilent 53230A which has a zero deadtime timestamping mode. The venerable SR620 is also capable of 1 kHz measurement rate, but I'm not sure if that's internal sampling or sustained data rate via GPIB. The TICC (designed by JohnA, distributed by TAPR) would also work to 1 kHz sampling if you rewrote the Arduino code.

What kind of oscillator is it that you're trying to measure? Pendulum? Tuning fork? TCXO? Some SiLabs thing? That may make a huge difference in the type of gear you need or the measurement model.

What timing resolution do you need at 1 ms sampling rates?


> But I'd still like to know how folks are
> getting around this dead time issue with the 53131A for their measurements
> in hopes it'll shed light on how I can do the same without needing to pick
> up more gear and the inevitable shipping delay that will entail.

If zero dead time is important then make single-shot time interval measurements instead of using frequency or period mode. I do almost all my GPS/1PPS logging that way, using a 53131A like yours. But, as you surmise, you don't get anywhere near a 1 kHz sampling rate.


> I'm still looking for the part in the manual where
> HP/Agilent/Keysight owns up to this and describe how it changes the
> measurement.

By now there's a lot of literature, both marketing and technical, that describes in detail how regression-based frequency counters work. The 53131A was designed in the 90's before that literature was written.

There's a key footnote in the manual from which you can infer all of this. For a summary see this posting, and the GIF:
https://www.febo.com/pipermail/time-nuts/2013-August/079647.html

Also if you look at the specifications pages (e.g., under RMS resoluion) you'll see a more explicit reference to the counter making 200,000 measurements per second. Putting all this together it's clear this counter does precise single-shot time measurements (compatible with ADEV) but it does regression-based frequency/period measurements, which may or may not be perfectly compatible with ADEV.

/tvb

----- Original Message ----- 
From: "David Burnett" <db at berkeley.edu>
To: <time-nuts at febo.com>
Sent: Sunday, April 08, 2018 6:29 PM
Subject: [time-nuts] ADEV dead time w/ HP 53131A & TimeLab


> Hi time-nuts,
> 
> I'm doing oscillator-related research for my PhD and found this list
> recently. It's been a great resource in trying to refine my freq
> measurement setup and in starting to understand what's really going on
> inside my lab equipment.
> 
> I've been trawling the archives and have a question about measuring ADEV
> accurately with the Agilent 53131A frequency counter I have on hand. From
> the comments on this list and elsewhere, and the fact that TimeLab will
> talk to my 53131A directly, I have the impression one can use the 53131A
> for period measurements with which to calculate ADEV. But from GPIB command
> sniffing it looks like there's a lot of dead time between measurements:
> -- In period or freq mode* measurements take an extra ~130ms longer than
> gate time to return (but this seems to produce the correct measurements for
> TimeLab);
> -- in time interval mode they take about ~20ms;
> -- in totalize mode they take about 5ms, in keeping with "200 measurements
> per second" advertised in the brochure, but of course this is a simple
> counter and one loses the resolution of a reciprocal counter or anything
> smarter added in.
> 
> Is it just generally assumed everyone is making period measurements on time
> scales long enough that any instrument dead time is ignorable? Or is
> TimeLab and everyone else silently applying the correction factor as
> described by the Barnes & Allan NIST paper (NIST technical note 1318)? Or
> is there a configuration mode I'm missing that prints measurements with
> more regularly? TimeLab's GPIB commands seem to be limited to "get current
> measurement" so I might not have the box set up right to start with.
> 
> My research concerns oscillator drift on time scales of ~1ms to ~10s, so
> I'm guessing the 53131A with its 5-130ms of dead time isn't suitable for
> what I'm trying to measure. But I'd still like to know how folks are
> getting around this dead time issue with the 53131A for their measurements
> in hopes it'll shed light on how I can do the same without needing to pick
> up more gear and the inevitable shipping delay that will entail. I suspect
> someone will recommend that I get a time-stamping/continuous measurement
> box, which is probably the best solution. But I'm hoping there's a way
> around that in the short term so I can make these measurements sooner.
> 
> 73,
> Dave
> 
> * Others on this list have warned about using this mode because the machine
> does a lot of averaging but it seems like TimeLab needs the box to be in
> this mode regardless. I'm still looking for the part in the manual where
> HP/Agilent/Keysight owns up to this and describe how it changes the
> measurement.
> _______________________________________________
> 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.




More information about the Time-nuts_lists.febo.com mailing list