[EMAIL PROTECTED] wrote: > > In a message dated 4/8/2007 16:49:00 Pacific Daylight Time, > [EMAIL PROTECTED] 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. > 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. > > >> Wavecrest is likely to have a trigger jitter ~ 10ps rms (when the input >> comparator noise is taken into account with the finite input sinewave >> signal slew rate) >> > > > 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. > 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. > > 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. > Only if the delay isn't too long for the particular source's noise characteristics. Otherwise you've just built a delay line discriminator. > > 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. > > 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. > 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. > > 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. > Will report raw capture data once I have the software running. > > bye, > Said > Bruce > > > _______________________________________________ time-nuts mailing list [email protected] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
