[time-nuts] TIC resolution impact on GPSDO's performance

Dr Bruce Griffiths bruce.griffiths at xtra.co.nz
Wed Dec 27 23:33:19 EST 2006


Didier Juges wrote:
> Dr Bruce Griffiths wrote:
>   
>> Didier Juges wrote:
>>   
>>     
>>> Hi David,
>>>
>>> David I. Emery wrote:
>>>   
>>>     
>>>       
>>>> On Tue, Dec 26, 2006 at 04:14:45PM -0600, Didier Juges wrote:
>>>>
>>>>   
>>>>     
>>>>       
>>>>         
>>>>> When reading the data sheet for the Thunderbolt, and reading all the 
>>>>> pitfalls associated with non-integrated GPSDO designs using stand alone 
>>>>> GPS receivers, such as sawtooth correction and quantization noise, it 
>>>>> seems like the integrated approach used in the Thunderbolt is the best 
>>>>> way to go. Not only it is cheaper and simpler, and therefore should be 
>>>>> more reliable, but it avoids an entire class of problems and should 
>>>>> perform better, everything else being equal (receiver sensitivity and 
>>>>> internal noise, OCXO quality). In this case, simplicity goes with better 
>>>>> performance, which is not always the case.
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>> 	It is my understanding that the Motorola Oncore timing receiver
>>>> modules (UT,VP and onwards to the M12+ family) can be ordered in a
>>>> version that accepts an EXTERNAL 10 mhz rather than using an internal
>>>> crystal for timing.   At least I think it is a 10 mhz input, but I am
>>>> quite sure they can be ordered in a version that does not generate
>>>> timing or frequency from an internal xtal oscillator.
>>>>
>>>> 	And if my presumption is correct that the Trimble Thunderbolt
>>>> hardware is either identical to or very similar to the HP/Symmetricom 
>>>> 58540A hardware (and both OEMed from a company in Japan) I think you
>>>> will find that they do use a Motorola GPS timing receiver in external
>>>> clocked mode using a clock derived from the 10 mhz OXCO.   I beleive my
>>>> 58540As do anyway.
>>>> 	
>>>>   
>>>>     
>>>>       
>>>>         
>>> If you look at the picture of the bare PWB of the Thunderbolt and the 
>>> explanations of the operation in the manual, you will see the unit fits 
>>> everything on a single PWB (no separate GPS receiver) and the unit's 
>>> software is designed to steer the 10 MHz VCOCXO in order to align it 
>>> with the GPS timing data. Simply feeding a GPS receiver with external 10 
>>> MHz (or other clock frequency) will not achieve the same thing. As long 
>>> as the firmware simply skips pulses to align the two, you will still 
>>> have granularity and possibly hanging bridges.
>>>
>>> Now, it may be possible to use a *conventional* GPS receiver and make it 
>>> work like the Thunderbolt with the right external firmware, but I don't 
>>> see how. You need access to the internals of the GPS firmware. The 
>>> difference is what the GPS receiver does when it finds a timing 
>>> difference between the GPS clock and the OCXO clock.
>>>
>>> In a standalone GPS receiver, the receiver does not control its CPU 
>>> clock (which is usually higher than 10 MHz), it can only control the PPS 
>>> output by selecting which edge of the clock it's going to pick to toggle 
>>> the PPS output (by skipping or adding pulses to the divider, I guess), 
>>> hence the granularity. In the Thunderbolt, the divider is fixed (except 
>>> for jam-sync) and the GPS receiver steers the OCXO via the DAC instead. 
>>> That processing must take place inside the GPS receiver and if that 
>>> feature has not been built in the GPS firmware, I don't see how you 
>>> could emulate it externally.
>>>
>>> Simply feeding an external clock to the GPS receiver does not address 
>>> the problem. It might actually make it worse by removing the randomness 
>>> in the PPS jitter, which could not be later removed by filtering.
>>>
>>> I have seen a picture of the HP/Symmetricon unit (there was one for sale 
>>> on eBay recently) and it looks very similar (looks about the same size 
>>> and same number and type of connectors), but the connector arrangement 
>>> is different, so they are not the same implementation. I have not taken 
>>> my Thunderbolt apart yet. When I do, I will look for clues about who is 
>>> making it and report here. If someone else already knows that, please 
>>> let me know so I don't have to take mine apart.
>>>
>>>   
>>>     
>>>       
>>>>> Yet, I am surprised that so many of the OEM timing receiver solutions 
>>>>> use the *conventional* approach. For instance, the Lucent receiver John 
>>>>> just bought seems to have a discrete, independent GPS receiver (the 
>>>>> darker board on top), and many companies still build stand alone GPS 
>>>>> receivers specifically for timing application without embedding the 
>>>>> GPSDO logic and an OCXO. That does not seem to make much sense to me.
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>> 	I have ordered a Lucent RFTG-M-XO box but it has yet to arrive -
>>>> however, looking at the photos published today, it does not seem clear
>>>> they don't use a GPS receiver with an external clock.  Not easy to tell
>>>> since the guts of the Motorola module are under a shield can.
>>>>
>>>> 	There is certainly no reason to integrate a GPS receiver with
>>>> the OXCO PLL and status electronics if one can buy an OEM one that takes
>>>> an external clock for less money (and hastle over firmware development
>>>> and licensing for the GPS side).   GPSDOs are a small market compared to
>>>> the overall market for OEM GPS solutions and there are economies of
>>>> scale involved.
>>>>
>>>> 	And as a final note - a Datum 9390 box I have that dates to
>>>> beginning of time (GPS time that is) used a Rb derived clock for the
>>>> antique OEM Trimble GPS receiver board it uses so that approach has been
>>>> around from the early days...
>>>>
>>>>   
>>>>     
>>>>       
>>>>         
>>> Again, the issue is not where the clock for the receiver comes from, 
>>> it's how the GPS firmware steers the clock. If the GPS receiver steers 
>>> it by skipping or adding pulses (and if the GPS receiver does not 
>>> directly control the OCXO, that's what will happen), you have 
>>> granularity and hanging bridges.
>>>
>>> I am probably missing something here, but I'll be glad to be enlightened.
>>>
>>> Didier
>>>
>>> _______________________________________________
>>> time-nuts mailing list
>>> time-nuts at febo.com
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>
>>>   
>>>     
>>>       
>> Didier
>>
>> Surely the PPS sawtooth correction, in effect, comprises the output of a 
>> narrow range phase detector which compares the computed GPS pulse with 
>> the both clock edges of the output pulse timing clock. In principle on 
>> just needs to combine the sawtooth correction with a knowledge of which 
>> clock edge was selected (easily done with a little hardware ) and use 
>> the combination as the phase error in a tracking loop that steers the 
>> oscillator to the "correct" frequency. Of course the relatively narrow 
>> range of the phase detector presents some difficulties such as ensuring 
>> the oscillator locks onto the correct integer multiple of 1Hz.
>>
>> Bruce
>>   
>>     
> Bruce,
>
> I understand that there are ways around the problem, but in a 
> conventional GPSDO, this correction can only happen after the 1 PPS has 
> been generated, after the fact if you will, and from there you can phase 
> lock a precise 10 MHz OCXO from which you can derive yet another 
> (jitter-free) PPS signal for other uses. In the Thunderbolt, this 
> correction is simply not needed, and the PPS is organically free of this 
> particular type of jitter, which really is an artifact due to the 
> architecture.
>
> It just seems the integrated architecture gets rid of a lot of 
> artificial baggage and complexity.
>
> I understand that the vastly larger part of the GPS market is for 
> consumer navigation systems, for which the PPS is not used (maybe not 
> even generated in hardware, why bother? who needs sub-second timing 
> accuracy in a car?), and economies of scale may make it attractive for 
> timing people to use the mass produced navigation hardware and patch 
> around the issues, but in this case, the cost savings associated with 
> the simplification may offset the amortization of the development costs 
> and the increased manufacturing costs due to smaller quantities of 
> integrated, strictly timing receivers/GPSDO.
>
> Interestingly, the Fury GPSDO seems to use an off-the-shelf Motorola GPS 
> receiver, yet achieves good performance at low cost, in an even smaller 
> package than the Thunderbolt and with half the power consumption (let's 
> ignore the 6 or 7 years difference between they birth dates...) They 
> advertise a price of $750 in small quantities (someone told me a few 
> days ago he had been quoted $1450 for a new Thunderbolt GPSDO.) The Fury 
> gives you the choice of GPS PPS and OCXO PPS, that's nice, but it shows 
> that the GPS PPS is generated, so I suspect the Fury may be subject to 
> sawtooth correction and hanging bridges. Maybe Said can enlighten us on 
> that.
>
> Anyway, as always, I have seriously enjoyed that thread!
>
> Thanks
>
> Didier
>
>
>
> _______________________________________________
> time-nuts mailing list
> time-nuts at febo.com
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>
>   
Didier

Yes, using an integrated high stability oscillator in the GPS receiver 
provides all the local oscillator signals etc, and is "locked" to the 
GPS signals eliminates the external TIC that would otherwise be 
required. Some of the more expensive early GPS receivers used 10.23MHz 
OCXOs for this purpose.
1575.42 = 154 x 10.23
1227.6   = 120 x 10.23

The drawback is that the short term frequency stability is limited to 
that of the oscillator chosen by the manufacturer, if one happens to 
have an oscillator (HP10811, HP10544, FTS1200, OSA 8607, etc.)with 
better short term stability one can do better.

The OCXO used in the Thunderbolt doesn't appear to have great short term 
stability specifications.
It appears to be worse (100X??)  than just about any variety of HP10811 
for example.
It appears to be (1000x ??) worse than an FTS1200, FTS1000, or an OSA 8607.

To use an external oscillator in the way I indicated, one has to modify 
a standard M12+, M12M timing receiver to allow using an external oscillator.
I'm not sure that this is possible though it is likely.

Bruce



More information about the time-nuts mailing list