[time-nuts] Performance verification for time counters

Poul-Henning Kamp phk at phk.freebsd.dk
Wed Nov 29 16:51:54 EST 2017


--------
In message <5602C647-1251-4D78-B82E-798BFCD8BF29 at leobodnar.com>, Leo Bodnar writes:

>Now, what would be recognised procedure for sweeping external input pulse delay over few hundred ns in a controlled, measurable and repeatable way? 

When I did this (20 years ago :-), I used a signal generator.

Lock it to the same frequency as your reference signal, but set it
for pure sine output slightly offset in frequency (10.000010/9.999990
MHz), so that your know your TI sweeps the entire window.

Until you get a god "box" distribution, there is no need to do
anything more complicated.

Be aware that flaws in the box shape can come from either the sig-gen
or your counter:  This is basically a "vernier" style of measurement,
and very few sources hold up to that kind of scrutiny.

Next run as high a sampling rate as your device supports and look
for samples which "leap-frog" each other, in theory you should have
none.

Next, siggen=ref frequency, but adjust the phase (relative to
the common clock reference) and the amplitude, and see if the
zero-crossings behave the way you expect.  In particular
check if the noise (= stddev) is even throughout the window.

Finally you can use PM/AM/FM modulation with different shapes
(triangle, square, sine etc) and idicies of modulation, in
each case you can calculate what distribution to expect.

While it is tempting and probably easiest to use a DDS style
generator, I recommend a synthesized one instead, to avoid
trouble with numeric spurs.

The HP3336 with its outstanding level-control is a much
overlooked bargain for this kind of stuff.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


More information about the time-nuts mailing list