The 1 PPS outputs come directly from the GPS modules, so they’re not interesting for me. I’m trying to evaluate the oscillators post-discipline.
I think the datasheet for the 53220A implies that no-dead-time measurement is a value-add feature that the 53220A lacks. If I were going to upgrade, it would be to a TimePod, but I can’t justify that today. I have discovered the data logging feature, but the problem now is that it doesn’t tell me what the sample time is. It appears the solution to that is to simply divide the run time by the sample count. I’ve got a run going now and am going to try that. I could just go back to straight frequency counting, but then I have two quantities - gate time and sample rate (where 1/sample rate > gate time). For example, with a gate time of 0.5s, I get a sample time of around 0.75s or so (caused by the over-the-network acquisition method used by TimeLab). Is that reducing my acuity unduly? > On May 29, 2016, at 10:34 PM, Anders Wallin <[email protected]> > wrote: > > 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.
