ADEV noise floor vs counter gate time
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
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.
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.martindale@gmail.com
To: jpbridge jpbridge@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.
I believe I see the pattern. As you figured out, you wouldn't expect a single
period to be a multiple of 20 ns; you expect the length of (about) 90 periods
to be an integer multiple of 50 ns, since that's what the counter actually
measures. Further, the measuring time isn't exactly 1 second, it is an
integer number of periods of the input frequency that makes up at least 1
second. If the counting logic was all hardware, you would expect to capture
either 90 or 91 cycles of the input, depending on whether the input frequency
was slightly below or above 90 Hz respectively.
I built this table of your frequency data in Excel. Math is 64-bit floating
point, equivalent to about 16 decimal digits, so plenty accurate enough to
simulate this counter:
Reading Input Count TB Count Rounded Frequency Interval
90.00006359 92 51111074.998 51111075 90.00006359 1.022221500
90.00007591 92 51111068.002 51111068 90.00007591 1.022221360
89.99999640 90 50000002.000 50000002 89.99999640 1.000000040
89.99998740 90 50000007.000 50000007 89.99998740 1.000000140
90.00006007 92 51111076.997 51111077 90.00006007 1.022221540
89.99996040 90 50000022.000 50000022 89.99996040 1.000000440
90.00008648 92 51111061.999 51111062 90.00008648 1.022221240
90.00008472 92 51111062.999 51111063 90.00008472 1.022221260
90.00011465 92 51111046.001 51111046 90.00011465 1.022220920
90.00014459 92 51111028.998 51111029 90.00014459 1.022220580
The first column is your data. The second column is a guess about how many
input cycles were captured. The third column is the number of timebase cycles
that have elapsed since the previous reading, based on the first two columns.
I hand-tweaked the numbers in the second column until the number in the third
column was within 0.003 of an integer. The fact that I was always able to do
this tells me that my guess is probably correct, and the small residual (which
is a few parts in 1e-10) is due to the counter rounding the results to 10
digits. The 4th column is the result of rounding the previous column to the
nearest integer. This is what I believe is the actual number of counts the
counter saw. The 5th column is a fresh calculation of frequency, based on the
integer number of input cycles in column 2 and the integer number of timebase
cycles in column 4. When the result is rounded to 10 digits, you can see it
matches the 10 digits that the counter provided back in column 1.
Oddly, the counter never captured 91 input cycles. If the input frequency was
a little higher than 90 Hz, it always measured at 92 cycles, even though 91
cycles was well more than 1 s since the previous reading. I guess the
microprocessor running the counter only checks periodically (e.g. every 20 ms)
to see if the gate time has elapsed, and then latches the counts on the next
active edge of the input signal.
So, I claim that with this small sample, at least, we recovered the exact
number of 20 ns periods between samples, and the number of integer input
cycles as well. Also notice the 6th column. This is the actual sample
interval, based on the number of elapsed timebase counts. Note that the
sample period is not exactly 1 second, nor is it even close to a constant
value, since some measurements are of 90 cycles while others are of 92
cycles. Does your ADEV calculation algorithm take into account the variable
spacing of the input samples in time? If it assumes they are regularly spaced
(i.e. every 90 cycles) it may get confused by this variable-spacing data.
Now here is almost the same process applied to your period data:
Reading Input Count TB Count Rounded Period Interval
0.01111107736 91 50555401.988 50555402 0.01111107736 1.011108040
0.01111110130 92 51111065.980 51111066 0.01111110130 1.022221320
0.01111110769 91 50555539.990 50555540 0.01111110769 1.011110800
0.01111110435 92 51111080.010 51111080 0.01111110435 1.022221600
0.01111110593 91 50555531.982 50555532 0.01111110593 1.011110640
0.01111110022 90 49999950.990 49999951 0.01111110022 0.999999020
0.01111114000 90 50000130.000 50000130 0.01111114000 1.000002600
0.01111110000 90 49999950.000 49999950 0.01111110000 0.999999000
0.01111110370 92 51111077.020 51111077 0.01111110370 1.022221540
Again, column 2 was hand-adjusted for each row to keep the third column close
to an integer. The residual errors here are larger, since the maximum
rounding error of 0.5 in the last place is a larger change relative to a
10-digit value of 11111111 than it is to a value of 90000000, but all are
still within 0.02 of being an integer. This time, the counter grabbed
measurements after 90, 91, or 92 cycles. Again, after rounding the timebase
count to an integer and calculating a 10-digit period for display, the result
always matched what the counter output. Again, I think we know with high
probability just how many input and timebase cycles were counted for each
measurement.
I adjusted column 2 by eye, while looking at the results of column 3, but that
process could be automated pretty easily (just not in Excel). As I tried 90,
91, and 92 in sequence, there was always just one of those which gave a small
residual error.
So I think your TF930 is making measurements and accurately converting them to
frequency or period, with a +- 20 ns uncertainty for each measurement. Since
it is a time-stamping counter, the uncertainty in a 10 s or 100 s or 1000 s
measurement time (assembled by external software) is still only 20 ns. That's
great, but to actually get that accuracy over a long measurement time, you
will need to determine and add up the actual number of input counts and
timebase counts. And you will have to understand that the counter does not
make measurements at constant or near-constant intervals (e.g. every 90 cycles
of input, without exception). It gives you measurements whenever it gets
around to measuring them.
Too bad there doesn't seem to be a way to get it to return the raw observed
data (input cycle count, timebase cycle count) instead of the frequency or
period derived from them. That would make it trivial to string together a
bunch of 1s measurements into arbitrarily long gate times.
- Dave
On 17/03/2015 05:57, jpbridge@aol.com wrote:
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.martindale@gmail.com
To: jpbridge jpbridge@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.
Hi Dave,
Interesting analysis. The accuracy stated in the manual is ...+ 2 counts and though this relates to the 50MHz clock, perhaps they use a similar algorithm for the input frequency.
I completed the 0.3 second measurements and the curve is similar to 1 second but higher up (i.e. as you'd expect by extrapolation from the behaviour of the other curves).
My ADEV calculation is based on the average frequency in each bin, the varying size of the bin should be insignificant as long as it is not affecting the average value within the bin. If the average frequency shifts by delta_F in one bin time step and the first bin is delta_T short (as a fraction of one bin time step) then the first frequency will be delta_T*delta_F low and the second bin perhaps that much high but the key point is that it is the product of the two deltas so it won't materially affect the accuracy of the calculation. At least I think that is correct.
Taking the worst possible case where the delta in bin size always went the wrong way so every term in the Alan Variance sum was multiplied by (1+2delta)^2 then the final Alan deviation might be (1 + 2 delta) too big but as delta is of the order of 10E-8 or less this wouldn't even register on the graphs.
What I might try doing is programming your approach into the code to try and get at the raw data - I only need to try 88,90 and 92 as possible counts - though to be sure I'll try mean frequency +- 5 say and then try and get the 50MHz clock values out as integers. What I might also do is then do a least squares fit (linear regression) to get the frequency over each bin and use the slope (this perhaps is what the counter does internally - I don't know).
I'd like to get to the bottom of this if only to understand my counter better.
James
-----Original Message-----
From: Dave Martindale dave.martindale@gmail.com
To: jpbridge jpbridge@aol.com; time-nuts time-nuts@febo.com
Sent: Wed, 18 Mar 2015 1:26
Subject: Re: [time-nuts] ADEV noise floor vs counter gate time
I believe I see the pattern. As you figured out, you wouldn't expect a single period to be a multiple of 20 ns; you expect the length of (about) 90 periods to be an integer multiple of 50 ns, since that's what the counter actually measures. Further, the measuring time isn't exactly 1 second, it is an integer number of periods of the input frequency that makes up at least 1 second. If the counting logic was all hardware, you would expect to capture either 90 or 91 cycles of the input, depending on whether the input frequency was slightly below or above 90 Hz respectively.
I built this table of your frequency data in Excel. Math is 64-bit floating point, equivalent to about 16 decimal digits, so plenty accurate enough to simulate this counter:
Reading Input Count TB Count Rounded Frequency Interval
90.00006359 92 51111074.998 51111075 90.00006359 1.022221500
90.00007591 92 51111068.002 51111068 90.00007591 1.022221360
89.99999640 90 50000002.000 50000002 89.99999640 1.000000040
89.99998740 90 50000007.000 50000007 89.99998740 1.000000140
90.00006007 92 51111076.997 51111077 90.00006007 1.022221540
89.99996040 90 50000022.000 50000022 89.99996040 1.000000440
90.00008648 92 51111061.999 51111062 90.00008648 1.022221240
90.00008472 92 51111062.999 51111063 90.00008472 1.022221260
90.00011465 92 51111046.001 51111046 90.00011465 1.022220920
90.00014459 92 51111028.998 51111029 90.00014459 1.022220580
The first column is your data. The second column is a guess about how many input cycles were captured. The third column is the number of timebase cycles that have elapsed since the previous reading, based on the first two columns. I hand-tweaked the numbers in the second column until the number in the third column was within 0.003 of an integer. The fact that I was always able to do this tells me that my guess is probably correct, and the small residual (which is a few parts in 1e-10) is due to the counter rounding the results to 10 digits. The 4th column is the result of rounding the previous column to the nearest integer. This is what I believe is the actual number of counts the counter saw. The 5th column is a fresh calculation of frequency, based on the integer number of input cycles in column 2 and the integer number of timebase cycles in column 4. When the result is rounded to 10 digits, you can see it matches the 10 digits that the counter provided back in col
umn 1.
Oddly, the counter never captured 91 input cycles. If the input frequency was a little higher than 90 Hz, it always measured at 92 cycles, even though 91 cycles was well more than 1 s since the previous reading. I guess the microprocessor running the counter only checks periodically (e.g. every 20 ms) to see if the gate time has elapsed, and then latches the counts on the next active edge of the input signal.
So, I claim that with this small sample, at least, we recovered the exact number of 20 ns periods between samples, and the number of integer input cycles as well. Also notice the 6th column. This is the actual sample interval, based on the number of elapsed timebase counts. Note that the sample period is not exactly 1 second, nor is it even close to a constant value, since some measurements are of 90 cycles while others are of 92 cycles. Does your ADEV calculation algorithm take into account the variable spacing of the input samples in time? If it assumes they are regularly spaced (i.e. every 90 cycles) it may get confused by this variable-spacing data.
Now here is almost the same process applied to your period data:
Reading Input Count TB Count Rounded Period Interval
0.01111107736 91 50555401.988 50555402 0.01111107736 1.011108040
0.01111110130 92 51111065.980 51111066 0.01111110130 1.022221320
0.01111110769 91 50555539.990 50555540 0.01111110769 1.011110800
0.01111110435 92 51111080.010 51111080 0.01111110435 1.022221600
0.01111110593 91 50555531.982 50555532 0.01111110593 1.011110640
0.01111110022 90 49999950.990 49999951 0.01111110022 0.999999020
0.01111114000 90 50000130.000 50000130 0.01111114000 1.000002600
0.01111110000 90 49999950.000 49999950 0.01111110000 0.999999000
0.01111110370 92 51111077.020 51111077 0.01111110370 1.022221540
Again, column 2 was hand-adjusted for each row to keep the third column close to an integer. The residual errors here are larger, since the maximum rounding error of 0.5 in the last place is a larger change relative to a 10-digit value of 11111111 than it is to a value of 90000000, but all are still within 0.02 of being an integer. This time, the counter grabbed measurements after 90, 91, or 92 cycles. Again, after rounding the timebase count to an integer and calculating a 10-digit period for display, the result always matched what the counter output. Again, I think we know with high probability just how many input and timebase cycles were counted for each measurement.
I adjusted column 2 by eye, while looking at the results of column 3, but that process could be automated pretty easily (just not in Excel). As I tried 90, 91, and 92 in sequence, there was always just one of those which gave a small residual error.
So I think your TF930 is making measurements and accurately converting them to frequency or period, with a +- 20 ns uncertainty for each measurement. Since it is a time-stamping counter, the uncertainty in a 10 s or 100 s or 1000 s measurement time (assembled by external software) is still only 20 ns. That's great, but to actually get that accuracy over a long measurement time, you will need to determine and add up the actual number of input counts and timebase counts. And you will have to understand that the counter does not make measurements at constant or near-constant intervals (e.g. every 90 cycles of input, without exception). It gives you measurements whenever it gets around to measuring them.
Too bad there doesn't seem to be a way to get it to return the raw observed data (input cycle count, timebase cycle count) instead of the frequency or period derived from them. That would make it trivial to string together a bunch of 1s measurements into arbitrarily long gate times.
- Dave
On 17/03/2015 05:57, jpbridge@aol.com wrote:
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.martindale@gmail.com
To: jpbridge jpbridge@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.
The counter always has a 1 count uncertainty in the timebase measurement,
which is a 2e-8 error with a 1 second gate time. If the value being
displayed starts with the digit 9, and 8 digits are displayed, then that
translates to +- 2 counts in the last place. But the measurements are
synchronized to the input signal, so it always measures an integer number
of input cycles, and there should be no comparable uncertainty in the input
(other than some noise in deciding exactly when the edge crosses the input
threshold, which should be tiny compared to the 20 ns timebase period).
But that's comparing the counter reading to the real world. My table was
comparing the displayed output to the likely raw measurements, and it seems
to show that the counter's internal math is being performed to the full 10
digits of precision in the USB data, even when the gate time supports only
8 bits of accuracy. That's good news because it allows you to know when
you have correctly guessed the input counts.
When trying to calculate the raw data from the reading, you do need to try
an input count of 91 in addition to 90 and 92. 91 did show up in the small
sample of period-mode measurements, even if it did not appear in any of the
frequency-mode measurements.
I don't think the counter is doing "averaging", in the sense of making
multiple independent short-period measurements and then averaging them for
higher precision. Instead, it is just making one long continuous
measurement, sampling the signal periodically, and then actually
calculating frequency or period from two measurements separated by an
appropriate time. For a simplified example:
Suppose the counter generates a time stamp approximately every 1 second
(always aligned with the input signal active edge) and then stores the two
pieces of raw data (the current input cycle counter and the current
timebase counter) in a small memory buffer. The counters are never reset;
they just need to be large enough to never overflow twice within the
longest input period allowed (1000 s for the TF930). To display a
frequency or period based on a 1 s gate time, the counter simply subtracts
two successive data records to get delta-input and delta-timebase counts,
then does its calculations based on those deltas. To display a 10 second
gate time measurement, the counter looks back through its memory to find a
time stamp about 10 seconds earlier than the most recent measurement (with
high input frequency, that will generally be 10 measurements ago, but when
measuring a signal with a 0.2 Hz frequency it's only 2 measurements ago).
For a 100 second gate time measurement, the counter needs to find a saved
time stamp that is about 100 seconds ago. Once it has found the correct
data record, it calculates the difference in input and timebase counts
between that one previous data record and the most recent, and then
calculates the displayed value from it.
One second later, the counter can calculate a new 100 s measurement, using
the new data point just captured and a different stored data point 100
seconds ago. But 99 of the 100 seconds in the new gate period are shared
with the old gate period, so the displayed value is not likely to change
very much simply because 99% of the observation period is shared.
Thus, every displayed value is calculated from only 2 time-stamped
measurements. The longer gate time places those measurements further
apart, reducing the uncertainty due to the +- 1 clock of the timebase.
Because the counters run continuously without resetting, no clock edges are
lost and a 100 s gate time measurement has only 20 ns uncertainty in the
whole 100 s period. Also, any wander in the input frequency between those
two measurements is invisible if it cancels out over the gate time. So
there is "averaging" in the sense that the counter display always reflects
what is happening on the scale of the gate time, but it's not computing and
then averaging multiple numbers.
I have not tried doing my own ADEV calculations, so I can't say what it is
about the shorter gate periods that make the oscillator appear noisier than
it really is. How does the ADEV calculation aggregate a stream of
short-time calculations into measurements for large tau values? My
intuition is this: If you just take readings from the counter with a 1 s
gate time, each reading has a 2e-8 uncertainty. If you average a bunch of
these readings, and the errors are independent, the accuracy should improve
by a factor of sqrt(N). But if you unwrap each reading into an integer
number of input and timebase cycles, you essentially have a series of phase
samples that can be added or subtracted without increasing the absolute
uncertainty. So when you combine 100 1 second measurements, you get a
relative accuracy that is 100 times better, not the sqrt(100) you'd get
from averaging.
- Dave
On Wed, Mar 18, 2015 at 6:33 AM, jpbridge@aol.com wrote:
Hi Dave,
Interesting analysis. The accuracy stated in the manual is ...+ 2 counts
and though this relates to the 50MHz clock, perhaps they use a similar
algorithm for the input frequency.
I completed the 0.3 second measurements and the curve is similar to 1
second but higher up (i.e. as you'd expect by extrapolation from the
behaviour of the other curves).
My ADEV calculation is based on the average frequency in each bin, the
varying size of the bin should be insignificant as long as it is not
affecting the average value within the bin. If the average frequency shifts
by delta_F in one bin time step and the first bin is delta_T short (as a
fraction of one bin time step) then the first frequency will be
delta_T*delta_F low and the second bin perhaps that much high but the key
point is that it is the product of the two deltas so it won't materially
affect the accuracy of the calculation. At least I think that is correct.
Taking the worst possible case where the delta in bin size always went the
wrong way so every term in the Alan Variance sum was multiplied by
(1+2delta)^2 then the final Alan deviation might be (1 + 2 delta) too big
but as delta is of the order of 10E-8 or less this wouldn't even register
on the graphs.
What I might try doing is programming your approach into the code to try
and get at the raw data - I only need to try 88,90 and 92 as possible
counts - though to be sure I'll try mean frequency +- 5 say and then try
and get the 50MHz clock values out as integers. What I might also do is
then do a least squares fit (linear regression) to get the frequency over
each bin and use the slope (this perhaps is what the counter does
internally - I don't know).
I'd like to get to the bottom of this if only to understand my counter
better.
James
-----Original Message-----
From: Dave Martindale dave.martindale@gmail.com
To: jpbridge jpbridge@aol.com; time-nuts time-nuts@febo.com
Sent: Wed, 18 Mar 2015 1:26
Subject: Re: [time-nuts] ADEV noise floor vs counter gate time
I believe I see the pattern. As you figured out, you wouldn't expect a
single period to be a multiple of 20 ns; you expect the length of (about)
90 periods to be an integer multiple of 50 ns, since that's what the
counter actually measures. Further, the measuring time isn't exactly 1
second, it is an integer number of periods of the input frequency that
makes up at least 1 second. If the counting logic was all hardware, you
would expect to capture either 90 or 91 cycles of the input, depending on
whether the input frequency was slightly below or above 90 Hz respectively.
I built this table of your frequency data in Excel. Math is 64-bit
floating point, equivalent to about 16 decimal digits, so plenty accurate
enough to simulate this counter:
Reading Input Count TB Count Rounded Frequency Interval
90.00006359 92 51111074.998 51111075 90.00006359
1.022221500
90.00007591 92 51111068.002 51111068 90.00007591
1.022221360
89.99999640 90 50000002.000 50000002 89.99999640
1.000000040
89.99998740 90 50000007.000 50000007 89.99998740
1.000000140
90.00006007 92 51111076.997 51111077 90.00006007
1.022221540
89.99996040 90 50000022.000 50000022 89.99996040
1.000000440
90.00008648 92 51111061.999 51111062 90.00008648
1.022221240
90.00008472 92 51111062.999 51111063 90.00008472
1.022221260
90.00011465 92 51111046.001 51111046 90.00011465
1.022220920
90.00014459 92 51111028.998 51111029 90.00014459
1.022220580
The first column is your data. The second column is a guess about how
many input cycles were captured. The third column is the number of
timebase cycles that have elapsed since the previous reading, based on the
first two columns. I hand-tweaked the numbers in the second column until
the number in the third column was within 0.003 of an integer. The fact
that I was always able to do this tells me that my guess is probably
correct, and the small residual (which is a few parts in 1e-10) is due to
the counter rounding the results to 10 digits. The 4th column is the
result of rounding the previous column to the nearest integer. This is
what I believe is the actual number of counts the counter saw. The 5th
column is a fresh calculation of frequency, based on the integer number of
input cycles in column 2 and the integer number of timebase cycles in
column 4. When the result is rounded to 10 digits, you can see it matches
the 10 digits that the counter provided back in column 1.
Oddly, the counter never captured 91 input cycles. If the input frequency
was a little higher than 90 Hz, it always measured at 92 cycles, even
though 91 cycles was well more than 1 s since the previous reading. I
guess the microprocessor running the counter only checks periodically (e.g.
every 20 ms) to see if the gate time has elapsed, and then latches the
counts on the next active edge of the input signal.
So, I claim that with this small sample, at least, we recovered the exact
number of 20 ns periods between samples, and the number of integer input
cycles as well. Also notice the 6th column. This is the actual sample
interval, based on the number of elapsed timebase counts. Note that the
sample period is not exactly 1 second, nor is it even close to a constant
value, since some measurements are of 90 cycles while others are of 92
cycles. Does your ADEV calculation algorithm take into account the
variable spacing of the input samples in time? If it assumes they are
regularly spaced (i.e. every 90 cycles) it may get confused by this
variable-spacing data.
Now here is almost the same process applied to your period data:
Reading Input Count TB Count Rounded Period
Interval
0.01111107736 91 50555401.988 50555402 0.01111107736
1.011108040
0.01111110130 92 51111065.980 51111066 0.01111110130
1.022221320
0.01111110769 91 50555539.990 50555540 0.01111110769
1.011110800
0.01111110435 92 51111080.010 51111080 0.01111110435
1.022221600
0.01111110593 91 50555531.982 50555532 0.01111110593
1.011110640
0.01111110022 90 49999950.990 49999951 0.01111110022
0.999999020
0.01111114000 90 50000130.000 50000130 0.01111114000
1.000002600
0.01111110000 90 49999950.000 49999950 0.01111110000
0.999999000
0.01111110370 92 51111077.020 51111077 0.01111110370
1.022221540
Again, column 2 was hand-adjusted for each row to keep the third column
close to an integer. The residual errors here are larger, since the
maximum rounding error of 0.5 in the last place is a larger change relative
to a 10-digit value of 11111111 than it is to a value of 90000000, but all
are still within 0.02 of being an integer. This time, the counter grabbed
measurements after 90, 91, or 92 cycles. Again, after rounding the
timebase count to an integer and calculating a 10-digit period for display,
the result always matched what the counter output. Again, I think we know
with high probability just how many input and timebase cycles were counted
for each measurement.
I adjusted column 2 by eye, while looking at the results of column 3, but
that process could be automated pretty easily (just not in Excel). As I
tried 90, 91, and 92 in sequence, there was always just one of those which
gave a small residual error.
So I think your TF930 is making measurements and accurately converting
them to frequency or period, with a +- 20 ns uncertainty for each
measurement. Since it is a time-stamping counter, the uncertainty in a 10
s or 100 s or 1000 s measurement time (assembled by external software) is
still only 20 ns. That's great, but to actually get that accuracy over a
long measurement time, you will need to determine and add up the actual
number of input counts and timebase counts. And you will have to
understand that the counter does not make measurements at constant or
near-constant intervals (e.g. every 90 cycles of input, without
exception). It gives you measurements whenever it gets around to measuring
them.
Too bad there doesn't seem to be a way to get it to return the raw
observed data (input cycle count, timebase cycle count) instead of the
frequency or period derived from them. That would make it trivial to
string together a bunch of 1s measurements into arbitrarily long gate
times.
- Dave
On 17/03/2015 05:57, jpbridge@aol.com wrote:
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.martindale@gmail.com
To: jpbridge jpbridge@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.
Hi Dave,
Thanks for another detailed response.
I've now programmed a version of my code that attempts to recover the raw data by trying different counts up and down from the nominal and finding the one with the smallest rounding error.
One problem is I need to restrain the amount it goes up or down otherwise it finds erroneously small or large numbers of cycles (+/- 2 is believable, more than that isn't).
As an experiment I then changed the data to match the "raw data". This doesn't change the shape of the curve but it lowers it so it starts below 10^-15! This is suspiciously good so I think I'm smoothing out changes that are really there.
Now that my new fca3100 has arrived I'm hoping to find time to get measurements with it which should be proper time-stamped ones and much more accurate - then I can compare the two.
To answer your question on ADEV aggregating values, and speaking as a total newbee myself, the approach to different tau sizes is to aggregate all measurements within a bin of size tau and average the frequencies (or average the time differences and invert - for small variations it makes very little difference as (1+delta)^-1 is 1-delta ignoring delta*delta terms). Then each term in the Alan Variaton summation is the square of the difference between the average frequency in adjacent bins.
So with 1 second values at a tau of 100 secs, 100 values in each cell are averaged whilst the 100 sec gate value results just have a single value for each bin. But given that the counter itself should be averaging there should be good agreement between the two - hence my puzzlement.
The fca3100 calculates ADEV directly so I'll have a check on my code.
James
-----Original Message-----
From: Dave Martindale dave.martindale@gmail.com
To: jpbridge jpbridge@aol.com
CC: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Wed, 18 Mar 2015 15:22
Subject: Re: [time-nuts] ADEV noise floor vs counter gate time
The counter always has a 1 count uncertainty in the timebase measurement, which is a 2e-8 error with a 1 second gate time. If the value being displayed starts with the digit 9, and 8 digits are displayed, then that translates to +- 2 counts in the last place. But the measurements are synchronized to the input signal, so it always measures an integer number of input cycles, and there should be no comparable uncertainty in the input (other than some noise in deciding exactly when the edge crosses the input threshold, which should be tiny compared to the 20 ns timebase period).
But that's comparing the counter reading to the real world. My table was comparing the displayed output to the likely raw measurements, and it seems to show that the counter's internal math is being performed to the full 10 digits of precision in the USB data, even when the gate time supports only 8 bits of accuracy. That's good news because it allows you to know when you have correctly guessed the input counts.
When trying to calculate the raw data from the reading, you do need to try an input count of 91 in addition to 90 and 92. 91 did show up in the small sample of period-mode measurements, even if it did not appear in any of the frequency-mode measurements.
I don't think the counter is doing "averaging", in the sense of making multiple independent short-period measurements and then averaging them for higher precision. Instead, it is just making one long continuous measurement, sampling the signal periodically, and then actually calculating frequency or period from two measurements separated by an appropriate time. For a simplified example:
Suppose the counter generates a time stamp approximately every 1 second (always aligned with the input signal active edge) and then stores the two pieces of raw data (the current input cycle counter and the current timebase counter) in a small memory buffer. The counters are never reset; they just need to be large enough to never overflow twice within the longest input period allowed (1000 s for the TF930). To display a frequency or period based on a 1 s gate time, the counter simply subtracts two successive data records to get delta-input and delta-timebase counts, then does its calculations based on those deltas. To display a 10 second gate time measurement, the counter looks back through its memory to find a time stamp about 10 seconds earlier than the most recent measurement (with high input frequency, that will generally be 10 measurements ago, but when measuring a signal with a 0.2 Hz frequency it's only 2 measurements ago). For a 100 second gate time measurement, the counter needs to find a saved time stamp that is about 100 seconds ago. Once it has found the correct data record, it calculates the difference in input and timebase counts between that one previous data record and the most recent, and then calculates the displayed value from it.
One second later, the counter can calculate a new 100 s measurement, using the new data point just captured and a different stored data point 100 seconds ago. But 99 of the 100 seconds in the new gate period are shared with the old gate period, so the displayed value is not likely to change very much simply because 99% of the observation period is shared.
Thus, every displayed value is calculated from only 2 time-stamped measurements. The longer gate time places those measurements further apart, reducing the uncertainty due to the +- 1 clock of the timebase. Because the counters run continuously without resetting, no clock edges are lost and a 100 s gate time measurement has only 20 ns uncertainty in the whole 100 s period. Also, any wander in the input frequency between those two measurements is invisible if it cancels out over the gate time. So there is "averaging" in the sense that the counter display always reflects what is happening on the scale of the gate time, but it's not computing and then averaging multiple numbers.
I have not tried doing my own ADEV calculations, so I can't say what it is about the shorter gate periods that make the oscillator appear noisier than it really is. How does the ADEV calculation aggregate a stream of short-time calculations into measurements for large tau values? My intuition is this: If you just take readings from the counter with a 1 s gate time, each reading has a 2e-8 uncertainty. If you average a bunch of these readings, and the errors are independent, the accuracy should improve by a factor of sqrt(N). But if you unwrap each reading into an integer number of input and timebase cycles, you essentially have a series of phase samples that can be added or subtracted without increasing the absolute uncertainty. So when you combine 100 1 second measurements, you get a relative accuracy that is 100 times better, not the sqrt(100) you'd get from averaging.
- Dave
On Wed, Mar 18, 2015 at 6:33 AM, jpbridge@aol.com wrote:
Hi Dave,
Interesting analysis. The accuracy stated in the manual is ...+ 2 counts and though this relates to the 50MHz clock, perhaps they use a similar algorithm for the input frequency.
I completed the 0.3 second measurements and the curve is similar to 1 second but higher up (i.e. as you'd expect by extrapolation from the behaviour of the other curves).
My ADEV calculation is based on the average frequency in each bin, the varying size of the bin should be insignificant as long as it is not affecting the average value within the bin. If the average frequency shifts by delta_F in one bin time step and the first bin is delta_T short (as a fraction of one bin time step) then the first frequency will be delta_T*delta_F low and the second bin perhaps that much high but the key point is that it is the product of the two deltas so it won't materially affect the accuracy of the calculation. At least I think that is correct.
Taking the worst possible case where the delta in bin size always went the wrong way so every term in the Alan Variance sum was multiplied by (1+2delta)^2 then the final Alan deviation might be (1 + 2 delta) too big but as delta is of the order of 10E-8 or less this wouldn't even register on the graphs.
What I might try doing is programming your approach into the code to try and get at the raw data - I only need to try 88,90 and 92 as possible counts - though to be sure I'll try mean frequency +- 5 say and then try and get the 50MHz clock values out as integers. What I might also do is then do a least squares fit (linear regression) to get the frequency over each bin and use the slope (this perhaps is what the counter does internally - I don't know).
I'd like to get to the bottom of this if only to understand my counter better.
James
-----Original Message-----
From: Dave Martindale dave.martindale@gmail.com
To: jpbridge < jpbridge@aol.com>; time-nuts < time-nuts@febo.com>
Sent: Wed, 18 Mar 2015 1:26
Subject: Re: [time-nuts] ADEV noise floor vs counter gate time
I believe I see the pattern. As you figured out, you wouldn't expect a single period to be a multiple of 20 ns; you expect the length of (about) 90 periods to be an integer multiple of 50 ns, since that's what the counter actually measures. Further, the measuring time isn't exactly 1 second, it is an integer number of periods of the input frequency that makes up at least 1 second. If the counting logic was all hardware, you would expect to capture either 90 or 91 cycles of the input, depending on whether the input frequency was slightly below or above 90 Hz respectively.
I built this table of your frequency data in Excel. Math is 64-bit floating point, equivalent to about 16 decimal digits, so plenty accurate enough to simulate this counter:
Reading Input Count TB Count Rounded Frequency Interval
90.00006359 92 51111074.998 51111075 90.00006359 1.022221500
90.00007591 92 51111068.002 51111068 90.00007591 1.022221360
89.99999640 90 50000002.000 50000002 89.99999640 1.000000040
89.99998740 90 50000007.000 50000007 89.99998740 1.000000140
90.00006007 92 51111076.997 51111077 90.00006007 1.022221540
89.99996040 90 50000022.000 50000022 89.99996040 1.000000440
90.00008648 92 51111061.999 51111062 90.00008648 1.022221240
90.00008472 92 51111062.999 51111063 90.00008472 1.022221260
90.00011465 92 51111046.001 51111046 90.00011465 1.022220920
90.00014459 92 51111028.998 51111029 90.00014459 1.022220580
The first column is your data. The second column is a guess about how many input cycles were captured. The third column is the number of timebase cycles that have elapsed since the previous reading, based on the first two columns. I hand-tweaked the numbers in the second column until the number in the third column was within 0.003 of an integer. The fact that I was always able to do this tells me that my guess is probably correct, and the small residual (which is a few parts in 1e-10) is due to the counter rounding the results to 10 digits. The 4th column is the result of rounding the previous column to the nearest integer. This is what I believe is the actual number of counts the counter saw. The 5th column is a fresh calculation of frequency, based on the integer number of input cycles in column 2 and the integer number of timebase cycles in column 4. When the result is rounded to 10 digits, you can see it matches the 10 digits that the counter provided back in column 1.
Oddly, the counter never captured 91 input cycles. If the input frequency was a little higher than 90 Hz, it always measured at 92 cycles, even though 91 cycles was well more than 1 s since the previous reading. I guess the microprocessor running the counter only checks periodically (e.g. every 20 ms) to see if the gate time has elapsed, and then latches the counts on the next active edge of the input signal.
So, I claim that with this small sample, at least, we recovered the exact number of 20 ns periods between samples, and the number of integer input cycles as well. Also notice the 6th column. This is the actual sample interval, based on the number of elapsed timebase counts. Note that the sample period is not exactly 1 second, nor is it even close to a constant value, since some measurements are of 90 cycles while others are of 92 cycles. Does your ADEV calculation algorithm take into account the variable spacing of the input samples in time? If it assumes they are regularly spaced (i.e. every 90 cycles) it may get confused by this variable-spacing data.
Now here is almost the same process applied to your period data:
Reading Input Count TB Count Rounded Period Interval
0.01111107736 91 50555401.988 50555402 0.01111107736 1.011108040
0.01111110130 92 51111065.980 51111066 0.01111110130 1.022221320
0.01111110769 91 50555539.990 50555540 0.01111110769 1.011110800
0.01111110435 92 51111080.010 51111080 0.01111110435 1.022221600
0.01111110593 91 50555531.982 50555532 0.01111110593 1.011110640
0.01111110022 90 49999950.990 49999951 0.01111110022 0.999999020
0.01111114000 90 50000130.000 50000130 0.01111114000 1.000002600
0.01111110000 90 49999950.000 49999950 0.01111110000 0.999999000
0.01111110370 92 51111077.020 51111077 0.01111110370 1.022221540
Again, column 2 was hand-adjusted for each row to keep the third column close to an integer. The residual errors here are larger, since the maximum rounding error of 0.5 in the last place is a larger change relative to a 10-digit value of 11111111 than it is to a value of 90000000, but all are still within 0.02 of being an integer. This time, the counter grabbed measurements after 90, 91, or 92 cycles. Again, after rounding the timebase count to an integer and calculating a 10-digit period for display, the result always matched what the counter output. Again, I think we know with high probability just how many input and timebase cycles were counted for each measurement.
I adjusted column 2 by eye, while looking at the results of column 3, but that process could be automated pretty easily (just not in Excel). As I tried 90, 91, and 92 in sequence, there was always just one of those which gave a small residual error.
So I think your TF930 is making measurements and accurately converting them to frequency or period, with a +- 20 ns uncertainty for each measurement. Since it is a time-stamping counter, the uncertainty in a 10 s or 100 s or 1000 s measurement time (assembled by external software) is still only 20 ns. That's great, but to actually get that accuracy over a long measurement time, you will need to determine and add up the actual number of input counts and timebase counts. And you will have to understand that the counter does not make measurements at constant or near-constant intervals (e.g. every 90 cycles of input, without exception). It gives you measurements whenever it gets around to measuring them.
Too bad there doesn't seem to be a way to get it to return the raw observed data (input cycle count, timebase cycle count) instead of the frequency or period derived from them. That would make it trivial to string together a bunch of 1s measurements into arbitrarily long gate times.
- Dave
On 17/03/2015 05:57, jpbridge@aol.com wrote:
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.martindale@gmail.com
To: jpbridge jpbridge@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.
Hi, James. I'm a Tektronix RF Application Engineer in Dallas and thought
I would throw in a few points about your FCA3100 (if you haven't read up
on these already):
All Tektronix manuals and technical reference documents can be
downloaded for no charge on our website (http://www.tek.com), but some
items may require you to register and sign in. The detailed
specification and performance verification document (document number
077-0495-01) has many details about the specifications, and is at:
http://www.tek.com/frequency-counter-supplies/mca3027-manual/fca3000-and-fca3100-series-mca3000-series
All downloadable files for this product can be found in the list at:
http://www.tek.com/search/apachesolr_search/fca3000 If you have a used
counter, be sure you check the firmware version and update it if needed.
If your exact model is "FCA3000", you have a 300 MHz counter with 100 ps
single-shot resolution. This counter has reciprocal counter features
(based on a 10 ns main counter time resolution), but also uses 100 ps
RMS jitter interpolation to determine edge location with an additional
X100 resolution. When the initial edge of the signal you are measuring
is detected, the interpolater resolves this edge with 100 ps resolution
relative to the internal 10 ns clock. After the desired measurement
interval, the final edge is also resolved with 100 ps resolution, and
the number of signal edges and interpolated intitial-to-final time are
used to determine the frequency (for example). The analog interpolation
circuit uses a constant current charging a capacitor with a sampler and
A/D converter. Counting a 100 MHz signal, this provides 12 digits of
resolution per second of measurement interval.
--
Bill Byrom N5BB
On Wed, Mar 18, 2015, at 05:49 PM, James via time-nuts wrote:
Hi Dave,
Thanks for another detailed response.
I've now programmed a version of my code that attempts to recover the
raw data by trying different counts up and down from the nominal and
finding the one with the smallest rounding error.
One problem is I need to restrain the amount it goes up or down
otherwise it finds erroneously small or large numbers of cycles (+/- 2
is believable, more than that isn't).
As an experiment I then changed the data to match the "raw data". This
doesn't change the shape of the curve but it lowers it so it starts
below 10^-15! This is suspiciously good so I think I'm smoothing out
changes that are really there.
Now that my new fca3100 has arrived I'm hoping to find time to get
measurements with it which should be proper time-stamped ones and much
more accurate - then I can compare the two.
To answer your question on ADEV aggregating values, and speaking as a
total newbee myself, the approach to different tau sizes is to
aggregate all measurements within a bin of size tau and average the
frequencies (or average the time differences and invert - for small
variations it makes very little difference as (1+delta)^-1 is 1-delta
ignoring delta*delta terms). Then each term in the Alan Variaton
summation is the square of the difference between the average
frequency in adjacent bins.
So with 1 second values at a tau of 100 secs, 100 values in each cell
are averaged whilst the 100 sec gate value results just have a single
value for each bin. But given that the counter itself should be
averaging there should be good agreement between the two - hence my
puzzlement.
The fca3100 calculates ADEV directly so I'll have a check on my code.
James
-----Original Message----- From: Dave Martindale
dave.martindale@gmail.com To: jpbridge jpbridge@aol.com
CC: Discussion of precise time and frequency measurement
time-nuts@febo.com Sent: Wed, 18 Mar 2015 15:22 Subject: Re:
[time-nuts] ADEV noise floor vs counter gate time
The counter always has a 1 count uncertainty in the timebase
measurement, which is a 2e-8 error with a 1 second gate time. If the
value being displayed starts with the digit 9, and 8 digits are
displayed, then that translates to +- 2 counts in the last place. But
the measurements are synchronized to the input signal, so it always
measures an integer number of input cycles, and there should be no
comparable uncertainty in the input (other than some noise in deciding
exactly when the edge crosses the input threshold, which should be
tiny compared to the 20 ns timebase period).
But that's comparing the counter reading to the real world. My table
was comparing the displayed output to the likely raw measurements, and
it seems to show that the counter's internal math is being performed
to the full 10 digits of precision in the USB data, even when the gate
time supports only 8 bits of accuracy. That's good news because it
allows you to know when you have correctly guessed the input counts.
When trying to calculate the raw data from the reading, you do need to
try an input count of 91 in addition to 90 and 92. 91 did show up in
the small sample of period-mode measurements, even if it did not
appear in any of the frequency-mode measurements.
I don't think the counter is doing "averaging", in the sense of making
multiple independent short-period measurements and then averaging them
for higher precision. Instead, it is just making one long continuous
measurement, sampling the signal periodically, and then actually
calculating frequency or period from two measurements separated by an
appropriate time. For a simplified example:
Suppose the counter generates a time stamp approximately every 1
second (always aligned with the input signal active edge) and then
stores the two pieces of raw data (the current input cycle counter and
the current timebase counter) in a small memory buffer. The counters
are never reset; they just need to be large enough to never overflow
twice within the longest input period allowed (1000 s for the TF930).
To display a frequency or period based on a 1 s gate time, the counter
simply subtracts two successive data records to get delta-input and
delta-timebase counts, then does its calculations based on those
deltas. To display a 10 second gate time measurement, the counter
looks back through its memory to find a time stamp about 10 seconds
earlier than the most recent measurement (with high input frequency,
that will generally be 10 measurements ago, but when measuring a
signal with a 0.2 Hz frequency it's only 2 measurements ago). For a
100 second gate time measurement, the count er needs to find a saved
time stamp that is about 100 seconds ago. Once it has found the
correct data record, it calculates the difference in input and
timebase counts between that one previous data record and the most
recent, and then calculates the displayed value from it.
One second later, the counter can calculate a new 100 s measurement,
using the new data point just captured and a different stored data
point 100 seconds ago. But 99 of the 100 seconds in the new gate
period are shared with the old gate period, so the displayed value is
not likely to change very much simply because 99% of the observation
period is shared.
Thus, every displayed value is calculated from only 2 time-stamped
measurements. The longer gate time places those measurements further
apart, reducing the uncertainty due to the +- 1 clock of the timebase.
Because the counters run continuously without resetting, no clock
edges are lost and a 100 s gate time measurement has only 20 ns
uncertainty in the whole 100 s period. Also, any wander in the input
frequency between those two measurements is invisible if it cancels
out over the gate time. So there is "averaging" in the sense that the
counter display always reflects what is happening on the scale of the
gate time, but it's not computing and then averaging multiple numbers.
I have not tried doing my own ADEV calculations, so I can't say what
it is about the shorter gate periods that make the oscillator appear
noisier than it really is. How does the ADEV calculation aggregate a
stream of short-time calculations into measurements for large tau
values? My intuition is this: If you just take readings from the
counter with a 1 s gate time, each reading has a 2e-8 uncertainty. If
you average a bunch of these readings, and the errors are independent,
the accuracy should improve by a factor of sqrt(N). But if you unwrap
each reading into an integer number of input and timebase cycles, you
essentially have a series of phase samples that can be added or
subtracted without increasing the absolute uncertainty. So when you
combine 100 1 second measurements, you get a relative accuracy that is
100 times better, not the sqrt(100) you'd get from averaging.
- Dave
On Wed, Mar 18, 2015 at 6:33 AM, jpbridge@aol.com wrote:
Hi Dave,
Interesting analysis. The accuracy stated in the manual is ...+ 2
counts and though this relates to the 50MHz clock, perhaps they use a
similar algorithm for the input frequency.
I completed the 0.3 second measurements and the curve is similar to 1
second but higher up (i.e. as you'd expect by extrapolation from the
behaviour of the other curves).
My ADEV calculation is based on the average frequency in each bin, the
varying size of the bin should be insignificant as long as it is not
affecting the average value within the bin. If the average frequency
shifts by delta_F in one bin time step and the first bin is delta_T
short (as a fraction of one bin time step) then the first frequency
will be delta_T*delta_F low and the second bin perhaps that much high
but the key point is that it is the product of the two deltas so it
won't materially affect the accuracy of the calculation. At least I
think that is correct.
Taking the worst possible case where the delta in bin size always went
the wrong way so every term in the Alan Variance sum was multiplied by
(1+2delta)^2 then the final Alan deviation might be (1 + 2 delta) too
big but as delta is of the order of 10E-8 or less this wouldn't even
register on the graphs.
What I might try doing is programming your approach into the code to
try and get at the raw data - I only need to try 88,90 and 92 as
possible counts - though to be sure I'll try mean frequency +- 5 say
and then try and get the 50MHz clock values out as integers. What I
might also do is then do a least squares fit (linear regression) to
get the frequency over each bin and use the slope (this perhaps is
what the counter does internally - I don't know).
I'd like to get to the bottom of this if only to understand my
counter better.
James
-----Original Message----- From: Dave Martindale
dave.martindale@gmail.com
To: jpbridge < jpbridge@aol.com>; time-nuts < time-nuts@febo.com>
Sent: Wed, 18 Mar 2015 1:26 Subject: Re: [time-nuts] ADEV noise floor
vs counter gate time
I believe I see the pattern. As you figured out, you wouldn't expect a
single period to be a multiple of 20 ns; you expect the length of
(about) 90 periods to be an integer multiple of 50 ns, since that's
what the counter actually measures. Further, the measuring time isn't
exactly 1 second, it is an integer number of periods of the input
frequency that makes up at least 1 second. If the counting logic was
all hardware, you would expect to capture either 90 or 91 cycles of
the input, depending on whether the input frequency was slightly below
or above 90 Hz respectively.
I built this table of your frequency data in Excel. Math is 64-bit
floating point, equivalent to about 16 decimal digits, so plenty
accurate enough to simulate this counter:
Reading Input Count TB Count Rounded Frequency Interval 90.00006359 92
51111074.998 51111075 90.00006359 1.022221500 90.00007591 92
51111068.002 51111068 90.00007591 1.022221360 89.99999640 90
50000002.000 50000002 89.99999640 1.000000040 89.99998740 90
50000007.000 50000007 89.99998740 1.000000140 90.00006007 92
51111076.997 51111077 90.00006007 1.022221540 89.99996040 90
50000022.000 50000022 89.99996040 1.000000440 90.00008648 92
51111061.999 51111062 90.00008648 1.022221240 90.00008472 92
51111062.999 51111063 90.00008472 1.022221260 90.00011465 92
51111046.001 51111046 90.00011465 1.022220920 90.00014459 92
51111028.998 51111029 90.00014459 1.022220580
The first column is your data. The second column is a guess about how
many input cycles were captured. The third column is the number of
timebase cycles that have elapsed since the previous reading, based on
the first two columns. I hand-tweaked the numbers in the second column
until the number in the third column was within 0.003 of an integer.
The fact that I was always able to do this tells me that my guess is
probably correct, and the small residual (which is a few parts in
1e-10) is due to the counter rounding the results to 10 digits. The
4th column is the result of rounding the previous column to the
nearest integer. This is what I believe is the actual number of counts
the counter saw. The 5th column is a fresh calculation of frequency,
based on the integer number of input cycles in column 2 and the
integer number of timebase cycles in column 4. When the result is
rounded to 10 digits, you can see it matches the 10 digits that the
counter provided back in column 1.
Oddly, the counter never captured 91 input cycles. If the input
frequency was a little higher than 90 Hz, it always measured at 92
cycles, even though 91 cycles was well more than 1 s since the
previous reading. I guess the microprocessor running the counter only
checks periodically (e.g. every 20 ms) to see if the gate time has
elapsed, and then latches the counts on the next active edge of the
input signal.
So, I claim that with this small sample, at least, we recovered the
exact number of 20 ns periods between samples, and the number of
integer input cycles as well. Also notice the 6th column. This is the
actual sample interval, based on the number of elapsed timebase
counts. Note that the sample period is not exactly 1 second, nor
is it even close to a constant value, since some measurements are of
90 cycles while others are of 92 cycles. Does your ADEV calculation
algorithm take into account the variable spacing of the input samples
in time? If it assumes they are regularly spaced (i.e. every 90
cycles) it may get confused by this variable-spacing data.
Now here is almost the same process applied to your period data:
Reading Input Count TB Count Rounded Period Interval 0.01111107736 91
50555401.988 50555402 0.01111107736 1.011108040 0.01111110130 92
51111065.980 51111066 0.01111110130 1.022221320 0.01111110769 91
50555539.990 50555540 0.01111110769 1.011110800 0.01111110435 92
51111080.010 51111080 0.01111110435 1.022221600 0.01111110593 91
50555531.982 50555532 0.01111110593 1.011110640 0.01111110022 90
49999950.990 49999951 0.01111110022 0.999999020 0.01111114000 90
50000130.000 50000130 0.01111114000 1.000002600 0.01111110000 90
49999950.000 49999950 0.01111110000 0.999999000 0.01111110370 92
51111077.020 51111077 0.01111110370 1.022221540
Again, column 2 was hand-adjusted for each row to keep the third
column close to an integer. The residual errors here are larger, since
the maximum rounding error of 0.5 in the last place is a larger change
relative to a 10-digit value of 11111111 than it is to a value of
90000000, but all are still within 0.02 of being an integer. This
time, the counter grabbed measurements after 90, 91, or 92 cycles.
Again, after rounding the timebase count to an integer and calculating
a 10-digit period for display, the result always matched what the
counter output. Again, I think we know with high probability just how
many input and timebase cycles were counted for each measurement.
I adjusted column 2 by eye, while looking at the results of column 3,
but that process could be automated pretty easily (just not in Excel).
As I tried 90, 91, and 92 in sequence, there was always just one of
those which gave a small residual error.
So I think your TF930 is making measurements and accurately converting
them to frequency or period, with a +- 20 ns uncertainty for each
measurement. Since it is a time-stamping counter, the uncertainty in a
10 s or 100 s or 1000 s measurement time (assembled by external
software) is still only 20 ns. That's great, but to actually get that
accuracy over a long measurement time, you will need to determine and
add up the actual number of input counts and timebase counts. And you
will have to understand that the counter does not make measurements at
constant or near-constant intervals (e.g. every 90 cycles of input,
without exception). It gives you measurements whenever it gets around
to measuring them.
Too bad there doesn't seem to be a way to get it to return the raw
observed data (input cycle count, timebase cycle count) instead of
the frequency or period derived from them. That would make it trivial
to string together a bunch of 1s measurements into arbitrarily long
gate times.
- Dave
On 17/03/2015 05:57, jpbridge@aol.com wrote:
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.martindale@gmail.com To: jpbridge jpbridge@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.
Hi Bill,
Thanks for the pointers.
I should say that my results reported so far have been with my older TTi TF930 reciprocal counter, not with my FCA3100 which I have only just got (it arrived a few days ago) and I'm in the process of writing software to talk to it via the USB.
I did discover the website, in fact I'd downloaded the manual before buying the counter, and it is fortunate I did because the website for me didn't work - I'm currently talking to Tek support about it.
The problem is that to download software you must have your details registered. Every time I register my details and press the "save" button the site wipes all my details and returns to a blank form. When I try to down load the software it then stops me and tells me to update my details. I update my details and it blanks the form and so on... slightly frustrating. I've tried both Firefox and IE.
The other thing is that the manuals don't show on the European site (I'm in the UK), you click on them but the download screen just shows a blank line. I got round this by going to the international site and just closing the screen asking me for my area rather than responding to it - I had to do this several times.
I have now downloaded NI-VISA and have managed to do a bit of talking to the instrument over USB though I've not yet had time to do this properly.
So in summary - I'm pleased with my counter but the Tek website for Europe at least has some serious bugs which hopefully will be fixed soon. The Tek support person I spoke to on the phone was helpful but she wasn't in a position to fix the web site issues directly so has forwarded my case to Tek IT.
I intend repeating my TTi TF930 experiment with my FCA3100 when I've got everything working ok and am looking forward to seeing the results.
James
-----Original Message-----
From: Bill Byrom time@radio.sent.com
To: time-nuts time-nuts@febo.com
Sent: Sun, 22 Mar 2015 2:27
Subject: Re: [time-nuts] ADEV noise floor vs counter gate time
Hi, James. I'm a Tektronix RF Application Engineer in Dallas and thought
I
would throw in a few points about your FCA3100 (if you haven't read up
on these
already):
All Tektronix manuals and technical reference documents can
be
downloaded for no charge on our website (http://www.tek.com), but
some
items may require you to register and sign in. The detailed
specification
and performance verification document (document number
077-0495-01) has many
details about the specifications, and is
at:
http://www.tek.com/frequency-counter-supplies/mca3027-manual/fca3000-and-fca3100-series-mca3000-series
All
downloadable files for this product can be found in the list
at:
http://www.tek.com/search/apachesolr_search/fca3000 If you have a
used
counter, be sure you check the firmware version and update it if
needed.
If your exact model is "FCA3000", you have a 300 MHz counter with 100
ps
single-shot resolution. This counter has reciprocal counter features
(based
on a 10 ns main counter time resolution), but also uses 100 ps
RMS jitter
interpolation to determine edge location with an additional
X100 resolution.
When the initial edge of the signal you are measuring
is detected, the
interpolater resolves this edge with 100 ps resolution
relative to the internal
10 ns clock. After the desired measurement
interval, the final edge is also
resolved with 100 ps resolution, and
the number of signal edges and
interpolated intitial-to-final time are
used to determine the frequency (for
example). The analog interpolation
circuit uses a constant current charging a
capacitor with a sampler and
A/D converter. Counting a 100 MHz signal, this
provides 12 digits of
resolution per second of measurement
interval.
--
Bill Byrom N5BB
On Wed, Mar 18, 2015, at 05:49 PM, James
via time-nuts wrote:
Hi Dave,
Thanks for another detailed
response.
I've now programmed a version of my code that attempts to
recover the
raw data by trying different counts up and down from the nominal
and
finding the one with the smallest rounding error.
One problem is I
need to restrain the amount it goes up or down
otherwise it finds erroneously
small or large numbers of cycles (+/- 2
is believable, more than that
isn't).
As an experiment I then changed the data to match the "raw data".
This
doesn't change the shape of the curve but it lowers it so it starts
below 10^-15! This is suspiciously good so I think I'm smoothing out
changes
that are really there.
Now that my new fca3100 has arrived I'm hoping to
find time to get
measurements with it which should be proper time-stamped
ones and much
more accurate - then I can compare the two.
To answer
your question on ADEV aggregating values, and speaking as a
total newbee
myself, the approach to different tau sizes is to
aggregate all measurements
within a bin of size tau and average the
frequencies (or average the time
differences and invert - for small
variations it makes very little difference
as (1+delta)^-1 is 1-delta
ignoring delta*delta terms). Then each term in the
Alan Variaton
summation is the square of the difference between the
average
frequency in adjacent bins.
So with 1 second values at a tau of
100 secs, 100 values in each cell
are averaged whilst the 100 sec gate value
results just have a single
value for each bin. But given that the counter
itself should be
averaging there should be good agreement between the two -
hence my
puzzlement.
The fca3100 calculates ADEV directly so I'll have
a check on my code.
James
-----Original
Message----- From: Dave Martindale
dave.martindale@gmail.com To: jpbridge
CC: Discussion of precise time and frequency
measurement
<time-nuts@febo.com> Sent: Wed, 18 Mar 2015 15:22 Subject:
Re:
[time-nuts] ADEV noise floor vs counter gate time
The
counter always has a 1 count uncertainty in the timebase
measurement, which
is a 2e-8 error with a 1 second gate time. If the
value being displayed
starts with the digit 9, and 8 digits are
displayed, then that translates to
+- 2 counts in the last place. But
the measurements are synchronized to the
input signal, so it always
measures an integer number of input cycles, and
there should be no
comparable uncertainty in the input (other than some noise
in deciding
exactly when the edge crosses the input threshold, which should
be
tiny compared to the 20 ns timebase period).
But that's
comparing the counter reading to the real world. My table
was comparing the
displayed output to the likely raw measurements, and
it seems to show that
the counter's internal math is being performed
to the full 10 digits of
precision in the USB data, even when the gate
time supports only 8 bits of
accuracy. That's good news because it
allows you to know when you have
correctly guessed the input counts.
When trying to calculate the
raw data from the reading, you do need to
try an input count of 91 in
addition to 90 and 92. 91 did show up in
the small sample of period-mode
measurements, even if it did not
appear in any of the frequency-mode
measurements.
I don't think the counter is doing "averaging", in
the sense of making
multiple independent short-period measurements and then
averaging them
for higher precision. Instead, it is just making one long
continuous
measurement, sampling the signal periodically, and then
actually
calculating frequency or period from two measurements separated by
an
appropriate time. For a simplified example:
Suppose the
counter generates a time stamp approximately every 1
second (always aligned
with the input signal active edge) and then
stores the two pieces of raw data
(the current input cycle counter and
the current timebase counter) in a small
memory buffer. The counters
are never reset; they just need to be large
enough to never overflow
twice within the longest input period allowed (1000
s for the TF930).
To display a frequency or period based on a 1 s gate time,
the counter
simply subtracts two successive data records to get delta-input
and
delta-timebase counts, then does its calculations based on those
deltas. To display a 10 second gate time measurement, the counter
looks back
through its memory to find a time stamp about 10 seconds
earlier than the
most recent measurement (with high input frequency,
that will generally be 10
measurements ago, but when measuring a
signal with a 0.2 Hz frequency it's
only 2 measurements ago). For a
100 second gate time measurement, the count
er needs to find a saved
time stamp that is about 100 seconds ago. Once it
has found the
correct data record, it calculates the difference in input
and
timebase counts between that one previous data record and the most
recent, and then calculates the displayed value from it.
One
second later, the counter can calculate a new 100 s measurement,
using the
new data point just captured and a different stored data
point 100 seconds
ago. But 99 of the 100 seconds in the new gate
period are shared with the old
gate period, so the displayed value is
not likely to change very much simply
because 99% of the observation
period is shared.
Thus, every
displayed value is calculated from only 2 time-stamped
measurements. The
longer gate time places those measurements further
apart, reducing the
uncertainty due to the +- 1 clock of the timebase.
Because the counters run
continuously without resetting, no clock
edges are lost and a 100 s gate time
measurement has only 20 ns
uncertainty in the whole 100 s period. Also, any
wander in the input
frequency between those two measurements is invisible if
it cancels
out over the gate time. So there is "averaging" in the sense that
the
counter display always reflects what is happening on the scale of the
gate time, but it's not computing and then averaging multiple
numbers.
I have not tried doing my own ADEV calculations, so I
can't say what
it is about the shorter gate periods that make the oscillator
appear
noisier than it really is. How does the ADEV calculation aggregate
a
stream of short-time calculations into measurements for large tau
values? My intuition is this: If you just take readings from the
counter with
a 1 s gate time, each reading has a 2e-8 uncertainty. If
you average a bunch
of these readings, and the errors are independent,
the accuracy should
improve by a factor of sqrt(N). But if you unwrap
each reading into an
integer number of input and timebase cycles, you
essentially have a series of
phase samples that can be added or
subtracted without increasing the absolute
uncertainty. So when you
combine 100 1 second measurements, you get a
relative accuracy that is
100 times better, not the sqrt(100) you'd get from
averaging.
- Dave
On Wed, Mar 18, 2015 at
6:33 AM, jpbridge@aol.com wrote:
Hi Dave,
Interesting analysis.
The accuracy stated in the manual is ...+ 2
counts and though this relates to
the 50MHz clock, perhaps they use a
similar algorithm for the input
frequency.
I completed the 0.3 second measurements and the curve is
similar to 1
second but higher up (i.e. as you'd expect by extrapolation from
the
behaviour of the other curves).
My ADEV calculation is based on the
average frequency in each bin, the
varying size of the bin should be
insignificant as long as it is not
affecting the average value within the
bin. If the average frequency
shifts by delta_F in one bin time step and the
first bin is delta_T
short (as a fraction of one bin time step) then the
first frequency
will be delta_T*delta_F low and the second bin perhaps that
much high
but the key point is that it is the product of the two deltas so
it
won't materially affect the accuracy of the calculation. At least I
think that is correct.
Taking the worst possible case where the delta in
bin size always went
the wrong way so every term in the Alan Variance sum was
multiplied by
(1+2delta)^2 then the final Alan deviation might be (1 + 2
delta) too
big but as delta is of the order of 10E-8 or less this wouldn't
even
register on the graphs.
What I might try doing is programming your
approach into the code to
try and get at the raw data - I only need to try
88,90 and 92 as
possible counts - though to be sure I'll try mean frequency
+- 5 say
and then try and get the 50MHz clock values out as integers. What
I
might also do is then do a least squares fit (linear regression) to
get
the frequency over each bin and use the slope (this perhaps is
what the
counter does internally - I don't know).
I'd like to get to the bottom of
this if only to understand my
counter better.
James
-----Original Message-----
From: Dave Martindale
jpbridge@aol.com>; time-nuts < time-nuts@febo.com>
Sent: Wed, 18 Mar 2015
1:26 Subject: Re: [time-nuts] ADEV noise floor
vs counter gate
time
I believe I see the pattern. As you figured out, you wouldn't
expect a
single period to be a multiple of 20 ns; you expect the length of
(about) 90 periods to be an integer multiple of 50 ns, since that's
what the
counter actually measures. Further, the measuring time isn't
exactly 1
second, it is an integer number of periods of the input
frequency that makes
up at least 1 second. If the counting logic was
all hardware, you would
expect to capture either 90 or 91 cycles of
the input, depending on whether
the input frequency was slightly below
or above 90 Hz respectively.
I
built this table of your frequency data in Excel. Math is 64-bit
floating
point, equivalent to about 16 decimal digits, so plenty
accurate enough to
simulate this counter:
Reading Input Count TB Count Rounded Frequency
Interval 90.00006359 92
51111074.998 51111075 90.00006359 1.022221500
90.00007591 92
51111068.002 51111068 90.00007591 1.022221360 89.99999640
90
50000002.000 50000002 89.99999640 1.000000040 89.99998740 90
50000007.000 50000007 89.99998740 1.000000140 90.00006007 92
51111076.997
51111077 90.00006007 1.022221540 89.99996040 90
50000022.000 50000022
89.99996040 1.000000440 90.00008648 92
51111061.999 51111062 90.00008648
1.022221240 90.00008472 92
51111062.999 51111063 90.00008472 1.022221260
90.00011465 92
51111046.001 51111046 90.00011465 1.022220920 90.00014459
92
51111028.998 51111029 90.00014459 1.022220580
The first column is
your data. The second column is a guess about how
many input cycles were
captured. The third column is the number of
timebase cycles that have elapsed
since the previous reading, based on
the first two columns. I hand-tweaked
the numbers in the second column
until the number in the third column was
within 0.003 of an integer.
The fact that I was always able to do this tells
me that my guess is
probably correct, and the small residual (which is a few
parts in
1e-10) is due to the counter rounding the results to 10 digits.
The
4th column is the result of rounding the previous column to the
nearest integer. This is what I believe is the actual number of counts
the
counter saw. The 5th column is a fresh calculation of frequency,
based on the
integer number of input cycles in column 2 and the
integer number of timebase
cycles in column 4. When the result is
rounded to 10 digits, you can see it
matches the 10 digits that the
counter provided back in column 1.
Oddly, the counter never captured 91 input cycles. If the input
frequency was
a little higher than 90 Hz, it always measured at 92
cycles, even though 91
cycles was well more than 1 s since the
previous reading. I guess the
microprocessor running the counter only
checks periodically (e.g. every 20
ms) to see if the gate time has
elapsed, and then latches the counts on the
next active edge of the
input signal.
So, I claim that with this small
sample, at least, we recovered the
exact number of 20 ns periods between
samples, and the number of
integer input cycles as well. Also notice the 6th
column. This is the
actual sample interval, based on the number of elapsed
timebase
counts. Note that the sample period is not exactly 1 second,
nor
is it even close to a constant value, since some measurements are of
90 cycles while others are of 92 cycles. Does your ADEV calculation
algorithm
take into account the variable spacing of the input samples
in time? If it
assumes they are regularly spaced (i.e. every 90
cycles) it may get confused
by this variable-spacing data.
Now here is almost the same process applied
to your period data:
Reading Input Count TB Count Rounded Period Interval
0.01111107736 91
50555401.988 50555402 0.01111107736 1.011108040
0.01111110130 92
51111065.980 51111066 0.01111110130 1.022221320
0.01111110769 91
50555539.990 50555540 0.01111110769 1.011110800
0.01111110435 92
51111080.010 51111080 0.01111110435 1.022221600
0.01111110593 91
50555531.982 50555532 0.01111110593 1.011110640
0.01111110022 90
49999950.990 49999951 0.01111110022 0.999999020
0.01111114000 90
50000130.000 50000130 0.01111114000 1.000002600
0.01111110000 90
49999950.000 49999950 0.01111110000 0.999999000
0.01111110370 92
51111077.020 51111077 0.01111110370 1.022221540
Again,
column 2 was hand-adjusted for each row to keep the third
column close to an
integer. The residual errors here are larger, since
the maximum rounding
error of 0.5 in the last place is a larger change
relative to a 10-digit
value of 11111111 than it is to a value of
90000000, but all are still within
0.02 of being an integer. This
time, the counter grabbed measurements after
90, 91, or 92 cycles.
Again, after rounding the timebase count to an integer
and calculating
a 10-digit period for display, the result always matched what
the
counter output. Again, I think we know with high probability just how
many input and timebase cycles were counted for each measurement.
I
adjusted column 2 by eye, while looking at the results of column 3,
but that
process could be automated pretty easily (just not in Excel).
As I tried 90,
91, and 92 in sequence, there was always just one of
those which gave a small
residual error.
So I think your TF930 is making measurements and
accurately converting
them to frequency or period, with a +- 20 ns
uncertainty for each
measurement. Since it is a time-stamping counter, the
uncertainty in a
10 s or 100 s or 1000 s measurement time (assembled by
external
software) is still only 20 ns. That's great, but to actually get
that
accuracy over a long measurement time, you will need to determine and
add up the actual number of input counts and timebase counts. And you
will
have to understand that the counter does not make measurements at
constant or
near-constant intervals (e.g. every 90 cycles of input,
without exception).
It gives you measurements whenever it gets around
to measuring them.
Too bad there doesn't seem to be a way to get it to return the raw
observed
data (input cycle count, timebase cycle count) instead of
the frequency or
period derived from them. That would make it trivial
to string together a
bunch of 1s measurements into arbitrarily long
gate times.
Dave
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.martindale@gmail.com To: jpbridge jpbridge@aol.com;
Discussion of precise time and frequency measurement
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
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.
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.
Was the website problem this past week? The main Tek US website was
acting up for a while one day this week, but seems to be fine now. I
have no insights on European access.
--
Bill Byrom N5BB
On Sun, Mar 22, 2015, at 07:10 AM, James via time-nuts wrote:
Hi Bill,
Thanks for the pointers.
I should say that my results reported so far have been with my older TTi
TF930 reciprocal counter, not with my FCA3100 which I have only just got
(it arrived a few days ago) and I'm in the process of writing software to
talk to it via the USB.
I did discover the website, in fact I'd downloaded the manual before
buying the counter, and it is fortunate I did because the website for me
didn't work - I'm currently talking to Tek support about it.
The problem is that to download software you must have your details
registered. Every time I register my details and press the "save" button
the site wipes all my details and returns to a blank form. When I try to
down load the software it then stops me and tells me to update my
details. I update my details and it blanks the form and so on... slightly
frustrating. I've tried both Firefox and IE.
The other thing is that the manuals don't show on the European site (I'm
in the UK), you click on them but the download screen just shows a blank
line. I got round this by going to the international site and just
closing the screen asking me for my area rather than responding to it - I
had to do this several times.
I have now downloaded NI-VISA and have managed to do a bit of talking to
the instrument over USB though I've not yet had time to do this properly.
So in summary - I'm pleased with my counter but the Tek website for
Europe at least has some serious bugs which hopefully will be fixed soon.
The Tek support person I spoke to on the phone was helpful but she wasn't
in a position to fix the web site issues directly so has forwarded my
case to Tek IT.
I intend repeating my TTi TF930 experiment with my FCA3100 when I've got
everything working ok and am looking forward to seeing the results.
James
-----Original Message-----
From: Bill Byrom time@radio.sent.com
To: time-nuts time-nuts@febo.com
Sent: Sun, 22 Mar 2015 2:27
Subject: Re: [time-nuts] ADEV noise floor vs counter gate time
Hi, James. I'm a Tektronix RF Application Engineer in Dallas and thought
I
would throw in a few points about your FCA3100 (if you haven't read up
on these
already):
All Tektronix manuals and technical reference documents can
be
downloaded for no charge on our website (http://www.tek.com), but
some
items may require you to register and sign in. The detailed
specification
and performance verification document (document number
077-0495-01) has many
details about the specifications, and is
at:
http://www.tek.com/frequency-counter-supplies/mca3027-manual/fca3000-and-fca3100-series-mca3000-series
All
downloadable files for this product can be found in the list
at:
http://www.tek.com/search/apachesolr_search/fca3000 If you have a
used
counter, be sure you check the firmware version and update it if
needed.
If your exact model is "FCA3000", you have a 300 MHz counter with 100
ps
single-shot resolution. This counter has reciprocal counter features
(based
on a 10 ns main counter time resolution), but also uses 100 ps
RMS jitter
interpolation to determine edge location with an additional
X100 resolution.
When the initial edge of the signal you are measuring
is detected, the
interpolater resolves this edge with 100 ps resolution
relative to the internal
10 ns clock. After the desired measurement
interval, the final edge is also
resolved with 100 ps resolution, and
the number of signal edges and
interpolated intitial-to-final time are
used to determine the frequency (for
example). The analog interpolation
circuit uses a constant current charging a
capacitor with a sampler and
A/D converter. Counting a 100 MHz signal, this
provides 12 digits of
resolution per second of measurement
interval.
--
Bill Byrom N5BB
On Wed, Mar 18, 2015, at 05:49 PM, James
via time-nuts wrote:
Hi Dave,
Thanks for another detailed
response.
I've now programmed a version of my code that attempts to
recover the
raw data by trying different counts up and down from the nominal
and
finding the one with the smallest rounding error.
One problem is I
need to restrain the amount it goes up or down
otherwise it finds erroneously
small or large numbers of cycles (+/- 2
is believable, more than that
isn't).
As an experiment I then changed the data to match the "raw data".
This
doesn't change the shape of the curve but it lowers it so it starts
below 10^-15! This is suspiciously good so I think I'm smoothing out
changes
that are really there.
Now that my new fca3100 has arrived I'm hoping to
find time to get
measurements with it which should be proper time-stamped
ones and much
more accurate - then I can compare the two.
To answer
your question on ADEV aggregating values, and speaking as a
total newbee
myself, the approach to different tau sizes is to
aggregate all measurements
within a bin of size tau and average the
frequencies (or average the time
differences and invert - for small
variations it makes very little difference
as (1+delta)^-1 is 1-delta
ignoring delta*delta terms). Then each term in the
Alan Variaton
summation is the square of the difference between the
average
frequency in adjacent bins.
So with 1 second values at a tau of
100 secs, 100 values in each cell
are averaged whilst the 100 sec gate value
results just have a single
value for each bin. But given that the counter
itself should be
averaging there should be good agreement between the two -
hence my
puzzlement.
The fca3100 calculates ADEV directly so I'll have
a check on my code.
James
-----Original
Message----- From: Dave Martindale
dave.martindale@gmail.com To: jpbridge
CC: Discussion of precise time and frequency
measurement
<time-nuts@febo.com> Sent: Wed, 18 Mar 2015 15:22 Subject:
Re:
[time-nuts] ADEV noise floor vs counter gate time
The
counter always has a 1 count uncertainty in the timebase
measurement, which
is a 2e-8 error with a 1 second gate time. If the
value being displayed
starts with the digit 9, and 8 digits are
displayed, then that translates to
+- 2 counts in the last place. But
the measurements are synchronized to the
input signal, so it always
measures an integer number of input cycles, and
there should be no
comparable uncertainty in the input (other than some noise
in deciding
exactly when the edge crosses the input threshold, which should
be
tiny compared to the 20 ns timebase period).
But that's
comparing the counter reading to the real world. My table
was comparing the
displayed output to the likely raw measurements, and
it seems to show that
the counter's internal math is being performed
to the full 10 digits of
precision in the USB data, even when the gate
time supports only 8 bits of
accuracy. That's good news because it
allows you to know when you have
correctly guessed the input counts.
When trying to calculate the
raw data from the reading, you do need to
try an input count of 91 in
addition to 90 and 92. 91 did show up in
the small sample of period-mode
measurements, even if it did not
appear in any of the frequency-mode
measurements.
I don't think the counter is doing "averaging", in
the sense of making
multiple independent short-period measurements and then
averaging them
for higher precision. Instead, it is just making one long
continuous
measurement, sampling the signal periodically, and then
actually
calculating frequency or period from two measurements separated by
an
appropriate time. For a simplified example:
Suppose the
counter generates a time stamp approximately every 1
second (always aligned
with the input signal active edge) and then
stores the two pieces of raw data
(the current input cycle counter and
the current timebase counter) in a small
memory buffer. The counters
are never reset; they just need to be large
enough to never overflow
twice within the longest input period allowed (1000
s for the TF930).
To display a frequency or period based on a 1 s gate time,
the counter
simply subtracts two successive data records to get delta-input
and
delta-timebase counts, then does its calculations based on those
deltas. To display a 10 second gate time measurement, the counter
looks back
through its memory to find a time stamp about 10 seconds
earlier than the
most recent measurement (with high input frequency,
that will generally be 10
measurements ago, but when measuring a
signal with a 0.2 Hz frequency it's
only 2 measurements ago). For a
100 second gate time measurement, the count
er needs to find a saved
time stamp that is about 100 seconds ago. Once it
has found the
correct data record, it calculates the difference in input
and
timebase counts between that one previous data record and the most
recent, and then calculates the displayed value from it.
One
second later, the counter can calculate a new 100 s measurement,
using the
new data point just captured and a different stored data
point 100 seconds
ago. But 99 of the 100 seconds in the new gate
period are shared with the old
gate period, so the displayed value is
not likely to change very much simply
because 99% of the observation
period is shared.
Thus, every
displayed value is calculated from only 2 time-stamped
measurements. The
longer gate time places those measurements further
apart, reducing the
uncertainty due to the +- 1 clock of the timebase.
Because the counters run
continuously without resetting, no clock
edges are lost and a 100 s gate time
measurement has only 20 ns
uncertainty in the whole 100 s period. Also, any
wander in the input
frequency between those two measurements is invisible if
it cancels
out over the gate time. So there is "averaging" in the sense that
the
counter display always reflects what is happening on the scale of the
gate time, but it's not computing and then averaging multiple
numbers.
I have not tried doing my own ADEV calculations, so I
can't say what
it is about the shorter gate periods that make the oscillator
appear
noisier than it really is. How does the ADEV calculation aggregate
a
stream of short-time calculations into measurements for large tau
values? My intuition is this: If you just take readings from the
counter with
a 1 s gate time, each reading has a 2e-8 uncertainty. If
you average a bunch
of these readings, and the errors are independent,
the accuracy should
improve by a factor of sqrt(N). But if you unwrap
each reading into an
integer number of input and timebase cycles, you
essentially have a series of
phase samples that can be added or
subtracted without increasing the absolute
uncertainty. So when you
combine 100 1 second measurements, you get a
relative accuracy that is
100 times better, not the sqrt(100) you'd get from
averaging.
- Dave
On Wed, Mar 18, 2015 at
6:33 AM, jpbridge@aol.com wrote:
Hi Dave,
Interesting analysis.
The accuracy stated in the manual is ...+ 2
counts and though this relates to
the 50MHz clock, perhaps they use a
similar algorithm for the input
frequency.
I completed the 0.3 second measurements and the curve is
similar to 1
second but higher up (i.e. as you'd expect by extrapolation from
the
behaviour of the other curves).
My ADEV calculation is based on the
average frequency in each bin, the
varying size of the bin should be
insignificant as long as it is not
affecting the average value within the
bin. If the average frequency
shifts by delta_F in one bin time step and the
first bin is delta_T
short (as a fraction of one bin time step) then the
first frequency
will be delta_T*delta_F low and the second bin perhaps that
much high
but the key point is that it is the product of the two deltas so
it
won't materially affect the accuracy of the calculation. At least I
think that is correct.
Taking the worst possible case where the delta in
bin size always went
the wrong way so every term in the Alan Variance sum was
multiplied by
(1+2delta)^2 then the final Alan deviation might be (1 + 2
delta) too
big but as delta is of the order of 10E-8 or less this wouldn't
even
register on the graphs.
What I might try doing is programming your
approach into the code to
try and get at the raw data - I only need to try
88,90 and 92 as
possible counts - though to be sure I'll try mean frequency
+- 5 say
and then try and get the 50MHz clock values out as integers. What
I
might also do is then do a least squares fit (linear regression) to
get
the frequency over each bin and use the slope (this perhaps is
what the
counter does internally - I don't know).
I'd like to get to the bottom of
this if only to understand my
counter better.
James
-----Original Message-----
From: Dave Martindale
jpbridge@aol.com>; time-nuts < time-nuts@febo.com>
Sent: Wed, 18 Mar 2015
1:26 Subject: Re: [time-nuts] ADEV noise floor
vs counter gate
time
I believe I see the pattern. As you figured out, you wouldn't
expect a
single period to be a multiple of 20 ns; you expect the length of
(about) 90 periods to be an integer multiple of 50 ns, since that's
what the
counter actually measures. Further, the measuring time isn't
exactly 1
second, it is an integer number of periods of the input
frequency that makes
up at least 1 second. If the counting logic was
all hardware, you would
expect to capture either 90 or 91 cycles of
the input, depending on whether
the input frequency was slightly below
or above 90 Hz respectively.
I
built this table of your frequency data in Excel. Math is 64-bit
floating
point, equivalent to about 16 decimal digits, so plenty
accurate enough to
simulate this counter:
Reading Input Count TB Count Rounded Frequency
Interval 90.00006359 92
51111074.998 51111075 90.00006359 1.022221500
90.00007591 92
51111068.002 51111068 90.00007591 1.022221360 89.99999640
90
50000002.000 50000002 89.99999640 1.000000040 89.99998740 90
50000007.000 50000007 89.99998740 1.000000140 90.00006007 92
51111076.997
51111077 90.00006007 1.022221540 89.99996040 90
50000022.000 50000022
89.99996040 1.000000440 90.00008648 92
51111061.999 51111062 90.00008648
1.022221240 90.00008472 92
51111062.999 51111063 90.00008472 1.022221260
90.00011465 92
51111046.001 51111046 90.00011465 1.022220920 90.00014459
92
51111028.998 51111029 90.00014459 1.022220580
The first column is
your data. The second column is a guess about how
many input cycles were
captured. The third column is the number of
timebase cycles that have elapsed
since the previous reading, based on
the first two columns. I hand-tweaked
the numbers in the second column
until the number in the third column was
within 0.003 of an integer.
The fact that I was always able to do this tells
me that my guess is
probably correct, and the small residual (which is a few
parts in
1e-10) is due to the counter rounding the results to 10 digits.
The
4th column is the result of rounding the previous column to the
nearest integer. This is what I believe is the actual number of counts
the
counter saw. The 5th column is a fresh calculation of frequency,
based on the
integer number of input cycles in column 2 and the
integer number of timebase
cycles in column 4. When the result is
rounded to 10 digits, you can see it
matches the 10 digits that the
counter provided back in column 1.
Oddly, the counter never captured 91 input cycles. If the input
frequency was
a little higher than 90 Hz, it always measured at 92
cycles, even though 91
cycles was well more than 1 s since the
previous reading. I guess the
microprocessor running the counter only
checks periodically (e.g. every 20
ms) to see if the gate time has
elapsed, and then latches the counts on the
next active edge of the
input signal.
So, I claim that with this small
sample, at least, we recovered the
exact number of 20 ns periods between
samples, and the number of
integer input cycles as well. Also notice the 6th
column. This is the
actual sample interval, based on the number of elapsed
timebase
counts. Note that the sample period is not exactly 1 second,
nor
is it even close to a constant value, since some measurements are of
90 cycles while others are of 92 cycles. Does your ADEV calculation
algorithm
take into account the variable spacing of the input samples
in time? If it
assumes they are regularly spaced (i.e. every 90
cycles) it may get confused
by this variable-spacing data.
Now here is almost the same process applied
to your period data:
Reading Input Count TB Count Rounded Period Interval
0.01111107736 91
50555401.988 50555402 0.01111107736 1.011108040
0.01111110130 92
51111065.980 51111066 0.01111110130 1.022221320
0.01111110769 91
50555539.990 50555540 0.01111110769 1.011110800
0.01111110435 92
51111080.010 51111080 0.01111110435 1.022221600
0.01111110593 91
50555531.982 50555532 0.01111110593 1.011110640
0.01111110022 90
49999950.990 49999951 0.01111110022 0.999999020
0.01111114000 90
50000130.000 50000130 0.01111114000 1.000002600
0.01111110000 90
49999950.000 49999950 0.01111110000 0.999999000
0.01111110370 92
51111077.020 51111077 0.01111110370 1.022221540
Again,
column 2 was hand-adjusted for each row to keep the third
column close to an
integer. The residual errors here are larger, since
the maximum rounding
error of 0.5 in the last place is a larger change
relative to a 10-digit
value of 11111111 than it is to a value of
90000000, but all are still within
0.02 of being an integer. This
time, the counter grabbed measurements after
90, 91, or 92 cycles.
Again, after rounding the timebase count to an integer
and calculating
a 10-digit period for display, the result always matched what
the
counter output. Again, I think we know with high probability just how
many input and timebase cycles were counted for each measurement.
I
adjusted column 2 by eye, while looking at the results of column 3,
but that
process could be automated pretty easily (just not in Excel).
As I tried 90,
91, and 92 in sequence, there was always just one of
those which gave a small
residual error.
So I think your TF930 is making measurements and
accurately converting
them to frequency or period, with a +- 20 ns
uncertainty for each
measurement. Since it is a time-stamping counter, the
uncertainty in a
10 s or 100 s or 1000 s measurement time (assembled by
external
software) is still only 20 ns. That's great, but to actually get
that
accuracy over a long measurement time, you will need to determine and
add up the actual number of input counts and timebase counts. And you
will
have to understand that the counter does not make measurements at
constant or
near-constant intervals (e.g. every 90 cycles of input,
without exception).
It gives you measurements whenever it gets around
to measuring them.
Too bad there doesn't seem to be a way to get it to return the raw
observed
data (input cycle count, timebase cycle count) instead of
the frequency or
period derived from them. That would make it trivial
to string together a
bunch of 1s measurements into arbitrarily long
gate times.
Dave
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.martindale@gmail.com To: jpbridge jpbridge@aol.com;
Discussion of precise time and frequency measurement
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
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.
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.