Hi 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.
Bob > On Jun 2, 2016, at 8:57 PM, Nick Sayer via time-nuts <time-nuts@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 <j...@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@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.
