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

Thanks for the data. Here is a paper that outlines some of your observations with some additional insight.

https://arxiv.org/pdf/1604.05076.pdf