PRS-10 input and output calibrations
Fellow time-nuts,
Anyone who has tried to calibrate the PPS input and PPS output
interpolators of the PRS-10?
The output calibration seems pretty easy to do, just a TIC to measure
the PPS to 10 MHz and then sweep through the output delay values to
cover a little more than the 400 ns range.
The input calibration would be something in the similar way, a simpel
method would be to use a coax cable between output and input, and then
use the internal output offset to measure the range of the input
interpolator. However, the input interpolator is a decade better than
the output interpolator. However, considering that I have a 5359A just
waiting to be used, I think I use a fixed output PPS delay and trigger
the 5359A with and then sweep that one.
I would then use the collected data to find suitable correction values.
Comments and suggestions? Experience?
Cheers,
Magnus
Magnus,
Interesting! Have a couple of PRS-10s at work that we wanted to lock
together. We never got one to track the other in a reliable way.
--
Björn
Fellow time-nuts,
Anyone who has tried to calibrate the PPS input and PPS output
interpolators of the PRS-10?
The output calibration seems pretty easy to do, just a TIC to measure
the PPS to 10 MHz and then sweep through the output delay values to
cover a little more than the 400 ns range.
The input calibration would be something in the similar way, a simpel
method would be to use a coax cable between output and input, and then
use the internal output offset to measure the range of the input
interpolator. However, the input interpolator is a decade better than
the output interpolator. However, considering that I have a 5359A just
waiting to be used, I think I use a fixed output PPS delay and trigger
the 5359A with and then sweep that one.
I would then use the collected data to find suitable correction values.
Comments and suggestions? Experience?
Cheers,
Magnus
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.
Hej Björn,
On 04/22/2012 06:12 PM, bg@lysator.liu.se wrote:
Magnus,
Interesting! Have a couple of PRS-10s at work that we wanted to lock
together. We never got one to track the other in a reliable way.
I'll play around with mine, and when I have more experience you can lend
me them and I can look them over. The PRS-10 is fairly nice since you
can experiment with the soft parameters and only when you are satisfied
you can write them to the EEPROM. You can also read out the EEPROM
parameters regardless of the current running parameters.
The manual isn't particular clever in correlating error observations and
what you should do about it, but it's fairly "open".
Cheers,
Magnus
In message 4F93F032.2040608@rubidium.dyndns.org, Magnus Danielson writes:
The input calibration would be something in the similar way,
What I did:
Detune an OCXO slightly (I actually have a 9.99997 MHz OCXO from
IsoTemp), feed it to PPSDIV, disable the discipline code in the
PRS10, collect the measured input time stamps over some hours.
Either you get a nice ramp, or you get som kind of demented staircase,
in which case you try to figure out which of the calibration constants
to mess with.
An alternative is to feed the PRS10 output to a HP333x Synthesizer
and have that generate your 10-epsilon MHz for the PPSdiv.
This general "vernier" method can be used to measure all sorts of tricky
stuff, from interrupt latencies in operating system kernels to
stuff like the above.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Björn, what do you mean with "We never got one to track the other in a
reliable way"?
Thai is, how can it be that a PRS10 cannot track another PRS10? What do you
get when trying to track one with the other?
On Sun, Apr 22, 2012 at 8:44 PM, Poul-Henning Kamp phk@phk.freebsd.dkwrote:
In message 4F93F032.2040608@rubidium.dyndns.org, Magnus Danielson
writes:
The input calibration would be something in the similar way,
What I did:
Detune an OCXO slightly (I actually have a 9.99997 MHz OCXO from
IsoTemp), feed it to PPSDIV, disable the discipline code in the
PRS10, collect the measured input time stamps over some hours.
Either you get a nice ramp, or you get som kind of demented staircase,
in which case you try to figure out which of the calibration constants
to mess with.
An alternative is to feed the PRS10 output to a HP333x Synthesizer
and have that generate your 10-epsilon MHz for the PPSdiv.
This general "vernier" method can be used to measure all sorts of tricky
stuff, from interrupt latencies in operating system kernels to
stuff like the above.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
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.
With factory default settings with 2 PRS-10s, connecting 1PPS_out from one
unit to 1PPS_in on the other, would not align the 1PPS_out pulses. They
were off by several hundred of ns. It was probably an operator error
somewhere. We just did not find the error in the time frame we had
available.
--
Björn
Björn, what do you mean with "We never got one to track the other in a
reliable way"?
Thai is, how can it be that a PRS10 cannot track another PRS10? What do
you
get when trying to track one with the other?
On Sun, Apr 22, 2012 at 8:44 PM, Poul-Henning Kamp
phk@phk.freebsd.dkwrote:
In message 4F93F032.2040608@rubidium.dyndns.org, Magnus Danielson
writes:
The input calibration would be something in the similar way,
What I did:
Detune an OCXO slightly (I actually have a 9.99997 MHz OCXO from
IsoTemp), feed it to PPSDIV, disable the discipline code in the
PRS10, collect the measured input time stamps over some hours.
Either you get a nice ramp, or you get som kind of demented staircase,
in which case you try to figure out which of the calibration constants
to mess with.
An alternative is to feed the PRS10 output to a HP333x Synthesizer
and have that generate your 10-epsilon MHz for the PPSdiv.
This general "vernier" method can be used to measure all sorts of tricky
stuff, from interrupt latencies in operating system kernels to
stuff like the above.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by
incompetence.
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.
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.
That is very interesting in my opinion and, for those who have access to
more than one PRS10, further investigation should be done. I had a new
PRS10 and, just out-of-the-box, it locked (not instantly, of course) to the
HP53508 PPS.
On Sun, Apr 22, 2012 at 10:47 PM, bg@lysator.liu.se wrote:
With factory default settings with 2 PRS-10s, connecting 1PPS_out from one
unit to 1PPS_in on the other, would not align the 1PPS_out pulses. They
were off by several hundred of ns. It was probably an operator error
somewhere. We just did not find the error in the time frame we had
available.
--
Björn
Björn, what do you mean with "We never got one to track the other in a
reliable way"?
Thai is, how can it be that a PRS10 cannot track another PRS10? What do
you
get when trying to track one with the other?
On Sun, Apr 22, 2012 at 8:44 PM, Poul-Henning Kamp
phk@phk.freebsd.dkwrote:
In message 4F93F032.2040608@rubidium.dyndns.org, Magnus Danielson
writes:
The input calibration would be something in the similar way,
What I did:
Detune an OCXO slightly (I actually have a 9.99997 MHz OCXO from
IsoTemp), feed it to PPSDIV, disable the discipline code in the
PRS10, collect the measured input time stamps over some hours.
Either you get a nice ramp, or you get som kind of demented staircase,
in which case you try to figure out which of the calibration constants
to mess with.
An alternative is to feed the PRS10 output to a HP333x Synthesizer
and have that generate your 10-epsilon MHz for the PPSdiv.
This general "vernier" method can be used to measure all sorts of tricky
stuff, from interrupt latencies in operating system kernels to
stuff like the above.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by
incompetence.
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.
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.
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.
On 04/22/2012 10:47 PM, bg@lysator.liu.se wrote:
With factory default settings with 2 PRS-10s, connecting 1PPS_out from one
unit to 1PPS_in on the other, would not align the 1PPS_out pulses. They
were off by several hundred of ns. It was probably an operator error
somewhere. We just did not find the error in the time frame we had
available.
Interlocking two oscillators like that might be a really bad idea, as
the PLL will have a gain, so risk having a gain loop, especially when
the oscillators have the same default parameters being setup. This is
similar to the form of long PLL chain analysis that has been simulated
using a single PLL and a delay-loop. The peaking gain at the PLL
bandwidth is what kills it.
If there is input and/or output non-linearities in the latest
calibration parameters, that may be a reason they locked up in a strange
situation.
Using a common PPS pulse as input and then compare the output PPS pulses
is a much more valid test.
Cheers,
Magnus
In message CAL8XPmO0Wj2AUW8Q=-DrDGGDMdhTsteVJaMKgkXktgq=0J4CSA@mail.gmail.com
, Azelio Boriani writes:
That is very interesting in my opinion and, for those who have access to
more than one PRS10, further investigation should be done. I had a new
PRS10 and, just out-of-the-box, it locked (not instantly, of course) to the
HP53508 PPS.
There are threel obvious issues: Which flank you trigger on and
which polarity and width the output pulse has.
The output pulse from the PRS10 is pretty narrow, making it very
easy to mistakenly use the wrong flank.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
In message 4F947FF0.8070703@rubidium.dyndns.org, Magnus Danielson writes:
On 04/22/2012 10:47 PM, bg@lysator.liu.se wrote:
Interlocking two oscillators like that might be a really bad idea, as
the PLL will have a gain, so risk having a gain loop, especially when
the oscillators have the same default parameters being setup.
You would clearly want to torque the timeconstant of the second PRS10
in that scenario, but idea is not without merit.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.