[time-nuts] GPSDO recovery from holdover

Said Jackson saidjack at aol.com
Sat Dec 1 17:28:16 UTC 2012


Hello Azelio,

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?

Bye,
Said

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
>>> cycles.
>>> The other is to adjust the frequency so that the PPS slews back to
>>> on-time.
>>> 
>>> The first approach gives you a second with the wrong number of cycles.
>>> The
>>> 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,
>> 
>> Charles
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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 mailing list