[time-nuts] ADEV noise floor vs counter gate time

jpbridge at aol.com jpbridge at aol.com
Mon Mar 23 21:12:27 UTC 2015


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 at radio.sent.com>
To: time-nuts <time-nuts at 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 at radio.sent.com>
> To: time-nuts <time-nuts at 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 at gmail.com> To: jpbridge
> <jpbridge at aol.com>
> > CC:
Discussion of precise time and frequency
> measurement
> >    
<time-nuts at 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 at 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 at gmail.com>
> >
>
>
> > To: jpbridge <
> jpbridge at aol.com>; time-nuts < time-nuts at 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 at 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 at gmail.com> To: jpbridge <jpbridge at aol.com>;
> >
> Discussion
of precise time and frequency measurement
> > <time-nuts at 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 at 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 at febo.com To unsubscribe, go to
> >
>
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the
> >
>
instructions there.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> >
> >
> >
> >
> >
> >
> >
> >
>
_________________________________________________
> > time-nuts mailing list
--
> time-nuts at febo.com To unsubscribe, go to
> >
>
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the
> >
>
instructions
> there.
> 
> _______________________________________________
>
time-nuts mailing
> list -- time-nuts at febo.com
> To unsubscribe, go to
>
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the
>
instructions there.
> 
>  
>
_______________________________________________
> time-nuts mailing list --
time-nuts at febo.com
> To unsubscribe, go to
>
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the
instructions there.
_______________________________________________
time-nuts
mailing list -- time-nuts at febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the
instructions there.

 



More information about the Time-nuts_lists.febo.com mailing list