Yet another DIY GPSDO - yes, another one

[nealix]

And for caputring the serial monitor output on a, cough, Windows 10 machine, you can open a free serial
terminal program instead of the Arduino IDE serial monitor, and then use a capture to file command in
the serial terminal program.   Take note of the COM port# that your STM32 uses in the Arduino serial
terminal monitor, and the baud rate.   CLOSE the arduino IDE serial terminal window to release the com port,
and then open a serial terminal program below using that same COM port# and baud rate.
Here are some options:

https://forum.arduino.cc/t/how-to-export-data-from-arduino-serial-monitor-to-a-csv-or-txt-file/354651/5

or

Using CAPTURE in the RealTerm program  https://realterm.sourceforge.io/#Capture


Disclaimer:   Linux is far better for almost any type of development work, coding, logging, text
manipulation, etc, because of the rich options that linux has built-in for these tasks and the powerful
linux pipe meachanism for cascading sub-commands.   But for those who are stuck with Windows OS,
at least the above options will work just fine for capturing the serial monitor output on Windows OS to a log file.

I hope the above is helpful.

Neal

[AndrewBCN]

Thank you Neal. 

Also I just wanted to add a note that there is a third, very practical way to capture the GPSDO output to a file: use the Bluetooth interface to send the data to your smartphone!   

Yes, your smartphone! Just use this free app available on the Google Playstore: https://play.google.com/store/apps/details?id=de.kai_morich.serial_bluetooth_terminal&hl=en&gl=US

[AndrewBCN]

Alpha quality firmware v0.06c (pre-release version with a number of outstanding bugs) uploaded to GitHub in folder /software, along with a warning message in file WARNING.txt.

There is now a "help" command, type H and it prints a list of available commands. Many small or cosmetic changes and the only major feature fully implemented is the complete switch to the new counting algorithm, and that needs a lot of testing but so far it seems to work fine. No PLL algorithm but the Vphase value is read and reported once per second. The picDIV arming and synchronization manual operation is now supported with the AP command (Arm picDIV).

[nealix]

Chip caution notes for builders who modify or deviate from the schematic, and/or implement optional parts and/or optional power supply arrangements:

1.  With regard to the ST32F411 Black Pill GPIO pins being 5V tolerant (the chip runs on 3.3V but we feed 5V OCXO and 5V PicDiv into IO pins),
     please be cautious and refer to ST.COM Application Note  AN4899 Rev 3, section 5.2.2 "Five Volt Tolerant GPIO":
     On the Black Pill, or most any other model STM32 MCU board, VDD will be run at 3.3 volts.
     From the app-note: "STM32 devices embed five-volt tolerant GPIOs. These GPIOs are actually tolerant to
     VDD + 3.6 V. It means that the I/O pins can accept such voltages without causing leakage
     current and damages on the GPIOs.
     Regardless of the supply voltage, VIN cannot exceed 5.5 V.
     When VDD = 0 V, the input voltage on the GPIO cannot exceed 3.6 V.
     In case of a multi-supplied and multiplexed GPIO (VDD, VDDUSB, VLCD, VDDA), the GPIO is
     tolerant to 3.6 V augmented of the minimum supply voltage among VDD, VDDUSB, VLCD, and VDDA.
     However, a GPIO is five-volt tolerant only in input mode. When the output mode is enabled,
     the GPIO is no more five-volt tolerant. For more details about I/O input voltage, refer to VIN
     parameters in the general operating conditions table of the datasheet."

     For the GPSDO project, the above indicates that there are two risk factors for damaging the STM32:
     A.  If the 5V OCXO is powered from a different power supply, and the STM32 is turned off (VDD goes to zero), the input pin could potentially be damaged.
     and
     B.  If the 5V OCXO is running/powered, and the STM32 has not yet been programmed, or if an input pin is accidentally programmed as output.
     In either of the two above situations, the max permissible input voltage on a GPIO pin could be exceeded, potentially causing damage to the chip.

     So, for those who decide to power the OCXO on a different isolated power supply or regulator chip, you may wish to use sequencing, to
     effectively keep the OCXO power off until AFTER the STM32 chip boots.   Of course, it takes far less parts and complication if we simply keep
     the input voltage to ANY STM32 GPIO pin no higher than 3.3 volts (3.6V max).   For our STM32, for example, this can be accomplished for the
     5V PicPPS input pin and the 10MHz 5V OCXO input pin, by using a resistor divider or a high speed level translator.

2.  PicDiv chip (MicroChip 12F675 programmed with PD11.hex divider code):
     On our GPSDO schematic, note that we take a GPIO output (PB3 on the STM32 Black Pill) and drive it as signal "picARM" to pin 4 (GP3) on the 12F675 PIC Chip.
     [  THIS IS AN OPTIONAL PART OF THE GPSDO SCHEMATIC, SHOWN ON GPSDO SCHEMATIC PAGE 3, ZONE C2. ]
     From the 12F675 PIC DataSheet, please take note of Section 12.0, Electrical Specifications, footnote at bottom of page:
     Regarding 12F675 GP3 pin, Voltage spikes below VSS at the MCLR pin, inducing currents greater than 80 mA, may cause latchup. Thus,
     a series resistor of 50-100 Ω should be used when applying a "low" level to the MCLR pin, rather than pulling this pin directly to VSS (Ground, pin 8 ).

     So, in summary, IF you implement the PicDiv chip option, and IF you happen to run into stability issues, please try adding a series resistor of anywhere from 50-100 Ω in
     between PicDiv pin 4 (Signal picARM) and the STM32 Black Pill picARM output pin.  This is not likely a routine problem, and is not likely to create any issue
     or damage.

I hope the above information is useful to those who are extending or adding to the project design.

Neal

     

[nealix]

For those in the USA or Canada who are building this, and IF you decide you want to add the optional PicDiv chip,
I am willing to help on an as-time-permits basis, for cost and my time.

I have the programmer for the PIC 12F675, and Tom at LeapSecond.com has granted me permission to
program the PD11 hex file into the PIC chips for GPSDO project builders who do not have their own programmer.
NOTE:  I still work full time, and don't have too much hobby time to spare.  And I am certainly NOT looking
for another full-time side business.   So I would please ask;  Do not contact me until you have already built the
basic GPSDO project and have it working.  Once you get it working, if at that point you are serious about adding
a PicDiv chip, there are two options I can help with;

1.  You can send me your blank PIC 12F675 and I will program it with the PD11 hex file and test it, for $5 USD.
     And mail it back to you via USPS mail.  [If you are in Canada, I need to look up postage cost and add that.]
or
2.  For $7 I can sell and mail a complete programmed and tested chip if you do not have a blank chip.
     [Again, If you are in Canada, I need to look up postage cost and add that.]

I would prefer to handle a max of 2 chips per person, since I only buy 10 chips at a time, and they take 2
weeks to come in from China.  And also, because it takes time to hook up the programmer, set options,
erase and verify the blank chip, load the hex file, flash the chip, move the chip to a bread-board, test
several output pins, put it in an envelope, address it, stamp it, and mail it.  So in reality it's more like
$35 of my time to sell you a chip for $7.  So I am trying to limit this to a handful of GPSDO project builders,
and NOT become a general source for buying PicDiv divider chips.

If you need this help, please send me a private message and I will try to find time to assist you.
If you have purchased the programmer, or want to get one, and need help setting it up to program your
own chips, I can also assist with that via email or phone (as time permits).
REF:  https://www.google.com/search?&q=pickit3     
https://www.ebay.com/sch/i.html?_from=R40&_trksid=p2047675.m570.l1313&_nkw=PICKit3+Microchip+Programmer+w%2F+USB+cable%2C+wires+Pic+Kit+3+and+ICSP+Socket&_sacat=0
Yes, get the 40-Pin Universal programming socket with it.  Works fine for the 8-pin chip and all the other larger chips.

If you are in Europe, AndrewBCN is able to assist with programming a PicDiv.

Cheers,

Neal

[AndrewBCN]

Hello,
Since I am going to be working on the hybrid FLL/PLL control loop algorithm for the STM32 GPSDO, I want to discuss a few aspects of GPSDO control loops and PID algorithms as applicable.

So first the PID reference is the Wikipedia article: https://en.wikipedia.org/wiki/PID_controller

And let us clarify a couple of points related to GPSDO control loops:

1. There are two main types of GPSDO control loops: FLL and PLL.

2. In FLL loops, the "process variable" PV is the frequency of the OCXO in Hz, measured by a counter with the gate time controlled by the PPS from the GPS receiver. No PPS, no frequency measurement.

3.  In PLL loops, the "process variable" PV is the phase difference (in ns) between the rising edge of the 10MHz from the OCXO, and again the rising edge of the PPS from the GPS receiver, measured by a "time interval counter" TIC circuit which can be digital or analog. And similarly, no PPS, no phase difference measurement.

4. In both cases, the presence of a PPS from the GPS receiver is essential. Not only that, but the "precision" of the PPS from the GPS receiver determines the precision of our measurements of the PV variables frequency or phase difference. This is in fact what GPSDOs are all about: we use the PPS from the GPS receiver as a "proxy" for the atomic clocks onboard the satellites, to measure our local oscillator frequency or phase, and "discipline" it.

5. Just a note about digital/analog measurement circuits: the STM32 GPSDO FLL uses a 100% digital frequency measurement circuit, Lars' DIY GPSDO uses an analog TIC that generates a voltage that is then converted to a digital value using an ADC.

6. Getting back to our PPS from the GPS receiver, how "accurate" is it ? The accuracy of a clock is not a single number, it is actually best described ("characterized") by a chart, the famous ADEV/MDEV charts, which essentially plot the statistical variance of the frequency of our clock over a period of time (tau). So we know that the ideal frequency of the PPS from the GPS receiver is exactly 1Hz, and we can measure (using an even better clock) the minute variations in time between two consecutive rising edges of our PPS signal, and then if we collect enough measurements over e.g. a day or two, we can plot an ADEV/MDEV chart for our PPS receiver. This has been done over and over again by extremely knowledgeable people using very expensive equipment for a number of GPS receivers, and - surprise, surprise - they have found that the ADEV/MDEV curves for the PPS from different GPS receivers are actually quite similar. I'll come back to that later. But for the moment, we can assume that the "precision" of the PPS signal from a < $10 u-blox NEO M8N is better than 100ns over 1 second (10E-7) and improves by an order or magnitude per decade iow it is approximately 10E-8 for tau = 10s, 10E-9 for tau = 100s, etc. up to 10E-11 for tau=10k seconds.

7. I have previously posted a link to an excellent analysis of various GPS receivers and I again refer you to it : https://hamsci.org/sites/default/files/publications/2020_TAPR_DCC/N8UR_GPS_Evaluation_August2020.pdf by John Ackermann N8UR

8. Note that in the STM32 GPSDO we use a little trick to further improve the accuracy of the PPS from the u-blox NEO-M8N. Check the function ubxconfig() and you'll find this comment:

Code: [Select]

  // send UBX commands to set optimal configuration for GPSDO use
  // we are going to change a single parameter from default by
  // setting the navigation mode to "stationary"
9. Getting back to the Wikipedia article on PID control loops, we have now defined our two process variables PVs frequency and phase difference, and we have just seen how to measure them. What is the setpoint SP or target value for these PVs ? For the frequency, it is the nominal frequency of our OCXO or 10MHz in our case, and for the phase difference it is exactly 0. In the STM32 GPSDO we already measure the error term e(t) every second for both PVs: for the frequency, this is the "offset" which is now stored in a unified ring buffer, and for the phase difference this is the reading from the TIC Vphase, which we average over the last 10 second using the moving average library.

10. Again referring to our ideal PID controller, our control variable u(t) in the case of most low-cost GPSDOs is the control voltage that we can apply to the OCXO to vary its frequency. For Lars' DIY GPSDO and for the STM32 GPSDO a 16-bit PWM DAC is used to generate a control voltage Vctl between 0 and 4V. This is an extremely economical solution but it does the job.

11. A complicating factor for programming the PLL or FLL algorithms for a GPSDO is that we are dealing with a discrete correction process, in other words changes in the control variable are applied at discrete time intervals which can be fixed or variable. For example, the STM32 GPSDO with its very crude FLL algorithm uses a fixed interval of 429s to change Vctl (except during the initial calibration). In older GPSDO designs using a purely analog circuit the control variable is applied continuously.

12. Consequently the program of an FLL or PLL loop for a GPSDO has two decisions to make every second:
a) What is the size of the correction to be applied to the control variable in other words how to compute the new value for Vctl ?
b) Should the correction that was just computed be applied now, or should we wait and apply a different correction later ? How frequently do we change Vctl and do we use a fixed or variable time constant?

13. The programmer (in this case myself) has to decide whether to use a P, PI or PID loop, the optimal values for Kp, Ki and Kd, how frequently do we change Vctl and do we use a fixed or variable time constant (the delay between changes to the Vctl), and any processing (filtering, averaging, removal of outlying values, etc) of the measurements from the frequency counter and the TIC.

14. More precisely in my case, there is an extra complicating factor because I am trying to merge the FLL and PLL control loops into a "hybrid" FLL/PLL control loop. How to best combine the information from the two measurements frequency and phase difference ? Should I have the two loops acting concurrently, or should one loop take over and in what conditions ?  Aaaaahhhhhhhh 

[nealix]

I notice that some of you guys mention using the STLINK to flash the BlackPill STM32 instead of the USB port DFU mode.
I too, am also having trouble with the USB DFU mode being fussy, and sometimes it takes ten tries to get the USB port to
appear as an STMboot device on the PC for download of the compiled code.

I have an STLINK device but never got around to learning to use it.
For those of you who are using the STLINK device, is there a procedure where you are able
to compile the GPSDO code using the arduino IDE, and then use some program with the
STLINK hardware to flash the blackpill using the Arduino IDE generated binary?

Is anyone willing to point me in the direction where I can learn these steps?

Thx,

Neal

[AndrewBCN]

Neal,
The program to use ST-Link is STM32 Cube Programmer which is installed automatically when you install the Arduino STM32 support package. Normally you can select to upload the firmware to the STM32 development board (the Black Pill in our case) through the ST-Link directly from the Arduino IDE.
Take a look at this: https://idyl.io/arduino/how-to/program-stm32-blue-pill-stm32f103c8t6/

[thinkfat]

I don't see much merit in a FLL/PLL hybrid, especially since your FLL has a very long settling time. The phase error you get from the TIC is normally sufficient. However, a frequency measurement can come in handy to speed up the lock of the PLL. If you're able to get the OCXO at least to within 100ns/s of the "true" 10MHz quickly so that the PLL can take over and lock to the phase, that would be something.

The frequency measurement can also prevent the PLL from trying to lock to multiples of 100ns/s of frequency offset. I've never actually seen this happen, but in theory, it could.

[AndrewBCN]

I don't see much merit in a FLL/PLL hybrid, especially since your FLL has a very long settling time. The phase error you get from the TIC is normally sufficient. However, a frequency measurement can come in handy to speed up the lock of the PLL. If you're able to get the OCXO at least to within 100ns/s of the "true" 10MHz quickly so that the PLL can take over and lock to the phase, that would be something.

The frequency measurement can also prevent the PLL from trying to lock to multiples of 100ns/s of frequency offset. I've never actually seen this happen, but in theory, it could.

Actually the STM32 GPSDO can achieve a PLL "lock" much faster than Lars' GPSDO and does not need the educated guesswork of a correct value for the "gain" in Lars' algorithm: we can calculate a nearly optimal "gain" value (or perhaps not optimal, but "good enough" gain value) during the calibration procedure. The problem with the PLL is the real resolution of Lars' TIC, which is around 25~30ns (vs. the claimed theoretical resolution of 1ns).

So my problem is creating an algorithm that takes the best features of the FLL and PLL and combines them into a "super" control loop.

[AndrewBCN]

A few (bad) hand drawings to illustrate a few concepts discussed above:

1) Frequency vs Time for an analog FLL PID controller showing the effects of non-optimal coefficients. Note the correction (Vctl) is continuously changed so the OCXO frequency also changes continuously.



2) Again an analog FLL PID controller, this time the OCXO frequency settles much faster and with little overshoot, since the coefficients are optimal or near-optimal.



3) Digital FLL PID controller showing discrete Vctl changes, once per second ("time constant" = 1 second). The coefficients are not optimal so there is some over and under shoot.



4) Digital FLL PID controller showing discrete Vctl changes, once per second ("time constant" = 1 second). At time t we lose the PPS or we enter "Holdover Mode" manually, whereupon the OCXO frequency starts drifting up, since the OCXO is not "disciplined" anymore (Vctl remains at the last value set by the PID controller).

[thinkfat]

Yes, that is all well understood, basic control theory. In fact, the digital and analog PLLs are not actually very different. It really depends on how frequently you get new information into the system.

For example, the old G3RUH design with the Jupiter GPS receiver used a quite high-frequent time signal, however this receiver would only update the phase of the signal once per second and so effectively it was quite digital as well. And I've seen "analog" designs that would use a discrete sample-and-hold circuit to store the output of the phase discriminator between time pulses from the GNSS receiver - not very analog either.

Regarding the time it takes for a PLL to settle, that is really a question of implementation. In that respect, Lars' PI controller implementation is very basic and should not be taken as a benchmark for what is possible. You can play a lot of tricks in software to adjust the characteristic of the regulation based on system state and achieve much quicker lock time.

Regarding the performance of the FLL - The problem is always to measure the frequency with high enough precision, and if it takes 100 seconds to get down to 1ppb precision that is your update frequency. In between your regulation cannot do anything.

On the other hand, a TIC gives you new information every second and that can be exploited.

However - you have all the tools available now to make a very interesting experiment: You can put your FLL to the test. Just plot the TIC values while leaving the control to the FLL. I would really love to see an evaluation of the stability.

[AndrewBCN]

...
Regarding the performance of the FLL - The problem is always to measure the frequency with high enough precision, and if it takes 100 seconds to get down to 1ppb precision that is your update frequency. In between your regulation cannot do anything.
...

Hello thinkfat,

That's not how the FLL works. Yes, you have to wait 10 seconds to get the first 0.1Hz resolution reading, 100 seconds to get the first 0.01Hz resolution reading, and so on. But that's just for the first reading at each resolution. All subsequent readings at each resolution are taken every second. So the regulation based on each resolution can take place every second, once the respective ring buffer has filled to capacity.

That is exactly the same constraint that a PLL loop has, because it has to "average" the TIC readings over a certain period of time to get any meaningful error value to a certain resolution.

In terms of measurement update frequency constraints, there is really no difference between a PLL or a FLL when used in a GPSDO control loop.

...
However - you have all the tools available now to make a very interesting experiment: You can put your FLL to the test. Just plot the TIC values while leaving the control to the FLL. I would really love to see an evaluation of the stability.

You are right, that is a very interesting experiment that only the STM32 GPSDO can perform. I'll get on to it soon. 

[thinkfat]

That is exactly the same constraint that a PLL loop has, because it has to "average" the TIC readings over a certain period of time to get any meaningful error value to a certain resolution.

In terms of measurement update frequency constraints, there is really no difference between a PLL or a FLL when used in a GPSDO control loop.

Well, no. The TIC adds an uncertainty of a couple nanoseconds per second, while the counter has an uncertainty of +/- 100ns per second. That makes a difference. Of course the timepulse of the GPS has some uncertainty, too, especially if you're not correcting the quantization error, but that is not in the order of 100s of nanoseconds - there's still some advantage that the TIC can provide.

[nealix]

Neal,
The program to use ST-Link is STM32 Cube Programmer which is installed automatically when you install the Arduino STM32 support package. Normally you can select to upload the firmware to the STM32 development board (the Black Pill in our case) through the ST-Link directly from the Arduino IDE.
Take a look at this: https://idyl.io/arduino/how-to/program-stm32-blue-pill-stm32f103c8t6/

Thanks.  ST-link V2 USB dongle is MUCH Easier and quicker for program upload/flash, compared to the very fussy USB Serial DFU pushbutton method.   The firmware in the eBay ST-Link V2 dongle had to be updated using the STM32CubeProgrammer software, and then, in the current Arduino IDE (v1.8.19), the TOOLS->Upload Method: menu entry needs to be "STM32CubeProgrammer (SWD)".   The menu no longer has an entry that says "ST-Link".

Neal

[nealix]

I ran into trouble getting the ST7735 display module working.   There is no schematic showing which pins to interface.
Badwater-Frank shared a PM with some of the details, but I still can't get the display going.

I googled and found this thread describes my problem exactly:
https://www.stm32duino.com/viewtopic.php?t=1113

Does anyone have this display working, and if so, can they please share which specific pins are used to interface
on the STM32 Black Pill?

Cheers,

Neal

[AndrewBCN]

I ran into trouble getting the ST7735 display module working.   There is no schematic showing which pins to interface.
Badwater-Frank shared a PM with some of the details, but I still can't get the display going.
...

Neal, the ST7735 display is not yet supported, it's an experimental feature. The SPI pins used in Badwater-Frank's ST7735 display implementation conflict with the pin assignments in the latest schematic.
You can try adapting the pins I used in the ST7789 code, these have no conflict.
Unfortunately I don't have an ST7735, so my help regarding this experimental feature will be very limited. 

[AndrewBCN]

OK, so another chart, this time it's the Allan deviation for:

1. A $5,000 (new) very high quality OCXO such as the one shown here: http://www.leapsecond.com/museum/osa8601/view.htm This is completely out of reach for most hobbyists.

2. A $10 used OCXO such as the ones we are using for the STM32 GPSDO.

3.The PPS from a $10 u-blox NEO-M8N GPS with a good antenna. If you think you would get a very different PPS ADEV curve from a more expensive GPS receiver, I refer you to the paper by John Ackermann that I linked to previously.

OK, so what does this chart show and why is it relevant to our discussion on PID controllers and the "performance" of a GPSDO in general ?

a) As the chart shows, a $5000 OCXO is approximately an order of magnitude more stable compared to a $10 OCXO up to until a tau of 1,000s.

b) As you can observe, the PPS Allan deviation intersects the $5,000 OCXO Allan deviation at around a tau of 100,000s, and doesn't really improve on it much beyond that. What this means is that there is practically no advantage to "disciplining" such a high quality OCXO with a $10 GPS receiver module. We gain practically nothing in terms of stability, and we actually would probably make things worse.

c) On the other hand, as the chart shows, the PPS Allan deviation intersects the $10 OCXO Allan deviation at around a tau of 1,000s. What this means is that if we carefully "discipline" such a $10 OCXO using the PPS from a $10 u-blox NEO-M8N GPS receiver module with a proper PID control loop with a "time constant" around 500s, the Allan deviation curve of our GPSDO should combine the OCXO stability up to around 1000s and the PPS stability from that point on.

That's the idea behind all GPSDOs, no matter how they implement the control loop or what hardware they are using. If the control loop is correctly setup and working as it should, the "performance" of a GPSDO can only be as good as the "performance" of the OCXO it is based upon up until the point at which it intersects the "performance" of the PPS from the GPS receiver used. And from this point on it should match the "performance" of the PPS from the GPS receiver.

As I wrote many times in this thread already: there is no magic happening in a GPSDO and there are no "special tricks" that can make it perform any better than the components it is based upon, because these components set the strict mathematical limits on the GPSDO overall performance.

I have just found this note by Lars Walenius in his PDF describing his Lars' DIY GPSDO: "The hardware may seem simple but the performance is still mostly dependent of the GPS receiver
and 10MHZ oscillator. So, first I recommend selecting a GPS receiver and oscillator depending on your requirement on stability." (my emphasis)

Note: all the numbers above are ballpark approximations, and so is the chart below.

[iannez]

i'm on vacation this week but i'm reading and thinking about various correlations between the variables for the pid. the problem is to have the given realtime frequency, tro have the direct correlation between pwm increase (1/65536), relative frequency increase and how long this increase takes effect.
I'm thinking...

[AndrewBCN]

That is exactly the same constraint that a PLL loop has, because it has to "average" the TIC readings over a certain period of time to get any meaningful error value to a certain resolution.

In terms of measurement update frequency constraints, there is really no difference between a PLL or a FLL when used in a GPSDO control loop.

Well, no. The TIC adds an uncertainty of a couple nanoseconds per second, while the counter has an uncertainty of +/- 100ns per second. That makes a difference. Of course the timepulse of the GPS has some uncertainty, too, especially if you're not correcting the quantization error, but that is not in the order of 100s of nanoseconds - there's still some advantage that the TIC can provide.

From Lars' PDF, right on the first page:

As the 1PPS has a lot of jitter, normally in the range 10-50ns p-p, the time measured between the 1PPS and 10MHz is filtered with a low-pass filter in the software.

(my emphasis)

Lars' low pass filter essentially averages the 1Hz TIC reading to extract a usable value from the noise. In the FLL used in the STM32 GPSDO we average the 1Hz frequency readings to chop down the 100ns uncertainty associated with a single reading. Essentially neither PLL nor FLL control loops can extract sufficient information about the error from a single 1Hz measurement. So exactly the same problem and exactly the same solution: take multiple sequential readings.

Neither PLL nor FLL have any advantage in terms of how much information either can extract from a single 1Hz error measurement.

[thinkfat]

That's not quite correct. Lars' TIC has about 1ns resolution. Not sure about the uncertainty, I guess it depends a lot on the component choice and the cleanliness of the build, but it can sample the noisy 1PPS input once a second and then averaging over like 10 or 20 seconds (Lars used an EMA filter for that purpose) gets rid of the quantization error mostly. So, there is information in that jittery signal that can be extracted. Mind you the PPS is not jittery because the time signal recovered by the receiver is so noisy. It is noisy because the 1PPS output is aliased to the receivers internal clock source. Over a couple of 10 seconds, the accuracy is much better than 50ns.

Using a 10MHz counter on the other hand, it is completely blind to this. There's no way to extract the information with 10 or 20 seconds of averaging.

[AndrewBCN]

That's not quite correct. Lars' TIC has about 1ns resolution. Not sure about the uncertainty, I guess it depends a lot on the component choice and the cleanliness of the build, but it can sample the noisy 1PPS input once a second and then averaging over like 10 or 20 seconds (Lars used an EMA filter for that purpose) gets rid of the quantization error mostly. So, there is information in that jittery signal that can be extracted. Mind you the PPS is not jittery because the time signal recovered by the receiver is so noisy. It is noisy because the 1PPS output is aliased to the receivers internal clock source. Over a couple of 10 seconds, the accuracy is much better than 50ns.

Using a 10MHz counter on the other hand, it is completely blind to this. There's no way to extract the information with 10 or 20 seconds of averaging.

Not at all. You can easily extract information from a 10MHz counter after 10 or 20 seconds: that's exactly what the STM32 GPSDO FLL control loop does. Actually the FLL control loop extracts information from the 10MHz counter continuously every second as soon as the GPS receiver provides a PPS, and saves the information for each and every reading in a (at present) 20,000 seconds circular buffer.

By contrast Lars GPSDO does not save the total information for each and every TIC reading, since Lars decided that for his control loop it was enough to use an exponential moving average of the TIC readings.

Note that I am not at all claiming either method is "superior" to the other, those are design decisions that each GPSDO designer deals with as best she/he can.

[Carsten]

The problem with the PLL is the real resolution of Lars' TIC, which is around 25~30ns (vs. the claimed theoretical resolution of 1ns).

How have you measured the resolution of your hardware implementation of Lars' TIC? The 25~30 ns you specify is suspiciously close to the NEO-M8N's 30 ns time pulse rms accuracy (datasheet, page 6). If you require higher time pulse accuracy (e.g., for shorter time constants or better transient behavior) you'd need a GNSS receiver with quantization error compensation.

The STM32F411's timers should enable 10 ns resolution capture at their 100 MHz max clock frequency. Unfortunately, that is not (trivially) possible with the BlackPill, because its PH0 pin is not accessible unless you desolder the HSE crystal. When using the 10 MHz OCXO as the HSE source, a timer could be run at 100 MHz from the PLL locked to the OCXO, enabling 10 ns resolution timer capture of the GNSS timepulse relative to the OCXO's current frequency. The same timer could be used to generate an OCXO-locked timepulse. Erik is currently experimenting with that. As long as the timepulse measurement resolution is below the timepulse jitter and both are uncorrelated (e.g., use a different clock), you can increase your accuracy via averaging.

Just an idea: With 30 ns jitter from the GNSS timepulse, using only the STM32F411 timers (at 100 MHz) might simplify your design by obviating the need for the analog TIC and the picDIV.

3.The PPS from a $10 u-blox NEO-M8N GPS with a good antenna. If you think you would get a very different PPS ADEV curve from a more expensive GPS receiver, I refer you to the paper by John Ackermann that I linked to previously.

The ZED-F9T w/ quantization correction is an order of magnitude better than a NEO-M8T (Fig. 26 of John Ackermann's paper). That could move the ADEV intercept of OCXO and timepulse by an order of magnitude on the tau axis, enabling, e.g., significantly faster settling after power up.

[AndrewBCN]

Notice that I often put performance between quotes? That's because defining the "performance" of a GPSDO is not that simple.

Going back to basics once again, what is the purpose of a GPSDO? As the name implies, a GPSDO is essentially an oscillator with a high degree of stability.

From the Wikipedia article on GPSDOs: "A GPS clock, or GPS disciplined oscillator (GPSDO), is a combination of a GPS receiver and a high-quality, stable oscillator such as a quartz or rubidium oscillator whose output is controlled to agree with the signals broadcast by GPS or other GNSS satellites."
https://en.wikipedia.org/wiki/GPS_disciplined_oscillator

And also as we have seen, the stability of an oscillator has a precise definition in mathematical terms: it is described by an ADEV/MDEV curve, and that curve is essentially determined by the quality of the two main components: the oscillator and the GPS receiver (when the GPSDO control loop is operating properly). As Lars Walenius wrote, the selection of a GPS receiver and oscillator essentially define the stability envelope of a GPSDO. The rest is up to the control loop, and when a control loop is well designed and well tuned it should realize the full stability potential of the GPS receiver and oscillator.

So can we just define the "performance" of a GPSDO as its ADEV/MDEV curve? I personally don't think so. While the stability of a GPSDO as measured by the ADEV/MDEV curve is certainly an important parameter, I don't think it is the only factor to consider when trying to define the overall performance of a GPSDO. Here is a non-exhaustive list of some other parameters that I consider important:

1. Software quality, including the quality of the control loop.
2. Source code availability (Open Source or proprietary).
3. Overall temperature stability.
4. For a DIY GPSDO: is it easy to source all the components? What is the total cost for the BOM? Is it easy to put together and use? Is there a PCB available? Is there good documentation?
5. Information reported every second, on a serial port or other (e.g. Bluetooth, WiFi, Ethernet, etc).
6. What sensors are available, if any.
7. Quality of the display, if any.
8. Support, if any.
9. Price/performance ratio. Here, as always, you get what you pay for.
10. Upgradability / expandability (software and hardware).
11. What other functionalities are provided? (e.g. an "atomic clock" display? A UTC-synchronized PPS during holdover? A frequency counter mode? NTP/PTP server? Portability?)
12. Is it a copy of an older, original design? Or is it a new design?
13. Does the design match the intended use case? Don't expect a commercial GPSDO designed for satellite use to resemble in any way, shape or form a DIY GPSDO designed for experimentation and hobby use.

 

[2N3055]

...... Here is a non-exhaustive list of some other parameters that I consider important:

1. Software quality, including the quality of the control loop.
2. Source code availability (Open Source or proprietary).
3. Overall temperature stability.
4. For a DIY GPSDO: is it easy to source all the components? What is the total cost for the BOM? Is it easy to put together and use? Is there a PCB available? Is there good documentation?
5. Information reported every second.
6. What sensors are available, if any.
7. Quality of the display, if any.
8. Support, if any.
9. Price/performance ratio.
10. Upgradability / expandability (software and hardware).
11. What other functionalities are provided? (e.g. an "atomic clock" display? A UTC-synchronized PPS during holdover? A frequency counter mode?)
12. Is it a copy of an older, original design? Or is it a new design?

 

Just a side note...
Bolded sentence is the only thing on your list that is actual performance parameter. Maybe number 1 but that is ambiguous what you mean by it.

Everything else are features and characteristics that you find important and desirable by your opinion as a user.
But they are not performance related.

Raison d'etre of GPSDSO is to provide high stability frequency source. And relevant performance parameters are only related to that. Maybe if you need portable one, performance parameters would include antenna sensitivity, time to lock, power consumption etc.

Implementation details and additional features are just that. And I agree that each person should choose one that fulfils most of it's needs.
If you will, one might say ( and you might have meant exactly that and I misunderstood) that when choosing on a GPSDO one should not make a choice simply on performance but also on other desirable parameters, of which you made your recommended list of things to pay attention to...
I believe that is a good approach and actually applicable to many other things too...