[time-nuts] Short term 10MHz source

[Magnus Danielson]

Hi,

On 1/9/19 3:05 AM, Tom Van Baak wrote:
>> Wouldn't any counter that has 50 picosecond resolution look the same? 
> 
> Nope. If you had a 20 GHz timebase you'd have 50 ps resolution and all your readings would be exact multiples of 50 ps. It would be very clean and simple. Readings of 25 ps or 49 ps or any other non-multiple of 50 ps would never occur. The histogram would be composed of thin vertical lines -- each exactly 50 ps apart.
> 
>> Its data output is quantized by its resolution.  For example, the 5334A 
>> with 2ns resolution will always show bins no less than 2ns apart.
> 
> Right, the 5335A has a 500 MHz clock and so all readings are multiples of 2 ns. The counter cannot output a reading that ends in 1 ns or .123 ns. The histogram would be composed of thin vertical lines -- each exactly 2 ns apart.

HP5335A is an interpolating counter. It uses 10 MHz as coarse counting
clock and then interpolate with x200 factor using a time-stretcher
circuit that then counts the error-pulse in 10 MHz clock using TTL. The
time-stretcher has no calibration of the analog, but only uses
calibration pulses to numerically compensate it's slope-offset.

The Philips/Fluke counter PM6654C has a 500 MHz coarse counter and no
interpolator, and indeed achieves 2 ns quantization steps.

The HP5371A, 5372A and 5373A also uses 500 MHz coarse counter, but then
do a x10 improved time-resolution to achieve 200 ps single-shot
resolution. The delay-line approach has a merrit in that it can handle a
very high sample rate, so the 100 ns or 75 ns time between samples gives
the maximum sample rate of 10 MS/s or 13.3 MS/s, but the time-resolution
is suffering. It is however recommended for the interested to dig into
the programmers manual, since it gives quite a bit of insight as to how
all measurements is done and calculated.

The Pendulum/Fluke CNT-80/81/90/91 all use a 100 MHz coarse counter and
then using error-pulse interpolators. The CNT-90/91 uses essentially the
same mechanism, but CNT-91 has improved performance in several aspects
in order to reach the 50 ps resolution.

> Now it gets a bit more complicated with an interpolating counter, like a SR620 or hp5370. In this case there are fractions involved, but they are fixed fractions.
> 
> The numerology [1] for SR620 quantization is something like 90 MHz, 111.11 ns, 1/512, for a final result of 21.701... ps.

The coarse counter of SR620 is 90 MHz, and then error-pulse
interpolation from that. The 90 MHz is synthesized using two
frequency trippler circuits after each other as I recall it.

> The numerology [2] for the hp5370 is something like 200 MHz, 5 ns, 257/256, 5.01953125 ns, 1/256, for a final result of 19.607... ps

The coarse counter of HP5370 is indeed 200 MHz, then using a tuned
coax-delay oscillator of 255/256*200 MHz as interpolator creating a
time-stretched approach using a coinsidense-detection. Marvelous
solution for it's time.

> There is determinism or fine quantization in the readings because even though this ~20 ps value is not a nice round number, it is a fixed number.

Yes, for the simplest linear quantization model which suffice here.

> /// Consequently, for any of the 4 counters mentioned above, if you take a noise floor dataset and sort | uniq -c you will see a small number of large peaks. Like a picket fence. A picket fence inside a Gaussian envelope.

Which is to be expected of the noise we have.

> What we see in the TICC is something quite different. It's not a problem, just very different. Why is that?

Well, you could run into an issue if the TIC-chip does recalibrations,
and jumps around over time and temperature. This may or may not be what
you want, depending on what you are doing.

>> You've mentioned this before, and I'm having trouble getting my head 
>> around it.  I may have this all wrong, but isn't the quantization simply 
>> the resolution of the device?  Your histogram shows humps about 50 
>> picoseconds apart, but that's the resolution of the counter.
> 
> Here's what's happening. Unlike the counters mentioned above there is no fixed cycle or fraction in the TICC. The ring counter is free-running and its rate can vary from unit to unit, from temperature to temperature, from reading to reading. That's why the all-important post-calibration step is performed for every reading. This results in readings that are not fixed fractions of 1 ns or 20 ps or 64 ps or 62.5 ps or any other deterministic value. So each vertical "line" of the histogram is no longer a thin line, it is spread out quite a lot.

Ah, yes, that explains it naturally. I have not looked very closely on
that chip.

Cheers,
Magnus

> /// If you take a TICC noise floor dataset and sort | uniq -c you will also see small number of large peaks, but the peaks are fat camel humps instead of thin picket fences. [3] It has a completely different look. Gaussian camel humps within a Gaussian envelope.
> 
> /tvb
> 
> [1] SR620 math: https://www.thinksrs.com/downloads/pdfs/manuals/SR620m.pdf
> [2] hp5370 math: http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1978-08.pdf
> [3] http://leapsecond.com/pages/ticc/