ADEV noise floor vs counter gate time
Hi Bill,
I'm travelling at the moment, but I had another go just now and it has stopped wiping my details when I press the save button so hopefully that means it is fixed.
I must just have been unlucky and picked a glitchy day (this was at the end of last week).
Though, now that I've downloaded NI-VISA and got that working I probably don't need to download tek-VISA.
Best Regards,
James
-----Original Message-----
From: Bill Byrom time@radio.sent.com
To: time-nuts time-nuts@febo.com
Sent: Sun, 22 Mar 2015 20:28
Subject: Re: [time-nuts] ADEV noise floor vs counter gate time
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:
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
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-----
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
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
--
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the
instructions there.
time-nuts mailing list
--
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
and follow the
instructions there.
time-nuts mailing list --
To unsubscribe, go to
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.