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.

...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@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@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

Hi, 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 the end. 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 action. 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 captured. 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. Cheers, Magnus 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@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@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@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. >