[time-nuts] Influence of Cycle Wraps on TInt-Measurements with53132A

[Hans Holzach]

hi tom,

thank you very much! that is quite interesting. i am happy to learn that 
there is nothing wrong with *my* counter! converting the non-linearity 
effect into a correction table is beyond my abilities, but simply 
knowing that this effect is inherent to the 53132a counter helps a lot.

indeed, my plots look similar to yours. after only three hours of 
warming up i measured the TI of an HP 10811 against the 1 pps output of 
my fury. the 10 mhz output of the fury was used as the external timebase 
of the counter.

the raw data of one hour measuring. average period of cycle wraps is 93.3 s:
https://farm8.staticflickr.com/7314/14076566541_79094d6850_o.png

steps and drift removed (detail):
https://farm8.staticflickr.com/7348/14079753105_f8ac97766d_o.png

autocorrelated. the average distance between two peaks is 94.6 s:
https://farm6.staticflickr.com/5518/14056659576_703b446cc2_o.png

as expected, the pattern is also visible in the ADEV plot (overlapping, 
all tau):
https://farm8.staticflickr.com/7382/14079754735_62d70d1480_o.png

and even better a few hours later (shorter period of cycle wraps):
https://farm8.staticflickr.com/7042/14079754345_b4b6f9afb8_o.png

but almost invisible in the "standard" ADEV plot:
https://farm6.staticflickr.com/5474/13893141107_5aa39eb199_o.png

hans






Hi Hans,

See if your plots look like approximately like these:
http://leapsecond.com/pages/53132/2324.gif
http://leapsecond.com/pages/53132/4099.gif

I did this as part of a week-long 51132A TIC resolution and linearity test.

I believe this is evidence of interpolator non-linearity within the 
53132 counter. It happens on each 53132 counter I tested although each 
has its own unique pattern. See, for example:
http://leapsecond.com/pages/53132/all7-phase.gif
http://leapsecond.com/pages/53132/all7-tdev.gif

There may be input signal conditioning, cross-talk, and DUT pulling 
effects too. I haven't sorted it all out yet.

Note the counters all meet spec. But under the spec is this very 
interesting world of interpolator non-linearity. It is exposed any time 
you very slowly ramp through the interpolator range, or if you apply 
pure noise and look at the distribution of all the bin's (histogram). So 
these subtle, periodic effects are expected in any interpolator design, 
but it is cool to actually see and measure it.

If they are consistent for a particular counter you can convert these 
"calibration" measurements into a correction table and thus improve the 
resolution of all subsequent time interval readings. The SR620 does this 
with an EEPROM table.

In my test I compared two 5 MHz oscillators that were about 5e-11 apart 
in frequency. That way it took about 4000 seconds to complete one 200 ns 
cycle wrap. Collect data for a day and you have a nice series of 
waveforms. I see both 100 ns periods (due to the 10 MHz 53132 clock) and 
200 ns periods (due to the 5 MHz DUT).

Avoiding cycle wraps with dividers doesn't really solve the problem. 
Also, it's not always practical to continuously sit in a small fraction 
of the full interpolator cycle. One solution is applying interpolator 
calibration, as mentioned above. But the solution I use is exactly 
opposite of your intuition -- for best resolution I welcome as many 
cycle wraps as possible. This is especially effective if you compute 
phase slope (frequency offset) with a least squares fit, instead of 
point-to-point.

/tvb