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.martind...@gmail.com>
To: jpbridge <jpbri...@aol.com>; time-nuts <time-nuts@febo.com>
Sent: Wed, 18 Mar 2015 1:26
Subject: Re: [time-nuts] ADEV noise floor vs counter gate time


 I believe I see the pattern.  As you figured out, you wouldn't expect a single 
period to be a multiple of 20 ns; you expect the length of (about) 90 periods 
to be an integer multiple of 50 ns, since that's what the counter actually 
measures.  Further, the measuring time isn't exactly 1 second, it is an integer 
number of periods of the input frequency that makes up at least 1 second.  If 
the counting logic was all hardware, you would expect to capture either 90 or 
91 cycles of the input, depending on whether the input frequency was slightly 
below or above 90 Hz respectively. 
  
 I built this table of your frequency data in Excel.  Math is 64-bit floating 
point, equivalent to about 16 decimal digits, so plenty accurate enough to 
simulate this counter: 
  
  Reading    Input Count TB Count      Rounded      Frequency       Interval 
  90.00006359    92    51111074.998    51111075    90.00006359    1.022221500 
  90.00007591    92    51111068.002    51111068    90.00007591    1.022221360 
  89.99999640    90    50000002.000    50000002    89.99999640    1.000000040 
  89.99998740    90    50000007.000    50000007    89.99998740    1.000000140 
  90.00006007    92    51111076.997    51111077    90.00006007    1.022221540 
  89.99996040    90    50000022.000    50000022    89.99996040    1.000000440 
  90.00008648    92    51111061.999    51111062    90.00008648    1.022221240 
  90.00008472    92    51111062.999    51111063    90.00008472    1.022221260 
  90.00011465    92    51111046.001    51111046    90.00011465    1.022220920 
  90.00014459    92    51111028.998    51111029    90.00014459    1.022220580 
  
 The first column is your data.  The second column is a guess about how many 
input cycles were captured.  The third column is the number of timebase cycles 
that have elapsed since the previous reading, based on the first two columns.  
I hand-tweaked the numbers in the second column until the number in the third 
column was within 0.003 of an integer.  The fact that I was always able to do 
this tells me that my guess is probably correct, and the small residual (which 
is a few parts in 1e-10) is due to the counter rounding the results to 10 
digits.  The 4th column is the result of rounding the previous column to the 
nearest integer.  This is what I believe is the actual number of counts the 
counter saw.  The 5th column is a fresh calculation of frequency, based on the 
integer number of input cycles in column 2 and the integer number of timebase 
cycles in column 4.  When the result is rounded to 10 digits, you can see it 
matches the 10 digits that the counter provided back in col
 umn 1. 
  
 Oddly, the counter never captured 91 input cycles.  If the input frequency was 
a little higher than 90 Hz, it always measured at 92 cycles, even though 91 
cycles was well more than 1 s since the previous reading.  I guess the 
microprocessor running the counter only checks periodically (e.g. every 20 ms) 
to see if the gate time has elapsed, and then latches the counts on the next 
active edge of the input signal. 
  
 So, I claim that with this small sample, at least, we recovered the exact 
number of 20 ns periods between samples, and the number of integer input cycles 
as well.  Also notice the 6th column.  This is the actual sample interval, 
based on the number of elapsed timebase counts.  Note that the sample period is 
*not* exactly 1 second, nor is it even close to a constant value, since some 
measurements are of 90 cycles while others are of 92 cycles.  Does your ADEV 
calculation algorithm take into account the variable spacing of the input 
samples in time?  If it assumes they are regularly spaced (i.e. every 90 
cycles) it may get confused by this variable-spacing data. 
  
 Now here is almost the same process applied to your period data: 
  
  Reading     Input Count  TB Count      Rounded         Period         
Interval 
  0.01111107736    91    50555401.988    50555402    0.01111107736    
1.011108040 
  0.01111110130    92    51111065.980    51111066    0.01111110130    
1.022221320 
  0.01111110769    91    50555539.990    50555540    0.01111110769    
1.011110800 
  0.01111110435    92    51111080.010    51111080    0.01111110435    
1.022221600 
  0.01111110593    91    50555531.982    50555532    0.01111110593    
1.011110640 
  0.01111110022    90    49999950.990    49999951    0.01111110022    
0.999999020 
  0.01111114000    90    50000130.000    50000130    0.01111114000    
1.000002600 
  0.01111110000    90    49999950.000    49999950    0.01111110000    
0.999999000 
  0.01111110370    92    51111077.020    51111077    0.01111110370    
1.022221540 
 
 Again, column 2 was hand-adjusted for each row to keep the third column close 
to an integer.  The residual errors here are larger, since the maximum rounding 
error of 0.5 in the last place is a larger change relative to a 10-digit value 
of 11111111 than it is to a value of 90000000, but all are still within 0.02 of 
being an integer.  This time, the counter grabbed measurements after 90, 91, or 
92 cycles.  Again, after rounding the timebase count to an integer and 
calculating a 10-digit period for display, the result always matched what the 
counter output.  Again, I think we know with high probability just how many 
input and timebase cycles were counted for each measurement. 
  
 I adjusted column 2 by eye, while looking at the results of column 3, but that 
process could be automated pretty easily (just not in Excel).  As I tried 90, 
91, and 92 in sequence, there was always just one of those which gave a small 
residual error. 
  
 So I think your TF930 is making measurements and accurately converting them to 
frequency or period, with a +- 20 ns uncertainty for each measurement.  Since 
it is a time-stamping counter, the uncertainty in a 10 s or 100 s or 1000 s 
measurement time (assembled by external software) is still only 20 ns.  That's 
great, but to actually get that accuracy over a long measurement time, you will 
need to determine and add up the actual number of input counts and timebase 
counts.  And you will have to understand that the counter does not make 
measurements at constant or near-constant intervals (e.g. every 90 cycles of 
input, without exception).  It gives you measurements whenever it gets around 
to measuring them. 
  
 Too bad there doesn't seem to be a way to get it to return the raw observed 
data (input cycle count, timebase cycle count) instead of the frequency or 
period derived from them.  That would make it trivial to string together a 
bunch of 1s measurements into arbitrarily long gate times. 
  
 - Dave 
  
  
On 17/03/2015 05:57,   jpbri...@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.martind...@gmail.com>    
 To: jpbridge     <jpbri...@aol.com>; Discussion of precise time and frequency 
measurement     <time-nuts@febo.com>    
 Sent: Tue, 17 Mar 2015 0:27    
 Subject: Re: [time-nuts] ADEV noise floor vs counter gate time    
     
     
      
       
 How is the counter configured?  Are you reading period or frequency?  Are you 
in "E?" (Every Result) mode, or "C?" (Continuous Result) mode?  The former 
should give you continuous but independent measurements, while the latter gives 
heavily overlapped measurements.  (For example, with a 100 second gate time, 
you get one E output every 100 seconds, which covers a different 100-second 
period than the previous measurement.  In C mode, you get one output every 2 
seconds, each of which is an estimate from 100 seconds of measurement, but 98 
seconds of that data was also part of the previous output and only 2 seconds of 
new data is included).        
       
       
        
       
 What does the data returned by the counter actually look like?  The manual 
implies that you always get 10 digits worth of result (not including the 
exponent) regardless of gate time, but are the values rounded for display in 7, 
8, or 9 digits at the shorter gate times, or are they a full 10 digits always?  
Given any particular value of frequency or period you get, you should be able 
to reverse-calculate the number of whole cycles of the input signal that the 
counter used as a gate time, and the number of cycles of 50 MHz timebase that 
were counted in that period.  Since the counter doesn't have interpolators, 
both of these values should be integers, and so the possible output values are 
a small subset of all possible 10-digit values for the shorter gate times.      
 
        
       
       
 For example, if the difference frequency is exactly 90 Hz, the period between 
two "1 second" measurements will be exactly 1 second, and the counter will 
record 90 cycles of input and 5e7 cycles of timebase, exactly.  In frequency 
mode, the output should be 90.0 Hz exactly, and in period mode the output 
should be 11.11111111 ms.  Now suppose that the difference frequency is just a 
hair slow, enough that 90 cycles of input spans 50,000,001 counts of the 
timebase.  The reported frequency should be 89.99999820 Hz and the reported 
period should be 11.11111133 ms.  With a 1 s gate time, no values between those 
are possible unless the values are being rounded (or there is an error in the 
calculation, which is always possible).  Looked at another way, the smallest 
possible change in the reported period is one timebase clock (20 ns) divided by 
the number of input cycles in one gate time (90 for 1 s).       
       
        
       
       
 If the counter is rounding, you may be able to unambiguously figure out what 
the actual inputs (cycles of input and cycles of timebase) to the calculation 
were, and use that instead of the rounded value in your calculations.  Rounding 
may round up or down, but if the two oscillators are stable enough the 
direction can be predominantly "up" or "down" for long periods of time, adding 
a bias to the actual frequency or period you're measuring.  (I don't know what 
effect this bias would have on ADEV).       
       
        
       
       
 - Dave       
      
      
       
       
 On Mon, Mar 16, 2015 at 10:15 AM, James via time-nuts        
<time-nuts@febo.com> wrote:        
        
 Hi All,         
         
 I'm in the process of getting a better counter, but at present I'm using my 
TTi TF930 counter.         
         
 For those who don't know it, it is a reciprocal counter which should be 
continuous, it counts periods in terms of its internal 50MHz clock which I've 
locked to an external 10MHz reference.         
         
 There are 4 gate times available, 0.3 secs, 1 sec, 10 secs and 100 secs.       
  
         
 These correspond to 7, 8, 9 and 10 digits.         
         
 I've been experimenting with using a single mixer (mini circuits ZAD+) along 
with a 1MHz low pass filter and appropriate attenuators to measure Alan 
Deviation (using my own software).         
         
 My set up is a 10MHz reference source (MV89A which I've approximately set 
using a 10kHz GPS signal).         
         
 The reference is used as the external reference for an Agilent 33522A 
arbitrary waveform generator.         
         
 The 33522A generates an 9.999910 MHz (10MHz - 90Hz) sine wave at 300mVpp to 
the mixer and the mixer is also fed by the 10MHz reference output of the 33522A 
via an attenuator to get it to roughly the same level.         
         
 The second output of the 33522A generates a 10MHz square wave as a reference 
for the counter (the counter requires quite a high reference signal and the 
reference out of the 33522A is too low a voltage to be used directly).         
         
 I initially ran this with a gate of 1 second and the LOG10(ADEV) curve drops 
linearly vs LOG10(tau) but then curves back up again. (I tried many variants 
such as using period rather than frequency and so on.)         
         
 But when I set the gate time to 10 seconds or 100 seconds then I get both 
lower curves and ones that no longer curve upwards.         
         
 The attached pdf shows the three curves on the same graph.         
         
 What puzzles me is that the counter at longer gates is only averaging to get 
more digits so the difference must come down to quantization in terms of the 
number of digits that are passed to the computer over the USB/RS232 link.       
  
         
 I find it rather puzzling.         
         
 James
 
 
 
 
 
          
 _______________________________________________         
 time-nuts mailing list --         time-nuts@febo.com         
 To unsubscribe, go to         
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts         
 and follow the instructions there.         
        
       
       
      
     
    
   
  
 

_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Reply via email to