[time-nuts] Timelab and the 53220A - getting best results
nsayer at kfu.com
Thu Jun 2 11:15:33 EDT 2016
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 datasheet 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 at 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.wallin at 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).
>> 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.
> 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