Luis,

You said: <<Furthermore the frequency counting resolution is 16 seconds, so the ZAZ gpsdo won't lock better than 0.0625Hz.>>

On my GPSDO design, a single 16-second frequency sample does have a resolution of 0.0625Hz. But the FLL firmware does averaging over as many samples as you want before adjusting the OCXO. So I don't agree with your statement that the ZAZ gpsdo won't lock better than 0.0625Hz. In fact, I have never seen my design go worse than 1x10E-9. It usually sit below 5x10E-10. This concurs with the many reports I got from other users.

Please elaborate.

Thanks,

Bert, VE2ZAZ

Message: 3

I built up the ZAZ GPSDO and like Bert have very very good performance.
Whats crazy interesting is the oven I am using is a Lucent one from the cel
towers.
All of the stuff combined the thing draws very low power. Its been a while
but I want to say 7 watts compared to may of the GPSDOs in the 30-50 watt
range.
Just another dimension to the timenuttieness "The green effect".
Regards
Paul.
WB8TSL

On Tue, May 3, 2011 at 4:42 PM, Bert, VE2ZAZ ve2zaz@yahoo.ca wrote:

Hi Bert,

Well, without the averaging I think I was correct
(I was obviously not considering the averaging).
Your implementation with averaging surely smooth this proportionally
and yes you end up better than 0.0625 as more you integrate.
Please consider then the numbers you may find relevant and the
corresponding integration time. (that was not really the
point in my email).

But since all topologies can average I presume you
agree that potential differences between systems
as remarked in my email still apply. Namely an offset
at a frequency drift that is basic behavior of any FLL
you wont have on a PLL.

All that may fall below most practical needs(1), I agree...
But in the timenuts spirit ought to be pointed out... right ?  ;-)

Luis Cupido
ct1dmk.

p.s. (1) folks running several Cesium stds don't
be offended I'm not saying your needs are not practical  :-)
;-) hi....

Bert, VE2ZAZ wrote:

Check here:

http://ve2zaz.net/GPS_Std/GPS_Std.htm

Bert is on this list.

Bob

On Tue, May 3, 2011 at 11:23 PM, Heathkid heathkid@heathkid.com wrote:

Indeed we were lazy calling it the zaz its the VE2ZAZ.

On Tue, May 3, 2011 at 11:44 PM, Bob Bownes bownes@gmail.com wrote:

Thanks to all for the discussion, but I'm still not sure why I have a
(now) consistent 1.495 hz frequency difference between the thunderbolt
and the VE2ZAZ FLL.

On a similar note, forgive my ignorance, but is there a simple
explanation why there are different frequency readings on my 5370B
when selecting frequency with a 1s gate vs frequency with 100k
samples? Not a few uHz, 1sec gate reading of the VE2ZAZ is
10,000,001.4946 Hz (+/- noise in the last digit) while 100k sample
reading is 9,997,322.2 Hz +/- noise in the last four digits.

Thanks,
Bob the geology major

On Tue, May 3, 2011 at 9:43 PM, Luis Cupido cupido@mail.ua.pt wrote:

On 05/07/2011 02:06 AM, Bob Bownes wrote:

You can have time-biases and voltage-biases which comes into the
measurement.

Recall, that the estimated frequency is

f = eventcount / time

and that an average over 100k samples will mainly average to higher
resolution mainly in the time numbers and to a smaller amount in the
event-count number.

Voltage-biases is due to difference in the trigger voltage of the start
and stop comparators on the input. By use of a calibrator you can
identify these can remove the effect, HP has patents and app-notes
relating to their calibrator. Similar results can be achieved using
other methods. Consider for instance that the frequency should stay the
same regardless if the start and stop is on the rising or falling edges,
but voltage biases can skew the time to create a time-bias.

Some counters, such as the SR-620, also has built-in time-biases in
their frequency mode which needs to be calibrated. This is due to delay
differences between start and stop events.

Now, with these skewed times going into the frequency formula above, it
should not be strange if these systematic errors will cause a systematic
skewing of the value on which no averaging is able to defeat. These
biases needs to be handled up-front.

A classical setup to identify this type of bias is to measure the
frequency of the counters reference output. That way you have completely
removed any issues relating to frequency difference.

A useful method to disclose if you have a bias is to shift time-base
length. If you have 1 second time-base and shift to 100 ms then the
eventcount value will become one tenth and 900 ms will be removed from
time, but the time-bias is as large as before but now has 10 times
higher impact. If you see that, you can be quite sure that you have a
bias and the best way to defeat it is by adjusting your trigger points.

When you have the counter under computer control, and pull out the
event-counter and time-values separately you can do more intricate
tricks naturally.

There are a way for a counter-designer to avoid voltage biases to
inflict on the frequency measure, and that is to take both the start and
stop events from the same comparator. Only very small biases of voltage
nature would remain, but the time-difference from that comparator to the
start and stop detectors would remain.

TIC-based comparision between two frequencies works well to measure
relative frequencies of fairly small differences in a way that biases
cancels on a first-degree level.

Measuring frequency has some intricacies in it.

Cheers,
Magnus