[time-nuts] Timelab and the 53220A - getting best results
kb8tq at n1k.org
Thu Jun 2 22:24:41 EDT 2016
If the counter is the limiting factor, it should scale by 10 as the timebase scales by 10. Your data goes from
90 ppt at 1 second to 9 ppt at 10 seconds. That is the expected outcome.
> On Jun 2, 2016, at 8:57 PM, Nick Sayer via time-nuts <time-nuts at febo.com> wrote:
> Oh, the limitation is on the TimeLab side? I was blaming the TIA. :)
> Since then, I have found an advanced gate setting that appears to add 500 ms after start. The time intervals seem to be without that delay, so it works. The resulting ADEV is unchanged (other than obviously truncated at low tau and having a longer duration).
> Looking at the phase and frequency data, I don't see anything wrong. The ADEV plot is linear, and it arrives to the spec at around tau 10s or so... It's just way steeper than I expect. An order of magnitude north of spec at tau 1s.
> The only thing I can think of is that it's compounding the error because I'm comparing two (of the same) oscillators to each other, but my understanding is that I can only attempt to compensate for that by scaling by sqrt(2).
> Sent from my iPhone
>> On Jun 2, 2016, at 11:12 AM, John Miles <john at miles.io> wrote:
>> One workaround for the 1-million point limitation on imported data is to use "Acquire->Acquire from live ASCII file" instead of "File->Import ASCII phase/frequency data." Most of the same code is used for both cases, but unlike the static file-import version of the dialog, the live data importer will let you specify the expected duration yourself. So you can give it a duration value that you know will be long enough to cover the whole data set.
>> I'm not too familiar with the 532x0A counters myself, but 8.9E-11 at t=1s doesn't sound too unrealistic. When in doubt, look at the 'f'requency and/or 'p'hase trends and residuals to sanity-check your data, rather than trying to puzzle out what's going wrong with the ADEV plot as many users seem to do. First you should satisfy yourself that the data makes sense, is unwrapped and scaled properly, and doesn't contain glitches, large crystal jumps, obvious beatnotes or other interference, or unexpected amounts of drift.
>> -- john, KE5FX
>> Miles Design LLC
>>> 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.
>> 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