Pete,

I don't recall that anyone complained much about the old 53132A, the counter that you have.

The discussions we had about external reference a while ago were about new 53230A. There's nothing wrong with it, I mean, it's a very nice counter, but since it's a fancy, new design, high-end, 20 ps counter some of us had equally high expectations about the purity of the input or output reference, or other subtle details of its operation.

/tvb

----- Original Message -----
From: "Pete Lancashire" pete@petelancashire.com
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Monday, December 18, 2017 11:23 AM
Subject: [time-nuts] Recently acquired 53132A

Hi

The 53132 is the older version of the 53230 counter. It’s been out of production
and past "end of life" support for quite a while now. It’s main issue measurement
wise is a group of issues that make it less sensitive (lower resolution) than one
might think right at 10 MHz and to a lesser extent at 10 MHz / N or 10 MHz * N.
There is no known “fix” other than running it with a reference that is detuned a bit
from 10 MHz. That obviously has some issues all by its self. I suppose a fix could
be to not measure 10 MHz ….

The biggest failure point in the counters that I have seen has been the power supplies.
They apparently came as a completed module from an HP supplier. One wonders who
that might have been …. I would strongly recommend taking a look at yours to be sure
the water did not damage the board. I would also make sure the fan is clean and
operates correctly. Clogged fans lead to dead power supply boards ….

All that said, it’s a pretty good counter. I’m not sure it is worth a crazy price, but there is
a price I would gladly pay for one. They all will eventually die as the las of the VFD displays
wear out. At that point, hopefully we all will be running them via serial or GPIB and
not even notice the issue.

Lots of Fun

Bob

Tom,

I should have re-read the model number, no wonder I could not find anything.
Hopefully still a good $100 investment.

On Mon, Dec 18, 2017 at 11:43 AM, Bob kb8tq kb8tq@n1k.org wrote:

Bob,

I took the cover off, looks like the moisture inside the box was not that
bad, can't see anything
with corrosion, rust, oxides etc. And my first test sticking my head in the
box and sniffing for
the usual mold/mildew smells.

On that VFD .. I totally agree my a 3324A and a 8664A are pretty much no
longer have a disply,
found a hanger queen with a good display for the 8664A but the 3324A is now
pretty much remote
only, or push buttons and hope for the best.

On Mon, Dec 18, 2017 at 11:54 AM, Pete Lancashire pete@petelancashire.com
wrote:

Hi

If it is in working condition and stays in working condition, anything under $300 is
a very good deal.

Bob

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

On 12/18/2017 11:23 AM, Pete Lancashire 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.

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@karlquist.com
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com; "Pete Lancashire" pete@petelancashire.com
Sent: Monday, December 18, 2017 1:33 PM
Subject: Re: [time-nuts] Recently acquired 53132A

Thank you Tom.
Very informative, sadly no simple answer to overcome the shortcoming. After move, downsizing and age I imposed on my self a buy stop that I keep braking. I did buy this year two 53132A's mainly because of the RS232 interface. Before I had excellent results with a combination Tracor 527 E and the HP 5345. I remember I paid a fortune but it still works and I use the 40 GHz head. I did discover the Tbolt jumps and the FE 5680 jumps with that setup. Years ago Richard MCC programmed for me what we call the Austron counter using one PIC and a board pulled from an Austron unit that generates a 1 MHz with a 100 Hz offst. Austron uses a D F/F for mixing. We have revisited that circuit over the years at least 10 times and now  have a counter for 5 and 10 MHz with a resolution of 1 E -12 at 0.1 sec all the way up to 1 E-15 at 100 seconds using a single analog mixer. We discard the last decimal. Goal to replace the Tracor 527 E and fan noise of the HP 53132. If any one is interested please contact me off list
Bert Kehren
In a message dated 12/18/2017 4:27:40 PM Central Standard Time, tvb@LeapSecond.com writes:

 
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@karlquist.com
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com; "Pete Lancashire" pete@petelancashire.com
Sent: Monday, December 18, 2017 1:33 PM
Subject: Re: [time-nuts] Recently acquired 53132A

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.

Hi,

On 12/18/2017 11:27 PM, Tom Van Baak wrote:

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.

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.

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

Another good read.

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.

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