[time-nuts] Data collection from 5115A phase noise test set?

[John Miles]

> Hi all,
> 
> A 5115A phase noise test set landed in our lab and I am wondering about the
> data collection.
> It has two telnet ports one for commands and one for phase data.
> When issuing "start" on the command-port it starts spitting out
> phase-difference values on the data port.
> 
> However it seems to me that the phase data alone (REF-DUT phase, in units
> of the REF period) is almost useless without knowing the internal workings
> of the device.
> The phase values are clearly not the true phase difference, which would
> quickly accumulate to a huge number with e.g. REF=10MHz and DUT=11MHz.
> My
> understanding is that digital downconversion (DDC) is performed on both REF
> and DUT signals, and without knowing the LO frequencies for the DDC the raw
> phase data alone is almost useless.
> 
> The command prompt does have commands for displaying the internally
> calculated ADEV, L(f), frequency-counter readings, etc. and these seem to
> show correct and OK values, but there seems to be no way to reproduce e.g.
> the ADEV or frequency-counter values/statistics from the raw phase values
> on the data port??
> Is this correct? Any other experiences with the 5115A or higher end 5120A?

The shorter-term ADEV values on the 5120A/5125A test sets are mathematically backed out of the phase noise data.  They will never perfectly match the ADEV values you get from plotting the phase data stream in my experience.  

I don't actually know what they do on the 5115A, though -- since it doesn't do cross-correlated PN, there's presumably no reason to derive the short-term ADEV plot from the PN data pipeline.  I'd expect the plots to match in that case, apart from any errors due to different measurement bandwidths and ADEV bin distributions.

It's also true that there will always be an arbitrary phase slope error due to the mismatch between the frequency estimate used to tune the internal DDCs and the "real" frequency of the incoming data.  Knowledge of the actual DDC core frequencies would not be enough to correct for this behavior, because you would also need to know how far off they are.  The true frequency offset can't be measured ahead of time with perfect certainty, so it has to be estimated, and the resulting error will often dominate the slope of the phase-difference graph.

The TimePod and 3120A test sets allow you to specify the input and reference frequencies explicitly to obtain a valid phase slope in residual measurements and other cases where the exact frequencies are known by the user.  But this is something you have to remember to do prior to the measurement, and you still don't get a calibrated absolute offset. 

(Also, note that TimeLab can read both phase and PN data from 51xx test sets without the need to use a Telnet client.  Not that it helps with this particular issue, of course.)

-- john, KE5FX
Miles Design LLC