[time-nuts] Timelab and the 53220A - getting best results

Anders Wallin anders.e.e.wallin at gmail.com
Mon May 30 01:34:04 EDT 2016


A time-interval measurement between 1-PPS outputs of your two clocks is the
most straightforward to interpret.
With the 20ps 53230A I get a noise-floor of about 1.8e-11/tau(s) for this
measurement.
I haven't tried the 100ps version, I suspect the hardware is identical and
HPAK just de-rates the spec/firmware to 100ps in order to 'segment the
market'.

In frequency counting mode things are tricky because it does some sort of
omega-counting in default (CONT) mode.
This makes the effective bandwidth depend on the gate-time. (see 2nd image
of 2nd link).
The pi-counting mode is called RCON and is undocumented AFAIK. I got
3e-11/tau(s) with a 1s gate time and here I would expect noise-floor
measurements to fall on this same line independent of gate time (I haven't
verified this).

http://www.anderswallin.net/2015/06/cont-vs-rcon-mode-on-the-53230a-frequency-counter/
http://www.anderswallin.net/2015/04/keysight-53230a-noise-floor-test/

Anders


On Sat, May 28, 2016 at 7:11 PM, Nick Sayer via time-nuts <
time-nuts at febo.com> wrote:

> So far, I’ve been configuring my 53220A for frequency measurements with a
> 500 msec gate time, and using the external reference and one input.
>
> If instead I send the two devices into inputs A and B, and ask for the
> time interval between the two and give that to Timelab, my results look
> quite a bit worse.
>
> At the moment, I’m doing that with a pair of 5680As. The ADEV at 100s is
> reasonably close to the spec at 1.83E-12, but the tau at 10s is what it’s
> *supposed* to be at 1s: 1.43E-11. At 1s, it’s 1.42E-10. The line is quite
> linear between those points, but the slope is way off the spec. The
> frequency difference graph supports this view - it shows a ±2E-10 “haze.”
>
> I don’t have any reason to believe either oscillator is misbehaving to an
> extent that would explain this. I’m fairly sure I’m making some kind of
> fundamental newbie mistake and the test setup is introducing some sort of
> error, or I’m inside of the uncertainty of the 53220A and that’s why it’s
> showing poorly at low tau. My money is on the former. :)
>
> The behavior I see suggests that how Timelab works with the 53220A is that
> it sends a command to obtain a single measurement over and over again.
> Thus, the network latency figures into the measurement timespan, I think.
> I’m sure there’s a way to record measurements in the 53220A internally and
> then export that file into Timelab, but I haven’t figured that out yet.
> _______________________________________________
> 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.
>


More information about the time-nuts mailing list