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

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@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.

Hi

Ok, first a step back:

At one second your GPS ADEV will be in the 1x10^-9 to 1x10^-7 range depending on the unit you have.

At one second your Rb will be somewhere in the 1x10^-12 to 1x10^-9 range depending on the unit you have.

If you compare them against each other, the number you get will be the one for the worse of the two.

Assuming you have a Telcom Rb and not something very unusual. It probably runs at 2x10^-11 at one second and
improves by square root of tau. At 100 seconds, it will be 2x10^-12.

If your GPS starts out at 1x10^-8, it improves as tau so at 100 seconds it may be at 1x10^-10.

Since these are rough rules of thumb, they do eventually fall apart. Other error sources get into the mix. The Rb probably
will not get to 2x10^-13 at 10,000 seconds. The GPS may not be at 1x10^-12 at 10,000 seconds.

======

So what does this all mean? What you really will be doing is measuring the ADEV of the GPS using the Rb as a
reference that is good enough that it can be ignored. That is a questionable assumption at 100,000 seconds, but you
need at least 1,000,000 seconds of data to make even a low accuracy estimate there.

If the objective is simply looking at the GPS, a 53132 counter will probably do a fine job. Run the 1 pps out of the
GPS and a 1 pps out of the Rb. Take the time interval between them at a 0.2 ns level once a second. If the
Rb does not have a 1 pps, you can do some tricks with the 10 MHz. It will take some effort to “unfold” the data
you get. ( = use 1 pps to 1 pps if you have never done this before)

You can grab a copy of TimeLab and it will do most of the heavy lifting for you. I would still start with a 1 pps to 1 pps
comparison ...

Bob

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@phk.freebsd.dk>

To: Discussion of precise time and frequency measurement time-nuts@febo.com; zzsilicon@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@3capp-ma
ilcom-lxa02>, zzsilicon@post.com writes:

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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

In message 1925117252.232793.1438455428192.JavaMail.yahoo@mail.yahoo.com, Bob Stewart writes:

For me it is a rule of principle:  If the HP5370 is clocked from the
same source I'm measuring, I can have no expectation of a well
behaved noise from the triggers.

The "noise" you saw is probably exactly that:  Overly optimistic
results if you clock the counter from one of the DUTs

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@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.

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

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?

Bob
From: Bob Camp kb8tq@n1k.org
To: Bob Stewart bob@evoria.net; Discussion of precise time and frequency measurement time-nuts@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

Hi

A few thoughts:

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