[time-nuts] TIC resolution impact on GPSDO's performance
didier at cox.net
Wed Dec 27 09:20:48 EST 2006
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.
More information about the time-nuts