HP53310A and other counter Allan deviation

[maxwell3e10]

I have been playing with HP53310A modulation domain analyzers for a while, now have 4 of them counting work and home! One thing I wanted to test is running them as a simple counter.

The simplest way to set it this way is using Fast Histogram without accumulation and using  FETC:FREQ:MEAN? GPIB command to get the frequency. To test the counter, apart from the timebase, I use its own 10 MHz reference as the input. Mine has the temperature-stabilized time base option.

Here is a plot for a few different settings. 100msec x 6 means it uses time interval of 100 msec for each frequency measurement and then returns the mean of 6 such measurements. Overall, the performance is pretty good, with about 10^(-12) scatter at 1 sec.



I'd be curious if anyone can perform similar measurements on 53230A and other counters. I don't think such data have been posted here before. It evaluates the time jitter and the "ehnanced resolution" algorithm. Just hook the reference output to the input and use gate time on the order of 1 sec or a little longer.

[awallin]

time-interval and default frequency counting mode of the 53230A
http://www.anderswallin.net/wp-content/uploads/2015/04/Keysight_53230A_noise_floor.png

RCON mode (which is the simple one to understand...). The default CONT mode does some kind of fancy filtering ('omega'-counter maybe..) which is a bit complicated..
http://www.anderswallin.net/wp-content/uploads/2015/06/RCON_vs_CONT.png

If you can post your results as dimensionless ADEV then we can compare.


AW

[maxwell3e10]

Thanks for the link. Also I found https://arxiv.org/abs/1604.05076 which analyses some funny behavior of the CONT mode.

The 53310A looks to be comparable or even a little better at short times. Its intrinsic time resolution is about 60 psec, a factor of 5 worse. So it must have a better implementation of the Omega or Lambda counting technique. Note that in the 53230A data the initial point of Allan deviation improves with gate time as 1/T. It should be 1/T^(3/2) if the enhanced counting is fully implemented. A good reference for this is https://arxiv.org/abs/1506.05009

[maxwell3e10]

A little better data for the HP53310A. I discovered it's quite sensitive to temperature and seems to be less noisy at 23C than at 19C.
For gate time of 8.5 sec (overall measurement time of 10 sec), I am getting fractional standard deviation of 8.3x10^-14, substantially better than reported for 53230A.  Can any other counter beat it?

[maxwell3e10]

I took more data with the HP53310A counter using continuous frequency measurements. Its a bit annoying to get the data off the counter. It can only record frequency continuously for a maximum of 800 sec into memory and the vertical resolution is limited to about 8 bits (zoomed to a chosen frequency range). SerialPlot is a very helpful program in reading binary data over GPIB-USB-serial adapter https://bitbucket.org/hyOzd/serialplot/src/default/

But the performance of the counter is quite impressive! It can achieve resolution of 10^-12/tau(sec) over a time scale from 0.1 to 100 sec. The Allan variance goes as 1/tau, indicating that the measurements are indeed continuous. At the same time, it is using an enhanced resolution counting technique, so the performance is more than a factor of 100 better than one would get with start and stop edge timing and 65 psec time resolution.



So the performance of HP53310A is a factor of 2-3 better than for the newest  Kyesight 53230A.  It seems to be like the HP3458A for frequency measurements, an unsurpassed piece of old technology.  The difference is that is that it is a relatively obscure instrument, so one can get it on ebay for as low as $100.

[jpb]

I'm in the middle of doing some Allan deviation tests on my GPSDO so can't set up a comparable measurement, but I attach a graph of my noise floor with an FCA3100 counter plus a mixer and Agilent 33522A providing a LO and (for the noise floor) the 10MHz being measured. The zero crossing is with a LTC6597 demo board. I tried various "gains" by making the LO 9MHz, 9.9MHz and so on and found that 9.9MHz was about optimal.

The resolution of the counter (one shot) is 50 psecs, so the natural resolution at 1 sec should be 5 x 10^-11. The theoretical gain of 100 should make that around 5 x 10^-13 but the reality is 1.8 x 10^-12.

It would be better to use a double balanced mixer approach but this single mixer seems to work well enough.

It is all a bit heath robinson, but that is part of the fun.

I should have added the GPDSO is reference to the counter and the output reference of the counter is used as an input reference on the 33522A. The measurements were period back-to-back with time stamp.

EDIT : I allowed the measurement to run for another 12 hours or so and have extended the plot as shown, interestingly this has also reduced the noise floor at high tau and slightly reduced it even at low tau - guess more samples is reducing the effective variance of random noise.

[jpb]

I also attach a plot of the standard Alan Deviation to perhaps better match other plots. I had to add a new post as my attachment size exceeded the maximum allowed.

[maxwell3e10]

Thanks. What mixer are you using?

Tektronix FCA3100 I think is a rebadged Pendulum instruments CNT-91. It can provide either enhanced resolution counting or continuous back-to-back counting but not both at the same time. One trick described here https://arxiv.org/abs/1604.05076 is to use relatively short counting interval and then use a moving average.

[jpb]

Thanks. What mixer are you using?

Tektronix FCA3100 I think is a rebadged Pendulum instruments CNT-91. It can provide either enhanced resolution counting or continuous back-to-back counting but not both at the same time. One trick described here https://arxiv.org/abs/1604.05076 is to use relatively short counting interval and then use a moving average.

Yes it is a rebadged Pendulum - some of the literature still has the Pendulum model number where it has been transferred by Tektronix and the editor didn't spot it! I went with it because I could get it ex-demo with warranty for less than half the price of an 53230A though I suppose, since it has half the resolution (50 psecs instead of 25 psecs) you get what you pay for. I'm generally happy with it but I'm only just getting around to programming it via the USB and VISA library calls even though I've had it over three years. My day job is being a programmer so I don't have that much energy to do it in the evenings for my hobby.

The mixer is a mini-circuits ZLW-1SHB the datasheet for the newer + version is here (I bought it as new old stock off ebay) :
https://www.minicircuits.com/pdfs/ZLW-1SH+.pdf

It is 17dBm which is a little high but ok for the 33522 and provides a little more output than my other mixers which are mainly 7dBm variants.

I'd improve the noise floor if I used a double balanced mixer approach but then I'd have to probably divide down further and use A to B channels and have to worry about cycle slips and so on. It is something I plan to work on. I don't really have any references that require a very low noise floor (unfortunately). I'd also probably have to work on a different zero crossing approach or use a sound card and cross correlation (I've seen a Chinese paper on this approach).

Thank you for the link to reference, it looks like interesting reading.

One thing I've discovered empirically is that the intelligent frequency mode (where it uses linear interpolation to get a more accurate average frequency) tends to mess up the Alan Deviation and is best avoided.

[jpb]

Tektronix FCA3100 I think is a rebadged Pendulum instruments CNT-91. It can provide either enhanced resolution counting or continuous back-to-back counting but not both at the same time. One trick described here https://arxiv.org/abs/1604.05076 is to use relatively short counting interval and then use a moving average.

Interesting article - the CNT-91 is noisier but doesn't have the intrinsic bias shown by some modes of the Keysight/Agilent/HP 53230.

I'd still like to have a 53230 but I'm given budget constraints I am happy with my choice of the FCA3100 aka CNT-91.

[maxwell3e10]

Here is the data for Picotest/Array U6200 counter. It is a little better than HP53132A. The time resolution is about 35 psec. At 1 sec gate time the frequency resolution is 2.5x10^-12. The U6200 can't make continuous frequency measurements, but it can make enhanced resolution frequency measurements for gate times down to 1 msec.

For reference, here is a measurement of the noise floor of HP53132A, https://timeokitalia.files.wordpress.com/2015/08/timeok-time-and-frequency-house-standard-v-2-0.pdf, At 2 sec gate time it is equal to 2.1x10^-12.

So, HP53132, Keysight 53230 and U6200 are not all that different from each other and HP53310 is a little better.

For real time-nuts, there is the K+K FXE counter http://www.kplusk-messtechnik.de/products/fxe_19.htm. It has a time resolution of 12 psec and frequency resolution of 3x10^-13 at 1 sec. So the time resolution is similar to Keysight 53230 but it can achieve a better frequency resolution by properly implementing Lambda or Omega counting. There is evidence that in Keysight 53230 this algorithm is just not implemented properly: https://arxiv.org/abs/1604.05076. Perhaps it could be fixed in the future with a firmware update?

Another approach for precision frequency measurements is digital demodulation, as implemented in TimePod 5330A, http://www.miles.io/timelab/beta.htm. It can achieve frequency resolution of 8x10^-14 at 1 sec integration time!

[awallin]

Another approach for precision frequency measurements is digital demodulation, as implemented in TimePod 5330A, http://www.miles.io/timelab/beta.htm. It can achieve frequency resolution of 8x10^-14 at 1 sec integration time!

We have some preliminary results with Ettus USRP SDRs and GNU-radio flowgraphs that give xe-14 @ 1s (in 0.5 Hz BW) numbers for the noise floor.
see e.g. https://arxiv.org/abs/1605.03505  and  https://arxiv.org/abs/1803.01438
the trick in this approach is bandwidth-reduction by a factor of 1e6 or so, which reduces the ADEV by a factor of 1e3 (or so).
also doable (maybe simpler?) with a scope/digitizer: https://arxiv.org/abs/1711.07917

[Gerhard_dk4xp]

>  also doable (maybe simpler?) with a scope/digitizer: https://arxiv.org/abs/1711.07917

I haven't had my 2nd cup of coffee this morning, but it seems that this could be
implemented on a Red Pitaya without any additional hardware.
From SMA inputs to the web server for the results.

    Gerhard

( I have a HP 53310A, too. Seldom used.)

[maxwell3e10]

I continue to study HP53310 as some kind of lost ancient advanced technology, which in a way it is. I looked at the limits of the enhanced frequency counting technique as implemented in HP53310. Typically there are two limits: maximum frequency at which one can still count all the zero crossings and minimum gate time for which one can still implement the algorithm. In both cases HP53310 surprised me.

If one looks at the fractional frequency uncertainty for a fixed gate time, it should improve as 1/sqrt(f) with frequency because there are more zeros to average until one reaches the maximum zero sampling rate. The maximum sampling rate of HP53310 is specified as 1 or 1.25 MHz. Yet, the frequency uncertainty continues to improve until 10 MHz. So, HP53310 is able to time stamp and average all zeros at a rate of 10 MHz. In contrast, Keysight 53230 has maximum time stamping rate of 1 MHz and HP53131, Picotest U6200 and Pendulum CNT-91 are limited to about 200-300 kHz. You can see the performance of U6200 is leveling off beyond 300 kHz.



The other limit is how well the enhanced counting technique works for short gate times. Here one can see that it works down to about 5 microsec for HP53310. Again all other counters only implement it for gate times longer than 1-100 msec. For this test I used a 10 MHz square wave with Gaussian noise added to it, so the pulse width resolution is 1 nsec. Here one can see how much the enhanced counting technique can gain relative to simple interval counting, more than 3 orders of magnitude.

[kj7e]

Looking forward to playing with mine, should be here tomorrow.

[maxwell3e10]

So what precisely is the counting algorithm used in HP53310? I try to figure out by applying a 10 MHz signal with a 500 Hz square wave frequency modulation. The counter is set to auto sampling with manual sampling interval of 100 usec. The data looks like this:

You can see that each transition is 2-3 points wide.  Also note that even though the period of 2 msec is a multiple of the sampling interval of 100 usec, the transition points don't line up, so each sampling interval is not precisely 100 usec, only on average so.

The counter can produce a nice histogram of the data, like this:


To get the counting weight from it, one has to first do a cumulative integral of the histogram, then exchange x and y axes of the plot, and then calculate the derivative. The result looks like this:


I was surprised when this nice plot appeared, it's like decoding a secret message!

So the counting method is a truncated Lambda scheme.  It uses a total of 3 times the specified sampling time interval t. Zero crossings at times from -1.5 t to -0.5t are subtracted from the ones from 0.5 t to 1.5 t and averaged together. The difference between every pair of zero crossings is 2 t. One can show that this is the most efficient simple accumulation scheme. The fractional frequency uncertainty is given by dt/(2 t)/sqrt(f t), where dt is the uncertainty of a simple pulse width measurement. If one scales to the total measurement time, the traditional lambda scheme gives a prefactor of sqrt(8 ), truncated lambda gives sqrt(6.75) and optimal linear fitting gives sqrt(6).

Looking at the plot from previous post, one would expect the simple gate time measurement with uncertainty 10^-9/tau to translate into 1.6x10^-13/tau^3/2 for the enhanced scheme at 10 MHz. Instead, we measure almost exactly a factor of sqrt(2) more, 2.2x10^-13/tau^3/2. This persists for all frequencies, so apparently HP53310 measures every other zero crossing. This would make sense based on careful reading of the datasheet. In the +TI Fast histogram mode it can make measurements at 2.5 MHz. Since each TI measurement requires 2 zero crossings, it implies that 5 MHz is the maximum zero crossing measurement rate.

So HP53310 implements a very efficient counting scheme and can measure zero crossings at a rate up to 5 MHz. But it counts only every other zero crossing. Also the time interval value is misleading, the total measurement time for each point is equal to 3 times time interval setting.

[maxwell3e10]

I have discovered that the power supply in my hobby HP53310 was slowly dying from leaking capacitors. Even though it was not producing obvious errors initially, it affected the stability of the -12V rail and the stability of the frequency measurements. After I replaced the capacitors and cleaned the board, the noise floor performance has improved. Now one can realize 3x10^(-13) Allan deviation at 1 sec. Interestingly, the Allan deviation of  back-to-back Lambda counting seems to improve as t^(-3/4) now. I have to think if it makes sense.

 

[mark03]

I recently fired up my 53310A to help me tune an Ebay OCXO and study the drift over time.  Since the last time I used it, I have acquired both a GPSDO and GPIB capability, so my renewed interest in long-term stability measurements led me to this thread.

@maxwell3e10, did you make any further progress reverse-engineering the undocumented GPIB commands in the HP software, as mentioned in the other 53310A thread?  I would be curious to know what options exist for using this as a logging TIC for Allan variance measurements.

Also, if you could share your code / methodology for the counter self-noise graphs, I'd be happy to measure my 53310As for comparison.

Edit:  I'd also be happy to sift through the Visual Basic code for that HP package.  I've never used VB but would be interested to see if a Python re-write is easy/feasible.

[maxwell3e10]

I have found a computer old-enough to run the phase analysis software. It can do time stamping and report the results. The time resolution is about 70 ps and the maximum number of points is 32000 (with extended memory option). So, it can be used for continuous time stamping, but with limitations on the length of the recording. I will be happy to send you decompiled code, which is relatively understandable.

Another option for relative time measurements is to use the TI mode and measure the time between two nearly identical sine waves zero crossings. One can set a histogram to average the time intervals and read them over GPIB at some rate. This method will have indefinite length but gaps in the measurements.

[mark03]

I didn't realize the 53305A software supports multiple counters.  There are references to 5372A and others in the code.  That will make it harder to identify any undocumented GPIB commands, as something not listed in the 53310A programmer's reference might be for a different piece of equipment.

The UCIC (universal counter integrated circuit) appears to have its own assembly language, and the program is loading it with custom microcode.  On some platform, anyway.

When you set up an Allan-variance measurement in the HP software, are there any indications it might be doing something "clever" that couldn't be accomplished with the documented commands alone?

[maxwell3e10]

Yes, I was able to follow the logic of the program to figure out which commands correspond to HP53310 and execute some of the commands for UCIC by hand. It appears to collect and return the times of zero crossings, which is not possible based on documented commands.

One can calculate the Allan deviation based on frequency measurements using just documented commands.  So, while the 53305 software provides additional information, its not necessary for frequency Allan deviation measurements.

[artag]

I had a poke around the 53310a ROMs, just out of interest.

A few strings are in the attached file - probably the most notable is the parse table for the SCPI command structure. I haven't tried to compare it to the documented command set but there may be a few hints - like the 'bread' command as the full form of 'bre'. Probably 'byte read', or perhaps 'block read'.

Then there's the project team list at the end :

***** SIXX *****
    Derek Alvis   
    David Clark   
    Lee Cosart   
    Larry DaQuino   
    Keith Ferguson   
    Hans Jekat   
    Sook-Lan Loh   
    Ray Moskaluk   
    Dick Schneider   
    Mike Wilson   
    and the entire   
    STONEHENGE team   
 
 53310a-roms.txt (21.38 kB - downloaded 137 times.)

[maxwell3e10]

Stonehenge is appropriate now, those guys did an amazing job that is yet to be replicated with more modern technology.

[maxwell3e10]

For completeness, here is a comparison of standard deviations of 53230A and HP53310A for equivalent gate times. I posted a brief review of 53230 here: https://www.eevblog.com/forum/testgear/keysight-53230-frequency-counter-review-and-bug-identification/. Despite having a better raw time resolution, it can't quite beat 55310A except in having more memory.