[time-nuts] MT3339 PA6H and Racal Dana GPIB, update

Bob Camp lists at rtty.us
Wed Dec 12 21:39:45 UTC 2012


If you are driving the counter's frequency standard input with the FE5680
and simply measuring the period of the GPS output, then the data would make

I am assuming that the counter starts counting on the pps out of the FE5680
and stops counting on the pps out of the GPS. That way every sample is the
time difference between the two.

Did I get it wrong?


-----Original Message-----
From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On
Behalf Of Fabio Eboli
Sent: Wednesday, December 12, 2012 4:13 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] MT3339 PA6H and Racal Dana GPIB, update

Bob Camp <lists at rtty.us> ha scritto:

> Hi
> Ok, so the data is already decimated and it does show a 20 hour period.


> The way I'm reading things - the pps's start out at zero offset on the
> side (yellow line at about sample 350). They still are at roughly zero
> offset on the right side (at about sample 17045). Total peak to peak in
> yellow line is 0.5 ns. Total peak to peak in the red line is 1.4 ns. One
> over 20 hours would be 1.4x10^-14.

I will think about this, now I cannot still figure it out :)

> So back to the original question - was drift in the pps removed before the
> graph was done?

No, the only filtering was the removing of the glitches:
the blue graph is the result of
"if Period is a number between 0 and 1,4s then plot (1-Period)x10^9"
the other are the averaging, each sample is averaged with
it's neighbours, 100 samples for the red (50 before and 50 after)
and 1000 samples for the yellow (500 before and 500 after).


This message was sent using IMP, the Internet Messaging Program.

time-nuts mailing list -- time-nuts at febo.com
To unsubscribe, go to
and follow the instructions there.

More information about the time-nuts mailing list