[time-nuts] Recently acquired 53132A

[Tom Van Baak]

Rick,

The 53132A is a "12 digit/s" counter. Unless the frequency is really close to 10 MHz. Then it becomes a 11 digit/s counter. This is because it uses oversampling (IIRC, 200k samples/s) and it relies to some extent on statistics for its 12 digit resolution.

This technique does not do as well when DUT is too closely aligned in phase and frequency with REF. I mean, you can oversample all you want, but when the two clocks appear locked most of those samples are redundant; they offer no statistical advantage. Hence the reduced resolution. By a factor of 10!

The nice thing about the 53131/53132 is that this condition is recognized in f/w and the output resolution is pruned automatically. If you have long log files of an oscillator warming up you can see it quite nicely.

Note also that it's not just when DUT is 10 MHz or near 10 MHz; there are hundreds of magic frequencies where reduced resolution occurs: any rational fraction or multiple of that's within about 7 digits of 10 MHz. This is not undocumented. Buried in the manual is:

http://leapsecond.com/pages/53132/53132-reduced-resolution.gif

Also, the issue isn't unique to the 53132A. Any counter or software that uses oversampling has to face this effect [1]. That is, you can't blindly assume your resolution always improves by sqrt(N). As obscure as this effect is, I'm really impressed hp put so much thought into it. It's one reason I have a lot of trust in the 53132A.

Finally, at the risk of mentioning noise, measurement, and ADEV here, you can also guess that this clever oversampling measurement technique has ramifications on the fidelity of ADEV calculations made from frequency readings. Check previous posts, probably from Magnus, that discusses this [2].

/tvb

[1] One way to avoid or reduce the chances are to use an obscure frequency for REF. Another way is to deliberately apply carefully characterized jitter to DUT or REF during measurement. You can see the connection with DMTD systems, or TimePod.

[2] See papers like:

    "On temporal correlations in high–resolution frequency counting", Dunker, Hauglin, Ole Petter Rønningen (!!!)
    https://arxiv.org/pdf/1604.05076.pdf

    "High resolution frequency counters", E. Rubiola
    http://rubiola.org/pdf-slides/2012T-IFCS-Counters.pdf

    "The Ω counter, a frequency counter based on the Linear Regression", Rubiola, Lenczner, Bourgeois, Vernotte
    https://arxiv.org/pdf/1506.05009.pdf

    "Isolating Frequency Measurement Error and Sourcing Frequency Error near the Reference Frequency Harmonics"
    http://literature.cdn.keysight.com/litweb/pdf/5990-9189EN.pdf



----- Original Message ----- 
From: "Richard (Rick) Karlquist" <richard at karlquist.com>
To: "Discussion of precise time and frequency measurement" <time-nuts at febo.com>; "Pete Lancashire" <pete at petelancashire.com>
Sent: Monday, December 18, 2017 1:33 PM
Subject: Re: [time-nuts] Recently acquired 53132A


> I worked in the HP Santa Clara Division frequency counter
> section at the time of the development of the 53132A series, which had 
> the internal code name of "Major League Baseball".  IIRC, the external
> reference circuit in it was designed by a couple of
> engineers who had no background in time nuttery and
> did a mediocre job.  Someone else commented on a problem
> with it not wanting to measure 10 MHz correctly.  I
> never heard of that before, but it would not surprise
> me, because the main measurement engine was designed
> by a very excellent FPGA engineer without an extensive
> background in time nuttery.  The problem mentioned might
> have been too subtle.
> 
> The 53132 has many good points but is not perfect.
> 
> Rick