This is a follow-up to my earlier notes on the 53230A noise floor.
Naively I did the initial frequency-counting tests using READ?, which is wrong both because it produces data with dead-time and because the consensus for what is meant by Allan deviation assumes pi-counting.
Driven by marketing, no doubt, the 53230A employs internal averaging (something akin to lambda-counting) both with the simple READ? command and the continuous CONT mode mentioned in the manual. Amazingly you have to use the undocumented RCON mode to get pi-counting which will produce correct Allan deviations.
Here is a plot. The opportunity for making errors (with pi- vs. lamda-counting, and gap-free data) is less in time-interval mode, and I have indicated the 12 ps RMS noise floor (1.8e-11/tau in terms of Allan deviation) with a black dashed line. In RCON mode the noise floor has the same 1/tau dependence and I get about 3e-11/tau. If however you simply use the built-in settings of the counter with READ? or CONT you get a noise floor of about 2e-12/sqrt(tau) due to the internal averaging going on behind the scenes.
For a paper that explains pi- and lambda-counting see Dawkins2007 (fulltext PDF on ReaserchGate). Enrico Rubiola also has notes on counters.
Datafiles and script for ADEV and figure: 2015-06-18_rcon_cont.zip
One thought on “CONT vs RCON mode on the 53230A frequency counter”
Thanks for the data. Here is a paper that outlines some of your observations with some additional insight.