[time-nuts] Recently acquired 53132A

[Magnus Danielson]

Hi,

On 12/18/2017 11:27 PM, Tom Van Baak wrote:
> 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.

It's really not due to oversampling. It is really an inherent effect of 
all counters. The oversampling and filtering done to improve frequency 
reading is just not algorithmically efficient when the systematic 
sampling spread goes outside of the time-window that the filter represents.

It does not care if the averaging is done in the counter or in the 
post-processing, the effect will be there. It will also eat you as you 
compare ADEV and MDEV, because MDEV does an averaging before the ADEV 
processing core.

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

Yeah, I keep study obscurities like these. :-)

The references given is good food for thought. I also made a paper and 
poster presentation for this summers event on the interaction of noise 
and time quantization, and it doesn't quite as people assume. I think 
only a few got the full lecture I was giving there. More to be written, 
more to be explained.

If I only had more time to do this stuff.

Anyway, the filtering of the counters as they do averaging causes a bias 
to ADEV, but their main effort is to filter out noise. The trouble is 
that the quantization noise isn't random so your milage may vary in 
fighting it. Turns out more actual noise helps to get better higher tau 
resolution, allowing MDEV or PDEV to go deeper than ADEV. Things just 
doesn't work the way you expect. Thus, ADEV can be "captured" by the 
systematics and short-tau MDEV and PDEV too.

> /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

Look closely at what you have, they have.
I had to point people to the poster-presentation of this at EFTF in York.

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

Another good read.

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

The Delta-counter is also a good read-up. The Omega counter is the 
linear regression / least square estimator. I presented an accelerated 
version of this last year at EFTF and IFCS.

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

Thanks for that reference, I had lost track of that paper and I need it.

Now, why does it look like DDS noise? ;-)

Cheers,
Magnus

> 
> 
> ----- 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
> 
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>