In a message dated 4/8/2007 16:49:00 Pacific Daylight Time,
bruce.griffiths@xtra.co.nz writes:

Since  Wavecrest, 53132A etc have no specifications for the effect of the
input  circuit noise with a finite slew rate input, the only way to make
a more  precise comparison is to actually make some measurements. The
integral and  differential nonlinearity of the Wavecrest do not seem to
be specified,  nor are the channel delay mismatches. Are thes internally
calibrated?

Hi Bruce,

yes, the unit calibrates out the inputs using two reference signals  that are
swapped during the measurement. All that is needed are two SMA cables,  and
two SMA grounding plugs. Best of all, the internal calibration only consists
of one screw for the Vectron 100MHz OCXO, and the power supply voltage
adjustments. All other calibrations are done in software automatically.

I did see some jitter differences when feeding square waves versus sine
waves into the unit. This was more pronounced on the newer SIA3000 units. I was
doing the tests with our Jackson-Labs Fury reference GPSDO which has both Sine
and CMOS outputs, the CMOS outputs having slightly less jitter.

Not so, it's better: when measuring the internal 100MHz reference (there is
a Sine-Wave output with -4dBm 100MHz in the back) then the RMS jitter  is
about 2.7ps, this doesen't change much from 5 to 1000 sample averages. This  is
about the number I get from other good 10MHz OCXO sources as well. It's in  line
with what the Wavecrest reps said the timebase typically can do.

Once I get the Windows software running, I was planning to split a signal
using a power splitter, delay one side of the signal with a longer cable, and
feed both inputs into the A to B measurement. That should give a
source-independent value for all internal noise sources.

For now, here is a hint of the precision that is achievable:

In cable-length measurement mode, the unit uses its' two reference outputs
to generate two 200MHz sine waves. these are feed via two SMA cables to the two
inputs, and the unit calibrates itself to 0.0ps cable length.

Then, one can insert an additional cable into one of the two feeds to
measure the electrical cable length of this added segment.

The LCD display updates the measurement about 20-30 times a second (guess)
and the values do not jitter more than about +-300 femtoseconds over a period
of  several seconds. I would guess they use internal averaging to get to the
number  the LCD is displaying since the resolution is "only" 800 femtoseconds.

Now one can slowly unscrew one of the SMA connectors effectively enlarging
one of the cable lengths by very small amounts.

By doing this, you can actually observe the measured value increase very
slowly, one can even observe the sub 1ps values increase! Doing this, you can
see about 3ps of added delay for every single turn of the SMA connector ground
nut.

Not sure many other instruments can do that.

Will report raw capture data once I have the software running.

bye,
Said

************************************** See what's free at http://www.aol.com.

From: SAIDJACK@aol.com
Subject: Re: [time-nuts] Looking for Wavecrest Visi
Date: Sun, 8 Apr 2007 21:12:52 EDT
Message-ID: cb8.f427e8a.334aed14@aol.com

Said,

This is to be expected as the slew-rate of the "CMOS" signal is higher than the
sine of the same frequency.

What you measure when you measure the instruments timebase is a filtered
variant of its phase-response. You get a high-pass filter effect due to the
time-delay difference, but it also contains a bunch of nulls in the response
which is to be expected. Thus, the noise you measure is being reduced. Also, as
for systematic errors you measure the noise-out average of a certain point of
the interpolator, not the full range.

No. It is better than feeding the internal timebase to a single input.

Cool!

For that measurement, yes.

Handy number to have in memory! Thanks! :-)

You should be able to get similar result on a network analyzer.

Keep us posted.

Don't you have the programmers manual so your can set up the GPIB yourself?
You should be able to do that in modern OSes.

Cheers,
Magnus

SAIDJACK@aol.com wrote:

Said

This is probably due to the fact that the CMOS gates have lower
bandwidth and input noise than the Wavecrest input comparators.
For a given fixed signal frequency there is, particularly for lower
frequencies, a more optimum signal conditioning circuit than a simple
comparator that will minimise the output timing jitter of a logic level
square wave. However such circuits require very good temperature control
and are optimised for the known input frequency.

We are not comparing the same thing here, the amplitude and slew rate of
the input signal are important.
With a 100MHz signal of amplitude >= +7dBm. one would expect the
internal noise (~ 3ps rms) to dominate.
The observed noise with a 10MHz input signal will depend on the signal
amplitude and the (unspecified) input comparator noise.
I assumed around 300uV rms as a reasonable guess for the (unspecified)
input noise bandwidth (> 1GHz ??)
It could be somewhat lower. Using a lower amplitude, known low slew rate
signal should make this dominant and would be useful in getting some
idea of the actual effective value of this noise. You could try
inserting an attenuator between the 10MHz OCXO output and the Wavecrest
to obtain a lower slew rate input signal so that the this noise may be
determined.
Once the effective input comparator noise is known it is then possible
to make a rational choice between counters particularly for lower input
frequency low slew rate signals.

Only if the delay isn't too long for the particular source's noise
characteristics.
Otherwise you've just built a delay line discriminator.

Unlikely to update the actual display at that rate (20-30 times per
second - 20-30 times a minute is more likely.) as it would become
unreadable, particularly the least significant digits. If the pp display
jitter is about 600fs and the input pp jitter is about 25ps then about
2000 measurements need to be averaged to achieve this.

There's no particular reason that they cannot if they have adequate
resolution and stability and a sufficient number of measurements are
averaged.
This should be possible even with an HP5370A/B albeit with a slower
response time.

Bruce

Dr Bruce Griffiths wrote:

Depending on how much the environment affects the jitter, you could
chain a bunch of them together and analyze the resulting distribution.
You'd only see the tails of the distribution when the sum of the jitter
exceeded your measurement threshold, but if you were willing to make
some indepdence and gaussian assumptions, the analysis should be possible.

(The sum of two gaussians has variance equal to the sum of the variance
of the input gaussians, assuming the variables are independent.  The
thing I'd worry about is that the jitter you end up measuring is more
affected by the environment - temp, EMI, etc.  You could correct for
that by then measuring the variance of 2x as many chained elements;  if
the variance was >2x, you'd know you have correlation.)

But really, I'd wager there are some very nice, known statistical
techniques for doing this.  I'm just making something up that seems
rational.

-Dave

David Andersen wrote:

Dave

Yes, more intended for a challenge to see how long a chain is required
for a particular time interval counter to be able to achieve a
repeatability of say 10% in measuring the jitter. Also useful for design
purposes when one wants to have some idea of  the limiting jitter of a
gate. Enclosing the test circuit in a massive aluminium block should
help with the thermal stability and with maintaining a low (external)
EMI environment, if one wishes to measure the low frequency jitter
components.

If the jitter of your time interval counter is reasonably stable one can
measure rms jitter of around the same value with good accuracy (provided
the counter resolution is adequate). For counters limited by their
hardware resolution, measuring rms jitter down to about the resolution
limit should be feasible.

Thus for

1. A 53132A jitter down to 150ps rms or so (equivalent to a chain of
   4700 HCT gates)
2. A 5370A/B jitter down to 35ps rms or so (equivalent to a chain of 253
   HCT gates)
3. A Wavecrest device down to 3ps rms or so (equivalent to a chain of 2
   HCT gates)

Thus for making this sort of measurement with HCT gates it would appear
that the Wavecrest us the only timer counter that is practical to use
unless one has a lot of PCB real estate and devices available.

However if one were to build a ring oscillator with such a inverting
gate chain then it may just be easier to measure its phase noise floor.

This is a somewhat indirect technique, using a high speed ADC (with the
DUT switched into and out of the sampling clock path ) converting a low
noise 100MHz input signal seems simpler.

Bruce

On Monday 09 April 2007 01:16, Dr Bruce Griffiths wrote:

Then don't use them.

Set up a current source to charge a cap, sample&hold, and bow correction, then measure
the delta between two points.  Somethings are still better to be done
in the analog domain.  I'll put a circuit on my web site when I get back in town
later in the week.

Dr Bruce Griffiths said the following on 04/08/2007 10:01 PM:

I routinely measure coax cable lengths to 200 femtosecond resolution
with my 5370B (though to be practical I normally round to at least 10
and sometimes 100 picoseconds, to take into account possible measurement
errors like adapter lengths and cable tempco).

I recently built 6 nominally 10 foot GPS antenna cables out of LMR-400.
They all had N connectors on one end, but the opposite ends were two
each of N, BNC, and TNC, which made measurement interesting because the
needed tweenie configurations and lengths were different.

After doing the best I could to normalize out the adapters, I measured
the six cables and the spread from longest to shortest was 61
picoseconds (nominal length was 12.55 nanoseconds); I suspect that as
much as 40 ps of that was due to uncalibrated tweenie lengths because
the three pairs of cables with identical connectors matched within 15,
9, and 20 picoseconds.  (And the coax was measured and cut by hand, so
there was certainly some room for error there!)

The technique was to feed a 1000 Hz pulse train (generated from a 5369A
time synthesizer, but any good pulse generator would do) into the 5370B
TIC by routing the pulses into a T connector connected to the counter
START input; the other side of the T went to a four foot cable to
provide some additional delay.

The cable under test was connected to that cable, then to another four
foot cable, and then to the stop input of the counter.  I first measured
the delay with just the two fixture cables and N adapters in place,
which as 12.579 nanoseconds; I then subtracted the estimated length of
the N barrel connector that substituted for the cable under test.  Then
I added the cable under test, remeasured, and subtracted out the fixture
delay to get the cable length.

I used a 100k sample average which yields (IIRC) 200 femtosecond
resolution in the 5370B, and for each run checked the min, max, and
standard deviation statistics to make sure nothing goofy was going on
Standard deviation for a run like that on my 5370B is typically 30 to 40ps.

John

John Ackermann N8UR said the following on 04/09/2007 08:40 AM:

I mistyped -- the cable was LMR-240 for the purists out there.

John

John Ackermann N8UR wrote:

John

Yes, fitting BNC or TNC connectors to LMR400 would have been an
interesting exercise.

Bruce