I’ve gotten a little further with this. If I capture 60 seconds worth of time interval measurements (between two FE-5680As that are GPS disciplined, but with a long enough time constant that they’re basically free-running), I get 60,000 of them. So I imported at a sample interval of 1e-3 and got the right duration. There are a couple of problems, however. 1 is that even if I attempt to log to a USB stick, it appears I can only log 1e6 samples before it stops. That’s 16:40 or so, which isn’t very long. I haven’t figured out how to change the sample gate for time intervals (I’m assuming that a million samples is a hard limit). Also, importing the interval samples into TimeLab still shows me a graph that’s still much steeper than I would expect. The graph is linear, with points at tau 1s = 8.9E-11, 10s = 9.47E-12, 100s = 1.5E-12 (by then, the ADEV graph is starting to flatten out a bit, which probably indicates the noise floor of the 53220A near 1E-12), but the FEI datashe et shows a spec with points more like tau 1s = 1.5E-11, 10s = 4.5E-12 and 100s = 1.5E-12.
> On May 30, 2016, at 2:25 PM, Nick Sayer via time-nuts <time-nuts@febo.com> > wrote: > > 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 <anders.e.e.wal...@gmail.com> >> 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 >> <time-nuts@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@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> > > _______________________________________________ > 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. _______________________________________________ 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.
