[time-nuts] Setting up PRS10 with M12+T GPS

Magnus Danielson magnus at rubidium.dyndns.org
Wed May 2 23:36:24 UTC 2012


On 05/03/2012 01:09 AM, bg at lysator.liu.se wrote:
>> Björn,
>>
>> On 05/03/2012 12:30 AM, bg at lysator.liu.se 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



More information about the time-nuts mailing list