My GPSDO project - Page 1
Forum section: electronics / projects

author: Mrt12
author_rank: Regular Contributor
timestamp: March 19, 2018, 09:15:39 am
content: Hi,I also want to build a GPSDO for usage in my lab. There are several designs out there, many of them using the Jupiter GPS module, which is obsolete, I think.So I wanted to make my own GPSDO.I use a uBlox LEA-8 timing module and a high-performance OCXO (I need extremely low phase noise for my application).My plan is the following:I will connect the OCXO to the oscillator input of a STM32F303 microcontroller. Then, a timer is configured such that it is clocked by the OCXO.The 1PPS signal from the GPS is used as a capture input, which means that the current counter value is latched in a seperate register if a rising edge on the 1PPS is detected.Then I will use an interrupt which compares the current counter value with the previously latched one. If the OCXO had exactly 10 MHz and the 1PPS would be exactly 1PPS, then the difference should be 10000000 counts. However, there will be an error, depending on the PPS jitter and the OCXO's deviation. So the resulting error signal will be filtered by a digital lowpass filter, and the result is fed to a DAC which controls the OCXO.Is this a valid approach? :-)

author: DimitriP
author_rank: Super Contributor
timestamp: March 19, 2018, 09:59:46 am
content: QuoteThere are a few out there. (http://www.jrmiller.demon.co.uk/projects/ministd/frqstd0.htm)As for the Jupiter being obsolete, the main "feature" of the jupiter was that it had a 10KHz output. But the LEA8 has a programmable output, (maybe two ) that can be set to ....10KHz, rendering the obsolesence of the Jupiter...redundant

author: DaJMasta
author_rank: Super Contributor
timestamp: March 19, 2018, 02:32:34 pm
content: If you're using the PPS output, there's no need to spring for the expensive timing module if going the ublox route, as the PPS output is effectively the same across their range (and back a few generations). The adjustment step size is also somewhat coarser than I had been hoping for, around 20ns, so when the one second mark falls right between two adjustment steps, you'll see constant fluctuations around it every few seconds.That said, it's easy compensate for by just waiting a number of seconds before doing the math to make your adjustment step. If instead of 10M, you waited for 1G, then you'd have 100s worth of averaging of the adjusting signal and would be adjusting to, but I think many good disciplining algorithms can use an order of magnitude or two more data to make their adjustments - which is not that hard to do with a micro and a counter. Then maybe increase the number of seconds averaged in your OCXO adjustment calculation as the total uptime with a lock increases.

author: Theboel
author_rank: Frequent Contributor
timestamp: March 19, 2018, 11:00:01 pm
content: Hi,I love to see Your design use STM32F303for information there is some people use uC as parts of their GPSDOlike this :https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/msg1278672/#msg1278672from a user like me (stupid in programming) the thing I "complain" from lars design is no position display and no programmable output.the other design sell in cheap enough is leo bodnar designhttps://www.eevblog.com/forum/metrology/leo-bodnar-mini-precision-gps-reference-clock-teardown/msg1398826/#msg1398826no position but with programmable output

author: Squiddaddy
author_rank: Regular Contributor
timestamp: March 20, 2018, 05:17:01 pm
content: I am going to build Lars' design once I finish up getting my TruePosition going. I was originally going to build, but then lucked into the commercial one cheap, but I'm still going to build for the learning experience.I'm anxious to see how close I can get with a DIY design.With the uBlox, you can change the timing pulse, so you can try out the James Miller PLL circuit too very easily.I may even try his design with a 1MHz pulse instead of 10kHz.If you get good with the Arduino, you can add display support to Lars' design.Or use a blue pill STM32 micro.Plenty of DIY options.

author: Mrt12
author_rank: Regular Contributor
timestamp: April 05, 2018, 09:43:58 am
content: Hi Guyssorry for my late reply.I think if I use this approach - capturing a free-running counter value with the 1PPS signal - I can implement kind of a PLL in software.What I am currently unsure about is the design of the loop filter.With every PPS rising edge I get a 'timestamp' of the counter counting with the 10MHz clock. By calculating the difference to the previous time stamp, I can find out how many clock cycles happened since the last PPS pulse. And if I then subtract 10MHz from this value, I get the phase error. Of course, because the PPS signal has a jitter, this phase error signal will have a jitter as well, so I will need a loop filter. This loop filter probably could be a FIR or IIR filter, and the filter output is then fed to a DAC which then drives the EFC signal for the OCXO.For a first test, I plan to use a simple lowpass filter as loop filter. However, how do I find out the correct number of taps and the corner frequency of that filter?

author: Gyro
author_rank: Super Contributor
timestamp: April 05, 2018, 07:33:29 pm
content: Quote from: Squiddaddy on March 20, 2018, 05:17:01 pmJust throwing in a link to my simple PLL based experiment using a uBlox 100kHz / 1MHz output (spotted the 1MHz pulse reference)... and no, it's still not cased!https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg929133/#msg929133

author: MosherIV
author_rank: Super Contributor
timestamp: April 05, 2018, 08:09:34 pm
content: QuoteIn order for 'timestamping' to be of any use, your system timer must be at a minimum 4 times faster than the freq that you are trying to measure and even that only gives you quadrature phase detection.I am not sure how you are going to subract 10MHz from the time stamps. You would need to have a 3rd time stamp at the moment 10million cycles happened.The jitter in the 1PPS would actually cause you a problem with this scheme because I do not think you can filter it out with FIR or IIR. The only way I know of getting rid of the jitter is to average it out over a very long time period.A simpler way of doing this is to use the 1PPS to gate a count of the ocxo freq and average that out over a long time. The will give you an average error which then needs to be corrected (up or down) then start the process again.

author: texaspyro
author_rank: Super Contributor
timestamp: April 06, 2018, 03:31:46 am
content: Check out Charles Wenzel's simple GPSDO:http://www.techlib.com/electronics/GPSstandard.htm

author: Theboel
author_rank: Frequent Contributor
timestamp: April 08, 2018, 12:50:02 pm
content: Quote from: texaspyro on April 06, 2018, 03:31:46 amWenzel technique is interesting use sample and hold system is there any actual measurement for this GPSDO ?

author: Cerebus
author_rank: Super Contributor
timestamp: April 08, 2018, 03:45:03 pm
content: Quote from: MosherIV on April 05, 2018, 08:09:34 pmHis 'timestamp' is the output of a 10MHz counter, driven by his VCO/OCXO/whatever, gated by the 1 PPS signal.QuoteHe expects his counter 'timestamps' to be the count of his 10MHz clock, So if on one PPS capture of the clock he gets a count of X and at the subsequent capture he gets a count of X+10,000,000 he knows his clock is correct; if he gets X+9,999,999 he knows his clock is slow, X+10,000,001 and it's fast.QuoteFIR or IIR are just digital filter implementation techniques. It's trivial to build a low pass filter with an IIR filter. What is a low pass filter but an average over time? BTW the jitter in the 1 PPS clock is probably going to be on the close order of +/- 15 ns, so that's a jitter of 15 parts per billion or 0.0000015%. It doesn't take too much filtering to get that down to the 'who cares' level. A 100s moving average would probably dilute the jitter to better than the innate short term stability of any oscillator that any of us could afford to buy.What's of more concern is that the granularity of a 10MHz clock is 100 ns - so the innate error of +-50 ns in the sampling of the 10 MHz clock by the 1 PPS signal is going to swamp the jitter in the 1 PPS signal by a factor of over 3.What's really wanted is to achieve the same effect as a classic type II phase/frequency detector, which effectively measures the time difference between the 1 PPS clock edge and the edge of a 1 Hz clock derived by dividing down the 10 MHz oscillator signal. That's easy to do with 100 ns granularity, which is what the OP's current design offers, but to get to a granularity lower than the clock period requires some analogue electronics, either in the form of a classical analogue PLL with a type II detector or using a time-to-digital convertor to capture the edge differences in the two clocks at finer granularity.By coincidence I'm working on a design for something that looks a lot like that. I have a Trimble Resolution-T GPS timing receiver. This has a 'sawtooth correction' output that allows one to correct the jitter in the 1 PPS clock edge to around 100 ps or so. The problem is that you get this correction supplied as a text output message from the GPS quite some time after the clock edge that it refers to. So I need a hybrid PLL that is at least part digital so that the sawtooth correction can be added into the PLL loop 'after the fact'. This is not trivial. The current rough design has an FPGA to handle the counters, 10 MHz divider and type II phase/frequency detector, and an analogue time to digital converter to measure the edge differences to 100 ps, all followed by an MCU, DAC and OXCO to close the loop.The truly tricky bit, which I haven't figured out yet, is how to convert the jitter reduction that all this offers into a re-timed 1 PPS output, without having a 10 GHz clock around. Without that the only useful feature that this hybrid design would offer is faster lock to GPS than is possible with the long time constants needed to average out the +/-50 ns sampling jitter in the basic 10 MHz divider type design. That alone would not be worth the added complexity required to incorporate the sawtooth correction.QuoteThat's what he's doing.

author: DimitriP
author_rank: Super Contributor
timestamp: April 08, 2018, 09:40:45 pm
content: QuoteThe last time I was intrigued by this I stumbled on the DALLAS DS1023 family of parts (around $14 from Mouser).This took me into the "I know what I don't know" territory and left it alone for now

author: Cerebus
author_rank: Super Contributor
timestamp: April 08, 2018, 10:25:13 pm
content: Quote from: DimitriP on April 08, 2018, 09:40:45 pmInteresting, very interesting. I'd forgotten that there were parts like this around. This might be just the kind of thing to use to generate a resynchronising delay. I was toying with the idea of building a sort of backwards dual slope time to digital convertor. (A dual slope time to digital convertor is what I designed in to get the inter-edge timing from the type II phase detector). Off for a hard think...

author: texaspyro
author_rank: Super Contributor
timestamp: April 08, 2018, 10:52:16 pm
content: The problem with using delay lines to adjust the PPS output for sawtooth correction is that many (most?) GPS receivers that report sawtooth corrections send the sawtooth message AFTER the 1PPS pulse. Those receivers expect you will use the sawtooth values to correct a "paper" 1PPS during data post-processing and correct it after-the-fact. Receivers that send the sawtooth message after the 1PPS are rather useless for doing real time hardware corrections.Also, most receiver documentation does not bother to tell you if the sawtooth message comes out before or after the 1PPS. They also don't mention whether you use positive or negative numbers for antenna cable delay compensation.

author: DimitriP
author_rank: Super Contributor
timestamp: April 09, 2018, 01:13:06 am
content: It seems to me that unless the OCXO is adjusted once per second every second (yeah that sounds wierd to me too) there is "time" to make the adustment in the next cycleThe way I think of it is if every hour can be up to minute off, and you don't adjust at all, during a 24 hour period you could be off exactly 0 minutes (if everythings averages itself out) , or worse case scenario 25 minutes over or 25 minutes short with no idea which.Now, if every hour the clock is adjusted by how much off the previous hour was , worse case you are off by exactly no more than 2 minutes at the end of the 24 hour period.Corrections welcomed and apologies for the temporary thread hijack

author: Cerebus
author_rank: Super Contributor
timestamp: April 09, 2018, 01:13:29 am
content: Quote from: texaspyro on April 08, 2018, 10:52:16 pmNot how I'm looking at doing it. The delay line, if used, would be just an adjunct to achieving lock sooner, not the method of applying the sawtooth correction to the incoming PPS pulses.The advantage of running a PLL control loop in software is that you can do the sawtooth correction a little bit later in time than you would have to do it in an analogue PLL. After all, you're going to be feeding it into a filter with a time constant of 10s, possibly hundreds, of seconds, so a few milliseconds delay in changing the input correction to that filter is really neither here or there.What I've got so far is the basics of a classic analogue PLL with a type II phase/frequency detector. The counter, divider and phase detector for this will be implemented in an FPGA. Where there would be an analogue low pass filter in the analogue PLL instead the 'up' or 'down' pulses from the phase detector go to a time to digital converter, thence to an MCU, the MCU drives a DAC, which drives the OCXO. So basically, the low pass filter is replaced with some digital shenanigans. The time to digital converter gives me the timing of the physical PPS pulse relative to the OXCO clock. The sawtooth correction also goes to the MCU and can be added or subtracted from the figure obtained from the time to digital convertor. Thus the correction amount that goes into the loop filter is sawtooth corrected but delayed by a few milliseconds from where it would have arrived. That, if I've got my maths right, may lead to a small steady state error that can be compensated for. Done this way the sawtooth correction can be used in real time, rather than as an 'after the fact' paper correction.The reason for using an FPGA, rather than just an MCU timer, is so that the counter can be synchronously zeroed at startup by a single PPS pulse, but then left to free run and generate a pukka hardware local 1 PPS signal. That reset gets me closer to phase lock immediately, without having to wait (potentially a very long time) for the PLL loop to pull the 1 Hz clock derived from the 10 MHz clock around into lock. I've an OCXO that's guaranteed to be less than 400 ppb away from 10 MHz, in fact is 150 odd ppb fast when free running, can be steered by +/- 400 ppb and so I ought to be able to achieve a comparatively short lock time. One LSB on my DAC is about 195ps/s phase shift and the sawtooth correction from the Trimble Resolution-T has a 100 ps granularity.That initial synchronous zeroing includes the physical sawtooth error associated with the GPS local clock (selecting a 12 odd MHz clock edge, which amounts to +/-15ns). So I'd like to be able to generate a second resynchronising pulse at approximately the right time (rather than on the next clock edge) to injection lock the local oscillator and that pulse is what would need a variable, non-clock derived, delay . That said, I suspect that what I would gain in improved lock time is small compared to the effort it would entail, whereas reducing the jitter from sawtooth errors is definitely worthwhile as it contributes to phase noise in the local, disciplined clock.Bear in mind what I've got at the moment isn't a completed design. The verilog for the FPGA is mostly written, the analogue side of the time to digital converter is designed and simulated (but needs my current 'orrible input level shifter design replaced with something more elegant). Next step is to write the verilog for the digital part of the time to digital convertor (including the cycle by cycle recalibration) and breadboard the whole hairy mess with an MCU.

author: lars
author_rank: Regular Contributor
timestamp: April 20, 2018, 09:01:43 pm
content: If you have a GPS module with 1PPS and an OCXO with voltage control I think it is a good idea to build a GPSDO.Mine is easy to start with (https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/?all). If you want to do your own controller read page 8 in my instruction to learn more about the low pass filter and PI-loop. Page 15 also have good links to other designs and control loops.If you design your own controller the first thing I suggest is to learn is how to get good "time stamps" between the PPS and 10MHz. Setting a DAC (inbuilt or external) comes as next step to see how the "time stamp" counter works. Building the loop comes later. (Not to say all error handling and interface).If you want low phase noise as the OP I would start with selection of an OCXO that matches the requirement. For all times shorter than 1 second and frequencies higher than 1Hz a good GPS controller wouldn't do anything to the OCXO.A good OCXO will be enough stable out to at least 100 seconds so the 1PPS and the controller should not disturb the EFC (voltage control line) on the OCXO unnecessary on higher frequencies.This is why taking the second to second jitter out of eg uBlox module is not meaningful. For a correctly designed loop the range of 100 to 1000 seconds of filtered "time stamps" are more interesting. This is what you see in the ADEV and especially the MDEV curves for GPS modules. The MDEV is more like a low pass filtered "time stamp" see for examplehttps://www.eevblog.com/forum/projects/ocxo-stable-reference-and-control-voltages/50/comparing position and timing modules with indoor and outdoor antennas. At 200-400 secs that is an important point for GPSDO's the timing model LEA-6T in fixed mode with an outdoor antenna is many times better than an indoor position NEO-6. At tau 1 second (second to second measurements) the ADEV and MDEV are almost exactly the same (as the jitter is 20ns p-p for all configs).Still I think a NEO-6 or 7 are a very good choice if you have a good outdoor antenna. For me an outdoor patch antenna have worked ok.For a good OCXO with a 500 second time constant and a 250 second low pass filter (IIR) my assumption is that the 20ns second to second jitter is attenuated first by 250 to 0.08ns by the low-pass filter and after that by the proportional term by 500. So the frequency change second to second is 0.16ps/s to the DAC. This is also what I see on the serial output of my controller. As it is drowned in the noise from both the OCXO and especially my counters (resolution 20ps) I can't confirm it on the real output signal.Lars

author: jpb
author_rank: Super Contributor
timestamp: April 20, 2018, 09:18:41 pm
content: Quote from: lars on April 20, 2018, 09:01:43 pmUseful information, thank you, especially the practical measurements.One thing though, I think that the 500 second time constant will reduce the variance by 500 which will reduce the deviation by sqrt(500) which is much less (factor of around 22).

author: mark03
author_rank: Frequent Contributor
timestamp: April 23, 2018, 02:30:49 pm
content: Quote from: lars on April 20, 2018, 09:01:43 pmLars, thanks for sharing your design. I saw it several months back and still thinking about it from time to time, although I haven't started my own project yet.Is the preceding still true if the 1PPS jitter is not white? What I see from folks on time-nuts and other places is that the beat pattern between the GPS module clock and the true 1PPS leads to so-called "hanging bridges" in the sawtooth error, where the error has the same polarity for many seconds or minutes, as it turns around and starts to drift in the other direction. I was never clear if sawtooth correction would be worthwhile to correct for this in a typical amateur GPSDO, or if, as you say, it's just buried in the noise.

author: lars
author_rank: Regular Contributor
timestamp: April 24, 2018, 08:01:13 pm
content: Quote from: jpb on April 20, 2018, 09:18:41 pmWell first remember what I say it is a second to second change of 20ns, useful eg to know if it affects eg narrowband microwave communications. For longer times it gets worse (until about the time constant). So the Arduino just do the math with the low pass filter (250s) and P-term that is 1/500 (kp=0.002), The I-term in this case (ki=0.0000013) and in all locked conditions for second to second is small, but it might not be so in out of lock condition when the I-term tries to take the phase back to zero. Ok so it is only these three terms involved in the Arduino between the time reading and the DAC (if still locked). So I still say it is a very small second to second jitter on the (perfect) OCXO of 0.16ps/s (1.6E-13) due to the 20ns p-p jitter from the 1PPS. If the 20 ns jump persists as mark03 so correct say will happen with the so called hanging bridges or another reason it still will not be worse second to second. I have seen 25-30ns jumps that stays for hours that I blame one of my patch antennas for during direct sun (black roof probably gets very hot). Also satellite changes with multipath will give long lasting jumps but probably more in the 5-10ns range max.Ok a 20ns jump will the next time move the low pass filter another 80ps and the P-term another 0.16ps/s. This will go on for about 400-500 seconds but with smaller and smaller steps. Until a (perfect) OCXO has about 30ps/s (3E-11) error. Now the error in frequency will drag the input time , through the low-pass filter and P-term back to zero again (and a little the I-term). In the links of my GPSDO you find Tom van Baak's GPSDO simulator that will show this if fed with correct data. I also have an excel spreadsheet but will not share it because it is to complicated to explain the function in that and my health has been worse lately. This also is what I see with an OCXO but together with some noise and drift.About hanging bridges. I would not say sawtooth correction is useless and drowned in noise. If I said that it were wrong. I still say as I say in the link to that ADEV and MDEVs above that it depends on low pass filter time. As an experiment I took 100ksecond data of sawtooth correction from an LEA6T and lowpass filtered it with 250 seconds. The +-10ns went to +-2ns maximum. I didn't check the lengths of the hanging bridges but some were quite long. I also guess the longer the hanging bridge the more seldom it will appear from a statistical view. At some point the noise in the TCXO in the GPS module will make even longer hanging bridges impossible I think.I have many times thought of implementing sawtooth correction and an LCD in the controller but when it will not be a general purpose flexible controller any longer as it is far to many GPS modules with different protocols. Just see Mark Sims (texaspyro) excellent LH program! Sometimes I hope Mark will implement a second channel for reading my controller that is the TIC, DAC and temperature fields together with an arbitrary GPS module.Probably if I were going to implement sawtooth correction and an LCD I would use another processor to keep the GPSDO controller robust without a lot of testing. Programming is not the problem (even if I am a poor programmer) but the testing. Just adding an input for the sawtooth correction value and add it to the time reading I guess is what I would do for the existing processor. Of course with an output from the second processor that already have decoded this and all other information for the LCD. But I guess it will not be me doing it.Lars

author: jpb
author_rank: Super Contributor
timestamp: April 24, 2018, 08:50:05 pm
content: Quote from: lars on April 24, 2018, 08:01:13 pmThank you for your detailed posting - I'll need some time to digest it. My comment about the variance was based on considering the jitter on the 1pps as noise and averaging over 500 samples, the variance in the sample mean reduces as sqrt(n) e.g.:http://sepwww.stanford.edu/sep/prof/pvi/rand/paper_html/node16.htmlbut you are considering the effect of the change on the tracking of the OCXO which is different. The sqrt(n) result is what shows up on ADEV plots of GPS 1pps.I was thinking more along the lines of how accurately we can estimate the true 1pps from the measured values. Of course we are not taking a mean anyway - if considering frequency we would be concerned with the slope and the variation of the slope is different again but it starts to get a little complicated, at least when I'm feeling tired:https://people.duke.edu/~rnau/mathreg.htmbut I think it works out slightly better than the reduction in variance of the mean.I was more thinking about the information available from the PPS over a fixed interval, but of course the integral term in the controller means that information is used over a much longer time span.

author: Mrt12
author_rank: Regular Contributor
timestamp: June 19, 2018, 06:57:00 am
content: Hi guys,I built my own GPSDO based on a STM32F303 microcontroller and a high quality OCXO which was selected for lowest phase noise.My GPSDO kind of works, but when I compare it to a commercial GPSDO from Meinberg, I am unsure whether it is really stable.I am using a LEA8T timing module. The microcontroller gets its clock from the OCXO and uses the internal PLL to generate a 60 MHz core clock. This clock is then used for a 32 bit timer. With the PPS output from the GPS module, I perform a timer capture, which means that on every PPS rising edge the timer contents are latched to a capcutre register and an interrupt is generated. In the ISR, I compare the currently latched timer value to the previous one. The difference should be always 60e6. If this is not the case, I increase or decrease the DAC accordingly. But at the moment I am unsure whether this approach will work because my own GPSDO seems unstable compared to the professional one - sometimes it is slightly 'too fast', and sometimes 'too slow'.I attached the OCXO portion of the schematic. I have already replaced the LM4040 on my PCB by a REF3225, but no improvement so far :-( what could I be doing wrong then?Is it a problem if my GPS module receives both GLONASS and GPS at the same time?

author: iMo
author_rank: Super Contributor
timestamp: June 19, 2018, 11:40:14 am
content: It could come from the F303's PLL. I did some measurements with stm32 in past (8MHz Xtal + internal PLL) measuring the PLLs frequency and I got a nice sawtooth shaped result with around 20-30Hz amplitude (no GPS used).

author: Mrt12
author_rank: Regular Contributor
timestamp: June 19, 2018, 02:06:12 pm
content: Oh, wow, interesting. I checked the F303's datasheet, and it says that the PLL has a worst case jitter of 300 ps per design. I wasn't expecting a 20..30 Hz frequency modulation. But I will check it, by simply disabling the PLL. Thanks for that hint!

author: Tom45
author_rank: Frequent Contributor
timestamp: June 19, 2018, 03:54:01 pm
content: Quote from: Mrt12 on June 19, 2018, 06:57:00 amI'm curious how you selected for lowest phase noise.Tom

author: iMo
author_rank: Super Contributor
timestamp: June 19, 2018, 03:55:59 pm
content: Quote from: Mrt12 on June 19, 2018, 02:06:12 pmI did with stm32F103, PLL freq measured against OCXO based fmeter. Below the measurement (it was 72/2=36MHz at the output, last 3 digits shown on Y axis).

author: Mrt12
author_rank: Regular Contributor
timestamp: June 19, 2018, 06:55:23 pm
content: @Tomthere is an OM in Germany who owns a company called AXTAL. He manufactures OCXOs. I told him that I need <-150dBc phase noise, and he selected one of his devices. He even gave me an 'OM discount', which is absolutely awesome. I got the OCXO with the associated test report, showing that my desired phase noise and harmonics specs are met.@imo:interesting. I would never think the STM32 PLL is that bad. But you are right, I disabled the PLL, and now, my frequency is spot on compared to the professional GPSDO. The phase drift is around 0.1deg/min, which is quite nice I think. I let the GPSDO run over night and check the drift tomorrow, I am curious whether it will improve as the device runs for a longer time.

author: jpb
author_rank: Super Contributor
timestamp: June 19, 2018, 08:22:15 pm
content: Quote from: Mrt12 on June 19, 2018, 06:55:23 pmJames Miller used AXTAL ocxos in his gpsdo:http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm

author: iMo
author_rank: Super Contributor
timestamp: June 20, 2018, 06:52:05 am
content: Quote from: Mrt12 on June 19, 2018, 06:55:23 pmPLLs of all MCUs are bad for this kind of applications..

author: Mrt12
author_rank: Regular Contributor
timestamp: June 23, 2018, 06:29:00 pm
content: Today I implemented a very simple control software for the GPSDO. I used a HP 53131A counter to measure frequency, and it looks like the GPSDO has reached 10.000 000 000 MHz after approx. half a day. I used the commercial GPSDO as reference for the counter.What I now would like to do is to implement a more sophisticated control algorithm which allows for faster lock times, i.e. the GPSDO shall reach 10.000 000 MHz after, say, a few minutes. I think this could be possible with a PLL, no?My first idea for the PLL was that I use a 'reference phase' variable, which is incremented each second by 10000000. The captured timer value is compared to the reference phase, the difference is used for DAC steering.... is such an approch theoretically possible? my first experiments showed it is quite unstable and does not lock at all. The other approach is to subtract the previously captured value from the current one and the difference needs to be 10000000 all times.

author: iMo
author_rank: Super Contributor
timestamp: June 23, 2018, 09:43:07 pm
content: QuoteAll similar methods suffer from following issue - your "sampling resolution" is always 1 ref clock (or 1 counter count). You have to go much deeper, many orders of magnitude inside the 1 counter count (the phase difference), as within the phase difference (0..1clock_duration) all the miracles happenWhen you want to get the phase difference fast (at each "sample") the way to go is in the "analog time" domain - for example with a "time interpolator" (ref_edge to sample_edge time difference converter).Thus at each sample you get the digital counters differences (new-old with 1 count resolution) AND the time difference hidden within the 1 count (a fraction of the 1 count). By combining both values you may get ~ps resolution at each sample. With such an value you may drive your OCXO (via DAC) fast, without waiting many hours till you get a "good average"..PS: this approach assumes an "ideal" ref freq source. With jitter and sawtooth coming from a gps module you have to make some avaraging/lowpassing, sure.Btw - the "sawtooth error" with GPS modules - I think it has nothing to do with GPS but rather with sub-optimal mcu's PLL design used in those modules (you can see the sawtooth error without involving any GPS into the measurement, as I wrote above).

author: Mrt12
author_rank: Regular Contributor
timestamp: June 24, 2018, 11:37:35 am
content: sure, I know about the interpolators. The HP 5335A counter for instance also has a start and stop interpolator. This is the reason why I wanted to use the PLL, to increase the resolution. I also thought about making an analog interpolator, but I only found very little useful information. I would like to make a second version of my GPSDO later, as I already see some drawbacks of my simple approach - but next time with an analog interpolator :-) can you give some hints about this topic?Does not using an interpolator mean that my GPSDO is useless, or does it only mean that it takes longer until it locks? I mean - after 1000 sec, I can also measure 1 mHz frequency deviation. I expect the ideal loop time constant being around 1000 sec.

author: iMo
author_rank: Super Contributor
timestamp: June 24, 2018, 11:57:55 am
content: QuoteUsing a time interpolator for getting the "numeric value" of the phase difference is required when you want to get the precise information at each sample interval (ie. you get 10000000.5673 counts as the result at each sample).When not using the phase value your measurement is of +/- 1 count resolution and you have to average those "integer" counts within say 1000secs to get the "fraction of the 1 count" hidden inside (your "milliHertz resolution").Both methods are theoretically "identical" when talking longer measurement periods (and some other assumptions).QuoteAll modern ($$) counters use a kind of an interpolator.The analog ones are easier to make - ie. a ramp generator started by ref edge and stopped by the signal edge and the actual ramp voltage sampled by an 10-16bit ADC (for example 0.000ns phase difference reads 1Volt and 99.999ns reads 4Volts off the ramp, provided your 1 count is 100ns). The ramp generator could be a simple capacitor charged via a current source (to get a linear readings).The ADC value is then converted to the "1 count fraction", and combined with the integer counter's value (or better to say "combined with the counter's ratio") you will get those 10000000.5673, as an example.What the modern counters also do is they use "sampling" of a continually running counters (ref/signal) without zeroing their values between the measurements (and they do "new-old"). Therefore you are not loosing the phase's trend information.That counters are ie. called "reciprocal counters with time interpolators". You may do, for example, 1000 measurements/samples per second with a milliHertz resolution (with some math involved).

author: mino-fm
author_rank: Regular Contributor
timestamp: June 24, 2018, 12:57:05 pm
content: Quote1000 samples per second, 1 mHz resolution, @ 10 MHz? I think that's not realistic.The easiest way of interpolation is using a TDC7200. It works well at 10 MHz to give 100 ps resolution. This is 1000 times better than using the 10 MHz clock only.

author: iMo
author_rank: Super Contributor
timestamp: June 24, 2018, 01:09:05 pm
content: For example the TDC7200 is the "digital" type of an interpolator, running a "ring oscillator" on the chip as the ref clock (perhaps in a few GHz region) while measuring the number of ref clocks between the start-stop edges.

author: Mrt12
author_rank: Regular Contributor
timestamp: June 24, 2018, 01:47:08 pm
content: yup, I also do the sampling of the free running counter. The counter never stops, but at the 1PPS rising edge, the counter value is captured into another register which can be read later.The interpolator with the capacitor is actually all I know about the interpolators. I am afraid that this won't work with my OCXO because I have a sine wave, and I would need to convert it to square to trigger the interpolator.... which is pointless because I actually do want the sine! and do I need to charge the capacitor on every rising edge of the clock, such that the capacitor is fully charged after 100 ns? Because I never know in advance at which clock edge the next PPS pulse arrives... and then, when do I discharge the capacitor? what if the PPS pulse arrives during discharge? there are lots of questions, and I was too unsure about the start and stop interpolator, this is why I decided to make my first approach without interpolator and see what results I can achieve.

author: iMo
author_rank: Super Contributor
timestamp: June 24, 2018, 01:56:09 pm
content: Code:..there are lots of questions..Yes, you are right. I built such a counter and it is not easy as theis literally in every detailFor your GPSDO project: If I were you I would start with some proved and well documented design, and I would do small step enhancements when the stuff works..

author: texaspyro
author_rank: Super Contributor
timestamp: June 24, 2018, 05:25:24 pm
content: Search for "Lars GPSDO". He implements a very simple interpolator based GPSDO on an Arduino.