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

[Magnus Danielson]

Björn,

On 05/02/2012 10:54 PM, bg at lysator.liu.se wrote:
> Jerry, Magnus,
>
>> Considering the M12+T PPS noise, you won't need anything stellar. A
>> PICTIC II will do just fine... or if you trust the PRS-10 readings, run
>> from that.
>>
>> What would make this better would to use a sawtooth-correction to PPS
>> delay setup, as the PRS-10 measurement resolution will be about on par
>> with that. Would lower the effects of hanging-bridges, even if one
>> suffers less when dealing with a rubidium.
>>
>> Adjust the PRS-10 PLL bandwidth/time-constant, the default value is most
>> probably not optimum, you can go further up in time. Do check the manual.
>
> But do not have a large PLL time-constant, while you are checking basic
> functionality. Time-constants are shown in a table on page 35 in the
> manual.
> With default (PT=8) settings it will take hours for the pll to get close
> in. Any tinkering with moving the pulse (PP) or delay calibration (TO)
> will take forever to show if you got the sign right or hade the right
> offset size... ;-(

Yes, PT8 gives an 18 hour time-constant, forgot that.

> Calibrate the Time offset (TO) according to the example on page 32 in the
> manual, by looping the 1pps_out to 1pps_in on the PRS10, keep in mind that
> you should use the cable, buffers, etc that later will take your GPS 1PPS
> to the 1PPS_in on the PRS, so that you really take care of all delay from
> the GPS 1pps to the PRS10, including internal PRS10 delays, that might
> have changed from previous calibration.

Yes, that would be meaningful for the time-offset. It's the second 
example on page 32, as the first example relates to the time-slope 
parameter.

> Also have in mind that the 1pps disciplining wants 256 good measurements
> in a row just to start closing the PLL.

Indeed. See page 17 for the steps.

> Take the time constant down to 0, and make yourself confident that all
> offset calibrations are right and that you are tracking the right edge of
> the GPS 1PPS etc. After all tinkering to get the basics right then
> increase the time-constant to filter out 1PPS noise and outliers.
>
> To check performance later, you could check that the PRS10 timetag (TT)
> stays very low, by polling each second and logg these values.
>
> I am not at all an expert on PRS10. Have spent the weekend trying to get
> two units to sync to each other. I would like to have a simple (quick
> feedback) way of making sure that most time bias'es are removed. A
> free-running Tbolt for example gives a low noise 1PPS, and quickly
> tracking that, would make bias elimination much less time consuming.
>
> Anyone having an efficiant scheme for setting up a PRS10?

Well, it is a good idea to lock-in with PT0, to make it quickly track 
frequency, and then step through PT1, PT2 etc until the final 
time-constant has been reached. The trick is that you let any remaining 
frequency error "ring out" before you step to the next level. Whenever 
you do a tracking loop, the averaged frequency will vary, and the noise 
will constitute an frequency error if going into hold-over. The peak 
noise "voltage" will be a result of the loop bandwidth filtering. 
Tracking into the hold-over directly will take time, but stepping it 
will work as you quickly will track in the coarse part, and then only 
have to track in the remainder. For longer time-constants, it will still 
take time to reach it, but you will get there quicker by doing this 
sequential stepping.

I haven't had time to try it on my PRS-10, but I think you get the 
general idea. A PI-loop is very cooperative to this approach, and the 
implementation supports this, since the I term is scaled on the input 
side of the integrator, so the accumulated state would not have to be 
scaled as you step the time-constant, which could be cumbersome in some 
other designs.

Also, be aware that you may want to use the pre-filtering (LM1) with 
noisy sources. It should be enabled by default. Pre-filtering when 
properly used (as in this case) gives you a -12 dB/Oct slope rather than 
-6 dB/Oct slope, which is really helpful as you can keep the 
time-constant fairly low for the same suppression capability of noise, 
giving you a quicker track-in time.

A fairly simple PIC/AVR/whatever design should be able to do the magic 
of re-aligning the PRS-10 input delay compensation (TO) as response to 
any time-adjustment values, thus simulating the SRO-100 functionality. 
It could also manage such tuned trackin. A Linux machine and a few lines 
of code would probably be a good starting-point. ;)

Cheers,
Magnus