[time-nuts] Notes on tight-PLL performance versus TSC 5120A

[Bruce Griffiths]

John Miles wrote:
>>> The integration secret  (which is no secret to anyone but
>>>        
>> Bruce)  is to analog filter, Oversample, then average the
>> Frequency data at a rate much faster than the tau0 data rate.
>>      
>>>        
>> Which again is misleading as you specify neither the averaging method
>> nor the analog filter.
>>      
> I can't speak for the analog side as I never saw a schematic of the PLL, but
> it may be worthwhile to point out that the averaging code in question is in
> SOURCE_DI154_proc() in ti.cpp, which is installed with
> http://www.ke5fx.com/gpib/setup.exe .  This is my code, not Warren's.  It
> does a simple boxcar average on phase-difference data, the same as my TSC
> 5120 acquisition routine does.  Previous tests indicated that simple
> averaging yields a good match to most ADEV graphs on TSC's LCD display, so I
> used it for the PLL DAQ code as well.
>
> I also tried a Kaiser-synthesized FIR kernel for decimating the incoming TSC
> data, but found that its conformance against the TSC's display was worse
> than what I saw with the simple average.  More work needs to be done here.
>
>    
>> When will you understand that phase differences and differences of
>> average frequency (unit weight to frequency measures over the sampling
>> interval zero weight outside) are equivalent.
>>      
> One subtlety is the question of whether to average (or otherwise filter) the
> DAQ voltage readings immediately after they're acquired and linearly scaled
> to frequency-difference values, versus after conversion of the
> frequency-difference values to phase differences.  I found that the best
> agreement with the TSC plots was obtained by doing the latter:
>
> 	val = (read and scale the DAQ voltage)
>
> 	// val is now a frequency difference
> 	// averaging val here yields somewhat higher
> 	// sigma(tau) values in the first few bins
> 	// after tau0
>
> 	val = last_phase + (val / DI154_RATE_HZ);
> 	last_phase = val;
>
>    
This appears to use a rectangular approximation to the required integral.
A trapezoidal or even Simpson's rule integration technique should be 
more accurate for a given sample rate.
One could even try a higher order polynomial fit to the sample points, 
however this isnt the optimum technique to use.

If one uses WKS interpolation to reconstruct the continuous frequency vs 
time function and integrates the result for a finite time interval 
(Tau0) then one ends up with a digital filter with infinite number of terms.
Since an infinite number of samples is required to do this using a 
suitable window function is probably advisable.

The paper (below) illustrates how AVAR etc can be calculated from the 
sampled frequency difference data using DFT techniques:

http://hal.archives-ouvertes.fr/docs/00/37/63/05/PDF/alaa_p1_v4a.pdf

> 	// val is now a phase difference
> 	// averaging val here matches the TSC better
>
> The difference is not huge but it's readily noticeable.
>
> This is subtly disturbing because the RC filter before the DAQ *does*
> integrate the frequency-difference data directly.  If it's correct to
> band-limit the frequency-to-voltage data in the last analog stage of the
> pipeline, it should be correct to do it in the first digital stage, I'd
> think.
>
>    
The RC filter doesnt accurately integrate the frequency difference over 
time interval Tau0.
> Further complicating matters is the question of whether the TSC 5120A's
> filtering process is really all that 'correct,' itself.  When they
> downsample their own data by a large fraction, e.g. when you select tau0=100
> msec / NEQ BW = 5 Hz, there is often a slight droop near tau0 that does not
> correspond to anything visible at higher rates.  To some extent we may be
> attempting to match someone else's bug.
>    
This is the result of the choice of the low pass filter bandwidth made 
by the designers.
The filter bandwidth increases as Tau0 decreases.
The traditional analyses of the dependence of AVAR on bandwidth of this 
filter assume a brickwall filter.

> At any rate I've run out of time/inclination to pursue it, at least for now.
> The SOURCE_DI154_proc() routine in TI.CPP is open for inspection and
> modification by any interested parties, lines 6753-7045 in the current
> build. :)  Warren has his hardware back now, and would presumably be able to
> try any modifications.
>
> -- john, KE5FX
>
>
> _______________________________________________
> 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.
>
>    
Bruce