[time-nuts] TIC resolution impact on GPSDO's performance
Dr Bruce Griffiths
bruce.griffiths at xtra.co.nz
Thu Dec 28 01:06:02 UTC 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_lists.febo.com
mailing list