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@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@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@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@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. _______________________________________________ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts