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

[Bill Byrom]

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.