My GPSDO project

[Mrt12]

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? :-)

[DimitriP]

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.

There 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

[DaJMasta]

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.

[Theboel]

Hi,
I love to see Your design use STM32F303
for information there is some people use uC as parts of their GPSDO
like this :
https://www.eevblog.com/forum/projects/lars-diy-gpsdo-with-arduino-and-1ns-resolution-tic/msg1278672/#msg1278672
from 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 design
https://www.eevblog.com/forum/metrology/leo-bodnar-mini-precision-gps-reference-clock-teardown/msg1398826/#msg1398826
no position but with programmable output

[Squiddaddy]

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.

[Mrt12]

Hi Guys

sorry 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?

[Gyro]

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.

Just 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

[MosherIV]

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.

In 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.

[texaspyro]

Check out Charles Wenzel's simple GPSDO:

http://www.techlib.com/electronics/GPSstandard.htm

[Theboel]

Check out Charles Wenzel's simple GPSDO:

http://www.techlib.com/electronics/GPSstandard.htm

Wenzel technique is interesting use  sample and hold system is there any actual measurement for this GPSDO ?

[Cerebus]

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.

In 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.

His 'timestamp' is the output of a 10MHz counter, driven by his VCO/OCXO/whatever, gated by the 1 PPS signal.

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.

He 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.

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.

FIR 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.

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.

That's what he's doing.

[DimitriP]

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 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

[Cerebus]

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 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

Interesting, 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...

[texaspyro]

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.

[DimitriP]

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 cycle

The 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

[Cerebus]

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.

Not 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.

[lars]

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 example https://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

[jpb]

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 example https://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

Useful 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).

[mark03]

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, 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.

[lars]

Useful 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).

Well 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

[jpb]

Useful 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).

Well 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

Thank 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.html

but 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.htm
but 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.

[Mrt12]

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?

[iMo]

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).

[Mrt12]

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!

[Tom45]

Hi guys,

I built my own GPSDO based on a STM32F303 microcontroller and a high quality OCXO which was selected for lowest phase noise.

I'm curious how you selected for lowest phase noise.

Tom