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

Discussion:

David Burnett

2018-04-09 01:29:25 UTC

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-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Bob kb8tq

2018-04-09 03:00:38 UTC

Permalink

Hi

The basic fact is that oscillators drift on *all* time scales. How much they drift
depends on the type of oscillator. A free running VCO based on a PCB resonator
will drift differently than a bare crystal oscillator. An OCXO will have different drift
characteristics than a bare oscillator.

A 53131 by its self is not capable of measuring the ADEV of a crystal oscillator over
short time periods. The counter’s ability scales by the gate time so eventually if the
gate time is long enough, it will catch up. That might be beyond 1,000 seconds for a
good OCXO. By that point, your dead time concerns are not as significant.

There are a number of methods out there to get higher resolution than a bare counter
will provide. The NIST Time and Frequency archives have quite a bit buried in them.
That includes information that digs into your dead time concerns.

One alternative to the 53131 is a TimePod from Symmetricom. A somewhat less
expensive approach is a DMTD setup. Both require a “better than” device to compare
your oscillator under test to. Unfortunately that’s a drawback to pretty much all ways
to do this. If your reference is more noisy than your DUT, you will just see the reference.

Bob

Post by David Burnett
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
-- 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.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

_______________________________________________
time-nuts mailing list -- time-***@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Tom Van Baak

2018-04-09 15:01:34 UTC

Permalink

Dave,

Post by David Burnett
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?

Post by David Burnett
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.

Post by David Burnett
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" <***@berkeley.edu>
To: <time-***@febo.com>
Sent: Sunday, April 08, 2018 6:29 PM
Subject: [time-nuts] ADEV dead time w/ HP 53131A & TimeLab

Magnus Danielson

2018-04-09 21:00:49 UTC

Permalink

Hi David,

Really good! Welcome!

Post by David Burnett
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
-- 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.

OK, first off, one hides the dead time of the counter by using the
time-interval mode and use a reference signal such as a PPS or other
suitable rate as start/Channel 1 signal where as the measured signals
goes into stop/Channel 2. That works up to the rate of the counter, and
you don't want to miss samples.

You should also consider what the time resolution you would need. A
HP5372A for instance can do 8000 samples as every 100 ns with 200 ps
resolution for instance. There is more modern counters that do much better.

Post by David Burnett
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.

Well, start with what you have, learn what limits it and then you can
motivate better toys/tools.

That you mention dead-time is refreshing, so you get an extra point
right there, besides asking how to get started.

Now, how much drift do you expect that your oscillators would do? Do you
have a rough idea?

i have done lot's of measurements using a 53131A and hold-over, but
usually the first 10-100 s is relatively easy, but depending on the
details of the lock mechanism it can be more or less "interesting".

Cheers,
Magnus

Post by David Burnett
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.
_______________________________________________
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.