[time-nuts] Averaging effects

[Bruce Griffiths]

Magnus Danielson wrote:
> On 12/28/2010 01:37 AM, John Miles wrote:
>>
>>>> What GPIB data rate did you actually get for the 10 kHz trace?
>>>> When JohnM ran the same test on my 2070C it was closer to
>>>> 0.74 s instead of 1.0 s. I'm wondering if you found a way to
>>>> get your DTS pacing more accurately.
>>
>> Note that Magnus is running a very different test -- I was selecting 10K
>> averages with 10 MHz on both inputs and letting the counter's ~0.7-sec
>> processing overhead determine the tau0 interval, whereas he is feeding a
>> lower rate to the START channel so that the counter will average samples
>> taken at regular intervals within the tau0 period.
>
> Actually, I ended up feeding a 10 kHz signal into the ARM1 input and 
> then let the 5 MHz sines hit the Ch1 and Ch2 inputs.
>
> The 5 MHz + 7 dBm sine signal has a limited slew-rate, so this puts 
> some extra stress on the inputs compared to a slew-rate optimized 
> signal. However, all the involved counters gets the same signal.
>
I found that a +13dBm signal gives far lower trigger jitter in my 5370A, 
even the effect of attenuating the input by 3dB is very noticeable.
Either add a buffer amp with a gain of about 6dB or use a pair of 
2N3904s configured as an LTP diffamp with a gain of about 10 to  
increase the input slew rate.
>> There appears to be no way to get the counter to average a burst of
>> successive samples between arming intervals, which is really what you 
>> want.
>
> Instead of arming measurement blocks (which the HP5372A can) you arm 
> each individual measurement. For this to be really useful you need an 
> arming controller.
>
> The DTS 2070C can do 15000 samples per second. This is comparable to 
> the HP5372A, but in the high performance mode the HP5372A can do 
> measurements only 75 ns away while normal performance take 100 ns. The 
> time-saving done is about avoiding storing away the upper part of 
> counters into the 8192 long event memory.
>
>>>> JohnM -- is there a linear trend
>>>> removal option to TimeLab that works on the freq series just like
>>>> works on the time (phase) series?
>>>
>>> Should be there.
>>
>> Indirectly.  If you want to flatten the frequency trace, you can 
>> remove the
>> quadratic trend from the phase trace with ctrl-q.
>>
>>>>> A peculiar effect is that to make good readings for low-tau values I
>>>>> need to trim the oscillators to be very near each other. Otherwise
>>>>> there will be a polution of the lower taus compared to my selected
>>>>> good plots. This polution and the slope is insensitive to any drift
>>>>> rate compensation, so Hadamard analysis does not help.
>>
>> This is likely caused by phase wrapping, which is incompatible with
>> averaging.  The counter can't average readings like 96 97 98 99 ... 
>> 01 02 ns
>> and come out with anything meaningful.  You'll have to use sample 
>> size=1 if
>> your sources are likely to phase-wrap during the measurement.
>
> Hmm. True. My reasoning to trim the oscillators close was to avoid 
> phase wrapping.
>
> If I only could get the TS-105A to output data on the serial port as I 
> would expect it to do, it would be nice to be able to use that one as 
> a TimeLab source too. :)
>
> Cheers,
> Magnus
>
Bruce