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.

To facilitate comparisons between regulators the estimates for the noise of the 723 reference is perhaps best expressed in ppm/rtHz. i.e. 723 reference noise is around 0.12ppm/rtHz in the (100Hz-10kHz) region. A similar analysis is possible for other conventional regulators.

. > > 73, Steve > Steve The effect of the finite resolution of the sound card ADC can be estimated as follows: For a 16 bit ADC and a sinusoidal beat frequency signal with 10MHz mixer inputs a 16 bit ADC has a quantisation noise of about 8.8 ppm of the amplitude of a full scale sinewave.

I expect that, if 2 sources are near zero phase, then it should only require <10s to estimate the actual phase error within 1ps, or less. Anyone agree? I await & hope for constructive comments and/or corrections. Pete Rawson

. >> It is then possible to obtain estimates for ADEV, MDEV etc for each standard. >> > > The optimistic results at and above the loop time constant, that results even when 3 or more units are used, > is because the noise is then mostly due to the GPS signal itself and NOT the local oscillators in the GPSDO. > In effect you are then using the same 1PPS

. >> >> Now I have not gone through the math to estimate performance compared to >> the traditional ZCD approach, but the complex multiply and average >> approach should be quite robust against noise, and is easily implemented >> in a DSP or FPGA. > >The time-difference between the two sampling points could be minimized >in such an approach as the phase could

I then did a restart with the original drift files and a clock estimate from ntpdate directed at NIST. This is a more realistic event. since even in the event of a system crash, that data is available. Even then, it is a bit unusual for both client and server to be restarted at the same time.

For this application overlapping estimator may work well enough. A full reciprocal counter is not needed, a fixed gate time could simplify things and by letting the loop frequency steer a counter it would only need to be sampled regularly for the rest of the processing to be done in software.

As a matter of fact, my measurements of the C-MAX line up with the top end of that estimate (and Tom's :-)). I'm still planning on capturing a long set of timings, but I need to do some hardware mods first.

He should measure: - Lock-in transient - Lock-in time/time-constant - Lock-in overshot - Estimate control loop bandwidth and Q-value/resonance He should then also have a "lock" detector, possibly several lock levels and illustrate them in the transient waveform. Then, he should measure the lock-in deviation pattern and measure bias and RMS noise.