Hi Dave,
Thank you for your detailed response.
I use the E? command because it returns results at the gate time intervals
rather than at the LCD update rate (as you point out). I think that this is
working correctly because I get very different file sizes.
The numbers are returned as strings of 10 digits - here are some for 1 second
gate:
90.00006359e+0Hz
90.00007591e+0Hz
89.99999640e+0Hz
89.99998740e+0Hz
90.00006007e+0Hz
89.99996040e+0Hz
90.00008648e+0Hz
90.00008472e+0Hz
90.00011465e+0Hz
90.00014459e+0Hz
I generally use the frequency mode but I also tried time period and found I got
the same curve in essence, which was comforting in a way but showed it wasn't
rounding in converting to frequency.
The numbers above, on my calculator at least don't exactly match counts of 20
nanosecs.
Here are some time period results:
11.11107736e-3s
11.11110130e-3s
11.11110769e-3s
11.11110435e-3s
11.11110593e-3s
11.11110022e-3s
11.11114000e-3s
11.11110000e-3s
11.11110370e-3s
Again they don't seem to be integer values of 20 nanosec exactly, though quite
close. For example
11.11107736E-3/20E-9 = 555,553.868
555,554 x 20E-9 = 11.11108E-3
But I guess what it returns is the ratio of counts within the gate. So
11.11107736E-3 period will occur
90 times in a second (as it is slightly short) and so I should take the ratio:
90 x 11.11107736E-3/20e-9 = 49,999,848.12
so still not quite an integer but if I assume the count (of 50MHz periods) was
49,999,848 and calculate one 90 th of it I get:
49,999,848 x 20E-9/90 = 1.1111077333333
Still not exact agreement. I note that .12 is very close to .125 or 1/8 but I
don't know if that is significant.
It is probable that it rounds the ratio in binary and then converts to decimal
to print out.
I've tried assuming 89 periods and 91 periods but still don't get exact integer
ratios.
Anyway, as I get good agreement between period and frequency measurements at 1
sec, I don't think that it is a rounding issue.
I do think it is a quantization issue down to the +/- 20 nanosecs/gate time but
I can't quite work it out.
I'm currently doing a run at 0.3 secs gate time and I'll see what sort of curve
that produces.
Tomorrow I should receive my new Tek counter (I went for the fca3100 in the end
as I got a very good discount on an ex demo unit) and that should give
something to compare (once I've worked out how to program it).
James
-----Original Message-----
From: Dave Martindale <dave.martind...@gmail.com>
To: jpbridge <jpbri...@aol.com>; Discussion of precise time and frequency
measurement <time-nuts@febo.com>
Sent: Tue, 17 Mar 2015 0:27
Subject: Re: [time-nuts] ADEV noise floor vs counter gate time
How is the counter configured? Are you reading period or frequency? Are you
in "E?" (Every Result) mode, or "C?" (Continuous Result) mode? The former
should give you continuous but independent measurements, while the latter gives
heavily overlapped measurements. (For example, with a 100 second gate time,
you get one E output every 100 seconds, which covers a different 100-second
period than the previous measurement. In C mode, you get one output every 2
seconds, each of which is an estimate from 100 seconds of measurement, but 98
seconds of that data was also part of the previous output and only 2 seconds of
new data is included).
What does the data returned by the counter actually look like? The manual
implies that you always get 10 digits worth of result (not including the
exponent) regardless of gate time, but are the values rounded for display in 7,
8, or 9 digits at the shorter gate times, or are they a full 10 digits always?
Given any particular value of frequency or period you get, you should be able
to reverse-calculate the number of whole cycles of the input signal that the
counter used as a gate time, and the number of cycles of 50 MHz timebase that
were counted in that period. Since the counter doesn't have interpolators,
both of these values should be integers, and so the possible output values are
a small subset of all possible 10-digit values for the shorter gate times.
For example, if the difference frequency is exactly 90 Hz, the period between
two "1 second" measurements will be exactly 1 second, and the counter will
record 90 cycles of input and 5e7 cycles of timebase, exactly. In frequency
mode, the output should be 90.0 Hz exactly, and in period mode the output
should be 11.11111111 ms. Now suppose that the difference frequency is just a
hair slow, enough that 90 cycles of input spans 50,000,001 counts of the
timebase. The reported frequency should be 89.99999820 Hz and the reported
period should be 11.11111133 ms. With a 1 s gate time, no values between those
are possible unless the values are being rounded (or there is an error in the
calculation, which is always possible). Looked at another way, the smallest
possible change in the reported period is one timebase clock (20 ns) divided by
the number of input cycles in one gate time (90 for 1 s).
If the counter is rounding, you may be able to unambiguously figure out what
the actual inputs (cycles of input and cycles of timebase) to the calculation
were, and use that instead of the rounded value in your calculations. Rounding
may round up or down, but if the two oscillators are stable enough the
direction can be predominantly "up" or "down" for long periods of time, adding
a bias to the actual frequency or period you're measuring. (I don't know what
effect this bias would have on ADEV).
- Dave
On Mon, Mar 16, 2015 at 10:15 AM, James via time-nuts <time-nuts@febo.com>
wrote:
Hi All,
I'm in the process of getting a better counter, but at present I'm using my
TTi TF930 counter.
For those who don't know it, it is a reciprocal counter which should be
continuous, it counts periods in terms of its internal 50MHz clock which I've
locked to an external 10MHz reference.
There are 4 gate times available, 0.3 secs, 1 sec, 10 secs and 100 secs.
These correspond to 7, 8, 9 and 10 digits.
I've been experimenting with using a single mixer (mini circuits ZAD+) along
with a 1MHz low pass filter and appropriate attenuators to measure Alan
Deviation (using my own software).
My set up is a 10MHz reference source (MV89A which I've approximately set
using a 10kHz GPS signal).
The reference is used as the external reference for an Agilent 33522A
arbitrary waveform generator.
The 33522A generates an 9.999910 MHz (10MHz - 90Hz) sine wave at 300mVpp to
the mixer and the mixer is also fed by the 10MHz reference output of the 33522A
via an attenuator to get it to roughly the same level.
The second output of the 33522A generates a 10MHz square wave as a reference
for the counter (the counter requires quite a high reference signal and the
reference out of the 33522A is too low a voltage to be used directly).
I initially ran this with a gate of 1 second and the LOG10(ADEV) curve drops
linearly vs LOG10(tau) but then curves back up again. (I tried many variants
such as using period rather than frequency and so on.)
But when I set the gate time to 10 seconds or 100 seconds then I get both
lower curves and ones that no longer curve upwards.
The attached pdf shows the three curves on the same graph.
What puzzles me is that the counter at longer gates is only averaging to get
more digits so the difference must come down to quantization in terms of the
number of digits that are passed to the computer over the USB/RS232 link.
I find it rather puzzling.
James
_______________________________________________
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.
_______________________________________________
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.
