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

Tue Mar 17 09:57:35 UTC 2015

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.    