Discussion:
53230A TIC and TimeLab
Add Reply
AC0XU (Jim)
2018-10-04 02:04:59 UTC
Reply
Permalink
I have recently acquited a 53230A counter and have tried to measure ADEV of a GPSDO with it. I am suspicious of the ADEV numbers reported by TimeLab V1.31 because

1) Timelab disagrees significantly with the ADEV numbers reported by the 53230A itself. In this case, with 1 sec sample intervals, the 53230A reports an ADEV of about 370 micro Hz (or 3.7e-11). Time lab reports 1.5e-11 @0.01 sec sample period, 2e-11 @0.1 sec sample period, 6e-11 @1sec sample period - all at tau=1sec.

2) When I use TimeLab to select different sample intervals, the whole ADEV curve shifts left (with smaller sample intervals) or right (with larger sample intervals).

Its as if TimeLab does not correctly account for the sample interval, but am I just not using the Timelab/counter setup correctly?

Thanks!


_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Ole Petter Rønningen
2018-10-04 06:26:09 UTC
Reply
Permalink
You may want to have a look at http://www.efos3.com/53230A/HPAK53230A-1.html

Ole
Post by AC0XU (Jim)
I have recently acquited a 53230A counter and have tried to measure ADEV of a GPSDO with it. I am suspicious of the ADEV numbers reported by TimeLab V1.31 because
2) When I use TimeLab to select different sample intervals, the whole ADEV curve shifts left (with smaller sample intervals) or right (with larger sample intervals).
Its as if TimeLab does not correctly account for the sample interval, but am I just not using the Timelab/counter setup correctly?
Thanks!
_______________________________________________
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Ole Petter Ronningen
2018-10-04 06:56:16 UTC
Reply
Permalink
Somewhat longer answer; I assume you have set up a frequency measurement
(as opposed to time interval)

1. Timelab uses SCPI-command "READ" to fetch readings from the 53230a (and
most other counters *). The 53230a does not return gap free frequency
measurements in this case. There will be deadtime which will be ignored, as
you say, but the measurements will also be biased. In addition, the
CONTinous gap free mode is broken when it comes to ADEV, as has been
documented elsewhere. From my experience, using the 53230a in a time
interval measurement takes care of these issues, at the expense of a
slighly more cumbersome setup.

2. You may know this, but from your text it could be a misunderstanding:
timelab does not configure the instrument; whichever sample interval you
select in timelab should match the sample interval you have set up the
53230a to use.

3. Regarding the ADEV number discrepancy; are the measurements made *at the
same time*? For "long enough"? (The numbers jump all over the place before
they settle down, thats normal from my experience.)

Of course, theres the question of what reference you are measuring against.

Ole

* at least this was the case the last time I checked, but I have not
looked at the source for 1.31 to verify.
Post by AC0XU (Jim)
I have recently acquited a 53230A counter and have tried to measure ADEV
of a GPSDO with it. I am suspicious of the ADEV numbers reported by TimeLab
V1.31 because
1) Timelab disagrees significantly with the ADEV numbers reported by the
53230A itself. In this case, with 1 sec sample intervals, the 53230A
reports an ADEV of about 370 micro Hz (or 3.7e-11). Time lab reports
sample period - all at tau=1sec.
2) When I use TimeLab to select different sample intervals, the whole ADEV
curve shifts left (with smaller sample intervals) or right (with larger
sample intervals).
Its as if TimeLab does not correctly account for the sample interval, but
am I just not using the Timelab/counter setup correctly?
Thanks!
_______________________________________________
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Magnus Danielson
2018-10-04 08:58:56 UTC
Reply
Permalink
Hi,
Post by Ole Petter Ronningen
Somewhat longer answer; I assume you have set up a frequency measurement
(as opposed to time interval)
1. Timelab uses SCPI-command "READ" to fetch readings from the 53230a (and
most other counters *). The 53230a does not return gap free frequency
measurements in this case. There will be deadtime which will be ignored, as
you say, but the measurements will also be biased. In addition, the
CONTinous gap free mode is broken when it comes to ADEV, as has been
documented elsewhere. From my experience, using the 53230a in a time
interval measurement takes care of these issues, at the expense of a
slighly more cumbersome setup.
Regardless, the 53230A does a filtered frequency estimation, which is
great for achieving high precision frequency measures quickly, but not
good for ADEV measures, as it introduces a bias due to the lower
bandwidth of the filtering as compared to the sampling interval.
Dead-time gaps biases also comes in.

For any software (TimeLab or Stable32) to process sufficiently unbiased
values, only phase values should be used to avoid both the filtering and
dead-time gap issues.
Post by Ole Petter Ronningen
timelab does not configure the instrument; whichever sample interval you
select in timelab should match the sample interval you have set up the
53230a to use.
TimeLab actually assumes that the user really know what they are doing,
but attempts to assist in the overall task. Adding a instrument
configuration tool into TimeLab would be possible, but for most part
consider the configuration you do for a measurement the opportunity to
input to TimeLab under which conditions the measurement was done, how
the instrument was setup etc. From there it just consumes measurements,
scales them according to the configuration, unwrapp phase etc. prior to
record the measurement record that is then used for analysis.
Post by Ole Petter Ronningen
3. Regarding the ADEV number discrepancy; are the measurements made *at the
same time*? For "long enough"? (The numbers jump all over the place before
they settle down, thats normal from my experience.)
One of the great learning experiences you can get from TimeLab is how
the real-time update of ADEV swings in the highest tau range of the
plot, but as more samples comes in, the same tau range becomes less
uncertain, the confidence bounds (chi-square based) goes down and
TimeLab illustrates this very nicely. Thus, one wants to have enough
samples before judging too much of a value. It's experience one has to
built.
Post by Ole Petter Ronningen
Of course, theres the question of what reference you are measuring against.
Always. It is always good to look at specs and other measurements to see
if the measurement is reasonably in compliance with what one can expect
from other measurements. Even with very good instruments that does a lot
to solve the measurement problem, you always needs to validate it and
check it. One need to understand how the measurement instrument and
processing will impact the value and understand what part of this is
needed to get "proper" value and what is various forms of impairments.

Cheers,
Magnus
Post by Ole Petter Ronningen
Ole
* at least this was the case the last time I checked, but I have not
looked at the source for 1.31 to verify.
Post by AC0XU (Jim)
I have recently acquited a 53230A counter and have tried to measure ADEV
of a GPSDO with it. I am suspicious of the ADEV numbers reported by TimeLab
V1.31 because
1) Timelab disagrees significantly with the ADEV numbers reported by the
53230A itself. In this case, with 1 sec sample intervals, the 53230A
reports an ADEV of about 370 micro Hz (or 3.7e-11). Time lab reports
sample period - all at tau=1sec.
2) When I use TimeLab to select different sample intervals, the whole ADEV
curve shifts left (with smaller sample intervals) or right (with larger
sample intervals).
Its as if TimeLab does not correctly account for the sample interval, but
am I just not using the Timelab/counter setup correctly?
Thanks!
_______________________________________________
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
_______________________________________________
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Ole Petter Ronningen
2018-10-04 09:21:53 UTC
Reply
Permalink
Post by Magnus Danielson
Regardless, the 53230A does a filtered frequency estimation, which is
great for achieving high precision frequency measures quickly, but not
good for ADEV measures, as it introduces a bias due to the lower
bandwidth of the filtering as compared to the sampling interval.
Dead-time gaps biases also comes in.
True - but be aware that the *first sample* returned from the instrument,
when fetched using "READ", will also be biased in an absolute sense - the
frequency reported will systematically be too high or too low (the
magnitude and direction of the error depending primarily on gate time, from
what I've seen).

So even when using this mode to only look at high resolution "absolute
frequency measurements", it is easy to get bitten if the data is collected
using a computer.

BR,
Ole
_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Magnus Danielson
2018-10-04 11:39:05 UTC
Reply
Permalink
Hej Ole!
Post by Ole Petter Ronningen
Post by Magnus Danielson
Regardless, the 53230A does a filtered frequency estimation, which is
great for achieving high precision frequency measures quickly, but not
good for ADEV measures, as it introduces a bias due to the lower
bandwidth of the filtering as compared to the sampling interval.
Dead-time gaps biases also comes in.
True - but be aware that the *first sample* returned from the instrument,
when fetched using "READ", will also be biased in an absolute sense - the
frequency reported will systematically be too high or too low (the
magnitude and direction of the error depending primarily on gate time, from
what I've seen).
Who-oh! OK. This means that one should intentionally let a number of
samples pass before trusting it.

It would be interesting to get some better qualifications of this.
Post by Ole Petter Ronningen
So even when using this mode to only look at high resolution "absolute
frequency measurements", it is easy to get bitten if the data is collected
using a computer.
Obviously. Good to know. Many thanks!

It is interesting to learn that we still need to handle the temperament
of instruments.

Cheers,
Magnus

_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Ole Petter Ronningen
2018-10-04 13:42:49 UTC
Reply
Permalink
Post by Magnus Danielson
Who-oh! OK. This means that one should intentionally let a number of
samples pass before trusting it.
Precisely. But, crucially, discard 1-2 samples *since the last INIT* -
which may not be obvious without some investigation. It is a bit
convoluted, but the behaviour is easily observed using TimeLab: Feed the
counter the same 10 MHz signal both on the EXTernal REFerence, and channel
1. Set up a frequency measurement, and collect data using timelab. Observe
the phaseplot (taking care to NOT have the phase plot in "residual mode").

After a few minutes, a slope will be observed on the phase plot that should
not be there - it is measuring its own reference, so the plot should be
pretty much dead flat over a sufficiently long interval. It is because
timelab calls READ every time it wants a sample, and the instrument returns
a biased frequency estimate. Shorter gate-times, steeper slope.

It would be interesting to get some better qualifications of this.


I have attempted to make a thorough writeup on the previously mentioned
http://www.efos3.com/53230A/HPAK53230A-1.html Also parts 2 and 3 - in
short, the behaviour has been observed on three separate instruments. The
data is available for download on my website. Oh, and Keysight has
acknowledged the issue, but not offered anything towards a solution.

Ole
_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Bob kb8tq
2018-10-04 14:02:52 UTC
Reply
Permalink
Hi

Probably also worth mentioning:

For short tau, you are probably measuring the ADEV of the counter noise floor rather than the
ADEV of the GPSDO. Yes, there are noisy GPSDO’s out there but most of what you run into
is not in that category.

Bob
Post by Ole Petter Ronningen
Post by Magnus Danielson
Who-oh! OK. This means that one should intentionally let a number of
samples pass before trusting it.
Precisely. But, crucially, discard 1-2 samples *since the last INIT* -
which may not be obvious without some investigation. It is a bit
convoluted, but the behaviour is easily observed using TimeLab: Feed the
counter the same 10 MHz signal both on the EXTernal REFerence, and channel
1. Set up a frequency measurement, and collect data using timelab. Observe
the phaseplot (taking care to NOT have the phase plot in "residual mode").
After a few minutes, a slope will be observed on the phase plot that should
not be there - it is measuring its own reference, so the plot should be
pretty much dead flat over a sufficiently long interval. It is because
timelab calls READ every time it wants a sample, and the instrument returns
a biased frequency estimate. Shorter gate-times, steeper slope.
It would be interesting to get some better qualifications of this.
I have attempted to make a thorough writeup on the previously mentioned
http://www.efos3.com/53230A/HPAK53230A-1.html Also parts 2 and 3 - in
short, the behaviour has been observed on three separate instruments. The
data is available for download on my website. Oh, and Keysight has
acknowledged the issue, but not offered anything towards a solution.
Ole
_______________________________________________
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo
AC0XU (Jim)
2018-10-05 02:56:23 UTC
Reply
Permalink
THANK YOU!

Thanks very much to all who responded to my query. Apparently, I was a bit naive in my expectations for the device. Since it am especially interested in measuring short-term stability, I am going to try using it the method described in (who??):

http://www.efos3.com/53230A/HPAK53230A-High-speed-TI.html

I understand that at some point I will be seeing the noise/stability floor of the instrument. According to

http://www.anderswallin.net/2015/04/keysight-53230a-noise-floor-test/

that noise floor may be around 2e-11 at 0.1 sec and 2e-12 at 1 sec. That is just about what I am aiming for.

Jim





_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Ole Petter Ronningen
2018-10-05 07:16:20 UTC
Reply
Permalink
[...] Since it am especially interested in measuring short-term stability,
http://www.efos3.com/53230A/HPAK53230A-High-speed-TI.html
Thats my website. The method can be a little fiddly if you don't understand
the instrument pretty well, I would suggest getting a bog-standard TI
measurement working first. In either case I'll be happy to assist if you
need some pointers, ofcourse.
I understand that at some point I will be seeing the noise/stability floor
of the instrument. According to
http://www.anderswallin.net/2015/04/keysight-53230a-noise-floor-test/
that noise floor may be around 2e-11 at 0.1 sec and 2e-12 at 1 sec. [...]
Well.. I trust I will be corrected if I am wrong, but I believe the
frequency measurements were taken using the "resolution enhanced mode" -
which does not yield the correct ADEV, as shown by the slope on the plots.
See here http://www.anderswallin.net/tag/53230a/ for a followup on that
post by Anders.

A 20ps counter should give a noise floor around 2e-11 at 1 second gate
time, with a slope of -1 on the log-plot; 2e-11 at 1 second, 2e-12 at 10
seconds, 2e-13 at 100 seconds and so forth, untill the noise is no longer
white PM.

Theres a lot more in i.e. Handbook of Frequency Stability Analysis (
https://tf.nist.gov/general/pdf/2220.pdf) and other places -
http://www.leapsecond.com/time-nuts.htm is a good place to start, if you
have not seen it.

Ole
_______________________________________________
time-nuts mailing list -- time-***@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Loading...