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
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
