> OK, now I've got it. I wasn't seeing the humps as being many slight > variations > around the 50ps points. Just had my mental scaling all wrong. > In other words, the TICC's resolution is "blurred" around the nominal value > rather > than being aligned to a precise increment.
John, Yes, that summary works. Also, TBD is if this accidental dithering might actually be a good thing. Re-read Bob's recent SDR comment. Note that counter resolution can be described by an rms value; a number computed from a calibrated noise floor test. Given a large set of samples, the rms noise is not due to the picket fence vs. camel hump effect, but by the Gaussian envelope that encloses those effects. To see what I mean about the Gaussian envelope that encloses those effects: http://leapsecond.com/pages/ticc/ticc-log5342-hist.gif I'm talking about the outer envelope; the green trace. Stable32 calculates a stdev of 45 ps. So you could say: in this test the TICC has the "equivalent of" 45 ps rms resolution. Some hand-waving required, but you get the idea. > I wonder if it would help to round (or truncate) the TICC output to 10 ps, > since the > last digit is noise anyway. Or go even further and round to the nearest 50 > ps. Yes, change from 1 ps to 10 ps. 1 ps was handy during development to make sure output formatting was not a limiting factor. But once all the math was sorted out that 1 ps digit was excessive. I would not go to 50 ps, however. At that point numerical / decimal quantization effects get in the mix. /tvb
_______________________________________________ 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.
