Data collection from 5115A phase noise test set?
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?
thanks,
Anders
Lucky you! The 5115A has a thousand times better resolution than a hp5370 or SR620 counter.
The architecture of the 5110A 5115A and 5120A is described in the manuals. These are frequency stability analyzers so the initial phase and frequency offsets are not important. What you're seeing is phase difference data after these initial calibration offsets are removed. This is necessary because the unit allows a wide-range of frequencies on either port.
That method also keeps the floating point output from losing accuracy over long runs. A count of raw cycles would grow unbounded and you would lose resolution as you gained range. So what you're seeing is by design and it doesn't affect the phase noise or ADEV plots at all. I'm not sure why you call it "useless".
Note the 5110A has a single-DDS option. When both inputs are nominally the same frequency the streaming data is closer to raw phase. Not sure if the 5115/5120 does also. But either way, none of this matters to ADEV.
Your ADEV plots from raw data should match the ADEV plots on the screen. Watch out for bandwidth mismatch.
/tvb
----- Original Message -----
From: "Anders Wallin" anders.e.e.wallin@gmail.com
To: "Discussion" time-nuts@febo.com
Sent: Thursday, December 10, 2015 7:20 AM
Subject: [time-nuts] Data collection from 5115A phase noise test set?
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?
thanks,
Anders
There is a gotcha in the TSC phase data... the architecture introduces a
deliberate phase offset to the phase data so you will always gain (or
lose) phase over time. Hook both inputs to the same source, and you'll
still have a slope in the output data (and the slope and intercept will
be different on each run).
Thus you cannot derive the actual frequency or phase offset from the
phase data -- it is only useful for stability and phase noise analysis.
The TSC people told me this was a feature, not a bug. :-) If you want
to get the actual frequency of the DUT, you need to use the fcounter
function. And I've never been sure about the averaging used to derive
the 1/10/100/1000 second values from fcounter, and how best to derive a
longer-term frequency average from that data.
John
On 12/10/2015 1:44 PM, Tom Van Baak wrote:
Lucky you! The 5115A has a thousand times better resolution than a hp5370 or SR620 counter.
The architecture of the 5110A 5115A and 5120A is described in the manuals. These are frequency stability analyzers so the initial phase and frequency offsets are not important. What you're seeing is phase difference data after these initial calibration offsets are removed. This is necessary because the unit allows a wide-range of frequencies on either port.
That method also keeps the floating point output from losing accuracy over long runs. A count of raw cycles would grow unbounded and you would lose resolution as you gained range. So what you're seeing is by design and it doesn't affect the phase noise or ADEV plots at all. I'm not sure why you call it "useless".
Note the 5110A has a single-DDS option. When both inputs are nominally the same frequency the streaming data is closer to raw phase. Not sure if the 5115/5120 does also. But either way, none of this matters to ADEV.
Your ADEV plots from raw data should match the ADEV plots on the screen. Watch out for bandwidth mismatch.
/tvb
----- Original Message -----
From: "Anders Wallin" anders.e.e.wallin@gmail.com
To: "Discussion" time-nuts@febo.com
Sent: Thursday, December 10, 2015 7:20 AM
Subject: [time-nuts] Data collection from 5115A phase noise test set?
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?
thanks,
Anders
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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
Thanks for these useful comments!
It seems there is no way to estimate frequency from looking at the phase
data then?
Does TimeLab have automated collection for the frequency-counter data on
the control port?
Anders
On Fri, Dec 11, 2015 at 2:51 AM, John Miles john@miles.io wrote:
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
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
It seems there is no way to estimate frequency from looking at the phase
data then?
Not to my knowledge. The frequency count chart on the instrument itself is always correct, since it can take the internal baseband offset out of the incoming data. Because TimeLab doesn't have access to that offset, its frequency count chart won't be accurate when acquiring data from the 51xx.
Does TimeLab have automated collection for the frequency-counter data on
the control port?
TimeLab doesn't, but I have another collection of quick-and-dirty utilities that includes a way to do it (http://www.ke5fx.com/gpib/readme.htm). The tsccmd.bat file can be run without any arguments to get command help; this option in particular will pull the frequency count entries across as ASCII text:
C:\Program Files (x86)\KE5FX\GPIB>tsccmd 192.168.1.225 "show fcounter"
Using Windows Sockets V2.2 (WinSock 2.0)
Initializing host JMCORE64, address 192.168.1.200
Attempting to connect to server 192.168.1.225:1299 . . .
Connected to server 192.168.1.225:1299
Transmitting "show fcounter" ...
show fcounter
Welcome to the Symmetricom 5125A
=192.168.1.225 > Reference Frequency: 100.0 MHz (auto)
Avg Time (s) Frequency (MHz)
1 9.9999999627589
10 9.99999996274766
100 9.999999962746890
Done, 8 line(s) received
Average rate = 11.0/sec
There's probably a way (wget?) to do something similar in most other OSes -- you basically need to send "show fcounter" to port 1299 with an appropriate timeout interval. Then you can pipe the response to something that parses the text that comes back, if desired.
-- john, KE5FX
Miles Design LLC