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

Dr Bruce Griffiths bruce.griffiths at xtra.co.nz
Wed Dec 27 20:06:02 EST 2006


Dr Bruce Griffiths 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
>>
>> _______________________________________________
>> time-nuts mailing list
>> time-nuts at febo.com
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>
>>   
>>     
> Didier
>
> I should have mentioned that  an external counter clocked by the same 
> clock as the PPS timing logic within the receiver can be used  together 
> with some additional logic to  extend the phase detector range as far as 
> required. This surely avoids the difficulties with locking onto the 
> wrong integer multiple of 1Hz. In effect the PPS output pulse from the 
> receiver is used to sample counter. Its slightly more complicated than 
> this in that the fact that the leading edge of  the PPS signal may be 
> synchronised to either of the edges of the clock signal.
>
> Bruce
>
> _______________________________________________
> time-nuts mailing list
> time-nuts at febo.com
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>
>   
Didier

Which just leaves the "minor" problem of synthesizing the required GPS 
receiver clock frequency from your 5 or 10MHz frequency standard.

Bruce




More information about the time-nuts mailing list