[time-nuts] Data Collection for Allan Deviation

Bob Camp kb8tq at n1k.org
Sun Aug 2 08:05:16 EDT 2015


Hi

A few thoughts:
> On Aug 1, 2015, at 9:34 PM, Bob Stewart <bob at evoria.net> wrote:
> 
> Hi Bob,
> I believe that the approach I used in the example plot I linked in the other post was PPS to ext/arm, GPSDO 10MHz to start, Cs 10MHz to stop.  So, is this a methodology issue, then?

Is the pps from a third source? 

1) That adds an “arm to start” delay into the mix. I would *hope* it’s stable, but no guarantees….
2) You will pick up the “next zero cross” on the GPSDO 10 MHz (so another variable delay) as start
3) You will then measure to the “next zero cross” on the Cs

Effectively you have two possibilities for phase slip and no real improvement in measurement accuracy. If the PPS edge is 
ambiguous, your GPSDO edge selection will be suspect. You also now have three (not just two) signals to “get noisy” and mess things up. 

A “more better” way to go:

PPS to start input 
Fast clock to stop input
Stream the data out however you are set up do do so (varies from counter to counter)
	With a GPIB counter running in full control mode, you will need to sync your data process to the 1 pps. 
	With a GPIB counter in talk only mode, you just need to grab the data when it arrives
	With a serial output counter, the data just shows up

In all cases you need to validate you setup. You should get one reading a second, not two closely
spaced readings. A 2 second gap between readings is also a bad sign. Since the checks are in the
“I can time it by eyeball” range, they aren’t terribly complex to set up. 

Bob



> 
> Bob
>      From: Bob Camp <kb8tq at n1k.org>
> To: Bob Stewart <bob at evoria.net>; Discussion of precise time and frequency measurement <time-nuts at febo.com> 
> Sent: Saturday, August 1, 2015 8:22 PM
> Subject: Re: [time-nuts] Data Collection for Allan Deviation
> 
> Hi
> 
> Which approach are you using:
> 
> 1) start with 1 pps, stop with 10 MHz (max period ~ 100 ns)
> 2) start with 1 pps stop with 1 pps (max period ~ 1 second)
> 
> Each has it’s own set of issues. A 1% error on 100 ns is at the noise
> on a 5335. Both counters need a pretty accurate reference if they
> are running out in the half second or more region. 
> 
> The 10811 in the 5370 should be < 1x10^-11 at one second unless you
> have an unusual poor example. It should hold <3x10^-10 per day if it’s 
> been on power for 30 days or more and not been abused. 
> 
> Bob
> 
> 
> 
>> On Aug 1, 2015, at 2:57 PM, Bob Stewart <bob at evoria.net> wrote:
>> 
>> 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
>> and follow the instructions there.
>> 
>> 
>> 
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at 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 at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.



More information about the time-nuts mailing list