[time-nuts] GPS 1PPS, phase lock vs frequency lock, design
How often Lady Heather gets a satellite position report depends upon the receiver type. It can range from every second to once per minute. - > (there seems to be some finite latency in LH's constellation reports, but I'm > not sure how much -- perhaps Mark will comment). ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design
Hi A little about the “why” of all this …. Few of us have ideal antenna locations. Even what we consider to be “really good” is still quite a ways from ideal. A concrete tower 50’ above everything else with a clear view of the sky down to zero degrees in every direction is “ideal”. Due to it’s location in view of the Rocky Mountains, NIST simply can’t put up an “ideal” antenna ….. (they have pointed this out a number of times …). If you are talking about a commercial product. The best guess is that it will be set up with an antenna location that is utter junk in some cases. There simply will not be any other location available. The result of this is that we get signals that come in from multiple paths. Each one has a delay associated with it. There is no antenna magic that will reject them all. Signal strength is *not* a good indicator in terms of multipath. Using a single satellite does not eliminate the problem. Since these mulitpath signals inherently are “at the wrong time”, they mess up the timing solution. They also mess up navigation. The receiver tries to deal with them as best it can. That process can be a bit random. Even the best signal you can get is still pretty low SNR. One would *assume* that the firmware makes decisions about how good a signal is and weights it accordingly into the solution. How accurate this process is (if it is even present) is unclear. There’s at least a couple of million lines of code going into that module. Sorting out what it all does …. yikes …. Bob > On Jun 3, 2019, at 2:55 AM, Charles Steinmetz wrote: > > I think you may be missing the most likely primary contributor. > > Each GPS receiver (and, thus, each GPSDO) tracks a constantly-changing > "constellation" of satellites. Each rx switches constellations as it sees > fit, depending on reception conditions as it sees them, and no two receivers > will track the same constellations, switching at the same time, even if they > are fed from the same antenna. Most GPS receivers switch constellations > quite frequently (at least several times per minute, sometimes much more > frequently) even with strong signals. At each switch, "GPS time" as computed > by each rx changes by a few nS (maybe more, depending on the quality of the > unit's "time solution" algorithms and the signal environment). You can see > this dynamically if you run each receiver into a separate instance of LH > (there seems to be some finite latency in LH's constellation reports, but I'm > not sure how much -- perhaps Mark will comment). > > So, for short tau (averaging times), there is quite a bit of jitter on each > receiver's time solution, which is *not* correlated between receivers even if > they are fed from the same antenna. (I.e., the jitter is almost all > differential, very little common-mode.) > > Of course, we already knew that raw GPS data at low tau has bad jitter > (compared to the jitter after averaging for 1000+ seconds, which is what we > think of naively as the precision of GPS), so all this should come as no > surprise). > > Some GPS receivers let you switch into "reduced switching" or even "single > satellite" modes, but this turns out to be much less helpful than you might > think with real-world signals. > > Hanging bridges can cause significant phase jumps, but they should be much > less frequent than most of the changes you are reporting. > > Best regards, > > Charles > > > ed wrote: > >> I think I have a setup that exemplifies this situation, and some >> anecdotes. A while back, I acquired two "identical" GPSDO boards, and >> boxed them up together, with common environment, power supply, and GPS >> signal via a splitter. I've mentioned this thing a couple of times here, >> and had planned to do some experimenting to see how they track each >> other, if crosstalk at the front-ends may have effects, etc. I haven't >> done any of this yet beyond looking at the relative phase of the 10 MHz >> outputs on a scope, over various periods from minutes to days. >> >> I had expected them to agree quite closely after enough running time, >> and be quite stable, but was disappointed. The phase drifts up and down, >> sometimes very, slowly, over an hour or so, and sometimes quickly, >> noticeable over a few minutes observation time. After some pondering on >> why identical units with the same GPS signal should drift like this, I >> realized that besides possible front-end interactions, and noise, that >> this was likely mostly from the sawtooth effect - the discreteness of >> phase comparison of the 1 PPS vs 10 MHz counting, and discreteness of >> OCXO tuning voltage via the DACs. They each responded differently, for a >> number of reasons. More time and voltage resolution would help, of >> course, but they will never perfectly agree, even in this idealized >> setup with identical units. Virtually identical, that is - there's no >> such thing as truly identical units,
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design
I think you may be missing the most likely primary contributor. Each GPS receiver (and, thus, each GPSDO) tracks a constantly-changing "constellation" of satellites. Each rx switches constellations as it sees fit, depending on reception conditions as it sees them, and no two receivers will track the same constellations, switching at the same time, even if they are fed from the same antenna. Most GPS receivers switch constellations quite frequently (at least several times per minute, sometimes much more frequently) even with strong signals. At each switch, "GPS time" as computed by each rx changes by a few nS (maybe more, depending on the quality of the unit's "time solution" algorithms and the signal environment). You can see this dynamically if you run each receiver into a separate instance of LH (there seems to be some finite latency in LH's constellation reports, but I'm not sure how much -- perhaps Mark will comment). So, for short tau (averaging times), there is quite a bit of jitter on each receiver's time solution, which is *not* correlated between receivers even if they are fed from the same antenna. (I.e., the jitter is almost all differential, very little common-mode.) Of course, we already knew that raw GPS data at low tau has bad jitter (compared to the jitter after averaging for 1000+ seconds, which is what we think of naively as the precision of GPS), so all this should come as no surprise). Some GPS receivers let you switch into "reduced switching" or even "single satellite" modes, but this turns out to be much less helpful than you might think with real-world signals. Hanging bridges can cause significant phase jumps, but they should be much less frequent than most of the changes you are reporting. Best regards, Charles ed wrote: I think I have a setup that exemplifies this situation, and some anecdotes. A while back, I acquired two "identical" GPSDO boards, and boxed them up together, with common environment, power supply, and GPS signal via a splitter. I've mentioned this thing a couple of times here, and had planned to do some experimenting to see how they track each other, if crosstalk at the front-ends may have effects, etc. I haven't done any of this yet beyond looking at the relative phase of the 10 MHz outputs on a scope, over various periods from minutes to days. I had expected them to agree quite closely after enough running time, and be quite stable, but was disappointed. The phase drifts up and down, sometimes very, slowly, over an hour or so, and sometimes quickly, noticeable over a few minutes observation time. After some pondering on why identical units with the same GPS signal should drift like this, I realized that besides possible front-end interactions, and noise, that this was likely mostly from the sawtooth effect - the discreteness of phase comparison of the 1 PPS vs 10 MHz counting, and discreteness of OCXO tuning voltage via the DACs. They each responded differently, for a number of reasons. More time and voltage resolution would help, of course, but they will never perfectly agree, even in this idealized setup with identical units. Virtually identical, that is - there's no such thing as truly identical units, and operating in identical conditions. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design (Bob kb8tq) (life speed)
I think I have a setup that exemplifies this situation, and some anecdotes. A while back, I acquired two "identical" GPSDO boards, and boxed them up together, with common environment, power supply, and GPS signal via a splitter. I've mentioned this thing a couple of times here, and had planned to do some experimenting to see how they track each other, if crosstalk at the front-ends may have effects, etc. I haven't done any of this yet beyond looking at the relative phase of the 10 MHz outputs on a scope, over various periods from minutes to days. I had expected them to agree quite closely after enough running time, and be quite stable, but was disappointed. The phase drifts up and down, sometimes very, slowly, over an hour or so, and sometimes quickly, noticeable over a few minutes observation time. After some pondering on why identical units with the same GPS signal should drift like this, I realized that besides possible front-end interactions, and noise, that this was likely mostly from the sawtooth effect - the discreteness of phase comparison of the 1 PPS vs 10 MHz counting, and discreteness of OCXO tuning voltage via the DACs. They each responded differently, for a number of reasons. More time and voltage resolution would help, of course, but they will never perfectly agree, even in this idealized setup with identical units. Virtually identical, that is - there's no such thing as truly identical units, and operating in identical conditions. Ed ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design (Bob kb8tq) (life speed)
Hi Ok > On May 31, 2019, at 4:48 PM, life speed via time-nuts > wrote: > > On Friday, May 31, 2019, 5:18:32 AM PDT, Bob kb8tq wrote: > > Hi > > One term you keep tossing up is “nominal phase coherence”. Typical GPS will > do “phase coherence” > at the 10 ns level to a fairly high degree of confidence (90 something > percent) with a number of > footnotes. You have never mentioned what your requirement is so it’s a bit > tough to know what > you are up against. If you are trying for “a couple of degrees at L band” > from 0.1 second on out, > GPS simply isn’t going to do that, no matter what you do. > > Bob > > Hi Bob, > As you know, phase coherence has bandwidth and noise floor. If you looked at > two VCOs phase-locked to a common 10MHz reference, they would be coherent > within the bandwidth of the PLL down to the in-band noise floor pedestal. > Beyond the bandwidth of the PLL they would not be coherent, and the in-band > phase coherence would have a noise floor as defined by the PLL architecture > and multiplied up reference noise. > So I guess by nominal phase coherence I am trying to say that two GPSDO > modules locked to the same GPS satellites (same physical location, probably > even the same external antenna - and by antenna I mean that in the classic > sense of the term, not GPS receiver) would exhibit phase coherence within a > very small bandwidth. From what we've discussed this would be tiny fractions > of a Hertz. > I understand that a GPS timing signal does not have the greatest jitter/phase > noise, which I think is what you meant by "10ns level to a fairly high degree > of confidence". But we've also discussed that GPS would be best used to > phase-lock a high-performance OCXO, where the PLL bandwidth is so low that > the crossover point is where the OCXO ADEV far-out in time (1,000 sec?) is > worse then the GPS. My goal would be, with such a correctly-implemented > system, to accomplish phase coherence within the BW of the PLL, which > admittedly might only be milliHertz. But if you displayed the 10MHz outputs > of 2 modules on an oscilloscope (or ran them into a mixer or any other method > of phase detection) they would be coherent. The phase noise at offsets > greater than a few milliHertz would of course not be coherent (correlated), > but that is not the requirement. I have other methods to implement > wide-bandwidth phase coherence when that is needed. You have two factors, one is the bandwidth of the loop. The other is the degree to which two identical GPS receivers track each other. In term of classic coherence, the units would be micro hertz rather than mili hertz. > One other term I've seen referenced is "navigation" vs. "timing" GPS > receivers, is this just the error/jitter in the PPS? TCXO vs. OCXO clocking > the receiver? > > You said: > "The TBolt simply takes out the need for a precision time measurement between > the PPS and the OCXO. They can do that because they builtthe receiver from > scratch." > It would seem this is somewhat along the lines of what I want to do. Not > necessarily build the RF receiver, but implement the code correction and > digital PLL to arrive at results more in line with a "timing" than > "navigation" receiver. A DIY receiver that “beats” a conventional off the shelf device likely involves custom ASIC’s. That’s not outside the range for a commercial project. It is a “couple of million” dollar sort of hit to the budget. Since timing and navigation are very much linked at the root of the system, there isn’t much you would do for a custom timing receiver that they don’t already do on the “timing” versions of the standard modules (and chip sets). More or less: If you are only making a couple thousand a year, modules are likely the most cost effective approach. Past that up into the couple thousand a month range, stock chip sets are probably your most effective solution. If you get into the tens of thousands per month, custom fiddling with stock chip sets comes in. At around a million a year, chip development is probably your best approach. Bob > Lifespeed > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design (Bob kb8tq) (life speed)
On Friday, May 31, 2019, 5:18:32 AM PDT, Bob kb8tq wrote: Hi One term you keep tossing up is “nominal phase coherence”. Typical GPS will do “phase coherence” at the 10 ns level to a fairly high degree of confidence (90 something percent) with a number of footnotes. You have never mentioned what your requirement is so it’s a bit tough to know what you are up against. If you are trying for “a couple of degrees at L band” from 0.1 second on out, GPS simply isn’t going to do that, no matter what you do. Bob Hi Bob, As you know, phase coherence has bandwidth and noise floor. If you looked at two VCOs phase-locked to a common 10MHz reference, they would be coherent within the bandwidth of the PLL down to the in-band noise floor pedestal. Beyond the bandwidth of the PLL they would not be coherent, and the in-band phase coherence would have a noise floor as defined by the PLL architecture and multiplied up reference noise. So I guess by nominal phase coherence I am trying to say that two GPSDO modules locked to the same GPS satellites (same physical location, probably even the same external antenna - and by antenna I mean that in the classic sense of the term, not GPS receiver) would exhibit phase coherence within a very small bandwidth. From what we've discussed this would be tiny fractions of a Hertz. I understand that a GPS timing signal does not have the greatest jitter/phase noise, which I think is what you meant by "10ns level to a fairly high degree of confidence". But we've also discussed that GPS would be best used to phase-lock a high-performance OCXO, where the PLL bandwidth is so low that the crossover point is where the OCXO ADEV far-out in time (1,000 sec?) is worse then the GPS. My goal would be, with such a correctly-implemented system, to accomplish phase coherence within the BW of the PLL, which admittedly might only be milliHertz. But if you displayed the 10MHz outputs of 2 modules on an oscilloscope (or ran them into a mixer or any other method of phase detection) they would be coherent. The phase noise at offsets greater than a few milliHertz would of course not be coherent (correlated), but that is not the requirement. I have other methods to implement wide-bandwidth phase coherence when that is needed. One other term I've seen referenced is "navigation" vs. "timing" GPS receivers, is this just the error/jitter in the PPS? TCXO vs. OCXO clocking the receiver? You said: "The TBolt simply takes out the need for a precision time measurement between the PPS and the OCXO. They can do that because they builtthe receiver from scratch." It would seem this is somewhat along the lines of what I want to do. Not necessarily build the RF receiver, but implement the code correction and digital PLL to arrive at results more in line with a "timing" than "navigation" receiver. Lifespeed ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design (Bob kb8tq)
Hi One term you keep tossing up is “nominal phase coherence”. Typical GPS will do “phase coherence” at the 10 ns level to a fairly high degree of confidence (90 something percent) with a number of footnotes. You have never mentioned what your requirement is so it’s a bit tough to know what you are up against. If you are trying for “a couple of degrees at L band” from 0.1 second on out, GPS simply isn’t going to do that, no matter what you do. Bob > On May 30, 2019, at 1:58 PM, life speed via time-nuts > wrote: > > 2. Re: GPS 1PPS, phase lock vs frequency lock, design (Bob kb8tq) > > Hi > > The TBolt is a very unique design. It directly uses code phase information > against the OCXO. The net result is really no different than the “correction > message” approach, but it is a different implementation. Since you can’t > *buy* the guts of a TBolt to strap into a DIY GPSDO, it’s not generally part > of a “I want to build a GPSDO from scratch” conversation. > > Bob > >> On May 29, 2019, at 9:50 AM, Alberto di Bene wrote: >> >> On 2019-05-29 14:53, Attila Kinali wrote: >>> The saw-tooth correction is the error of the PPS signal, as generated by >>> the hardware, and where it really should be. The clocks of most GPS >>> receivers >>> are in the order of 20-60MHz and are usually unsteered TCXOs (or even XO for >>> the cheap ones). Hence the granularity at which the PPS can be generated >>> is fixed. The saw-tooth correction gives you a higher accuracy (or removes >>> noise) from what you would get without. >> >> Am I correct if I suppose that the Trimble Thunderbolt, which uses the 10MHz >> OCXO as clock for the processor, does not need any saw-tooth correction ? >> >> TNX >> >> 73 Alberto I2PHD >> /<<< http://www.weaksignals.com >>>/ > Just to be clear, I am an electrical engineer working on a commercial new > product design, which already has a high-performance 10MHz OCXO as part of > the product. Although I realize much of this list is composed of DIY and > hobbyists, it has always been clear to me there are some smart people > participating in these discussions. I am in the investigation phase of a > feature enhancement to the product that is unfamiliar to me, hence my > questions. > Bob, > Would you care to elaborate on "directly uses code phase information against > the OCXO"? > I have noticed that a product my company is currently manufacturing uses a > "GPS receiver" containing a TCXO, which we then use the 1PPS to discipline a > low-end 100MHz OCXO. When I investigated the performance of our current > design it did not meet my requirement of nominal phase coherence of two > separate receivers. > It would seem that a GPS receiver containing an oscillator may not make sense > for a design that already contains a high-end 10MHz OCXO, rather the > implementation should use the oscillator that is already part of the design. > Lifespeed > > | > | > | | > time-nuts Info Page > > > | > > | > > | > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design
> 2) I think I understand this. Further I will have to understand what the > optimal PLL BW is in light of the OCXO short-term ADEV being potentially > better than GPS 1PPS with correction. Perhaps this means the loop BW should > be on the order of a milliHertz, if it takes 1000 seconds for the OCXO to > drift worse than the GPS. > 3) The nominal design uses a low-noise 16-bit > current output DAC, your point regarding LDAC to enable precision (in time) > updates to the output would enable a more-rigorously correct loop. I am > considering using two DACs, one scaled to the OCXO tune range of 5V or 10V, > one scaled with much smaller range to provide additional bits of resolution, > summed to provide the extra bits necessary. Does your sigma-delta modulator > comment apply to the numbers written to the traditional 16-bit DAC as a > dithering technique? I understand your comment regarding a direct > implentation of an SD 1-bit DAC, again dithering the digital input presumably > to "smear" quantization noise? Don't forget to consider the stability of your DAC. If it drifts slowly, the PLL will track the drift. But that's slow relative to the PLL bandwidth. If your PLL time constant is 1000 seconds, your room temperature probably changes faster than that. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design (Bob kb8tq)
Hi Without a deep dive into the physics of GPS, there is not a good way to demonstrate just *why* the solution is as bad as it is on a second to second basis. There is no magic “silver bullet” that will suddenly turn it from an ADEV of 1x10^-9 into an ADEV of 1x10^-13 at one second. The system ( Ionosphere, onboard clocks, orbits, transmitters, coding algorithm, signal to noise ….) just isn’t good enough. Given that 1 ns is *way* better than the spec it was designed against, you really can’t complain. Basics of GPS: 1) You lock on to at least 4 sats ( = find the carrier / work out the doppler) 2) You demodulate the spectrum spreading to get the code clock 3) You use the code clock to get the data 4) From the data you work out: a) What sat is it b) Where is it c) What time does it think it is 5) Based on all that you can figure out where you are and what time it is. When spread, the signals are *way* below the noise floor. Even after de-spreading they are not so great S/N in a pretty narrow bandwidth. What’s described above is not an easy task. Code phase simply means you are workin out time against the code clock. That’s what all the magic little brains do. The TBolt simply takes out the need for a precision time measurement between the PPS and the OCXO. They can do that because they built the receiver from scratch. Bob > On May 30, 2019, at 1:58 PM, life speed via time-nuts > wrote: > > 2. Re: GPS 1PPS, phase lock vs frequency lock, design (Bob kb8tq) > > Hi > > The TBolt is a very unique design. It directly uses code phase information > against the OCXO. The net result is really no different than the “correction > message” approach, but it is a different implementation. Since you can’t > *buy* the guts of a TBolt to strap into a DIY GPSDO, it’s not generally part > of a “I want to build a GPSDO from scratch” conversation. > > Bob > >> On May 29, 2019, at 9:50 AM, Alberto di Bene wrote: >> >> On 2019-05-29 14:53, Attila Kinali wrote: >>> The saw-tooth correction is the error of the PPS signal, as generated by >>> the hardware, and where it really should be. The clocks of most GPS >>> receivers >>> are in the order of 20-60MHz and are usually unsteered TCXOs (or even XO for >>> the cheap ones). Hence the granularity at which the PPS can be generated >>> is fixed. The saw-tooth correction gives you a higher accuracy (or removes >>> noise) from what you would get without. >> >> Am I correct if I suppose that the Trimble Thunderbolt, which uses the 10MHz >> OCXO as clock for the processor, does not need any saw-tooth correction ? >> >> TNX >> >> 73 Alberto I2PHD >> /<<< http://www.weaksignals.com >>>/ > Just to be clear, I am an electrical engineer working on a commercial new > product design, which already has a high-performance 10MHz OCXO as part of > the product. Although I realize much of this list is composed of DIY and > hobbyists, it has always been clear to me there are some smart people > participating in these discussions. I am in the investigation phase of a > feature enhancement to the product that is unfamiliar to me, hence my > questions. > Bob, > Would you care to elaborate on "directly uses code phase information against > the OCXO"? > I have noticed that a product my company is currently manufacturing uses a > "GPS receiver" containing a TCXO, which we then use the 1PPS to discipline a > low-end 100MHz OCXO. When I investigated the performance of our current > design it did not meet my requirement of nominal phase coherence of two > separate receivers. > It would seem that a GPS receiver containing an oscillator may not make sense > for a design that already contains a high-end 10MHz OCXO, rather the > implementation should use the oscillator that is already part of the design. > Lifespeed > > | > | > | | > time-nuts Info Page > > > | > > | > > | > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design (Bob kb8tq)
2. Re: GPS 1PPS, phase lock vs frequency lock, design (Bob kb8tq) Hi The TBolt is a very unique design. It directly uses code phase information against the OCXO. The net result is really no different than the “correction message” approach, but it is a different implementation. Since you can’t *buy* the guts of a TBolt to strap into a DIY GPSDO, it’s not generally part of a “I want to build a GPSDO from scratch” conversation. Bob > On May 29, 2019, at 9:50 AM, Alberto di Bene wrote: > > On 2019-05-29 14:53, Attila Kinali wrote: >> The saw-tooth correction is the error of the PPS signal, as generated by >> the hardware, and where it really should be. The clocks of most GPS receivers >> are in the order of 20-60MHz and are usually unsteered TCXOs (or even XO for >> the cheap ones). Hence the granularity at which the PPS can be generated >> is fixed. The saw-tooth correction gives you a higher accuracy (or removes >> noise) from what you would get without. > > Am I correct if I suppose that the Trimble Thunderbolt, which uses the 10MHz > OCXO as clock for the processor, does not need any saw-tooth correction ? > > TNX > > 73 Alberto I2PHD > /<<< http://www.weaksignals.com >>>/ Just to be clear, I am an electrical engineer working on a commercial new product design, which already has a high-performance 10MHz OCXO as part of the product. Although I realize much of this list is composed of DIY and hobbyists, it has always been clear to me there are some smart people participating in these discussions. I am in the investigation phase of a feature enhancement to the product that is unfamiliar to me, hence my questions. Bob, Would you care to elaborate on "directly uses code phase information against the OCXO"? I have noticed that a product my company is currently manufacturing uses a "GPS receiver" containing a TCXO, which we then use the 1PPS to discipline a low-end 100MHz OCXO. When I investigated the performance of our current design it did not meet my requirement of nominal phase coherence of two separate receivers. It would seem that a GPS receiver containing an oscillator may not make sense for a design that already contains a high-end 10MHz OCXO, rather the implementation should use the oscillator that is already part of the design. Lifespeed | | | | time-nuts Info Page | | | ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design
Hi The TBolt is a very unique design. It directly uses code phase information against the OCXO. The net result is really no different than the “correction message” approach, but it is a different implementation. Since you can’t *buy* the guts of a TBolt to strap into a DIY GPSDO, it’s not generally part of a “I want to build a GPSDO from scratch” conversation. Bob > On May 29, 2019, at 9:50 AM, Alberto di Bene wrote: > > On 2019-05-29 14:53, Attila Kinali wrote: >> The saw-tooth correction is the error of the PPS signal, as generated by >> the hardware, and where it really should be. The clocks of most GPS receivers >> are in the order of 20-60MHz and are usually unsteered TCXOs (or even XO for >> the cheap ones). Hence the granularity at which the PPS can be generated >> is fixed. The saw-tooth correction gives you a higher accuracy (or removes >> noise) from what you would get without. > > Am I correct if I suppose that the Trimble Thunderbolt, which uses the 10MHz > OCXO as clock for the processor, does not need any saw-tooth correction ? > > TNX > > 73 Alberto I2PHD > /<<< http://www.weaksignals.com >>>/ > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design
On 2019-05-29 14:53, Attila Kinali wrote: The saw-tooth correction is the error of the PPS signal, as generated by the hardware, and where it really should be. The clocks of most GPS receivers are in the order of 20-60MHz and are usually unsteered TCXOs (or even XO for the cheap ones). Hence the granularity at which the PPS can be generated is fixed. The saw-tooth correction gives you a higher accuracy (or removes noise) from what you would get without. Am I correct if I suppose that the Trimble Thunderbolt, which uses the 10MHz OCXO as clock for the processor, does not need any saw-tooth correction ? TNX 73 Alberto I2PHD /<<< http://www.weaksignals.com >>>/ ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design
On Wed, 29 May 2019 14:53:07 +0200 Attila Kinali wrote: > > 2) I think I understand this. Further I will have to understand what the > > optimal PLL BW is in light of the OCXO short-term ADEV being potentially > > better than GPS 1PPS with correction. Perhaps this means the loop BW > > should > > be on the order of a milliHertz, if it takes 1000 seconds for the OCXO to > > drift worse than the GPS. > > Usual time constants for OCXO based GPSDOs are in the order of a few 100s > to ~5000s. As a rule of thumb, you set the time constant to the cross > over point of the GPS ADEV[1] to the ADEV of your OCXO. At these time-scales > most people talk of time constant instead of BW of the loop, though it's > the same thing. Addendum: It's quite important here that you are aware what you optimize for. It makes a difference if you use ADEV or MDEV or HDEV. You will get different cross over point and thud different time constants. This is especially true, if you use something more complex than a first order PI loop. Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neal Stephenson ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design
On Tue, 28 May 2019 18:39:34 + (UTC) life speed via time-nuts wrote: > Attila, > Thanks for taking the time to respond and share your practical experiences in > this area. Your explanations are very helpful, I have a few more questions > if you don't mind: > 1) Would you elaborate on the "saw-tooth" correction, is this related to the > "correction" data made available by the GPS receiver that is in addition to > the 1PPS output, which apparently has limited accuracy by itself. The saw-tooth correction is the error of the PPS signal, as generated by the hardware, and where it really should be. The clocks of most GPS receivers are in the order of 20-60MHz and are usually unsteered TCXOs (or even XO for the cheap ones). Hence the granularity at which the PPS can be generated is fixed. The saw-tooth correction gives you a higher accuracy (or removes noise) from what you would get without. The u-blox timing appnote has a nice graph showing the distribution of the offset of the PPS with and without saw-tooth correction. > 2) I think I understand this. Further I will have to understand what the > optimal PLL BW is in light of the OCXO short-term ADEV being potentially > better than GPS 1PPS with correction. Perhaps this means the loop BW should > be on the order of a milliHertz, if it takes 1000 seconds for the OCXO to > drift worse than the GPS. Usual time constants for OCXO based GPSDOs are in the order of a few 100s to ~5000s. As a rule of thumb, you set the time constant to the cross over point of the GPS ADEV[1] to the ADEV of your OCXO. At these time-scales most people talk of time constant instead of BW of the loop, though it's the same thing. > 3) The nominal design uses a low-noise 16-bit current output DAC, your point > regarding LDAC to enable precision (in time) updates to the output would > enable a more-rigorously correct loop. I am considering using two DACs, one > scaled to the OCXO tune range of 5V or 10V, one scaled with much smaller > range to provide additional bits of resolution, summed to provide the extra > bits necessary. This would also work. > Does your sigma-delta modulator comment apply to the numbers written to the > traditional 16-bit DAC as a dithering technique? I understand your comment > regarding a direct implentation of an SD 1-bit DAC, again dithering the > digital input presumably to "smear" quantization noise? Yes. Exactly. > 5) When you refer to "timestamp PPS", is this the technique that is used to > extract extra resolution from the GPS signal at the receiver? Mostly I'm > following your (very helpful) descriptions, but some of this terminology is > new to me. time stamp as in "measure the arrival time of the PPS using the local clock (aka OCXO) as reference". It's the same as a phase detector, but using (relative) time as the measured value instead of (relative) phase. Attila Kinali [1] see e.g. http://www.leapsecond.com/pages/m12-adev/ -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neal Stephenson ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design
On Sunday, May 26, 2019, 7:24:31 AM PDT, Attila Kinali wrote: As you state that you are familiar with PLL design, I guess your confusion comes from having a 1Hz signal and trying to use that for a "normal" phase detector. While this is possible and can be done, it leads imediatly to the problems you have stumbled upon. The canonical way to do it, is instead measuring the arrival time of the PPS relative to a clock derived from the 10MHz. Ie you timestamp the PPS. Then you take the timestamp modulo 1 second and substract from it the setpoint value (can be 0 or anything else that makes your math easier), which then gives you the error or your control loop. Having the error value, you now can apply the digital PLL knowledge you have and design the loop filter. There are of course a few complications of the system: 1) You need to apply the saw-tooh correction to the measured PPS timestamp. Otherwise you get a spread in the order of 10ns and, much worse, "hanging bridges" 2) The systems sampling clock is 1Hz, which is unusual to most people who are used kHz or even MHz sampling rate digital loops. But the advantage is that it's so slow, that you can do all the calculations with minimal dead time, compared to the sampling period. Just keep in mind that everything has to have a sub-Hz bandwidth. 3) To achieve a decent frequency stability and low noise OCXO output, the DAC you use to control it needs to have at the very least 16bit (mostly DNL, but INL shouldn't change too much or too quickly, otherwise the loop becomes unstable). For one of my design, I calculated that I would need ~23bit for the stability I wanted, which poses a problem by itself. Luckily, having the DAC in the control loop simplifies things quite a bit. Using a 16bit DAC (eg AD5560 or AD5683R, the latter would be better suited for this application due to the LDAC pin) and using a delta-sigma modulator (at least 2nd order, better 4-8th order) should give you enough resolution to work with. Alternatively, a 1bit DAC using a high order delta-sigma modulator and an external D-FF (don't use one in the FPGA as the jitter from the FPGA would kill the resolution) would also work. Audio DACs don't work for this application as they have too much low-frequency noise (aka drift). 4) The filter after the DAC will require some good opamps. Even though using chopper/autozero opamps is tempting, I'd rather go for low flicker noise bipolar opamps (eg LT6018 or LTC6081, LT6010,...) as the loop will compensate for the drift of the opamp (given it's not too big). 5) The easiest way to timestamp PPS if you already have a FPGA is using a ring oscillator based TDC. There is code out there that works for Xilinx[1]. I have a port to Altera/Intel Cyclone4 lying around if you are interested. This will give you a resolution in the order of 100-200ps, which should be good enough for a GPSDO. The second way would be to implement a time-to-amplitude converter (the simplest, I am aware of, is the one in Nick Sayer's GPSDO[2]), but that is already quite a bit more effort in the analog domain than what a ring oscillator TDC would require. > I need the output of two of these units I design to have to be phase > coherent relative to each other. Your knowledge, experience and scholarly > references are welcome. There is not much out there on refernces that I could send you. Most of what I know I gathered from looking at other peoples GPSDOs and reading what they have done. An outdated summary of that can be found at [3]. Additional to this you will need good knowledge of digital PLL design, for which I recommend having a look at the standard books (e.g. Gardner[4] and Best[5]). How well you can get the GPSDOs synchronized depends a bit on the effort you spend on the receiver. Standard L1 receivers (of the same model with the same firmware) will be better than 10ns if they are not too far apart (a few 10km to maybe 100km). If you need better than 1ns, you will need an L1/L2 receiver and have to manually calibrate the offset of the receiver. HTH Attila Kinali [1] https://ohwr.org/project/tdc-core/wikis/home [2] https://hackaday.io/project/6872-gps-disciplined-xcxo [3] https://attila.kinali.ch/blog/2016/02/07/gps-disciplined-oscillator [4] "Phaselock Techniques", 3rd edition, 2015 by Floyd Gardner [5] "Phase-locked lopps", 6th edition, 2009, by Roland Best -- The bad part of Zurich is where the degenerates throw DARK chocolate at you. Attila, Thanks for taking the time to respond and share your practical experiences in this area. Your explanations are very helpful, I have a few more questions if you don't mind: 1) Would you elaborate on the "saw-tooth" correction, is this related to the "correction" data made available by the GPS receiver that is in addition to the 1PPS output, which apparently has limited accuracy by itself. 2) I think I understand this. Further I will have to understand what the optimal PLL BW is in
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design
Apologies, teletype did not let the picture through http://www.leobodnar.com/files/2x%20ECOC%203v6.png > I had half a dozen of 38.88MHz ones for tinkering. > There is nothing exciting about them apart from a noisy LDO which has peaking > around 70kHz. > Spurs are mine. > Leo ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design
On Sat, 25 May 2019 00:51:46 + (UTC) life speed via time-nuts wrote: > I want to discipline a 10 MHz OCXO with 1PPS from GPS. Obviously not an > unusual application, but I need to understand the methodology as I will not > be buying a module but rather implementing the design with an FPGA, off-the- > shelf GPS chip and a high-quality 10MHz DOCXO. > > One of the first questions I have: is it possible to implement phase-lock > with a narrow digital PLL and DSP integrator/filter in the FPGA? I suspect > some 1PPS disiplined OCXO implementations are merely controlled to the same > frequency, but not necessarily the same phase, depending on the details of > the implementation. As you state that you are familiar with PLL design, I guess your confusion comes from having a 1Hz signal and trying to use that for a "normal" phase detector. While this is possible and can be done, it leads imediatly to the problems you have stumbled upon. The canonical way to do it, is instead measuring the arrival time of the PPS relative to a clock derived from the 10MHz. Ie you timestamp the PPS. Then you take the timestamp modulo 1 second and substract from it the setpoint value (can be 0 or anything else that makes your math easier), which then gives you the error or your control loop. Having the error value, you now can apply the digital PLL knowledge you have and design the loop filter. There are of course a few complications of the system: 1) You need to apply the saw-tooh correction to the measured PPS timestamp. Otherwise you get a spread in the order of 10ns and, much worse, "hanging bridges" 2) The systems sampling clock is 1Hz, which is unusual to most people who are used kHz or even MHz sampling rate digital loops. But the advantage is that it's so slow, that you can do all the calculations with minimal dead time, compared to the sampling period. Just keep in mind that everything has to have a sub-Hz bandwidth. 3) To achieve a decent frequency stability and low noise OCXO output, the DAC you use to control it needs to have at the very least 16bit (mostly DNL, but INL shouldn't change too much or too quickly, otherwise the loop becomes unstable). For one of my design, I calculated that I would need ~23bit for the stability I wanted, which poses a problem by itself. Luckily, having the DAC in the control loop simplifies things quite a bit. Using a 16bit DAC (eg AD5560 or AD5683R, the latter would be better suited for this application due to the LDAC pin) and using a delta-sigma modulator (at least 2nd order, better 4-8th order) should give you enough resolution to work with. Alternatively, a 1bit DAC using a high order delta-sigma modulator and an external D-FF (don't use one in the FPGA as the jitter from the FPGA would kill the resolution) would also work. Audio DACs don't work for this application as they have too much low-frequency noise (aka drift). 4) The filter after the DAC will require some good opamps. Even though using chopper/autozero opamps is tempting, I'd rather go for low flicker noise bipolar opamps (eg LT6018 or LTC6081, LT6010,...) as the loop will compensate for the drift of the opamp (given it's not too big). 5) The easiest way to timestamp PPS if you already have a FPGA is using a ring oscillator based TDC. There is code out there that works for Xilinx[1]. I have a port to Altera/Intel Cyclone4 lying around if you are interested. This will give you a resolution in the order of 100-200ps, which should be good enough for a GPSDO. The second way would be to implement a time-to-amplitude converter (the simplest, I am aware of, is the one in Nick Sayer's GPSDO[2]), but that is already quite a bit more effort in the analog domain than what a ring oscillator TDC would require. > I need the output of two of these units I design to have to be phase > coherent relative to each other. Your knowledge, experience and scholarly > references are welcome. There is not much out there on refernces that I could send you. Most of what I know I gathered from looking at other peoples GPSDOs and reading what they have done. An outdated summary of that can be found at [3]. Additional to this you will need good knowledge of digital PLL design, for which I recommend having a look at the standard books (e.g. Gardner[4] and Best[5]). How well you can get the GPSDOs synchronized depends a bit on the effort you spend on the receiver. Standard L1 receivers (of the same model with the same firmware) will be better than 10ns if they are not too far apart (a few 10km to maybe 100km). If you need better than 1ns, you will need an L1/L2 receiver and have to manually calibrate the offset of the receiver. HTH Attila Kinali [1] https://ohwr.org/project/tdc-core/wikis/home [2] https://hackaday.io/project/6872-gps-disciplined-xcxo [3] https://attila.kinali.ch/blog/2016/02/07/gps-disciplined-oscillator [4] "Phaselock Techniques", 3rd edition, 2015 by Floyd Gardner [5] "Phase-locked
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design
I had half a dozen of 38.88MHz ones for tinkering. There is nothing exciting about them apart from a noisy LDO which has peaking around 70kHz. Spurs are mine. Leo On 25 May 2019, at 17:00, Gerhard Hoffmann wrote: > Has anybody out there more information about this oscillator? > Its data sheet is thinner than a cookbook from the Sahel zone. > No phase noise data @ 100 MHz??? I've got one of them last week. > https://www.digikey.de/products/de?keywords=xc2265-nd > regards, Gerhard ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] GPS 1PPS, phase lock vs frequency lock, design
Am 25.05.19 um 02:51 schrieb life speed via time-nuts: Hi all, it's been a while since I visited. I am venturing into an unfamiliar area from my usual low phase noise PLL, OCXO and microwave synthesizer design endeavors. I recall there are some knowledgeable, well, time nuts on this list and hope you'll indulge some questions and maybe direct me to some appropriate white papers and share insights. I want to discipline a 10 MHz OCXO with 1PPS from GPS. Obviously not an unusual application, but I need to understand the methodology as I will not be buying a module but rather implementing the design with an FPGA, off-the-shelf GPS chip and a high-quality 10MHz DOCXO. One of the first questions I have: is it possible to implement phase-lock with a narrow digital PLL and DSP integrator/filter in the FPGA? I suspect some 1PPS disiplined OCXO implementations are merely controlled to the same frequency, but not necessarily the same phase, depending on the details of the implementation. I need the output of two of these units I design to have to be phase coherent relative to each other. Your knowledge, experience and scholarly references are welcome. Thanks, Lifespeed Hi, I have a new release of my OCXO support board on the backburner. it will provide -a home for HP10811A, MTI-260, Morion MV89, a 100 MHz SC cut oven (Digikey XC2265-ND) and some others. - Locking on incoming 10 MHz, - Locking on incoming 1pps - free running adjusted from 10 turn pot - generation of 1pps from onboard oscillator - frequency doubler 5 to 10 MHz (or undoubled, or other frequencies) - dBm measurement of incoming reference frequency Gone from version 1 are: - some voltage regulators - ring mixer as phase detector, driver amplifiers etc. - Picdiv ( there were complaints that I didn't have it, but when I put it on the board, nobody was interested. ) - the "Wenzel" style squarers ( I have seen that in a previous life in a frequency counter by HEB when 74S was bleeding edge, and in every other text book.) The LT6??? does that in 5*5 mm. The phase comparator is now a 3 states FlipFlop comparator in a Xilinx Coolrunner II CPLD. That also makes the 1pps from most common oscillator frequencies. Freq and OCXO tuning direction are jumper selectable. The integrator is a JFET op amp and a foil capacitor. VHDL sources are abt. 4 pages; 64 FlipFlops max. make sure that it won't grow without limit. Sources & layout will be open in BSD license style (basically: do with it what you want but don't bite the feeding hand). Pics of the status quo: old board with rucksack for the alternative oscillators and patches, new layout in statu nascendi. Flickr has some problems because they are moving to a new server farm, so I leave it in the upload stream. https://www.flickr.com/photos/137684711@N07/47929260287/in/dateposted-public/ Has anybody out there more information about this oscillator? Its data sheet is thinner than a cookbook from the Sahel zone. No phase noise data @ 100 MHz??? I've got one of them last week. https://www.digikey.de/products/de?keywords=xc2265-nd regards, Gerhard ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] GPS 1PPS, phase lock vs frequency lock, design
Hi all, it's been a while since I visited. I am venturing into an unfamiliar area from my usual low phase noise PLL, OCXO and microwave synthesizer design endeavors. I recall there are some knowledgeable, well, time nuts on this list and hope you'll indulge some questions and maybe direct me to some appropriate white papers and share insights. I want to discipline a 10 MHz OCXO with 1PPS from GPS. Obviously not an unusual application, but I need to understand the methodology as I will not be buying a module but rather implementing the design with an FPGA, off-the-shelf GPS chip and a high-quality 10MHz DOCXO. One of the first questions I have: is it possible to implement phase-lock with a narrow digital PLL and DSP integrator/filter in the FPGA? I suspect some 1PPS disiplined OCXO implementations are merely controlled to the same frequency, but not necessarily the same phase, depending on the details of the implementation. I need the output of two of these units I design to have to be phase coherent relative to each other. Your knowledge, experience and scholarly references are welcome. Thanks, Lifespeed ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
