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
