[time-nuts] Short term 10MHz source

[Tom Van Baak]

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ticc-log5342-hist.gif
Type: image/gif
Size: 25761 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20190108/e4325ee5/attachment.gif>