Electronics > Projects, Designs, and Technical Stuff
GPSDO: PLL or MCU controlled?
Johnny B Good:
--- Quote from: Gyro on July 27, 2019, 11:43:53 am ---Here's a pll based one that I did (still at the same scruffy breadboard stage :()...
https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/
--- End quote ---
Hi, Gyro,
I've been messing about with a homebrewed GPSDO assembled onto a plug in prototyping breadboard for the past month or so, based on your scruffy GPSDO (well, the LPF parts following a 74HC86 xor phase detector that replaced the ancient 4046 micropower pll chip I'd been using with a (very cheap) ublox neo 6M module[1] which could only be programmed to a maximum PPS frequency of 1KHz requiring a couple of '390s to divide the OCXO's output down to a glacial 1KHz to drive the 4046 (PD2 output option).
When a replacement M8N module[2] I'd had on order finally turned up, I retained the same glacial 10,000 divisor for my initial tests just to confirm that the cheap 6M had definitely been the sole cause of all my woes of the week before, before doing the 'sensible thing' by programming the M8N to give out a 100KHz on its PPS line, allowing me to shed one of the '390s and ditch the 'glacier watching' experience associated with a 1KHz phase locking frequency from a 10MHz ocxo.
That meant that, at long last, I could finally ditch the 4046 and use a 74HC86 xor gate phase detector to feed the LPF which initially drove the OCXO's Vfc pin directly. To start with, I used 100k with 22μF and 470μF in series with a 39k in my filter (not exactly the same component values you'd chosen, just near enough for the job - they were just what I happened to have to hand to put me in the same ball park).
It was only later on that I changed them to 10M with 1μF and a 10μF with a 390k series resistor once I had inserted a 5v cmos RRO buffer amp in between the LPF output and the OCXO's Vfc line. This seems the best compromise so far with my current batch of CQE branded OCXOs between minimising the effects of the phase variations inherent in the GPS system and holding the startup time to a reasonably acceptable 15 minutes[3].
I experimented with much larger time constants (500 seconds!) to see whether I could smooth out the random timing error excursions in the GPS system but gave up on this method of filtering when it became obvious that during the more protracted map deviation events the phase excursions were being amplified.
It had looked promising enough for the shorter half minute or so shifts in positional error once the hour or so startup time had elapsed but I could see that using very long time constant filtering here wasn't going to cut it so it was a case of going back to the "Devil You Know" with less ambitious time constant values (10/100 seconds versus your original choice of 3.3/33 seconds).
With such a basic PLL solution as this, the output is always going to be polluted by these 20 to 30ns phase shifts when using non-timing GPS receiver modules such as the NEO-M8N and the NEO-6M. Timing modules may reduce this effect but they cost far more than the additional cost of an Arduino nano running a Kalman filtering algorithm to filter out such effects to ever greater and greater effect with each passing hour of operation.
Long term (weeks to decades) the PPS or its derived 100 to 10,000KHz is never going to be out from the exact GPS time by much more than 50ns anyway whether you use a costly timing module or a cheap 'n' cheerful navigation only module. If you can live with these nanosecond sized phase shifts, typically at less than one ns per second either way every few minutes or so, on a 10MHz reference, a simple PLL design will do the job.
If you're building your first GPSDO, you can always leave a bit of room spare to add an Arduino nano with another IC or two to allow for a future upgrade. After all, even a basic GPSDO is better than no GPSDO at all. :)
I'm now actually in the process of reassembling my breadboarded GPSDO into a proper enclosure. I've finally had enough of the unpredictability of plug in breadboard construction - stable enough if you don't physically disturb it but a pain if you have to wrangle it around the bench.
I've now actually committed myself to building it onto a vero board I'd previously trimmed to slide into the slots of a small extruded case by drilling the extra hole between tracks to accommodate the Vref pin of my OCXO which unconscionably doesn't line up with the 0.1 inch hole spacing of veroboard. ::) Who knows? I might actually have it ready for initial testing before the end of next week! :)
I'm going to use up my very first CQE OCXO acquisition on this model, a 13MHz 5v example rather than any of the 12v 10MHz units in my collection. I've already had this OCXO setup on a breadboard lashup to generate a 10MHz signal using a 74193 as a divide by 13 of the doubled up to 26MHz so as to feed a 3N502 ultra low jitter clock multiplier with its minimum specified input clock frequency of 2MHz. On that occasion, I'd used another 3N502 for the initial doubler but I'm going to use an XOR gate this time round (I've got three going spare) to save using up any more of my precious 3N502s. I'd already tested the XOR doubler idea with the breadboarded GPSDO lashup so I'm quietly confident this will work.
[Notes]
[1] This had been driving me round the twist with its 1ms pps 1/2ms pulse that kept getting narrower and narrower about halfway through a 10 to 15 minute cycle (a sawtooth correction bug I guess) before finally disappearing up its own fundament to then instantly reincarnate itself as the 50% duty cycle 1ms pulse I'd programmed before starting another cycle of this nonsense. |O
I'd set up two '390s to divide the 10MHz ocxo to feed the phase detector with 1KHz (the fastest I could program that 6M to output on its PPS line) and spent many days trying to get the damned thing to lock, even resorting to that 4046's frequency/phase detector output which did eventually start to show signs of working for longer than the 15 minutes it would take to lock phase at such a glacial 10,000:1 division ratio from the OCXO to the PLL's phase/frequency detector.
At that stage I was waiting on delivery of a cheapish M8N (which has since proved to be a Chinese fake but not fatally so - it's what I'm currently using). I decided at that point to probe the phase detector inputs (after nearly a week of slowly going round the bend) and finally discovered that weird behaviour of the 6M's narrowing pulse :palm: - no wonder I couldn't get it to work! - in fact, I'm surprised I'd experienced those brief moments of short lived "triumph" even using the PD2 output from the 4046! ::)
I suppose it's just possible that this effect might not appear if it's left on its default 1PPS setting but I haven't tested this possibility since I've no immediate plans to try it out using Lars' GPSDO design where it might just be able to redeem itself. It had only cost me £3.99, delivered anyway so such testing can stay on the back burner for now, (or even forever - it only receives GPS svs anyway).
[2] I'd managed to burn out the PPS line on my first (genuine!) M8N module with a 12 volt jolt just over three months ago now :palm:, hence this replacement module from China which, unsurprisingly, is a fake (no flash and no SAW filter, judging by the anomalous results between externally mounted and internally mounted active GPS patch antennas). A CR2032 1KR and Schottky blocking diode solves the short 50 minute BBRAM retention time issue, giving me an estimated 250 days or better powered off retention time to protect my settings and maintain the RTC.
[3] The point at which it's no worse than the GPS positional error induced phase shifts can become (when the final excursions around the phase lock in point become lost in the GPS system noise).
JBG
Johnny B Good:
--- Quote from: MosherIV on July 27, 2019, 09:39:52 am ---It depends on how the 10KHz from the neo-m8t is generated.
My understanding is that it is using the same timing source as the 1pps, so will therefore have the same jitter problem. Ublox have an onboard TCXO whuch is used to generate the 1pps or any freq via the programable interface, the jitter is created by the divide down method from the TCXO. I think the TCXO is 12MHz so only multiples of 12MHz will not have much jitter. The remainging jitter will purely be down to the jitter of the crystal part of the TCXO.
The PLL method only works if the signal is derived from the GPS signal itself. The older GPS modules did this but not models from Ublox.
The more stable method for 1pps signal is to use the averaging method.
I think you will get better results by usung the 1pps and averaging even though you have a T model (timing - better for timing application as opposed to location applications).
--- End quote ---
The NEO M8N (and, I think this also applies to the timing variants, BICBW) use a 48MHz tcxo. The M8N modules at least, issue a new PPS on the closest rising edge of this 48MHz clock which generates a skipped pulse of up to +/- half a cycle corresponding to a jitter of 20.833333ns every so often. If you program the M8N to give out a 10MHz on its PPS line, it seems to apply this sawtooth correction at anywhere from 5 a second or so to once every half minute or even longer, depending on how close to the exact 48MHz this tcxo happens to have settled on.
Also, because 10MHz isn't an exact even integer divider ratio, the 10MHz will have a clock divider jitter component as well as this sawtooth correction. You can eliminate this divider jitter (but not the sawtooth jitter) by selecting an even numbered divisor indirectly by selecting, for example, a 12 or 8 or 6 or 4 or 3 or 2 or 1.5 MHz frequency and so on. As long as the chosen frequency is based on an even numbered integer, it'll remain free of this non integer divider induced jitter (but not free of the ubiquitous sawtooth corrections).
These issues are seemingly a serious problem to the novice GPSDO builder with hopes of using a NEO M8N's ability to generate a 10MHz reference directly from its PPS line and avoid the expense of a 10MHz OCXO. Whilst the raw 10MHz output can be used as a calibration reference to trim the reference XO or TCXO inside other test gear and communications equipment, it certainly can't be used as an external 10MHz reference directly in most cases (there may be exceptions where the reference is phase locking a much higher internal reference which is filtered from any such jitter components but I don't know of any specific examples).
Once you've bitten the bullet on the cost of a reasonable to excellent quality OCXO for your GPS receiver to discipline, you can stop worrying about divider jitter and even the sawtooth jitter since the necessary LPF after the phase detector will rather effectively remove their effect on the OCXO, leaving you to concentrate on the one remaining 'insurmountable' (as far as a simple PLL based GPSDO setup goes) issue of phase errors in the GPS system itself which are mainly due to the effects of varying electron density in the ionosphere on the propagation speed of the signals emanating from the SV's themselves.
There are other, lesser sources of error in the SV's and the receivers themselves but they pale into insignificance when compared to the vagaries of the ionosphere. You can see the effect reflected in the u-centre deviation map plots and the altitude display, typically deviations of 10 metres or more for both being not unusual. At a speed of just under a foot per nanosecond for the SV's signals, such deviations could represent timing errors of as much as 30ns, almost a third of a cycle at 10MHz.
For amateur radio use, this is still generally good enough as an external reference for radio equipment operating in the low GHz bands but if you're trying to calibrate a 10MHz OCXO in a signal generator to within 50ppt, the operation becomes somewhat tricky with this level of phase deviation.
Calibrating OXCOs in test equipment (notably frequency counters) to within 0.1ppb can be achieved without too much difficulty at this level of phase error typical of a basic PLL GPSDO design so all is not lost for the lack of Kalman filtering. You can follow the Time Nuts down that particular rabbit hole at your leisure any time you feel the urge once you've had a chance to become dissatisfied with your current GPSDO project. >:D
JBG
Gyro:
--- Quote from: Johnny B Good on August 01, 2019, 11:26:55 pm ---
--- Quote from: Gyro on July 27, 2019, 11:43:53 am ---Here's a pll based one that I did (still at the same scruffy breadboard stage :()...
[url]https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/[/url]
--- End quote ---
Hi, Gyro,
I've been messing about with a homebrewed GPSDO assembled onto a plug in prototyping breadboard for the past month or so, based on your scruffy GPSDO (well, the LPF parts following a 74HC86 xor phase detector that replaced the ancient 4046 micropower pll chip I'd been using with a (very cheap) ublox neo 6M module[1] which could only be programmed to a maximum PPS frequency of 1KHz requiring a couple of '390s to divide the OCXO's output down to a glacial 1KHz to drive the 4046 (PD2 output option).
When a replacement M8N module[2] I'd had on order finally turned up, I retained the same glacial 10,000 divisor for my initial tests just to confirm that the cheap 6M had definitely been the sole cause of all my woes of the week before, before doing the 'sensible thing' by programming the M8N to give out a 100KHz on its PPS line, allowing me to shed one of the '390s and ditch the 'glacier watching' experience associated with a 1KHz phase locking frequency from a 10MHz ocxo.
That meant that, at long last, I could finally ditch the 4046 and use a 74HC86 xor gate phase detector to feed the LPF which initially drove the OCXO's Vfc pin directly. To start with, I used 100k with 22μF and 470μF in series with a 39k in my filter (not exactly the same component values you'd chosen, just near enough for the job - they were just what I happened to have to hand to put me in the same ball park).
It was only later on that I changed them to 10M with 1μF and a 10μF with a 390k series resistor once I had inserted a 5v cmos RRO buffer amp in between the LPF output and the OCXO's Vfc line. This seems the best compromise so far with my current batch of CQE branded OCXOs between minimising the effects of the phase variations inherent in the GPS system and holding the startup time to a reasonably acceptable 15 minutes[3].
I experimented with much larger time constants (500 seconds!) to see whether I could smooth out the random timing error excursions in the GPS system but gave up on this method of filtering when it became obvious that during the more protracted map deviation events the phase excursions were being amplified.
It had looked promising enough for the shorter half minute or so shifts in positional error once the hour or so startup time had elapsed but I could see that using very long time constant filtering here wasn't going to cut it so it was a case of going back to the "Devil You Know" with less ambitious time constant values (10/100 seconds versus your original choice of 3.3/33 seconds).
With such a basic PLL solution as this, the output is always going to be polluted by these 20 to 30ns phase shifts when using non-timing GPS receiver modules such as the NEO-M8N and the NEO-6M. Timing modules may reduce this effect but they cost far more than the additional cost of an Arduino nano running a Kalman filtering algorithm to filter out such effects to ever greater and greater effect with each passing hour of operation.
Long term (weeks to decades) the PPS or its derived 100 to 10,000KHz is never going to be out from the exact GPS time by much more than 50ns anyway whether you use a costly timing module or a cheap 'n' cheerful navigation only module. If you can live with these nanosecond sized phase shifts, typically at less than one ns per second either way every few minutes or so, on a 10MHz reference, a simple PLL design will do the job.
If you're building your first GPSDO, you can always leave a bit of room spare to add an Arduino nano with another IC or two to allow for a future upgrade. After all, even a basic GPSDO is better than no GPSDO at all. :)
I'm now actually in the process of reassembling my breadboarded GPSDO into a proper enclosure. I've finally had enough of the unpredictability of plug in breadboard construction - stable enough if you don't physically disturb it but a pain if you have to wrangle it around the bench.
I've now actually committed myself to building it onto a vero board I'd previously trimmed to slide into the slots of a small extruded case by drilling the extra hole between tracks to accommodate the Vref pin of my OCXO which unconscionably doesn't line up with the 0.1 inch hole spacing of veroboard. ::) Who knows? I might actually have it ready for initial testing before the end of next week! :)
I'm going to use up my very first CQE OCXO acquisition on this model, a 13MHz 5v example rather than any of the 12v 10MHz units in my collection. I've already had this OCXO setup on a breadboard lashup to generate a 10MHz signal using a 74193 as a divide by 13 of the doubled up to 26MHz so as to feed a 3N502 ultra low jitter clock multiplier with its minimum specified input clock frequency of 2MHz. On that occasion, I'd used another 3N502 for the initial doubler but I'm going to use an XOR gate this time round (I've got three going spare) to save using up any more of my precious 3N502s. I'd already tested the XOR doubler idea with the breadboarded GPSDO lashup so I'm quietly confident this will work.
[Notes]
[1] This had been driving me round the twist with its 1ms pps 1/2ms pulse that kept getting narrower and narrower about halfway through a 10 to 15 minute cycle (a sawtooth correction bug I guess) before finally disappearing up its own fundament to then instantly reincarnate itself as the 50% duty cycle 1ms pulse I'd programmed before starting another cycle of this nonsense. |O
I'd set up two '390s to divide the 10MHz ocxo to feed the phase detector with 1KHz (the fastest I could program that 6M to output on its PPS line) and spent many days trying to get the damned thing to lock, even resorting to that 4046's frequency/phase detector output which did eventually start to show signs of working for longer than the 15 minutes it would take to lock phase at such a glacial 10,000:1 division ratio from the OCXO to the PLL's phase/frequency detector.
At that stage I was waiting on delivery of a cheapish M8N (which has since proved to be a Chinese fake but not fatally so - it's what I'm currently using). I decided at that point to probe the phase detector inputs (after nearly a week of slowly going round the bend) and finally discovered that weird behaviour of the 6M's narrowing pulse :palm: - no wonder I couldn't get it to work! - in fact, I'm surprised I'd experienced those brief moments of short lived "triumph" even using the PD2 output from the 4046! ::)
I suppose it's just possible that this effect might not appear if it's left on its default 1PPS setting but I haven't tested this possibility since I've no immediate plans to try it out using Lars' GPSDO design where it might just be able to redeem itself. It had only cost me £3.99, delivered anyway so such testing can stay on the back burner for now, (or even forever - it only receives GPS svs anyway).
[2] I'd managed to burn out the PPS line on my first (genuine!) M8N module with a 12 volt jolt just over three months ago now :palm:, hence this replacement module from China which, unsurprisingly, is a fake (no flash and no SAW filter, judging by the anomalous results between externally mounted and internally mounted active GPS patch antennas). A CR2032 1KR and Schottky blocking diode solves the short 50 minute BBRAM retention time issue, giving me an estimated 250 days or better powered off retention time to protect my settings and maintain the RTC.
[3] The point at which it's no worse than the GPS positional error induced phase shifts can become (when the final excursions around the phase lock in point become lost in the GPS system noise).
JBG
--- End quote ---
Good to hear that you've been having some fun. It sounds as if you've duplicated quite a lot of my findings. I found that 100kHz locking was better that 1MHz (with some advice from Lars), I haven't really tried 10kHz but suspect that 1kHz is too low for sensible PLL filtering.
I would be tempted to build the filter section dead-bug style on a piece of copperclad rather than veroboard. It's not RF, but a solid ground is beneficial for keeping noise to a minimum (as is the buffer opamp as you found).
As you are aware, you are still compromised by the use of a non-timing GPS module. I'm not sure how much you've invested so far, but I see that there are still a few LEA-6T based modules being listed on ebay from China and Hong Kong for just over the £20 mark. You ought to get some performance improvement over an 8M (real or fake!). You may well get away with longer time-constants then.
Illusionist:
It's interesting to read what others are doing, and adjusting things to try them out here.
I've gone over to 100kHz, along with a different OCXO. It's a Chinese made, new (old stock, couple of years) OCXO with a marginally better specs and a lower adjustable range than the Swiss one I was using. 3Hz/V versus 10Hz/v. I'm thinking that can't hurt. It also runs a lot hotter.
I'm playing with the loop filter too. Later today I might try an active filter, since there's a dual op amp sitting there just as a buffer anyway. Being able to watch the startup up on the 'scope is useful (and fun!) as the PLL hunts, locks and stabilizes. I'm still getting used to having a good 'scope.
I even got the main PIC to generate the 10kHz, then 100kHz, signal for the PLL instead of the '390 divider. It's running from the OCXO so why not. That seemed to work OK, just took a little longer to settle but not much. It was a problem when I reprogrammed the PIC and restarted it though, which I'm doing quite often, having to then wait for PLL stabilization again before I could test the code. So I went back to the '390 divider.
I'm thinking of making the thing reasonably modular, once the design is stable enough to have some PCBs made. I already have the board I made for the neo-m8t which I designed to work both as a development board and final part of the GPSDO. I was thinking of putting the OCXO and PLL (or DAC if I go back to that route) on one PCB and the control/user interface/main PSU on a third board, and the output drivers on a fourth fitted on the back panel of the enclosure. That way I can swap a module out when I want to 'upgrade'. We'll see how it pans out.
Oh, and I was lucky enough to catch a couple of new neo-m8t's from a seller in France, for about £20 each. I gave up on the Chinese ones - every one I got was fake, including the m8n which didn't even have the flash inside the module.
I have some nice 18-bit calibration DACs on the way, should arrive today, so I might have another go at the MCU/DAC control method again later.
One thing I have noticed is that with that method, and my code, my derived (lower jitter) PPS very slowly goes out of sync with the GPS PPS. Clearly I'm not hitting the spot, although I can't measure any frequency error even over 10,000 seconds. With the PLL method the DPPS and PPS stay in sync within 20ns even after two full days running. I need to investigate that and look at my code. I want to roll my own code, but I'm not exactly familiar with writing filtering algorithms. I should probably learn though, otherwise I'm sort of wasting that 50MIPS dsPIC I'm using...
edigi:
My solution (not completed, but concept is tested and it works) is MCU based and I prefer that because of the great flexibility.
The 10 MHz xCXO frequency is directly measured with 60-100ps resolution (counters continuously run in both CPLD and MCU).
The concept is described here http://n1.taur.dk/permanent/frequencymeasurement.pdf but instead of the analogue interpolation I've used TI TDC7200 chip to measure the fraction (the TDC chip's clock input uses also the same 10MHz).
The end of the previous measurement/the beginning of the next measurement (basically the time stamping) is determined by the GPS output (actually another viewpoint is that the time period of the GPS output is measured with the 10 MHz reference). It can be from 1 Hz to couple of hundred Hz (but as others already wrote the GPS output must be integer fraction of its clock, in case of NEO 48 MHz) depending on SW configuration.
The upper limit is determined by the MCU's capability to handle the measurement and low pass filtering (since the time stamping signal from the GPS has big jitter even if the xCXO is very stable due to the jitter of the time stamping the measured frequency will be loaded with jitter as well). Aiming for too many measurements per second is pretty pointless in this case as nothing is gained with that but it can create many challenges.
The low pass filtering of the measurement results is done in the MCU thus very flexible; new filter means new algorithm is uploaded to the MCU.
The error from the low pass filtered measured frequency is used to drive a DAC (external or if the MCU has precise enough DAC even internal) that drives the voltage control of the xCXO.
If GPS output fails (no output at all or too jittery; or there are glitches that the MCU can reject/filter, which makes the MCU based solution better than the PLL based one) last xCXO control voltage can be held or if this is after switch on taken from MCU's flash.
Precision depends mostly on the phase noise and walk/drift of the xCXO (also the clock source of the GPS but let's assume that we use it as it is). In my view 12 digits is not impossible to reach with high quality xCXO (10 digit is easy with any decent quality), however that is beyond my needs and I also don't have any frequency counter to check that (the one that I've built is based on the same concept and it would be a bad idea to make cross check with it because of that).
Due to summer vacation I'm actually too busy with other things to go into details/progress this project...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version