[time-nuts] TIC resolution impact on GPSDO's performance
Didier Juges
didier at cox.net
Thu Dec 28 02:15:40 UTC 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_lists.febo.com
mailing list