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" <rich...@karlquist.com>
To: "Discussion of precise time and frequency measurement" 
<time-nuts@febo.com>; "Pete Lancashire" <p...@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


_______________________________________________
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.

Reply via email to