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