Björn,
On 05/02/2012 10:54 PM, b...@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
_______________________________________________
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.
