# [time-nuts] yet another GPSDO design, or so

Stanley Reynolds stanley_reynolds at yahoo.com
Sun Jun 27 23:17:02 UTC 2010

```My last statement is not quite correct.

"If the drift is too big we will over shoot to the next higher integer number and this will bias the average up too high."

In the case where the 100Mhz clock drifts both up and down the number could average to the correct fraction.  But now the rate of drift as well as it's magnitude would need to be correct.

Accuracy is not important here just the precision, as the number is not important just the rate of change of the number indicates error.

Stanley

----- Original Message ----
From: Stanley Reynolds <stanley_reynolds at yahoo.com>
To: Discussion of precise time and frequency measurement <time-nuts at febo.com>
Sent: Sun, June 27, 2010 5:23:13 PM
Subject: Re: [time-nuts] yet another GPSDO design, or so

Jitter may not be the correct word. I also don't know how accurate or repeatable the averaging effect is as described in the article.  But I do believe the amount of drift is important for this to work as stated before. Independent is required, if locked then this is the extreme case of no drift and average value will be the same as all the samples are the same integer number. To see the fraction between the integer we need our data set to have some number of samples above and below and hopefully in a ratio to indicate the real measurement. If the drift is too small then we will tend to calculate an average too small, as more samples will fall to the low side the high side is never reached. If the drift is too big we will over shoot to the next higher integer number and this will bias the average up too high.

Stanley

----- Original Message ----
From: "EWKehren at aol.com" <EWKehren at aol.com>
To: time-nuts at febo.com
Sent: Sun, June 27, 2010 4:27:39 PM
Subject: Re: [time-nuts] yet another GPSDO design, or so

Stanley
I am not an expert but it is not only the jitter it is the fact that since
the two sources are not linked the independent drift of the 100 MHz causes
a  distribution of the count. Again even with the same resolution the count
error  will be four X and the subsequent correction will be to scale, with
out changing  the code.  Bert

In a message dated 6/27/2010 4:00:59 P.M. Eastern Daylight Time,
stanley_reynolds at yahoo.com writes:

Without  knowing your 100Mhz clock would it not need less jitter to average
out +- one  count at 100Mhz vs one count at 24Mhz?

The GPS error has improved with  better hardware/software in the receivers
as well as turning off SA. So I'm  not so sure the GPS error will wash out
the counter's error. Even if it does,  as a want to be time nut I need a
better counter which is why more is better,  a faster count with a recipical
counter equals better unless the faster  counter no longer averages out the +-
count.

Stanley

----- Original Message ----
From:  "EWKehren at aol.com" <EWKehren at aol.com>
To: time-nuts at febo.com
Sent:  Sun, June 27, 2010 1:17:51 PM
Subject: Re: [time-nuts] yet another GPSDO  design, or so

Going from 24 to 100 MHz only gives you smaller steps  (resolution) every
thing else stays the same.
If the he saw 2 to  3 nsec should be more like 8, going to 100 MHz will
improve it by a  factor of 4. In a redesign of the total system I would
have two
sample  sizes maybe stay with 30 or go to 50/60 and in the Rub. mode 200
maybe 300 sec. Let us not forget what we start out with the GPS signal
does
not  allow us to take advantage of the full resolution.
Do  not forget I did this to get smaller D/A steps and am not able to
rewrite the code, basically fooling the controller that the error should
call
for a 1.7 E-13 correction when in reality the error is 4.3 E-14  and the
resulting step is also 4.3 E-14  per D/A  bit.
Bert

In a message dated 6/27/2010 1:43:40 P.M. Eastern  Daylight Time,
stanley_reynolds at yahoo.com writes:

Yes I  see your need for a reduced range with smaller steps. But I was
looking  for  smaller steps to improve the tracking accuracy without a loss
of
the benefit  of averaging. From the QST  article:

"Interestingly, it is  desirable to have the frequency of  U7 drift
slightly
rather than being  synchronized with the VCXO.  A
slight random drift averages out the count  ambiguity that is  inherent in
any pulse-counting device. My  measurements
indicate  that the simple phase-measuring circuit I use is  consistently
accurate to 2 or 3 ns (for a 30-second measurement),  while
without drift, the resolution would be limited to 42 ns. The \$5  crystal

So the drift should  just  cover the area of uncertainty that is one cycle,
too much drift  would reduce  accuracy, not enough and the average is of no

benefit.
One extreme no  jitter, average doesn't work as it  doesn't distribute the
samples over the  range of uncertainty. The  other case too much jitter and
the best to expect is  an average  weighted to one side or the other (+-1
count) with the extreme  producing multiple counts of error. Something
makes me  nervous  maybe the part about "slight random drift" what is
slight
at  24 Mhz is it also  slight at 100 Mhz ? An average of 30 samples does
have a limit to what it will  correct.

Stanley

----- Original Message ----
From:  "EWKehren at aol.com"  <EWKehren at aol.com>
To: time-nuts at febo.com
Sent:  Sun, June  27, 2010 8:58:55 AM
Subject: Re: [time-nuts] yet another GPSDO  design, or so

Stanley
the faster counter also has the jitter,  no  change, as long as it is  not
tied to the input frequency.  The 24 MHz  is not unique, the 100 MHz is
same

technology just  four times faster  and thus gives me smaller steps on the
D/A
and  since I use it on  Rub. the full range of the 18 bit covers  the full
tuning range  of  the Rub.
Bert

In a  message dated 6/27/2010 9:05:12 A.M. Eastern  Daylight Time,
stanley_reynolds at yahoo.com writes:

I  have  been thinking  about a faster counter also but the Shera board was

depending  on  the jitter in the 24 Mhz clock to average out the +-  count.

The
faster  clock would reduce the need for this but  without  the right amount
of jitter we  lose the benefit of  this  average.

Stanley

<snip>

_______________________________________________
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

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