My u-blox LEA-6T based fast locking GPSDO [experiment] - Page 1
Forum section: electronics / projects

author: Gyro
author_rank: Super Contributor
timestamp: April 28, 2016, 07:21:18 pm
content: This may take the title of simplest...and certainly the world's scruffiest 10MHz GPSDO.A while back I did a teardown of one of the cheap ebay u-blox LEA-6T GPS modules...https://www.eevblog.com/forum/projects/ebay-u-blox-lea-6t-gps-module-teardown-and-initial-test/msg886887/#msg886887It seems time to try to turn it into a 10MHz GPSDO. As mentioned it the previous thread, one of the good thing about the LEA-6T is two independently programmable pulse / frequency outputs. It also has simultaneous serial NMEA and USB data interfaces. The module is capable of putting out 10MHz, and although I found it usable for setting my frequency counter on a 10 second gate, it jitters badly because it is a non-integer divide of it's internal TCXO. If it hadn't been for this I might have been inclined to use it as-is, but I wanted a stable clock to slave my synthesized signal generator to. Also, I've had an ebay Efraton/Datum 105243-003 10MHz OCXO sitting around for some time waiting for this application.The first breadboard is shown below. I decided to use a 1MHz as the lock frequency with the GPS, It is an integer divide, and 1MHz is a useful output frequency. This makes the circuit even simpler than James Miller's simple GPSDO because it only needs a single divide by 10 stage (his relied on the Jupiter GPS with 10kHz output). I used half of a 74HC390 (divide by 5 followed by divide by 2 to maintain a 1:1 mark:space). I will probably use the other half to provide a 5MHz output too.For the phase comparator I went for a 74HC4046 (VCO disabled) rather than a simple XOR gate so that I could experiment with the different comparators; and also because it has self-biased frequency inputs, so that I could AC couple the 3V3 signal from the LEA-6T and provide accidental back-drive protection. The loop filter is very simple, with quite a long time constant of 10s (100k / 100uF Tant). I haven't yet managed to improve on this yet, but it does require Phase comparator 3 (the RS flip-flop one), I couldn't get reliable pull-in on PC1 (XOR) and PC2 seemed far too aggressive and hunted whatever the filter constants. I think the problem here is that, although there isn't non integer divide jitter at 1MHZ, there is still the characteristic GPS sawtooth superimposed on the signal as it isn't possible to sawtooth correct at higher than 1Hz and with data correction.I found that the Efratom OCXO has a 68k internal pulldown on its VFC input, so I had to buffer it with a CMOS opamp. That's about it, I paralleled the 100uF with a 100n to help with its ESR at 1MHz and put a 100R/100nF on the output of the opamp to help block HF noise into the OCXO. There's minimal supply decoupling at this stage and the VFC signal is on a clip lead! I also haven't split out the cable and adapter board supplied with the GPS module so the 1MHz signal is passing down the cable from my modified module alongside supply, 1pps, serial data etc. As I said, decidedly scruffy at this stage.Performance wise I am quite surprised. The OCXO has a measured frequency offset of 5.2 Hz /volt on the VFC input (26Hz over a 5 volt range), therefore 1mV shift equates to 5.2mHz / mV or 5.2e-10 of 10MHz. I found that the OCXO control voltage settles to a stability to less than 1mV within 6 minutes of a cold start, this includes GPS lock time (using my external active antenna, upstairs ceiling height), and OCXO warm up of 3 minutes (pretty fast). From a warm start the control voltage stabilizes to the 1mV level within about half the time, it 'rings' around the lock frequency but settles reasonably smoothly. The control voltage shifts by a couple of mV as the oven fully stabilizes but then remains stable within 1mV over several hours.I don't have the equipment to evaluate the output purity of the OCXO and a 5e-10 level is nearly two orders of magnitude better than my counter can resolve, but the OCXO control voltage is clean on the scope with no visible sawtooth remaining.I'm not sure about the merits of Phase locking at as high as 1MHz rather than 1Hz or 800Hz (I've seen mentioned in the u-blox timing app note). It does make it very easy to filter the comparator output pwm and avoids the jitter generated by several decades of asynchronous 74HC390 dividers. Opinions welcomed.The other photo shows the frequency counter (previously adjusted in reciprocal mode with the LEA-6T pulse output set to its maximum 60s pulse rate), OCXO VFC control voltage, and comparator PC3 output waveform (not very interesting really!).The next stage I guess it to actually build it (proper Manhattan this time), at least I know that noise wont be a problem. I also need to work out a reliable lock indication method, maybe monitoring the VFC shift using a micro (and decoding and displaying NMEA data at the same time), or maybe just a front panel monitor socket. I also need to implement some 50R output buffers using ACT14s.I hope this has some entertainment value anyway.

author: Gyro
author_rank: Super Contributor
timestamp: April 29, 2016, 11:55:57 am
content: A quick update.It looks as if a switched fast / slow loop filter time constant is the way to go. Once the loop is locked I found that it remains stable with the time constant increased to 100s (1M, 100uF). A fast time constant of 1sec (10k/100uF) gets the OCXO control voltage within lock range in a few seconds and should track oven warm-up easily. The Efratom OCXO has a convenient 'Oven OK' output that I can use to control the time constant switch.I've attached a trace of the jitter on the LEA-6T 1MHz output (red) versus the divided down OCXO. Jitter looks to be around 22ns p-p, when zoomed up to 10ns/div infinite persistence (the png for that one is too large to attach). Pretty much what would be expected I think.Hopefully extending to the long filter time constant will further increase stability with the fast mode still allowing fast startup.

author: jpb
author_rank: Super Contributor
timestamp: April 29, 2016, 05:22:32 pm
content: Thanks for sharing your experiments.I have a long term project of designing and building a GPSDO and seeing practical results from others is very useful. I have a board from Jim Miller, a collection of e-bay OCXOs as well as a new one I got with a discount voucher from Farnell. I've also collected various GPS units including the cheap Ublox-6T that you're using and a couple of 10kHz units. The one thing I never seem to get enough of is time!So it is nice to see you're documented progress.

author: Gyro
author_rank: Super Contributor
timestamp: May 07, 2016, 04:26:37 pm
content: Just a quick update on progress. After a brief interlude to obtain a replacement HC4046 (), I've now implemented the dual time-constant loop filter. Chip count is now up to four.I've used an HC4066 analogue switch, controlled by the OCXO /Oven-OK signal to switch from a 5 second time-constant filter for startup to a 100 seconds for normal running. This scheme seems to be working well, the fast filter is able to track the oven warm-up (once the frequency comes into range anyway) and is able to hold the OCXO control voltage within a couple of mV until the /Oven-OK signal goes active and the long filter cuts in. Within an hour the control voltage is stable within a couple of hundred uV with no fast excursions, even with the amount of wires hanging off it. The (10MHz) OCXO sensitivity is 5e-10 per mV as previously indicated.I'm still using the third phase comparator, PC3, of the HC4046 (pin 15) as this is most stable, but am now also using the PC2 output to gently drag down the loop filter voltage via a diode and resistor when its voltage goes too high. This further improves the lock time by reducing positive overshoot and removes a tendency for it to get stuck up there (not sure if this is due to the sawtooth nature of the GPS jitter). Due to the different phase relationships of the comparators PC2 sits high when PC3 is locked so doesn't interfere further.Just to reinforce that I'm not really a Timenut, I'm not looking for 1e-12. My goal is to be able to calibrate my Counter and use this as a reference for my synthesised sig-gen without having to wait around all day. At this point the frequency is stable to an order of magnitude better than the resolution of my counter within 5 minutes of a cold start... which is now a lot quicker than the OCXO warm-up of the counter.I was initially dubious about the idea of phase locking as high as 1MHz, but even with the jitter on the GPS module output the fast locking and stability is well up to my need. I haven't investigated the effect of dropping the PLL frequency to 100kHz, or increasing it to 2MHz yet, but it's on the list.Latest, increasingly Frankensteinian photo attached.

author: DimitriP
author_rank: Super Contributor
timestamp: May 09, 2016, 06:50:34 am
content: Quote

author: lars
author_rank: Regular Contributor
timestamp: May 10, 2016, 08:39:48 pm
content: Thanks Gyro,Couldn´t resist to test your good idea. Took away the Arduino promini on an Arduino GPSDO controller that happened to have the HC390+4046 and connected the 1MHz from the LEA-6T instead of 1PPS. I have a very stable OCXO in a box with a very small voltage control range of 4ppb (0-5Volt). The OCXO have earlier shown an ADEV of about 3E-12 at 100-1000secs. With a few cables I connected an RC filter (100k+1uF) between the HC4046 and OCXO. As I guessed I got about 250 seconds time constant so it took many minutes before lock. Enclose a picture of both my setup and an ADEV+MDEV chart. Below about 100secs the counter limits the result. Just below 250sec I think it is the OCXO ADEV that is seen and above 250secs the GPS gives the improvement in ADEV. My guess is that you may get an ADEV from the GPS 1MHz (after the RC-filter) that is around 1E-9 for 1sec, 1E-10 for 10secs and 1E-11 for 100secs. If the OCXO is better than the GPS at the time constant chosen it will limit the performance (but still work well). One thing with the 1MHz giving so low ripple after the RC-filter I believe is due to the GPS TCXO "48Mhz" is not exact. If it is exact it could give a sawtooth that moves the output. I warmed my module and could get a much higher ripple after the RC-filter (In other modules cooling may give the same increase instead).The reason I think I have 250 seconds time constant is that the phase detector has 1us range for 5Volts and the OCXO 4ppb (0.004us/s) for 5Volts. As long as the RC-filter has a shorter time constant than the phase detector range divided by the VCO range the time constant will be the latter. If the RC filter has a longer time constant it will be more complex and also it will be more prone to oscillations and ringing as the phase margin of the loop will be smaller. The Miller design with the 10kHz XOR have 50us phase detector range and an example with 1.6ppm (1.6us/s) OCXO range is given. This will give an time constant of about 32 secs and Miller has chosen an RC time constant of 16secs. As I am not an loop expert somebody may correct me if I am wrong.Your setup probably would benefit from using 100kHz or a smaller VCO range to get less gain in the loop.I myself prefer the XOR phase detector for filtered signals like this. The problem with the SR detector is, as you seems to have found out, that it gives a wrong filtered signal near what should be 0 or 5volts out. The problem is that it might lock on this wrong signal. The XOR is better in this case even if the gain is a factor two higher. In the Arduino GPSDO I also use the SR detector but as I measure the phase for each sample it doesn´t give the same problem as with an RC-filter.Lars

author: Gyro
author_rank: Super Contributor
timestamp: May 11, 2016, 09:57:49 am
content: Hi Lars,Thanks very much for putting the work in on this and for your advice.Yesterday I did more work on critically damping the loop filter (I've now have a 330uF Tant. in a series RC network across the filter cap), but I think you are right - too much gain. My OCXO has a 28ppm over a 5 volt range. I think I have read that there is some sawtooth in the internal locking of the 48MHz too, the reason that u-blox recommend an external OCXO.The dual time-constant arrangement is certainly helping me with the issue of lock time time, the short startup filter gets me me in the few mV ballpark before switching to the longer one although of course it doesn't speed up the settling time to higher 10E-??. I also get a small kick as the 4066 switches time-constants which is proving difficult to snub. I will try adjusting the time-constant in line with your suggestions, sadly I'm not a loop expert either.I agree that the XOR phase detector ought to be the best one to use in this situation... and it does work, but the PC3 detector showed less control voltage variation in my early tests for some reason. I need to work out why, or at least optimise for XOR.Yesterday I also tried modifying the PLL lock frequency to both 2MHz (highest common integer divide) and 100kHz. 2MHz seemed to work well. At 100kHz things become a lot more civilised, lock time is longer but smoother as you expected from the lower gain. Visible jitter on the LEA-6T is obviously greatly reduced - I am still not clear on the relative merits of phase locking on a cleaner clock edge at one frequency versus 100 times the number of significantly more jittery clock edges in the same time period. Given the options, 1pps feels like it's just too far away from best compromise.After an extended period at 100kHz, the OCXO control voltage is showing variations of sub 100uV. This points out a very glaring issue with my method of estimating frequency variation by control voltage. Touching the Efratom OCXO outer case for several seconds causes a slow but significant (several 100uV) shift in the control voltage. This is clearly thermal rather than electrical noise from the way it shifts and returns (no overshoot), I also found that the breeze when the window is open causes wider variations in control voltage and covering the OCXO improves it. A lot of the remaining control voltage variation must now be legitimate compensation of environmental influences. This means that I am now unfortunately past the point where I can accurately measure the frequency deviation.Chris

author: Gyro
author_rank: Super Contributor
timestamp: May 13, 2016, 06:33:06 pm
content: Some more work done on the loop filter values. I think I have achieved optimum values for 100kHz operation. Response is good enough now that I have dropped the switched fast-lock time-constant. It was becoming problematic optimising the filter for both time-constants and damping is so good now that the fast-lock would only save a couple of minutes, chip count is down to three again. The output is now useable (1e-10) within 5 minutes of a cold start, even though still settling.Filter components are now 100k / 33uF with 12k+330uF in parallel, so time-constant is around 30 secs. I'm also now using the PC1 (XOR) comparator and there is no longer any difference in performance between PC1 and PC3. The filter is now too damped for 1MHz operation, it rises slowly and takes an age to settle.I've attached a couple of traces of the loop filter performance over the first 3 minutes of operation. The first is for a warm start (OCXO already up to temperature). The lower trace shows the 1pps signal as an indication of GPS lock. Response is pleasingly well damped.The second trace shows a cold start. The PLL can be seen 'hunting' until the OCXO frequency comes within lockable range. Again it locks up smoothly and isn't that far behind the warm start trace. After a further couple of minutes, ripple drops below the 100uV level.

author: Miti
author_rank: Super Contributor
timestamp: April 24, 2018, 10:55:28 am
content: Looks interesting. Could you post a schematic please?

author: Gyro
author_rank: Super Contributor
timestamp: April 24, 2018, 06:17:30 pm
content: Sure, attached (I realized that I still needed to draw it first).The opamp is just a general purpose 5V rail to rail CMOS one, I can't remember what I used now - it's upside down.Edit: IC1 is a 74HC390, IC2 is a 74HC4046. IC supply connections and decoupling not shown.