[time-nuts] How to measure Allan Deviation?

Didier Juges didier at cox.net
Mon Oct 23 22:15:09 EDT 2006

Hi Tom,

comments are embedded:

Tom Van Baak wrote:
> Didier,
> I've been out of town and I see a flurry of postings to
> your original query about Allan deviation. It sounds
> like your goal is to measure the stability of various
> oscillators that you have lying around?
That's what happens when you go on vacation :-) and the answer is yes...
> First, your 5370 or any other TIC (Time Interval Counter)
> will be adequate for this. I'd suggest using a 'scope on
> the input channel(s) to make sure your signal and trigger
> levels are what you think they are. Outliers or high 5370
> STDEV is a hint of poor triggering.
I do not understand the signal on the rear trigger outputs. At the 
moment, I have a single 10 MHz sine signal fed to the START channel, and 
the 5370 is set to  TI, MEAN, SAMPLE SIZE 1, + TI ONLY, START channel 
triggers on rise and STOP channel triggers on fall, and START COM is 
selected. The instrument displays about 60 nS (fairly stable, 150 ps 
jitter) or so at the moment. The rear  START trigger shows a negative 
going pulse (400uS wide, at 62 mS rep rate), with the rising edge 
(positive going) synchronous with the 10 MHz signal and the phase is 
adjustable using the *STOP* trigger level! When I trigger the scope on 
the falling edge of the START trigger output, the 10 MHz signal seems to 
drift, and the trigger setting has no effect, except that if adjusted 
too far, the instrument stops updating the display.

Apparently, the START trigger adjustment has no effect on the timing of 
the rear START trigger output, but will cause the display to freeze if 
the START trigger is set to either extreme, even though the START 
trigger output on the rear does not change.

The STOP trigger output works the opposite: it responds to the START 
trigger level. Could it be that the outputs are reversed on my instrument?

I am not sure this is a complete description, and maybe there is an 
obvious answer that I am missing, but I am perplexed.
> It sounds like you have the computer data logging part
> solved. Most ADEV tools take accumulated phase
> difference data; just the data that a 5370 in TI mode
> will generate.
It seems simple, but it would help to have a short sample file suitable 
to feed into your favorite ADEV program just to make sure I have the 
format right. It seems like I will be trying AlaVar and Plotter.
> Second, your Jupiter GPS board, or any other sub-100 ns
> GPS timing board, will work fine. Use the 1PPS output.
Good, thanks
> You don't have to build a GPSDO in order to make the
> measurements that you want! In fact, it may only get
> in the way. Instead, consider these two points.
> 1) For short-term stability tests, just make a set of
> quick pair-wise measurements between stand-alone
> oscillators at short gate-times. If they are close in
> frequency, or can be made close in frequency, then
> the 5370 built-in STDEV statistic is useful in real-time
> (use an N or 10 or 100). If not, collect raw phase data
> and run it through your favorite ADEV tool.
I guess I could collect the STDEV values via GPIB and plot them.
> This method should work fine for fractions of a second
> to 10s or 100s of seconds.
> The good and bad pairs will be obvious; in a matter of
> minutes you can tell which one or two oscillators are
> the best, short-term.
> Remember that your measurements are the RMS sum
> of both oscillators and the counter itself so there will be
> limits to the resolution, especially visible at short times.
> 2) For long-term stability measurements, one at a time,
> compare your oscillators against the raw GPS 1PPS,
> collect phase data, and run it through your ADEV tool.
> To avoid phase wrap-around, depending on the frequency
> offsets, you may need to divide the 5/10 MHz oscillator
> down to at least the kHz range, or the obvious 1PPS, to
> get clean phase measurements.
> Let the GPS 1PPS be the start channel. For this sort
> of long-term measurement any TTL/CMOS homebrew
> divider will work (the jitter and tempco are in the noise).
If I understand correctly, if I use the 1 PPS as the start channel, I 
only need to divide the 10 MHz down to something like 1 or 10 kHz, 
depending on the observation window and the frequency difference. 
Someone else offered the same trick, so it sounds like a good idea.
> It's OK to average the samples down by 100 to 1000
> to reduce the volume of data you collect or process.
> I often use something around 300 (5 minutes).
There seems to be a common agreement about that.
> This will give you frequency offset, mid- to long-term
> stability, and frequency drift information. A couple of
> hours or days of data per oscillator should be sufficient.
I like that better than weeks or months. At least, I am sure it will be 
a while before I am at the point of having to collect data for months 
before I can tell my oscillators apart...
> Again, you don't need to build a GPSDO for any of this.
> /tvb
Thanks a bunch, but the whole point of this is to pick the best OCXO to 
make a GPSDO :-)


More information about the time-nuts mailing list