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