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

Didier Juges didier at cox.net
Wed Dec 27 21:15:40 EST 2006


Dr Bruce Griffiths wrote:
> 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
>
> _______________________________________________
> time-nuts mailing list
> time-nuts at febo.com
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>
>   
Bruce,

My point exactly, that's a lot of complexity, which surely can be solved 
at significant expense of hardware and development time.
I vote for the solution that simply does not require that expense (of 
hardware at least :-)

Didier


PS: I did not realize the GPS can use either edge of the clock to 
synchronize the PPS. Reduces the jitter by 2 for a given clock.



More information about the time-nuts mailing list