GPSDO - Using a 10kHz instead of 1Hz pps - Page 1
Forum section: electronics / projects

author: tverbeure
author_rank: Regular Contributor
timestamp: December 21, 2022, 07:28:01 am
content: Hi all,In almost all PLL-based GPSDOs, a ublox unit is programmed to output pulses at a rate much higher than 1pps. I'm assumption is that this makes it much easier to create an analog phase comparator because with 1pps, you'll have to might have to deal with a very high time range while maintaining high precision? E.g. it would require a large dynamic range ADC?But I'm wondering if anyone has talked about the trade-off in terms of averaging out the jitter on the PPS signal. (Seehttps://www.pearl-hifi.com/06_Lit_Archive/15_Mfrs_Publications/20_HP_Agilent/HP_App_Notes-Handbooks/AN-162-01_Time_Interval_Averaging.pdf)Here's my calculation:* When using a 1Hz pps: A Ublox M8N has a jitter of ~17ns (1.7E-8). If you feed this into a perfect (no loss) analog phase comparator followed by a perfect ADC, and you measure for 1000 seconds, you get a standard deviation of 1.7E-8/2/sqrt(1000)=2.7E-10. In other words, you've increased the accuracy of PPS pulse from 17ns to 270ps. (FWIW: that still seems pretty high to me!)* When using a 10kHz pps: the jitter is still 17ns, but in 1000seconds, you can now do 10000 measurements, for a total of 10M measurements. The standard deviation for 1 measurement is: 1.7E-8/2/sqrt(10E6)=2.7E-12. However, that's the measurement for 1 10kHz period.If I want to do an apples to apples comparison an scale up the 10kHz result back to 1second, what number of I need to multiply the 2.7E-12 by? If I multiply by 10000, then I end up with 2.7E-8 or 27ns, which is worse than the jitter itself. That doesn't seem right? If I multiply by sqrt(10000) (why?), then I end up with the same 2.7E-10 as the 1Hz pps method. That seems a bit suspect as well? Any insights?

author: Gyro
author_rank: Super Contributor
timestamp: December 21, 2022, 09:34:41 am
content: Here's one I knocked together using a PLL and a ublox LEA-6T outputting 100kHz. The thread includes some words of wisdom from dear departed Lars...https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/

author: David Hess
author_rank: Super Contributor
timestamp: December 21, 2022, 03:04:21 pm
content: I do not think you gain anything in this case from phase locking to a 10kHz output instead of a 1Hz output, unless your phase detection is very coarse.The 10kHz output is only updated as each navigation/time solution is calculated, so it contains only as much information as the 1Hz output. Locking to the 10kHz output does provide better resolution from the phase detector, but the navigation/time error over such a short period of time, minutes to hours, contains errors greater than this.The time constant of the phase detector is minutes to hours, so locking to a higher frequency is irrelevant.Quote from: tverbeure on December 21, 2022, 07:28:01 amThe dynamic range requirements are not great because the divider producing the 1 PPS output can be "jammed" so that it is closely aligned with the 1 PPS signal. After that it should never be very far off.QuoteThe extra measurements made at a higher frequency are not independent because they all reflect the same navigation/time solution.

author: bson
author_rank: Unknown
timestamp: December 21, 2022, 03:44:23 pm
content: XOs tend to have extremely low jitter but drift in frequency over time. 1pps is long enough to keep them on frequency, and in many cases the phase detector can be a simple reciprocal counter.

author: bingo600
author_rank: Super Contributor
timestamp: December 21, 2022, 04:07:35 pm
content: I think most of the 10kHz "GPDSO's" are referring to the : James Miller design , where he used a Jupiter GPS , and an XOR - No MCU involved.http://jrmiller.online/projects/ministd/frqstd0.htmhttp://jrmiller.online/projects/ministd/frqstd.htmAccording to TVB it performed quite wellhttp://www.leapsecond.com/pages/gpsdo//Bingo

author: tverbeure
author_rank: Regular Contributor
timestamp: December 21, 2022, 06:39:39 pm
content: Quote from: David Hess on December 21, 2022, 03:04:21 pmI don't understand this part.QuoteRight. But the oscillator inside the ublox is independent from the satellite pps.My general question is not about whether or not, by increasing the rate, you get more core information per second (you don't), but whether or not, from a mathematical point of view, increasing the rate will increase or decrease the accuracy of the value that you're receiving.Let's take this to an extreme, where you only take measurements for 1 second. When you're in 1Hz mode, you get 1 measurement with a 17ns uncertainty interval and a standard deviation of 8.5ns if you fill it in the sigma=T/2/sqrt(N) formula. (Through the formula probably can't be used anymore because there are not enough samples.). If you're in 10kHz mode, you get 10000 measurements, with each measurement still having a 17ns jitter. After time averaging, the standard deviation is 85ps.10kHz corresponds to a period of 100us.In terms of precision, the 10kHz case has an inaccuracy ratio of 85ps/100us=8.5E-7. The 1Hz case has an inaccuracy of 8.5ns/1s = 8.5E-9. So by sampling 10k times, your relative precision has gone down by a factor of 100. Does that make sense?And so it make me question if the benefits of increasing the ublox pps rate outweigh the loss of accuracy.This is all in the context of trying to figure out mathematically how much pps data you need to gather to achieve a certain GPSDO precision.Quote from: Gyro on December 21, 2022, 09:34:41 amI've read a ton of GPSDO build pages or discussions, but I haven't seen the math behind it. If my reasoning above is correct (it may very well not be!), and you take 1 measurement per second for 1000 seconds, then, with a 17ns jitter, you get a 2.7E-10 standard deviation over 1 second. That should be *just* good enough if you want to make GPSDO that is 1ppb accurate, but not if you sample 10k per second if the precision is 100x lower. A factor of 100 would mean that you'd need 100k seconds to make your GPSDO stable enough, which is not reasonable.

author: iMo
author_rank: Super Contributor
timestamp: December 21, 2022, 07:59:20 pm
content: I think Miller's design is equivalent to any other design. The low pass after the XOR has a large time constant (I published an excel tool for the low pass design some time back) so even though the 10kHz (I used to use 20/40kHz too) would be updated once per second (frankly, I doubt it is done that way) it would be averaged thus the result will be the same. The main reason to use the XOR with ie. 10kHz is the simplicity of the design. Again, I am pretty confident the end result is the same..

author: David Hess
author_rank: Super Contributor
timestamp: December 21, 2022, 11:15:01 pm
content: Quote from: tverbeure on December 21, 2022, 06:39:39 pmWhen the system starts, the two PPS signals can start with any phase relationship, and if they are 180 degrees apart, then the time delay measurement will be 1/2 second, and it will take a long time to slew the oscillator and phase lock the two signals. When the two signals are not within the dynamic range of the time delay measurement, the counter which produces the 1 PPS signal from the oscillator can be "jammed" or reset to a specific value to force alignment and then the phase comparison will return a reasonable value.QuoteThat might work and would be suitable for receivers which do not provide the offset of each PPS pulse from true which can be added to the solution.It also should work if your time delay counter resolution is low, like 100 nanoseconds from a 10 MHz clock. I have plenty of non-interpolating universal counters which work that way to produce 100 or even 10 picosecond resolution from 100 nanosecond resolution using averaging.

author: tverbeure
author_rank: Regular Contributor
timestamp: December 22, 2022, 01:48:07 am
content: Quote from: David Hess on December 21, 2022, 11:15:01 pmAh, yes, that totally makes sense. My plan was, instead of jamming, to also lead the 2 pps pulses to a micrcontroller for coarse regulation until the pulses were close enough. But when you use the 1Hz pps as direct input into the fine regulation PLL, there's a bit of an issue for the case where the smoothed pulse comes earlier than the source pulse: you can't use the source pulse as set and the smoothed pulse as reset in that case. I have some ideas on how to work around that.In general, it surpises me that I can't find any GPSDO that has a dejittered PPS output. Is there just no need for that?QuoteDon't you need something like 25M samples to time interval average your way down from 100ns to 10ps? :-)

author: David Hess
author_rank: Super Contributor
timestamp: December 22, 2022, 10:59:41 pm
content: Quote from: tverbeure on December 22, 2022, 01:48:07 amOne of my counters supports 100,000 samples to average, and reciprocal counters can do more than that based on gate time.

author: MIS42N
author_rank: Frequent Contributor
timestamp: December 26, 2022, 10:39:28 am
content: To answer the "how many samples does it take to get a stability of 1ppb?". My GPSDO does not use a PLL. The processor measures the arrival time of the 1pps to the nearest 25ns. A correction to the control voltage is computed after a period, and from experiment a period of 512 seconds seems to work best. So basically the OCXO is allowed to run at (one assumes) constant frequency for 512 seconds, a correction is applied, the OCXO then runs at another frequency for 512 seconds. Because the system is always trying for perfect frequency, I make the assumption the frequency change is equal or greater than the frequency error. I don't have equipment to measure the frequency, but I do know the change in control voltage and I know the sensitivity of the OCXO to control voltage changes.One setup consistently delivers changes of less than 4 parts in 10^-11 (0.04 ppb). Recording every second for over 2 weeks. Using a non timing GPS module (NEO-7M).I conclude that 500 samples of 1 pulse per second is entirely adequate to reduce the effect of jitter to negligible levels with respect to a target of 1 part per billion. Results of using shorter periods indicate 100 samples is enough, even using the crude 25ns measurement, to stay within 1ppb.

author: Melt-O-Tronic
author_rank: Frequent Contributor
timestamp: December 29, 2022, 03:17:49 pm
content: tverbeure, you probably already recognize this, but at 1 Hz, an analog PLL is probably not going to work and you'll be routing through a microcontroller anyway to form a digital PLL.As far as "jamming" (which is a terribly confusing use of the word), I assume you'll be dividing down a 10 MHz oscillator to 1 Hz. If you use aPicDivto do that, some variations of it give you Arm and Sync pins for this purpose. So jamming becomes as simple as holding a pin low for 1 second if your phase comparator (time interval counter) is beyond its range.

author: MIS42N
author_rank: Frequent Contributor
timestamp: December 30, 2022, 12:47:43 am
content: Quote from: Melt-O-Tronic on December 29, 2022, 03:17:49 pmMy GPSDO microcontroller is a PIC16F1455. It is clocked by the OCXO (10MHz). That makes it very simple to "jam". Wait for a 1pps, start a timer. Just before 1 second is up, look for another 1pps.That isn't quite the way I implemented it. Timer 2 is set to wrap and interrupt every 250 cycles. 40,000 interrupts = 1 second. So software can "jam" the 40,000 count. The fine tuning comes from Timer 1 running at 40MHz and gated by the 1pps. Not bad for a $2 part.

author: tverbeure
author_rank: Regular Contributor
timestamp: January 03, 2023, 11:01:47 pm
content: Quote from: MIS42N on December 26, 2022, 10:39:28 amThat makes your solution an FLL instead of a PLL, right?This works if you're interested only in getting the frequency right (nothing wrong with that! It's what most people are shooting for), but it does mean that you don't compensate for sudden disruptions caused by things like a sudden temperature jump: it will only adjust Vctrl to set the output frequency back to where it needs to be but it will not adjust to correct for the earlier disruption. That's a problem if you have a system that relies on the correct number of pulses in the long term.QuoteNot sure what this means.When you calculate the next Vctrl, I assume that you use a deltaVctrl to deltaHz coefficient (from the xtal spec or through xtal characterization), and that you try to immediately hit the right target frequency without trying to edge towards it?QuoteBut you only change every 512s. So what you're recording every second are the raw number of whole 10MHz clock cycles?QuoteWith 500 samples and 20ns jitter, you reduce standard deviation on your 1 second measurement to 4.42E-10s or 442ps. How can this be reconciled with your 0.04ppb number?

author: MIS42N
author_rank: Frequent Contributor
timestamp: January 04, 2023, 03:53:55 am
content: Quote from: tverbeure on January 03, 2023, 11:01:47 pmI hadn't really thought too much about what sort of scheme it is, because it does not correct continuously but at discrete intervals and it is all done arithmetically. I guess it really is a form of phase locked loop because I compensate for both a frequency error and a phase error.Quote from: tverbeure on January 03, 2023, 11:01:47 pmYes, the deltaVctrl to deltaHz coefficient is characterised in what I term a calibration run. It determines the coefficient and a reasonable start value for Vctrl by deliberately mistuning 0.25Hz high and 0.25Hz low.As to the assumption - assume both frequency and phase are correct at the start of 512 seconds. At the end, if frequency didn't vary, phase is still correct. But if frequency changes, so does phase. The correction applied is to correct both - a change to get the right frequency, added to which is a change to correct the phase error. That additional change is in fact introducing a frequency error opposite to the detected error. E.g. if the frequency is a little low, then it is necessary to make it a little higher than 10MHz to get the phase error out. The difference between those two frequencies (the only thing I can measure) should be greater than the frequency error when it was a little low.The phase correction (increment of frequency) is designed to bring the phase error to zero at the end of the next 512 seconds.Quote from: tverbeure on January 03, 2023, 11:01:47 pmBecause the arrival of 1pps is timed to the nearest 25ns, the raw value is quarter cycles, not whole cycles. So a bit more accurate (and a good fit for a 22ns jitter. If the frequency and phase are OK, the 22ns jitter is all within the 25ns window. Drift by 4ns either side, some crop up as early or late).Quote from: tverbeure on January 03, 2023, 11:01:47 pmBecause that's the possible error at the start and end of a 512 second period [I assume your calculation is OK]. A bad case is 4.42E-10s at start of period (instead of 0) and 512-4.42E-10s at end of period. The measurement error is 512-8.84E-10s, an error of 1.73E-12 in measuring a 512 second period. Does that make sense?

author: tverbeure
author_rank: Regular Contributor
timestamp: January 05, 2023, 07:16:58 am
content: Instead of trying to reason my way out of this, I wrote a Python script that implements a reciprocal frequency counter, and then I run a bunch of simulations for different input values to see what kind of accuracy it gets.This immediately pinpointed a mistake in my assumptions.When you're counting the number of input pulses over a fixed time, you can either end up with a number that is Q or Q+1, depending on where the sampling window is located relative to the input. If you are making N measurements that areindependentfrom each other, then, statistically, the ratio of the number of Q vs Q+1 measurements will allow you calculate the input frequency with higher accuracy. But since there's luck involved, the it's possible that the ratio won't be quite what it needs to be.It's for this case of independent measurements that:accuracy=jitter/2/sqrt(number_of_measurements)My simulation shows that this is indeed the case.You can NOT use this formula when you have gapless time measurements, where the stop of the previous measurement is the start of the next one.In this case, each of the measurements will still end up with a number that is either Q or Q+1, but the measurements are not independent anymore. Except for the very first and the very last measurement, you're guaranteed that the ratio of Q and Q+1 results will be correct: when one measurement *just* ends up with Q pulses (because the next input pulse falls just outside that measurement window), then it's guaranteed that the next measurement will pick up that last pulse and that you'll end up with Q+1 pulses. (I'm assuming that everything is behaving perfectly, e.g. no jitter on the reference clock and so forth.)For this case, you get:accuracy=jitter/2/number_of_measurements(if we ignore that very first and very last measurement.)I think this explains why I couldn't reconcile some of the numbers that I saw earlier.

author: MIS42N
author_rank: Frequent Contributor
timestamp: January 05, 2023, 10:36:29 am
content: I will detail the method I use and you can run your stats on it. Although I said I measure over a period of 512 seconds, I actually use 2 successive 256 second accumulations of phase errors (i.e. the difference between the measured arrival time of a 1pps v the expected arrival time, in 25ns increments). So typically if there is no phase error the input is 0,0,0,0,0,0,0,0,0,0,0.... If there is a phase error it could be 1,1,2,1,1,1,2,1,2,1,... [dithering between 1 and 2 due to the jitter]. Or -3,-2,-3,-3.... Call those accumulations A and B.If there is no frequency error, A and B are equal. If there is a frequency error then it is (B-A)/262144 Hz (which for 10MHz is an error less than 1E-12). Why 262144? - first, A and B are accumulations, and to change that to an average phase error for each period divide by samples - 256. second, the phase change is over a period of 256 seconds, and a frequency error is phase change per second, so divide by 256 to get change per second. And because the measurement is in 1/4 cycles, divide by 4 to get cycles - 256*256*4 = 262144.If correcting for phase error, require the estimated errorat the end of the 512 seconds. The average phase error [in cycles] is (B+A)/2048 (there being 512 measurements in total, and converting from 25ns increments to cycles by dividing by 4) which is assumed to be the phase error at the middle of the period (i.e. 256 seconds ago). To get the estimated phase error at the end, have to apply the frequency error for 256 seconds. From the previous calculation, that was (B-A)/1024. Combining, the estimated error in cycles is (3B-A)/2048.This method takes advantage of jitter to randomise the input. The 1pps can vary ±25ns undetected. With cheap GPS modules, the determination of location may cause more than this deviation in its calculation. But introducing jitter almost guarantees that some readings will be 1 more or less than the GPS should have produced.