Yet another DIY GPSDO - yes, another one

[AndrewBCN]

Hello,
I have been following the thread by the late Lars about his inspirational DIY Arduino GPSDO project. And I checked the dozen or so GPSDO projects published on the net.
Then I decided to join the party and design and build my own. 
I didn't quite know what I was getting into, but after a couple of months waiting for the parts to come from China, and then another couple of months writing the firmware, I have a working, blinking, timekeeping and happily and precisely oscillating GPSDO. 
The main differences with Lars' design are:
- Modular and as much as possible, follows the K.I.S.S. design rule.
- It's based on an inexpensive yet powerful 32-bit STM32F411 MCU development board, the WeAct Black Pill running at 100MHz.
- It uses a digital FLL, not a digital/analog PLL. New! It can also use a PLL, see post #131 on page 6 in this thread.
- It can be put together on a breadboard in one afternoon (provided one has all the parts).
- It works practically "out of the box". There is nothing to adjust.
- It has an optional small OLED display.
- It has an optional BMP280 atmospheric pressure and temperature sensor.
- It has an optional AHT10 temperature and humidity sensor. Note: for new builds, the drop-in compatible AHT20 replaces the AHT10, same cost, slightly better accuracy.
- New! It has an optional INA219 current/voltage sensor to monitor the power consumption of the OCXO.
- It has an optional Bluetooth interface, so you can control it from your smartphone.
- New! It has an optional "Atomic Clock" display in big bright red, green or blue LED digits using a TM1637 display module, with the classic 1Hz blinking colon!
- New! Optional UTC-aligned 1PPS output using a picDIV. http://www.leapsecond.com/pic/picdiv.htm
- The BOM is very short and all the bits and pieces are easy to find and order.
- Total cost is around 30€ 40€ (that's around US $35 $45) for the stripped-down version, < 50€ 60€ with all the bells and whistles. Note: as of March 2022, with the recent semiconductor shortage and rising prices of components, the total cost has increased correspondingly.

Like with Lars' design, any OCXO, DOCXO or even rubidium frequency standard can be used, but the recommended oscillator is an inexpensive used square wave 10MHz 5V OCXO, which is what I am using in the breadboard prototype. These OCXOs are available from various sources on the net, recycled from decommissioned telecom equipment and sometimes still soldered onto a piece of PCB, for around 10€ or less (< US $12). The OCXO is the most expensive part in this GPSDO.

The second most expensive part is the GPS receiver module. I strongly recommend a u-blox Neo-M8 GPS module with an SMA antenna connector. With a u-blox Neo-M8, I am still getting 5~9 satellites even indoors in my basement cave lab. The much cheaper Neo-M6 struggles to get a fix in the same conditions.

The open source code in C/C++ (the firmware for the MCU when compiled) and documentation are available on GitHub, here: https://github.com/AndrewBCN/STM32-GPSDO

Here is the BOM: https://docs.google.com/spreadsheets/d/1BZbZeLiag-d61XXe9ATuPoSe3eMOxMuYYZ0WjF3BLuA/edit?usp=sharing (updated in March 2022)

New! I posted the latest KiCad schematic revision 0.7.1 (three sheets PDF file) in post #723, page 29 in this thread. A PCB design is in the works and will be available ASAP.

[bob91343]

Looks like a winner!  I assume it puts out 10 MHz.  More details please.

Bob

[MIS42N]

I see you are using isotemp in the prototype and in software you also used an osc5a2b02. I have only used the osc5a2b02 as it is very cheap. Do you find the isotemp a better ocxo? I have one osc5a2b02 consistently keeps better than 0.1 ppb but I don't know if that is unusual. I put it down to a good power supply. Do you output the 10MHz anywhere?

[AndrewBCN]

Hello Bob,
Yes, it uses a (recycled) square wave 5V 10MHz OCXO. The oscilloscope trace is exactly that, taken from the output of the OCXO. The visible ringing is due to a mismatch between the low impedance output of the OCXO and the high impedance of the 10x scope probe, but it doesn't affect the stability of the GPSDO one bit (or one Hz, I could say).
The use of an FLL control loop means that this GPSDO is mostly software-based, and no extra ICs are used (no dividers, no PLL chip, actually not even an op-amp). I am using a 32-bit timer counter in the MCU to do the frequency measurement, and a $1 I2C 12-bit DAC "closes the loop" by providing the frequency control voltage (Vctl) for the OCXO.
The firmware is still in development, but is already functional right now. I am using the Arduino IDE 1.8.13 with the latest STM32 core 2.0.0 package for development. The C/C++ source code for the project is available on GitHub under the GPL V3 license. There was no need for any assembly language code (which is usually an order of magnitude harder to maintain) and the C/C++ source code is copiously commented.

Hello MIS42N,
Yes, I have tested both OCXOs, the Isotemp 143-141 and the CTI OSC5A2B02. They essentially perform the same in terms of stability, but the CTI runs much hotter to the touch.
Depending on the application I would suggest adding a 74HC14 buffer and a coaxial 50 Ohm connector, and eventually an active low-pass filter if one needs a sine wave output.

[bob91343]

Well then Andrew I hope you intend to give a diagram an maybe even sell a PC board.  I already have a rubidium standard but no way to know if it's correct.  This could close that gap.

[MIS42N]

I have also been working on a GPSDO. Details here https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/. It started out to see how little was needed to build a respectable system.

In the details of the second build, I show the circuit for output using a 74HC04. This has now been tested, outputs a respectable square wave about 3v p-p into 50 ohm. It was used as the reference for a WSPR receiver, performed well and the tester now wants one.

Build number 3 is in progress. It was pointed out to me that most amateur radio gear runs from 12V so that will be the supply and use a buck converter to get 5V for the OCXO, 74HC04, Line receiver. The PIC16F1455 runs on less than 15mA so it will be supplied from a MAX6350 precision voltage source. I synthesise a 24-bit DAC for the control voltage directly from the output of the PWM, which is dithered at 40kHz. So the stability of the control voltage is dependent on the stability of supply to the PIC. The control voltage seems to be the limiting factor in achieving better figures.

I am not sure if this is abandoning the minimalist approach. If 12V is available 'for free' the main cost was the GPS module and antenna. In Australia this is about $25. The parts cost even for the third build are quite low and I think the major cost will be a case to put it in. Maybe $60 for the lot?

You can expect an OCXO to run hot. It has to be hotter than any expected air temperature. Also the best temperature for SC cut crystals is somewhere near 70C, SC cut is preferred for references as it has a fairly flat C/Hz curve if ovenized. Maybe the Isotemp has better insulation than the CTI. The CTI passes the finger test.

[AndrewBCN]

Hello Bob,
Yes indeed, a BOM, a circuit diagram and a PCB design are coming ASAP.

EDIT: link to the BOM https://docs.google.com/spreadsheets/d/1BZbZeLiag-d61XXe9ATuPoSe3eMOxMuYYZ0WjF3BLuA/edit?usp=sharing

Hello MIS42N,
Nice work!

[AndrewBCN]

So I went ahead and wired a second prototype on a second breadboard, and below is a picture of both the original GPSDO prototype spread out on two breadboards, and the second prototype with a more compact layout.
The big difference between the two prototypes, apart from the layout, is in the power supply: the first prototype derives its power entirely from the USB connection to my development laptop, using the USB C connector on the STM32F411CEU6 Black Pill development board, whereas the second prototype uses a +5V and +3.3V power supply board attached to the end of the breadboard.
Both prototypes use a u-blox Neo-M8 GPS module, and both get a position fix in a few minutes from a cold start, even in the less-than-ideal conditions in my basement cave lab. And both achieve a stable +/- 1ppb 10MHz signal within a couple of hours of being turned on.

I am also including a picture of the OLED display with the various fields explained.

And finally: I just pushed version v0.03b of the firmware to GitHub. This is the first version that implements a command parser, and I intend to implement a full set of commands to allow for complete control of the GPSDO using either the USB serial or the Bluetooth serial interfaces, making it compatible with LadyHeather and TimeLab. The command parser really opens up a wealth of possibilities for this project.

[bob91343]

Looks good so far.  I keep reading to see at what point I think I could build this.  The software aspect intimidates me.  When the board is available I definitely want one.  In fact, the whole kit of parts would make life easier for me, since it reduces to assembly and test, without shopping for parts.

[MIS42N]

Good work. We seem to be in parallel universes. Yesterday I adapted one of my GPSDO to run off a 12V wall wart, with a buck converter to supply 5V. Now the whole kit is connected with standard connectors, barrel connector for supply.

I too implemented a command interface but not complex. The only dynamic value the software needs is the V/Hz value for the control voltage and it is read from non volatile memory. If the value is unknown, the software does a calibration run to determine it. So the user doesn't need to do anything. The state is shown by the one LED - a short flash every second says it is running better than 1 ppb. Which is about all the user needs to know. I have a serial interface, it can be set to pass through so the NMEA data can be seen. My thinking is some people just want a simple setup that works, and one LED can do that.

[bob91343]

What I want is a simple setup that gives me 10 MHz to either compare my counter OCXO or, better, substitute for it.

[AndrewBCN]

Hello Bob,
The software part is in fact the most enjoyable part of this project for me personally. The big advantage from using a powerful 100MHz 32-bit ARM MCU (with hardware floating point!) is that I can program it in C/C++ and use all the Arduino libraries without any worries about exceeding the capabilities of the MCU.
Also, the hardware is very simple to put together on a breadboard, in fact if one has all the components available, it can be done in an afternoon, and flashing the STM32F411CEU6 MCU takes a few seconds at most from the Arduino IDE.
I haven't started working on the circuit diagram or the PCB yet, but ASAP.
To what precision do you want to calibrate your frequency counter OCXO and/or your rubidium oscillator? Do you have the pinout and/or the technical specs for both?

Hello MIS42N,
I read your impeccable project documentation and I really admire your work, it seems you have a deep understanding of the practical aspects of GPSDO design. I also tried to understand your PIC assembly language firmware for your GPSDO but that was way beyond my capabilities, even though you provide a good description of how it works and ties to your hardware design.
It's very impressive how you managed to fit all that functionality in 4,000 lines of PIC assembly language!
I have one suggestion: ditch the u-blox Neo-M6 GPS module and spend around 10€ to get a much better u-blox Neo-M8 module instead, I have found that it makes a huge difference with getting a position fix and satellite reception in less than ideal conditions.

Compared to yours, my design is oriented toward using standard off-the-shelf modules and easy to understand and maintain C/C++ code. So I would say it's more beginners friendly. But in the end, both projects achieve exactly the same: a stable 10MHz frequency standard with 1ppb accuracy.

Attached pictures:
1. The 10MHz signal from the OCXO "cleaned out" ouput by adding a 220R resistor in series, this greatly reduces the excessive ringing, compared to the previous oscilloscope trace.
2. I have disassembled the first protoype and I am rewiring it in a more compact way so that it fits on a single breadboard. Without the wires it's easier to distinguish the modules in my GPSDO design.

[MIS42N]

I have one suggestion: ditch the u-blox Neo-M6 GPS module and spend around 10€ to get a much better u-blox Neo-M8 module instead, I have found that it makes a huge difference with getting a position fix and satellite reception in less than ideal conditions.

You are probably right. I see you are using a patch antenna, I could not get decent reception in the house anywhere using a patch antenna and even with the puck antenna there were only a few places. Instead of ditching the Neo-6 module I decided to put it where there is a good signal and bring the NMEA and 1pps using line driver/receiver through an Ethernet cable  to the GPSDO. A different solution but it works. I've had it set up with the GPS module over 30 meters from the GPSDO with no problems. I'm getting 10-12 satellites many over 40dB so 30 seconds from cold start to fix.

I might revisit the GPS module after I build V3 GPSDO. Design is complete, power supply is sort of working, just need to put it together. I have all the parts (you may notice I don't use a lot of parts). I used a really cheap buck converter to get 5V from 12V (really any input from 9V to 20V should work). It was very difficult to set the pot to 5V so I reverse engineered the circuit to see if there was something wrong. It actually followed the reference design quite closely, except the output voltage is set by varying a potentiometer. The value for 5V is around 35kohm, the pot is 200kohm so only working near the low end. I shall try and parallel it with a 47kohm tomorrow, should make for easier adjustment.

I did try to use C, maybe too early as it was hard to get programs to fit the memory. Now these 32 bit systems are cheap, it is a lot easier. The assembler is a bit of a hobby, I like how precisely things can be controlled. It does however make for a lot of work. I was thinking recently that perhaps I could put just the basic functionality in a PIC processor and have it communicate with another processor to do the grunt work. It would be quite easy, the two devices could chat using the serial interface. The essential PIC part is timing the arrival of the 1pps, and synthesising the 24 bit DAC from the 10 bit PWM. That's probably less than 100 lines of code.

But for the moment, stick to what already works.

[Miti]

I am using a 32-bit timer counter in the MCU to do the frequency measurement, and a $1 I2C 12-bit DAC "closes the loop" by providing the frequency control voltage (Vctl) for the OCXO.

Nice project!
If you want a really good short term stability and no adjustments, 12 bits is not enough, you need at least 16 bits.
I also used a sine wave OCXO in my Lars GPSDO. It is way cleaner spectrum wise than the square wave.

[AndrewBCN]

...
But for the moment, stick to what already works.

Absolutely! In any case, nice work, and I do appreciate your minimalist and original approach.

[AndrewBCN]

I am using a 32-bit timer counter in the MCU to do the frequency measurement, and a $1 I2C 12-bit DAC "closes the loop" by providing the frequency control voltage (Vctl) for the OCXO.

Nice project!
If you want a really good short term stability and no adjustments, 12 bits is not enough, you need at least 16 bits.
I also used a sine wave OCXO in my Lars GPSDO. It is way cleaner spectrum wise than the square wave.

Hello Miti,
Thank you! I could generate the Vctl for the OCXO using the PWM capabilities of the STM32F411CEU6 (it has a 16-bit PWM mode), that's actually on my (long) list of things to try. The 12-bit I2C DAC I am using right now was readily available and with a negligible cost (€0.50), so I went with that.
And no doubt a sine wave OCXO has much fewer harmonics than a square wave one, I guess for amateur radio applications the way to go is with a sine wave OCXO/DOCXO. In my case, I was really looking for the least expensive OCXOs I could find, and these all happen to be used square wave 5V OCXOs pulled from decommissioned telecom equipment.

[bob91343]

I eagerly await the final (?) design so I can buy the kit and start soldering.  I am really a hardware guy, and while I can see what's going on with software, I can't create my own.  But it's a hobby, right?  And you can't do everything, right?

My initial goal is to have 10 MHz so close that it will be better than my 500 MHz counter that resolves 0.1 Hz.  I think that's about 2 parts in 10^10, maybe 0.2 ppb if my math is good.  I think the rubidium standard is capable of better than that, so ultimately I'd like to verify its frequency.  Both the counter and the standard put out 10 MHz so right now all I do is put them into my analog scope X-Y and see how fast the Lissajous spins.  I can set it so it holds position for a few minutes but when I come back a few months later it has drifted.  With the GPSDO I wouldn't even have to test it, but just use it.  I would use the latter in place of the internal OCXO of the counter, rather than try to zero beat.  That would make my rubidium unit superfluous.

So my BC-221 is ready for a collector.

I remember building a frequency meter in the 1970s that was about as accurate as one could want, but somewhat laughable today.

[AndrewBCN]

So I went ahead and built a third GPSDO, again on a breadboard. The hardware is almost identical to the first two, and so it performs exactly the same: with 5 or more satellites in view for a few hours, I get 10MHz +/- 1ppb. The only thing that has changed is that I have now tested three different OCXOs, one from CTI (Chinese company), one from IsoTemp (US company, but I think they are assembled in Singapore), and one from NDK (Japanese company). They all perform exactly the same.

I think this validates one of my design objectives, which was to get acceptable performance "out of the box", without any adjustments or fiddling with component values. By not spending time on the hardware, I can spend more time on the software, and that is exactly what I did these last few days.

I uploaded to GitHub* Version v0.03e of the STM32 GPSDO firmware which implements a 64-bit counter (tested and working) and 64-bit ring buffers, and also provides a PWM signal with 16-bit resolution, which I still have to test and see whether it can be used instead of the 12-bit DAC, to control the OCXO frequency. All in all the project is coming along quite nicely.

I have also started working on the circuit diagram in KiCad.

Lastly, one thing I have noticed and I am certain that every GPSDO designer knows well: a GPSDO is only as good as the GPS receiver it uses, and a GPS receiver is only as good as the signal it gets from the antenna. 

*: The GitHub repository is this one: https://github.com/AndrewBCN/STM32-GPSDO

[MIS42N]

Lastly, one thing I have noticed and I am certain that every GPSDO designer knows well: a GPSDO is only as good as the GPS receiver it uses, and a GPS receiver is only as good as the signal it gets from the antenna.

It's a little more subtle than that. Designs that rely on a Phase Locked Loop perform better when the synchronising signal (usually 1 pulse per second) is accurately timed. If the 1 pps wanders, the loop has to follow. A few people have published the DAC value they are using, and they generally are altering the DAC value every few minutes. To optimise the 1 pps, people are using special timing receivers and require that signal's arrival time to be timed accurately. They also play with aperture settings etc to iron out ionospheric variations.

The other approach is based on the idea that in the short term the synchronising signal wanders a bit but statistically will iron out. As an example, say you have a perfect oscillator and are allowed 2 events to synchronise it. If the signals are known to vary by +-100ns, then taking two events 1 second apart can result in a maximum error of 200ns in 1 second, so the error will be 2 parts in 10E-8. But if you take the readings 3 hours apart (about 10,000 seconds) then the error is 2 parts in 10E-12.

Of course we don't work with perfect oscillators but we can collect a lot of 1 second samples and hope the average is statistically better than the individual sample errors. Then there is a compromise between the sampling length and the oscillator stability.

My design is based on the second approach - use a cheap GPS unit and an approximate arrival time (within 25ns). Then average. My rig is a bit sensitive to external influences so I just let it run overnight with no electronic equipment nearby. This is the result - the 'DAC' (really synthesised from PWM) values are given as a voltage assuming supply is exactly 5V. The DAC only changes when it has to, which is usually a drift of the oscillator by 1 cycle from zero error:

 Time 132258 UTC. Ctrl 2.0974806 0.112 ppb
 Time 134833 UTC. Ctrl 2.0973743 -0.101 ppb
 Time 151352 UTC. Ctrl 2.0973154 -0.056 ppb
 Time 153511 UTC. Ctrl 2.0972531 -0.059 ppb
 Time 175142 UTC. Ctrl 2.0971912 -0.059 ppb
 Time 192533 UTC. Ctrl 2.0971301 -0.058 ppb
 Time 201644 UTC. Ctrl 2.0971545 0.023 ppb

However, I agree with the requirement for good reception of satellites. I have tried a few times to use weak signals, the result is disappointing. The GPS 1 pps can wander +- 500ns and that is very hard to work with.

[AndrewBCN]

Hello MIS42N

It is exactly as you wrote: over a single second the 1PPS signal from the GPS receiver has an accuracy (total error) of roughly +/- 100ns. Which is exactly the period of the 10MHZ OCXO. So any frequency measurement of the 10MHz OCXO over a sample time of 1 second, based on the 1PPS signal from the GPS receiver, whether by means of an analog or digital phase locked loop or a frequency meter, has a maximum resolution of +/- 1Hz (1x10E-7). To get any higher resolution requires averaging the data over a longer sample time, independent of the method used to measure/control the OCXO frequency.
- 10s sample time gives us 0.1Hz resolution (1x10E-8).
- 100s sample time gives us 0.01Hz resolution (1x10E-9 or 1ppb).
- 1000s sample time gives us 0.001Hz resolution (1x10E-10).
- etc.

The problem for GPSDOs based on inexpensive single oven OCXOs is that for measurement sample times beyond around 500s, the OCXO itself can and most probably will randomly drift in frequency by 0.005Hz or so, because of various environmental factors (temperature, atmospheric pressure, electromagnetic noise, etc), even assuming a stable, noiseless, good quality power supply. So imho it hardly makes sense to claim that a $100 GPSDO based on a cheap GPS receiver module and a single oven OCXO has any better performance than 5x10E-10. And that's assuming one has an excellent antenna mounted on top of the roof.

Going for a double oven OCXO (DOCXO) and a high quality power supply will multiply the cost of the GPSDO by 3x to 10x, and supposedly allows one to get an order of magnitude better precision by using an order of magnitude longer sample time (around 5000s max). Or one can go for a rubidium oscillator and that multiplies the cost of the GPSDO by 50x to 100x, but with the recent development of chip-scale atomic clocks, personally I don't think rubidium oscillator based GPSDOs make sense anymore in terms of price/performance ratio.

And again: imho all these considerations on GPSDO accuracy are only valid if your latest generation GPS receiver has a fix and is providing a stable 1PPS, with 6 or more satellites in view, uninterrupted over several days.

[MIS42N]

It is exactly as you wrote: over a single second the 1PPS signal from the GPS receiver has an accuracy (total error) of roughly +/- 100ns. Which is exactly the period of the 10MHZ OCXO. So any frequency measurement of the 10MHz OCXO over a sample time of 1 second, based on the 1PPS signal from the GPS receiver, whether by means of an analog or digital phase locked loop or a frequency meter, has a maximum resolution of +/- 1Hz (1x10E-7). To get any higher resolution requires averaging the data over a longer sample time, independent of the method used to measure/control the OCXO frequency.
- 10s sample time gives us 0.1Hz resolution (1x10E-8).
- 100s sample time gives us 0.01Hz resolution (1x10E-9 or 1ppb).
- 1000s sample time gives us 0.001Hz resolution (1x10E-10).
- etc.

I was only looking at the case where you can take two samples. In reality you can take a sample a second then apply statistics to find a mean value. If the distribution were a bell curve, then the mean of 100 samples has (with 90% confidence) 5 times less error than any individual sample. So if you individual errors are around +- 100ns but you look at the mean of two successive 100 samples, the error in each with reasonable confidence is only +- 20ns, the maximum error is 40ns over 100 seconds giving 0.004Hz resolution rather than 0.01Hz.

I have not been able to find any information of how reliable a single frequency GPS is in the medium term. It is affected by changes in the ionosphere, but I don't know by how much. I used VisualGPS to record a day of data, it says the location coordinates vary by less than 3 meters horizontally. If the 1 pps is derived from the same data, it is about +- 10 ns in time of arrival. With a long sample time it shouldn't have a lot of effect.

The problem for GPSDOs based on inexpensive single oven OCXOs is that for measurement sample times beyond around 500s, the OCXO itself can and most probably will randomly drift in frequency by 0.005Hz or so, because of various environmental factors (temperature, atmospheric pressure, electromagnetic noise, etc), even assuming a stable, noiseless, good quality power supply. So imho it hardly makes sense to claim that a $100 GPSDO based on a cheap GPS receiver module and a single oven OCXO has any better performance than 5x10E-10. And that's assuming one has an excellent antenna mounted on top of the roof.

Check the figures I gave in my last post - many of the readings are less than 0.1 ppb - i.e. better than 1 part in 10E-10. And I am still not sure what is causing that error - may be temperature, ageing, power supply etc. So my limit at the moment seems to be about 6 parts in 10E-11. Part of that is the limit of arithmetic, I had not expected anything much better than 1E-9 but both GPSDOs with OSC5A2B02 OXCO are doing better than 1E-10 most days. So I have to rewrite the control algorithm.

Going for a double oven OCXO (DOCXO) and a high quality power supply will multiply the cost of the GPSDO by 3x to 10x, and supposedly allows one to get an order of magnitude better precision by using an order of magnitude longer sample time (around 5000s max). Or one can go for a rubidium oscillator and that multiplies the cost of the GPSDO by 50x to 100x, but with the recent development of chip-scale atomic clocks, personally I don't think rubidium oscillator based GPSDOs make sense anymore in terms of price/performance ratio.

IMHO a good disciplined DOCXO should be as good or better than a rubidium standard. A rubidium standard disciplines an oscillator using information from the rubidium cell. It is more stable in the short term than GPS, but not as accurate. So I agree, rubidium is too expensive with a shorter lifetime, for maybe no benefit.

And again: imho all these considerations on GPSDO accuracy are only valid if your latest generation GPS receiver has a fix and is providing a stable 1PPS, with 6 or more satellites in view, uninterrupted over several days.

As I mentioned before, I don't see the need for 'latest generation' or high performance GPS if one is willing to accept the short term errors of a basic GPS. They can be reduced to insignificance with statistics. However, no argument with continuous view of satellites. I keep statistics on missing or rejected 1 pps (missing because the GPS unit doesn't report a valid fix in the $GPRMC message; rejected because it arrived outside of a window of acceptance (which I think is +- 400 ns but I'd have to check the program)). Unless I deliberately interfere, there are no errors (in several weeks' data).

[AndrewBCN]

I was only looking at the case where you can take two samples. In reality you can take a sample a second then apply statistics to find a mean value. If the distribution were a bell curve, then the mean of 100 samples has (with 90% confidence) 5 times less error than any individual sample. So if you individual errors are around +- 100ns but you look at the mean of two successive 100 samples, the error in each with reasonable confidence is only +- 20ns, the maximum error is 40ns over 100 seconds giving 0.004Hz resolution rather than 0.01Hz.

I have not been able to find any information of how reliable a single frequency GPS is in the medium term. It is affected by changes in the ionosphere, but I don't know by how much. I used VisualGPS to record a day of data, it says the location coordinates vary by less than 3 meters horizontally. If the 1 pps is derived from the same data, it is about +- 10 ns in time of arrival. With a long sample time it shouldn't have a lot of effect.
...

U-blox has an Application Note which I believe you'll find interesting: GPS-based Timing - Considerations with u-blox 6 GPS receivers
https://www.u-blox.com/sites/default/files/products/documents/Timing_AppNote_(GPS.G6-X-11007).pdf

Of particular interest is section 2.1 Accuracy of time pulse.

[AndrewBCN]

I have just uploaded firmware version v0.03h which fixes various bugs, but most importantly has various improvements in measurements available, reporting and in the commands.

New commands:

- F (Flush) command: flushes the ring buffers.
- Up/Down PWM/DAC fine/coarse adjust commands.

The 64-bit counter is implemented and tested, the new code seems to be working fine and will soon replace the previous, slightly messy 32-bit code.

The 16-bit PWM to generate Vctl to control the OCXO frequency seems to be working well, but further testing is required and ongoing.

And this is what the GPSDO reports on either the USB serial monitor or the Bluetooth serial:

Wait for GPS fix max. 5 seconds...
Fix time 884mS
Uptime: 000d 00:52:11
New GPS Fix:
Lat: 48.~~~~~~ Lon: 7.~~~~~~ Alt: 132.9m Sats: 8 HDOP: 0.90
UTC Time: 06:05:26 Date: 27/5/2021

Vctl: 1.72  DAC: 2177
VctlPWM: 1.78  PWM: 35345
Vcc: 5.05
Vdd: 3.30

Using 64-bit counter implemented in software
Most Significant 32-bit Count (OverflowCounter): 7
Least Significant 32-bit Count (TIM2->CCR3): 1225527159
64-bit Count: 31290298231 Frequency: 10000000 Hz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.00 Hz
1000s Frequency Avg: 10000000.000 Hz
BMP280 Temperature = 21.2 *C
Pressure = 1018.8 hPa
Approx altitude = 67.2 m
AHT10 Temperature: 18.16 *C
Humidity: 77.63% rH


And yes, I have implemented a 1000s 64-bit ring buffer that allows 10MHz frequency measurements with a resolution of 0.001Hz (10E-10). Note that I am not claiming an accuracy of 0.001Hz, but a measurement resolution of 0.001Hz over 1000s. Those are two different things.

[AndrewBCN]

I have just pushed version v0.04b of the STM32 GPSDO firmware to GitHub.

This version is focused on improving the serial Bluetooth communications and general code refactoring. As far as I know, this is the only GPSDO in the world, DIY or commercial, with a Bluetooth interface.    Many commercial GPSDOs feature an RS-232 DB-9 port or in some cases a GPIB (instrumentation) port, which is fine for their intended purpose, but how many laptops are available these days with an RS-232 serial port, and how much does a GPIB interface cost? On the other hand, there are 4 billion or so smartphones with Bluetooth out there, so...

But enough bragging! Apart from that, I have had the breadboard prototype with the 16-bit PWM Vctl control loop running version v0.03i uninterrupted these days, uptime is 5 days 19 hours right now and this is what it's displaying on the serial monitor:

Code: [Select]

Wait for GPS fix max. 5 seconds...
Fix time 885mS
Uptime: 005d 19:08:09
New GPS Fix:
Lat: 48.560772 Lon: 7.781876 Alt: 151.2m Sats: 10 HDOP: 1.37
UTC Time: 09:28:08 Date: 3/6/2021

Vctl: 2.25  DAC: 2804
VctlPWM: 1.85  PWM: 35721
Vcc: 5.00
Vdd: 3.29

Using 64-bit counter implemented in software
Most Significant 32-bit Count (OverflowCounter): 1135
Least Significant 32-bit Count (TIM2->CCR3): 732228963
64-bit Count: 4875520109923 Frequency: 10000000 Hz
10s Frequency Avg: 10000000.0 Hz
100s Frequency Avg: 10000000.01 Hz
1,000s Frequency Avg: 10000000.006 Hz
10,000s Frequency Avg: 10000000.0022 Hz
BMP280 Temperature = 27.2 *C
Pressure = 1020.8 hPa
Approx altitude = 50.9 m
AHT10 Temperature: 23.42 *C
Humidity: 67.47% rH

So far so good, I would say. 

I was asked if I wouldn't consider changing the FLL to a PLL, and I would like to comment on that.

1. The use of a PLL, as in Lars' DIY GPSDO or in Brooks Shera original design from 1998 (or in many commercial GPSDOs), requires the use of extra components (ICs, capacitors, resistors), some of which may or may not require calibration and may or may not be temperature and supply voltage sensitive. My FLL is 100% digital and 100% implemented using the flexible 32-bit timers available in the STM32F411 MCU, so it requires zero extra components and is in principle temperature and supply voltage insensitive.

2. Mathematically the frequency and phase closed loops (FLL and PLL) are equivalent in their capacity to control the OCXO frequency, but each has some advantages and disadvantages. The main advantage of the FLL as I implemented it, is that its behavior (response time, avoiding oscillations/overshoot, temperature compensation, aging compensation, etc) is entirely software configurable, meaning that as the firmware improves, so does the quality of the FLL.

3. Finally, when I got started on this project, very early on I was impressed by the elegant implementation of a PLL in Lars' DIY GPSDO, and I thought that it would be rather impossible to improve on his work: it's just as good and as simple as it gets for a 1ns resolution TIC/PLL. So I had two choices: either copy Lars' PLL design or go a completely different way, and I decided on the latter.

I would like to note that if anybody feels like it, she/he can perfectly well stitch together my STM32 GPSDO design and Lars' 1ns resolution TIC. That would take some work to merge Lars' code with mine, but it should not be too difficult, since both code bases are well documented. Personally I have no interest in doing that, I believe Lars' DIY GPSDO project is best left as he originally intended it.

[bob91343]

You have shot way over my head.  I was hoping for a way to build one of these but at this point I think I will give up.  It would have been nice to have a module that could substitute for the 10 MHz time base of my counter but alas, I have been left in the dust.

While I understand the basic idea of programming, and have even done some of it, the plethora of languages and complexity of installing (and running) code has me totally wiped out.