[time-nuts] GPSDO recovery from holdover
saidjack at aol.com
Sat Dec 1 17:28:16 UTC 2012
We added a user adjustable jam-sync threshold some time ago for European DVB-T applications for that reason. The customer can now decide the phase window in which the frequency is drifted slowly without a phase jump.
But I think your math may be off, with default settings we typically do phase adjustments with about 2E-011 (0.02ppb, 0.0002Hz at 10MHz, 0.02Hz at 1GHz carrier) frequency offsets. To correct 1000ns offset from your example, it would take about 50K seconds, or a bit more than a half a day with those settings.
But if you set the loop parameters more aggressively to 1ns/s as in your example, it would take less than 20 minutes to correct 1us.. Not 12hrs. Unless you meant to say ms?
Sent from my iPad
On Dec 1, 2012, at 6:17 AM, Azelio Boriani <azelio.boriani at screen.it> wrote:
> Here in Europe the use of GPSDOs has dramatically increased with the
> transition to the digital TV broadcasting. The single frequency network
> (SFN) mode of transmission requires the presence of a time and frequency
> reference. The ETSI has a Technical Report (TR101-190) where the maximum
> time and frequency error is stated: + or - 1uS for the time (PPS) and 1.1Hz
> for the highest carrier frequency. The 1.1Hz max error for the frequency
> binds the maximum recovery speed for the PPS. The UHF highest carrier is
> 858MHz so that the 10MHz max frequency error is 0.01282Hz that is 1.282nS
> for every second. To recover, say, 1uS, you need 12.8 hours. Recently
> (April 2012), our national broadcaster (RAI TV) research lab (RAI CRIT) has
> published an article in his technical magazine (Elettronica e
> Telecomunicazioni http://www.crit.rai.it/eletel/ ) about how to test GPSDOs
> for the SFN use. They state that the maximum time error, above which the
> PPS recovery can be made with a phase jump, is 5uS but they forgot that to
> recover 5uS without phase jumps at 1.282nS/S speed is 2 days and 16 hours!
> On Sat, Dec 1, 2012 at 11:17 AM, Charles P. Steinmetz <
> charles_steinmetz at lavabit.com> wrote:
>> Hal wrote:
>> I can see two ways to recover. One is to jump the 10 MHz clock by 10
>>> The other is to adjust the frequency so that the PPS slews back to
>>> The first approach gives you a second with the wrong number of cycles.
>>> second approach has your clock frequency off for a while with a trade off
>>> between how far off and how long it's off.
>> Both the TBolt and HP38xx default to the second method you describe, and
>> both can be manually forced to jump to the nearest cycle (TBolt = "jam
>> sync," HP = ":SYNChronization:IMMediate"), which gets the PPS within 50 nS.
>> At that point, they revert to the first method and do the last <=50 nS by
>> adjusting the oscillator frequency.
>> The TBolt allows you to program a "maximum frequency offset," which seems
>> as if it should establish a limit on how fast it can correct the PPS, but I
>> have never seen one come anywhere near the default maximum offset. The
>> TBolt also allows you to set a "jam sync threshold," which seems as if it
>> ought to make the unit jam sync automatically when the threshold is
>> exceeded -- but I've never seen one do that, either, even when set to "fast
>> recovery." So far as I have seen, jam sync only occurs manually.
>> Best regards,
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> 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