On 05/03/2012 01:09 AM, [email protected] wrote:
Björn,
On 05/03/2012 12:30 AM, [email protected] wrote:
Magnus,
Tbolt PRS10A PRS10B
1pps --> PPSIN
PPSOUT --> PPS IN
PRS10A slowly following the Tbolt (PRS10A PT8)
PRS10B "quickly" following the PRS10A (PRS10B PT0)
Ok?
Yes, but if this is a free-running thunderbolt (I think you said
something about that) then PT8 will be a bit slow. For a tracking
thunderbolt PT8 may work, even if it takes time for it to track in.
No a GPS locked Tbolt.
Thanks for that clarification, I am obviously a bit tired.
A free-running Tbolt was just an example of a very
low noise 1PPS source, where I would find it useful to have a "PT-1"
bias
calibration mode bypassing the PLL, and moving the PPSOUT directly with
the PPSIN.
So this does not suffice?:
Page 33:
"When provided with an accurate and stable 1pps source, the unit will
automatically align its 1pps output to the 1pps input and then adjust
the frequency of the rubidium reference to maintain the alignment over
time."
Page 17:
"After receiving 256 consecutive "good" 1pps inputs, the 1pps pulse
delay is set to the last of the 256 time-tag values."
I interpret this as this:
When the 256s PPS has been approved, the last-time-tag is used to adjust
the output delay such that the output signal is aligned, within the
precision of the time-offset value.
Then, the PLL is running. Either the output delay is not shifted and
only the PPS alignment is done on approval, or it is updated in the
background. The text only supports the former explicitly, but it would
be nice to verify if it is either of these.
Doing phase-jump of PPS like this on start-up is expected. I've even has
a measurement on it somewhere.
It is surely working alright in the long run. I am not convinced it is
appropriate for applications where you fire up the PRS for a few hours and
then do a few hours of measurements.
Even if it jumps the 1pps, early on the PLL will still be 100s of ns away
from its reference. There should be a better way to make this, than how I
run the PRS...
Indeed. What you can do is to forward correct the phase error in order
"hide" the loop error.
What the PRS-10 approach does is:
1) First degree compensate the PPS offset error
2) Use the phase difference from that point to track in frequency error.
The PI-loop will ensure that the phase-error goes towards 0.
The end result should be a time-error close to zero.
The track-in error would be exposed in the PRS-10, but a feed-forward
solution would paper over it. Considering that PRS-10 had telecom
applications in mind, this approach would be fine, since we have usually
loads of time to average things out on, and we can handle some
transients at times.
The PRS-10 approach is not ideal for some measurements and some other
approaches. You can however lower the initial jump by the trimmer, as
the initial frequency offset could be reduced. /|T(0) would however
still be there.
The relative openness of the PRS-10 would however allow for some smarter
tricks to be played. The PRS-10 does not play all the tricks it could
play given the hardware capabilities it has.
Cheers,
Magnus
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
