Dave, > My research concerns oscillator drift on time scales of ~1ms to ~10s, so > I'm guessing the 53131A with its 5-130ms of dead time isn't suitable for > what I'm trying to measure.
True. Try a fancy TIA (time interval analyzer) or MDA (modulation domain analyzer) instead. Or consider a high-res (tens of ps) timestamping counter capable of 1000 samples per second. The Pendulum CNT-91 may work. Also look into the Agilent 53230A which has a zero deadtime timestamping mode. The venerable SR620 is also capable of 1 kHz measurement rate, but I'm not sure if that's internal sampling or sustained data rate via GPIB. The TICC (designed by JohnA, distributed by TAPR) would also work to 1 kHz sampling if you rewrote the Arduino code. What kind of oscillator is it that you're trying to measure? Pendulum? Tuning fork? TCXO? Some SiLabs thing? That may make a huge difference in the type of gear you need or the measurement model. What timing resolution do you need at 1 ms sampling rates? > But I'd still like to know how folks are > getting around this dead time issue with the 53131A for their measurements > in hopes it'll shed light on how I can do the same without needing to pick > up more gear and the inevitable shipping delay that will entail. If zero dead time is important then make single-shot time interval measurements instead of using frequency or period mode. I do almost all my GPS/1PPS logging that way, using a 53131A like yours. But, as you surmise, you don't get anywhere near a 1 kHz sampling rate. > I'm still looking for the part in the manual where > HP/Agilent/Keysight owns up to this and describe how it changes the > measurement. By now there's a lot of literature, both marketing and technical, that describes in detail how regression-based frequency counters work. The 53131A was designed in the 90's before that literature was written. There's a key footnote in the manual from which you can infer all of this. For a summary see this posting, and the GIF: https://www.febo.com/pipermail/time-nuts/2013-August/079647.html Also if you look at the specifications pages (e.g., under RMS resoluion) you'll see a more explicit reference to the counter making 200,000 measurements per second. Putting all this together it's clear this counter does precise single-shot time measurements (compatible with ADEV) but it does regression-based frequency/period measurements, which may or may not be perfectly compatible with ADEV. /tvb ----- Original Message ----- From: "David Burnett" <d...@berkeley.edu> To: <email@example.com> Sent: Sunday, April 08, 2018 6:29 PM Subject: [time-nuts] ADEV dead time w/ HP 53131A & TimeLab > Hi time-nuts, > > I'm doing oscillator-related research for my PhD and found this list > recently. It's been a great resource in trying to refine my freq > measurement setup and in starting to understand what's really going on > inside my lab equipment. > > I've been trawling the archives and have a question about measuring ADEV > accurately with the Agilent 53131A frequency counter I have on hand. From > the comments on this list and elsewhere, and the fact that TimeLab will > talk to my 53131A directly, I have the impression one can use the 53131A > for period measurements with which to calculate ADEV. But from GPIB command > sniffing it looks like there's a lot of dead time between measurements: > -- In period or freq mode* measurements take an extra ~130ms longer than > gate time to return (but this seems to produce the correct measurements for > TimeLab); > -- in time interval mode they take about ~20ms; > -- in totalize mode they take about 5ms, in keeping with "200 measurements > per second" advertised in the brochure, but of course this is a simple > counter and one loses the resolution of a reciprocal counter or anything > smarter added in. > > Is it just generally assumed everyone is making period measurements on time > scales long enough that any instrument dead time is ignorable? Or is > TimeLab and everyone else silently applying the correction factor as > described by the Barnes & Allan NIST paper (NIST technical note 1318)? Or > is there a configuration mode I'm missing that prints measurements with > more regularly? TimeLab's GPIB commands seem to be limited to "get current > measurement" so I might not have the box set up right to start with. > > My research concerns oscillator drift on time scales of ~1ms to ~10s, so > I'm guessing the 53131A with its 5-130ms of dead time isn't suitable for > what I'm trying to measure. But I'd still like to know how folks are > getting around this dead time issue with the 53131A for their measurements > in hopes it'll shed light on how I can do the same without needing to pick > up more gear and the inevitable shipping delay that will entail. I suspect > someone will recommend that I get a time-stamping/continuous measurement > box, which is probably the best solution. But I'm hoping there's a way > around that in the short term so I can make these measurements sooner. > > 73, > Dave > > * Others on this list have warned about using this mode because the machine > does a lot of averaging but it seems like TimeLab needs the box to be in > this mode regardless. I'm still looking for the part in the manual where > HP/Agilent/Keysight owns up to this and describe how it changes the > measurement. > _______________________________________________ > time-nuts mailing list -- firstname.lastname@example.org > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- email@example.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.