I have ordered a Lucent RFTG-M-XO box but it has yet to arrive -

David I. Emery said the following on 12/27/2006 01:21 AM: > 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. It's possible that the receiver on the Lucent board (the guts of which were made by Efratom, by the way) is externally clocked, but I don't think so. The only connectors on the GPS are the standard 5x2 header for power and I/O, and the coax antenna connector. John

It is my understanding that the Motorola Oncore timing receiver

And if my presumption is correct that the Trimble Thunderbolt

I have ordered a Lucent RFTG-M-XO box but it has yet to arrive -

There is certainly no reason to integrate a GPS receiver with

And as a final note - a Datum 9390 box I have that dates to

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

It is my understanding that the Motorola Oncore timing receiver

And if my presumption is correct that the Trimble Thunderbolt

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. > > I have found internal pictures of the 58540A receiver at http://www.realhamradio.com/58540A.htm The spec/manual is available from tvb's web site (found it through google...) It is interesting that the Thunderbolt and the 58540A have pretty much exactly the same dimensions and interface connectors, have both an 8 channel receiver yet look completely different internally. Also, the 58540A review linked above says the 58540A does not support some of the features that are available on the Thunderbolt, such as timing error which is available on the TB. The locked spec is similar, with the 20nS 1 sigma. The holdover is specified quite differently though, +/-1 uS in 2 hours for the TB and 100 uS/hour for the HP, that's worlds apart!!! Of course, the software interface is totally incompatible, with the TB using T-SIP and HP using SCPI. Didier

It is my understanding that the Motorola Oncore timing receiver

And if my presumption is correct that the Trimble Thunderbolt

I have ordered a Lucent RFTG-M-XO box but it has yet to arrive -

There is certainly no reason to integrate a GPS receiver with

And as a final note - a Datum 9390 box I have that dates to

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

It is my understanding that the Motorola Oncore timing receiver

And if my presumption is correct that the Trimble Thunderbolt

I have ordered a Lucent RFTG-M-XO box but it has yet to arrive -

There is certainly no reason to integrate a GPS receiver with

And as a final note - a Datum 9390 box I have that dates to

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

It is my understanding that the Motorola Oncore timing receiver

And if my presumption is correct that the Trimble Thunderbolt

I have ordered a Lucent RFTG-M-XO box but it has yet to arrive -

There is certainly no reason to integrate a GPS receiver with

And as a final note - a Datum 9390 box I have that dates to

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

It is my understanding that the Motorola Oncore timing receiver

And if my presumption is correct that the Trimble Thunderbolt

I have ordered a Lucent RFTG-M-XO box but it has yet to arrive -

There is certainly no reason to integrate a GPS receiver with

And as a final note - a Datum 9390 box I have that dates to

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 > Bruce, I understand that there are ways around the problem, but in a conventional GPSDO, this correction can only happen after the 1 PPS has been generated, after the fact if you will, and from there you can phase lock a precise 10 MHz OCXO from which you can derive yet another (jitter-free) PPS signal for other uses. In the Thunderbolt, this correction is simply not needed, and the PPS is organically free of this particular type of jitter, which really is an artifact due to the architecture. It just seems the integrated architecture gets rid of a lot of artificial baggage and complexity. I understand that the vastly larger part of the GPS market is for consumer navigation systems, for which the PPS is not used (maybe not even generated in hardware, why bother? who needs sub-second timing accuracy in a car?), and economies of scale may make it attractive for timing people to use the mass produced navigation hardware and patch around the issues, but in this case, the cost savings associated with the simplification may offset the amortization of the development costs and the increased manufacturing costs due to smaller quantities of integrated, strictly timing receivers/GPSDO. Interestingly, the Fury GPSDO seems to use an off-the-shelf Motorola GPS receiver, yet achieves good performance at low cost, in an even smaller package than the Thunderbolt and with half the power consumption (let's ignore the 6 or 7 years difference between they birth dates...) They advertise a price of $750 in small quantities (someone told me a few days ago he had been quoted $1450 for a new Thunderbolt GPSDO.) The Fury gives you the choice of GPS PPS and OCXO PPS, that's nice, but it shows that the GPS PPS is generated, so I suspect the Fury may be subject to sawtooth correction and hanging bridges. Maybe Said can enlighten us on that. Anyway, as always, I have seriously enjoyed that thread! Thanks Didier

It is my understanding that the Motorola Oncore timing receiver

And if my presumption is correct that the Trimble Thunderbolt

I have ordered a Lucent RFTG-M-XO box but it has yet to arrive -

There is certainly no reason to integrate a GPS receiver with

And as a final note - a Datum 9390 box I have that dates to

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.

It is my understanding that the Motorola Oncore timing receiver

And if my presumption is correct that the Trimble Thunderbolt

I have ordered a Lucent RFTG-M-XO box but it has yet to arrive -

There is certainly no reason to integrate a GPS receiver with

And as a final note - a Datum 9390 box I have that dates to

Didier Juges 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 >> >> > Bruce, > > I understand that there are ways around the problem, but in a > conventional GPSDO, this correction can only happen after the 1 PPS has > been generated, after the fact if you will, and from there you can phase > lock a precise 10 MHz OCXO from which you can derive yet another > (jitter-free) PPS signal for other uses. In the Thunderbolt, this > correction is simply not needed, and the PPS is organically free of this > particular type of jitter, which really is an artifact due to the > architecture. > > It just seems the integrated architecture gets rid of a lot of > artificial baggage and complexity. > > I understand that the vastly larger part of the GPS market is for > consumer navigation systems, for which the PPS is not used (maybe not > even generated in hardware, why bother? who needs sub-second timing > accuracy in a car?), and economies of scale may make it attractive for > timing people to use the mass produced navigation hardware and patch > around the issues, but in this case, the cost savings associated with > the simplification may offset the amortization of the development costs > and the increased manufacturing costs due to smaller quantities of > integrated, strictly timing receivers/GPSDO. > > Interestingly, the Fury GPSDO seems to use an off-the-shelf Motorola GPS > receiver, yet achieves good performance at low cost, in an even smaller > package than the Thunderbolt and with half the power consumption (let's > ignore the 6 or 7 years difference between they birth dates...) They > advertise a price of $750 in small quantities (someone told me a few > days ago he had been quoted $1450 for a new Thunderbolt GPSDO.) The Fury > gives you the choice of GPS PPS and OCXO PPS, that's nice, but it shows > that the GPS PPS is generated, so I suspect the Fury may be subject to > sawtooth correction and hanging bridges. Maybe Said can enlighten us on > that. > > Anyway, as always, I have seriously enjoyed that thread! > > Thanks > > Didier > > > > _______________________________________________ > time-nuts mailing list > time-nuts@febo.com > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > Didier Yes, using an integrated high stability oscillator in the GPS receiver provides all the local oscillator signals etc, and is "locked" to the GPS signals eliminates the external TIC that would otherwise be required. Some of the more expensive early GPS receivers used 10.23MHz OCXOs for this purpose. 1575.42 = 154 x 10.23 1227.6 = 120 x 10.23 The drawback is that the short term frequency stability is limited to that of the oscillator chosen by the manufacturer, if one happens to have an oscillator (HP10811, HP10544, FTS1200, OSA 8607, etc.)with better short term stability one can do better. The OCXO used in the Thunderbolt doesn't appear to have great short term stability specifications. It appears to be worse (100X??) than just about any variety of HP10811 for example. It appears to be (1000x ??) worse than an FTS1200, FTS1000, or an OSA 8607. To use an external oscillator in the way I indicated, one has to modify a standard M12+, M12M timing receiver to allow using an external oscillator. I'm not sure that this is possible though it is likely. Bruce

From: Dr Bruce Griffiths <bruce.griffiths@xtra.co.nz> Subject: Re: [time-nuts] TIC resolution impact on GPSDO's performance Date: Thu, 28 Dec 2006 17:33:19 +1300 Message-ID: <4593490F.5000007@xtra.co.nz> > Didier > > Yes, using an integrated high stability oscillator in the GPS receiver > provides all the local oscillator signals etc, and is "locked" to the > GPS signals eliminates the external TIC that would otherwise be > required. Some of the more expensive early GPS receivers used 10.23MHz > OCXOs for this purpose. > 1575.42 = 154 x 10.23 > 1227.6 = 120 x 10.23 > > The drawback is that the short term frequency stability is limited to > that of the oscillator chosen by the manufacturer, if one happens to > have an oscillator (HP10811, HP10544, FTS1200, OSA 8607, etc.)with > better short term stability one can do better. > > The OCXO used in the Thunderbolt doesn't appear to have great short term > stability specifications. > It appears to be worse (100X??) than just about any variety of HP10811 > for example. > It appears to be (1000x ??) worse than an FTS1200, FTS1000, or an OSA 8607. > > To use an external oscillator in the way I indicated, one has to modify > a standard M12+, M12M timing receiver to allow using an external oscillator. > I'm not sure that this is possible though it is likely. It should be possible. I'll flipp my M12M over and check. Bjorn and I have a little project going where we use the CNC Allstar receivers. They have the specific feature that their referens XO is at 10 MHz. This will make it very easy to drop in a suitable oscillator. As it happends I see that a FTS1200 and an Allstar receiver has showed up in my main rack during some unexplainable appearance in the lab yeasterday. It is not as much the ability too hook it up as getting the receiver time to EFC solution into place. I'm working on that right now, but it will involve a little bit of wizardy. The Allstar receivers have about 1 cm RMS of carrier noise which should show up as about 33 ps RMS noise. It should be an interesting proof of concept thing. Cheers, Magnus