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

Ed Palmer ed_palmer at sasktel.net
Thu May 1 09:50:01 EDT 2014


What happens if you use Timelab to analyze the same data instead of Plotter?

I find that, depending on the dataset, one program or the other will 
sometimes have trouble removing the steps completely.  They leave small 
steps behind.  It isn't related to the counter used, but seems to be 
related to the number of data points per cycle and the unwrapping 
algorithm used by the program.

Ed

On 5/1/2014 4:05 AM, Hans Holzach wrote:
> 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
>
>
>




More information about the time-nuts mailing list