[time-nuts] How to measure Allan Deviation?

Dr Bruce Griffiths bruce.griffiths at xtra.co.nz
Sun Oct 22 19:19:24 EDT 2006

Didier Juges wrote:
> More comments embedded...
> Didier
> John Ackermann N8UR wrote:
>> Didier, a few comments embedded below.
>> John
>> ----
>> Didier Juges said the following on 10/22/2006 10:34 AM:
>>> Hi Warner,
>>> Does it mean I should divide the 10 MHz down to 1 Hz output and use the 
>>> 5370 to measure TI compared to it's internal timebase once per second, 
>>> and feed that to the computer, store it to a file and feed the output to 
>>> AlaVar? (obviously, the divider would have to use synchronous counters)
>>> Or should I work directly on the 10 MHz output? The 5370 can average up 
>>> to 100k samples, so by averaging 100k samples and polling the GPIB 
>>> once/sec, would I be correct if I use the computer to average those 
>>> further down to 2/sec, 4/sec and so on as needed before feeding the data 
>>> to Alavar?
>> Ideally, you want to reduce both the device under test (DUT) and the
>> reference to 1 PPS.  The GPS can give you that directly, and you can use
>> some sort of divider to reduce the DUT from its nominal frequency.  Not
>> everyone does it the same way, but there seems to be a convention that
>> the reference signal is applied to the "stop" input of the counter, and
>> the DUT to the "start" input.  You want to bump the phase of the pulses
>> so that the initial time difference is relatively small -- ideally, not
>> more than a few hundred microseconds.  This will reduce the impact of
>> any noise or offset in the counter's reference.
>> It's possible to use 1PPS from the reference, and a higher frequency
>> (even 10MHz) from the DUT, but I've never had a lot of luck doing this.
>>  It's way too easy to slip a cycle and get artificial phase jumps.
>  From your comment, I gather that if the oscillators to be compared are 
> not on the same frequency, problem might ensue, so the 1 PPS output is a 
> much better option than the 10 MHz.
> If I use a 1 PPS signal for both oscillators, as long as they do not 
> drift by 1 cycle during the sample period, we should be OK.
> So the best would be to be able to reset the divider (that takes the 
> crystal down to 1 PPS) synchronously (or with a small delay) with the 1 
> PPS output of the GPS, then I should be good for a while. If I get the 
> OCXO within 10-6, I should be good for 10^6 seconds before skipping a 
> cycle (assuming the drift is in the proper direction....)
>>> Now, let's assume I have a big hard drive (250 GB + 120 GB at the 
>>> moment, with probably close to a total of 200 GB available), other than 
>>> computing time (which may not be negligible), how can I determine the 
>>> best acquisition interval? (as the one that will give me meaningful data 
>>> in the shortest amount of time)
>> Even with the 5370's 20ps resolution, you won't be able to measure good
>> DUTs below about 100 seconds averaging; the trigger jitter and other
>> noise will get you unless you go to something sophisticated like a
>> dual-mixer time-difference system (which isn't as easy to implement as
>> it appears at first glance).
>> So, I normally average data for 100 seconds and then log those averages.
>>  You can use the counter's internal average command, or just capture
>> each data point and average in your software.  I output a data file with
>> the MJD and phase value.  That data file then feeds whatever analysis
>> tool I'm using at the moment.
> So every 100 seconds, you log the average data collected at the 1 PPS 
> rate, for a few months.
> How long before you have something that is at least worth looking at 
> just to make sure it is working?
> (my type A personality does not deal with experiments lasting months too 
> well :-)
> I remember seeing some postings about MJD being in a particular format. 
> I will look in the AvaTar help file, I believe I saw something about that.
> A sample file would be helpful.
> So I gather this procedure will measure the sum of the variations of 
> both oscillators. By using three oscillators, and measuring them 2 at a 
> time, after 3 measurement cycles, I should be able to determine the 
> performance of each oscillator. At least that's all I remember of 
> statistics classes. How to do that escapes me at the moment.
> Maybe it would be simpler to buy an FRK Rubidium oscillator on eBay. How 
> do these compare to a 10811 in the short term and the long term?
>>> I understand AlaVar only works in batch mode (no real time capability), 
>>> so I have to collect a certain amount of data "blindly" before I can 
>>> find out if it is any good. If I am checking a GPS disciplined 
>>> oscillator, that will take several hours at a time and I am trying to 
>>> speed up the process, at least to make sure the procedures and 
>>> algorithms are OK.
>> This is an avocation for the patient. :-)  My current experiment logging
>> 2 HP5061As and an HP5065A against GPS has been running for about 90 days
>> now, and I hope to get at least another 30 days before I have to stop to
>> make some equipment changes.
> Roger that, see my comment above.
> I have an older laptop and spare GPIB/serial controller that I can 
> dedicate to the task. I will set that aside so I am not tempted to mess 
> with it while it collects data.
> I must make sure my battery backup system is working (the 5370A draws 
> 200 VA), and I'll be listening to 6m in the mean time (talking about 
> patience :-)
>> John
> Thanks a lot
> Didier
> _______________________________________________
> time-nuts mailing list
> time-nuts at febo.com
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Since the 5370 is relatively old and uses the same processor for 
communication and measurement, it cannot overlap measurement and data 
Thus it is desirable that the two PPS pulses being compared are 
sufficiently close together that the 5370 has sufficient time to 
complete transmitting the measurement results before the next PPS pulse 
arrives. Using the raw binary data format minimises this deadtime. If 
the time interval being measured becomes too large then the 
accuracy/stability of the 5370's internal frequency standard can also 
become an issue.

The 3 cornered hat technique comparing 3 oscillators actually requires 
simultaneous measurements of the 3 time/phase differences to provide 
useful results.
Whilst useful it wont perform miracles, cross correlation techniques are 
more effective. The 3 cornered hat technique can even produce non 
physical negative variances.
Extensions of this technique using more than 3 oscillators and allowing 
finite covariances can improve the reliability of the frequency 
stability estimates, however the measurement system becomes somewhat 
complex and expensive.

An inexpensive modern time interval counter with a power dissipation of 
less than 10 watts and a resolution comparable to the 5370 would be 
useful for such comparisons especially if the experiment lasts several 
The following papers provide useful info on the 3 cornered hat technique:

33rd Annual Precise Time and Time Interval (PTTI) Meeting
Christopher R. Ekstrom and Paul A. Koppang
U.S. Naval Observatory, Washington, D.C.
The three-cornered hat is a procedure for extracting the stabilities of 
clocks when the only available information is the time or frequency
differences between the clocks. To our knowledge, there has been no method
of determining a confidence interval for such a stability estimate. In this
paper, we present a method for determining the number of degrees of freedom
of the estimate, which allows the assignment of a confidence interval to a
three-cornered-hat stability estimate


90th Annual Precise Time and Time Interval (PTTI) Meeting
F. Torcaso, C. R. Ekstrom, E. A. Burt, D. N. Matsakis
U. S. Naval Observatory
3450 Massachusetts Ave., NW
Washington, DC 20392 USA
We present a method for estimating the absolute frequency stability of N 
clocks separate from
a reference. The method introduced is a modification of the one proposed 
by Tauella and Premoli
(1993). After developing the theory we apply the method to atomic clock 
data gathered from the



More information about the time-nuts mailing list