magnus at rubidium.dyndns.org
Wed Aug 17 14:34:06 EDT 2016
You do the jamming when you have a reference again.
You have three possibilities when the reference/GPS comes back:
1) Re-acquire frequency and phase lock directly
The time error between the generated PPS and the reference PPS is
directly applied to the control loop which then will start to track in.
This works, but if you have been in hold-over for a long time, the
trace-in might take quite some time.
To overcome this, heuristics can be used to increase the loop bandwidth,
as the trace-in time depends heavily on it. Then the heuristics also
needs to adjust the bandwidth back to narrow-band.
Shifting of bandwidth needs to be done with care, and there is an art to
design the loop for it and the heuristics to work well. A Kalman filter
could be used, but just tossing your trust to the Kalman as if it is a
silver bullet is quite foolish, the Kalman needs it's heuristics and
design to do well, so well, I'm not sure the difference is very large in
2) Jam phase into about right phase and then re-acquire frequency and
phase from there.
Here you start with detecting that the phase is way out there, so throw
a wrench into the machinery to re-set the counters and thus push the
generated PPS into about the same phase. For a 10 MHz clock you select
the 100 ns cycle that fits and you can with easy methods be within +/-
100 ns and with a little bit care be within +/- 50 ns by such a jamming
The effect of the jamming is that you have the phase about where you
want it, but a phase error will remain. Just close the loop with the
remaining phase error and any frequency error will also be need to be
The benefit is that you don't need to back out as much in bandwidth and
the process goes quicker.
3) Jam phase and frequency and then re-acquire frequency and phase.
Just as you jam the phase, you then measure the frequency error and
re-set the frequency state. You then measure the frequency during some
time, set it and then close the loop.
Again you have the benefit of the phase-jam, but the frequency
measurement time is similar to the closing of the loop and well, your
milage vary depending how well you do the heuristics.
A re-occuring theme is that there is heuristics controlling the process,
and that can be both a help and a threat to system properties.
Let's just say that one needs to work on it and many details.
On 08/17/2016 10:06 AM, Azelio Boriani wrote:
> ...the Z3801A requires the device to be in holdover... with the GPS
> PPS already acquired: I think that the "jam sync" must be done against
> some reference...
> On Wed, Aug 17, 2016 at 4:49 AM, Mark Sims <holrum at hotmail.com> wrote:
>> The Trimble GPSDOs and most of the SCPI ones (like the Z3801A) have "jam sync" commands that force the receiver to do an immediate time sync (the Z3801A requires the device to be in holdover before it will accept a jam sync). Some also have commands where you an also specify thresholds where the receiver alarms and/or does an automatic jam sync and thresholds for loss-of-signal time before the device goes into holdover mode.
>> I have selected a somewhat more intricate setup in which you can set a
>> re-assignment limit, so when the phase error is outside of that limit,
>> you turn the output off, jumps the phase difference, and then starts to
>> track in from there. The reason being that at some time deviation, the
>> time it takes to track in the phase error is too large to be practical
>> so turning of and jump has less impact.
>> time-nuts mailing list -- time-nuts at 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 at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts