# [time-nuts] Data Collection for Allan Deviation

Bob Stewart bob at evoria.net
Sat Aug 1 14:57:08 EDT 2015

```Hi Poul,
"0)  Make sure that the counter does not get its reference frequency
from any of the input signals."
Does your rule 0 hold if one of the input signals is a Cs standard?  I believe I've posted in the past that the ADEV from 1 tau to 100 tau is a bit noisy if I use the internal 10811 to clock the 5370A.  I noticed the same on my 5335A.
Bob

From: Poul-Henning Kamp <phk at phk.freebsd.dk>
To: Discussion of precise time and frequency measurement <time-nuts at febo.com>; zzsilicon at post.com
Sent: Saturday, August 1, 2015 4:19 AM
Subject: Re: [time-nuts] Data Collection for Allan Deviation

--------
In message <trinity-fbe15ceb-78c6-4e04-a3e1-b9b5c2e20fd9-1438400665333 at 3capp-ma
ilcom-lxa02>, zzsilicon at post.com writes:

>If I have a GPS receiver with output pin of both 1pps & 10KHz, a
>Rubidium clock of 10MHz, and a signal generator. How can I determine
>their Allan Deviation? I know the math formula, but my problem is
>the data collection.

Presuming you have a counter which can measure Time Interval between
two signals.

0)  Make sure that the counter does not get its reference frequency
from any of the input signals.

If one of your signals is 1PPS:

1)  Connect 1PPS to START

2)  Connect other signal to STOP

3)  Collect TI measurements.

else:

1)  Connect signal with lowest frequency to START

2)  Connect signal with highest frequency to STOP

3)  Trigger measurements at 1Hz rate, either through EXT TRIG or GPIB

For this to work, the signals must be sufficient "on-frequency"
that the phase-wrap-arounds (when the STOP signal slips past the
START signal) can be resolved afterwards.

A good rule of thumb is that the flanks of the START/STOP signals
should not move more than 1/3 the period of the higher frequency
signal in the time between measurements (= 1sec above).

I use my own home-grown program to calculate the MVAR.

The Lady Heather program should be able to do it with data collected
this way.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

_______________________________________________
time-nuts mailing list -- time-nuts at febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts