First of all, the time-nuts people can give you much higher quality advice that I can: www.leapsecond.com/time-nuts.htm to get started. I did a bunch of work with NTP (the Network Time Protocol) years ago; I was one of the authors of the UNIX reference implementation to validate that the protocol spec was complete enough to do a from-scratch implementation. The NTP implementation tried to solve two problems - how to determine clock offset and round-trip latency to other reference sources on the internet, and the algorithms used to filter those samples and select the best candidate synchronization source - you don't have this problem since you have the GPS receiver already there. The other half of the problem was correcting and maintaining the clock on the local computer. But this really was about implement this abstract clock model on the OS, where you got to tweak the timekeeping. Most computers have some timekeeping interrupt that fires every so many milliseconds, and by default, you add that many milliseconds to the local time in the interrupt service routine and move along. Then when a program wants to know what time it is, you look at the software counter and maybe read some hardware register so some math and return the answer. What NTP (and the OS) tried to do was to maintain a phased locked loop, corrected by the phase error by way of the samples being taken. The loop filter of the PLL got "tighter" as you got closer to the right time. Also the polling intervals became longer to be able to both resolve the phase error and hopefully reduce the impact of the jitter associated with the measurements (in this case, packet arrival times). Since you were timestamping the packets arriving with the same clock you were gently slewing, you could only adjust the clock so fast.. There are parallels to your work - I think that maybe as you get closer to synchronizing the phase of the TCXO with the 1PPS output, you might want to do this over successively smaller longer intervals as you get closer. This might also have the effect of mitigating some of the sawtooth jitter on the 1PPS signal. The sawtooth probably exists for the same reason you'll have sawtooth phase error in your 10MHz - because you need to adjust at a resolution below 1 bit of DAC resolution. So maybe this is something to implement in the FPGA - both the longer measurement interval as well as some virtualized tuning value that gets turned into a series of alternating DAC values over some interval. I suppose this comes down to how much phase noise on the 10MHz output you're willing to tolerate. I'm way beyond my depth in the advice on your hardware implementation since my experience 25 years ago (more?) with was the software analog of all this. Speaking of analog, the introduction of analog components to measure the phase error seems like another opportunity to fight temperature effects.. When I did my NTP implementation, one of the results computed was the intrinsic frequency error of the local (really shitty crystal) oscillator in my computer. It was really easy to measure the temperature of my office once by looking at this computed frequency error once I calibrated it. It was, as you might expect, somewhat linear. The real reason for the computed frequency error was to implement holdover should the computer lose its network connectivity to its synchronization sources. So many words, maybe some of them are helpful to you. Really interesting work to follow along with. You're entering a dangerous area of precise time and frequency mental illness. Proceed with caution.
The PLL approach is interesting (for clock synchronization), but I think only workable, with the challenges of locking and then correcting as you have mentioned, if you have an accurate standalone 10MHz OCXO (as the main uncorrected source), then use a Neo-M9N (GPS) Module programmed for a GPS referenced oscillator output of 10MHz, then have a heavy filtered PLL to correct the OCXO output when the GPS source is available. If the GPS source is lost then the circuit would revert back to the OCXO source. I am not exactly sure how to do the above without doing some bread boarding circuit tests, and I see two problems the first is the GPS source clock jitter at 10MHz (which I believe is not an even subdivision of the GPS sync signal, that is a fractional divide) and how this would effect the actual 10MHz synchronized output, so you may want to have add a divide by ten in the PLL loop for a corrected output 1MHz as your true reference, but the delays through the clock chain should be kept to a minimum, which would mean a very fast edge rate logic family. And you I agree that in experimenting with this topic the engineer may suffer from precise time phobias given the problem is just not knowing the true time but then how and when to correct the time used by the system.
@@windward2818 I think that if you had an OXCO, you could ignore the the 10MHz output from the GPS receiver, and then instead discipline the OXCO by using the 1PPS output over long intervals. This would take the form of some control loop ultimately tweaking some D/A converter that's pushing on the OXCO. If you loose GPS lock (and presumably the 1PPS output), then you can continue to apply the same frequency correction with your D/A output until your synchronization source returns. This was essentially what my UNIX NTP implementation did years ago (and in a similar fashion these days, with improved kernel support.) You compute some frequency error and keep applying that correction even in the absence of a synchronization source. Years ago, that got done with periodic UNIX adjtime() system calls applying a correction; these days there are better kernel facilities to do that and much of this logic is inside the kernel.. For bonus points and for the extra paranoid, you could try to model the frequency error that you're correcting against ambient temperature and continue to apply that when free running. You'd think this should be small for an OXCO.
I am in the middle of building two GPSDOs as well using some Ublox NEO-6T GNSS receivers that I have left over from a project. I assume that you know that the TIMEPULSE output does not have to run at 1PPS? I think some of your architecture problems are related to having to manage both frequency and phase. If you reprogram the TIMEPULSE output to generate 10, 25, 50 or 100KHz and use a simple hardware divider on the output of the 10MHz OXCO then you can simplify the architecture and deal with just phase measurement/phase locking of two sources that are already inside the same frequency capture range. There are 'all analogue' designs that use a Type 1 phase comparator to compare the divided down OXCO against the (faster) TIMEPULSE and achieve very good performance with relatively simple two-pole low pass filters. There are other implementations that move to the digital domain and employ an MCU which is directly clocked from the 10MHz OXCO and takes a 10KHz (or similar) reference clock to a timer/counter input programmed to generate IRQs and use an algorithm to resolve the difference between hardware time (from GNSS) and software time (from CPU clock, clocked by the variable OCXO) and generate the tuning voltage either via 16-bit PWM or a 16-bit DAC. None of these solutions needs an FPGA since the solution can be implemented entirely in the analogue domain or in the software domain. The advantage of the software domain is that you can implement things like stored values for faster start-up, compensation for long-term ageing, hold-over, real-time status display, alarms, NTP server, IEEE-1588, etc.
Truly nice! The idea of pulse width to voltage conversion is really well done. I'll be posting the project of a gpsdo I'm design also. My idea is to use a free running crystal oscillator as an "phase counter" that counts the phase different between the VCO and the gps 1pps. My idea is that an uncorrelated phase counter will result in greater frequency resolution as jitter would help to oversample the signal phase difference.
Thank you for this video, I found it interesting. One thing to watch for on the non-timing GPS modules is they will vary the reported altitude more to adjust for what should be timing changes. This will add some error to your measurements. The Neo-M8T also reports the quantization error in its PPS output ($PUBX or UBX-TIM-TP messages), which will be in the nanosecond range. I think you've gone with a frequency counter design, you might also want to consider a time interval counter design.
Nice to see some VHDL coding. I have played with PIC and gps trying to discipline the timer in the pic.. For educational purposes. The regulation loop with adjusting by +-1 worked only when the frequency was close to the 1pps, but since i didn't have a 1pps signal I used the uart signal, some one shot conditioning of it and in on a capture pin on the PIC. Turned out it was very jittery, perhaps because of the realtime OS... Anyway it was fun, and RomanBlack had and still has many fun projects on his website. He also talked about how he could see the oscillator (counted by the pic) change only by moving next to it 🙂
I've actually done a project rather similar to this. I abused the fact that my MSP430F2274 has hardware latched capture/compare registers(I'm sure many others do also), and used the GPS 1pps to latch a hardware/software counter that overflowed for the MSBs, then made sure I was counting 10M cycles in total, it worked surprisingly well.
I think i'd add cutouts around the oscillator wide enough to get some foam through and have foam back and front, and thermal isolation from the rest of the pcb.
Definitely needed, it really doesn't take much to cause this oscillator to drift. If I can find some double oven oscillators I might use those instead, otherwise I'll 3D print something that I can fill with insulation and clamp it around the board. Thanks
Hi, the ublox neo can output other frequencies then 1 pps . are other frequencies as accurate as the 1 pps? i measured 24mhz from the internal ublox crystal oscillator(under the lid) so a 12mhz should be a complete divide by 2 . can you please measure the 12mhz output without gps lock and with the gps lock and compare the two?
If you want to sample at 400 MHz in the FPGA, you don't need to count the entire 24 bit at 400 MHz. You can just take 4 samples at 400 MHz and then transfer those 4 bits to the 100 MHz clock domain. You can then see if there was a transition and if there was a transition see at which clock edge it was. You can even use DDR flip-flops at 400 MHz to increase the sample rate to 800 MHz while having a single 400 MHz clock. An advantage of sampling with just one clock is that the "jitter" between the samples is much lower since the signal does not follow different paths for the different samples. Especially if the tooling can map the DDR register in a IO block.
The UBLOX module allows as output clock all factors of 24MHz. So 1MHz, 2MHZ, 3MHz, 4MHz are avail with low jitter. 10MHz is not an integer factor of 12MHz and therefore has a lo of jitter. Why not make a PLL comparing the UBLOX 1MHz with the 10MHz VCO (divided by 10)?
I created a phase-frequency detector to lock a 10 MHz to 10 kHz from a Jupiter GPS. I use the FPGA to read the frequency with the 1PPS, that gets a course lock, and then pass over to the phase-frequency detector.
This subject is rather complex for me but its great to hear your thoughts on it. Thanks for sharing and good luck with this protect. Also I would like to see some episodes on the firmware creation , I think you would explain the process really well as your going along.- just my thoughts :)
The NEO-M8T is a really interesting receiver as it can output raw pseudo ranges and carrier phases... a good candidate for sub-cm differential surveying (I used to play with Motorola Oncore for this)... anyway... the project is getting interesting! In my limited understand the PPS is asynchronous to the GPS clock (it tries its best but it runs separately) so you need TIM-TP message to adjust the phase or long averaging. You should also fix the position so the receiver only has to solve for time. I'm very jealous of the hotplate... that seems such a good toy.
The hotplate worked really well! I was impressed with it. I'm reading up on the M8T - it looks like it can do a lot for you to give the best results, but the datasheet is a little vague in places so more reading up needed
Just to make sure I have this right - The goal is to simply produce an accurate 10MHz. The standard, datum or reference for the entire system is the 1PPS from GPS but it suffers from jitter. So overtime we know that once averaged the 1PPS are extremely close to "1PPS" and we use this fact to gently discipline the OCXO overtime, which over time produces a stable 10MHz sinewave. I think that's what you said but I loose track of which is the true reference, in this case 1PPS, but then the 10MHz becomes a useable reference.
Basically yes, the 1pps is entirely accurate over time, but suffers from several forms of jitter. The idea is to get the 10 MHz as near as possible to this 1pps but essentially eliminate the jitter from appearing on the 10 MHz. Long time constants and lots of statistics are used to get there. In real terms, the only time where the jitter is likely to be a problem for measurements is where you have this feeding the reference input into a spectrum analyser. Counters and signal generators are unlikely to need the same performance.
You don't actually need a large number of bits in your counter. For example, if you are counting at 1GHz (that would be nice!) and your OCXO is no more than 10ppm off, then a 15 bit counter is sufficient to count the interval between 1pps signals (since 1GHz times 10ppm is 10,000, so you need to be able to count to at least twice that). Such a counter will roll over more than 30,000 times each second, and if your OCXO is at exactly 10MHz, the final counter value will be 18,944 (the modulus of dividing 1,000,000,000 by 32,768) more than its previous value.
Thank you for your interesting video! I noticed that you run your uart process with the "serial_process_clock" which I guess is a down-divided version (and thus phase locked to it) of your clk_125_000. Maybe I missed the synchronization scheme, but it seems as if the uart process can access directly the registers written by processes wit the phase shifted clocks. In this situation it is very easy to create timing violations (if the uart process immediately accesses a register just written it might read metastable values), which can lead to hard to track down instabilities (sporadic wrong output values). Didn't your timing report show any problems? I would have expected that for reliable transfer you either require a synchronization scheme as is used for clock domain crossing (FF chain in destination domain) or the guarantee that the access from the uart process happens only after the registers properly stabilized. Furthermore I'm not sure, if mixing of rising_edge()/falling_edge() triggering could lead to problems.I guess that either the FFs in the logic cells can only run on one edge type and the dedicated clock routing network contains an additional inverted clock or the FFs can be configured to trigger on rising or on falling edge in the individual cell. In any case this will likely create an additional (small) delay, so the phase shifts are not in perfect inversion to their non-inverted counterparts. When I required an inverted clock signal for DDR at high speed, previously, I explicitly created an inverted clock with the DCM (clock management core), as was suggested by the datasheet of Xilinx (IIRC).
Good observations. The UART state machine runs at 5 MHz, but is designed in such a way to avoid metastable conditions (assuming the 1pps doesn't suddenly change to MHz...) - essentially, the first counter triggers the UART state machine from the Idle state, but the interpretation of the latched versions of the counter variables doesn't occur until 200 ns later. We know all 8 latched outputs will be ready in only 8ns. I was also concerned about the falling edge clocks, however the synthesis tool is clever enough to just invert the clocks and then copy the same logic as before. If I wanted to ensure this happened, I could just purposely infer that method in the VHDL (clk_125_180
@@sdgelectronics You are right! When you are really sure that the access in the Uart process happens only >200ns later, there is no problem. At least with the Xilinx synthesis tools I'm pretty sure that the statement "clk_125_180
Saw someone use a u-blox M7 gps module to get a perfect 10Mhz signal, must admit did not see the other vids on this so maybe I am missing the point but it seemed to be a way easier method to get 10Mhz signal. Especially when you combine it with the u-center soft that allows you to even select different freqs.
I've shelved the project for now, but the problem with the ublox module is the frequency is divided down from an internal 48 MHz source, so it can never output a 'perfect' 10 MHz signal (since it doesn't divide by 10). It'll always have bad jitter and phase noise which is undesirable for a reference unit.
In reality, the home user doesn't need this level of precision. You would normally feed into all your equipment (oscilloscope, sig gen, counters etc) through the 10 MHz reference input so you know the timing is correct on those devices. Part of the fun in this is designing something with specifications far exceeding normal day-to-day projects and understanding the effect this has on the component choice, PCB layout etc.
@@sdgelectronics that makes sense. I like the fact that even if I don't understand all the things you say, you do a good job at explaining the workings of the entire board on how you tackle each problem piece by piece. Thank you for your videos.
@@sdgelectronics Would there be a difference in frequency read by each appliance (jitter) due to signal being a sine wave and tolerances in threshold levels of 10Mhz input front-ends on those devices?
The only thing that comes to mind is a correction voltage based upon the addition of the waveform phases, once they are in phase there is no correction voltage, and the further out of phase the greater the voltage, how a PLL phase detector works basically, but I think that is far too simplistic compared to what you have been working on.
Yes, the phase shift is something that can't be corrected by just implementing a frequency control loop as I have done. I may well end up with a separate time interval counter to get it synced, and use the 1 ns resolution counter for everything else. Thanks
I would not consider the GPS a short term reference, one needs to integrate over hours to get a stable reference. I think the 1pps is quite limiting because you can only update the phase error ever second so lockup time suffers. Reducing the loop filter cutoff gets you a faster lockup but now you have more phase noise. Use U-Center to program the GPS receiver to output a higher frequency and use it to do the phase comparison. What ever you use needs to be hole number divisor of 48Mhz or else the DSS in the GPS will output lots of phase jitter. 2Mhz, 1Mhz and 100Khz seem to work fine for me. I think folks are stuck on uising 1pps because that was all you could get out of early GPS receivers, not true today. I compare the GPS output set at 100Khz to the 10Mhz OCXO divided by 100 with a 74HC4046. Not sure why I didn't use 1Mhz will have to look at that. With the loop filter it takes about 1 to 2 minutes to lock on and is rock stable with my Rb oscillator. Though ever 15 to 30 minutes I get a slow wander of phase for a few minutes, never more then one period of 10Mhz. To me the key is doing a good PID loop with possibly a gear shift to get a fast lockup then a long term, many hour average. What I don't know is the source of my phase wander, could be power, OCXO oven control loop, GPS signal corrections, or the Rb comparison oscillator. Still plenty accurate to calibrate my Rb oscillator. Also need to watch the temp change on the GPS receiver as well.
Hi….I know this was three years ago and done and dusted…however with respect to increasing the clocking rate of your phase detection of the 10 mhz with respect to the signal the pps. You do not need a a full 32 bit counter as the bulk of the digits are superfluous as you know exactly what they will be. I.e if you are counting an accurate 10mhz clocks between the rising edge of the the pps then for a suitably accurate reference clock then the count may be 9999997 or 10000003….. however if you run the counter such that it overflows even if you have recorded the last three digits you can infer the more significant digits. I.e. if you were told that the last three digits were 997 then you know the full count was 9999997… thereby having a much smaller counter that can run much faster not waiting for full propagation delay of carry. Clearly my example is in decimal but same thing for binary.
Most of this episode was focused on getting high precision measurement of the GPS 1 second output period. But, like I commented on your other video, the GPS 1pps signal will be out by as much as 50 parts per billion at any time. This is because satellites drift in/out of use every few minutes, and the timekeeping is from an average of the satellites in use. So basically, all your work measuring each second with nS precision is wasted because for this project to work well you will need a long term average of the 1pps over MANY MINUTES. This doesn't need a FPGA, but it does need a good software algorithm averaging 30+ minutes of data, and the input measurement of the 1pps signal can be easily handled by any decent MC, with a CCP resolution at 10mHz or so. You will also need a very fine resolution DAC system for the voltage control to the OCXO. 12 bit just won't cut it. I suggest using a combination of DAC and Sigma delta modulation with total resolution >100,000 steps. 🙂
I think this DAC is 16 bits, but I'm not certain this oscillator is the best choice. The pull range is quite extreme - good in that it has a longer service life, but poor from the controllability aspect, it also seems to drift quite a lot. Finding a DAC with more resolution and maintaining monotonicity is a difficult feat. The next task on my list is recording the error on the GPS 1 pps output to understand the behaviour. Thanks for your input
@@sdgelectronics regarding the DAC, you can use that same DAC but use a Sigma delta system to modulate between 2 integer steps, that gives you the ability to have much finer resolution than the native 16bits of the DAC. Regarding the OCXO and drift, just supply it with a really good regulated voltage and give it a couple of hours to settle down. Both the OCXO and the DAC should be run from very stable PSUs. The drift might be PSU drift. Measuring the GPS accuracy will give you a lot of info. The Ublox8T will give better timepulse accuracy than the standard Ublox8 once it has been locked for a couple of hours. I suggest displaying sats in view (and their sat number code) while you do the tests so you can see how much the timepulse period changes based on which satellites. I suspect the UbloxT will be doing a lot of long term internal averaging itself, before it's timepulse settles down and it might take hours. And thank YOU, for all the hours of effort you put in to channel for people to enjoy for free. 👍😁
In my opinion, using timestamping interval counters in cheap and popular uC's is the way to go, and then leave all of the post-processing for software, such that an increasingly sophisticated and refined algorithm can be applied. But is your objective to frequency lock your OCXO or phase lock it? I will assume frequency locking in my following comments, as I presume that you are not aiming to replicate the neutrino time-of-flight experiments across continents. One approach is to clock the uC's TIC using your 10MHz reference. Another is to use it as the uC's main oscillator reference clock, which is then multiplied by the uC core PLL for even higher resolution with little additional effort or cost. I believe that you are in luck in that 10MHz is within the allowable PLL reference frequency range for the dsPIC33. However I would not fixate on excessively high resolution as it is only one jitter/noise component feeding into the control loop with adverse GNSS constellation and the 1PPS jitter caused by output resolution of the GNSS receiver itself being limited by its own internal clock frequency. (Interestingly, Stanford Research Systems mitigates that by using an analog interpolator on the 1PPS input of its PRS10 rubidium frequency standard module.) Per one of my prior recommendations, you need to evaluate all of the sources of error at the system level in order to make rational optimization decisions or risk considerably over-engineering one aspect of the design for no appreciable benefit in the final solution. With a FIFO of TIC timestamps one can calculate absolute error and deviation statistics over a range of time periods to provide both filtered feedback control as well as indicators as to when to adjust the feedback algorithm itself based upon lower observed deviations: a mathematical determination of "stasis" and what that looks like. (As there will be the slow drift of crystal aging mixed in there too.) For instance, consider calculating the frequency between 10, 100, 1000, 10000 samples apart, which can be done directly if one implements enough bits in the interval counter with width extension in software of the hardware TIC overflow as necessary. Each order increase of the number of samples increases your "gating time" for a higher precision measurement. With some math, these can be turned into rolling self-reported long-term ADEV figures for operational monitoring as well. Totally going to have to delta-sigma that DAC to get the stability that I believe that you are aiming for. You can implement that later, but bear in mind that your short-term deviation will noticeably seesaw around the target frequency even when you get it all dialed in due to the tuning coarseness. This is easy to do, so I wouldn't save it for last.
Can I assume that it would be un-realistic to attempt to achieve in phase between your GPS disciplined 10MHz and a commercial GPS disciplined 10MHz due to the many variations in the two signal paths and it was simply a pie in the sky wish list desire?
First of all, the time-nuts people can give you much higher quality advice that I can: www.leapsecond.com/time-nuts.htm to get started. I did a bunch of work with NTP (the Network Time Protocol) years ago; I was one of the authors of the UNIX reference implementation to validate that the protocol spec was complete enough to do a from-scratch implementation. The NTP implementation tried to solve two problems - how to determine clock offset and round-trip latency to other reference sources on the internet, and the algorithms used to filter those samples and select the best candidate synchronization source - you don't have this problem since you have the GPS receiver already there.
The other half of the problem was correcting and maintaining the clock on the local computer. But this really was about implement this abstract clock model on the OS, where you got to tweak the timekeeping. Most computers have some timekeeping interrupt that fires every so many milliseconds, and by default, you add that many milliseconds to the local time in the interrupt service routine and move along. Then when a program wants to know what time it is, you look at the software counter and maybe read some hardware register so some math and return the answer.
What NTP (and the OS) tried to do was to maintain a phased locked loop, corrected by the phase error by way of the samples being taken. The loop filter of the PLL got "tighter" as you got closer to the right time. Also the polling intervals became longer to be able to both resolve the phase error and hopefully reduce the impact of the jitter associated with the measurements (in this case, packet arrival times).
Since you were timestamping the packets arriving with the same clock you were gently slewing, you could only adjust the clock so fast..
There are parallels to your work - I think that maybe as you get closer to synchronizing the phase of the TCXO with the 1PPS output, you might want to do this over successively smaller longer intervals as you get closer. This might also have the effect of mitigating some of the sawtooth jitter on the 1PPS signal. The sawtooth probably exists for the same reason you'll have sawtooth phase error in your 10MHz - because you need to adjust at a resolution below 1 bit of DAC resolution. So maybe this is something to implement in the FPGA - both the longer measurement interval as well as some virtualized tuning value that gets turned into a series of alternating DAC values over some interval. I suppose this comes down to how much phase noise on the 10MHz output you're willing to tolerate.
I'm way beyond my depth in the advice on your hardware implementation since my experience 25 years ago (more?) with was the software analog of all this.
Speaking of analog, the introduction of analog components to measure the phase error seems like another opportunity to fight temperature effects.. When I did my NTP implementation, one of the results computed was the intrinsic frequency error of the local (really shitty crystal) oscillator in my computer. It was really easy to measure the temperature of my office once by looking at this computed frequency error once I calibrated it. It was, as you might expect, somewhat linear. The real reason for the computed frequency error was to implement holdover should the computer lose its network connectivity to its synchronization sources.
So many words, maybe some of them are helpful to you. Really interesting work to follow along with. You're entering a dangerous area of precise time and frequency mental illness. Proceed with caution.
Much respect for that post ! Would be a great addition to add the NTP server part to this project and get your experience inside it !
The PLL approach is interesting (for clock synchronization), but I think only workable, with the challenges of locking and then correcting as you have mentioned, if you have an accurate standalone 10MHz OCXO (as the main uncorrected source), then use a Neo-M9N (GPS) Module programmed for a GPS referenced oscillator output of 10MHz, then have a heavy filtered PLL to correct the OCXO output when the GPS source is available.
If the GPS source is lost then the circuit would revert back to the OCXO source.
I am not exactly sure how to do the above without doing some bread boarding circuit tests, and I see two problems the first is the GPS source clock jitter at 10MHz (which I believe is not an even subdivision of the GPS sync signal, that is a fractional divide) and how this would effect the actual 10MHz synchronized output, so you may want to have add a divide by ten in the PLL loop for a corrected output 1MHz as your true reference, but the delays through the clock chain should be kept to a minimum, which would mean a very fast edge rate logic family.
And you I agree that in experimenting with this topic the engineer may suffer from precise time phobias given the problem is just not knowing the true time but then how and when to correct the time used by the system.
@@windward2818 I think that if you had an OXCO, you could ignore the the 10MHz output from the GPS receiver, and then instead discipline the OXCO by using the 1PPS output over long intervals. This would take the form of some control loop ultimately tweaking some D/A converter that's pushing on the OXCO. If you loose GPS lock (and presumably the 1PPS output), then you can continue to apply the same frequency correction with your D/A output until your synchronization source returns.
This was essentially what my UNIX NTP implementation did years ago (and in a similar fashion these days, with improved kernel support.) You compute some frequency error and keep applying that correction even in the absence of a synchronization source. Years ago, that got done with periodic UNIX adjtime() system calls applying a correction; these days there are better kernel facilities to do that and much of this logic is inside the kernel..
For bonus points and for the extra paranoid, you could try to model the frequency error that you're correcting against ambient temperature and continue to apply that when free running. You'd think this should be small for an OXCO.
I am in the middle of building two GPSDOs as well using some Ublox NEO-6T GNSS receivers that I have left over from a project. I assume that you know that the TIMEPULSE output does not have to run at 1PPS? I think some of your architecture problems are related to having to manage both frequency and phase. If you reprogram the TIMEPULSE output to generate 10, 25, 50 or 100KHz and use a simple hardware divider on the output of the 10MHz OXCO then you can simplify the architecture and deal with just phase measurement/phase locking of two sources that are already inside the same frequency capture range. There are 'all analogue' designs that use a Type 1 phase comparator to compare the divided down OXCO against the (faster) TIMEPULSE and achieve very good performance with relatively simple two-pole low pass filters. There are other implementations that move to the digital domain and employ an MCU which is directly clocked from the 10MHz OXCO and takes a 10KHz (or similar) reference clock to a timer/counter input programmed to generate IRQs and use an algorithm to resolve the difference between hardware time (from GNSS) and software time (from CPU clock, clocked by the variable OCXO) and generate the tuning voltage either via 16-bit PWM or a 16-bit DAC. None of these solutions needs an FPGA since the solution can be implemented entirely in the analogue domain or in the software domain. The advantage of the software domain is that you can implement things like stored values for faster start-up, compensation for long-term ageing, hold-over, real-time status display, alarms, NTP server, IEEE-1588, etc.
This project is getting really good, thanks for the progress update.
Truly nice! The idea of pulse width to voltage conversion is really well done. I'll be posting the project of a gpsdo I'm design also. My idea is to use a free running crystal oscillator as an "phase counter" that counts the phase different between the VCO and the gps 1pps. My idea is that an uncorrelated phase counter will result in greater frequency resolution as jitter would help to oversample the signal phase difference.
Thank you for this video, I found it interesting.
One thing to watch for on the non-timing GPS modules is they will vary the reported altitude more to adjust for what should be timing changes. This will add some error to your measurements. The Neo-M8T also reports the quantization error in its PPS output ($PUBX or UBX-TIM-TP messages), which will be in the nanosecond range.
I think you've gone with a frequency counter design, you might also want to consider a time interval counter design.
I'm definitely not sticking with the frequency counter alone. It's great for the statistics, but can drift around too much. Thanks for your input.
Nice to see some VHDL coding. I have played with PIC and gps trying to discipline the timer in the pic.. For educational purposes. The regulation loop with adjusting by +-1 worked only when the frequency was close to the 1pps, but since i didn't have a 1pps signal I used the uart signal, some one shot conditioning of it and in on a capture pin on the PIC. Turned out it was very jittery, perhaps because of the realtime OS... Anyway it was fun, and RomanBlack had and still has many fun projects on his website. He also talked about how he could see the oscillator (counted by the pic) change only by moving next to it 🙂
I've actually done a project rather similar to this. I abused the fact that my MSP430F2274 has hardware latched capture/compare registers(I'm sure many others do also), and used the GPS 1pps to latch a hardware/software counter that overflowed for the MSBs, then made sure I was counting 10M cycles in total, it worked surprisingly well.
I think i'd add cutouts around the oscillator wide enough to get some foam through and have foam back and front, and thermal isolation from the rest of the pcb.
Definitely needed, it really doesn't take much to cause this oscillator to drift. If I can find some double oven oscillators I might use those instead, otherwise I'll 3D print something that I can fill with insulation and clamp it around the board. Thanks
Hi, the ublox neo can output other frequencies then 1 pps . are other frequencies as accurate as the 1 pps? i measured 24mhz from the internal ublox crystal oscillator(under the lid) so a 12mhz should be a complete divide by 2 . can you please measure the 12mhz output without gps lock and with the gps lock and compare the two?
If you want to sample at 400 MHz in the FPGA, you don't need to count the entire 24 bit at 400 MHz. You can just take 4 samples at 400 MHz and then transfer those 4 bits to the 100 MHz clock domain. You can then see if there was a transition and if there was a transition see at which clock edge it was. You can even use DDR flip-flops at 400 MHz to increase the sample rate to 800 MHz while having a single 400 MHz clock. An advantage of sampling with just one clock is that the "jitter" between the samples is much lower since the signal does not follow different paths for the different samples. Especially if the tooling can map the DDR register in a IO block.
Cool project. Respect
Do you publish this project on your website?
Where I can find the PCB Layout and the source code?
The UBLOX module allows as output clock all factors of 24MHz. So 1MHz, 2MHZ, 3MHz, 4MHz are avail with low jitter. 10MHz is not an integer factor of 12MHz and therefore has a lo of jitter.
Why not make a PLL comparing the UBLOX 1MHz with the 10MHz VCO (divided by 10)?
I created a phase-frequency detector to lock a 10 MHz to 10 kHz from a Jupiter GPS.
I use the FPGA to read the frequency with the 1PPS, that gets a course lock, and then pass over to the phase-frequency detector.
This subject is rather complex for me but its great to hear your thoughts on it. Thanks for sharing and good luck with this protect.
Also I would like to see some episodes on the firmware creation , I think you would explain the process really well as your going along.- just my thoughts :)
Thanks, I realise after the fact I just rambled on. I will do a shorter follow up on exactly what's going on without all the detail.
The NEO-M8T is a really interesting receiver as it can output raw pseudo ranges and carrier phases... a good candidate for sub-cm differential surveying (I used to play with Motorola Oncore for this)... anyway... the project is getting interesting! In my limited understand the PPS is asynchronous to the GPS clock (it tries its best but it runs separately) so you need TIM-TP message to adjust the phase or long averaging. You should also fix the position so the receiver only has to solve for time. I'm very jealous of the hotplate... that seems such a good toy.
The hotplate worked really well! I was impressed with it. I'm reading up on the M8T - it looks like it can do a lot for you to give the best results, but the datasheet is a little vague in places so more reading up needed
can anyone tell me where to get the code and pcb layout from?
I didn't finish, but I plan to revisit soon once I can get a few of the components I've been waiting for.
the 10mhz output, can you connect that to more than one equipment?, or do one need extra circuitry to do that?
It needs a separate amplifier for each output to prevent signal reflections.
@@sdgelectronics because one totally need more than one output :)
Just to make sure I have this right - The goal is to simply produce an accurate 10MHz. The standard, datum or reference for the entire system is the 1PPS from GPS but it suffers from jitter. So overtime we know that once averaged the 1PPS are extremely close to "1PPS" and we use this fact to gently discipline the OCXO overtime, which over time produces a stable 10MHz sinewave. I think that's what you said but I loose track of which is the true reference, in this case 1PPS, but then the 10MHz becomes a useable reference.
Basically yes, the 1pps is entirely accurate over time, but suffers from several forms of jitter. The idea is to get the 10 MHz as near as possible to this 1pps but essentially eliminate the jitter from appearing on the 10 MHz. Long time constants and lots of statistics are used to get there. In real terms, the only time where the jitter is likely to be a problem for measurements is where you have this feeding the reference input into a spectrum analyser. Counters and signal generators are unlikely to need the same performance.
You don't actually need a large number of bits in your counter. For example, if you are counting at 1GHz (that would be nice!) and your OCXO is no more than 10ppm off, then a 15 bit counter is sufficient to count the interval between 1pps signals (since 1GHz times 10ppm is 10,000, so you need to be able to count to at least twice that). Such a counter will roll over more than 30,000 times each second, and if your OCXO is at exactly 10MHz, the final counter value will be 18,944 (the modulus of dividing 1,000,000,000 by 32,768) more than its previous value.
Thank you for your interesting video!
I noticed that you run your uart process with the "serial_process_clock" which I guess is a down-divided version (and thus phase locked to it) of your clk_125_000. Maybe I missed the synchronization scheme, but it seems as if the uart process can access directly the registers written by processes wit the phase shifted clocks. In this situation it is very easy to create timing violations (if the uart process immediately accesses a register just written it might read metastable values), which can lead to hard to track down instabilities (sporadic wrong output values). Didn't your timing report show any problems? I would have expected that for reliable transfer you either require a synchronization scheme as is used for clock domain crossing (FF chain in destination domain) or the guarantee that the access from the uart process happens only after the registers properly stabilized.
Furthermore I'm not sure, if mixing of rising_edge()/falling_edge() triggering could lead to problems.I guess that either the FFs in the logic cells can only run on one edge type and the dedicated clock routing network contains an additional inverted clock or the FFs can be configured to trigger on rising or on falling edge in the individual cell. In any case this will likely create an additional (small) delay, so the phase shifts are not in perfect inversion to their non-inverted counterparts.
When I required an inverted clock signal for DDR at high speed, previously, I explicitly created an inverted clock with the DCM (clock management core), as was suggested by the datasheet of Xilinx (IIRC).
Good observations. The UART state machine runs at 5 MHz, but is designed in such a way to avoid metastable conditions (assuming the 1pps doesn't suddenly change to MHz...) - essentially, the first counter triggers the UART state machine from the Idle state, but the interpretation of the latched versions of the counter variables doesn't occur until 200 ns later. We know all 8 latched outputs will be ready in only 8ns. I was also concerned about the falling edge clocks, however the synthesis tool is clever enough to just invert the clocks and then copy the same logic as before. If I wanted to ensure this happened, I could just purposely infer that method in the VHDL (clk_125_180
@@sdgelectronics You are right! When you are really sure that the access in the Uart process happens only >200ns later, there is no problem.
At least with the Xilinx synthesis tools I'm pretty sure that the statement "clk_125_180
Saw someone use a u-blox M7 gps module to get a perfect 10Mhz signal, must admit did not see the other vids on this so maybe I am missing the point but it seemed to be a way easier method to get 10Mhz signal. Especially when you combine it with the u-center soft that allows you to even select different freqs.
I've shelved the project for now, but the problem with the ublox module is the frequency is divided down from an internal 48 MHz source, so it can never output a 'perfect' 10 MHz signal (since it doesn't divide by 10). It'll always have bad jitter and phase noise which is undesirable for a reference unit.
This is rocket science to me but I find it fascinating. Could you explain what practical use such device can be?
In reality, the home user doesn't need this level of precision. You would normally feed into all your equipment (oscilloscope, sig gen, counters etc) through the 10 MHz reference input so you know the timing is correct on those devices. Part of the fun in this is designing something with specifications far exceeding normal day-to-day projects and understanding the effect this has on the component choice, PCB layout etc.
@@sdgelectronics that makes sense. I like the fact that even if I don't understand all the things you say, you do a good job at explaining the workings of the entire board on how you tackle each problem piece by piece. Thank you for your videos.
@@sdgelectronics Would there be a difference in frequency read by each appliance (jitter) due to signal being a sine wave and tolerances in threshold levels of 10Mhz input front-ends on those devices?
The only thing that comes to mind is a correction voltage based upon the addition of the waveform phases, once they are in phase there is no correction voltage, and the further out of phase the greater the voltage, how a PLL phase detector works basically, but I think that is far too simplistic compared to what you have been working on.
Yes, the phase shift is something that can't be corrected by just implementing a frequency control loop as I have done. I may well end up with a separate time interval counter to get it synced, and use the 1 ns resolution counter for everything else. Thanks
I would not consider the GPS a short term reference, one needs to integrate over hours to get a stable reference. I think the 1pps is quite limiting because you can only update the phase error ever second so lockup time suffers. Reducing the loop filter cutoff gets you a faster lockup but now you have more phase noise. Use U-Center to program the GPS receiver to output a higher frequency and use it to do the phase comparison. What ever you use needs to be hole number divisor of 48Mhz or else the DSS in the GPS will output lots of phase jitter. 2Mhz, 1Mhz and 100Khz seem to work fine for me. I think folks are stuck on uising 1pps because that was all you could get out of early GPS receivers, not true today. I compare the GPS output set at 100Khz to the 10Mhz OCXO divided by 100 with a 74HC4046. Not sure why I didn't use 1Mhz will have to look at that. With the loop filter it takes about 1 to 2 minutes to lock on and is rock stable with my Rb oscillator. Though ever 15 to 30 minutes I get a slow wander of phase for a few minutes, never more then one period of 10Mhz. To me the key is doing a good PID loop with possibly a gear shift to get a fast lockup then a long term, many hour average. What I don't know is the source of my phase wander, could be power, OCXO oven control loop, GPS signal corrections, or the Rb comparison oscillator. Still plenty accurate to calibrate my Rb oscillator. Also need to watch the temp change on the GPS receiver as well.
Hi….I know this was three years ago and done and dusted…however with respect to increasing the clocking rate of your phase detection of the 10 mhz with respect to the signal the pps.
You do not need a a full 32 bit counter as the bulk of the digits are superfluous as you know exactly what they will be.
I.e if you are counting an accurate 10mhz clocks between the rising edge of the the pps then for a suitably accurate reference clock then the count may be 9999997 or 10000003….. however if you run the counter such that it overflows even if you have recorded the last three digits you can infer the more significant digits. I.e. if you were told that the last three digits were 997 then you know the full count was 9999997… thereby having a much smaller counter that can run much faster not waiting for full propagation delay of carry.
Clearly my example is in decimal but same thing for binary.
You can increase the output frequency of the GPS LED, ublox neo m8n can do it
Great video i understand just 10% of it :D
Sorry it almost ended up like a mikeselectricstuff video, but with out the LEDs :( I plan to follow up with something a bit more coherent...
Most of this episode was focused on getting high precision measurement of the GPS 1 second output period.
But, like I commented on your other video, the GPS 1pps signal will be out by as much as 50 parts per billion at any time. This is because satellites drift in/out of use every few minutes, and the timekeeping is from an average of the satellites in use.
So basically, all your work measuring each second with nS precision is wasted because for this project to work well you will need a long term average of the 1pps over MANY MINUTES.
This doesn't need a FPGA, but it does need a good software algorithm averaging 30+ minutes of data, and the input measurement of the 1pps signal can be easily handled by any decent MC, with a CCP resolution at 10mHz or so.
You will also need a very fine resolution DAC system for the voltage control to the OCXO. 12 bit just won't cut it. I suggest using a combination of DAC and Sigma delta modulation with total resolution >100,000 steps. 🙂
I think this DAC is 16 bits, but I'm not certain this oscillator is the best choice. The pull range is quite extreme - good in that it has a longer service life, but poor from the controllability aspect, it also seems to drift quite a lot. Finding a DAC with more resolution and maintaining monotonicity is a difficult feat. The next task on my list is recording the error on the GPS 1 pps output to understand the behaviour. Thanks for your input
@@sdgelectronics regarding the DAC, you can use that same DAC but use a Sigma delta system to modulate between 2 integer steps, that gives you the ability to have much finer resolution than the native 16bits of the DAC.
Regarding the OCXO and drift, just supply it with a really good regulated voltage and give it a couple of hours to settle down. Both the OCXO and the DAC should be run from very stable PSUs. The drift might be PSU drift.
Measuring the GPS accuracy will give you a lot of info. The Ublox8T will give better timepulse accuracy than the standard Ublox8 once it has been locked for a couple of hours. I suggest displaying sats in view (and their sat number code) while you do the tests so you can see how much the timepulse period changes based on which satellites. I suspect the UbloxT will be doing a lot of long term internal averaging itself, before it's timepulse settles down and it might take hours.
And thank YOU, for all the hours of effort you put in to channel for people to enjoy for free. 👍😁
In my opinion, using timestamping interval counters in cheap and popular uC's is the way to go, and then leave all of the post-processing for software, such that an increasingly sophisticated and refined algorithm can be applied. But is your objective to frequency lock your OCXO or phase lock it? I will assume frequency locking in my following comments, as I presume that you are not aiming to replicate the neutrino time-of-flight experiments across continents.
One approach is to clock the uC's TIC using your 10MHz reference. Another is to use it as the uC's main oscillator reference clock, which is then multiplied by the uC core PLL for even higher resolution with little additional effort or cost. I believe that you are in luck in that 10MHz is within the allowable PLL reference frequency range for the dsPIC33. However I would not fixate on excessively high resolution as it is only one jitter/noise component feeding into the control loop with adverse GNSS constellation and the 1PPS jitter caused by output resolution of the GNSS receiver itself being limited by its own internal clock frequency. (Interestingly, Stanford Research Systems mitigates that by using an analog interpolator on the 1PPS input of its PRS10 rubidium frequency standard module.)
Per one of my prior recommendations, you need to evaluate all of the sources of error at the system level in order to make rational optimization decisions or risk considerably over-engineering one aspect of the design for no appreciable benefit in the final solution.
With a FIFO of TIC timestamps one can calculate absolute error and deviation statistics over a range of time periods to provide both filtered feedback control as well as indicators as to when to adjust the feedback algorithm itself based upon lower observed deviations: a mathematical determination of "stasis" and what that looks like. (As there will be the slow drift of crystal aging mixed in there too.) For instance, consider calculating the frequency between 10, 100, 1000, 10000 samples apart, which can be done directly if one implements enough bits in the interval counter with width extension in software of the hardware TIC overflow as necessary. Each order increase of the number of samples increases your "gating time" for a higher precision measurement. With some math, these can be turned into rolling self-reported long-term ADEV figures for operational monitoring as well.
Totally going to have to delta-sigma that DAC to get the stability that I believe that you are aiming for. You can implement that later, but bear in mind that your short-term deviation will noticeably seesaw around the target frequency even when you get it all dialed in due to the tuning coarseness. This is easy to do, so I wouldn't save it for last.
Could General Relativity be playing a role?
Excellent.
Can I assume that it would be un-realistic to attempt to achieve in phase between your GPS disciplined 10MHz and a commercial GPS disciplined 10MHz due to the many variations in the two signal paths and it was simply a pie in the sky wish list desire?
Supposedly, the 1pps from all these receivers are synchronised once the 3D fix is complete on the GPS module. I've not tested this though.
No apologies needed... maybe not as "informative" as other vids, but still interesting.
👍👌
it will only be revolutionary if the cost is low, which means no FPGA or a very cheap FPGA
True, this definitely will not be any kind of 'definitive' design. It is however my overly complex interpretation ;)