53230A noise floor
Hi all,
I ran some tests on a new 53230A counter that just arrived:
http://www.anderswallin.net/2015/04/keysight-53230a-noise-floor-test/
The time-interval single-shot noise and resulting ADEV seems easy enough to
explain.
I didn't yet have time to look closely at Enrico Rubiola's notes over here:
http://rubiola.org/pdf-slides/2012T-IFCS-Counters.pdf
There is probably a good explanation for the ADEV-level in standard
(pi-counting?) reciprocal frequency counter mode as well as the roughly
1/sqrt(10) enhancement in ADEV when increasing the gate-time 10-fold.
on another note:
The discussion on phase-noise <-> ADEV calculations earlier was
interesting. Datasets (synthetic or real) with known correct ADEVs and
phase-noise-spectra would be a good addition to allantools and a motivation
to add code for the phase-noise <-> ADEV conversion.
cheers,
Anders
Hi
You may want to take a look at some of Bill Riley’s (and others) papers on how pre-filtering
can lead to errors in an ADEV calculation.
Simply put - the frequency mode is a filter and it is not the right one to have in front of an ADEV
calculation.
Bob
On Apr 3, 2015, at 5:49 AM, Anders Wallin anders.e.e.wallin@gmail.com wrote:
Hi all,
I ran some tests on a new 53230A counter that just arrived:
http://www.anderswallin.net/2015/04/keysight-53230a-noise-floor-test/
The time-interval single-shot noise and resulting ADEV seems easy enough to
explain.
I didn't yet have time to look closely at Enrico Rubiola's notes over here:
http://rubiola.org/pdf-slides/2012T-IFCS-Counters.pdf
There is probably a good explanation for the ADEV-level in standard
(pi-counting?) reciprocal frequency counter mode as well as the roughly
1/sqrt(10) enhancement in ADEV when increasing the gate-time 10-fold.
on another note:
The discussion on phase-noise <-> ADEV calculations earlier was
interesting. Datasets (synthetic or real) with known correct ADEVs and
phase-noise-spectra would be a good addition to allantools and a motivation
to add code for the phase-noise <-> ADEV conversion.
cheers,
Anders
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
There is probably a good explanation for the ADEV-level in standard
(pi-counting?) reciprocal frequency counter mode as well as the roughly
1/sqrt(10) enhancement in ADEV when increasing the gate-time 10-fold.
Anders,
See the part the end that shows why averaging breaks ADEV:
http://leapsecond.com/pages/adev-avg/
I collected the data with a simple program that just calls the "READ?" function
repeatedly, which does result in some dead-time between measurements.
Yes, that's the easy way. But for more valid results use gap-free continuous mode (SENS:FREQ:MODE CONT). From the manual:
"CONTinuous configures the instrument to make continuous resolution-enhanced, gap-free measurements. This mode should be selected for true Allan deviation computation (CALCulate:AVERage subsystem). In this mode, all samples for a each trigger are started by a single gate open (instead of gate open/close per sample), and the measurements are computed back-to-back with no dead time. CONTinuous can only be used for frequency and average period measurements. Available only on the Agilent 53230A."
/tvb
In message CAPnVNRUdeRCi4suLHB9dJJF7sQwiXa5oVaRjWTEYLpoht+MyUA@mail.gmail.com
, Anders Wallin writes:
I ran some tests on a new 53230A counter that just arrived:
http://www.anderswallin.net/2015/04/keysight-53230a-noise-floor-test/
Anders,
I think that setup didn't measure what you think.
When you feed the counter EXT REF from the same source you measure,
all the transitions will happen at a certain point relative to the
internal clockcycles of the counter, and therefore be subject to
only one of many possible noise-situations.
A much better way:
Use the "good" signal for your CH1/CH2 inputs, and also feed it to a
slightly offset synthesizer generator for the EXT REF.
If you feed the EXT REF 10.0001 MHz (relative to CH1/CH2, the absolute
value is not really important) then over a period of 10000 seconds
your test-setup will sweep the internal clock-cycle of the counter
at least once.
Then plot the MIN/MAX/STDDEV of the measurement versus time and you
will discover that the noise floor is not even close to being even.
If you find a particular good spot and want to use it for measurements,
the way to go is to tune the length of the cable for EXT REF (or use
a tweakable delay line)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
The standard deviation is good and consistent with others measurements which seem to be in the range 10 to 15 psecs.
I think the channel skew is one half of 112psecs = 56 psecs (as it adds one way and subtracts the other) and this is close to the Keysight datasheet claim of 50 psecs typically.
It is interesting to get some practical readings - when I was trying to decide on my counter it was very hard to get information - different datasheets give different parameters eg Pendulum CNT91/Tek fca 3100 has skew as < 500 psecs whilst Keysight put 50 psecs typical.
I ended up getting an fca3100 as I got a very good discount and I found that the skew I actually measured was (5.1282 nsecs - 5.0972 nsecs)/2 = 15psecs which is very good.
The std dev for the fca3100 on my unit was 30psecs which is 2 to 3 times worse than the 53230A which is consistent with the ratio of 50 psecs (fca3100) and 20 psecs (53230A).
It seems that the typical one-shot resolution is around 2.5 times better than the datasheet (your measurement of 12psecs/sqrt(2) is 2.4 times better than the nominal 20 psecs whilst my fca 3100 measurement of 30psecs/sqrt(2) is also 2.4 times better than the nominal 50 psecs.
Interestingly, the SR620 data sheet says the one shot is typically 20 psecs and is 50 psecs max which is also a similar ratio.
Perhaps there is some sort of industry standard that states datasheet one shot resolution should be expressed as 2.5 times the typical one shot resolution :).
James
-----Original Message-----
From: Anders Wallin anders.e.e.wallin@gmail.com
To: Discussion time-nuts@febo.com
Sent: Fri, 3 Apr 2015 12:04
Subject: [time-nuts] 53230A noise floor
Hi all,
I ran some tests on a new 53230A counter that just
arrived:
http://www.anderswallin.net/2015/04/keysight-53230a-noise-floor-test/
The
time-interval single-shot noise and resulting ADEV seems easy enough
to
explain.
I didn't yet have time to look closely at Enrico Rubiola's notes
over here:
http://rubiola.org/pdf-slides/2012T-IFCS-Counters.pdf
There is
probably a good explanation for the ADEV-level in standard
(pi-counting?)
reciprocal frequency counter mode as well as the roughly
1/sqrt(10) enhancement
in ADEV when increasing the gate-time 10-fold.
on another note:
The
discussion on phase-noise <-> ADEV calculations earlier was
interesting.
Datasets (synthetic or real) with known correct ADEVs and
phase-noise-spectra
would be a good addition to allantools and a motivation
to add code for the
phase-noise <-> ADEV
conversion.
cheers,
Anders
time-nuts
mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the
instructions there.
Anders,
On 04/03/2015 11:49 AM, Anders Wallin wrote:
Hi all,
I ran some tests on a new 53230A counter that just arrived:
http://www.anderswallin.net/2015/04/keysight-53230a-noise-floor-test/
The time-interval single-shot noise and resulting ADEV seems easy enough to
explain.
I didn't yet have time to look closely at Enrico Rubiola's notes over here:
http://rubiola.org/pdf-slides/2012T-IFCS-Counters.pdf
There is probably a good explanation for the ADEV-level in standard
(pi-counting?) reciprocal frequency counter mode as well as the roughly
1/sqrt(10) enhancement in ADEV when increasing the gate-time 10-fold.
When using new counters with Delta (HP53132A) or Omega (Pendelums
Least-Square) estimators for refined frequency resolution, they work by
doing a filtered weighing which has a lower bandwidth than the brute
force counter, and this will give a lower reading for white and flicker
phase noise (see their formulas), and this causes the deception that the
ADEV is lower, just because you get the reading, that the noise-type is
lower, but all which is happening is that you lower the reading for that
noise-type, not that you have a better noise situation.
on another note:
The discussion on phase-noise <-> ADEV calculations earlier was
interesting. Datasets (synthetic or real) with known correct ADEVs and
phase-noise-spectra would be a good addition to allantools and a motivation
to add code for the phase-noise <-> ADEV conversion.
Do look at the NIST SP 1065 for a noise-generator with known properties
for a number of algorithms.
Cheers,
Magnus
See the part the end that shows why averaging breaks ADEV:
http://leapsecond.com/pages/adev-avg/
Hi Tom, thanks for reminding me of that page. I did no averaging of the
data myself, and I think it's logical that the counter noise floor goes
down with increasing gate time - I just haven't had time to read and think
about the counter specs enough to write down some reasonable formula that
predicts the noise floor for different gate times.
PHK's comment about trying something different than exactly 10MHz is worth
testing.
Reading your page above I am confused by the graph where you add noise.
If I create a synthetic phase dataset with 1 ns of RMS noise (i.e. you
histogram the data and it looks like a gaussian with standard deviation
1ns) and then calculate ADEV I get ADEV(1s) = sqrt(3)*1e-9 (tried with
both stable32 and allantools)
Your page says "add 1ns noise" and shows ADEV(1s)=1e-9. Can you clarify
what "add 1ns noise" means - or am I doing something wrong?
Anders
Hi
If you use the same sort of small step synthesizer approach and get very close (but not equal to) the reference, you
can find “dead spots” where the resolution is not as good as you expected it to be. You need to be able to
step off in 1x10^-11 steps to do a good job of plotting it. Sweeping the EFC of a (very good) OCXO is one way
to do it. There are others.
This is by no means a bash on the 53230. Properly fed, it’s a fine device. Every fancy counter I’ve seen has these
sort of issues one way or the other. The fancier they make the software enhancements (like frequency estimation) the
more odd cases they seem to have pop up….
Bob
On Apr 3, 2015, at 11:06 AM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:
In message CAPnVNRUdeRCi4suLHB9dJJF7sQwiXa5oVaRjWTEYLpoht+MyUA@mail.gmail.com
, Anders Wallin writes:
I ran some tests on a new 53230A counter that just arrived:
http://www.anderswallin.net/2015/04/keysight-53230a-noise-floor-test/
Anders,
I think that setup didn't measure what you think.
When you feed the counter EXT REF from the same source you measure,
all the transitions will happen at a certain point relative to the
internal clockcycles of the counter, and therefore be subject to
only one of many possible noise-situations.
A much better way:
Use the "good" signal for your CH1/CH2 inputs, and also feed it to a
slightly offset synthesizer generator for the EXT REF.
If you feed the EXT REF 10.0001 MHz (relative to CH1/CH2, the absolute
value is not really important) then over a period of 10000 seconds
your test-setup will sweep the internal clock-cycle of the counter
at least once.
Then plot the MIN/MAX/STDDEV of the measurement versus time and you
will discover that the noise floor is not even close to being even.
If you find a particular good spot and want to use it for measurements,
the way to go is to tune the length of the cable for EXT REF (or use
a tweakable delay line)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
I've just been playing with my new (ex demo) fca3100 and the results seem dependent on setup.
(I'm not trying to hijack the thread from the 53230A but I think it is useful to have comparison results - I know I would have liked to see some prior to buying my counter.)
I have found that if I turn off the interpolation calibration then the std figures drop significantly at a bit of a cost in skew between channels.
Changing the impedance to 50 ohms from 1Mohm and doing the experiments with the instruments own pulse generator (though results with my separate pulse generator aren't hugely different) I get the following:
A->B no calib std : 19 ps mean (1M) : 1.285 02 ns
A->B calib std : 29 ps mean (1M) : 1.286 55 ns
B->A no calib std : 20 ps mean (1M) : 1.298 00 ns
B->A calib std : 31 ps mean (1M) : 1.292 63 ns
with this setup the difference between calib on and off is only -1.53 ps or + 4.63 ps (for other setups
it is rather larger).
The difference from A->B vs B->A is only 6 ps with calib on and 13 ps with calib off.
I don't know quite what to conclude from all this other than being careful about signal shape and matching and setting of trigger levels can improve results significantly.
Secondly, there seems to be a trade off between channel skew and single shot resolution - I have no idea why as I'm not sure what the interpolator calibration does - but if this is general perhaps Keysight have geared the 53230A to give low single shot resolution at the expense of slightly higher channel skew.
James
-----Original Message-----
From: Anders Wallin anders.e.e.wallin@gmail.com
To: Discussion time-nuts@febo.com
Sent: Fri, 3 Apr 2015 12:04
Subject: [time-nuts] 53230A noise floor
Hi all,
I ran some tests on a new 53230A counter that just
arrived:
http://www.anderswallin.net/2015/04/keysight-53230a-noise-floor-test/
The
time-interval single-shot noise and resulting ADEV seems easy enough
to
explain.
I didn't yet have time to look closely at Enrico Rubiola's notes
over here:
http://rubiola.org/pdf-slides/2012T-IFCS-Counters.pdf
There is
probably a good explanation for the ADEV-level in standard
(pi-counting?)
reciprocal frequency counter mode as well as the roughly
1/sqrt(10) enhancement
in ADEV when increasing the gate-time 10-fold.
on another note:
The
discussion on phase-noise <-> ADEV calculations earlier was
interesting.
Datasets (synthetic or real) with known correct ADEVs and
phase-noise-spectra
would be a good addition to allantools and a motivation
to add code for the
phase-noise <-> ADEV
conversion.
cheers,
Anders
time-nuts
mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the
instructions there.
In message 973E79BB-7B83-40A8-9799-C3B072A68E9E@n1k.org, Bob Camp writes:
This is by no means a bash on the 53230. Properly fed, it’s a fine
device. Every fancy counter I’ve seen has these sort of issues one
way or the other.
Absolutely.
But I'm just trying to alert Anders that what he has measured is not
what he think he has measured.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.