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

[Dr Bruce Griffiths]

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