Yet another DIY GPSDO - yes, another one

[Johnny B Good]

FYI - here is a link to an excel table for calculating the filter parameters of a XOR based Miller design.

https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070

 Thanks for sharing that but TBH, I'm not quite sure how to apply the calculations. I do know that my OCXOs have a EFC sensitivity of around 3Hz per volt but I think any further optimisation of the LPF will only offer me a marginal improvement at best.

 I'd been dithering about how exactly to phase lock an OCXO to the output from a GPS receiver module when I came across Gyro's posting of the circuit I've attached below. Its utter simplicity neatly condensed the essentials to galvanise me into lashing together my very first GPSDO project.

 I think I was still stuck with that 13MHz OCXO and a bunch of TTL magic to generate the required 10MHz output so had enough complexity of my own to persuade me to take just the bare minimum of his circuit to start experimenting. I simplified his further by eliminating the opamp and its RC LPF by simply taking the PLL's LPF output straight to the EFC pin. I'd figured it wouldn't seriously compromise its performance and this turned out to be the case. From then on, I was finally up and running to developing my own improved versions.

 What I basically did was keep to his 10:1 ratio between R1 and R2 (there was no R3 in his circuit) and ditto for the capacitors, merely scaling the caps up to 470 and 47 μF and using larger and larger R values once I'd added a 5v cmos RRO opamp back in. I just took it on faith that he'd chosen ratios close to the optimum and this does seem to have been the case.

 I've since tested with TCs ranging from a low of 100 to a high of 5000 seconds with no great variations in stability (with a NEO M8N module - it might be a different story now I'm using NEO M8T modules). I landed up compromising on a TC of 1200 seconds but I might revisit the 5000 seconds option now that I'm using NEO M8Ts.

 The protracted startup to lock times, despite the inclusion of a startup accelerator circuit don't overly concern me since you need to allow a good 10 to 15 minutes (preferably longer) for the OCXO to warm up and stabilise anyway. In fact, despite the note on my MK II diagram, I think I'd managed to reduce the time to lock from cold power up to just over ten minutes with a TC of 5000 seconds (although that result might have been with a TC of 2000 seconds).

 When you're running a reference oscillator where the addition of an on/off switch would be an act of insanity because any sane person wouldn't dream of shutting down a piece of kit that's best left to run 24/7 year in year out if they could possibly help it, even a run up time of an hour or more to achieve 'lock' will be of no consequence in this case.

 Anyway, I'm about to re-aquaint myself with a nano 3 that's currently got an edited version of the Blink program on it from when I last tried it out over six months back in order to run a barometric sensor sketch to test out that BMP280 module and start getting my eye in on all this microcontroller malarky. It'll probably go rather quiet from my end for a while as I suspect some here will be pleased to hear.

 My apologies to AndrewBCN for the "Off Topic" contributions but I thought they might help Bob's endeavours to build himself a GPSDO, eventually based on your design efforts, by offering him a gentler route into making up a simple and basic James Miller inspired design from which to work upon and gain some valuable experience. After all, the required parts for such a basic GPSDO are also the very same essentials he'd need anyway to build your design.

 As already mentioned I've attached a copy of Gyro's simple GPSDO image file to help clarify my description of the cutdown version I'd used as a prototype for my own humble efforts.

[AndrewBCN]

...
 My apologies to AndrewBCN for the "Off Topic" contributions but I thought they might help Bob's endeavours to build himself a GPSDO, eventually based on your design efforts, by offering him a gentler route into making up a simple and basic James Miller inspired design from which to work upon and gain some valuable experience. After all, the required parts for such a basic GPSDO are also the very same essentials he'd need anyway to build your design.
...

Apologies accepted however:
1.  To be honest I would prefer if you would start your own thread and post in it your experiments with your rubidium oscillator. Your numerous long posts are completely off-topic in this thread.
2.  Imho the James Miller GPSDO (as well as the numerous GPSDO designs copied or "derived" from it) is more complex to understand, more expensive to build and technologically obsolete, compared to either Lars' GPSDO or the STM32 GPSDO. It was a valid GPSDO design 20 years ago, but not in 2021. Btw James Miller himself has ceased selling his GPSDOs in 2017.
3.  If you want to exchange exclusively with Bob you can use the Private Messaging option in this forum, there is no need to post here in this thread.

[Johnny B Good]

FYI - here is a link to an excel table for calculating the filter parameters of a XOR based Miller design.

https://www.eevblog.com/forum/projects/gpsdo-with-xor-phase-comparator-control-loop-filter-design/msg3458070/#msg3458070

Very, very nice.
However, it clearly shows how an analog PLL hardware control loop is limited when compared to a PLL or FLL control loop implemented in software.
When using a software control loop (Lars' GPSDO, STM32GPSDO or Erik's GPSDO), changing the corner frequency of the low pass filter is as simple as changing the value of a constant or variable. In Lars' GPSDO and the STM32 GPSDO, this is a constant defined at compile time, in Erik's GPSDO this is a variable that "adapts" to the stability of the TCXO.
When using an analog hardware control loop as in the Miller design and various old commercial GPSDOs, changing the corner frequency of the low pass filter requires changing an onboard capacitor and resistor pair. Also, since the capacitor and resistor are temperature sensitive, the corner frequency will change with temperature, and will also be affected by aging of the components.

Back in the early 2000's when James Miller came up with his simple GPSDO design, the use of a hardware control loop was justifiable and was an ingenious solution. But we are in 2021, and an MCU development board can cost as little as $2. A software control loop is a superior, cost effective solution, without a shadow of a doubt.

 There's no argument with those last two statements, however I do think you're rather overstating the case against using a James Miller type of hardware PLL'd GPSDO design.

 The limitations of tuning a hardware PLL filter are only an issue during the development phase when proving the calculated values are actually optimised, Once set and in production, there's no further need to experiment with different values. Also, even if the tempco was as high as 1% per deg C on the LPF components, it would make only an imperceptible difference. It's not as if they're highly stressed like the caps in a switching regulator or psu and ageing isn't a thing with caps and resistors when faced with no more stress than what they'd suffer under storage conditions.

 You might want to take another look at that leapsecond.com page here:- http://www.leapsecond.com/pages/gpsdo/ before condemning the James Miller design out of hand. It was only beaten to first place at the 40,000 seconds mark by the Thunderbolt. It exhibited no unusual behaviour to mark it out as not being a microcontrolled design like its three competitors.

 There's no need to extol the already well known virtues of using microcontrollers by extolling the overstated vices of analogue solutions, especially when you fail to mention the downsides of having to account for the effect of temperature on critical sub-components such as DACs and voltage regulators and so on - all things that are rather neatly dealt with in the James Miller design by the action of the PLL in handling their effects and that of the OCXO's drift as a single source of error to be corrected.

 Don't get me wrong, I can well see the shortcomings of the James Miller design in the face of the residual sources of error inherent in the GPS system itself when relying on a single frequency band receiver to discipline an OCXO. In the end, no matter what technique is used, it will be limited by the medium term stability of its OCXO. I'm going to cheat my way past this limitation by disciplining a temperature stabilised and barometrically compensated Rb oscillator instead.

 Now I'm off to make a long overdue appointment with a 'blinking' nano 3 and its friend, the Arduino IDE but only after I've had a good night's sleep!

[MIS42N]

An advantage of microprocessor based GPSDO control over analog control is it can make estimates of its own accuracy. As far as I can see, the only way to test an analog design is to compare it with a better design. The GPS signal is long term the best reference that most of us can access, and a uP is able to accumulate data comparing the local oscillator with the arrival of 1pps. A second advantage is a uP can be programmed to be adaptive.

Something that still confuses me is Allan Deviation. I assume the only way to measure?/calculate? this is by comparison with a better reference than the system being measured. Is the reason they all head for 10-13 after 10,000 seconds because they are all locked by one means or another to GPS? Does that have practical meaning? Johnny B Good links to an article that shows the Miller design is beaten by the Thunderbolt after 40,000 seconds. Is that due to differences in OCXO or differences in control? and is that difference significant?

It seems to me there are two groups of GPSDO makers - the ones who will use the GPSDO as a reference for other things, and therefore is the most accurate piece of equipment they own - and ones who are trying to make better and better GPSDO for a challenge (when some already own a cesium beam reference). People in the first group would like to know their equipment meets some standard. With an analogue design they just have to take it on trust that their equipment meets the standard. With a microprocessor design it is possible to demonstrate it (although as noted early Leo Bodnar designs had a software error that ensured it was inaccurate).

So I am firmly in the microprocessor camp, not because I think it results in superior performance (I believe this ultimately comes down to choice of OCXO and the careful design of the supporting circuitry and environment), but because it gives better bang for buck for those on a budget. They are the ones most likely to use a GPSDO as a reference device. They won't be looking for ultimate accuracy, just better than what they already have. 

[AndrewBCN]

Just grafting a microprocessor onto a previous analog design doesn't necessarily result in a "better" GPSDO.

The STM32 GPSDO was designed from the start around the capabilities of the STM32F411CEU6 "Black Pill", and makes extensive use of all the available peripherals in the STM32 MCU. The result is a fully featured experimental GPSDO that compares well to what I consider the "Gold Standard" of modern DIY GPSDOs, Lars' GPSDO.

It is extremely unfortunate that Lars is not among us anymore, I am sure he would have very interesting remarks and his insight would be most valuable.

[Johnny B Good]

@MIS42N

 Just one tiny nit pick, if I may. It seems to me that the last sentence is missing the word "initially". 

[MIS42N]

 

@MIS42N

 Just one tiny nit pick, if I may. It seems to me that the last sentence is missing the word "initially". 

so true.

It depends on how you interpret that sentence. Having acquired a GPSDO, it then becomes part of their kit and they then want to know if it performs well. So they acquire a better GPSDO. It's an iterative process - leading down one very long rabbit hole.

I have no use for a GPSDO at all. I like the programming challenge. I am now hooked on the electronic challenge as well.

[thinkfat]

@MIS42N

 Just one tiny nit pick, if I may. It seems to me that the last sentence is missing the word "initially". 

I can subscribe to that, oh my...

[iMo]

It is great we have got here more threads on different approaches to the GPSDO design!!
 

To the discussion on "old" Miller design (or any MCU-less one) - could we somehow formalize which one is better for a specific use? For example I want to use 10MHz GPSDO as a reference for my QO-100 satellite operation. Do I need to mess with SW one? Is the simple Miller ok for that?

From my practical experience with the Miller - there are 2 issues I see:

1. when the loop is disrupted it takes a few multiplies of the LPF filter time constant to get "locked".
Note: "locked" in Miller means you are as close as possible to the "right" EFC such you get 10MHz. There is none indication it happened, however, unless you measure the EFC voltage (I did).

2. when having a Neo module without a backup battery you have to set up the Neo module (to say a 10kHz output) via an MCU at the start (thus you need the MCU either).

With SW designs you can almost immediately "judge" you are close to 10MHz because you can remember the statistics history, thus you know that "this DAC setting is as close as possible to the 10MHz" (provided your DAC and OCXO are long time stable).

Otherwise, when locked, it does not matter whether you run Miller or any SW GPSDO, imho..

[AndrewBCN]

It is great we have got here more threads on different approaches to the GPSDO design!!
 

To the discussion on "old" Miller design (or any MCU-less one) - could we somehow formalize which one is better for a specific use?
...

Imo, to answer your questions:

1. As I wrote before, just because a GPSDO has an MCU means nothing. It all depends on how the MCU is used, in other words, on the program.

2. Please define "better". In the case of a DIY GPSDO, this could mean many, many things.

3. I am not at all critical of the Miller GPSDO design, quite the contrary actually. But technology has evolved while his design did not. So, in 2021, it's obsolete. Note that obsolete does not mean it was a bad design or didn't do its job many years ago, similar to the Apollo Guidance Computer on the lunar lander that put men on the moon some 50 years ago.
https://en.wikipedia.org/wiki/Apollo_Guidance_Computer

4. There are so many potential advantages to using an advanced MCU in a GPSDO (or any lab instrument) that I can't really make a list, it would just be too long. However, as I noted above, these potential advantages translate into reality if and only if the software/firmware implements them. Conclusion: the software really matters when you add an MCU to a GPSDO (or, again, any lab instrument).

Let's see some advantages of the STM32 GPSDO vs other designs:

1. Inexpensive.

2. Can be assembled on a breadboard in two~three hours.

3. Easily purchased components.

4. Informative OLED display.

5. Low power consumption (< 5W).

6. Full suite of sensors.

7. Modular.

8. Bluetooth interface to a smartphone.

9. Full GPS status reporting.

10. Open source hardware and software.

11. No adjustments, works "out of the box".

12. Hardware implements both PLL and FLL control loops. (Note: the PLL software is still work in progress)

13. Upgradable firmware. Flashing a new firmware takes less than a minute.

14. Uses a powerful 100MHz 32-bit ARM Cortex-M4 MCU.

And there are some disadvantages:

1. No PCB yet - this is coming ASAP.

2. Not a commercial project, you can't buy it assembled or as a kit.

3. People with no programming background may be put off by the GPSDO software, or how to flash the STM32 MCU.

4. Still an evolving project (Beta stage).

5. There is no user manual yet.

6. Even though it is probably capable of better performance, the claim is 1ppb (10E-9) short term accuracy/stability. That translates into 0.01Hz frequency or 10ns phase accuracy/stability; or 1 second every 32 years, but I honestly doubt anybody is going to keep a GPSDO running continuously for 32 years... 

[FransW]

Now it is becoming realistic.
Thanks,
Frans

[bob91343]

Advantage number 3 isn't working for me.  I am still in the midst of a dispute with Aliexpress.  Each time a deadline is reached, a new one appears.  I ordered this thing in June and the latest 2-day deadline produced a new 10-day deadline.  I despair of ever getting this thing assembled.  Even if they send a new one it will take several weeks to arrive.  (I am not measuring these times with my not-yet-built GPSDO, but with an old fashioned calendar.)

It certainly has been a learning experience, but not one I had anticipated.  I have built quite a bit of stuff over the years but this one is very frustrating.

Pardon me for venting here; I don't expect any useful replies other than to throw more money at the project and order from someone else.  Thanks for reading.

[MIS42N]

To the discussion on "old" Miller design (or any MCU-less one) - could we somehow formalize which one is better for a specific use? For example I want to use 10MHz GPSDO as a reference for my QO-100 satellite operation. Do I need to mess with SW one? Is the simple Miller ok for that?
:
:
Otherwise, when locked, it does not matter whether you run Miller or any SW GPSDO, imho..

It looks like you answered your own question. When locked, for practical purposes it doesn't matter. My experiments are all microprocessor based so no experience with Miller.

When looking at a practical application, need to specify what is actually required. For satellite operation at 2.4GHz is +- 3Hz OK? That's an accuracy of 1 part in 10E9 and as discussed just about any GPSDO should achieve that. I am running a test at the moment, the worst figure for the last 8 hours is 2 parts in 10E10. Using a $4 second hand OCXO.

So it becomes a matter of trust. Can you trust your Miller design to be locked? If so, then use it. Can you trust the software in a microprocessor? if so, use it.

My preference for uP based systems is because it can tell you when it is locked (I do that through a LED). Also it is very flexible. I use the 1pps from the cheapest GPS module straight into the processor and measure TIC to nearest 25ns. Since the jitter on the module is estimated to be 20ns they are a good match. The uP averages that (similar to a PLL but in software). Also the uP decodes the NMEA messages to ensure the GPS module thinks it has a fix (adequate signal). Can't do that with a Miller design.

The downside is that the disciplining algorithm is up to the programmer. Plenty of scope for mistakes.

[thinkfat]

The main justification for adding a processor is allow more functionality than just output of am accurate reference frequency. Technically, for this purpose the G3RUH design is just fine.

You add a processor if you want to experiment with control algorithms, have more status info than just a "locked" LED or just want more functionality in general. I made a GPSDRO with an STM32 and a TDC7200 and it worked really nicely, but then I realized that I'm wasting a lot of potential and that using a Linux SBC as the basis would open up a whole set of additional functions I hadn't thought about. For example, a stable 1PPS output without GPS jitter, a Stratum 1 NTP server, a PTP grandmaster, ...

[AndrewBCN]

When a 5ft (1.5m) GPS cable costs twice as much as a complete STM32 GPSDO...

Perhaps you have heard about a little company called FacePlant or something. It turns out their engineers decided to design an "open source" GPSDO on a PCI-e card, except of course they don't call it a GPSDO. They call it a "Time Card". See the attached diagram.
They claim anybody can build their "Time Appliance", given enough time and money... lots of money and lots of time apparently. A 1.5m GPS cable for their GPSDO Time Card costs $77:
https://store.orolia.com/collections/accessories/products/antenna-cable?variant=32314965721166

( What use is a $77 1.5m GPS cable, you may wonder? Well, I wonder too.)

Apart from that, their GPSDO Time Card would require a number of "unobtainium" parts, but you can go over the fine details of the project here: https://github.com/opencomputeproject/Time-Appliance-Project if you can make sense of their documentation.

Having poured some tens of engineer.years and no doubt about a couple of $ millions or more into their project, what is their claim for accuracy/stability? Well of course they don't give us an Allan Deviation number, because why should they follow long established standards for measuring clock accuracy and stability?

Instead, we get this, which is comically naïve:

"Indeed, when we compare 1 PPS between Time Card output and the internal reference of the Calnex Sentinel, we see that the combined error ranges within ±200 nanoseconds..."

So, 200ns jitter. Can't say I am impressed really. 

I am hereby declaring that I am challenging FacePlant that I can build a better GPSDO Time Card at less than 1/10 their cost, with at least 2x better performance, using three months of my spare time, with a total development budget of $5,000. Ouch!

https://engineering.fb.com/2021/08/11/open-source/time-appliance/

[Johnny B Good]

My preference for uP based systems is because it can tell you when it is locked (I do that through a LED). Also it is very flexible. I use the 1pps from the cheapest GPS module straight into the processor and measure TIC to nearest 25ns. Since the jitter on the module is estimated to be 20ns they are a good match. The uP averages that (similar to a PLL but in software). Also the uP decodes the NMEA messages to ensure the GPS module thinks it has a fix (adequate signal). Can't do that with a Miller design.

 That last remark is true enough with the original Jupiter T based version but if you upgrade that vintage Jupiter T to a u-blox 7N or 8N (preferably an M8T) and chuck an FTDI232 into the mix,  you can do some cunning reprogramming of the PPS line to output any frequency and duty cycle of your choosing (within the 1Hz to 24MHz range allowed) for each of the locked and unlocked states. A very useful feature when all you require (as you implied) is a simple LED indication to show whether it is locked or not. 

 I was using fake M8N modules during the time I was developing the MK II. These didn't have flash ram to store the user settings through an indefinite power down, relying only on the BBram's 40 minutes or so reserve provided by a cheap 80mF supercap. This limitation was bypassed by simply adding a CR2032 with a backfeed protection diode (and, optionally a 1k series resistor to provide short circuit protection but mainly to verify the claimed 14μA consumption of the BBRam circuit).

 Even though the CR2032 cell gave you an accumulated total powered down time of some 280 days of backup, I still needed some clear indication that it hadn't reverted to its default settings so I programmed the PPS to output 4Hz 50% duty cycle when unlocked and a 100KHz 50% when locked. There was little point in trying to phase lock the OCXO with a 100KHz derived from its 48MHz TCXO so I figured I'd be damned if I tried to do so anyway.

 More usefully, the 4Hz 50% duty cycle would produce an EFC midway between 0 and 5 volt, reasonably close to the 2.421v mark (at that time - it's now dropped to 2.381v some 12 months on) when locked to a valid 100KPPS. I could have programmed the duty cycle to place it even closer if it had occurred to me at the time but my main concern was to generate an "Unlocked to GPS" indicator on the green 'Lock Status' LED that could also alert me to a loss of user settings and reversion to the default 1PPS at 10% duty cycle where it would visibly blink (or wink) at 1PPS - the locked state is a steady but slightly dimmed glow adjusted to match the brightness of the red power on LED which, it could be argued as being an unnecessary indicator.

 I did briefly consider this 'minimalist approach' but decided it would not only provide a reassuring confirmation of its powered up status with a cheerful red glow, it would also, in that rarest of scenarios, take the guesswork out of deciding whether a completely extinguished green LED was due to an internal fault or just a missing 7 to 24 volt supply to the whole GPSDO. A modicum of redundancy being no bad thing in this case.

 The point in this case being that a modern day re-spin of the James Miller GPSDO effectively provides you with a user programmable microcontroller at the heart of these u-blox modules with sufficient end user options to make a second microcontroller redundant when all you need are simple LED indications of the GPSDO's status.

 I don't deny the benefit of using a microcontroller (with appropriately sophisticated DSP based algorithms) to greatly improve on the James Miller's erstwhile excellent performance at its inception but, as you were careful to point out, only with carefully thought out and bug free firmware (not overlooking the need to minimise the sources of error arising out of the design and assembly of the actual hardware itself).

 If you're aiming to develop a better than James Miller performance GPSDO via the microcontroller route, it might help to actually have a James Miller type of GPSDO on hand from which to improve upon, even if merely to provide a 'sanity check' on your own modest efforts, besides which, it can give you a better insight into the full extent of the problems you'll be dealing with... imho.

 Right now I'm working on figuring out an arduino based temperature controller having successfully got the BMP280 with OLED1306 display module sketch to work as a beginner's exercise and test utility. The Banggood 128 by 64 display was using the 0x3C address of the 128 by 32 version mentioned in the comment line of that sketch so I only had to edit the defined 0x3D address to get it to display the BMP's output.

 I've tracked down a sketch that uses thermistor input rather than temperature sensing module I2C outputs. Now all I have to do is figure out how to process and output this via a PWM pin to drive the switching FET controlling  the cooling fan's speed between minimum and max as smoothly as I can.

 I'm just building towards a micro controlled GPSDRO one baby step at a time at this stage of the game and I need all the experience I can gain.

[thinkfat]

Well, you'll have to provide some means to beat all their specs then, and while I too think that their solution is probably a bit overengineered (I'm quite sure you don't need an FPGA and a ublox F9T for decent GPSDO), without an atomic clock you'll not beat the holdover performance, and without a timestamping NIC you won't be able to distribute the time with the necessary accuracy. So, some money will have to change hands.

[AndrewBCN]

Well, you'll have to provide some means to beat all their specs then, and while I too think that their solution is probably a bit overengineered (I'm quite sure you don't need an FPGA and a ublox F9T for decent GPSDO), without an atomic clock you'll not beat the holdover performance, and without a timestamping NIC you won't be able to distribute the time with the necessary accuracy. So, some money will have to change hands.

Indeed. It wouldn't be fun and it wouldn't be a challenge if it didn't require some "thinking outside the box".

[MIS42N]

I did briefly consider this 'minimalist approach' but decided it would not only provide a reassuring confirmation of its powered up status with a cheerful red glow, it would also, in that rarest of scenarios, take the guesswork out of deciding whether a completely extinguished green LED was due to an internal fault or just a missing 7 to 24 volt supply to the whole GPSDO. A modicum of redundancy being no bad thing in this case.

I took the minimalist approach. If the LED isn't doing something, something has failed. It makes different indications for power on, OCXO failure, satellites in view, trying to lock, locked but not verified as 10E-9 accurate, and verified. The use of 1 LED was partially philosophical (why have two when one will do) and partially practical (ran out of easy options to program a pin).

I spent a few minutes looking through the Time Card documentation, talk about using a bulldozer to crack a nut!!

I doubt that AndrewBCN could deliver on his challenge, but what would be the point? The thing overspecified to the extreme. It seems most synchronisation needs are in the microsecond region, so specifications like this seems a bit over the top:

PPS out

    PPS Out Rise/Fall Time < 5 nano Sec
    PPS Out Delay < 400 pico Sec
    PPS Out Jitter < 250 femto Sec
    PPS Out Impedance = 50 Ohm
    PPS Out frequency 1Hz - 10MHz (a new meaning for PPS?)

I question the need for holdover - "In the event of the GNSS signal loss". I have never seen signal loss of more than a few seconds, and that is rare. I just looked at stats from my current test, over 500,000 seconds and no loss. The losses are categorised as 'Lost Fix' (the NMEA data says fix is lost), 'missing 1pps' (expected to be in a 1ms wide window) or 'discarded' (in the window but not within +- 400ns) and the figures are zero for all. The GNSS has multiple constellations each of which has redundant satellites. They are not going to fall out of the sky and they are not going to run into each other. What sort of event causes losses greater than a few minutes (which any decent OCXO will hold within a few nanoseconds). And if it is a worry, put in a redundant GPS derived time source.

Then there's the interesting idea that the time card goes in a PC that then talks to a NIC. The PC clock isn't synchronised to anything so inevitably introduces some jitter. Or "For the extremely high precision 1PPS output of the Time Card will be connected to the 1PPS input of the NIC, providing <100ns precision". Whoopy do. Does this need a PPS with jitter < 250 femto seconds and delay of 400 pico seconds?

A solution looking for a problem to solve?

When people really need synchronised clocks, they do it by independent dual band GPS receivers. For most commercial use, a few microseconds is immaterial. Years ago I supervised the implementation of time synchronisation on many thousands of PCs and servers. We were happy if they agreed to the second.

[AndrewBCN]

The holdover specification is a legacy from pre-2000 GPS receivers, when the world had a single constellation of timing satellites, and some or most of them could be brought off-line at any time, arbitrarily, by the US military. When NTP servers and entire communication networks depended on these GPS satellites, you had to have a specification for when the GPS system was brought off-line. Hence the different holdover requirements for different NTP strata servers.
In the case of a GPSDO, the holdover specification refers to the maximum drift over an arbitrary specified period, usually 24 hours, and/or one month and/or one year. As MIS42N wrote, these holdover specifications don't make much sense in 2021, when any commercial GPSDO and even a $35 DIY STM32 GPSDO can be kept working uninterrupted and permanently GNSS locked for any length of time (hence with essentially zero drift relative to GPS time).
Also NTP servers check on each other, the whole NTP infrastructure is extremely resilient and if you want to make sure your local network always has accurate time, just use two, three, four or more inexpensive GPSDOs connected to properly distributed Linux NTP servers (which don't even need to be dedicated machines).

As MIS42N wrote, the FacePlant GPSDO Time Card is ridiculously overengineered, over and under specified, absurdly expensive and worst of all, constitutes a single point of failure if an entire FacePlant data center depends on it. It's a solution looking for a problem that doesn't exist, and it's also a security risk for an entire data center to be brought down because of a single hardware or software failure.

Oh, I stand by my challenge. 

[thinkfat]

What irks me most about the TimeCard is the effort spent on a nearly jitter-free, low-delay PPS output (well, edges could be a bit faster, but hey...) just to feed it into the PPS input of a network card which then wastes all the precision because its timestamping is not nearly at the same level.

PS: Adding insult to injury, the PHC that delivers the timestamps is asynchronous to the wall clock of the PC which requires synchronizing that clock to the PHC using a software PLL, which additionally degrades the stability of the end result.

[AndrewBCN]

Erik (erikka) has noticed an important error in the schematics Rev 0.4: I had inverted pins PB10 and PA15. I am attaching below the corrected schematics, Rev 0.5.
Many thanks to Erik, of course. 

Btw, Erik is testing the use of the cheaper, but with less RAM and ROM, STM32F401 Black Pill. For most purposes, it's a drop in replacement, except for one detail: the 10,000 seconds 64-bit ring buffer does not fit in 64KB of RAM. No big deal, since we can use a 5,000s ring buffer with a one-bit loss of resolution in our 0.0001Hz frequency measurements.

More news on this front as Erik progresses with his experiments.

[FriedLogic]

Ian Cutress did an interview with a Facebook engineer involved with this on his Youtube TechTechPotato channel:
“Democratizing Time: Hands on with an Atomic Clock PCIe Card”


It's maybe not the best interview ever, but it gives an overview and helps explain design choices like the oscillator. Holdover requirements really are still here in 2021.

[AndrewBCN]

"It's maybe not the best interview ever..."

That's quite the understatement. It's a terrible interview.

The name of the FacePlant engineer is Oleg Obleukhov (also the co-author of the blog post I linked to), and during the entire interview he does not refer so much as once to the essential concepts of Allan variance/deviation, just as in the blog post.

Clearly the team that designed the FacePlant GPSDO "Time Card" skipped on the fundamentals, tried to compensate for that lack of basic knowledge by overengineering the "clock processing logic" aka "time engine" (the FPGA), worked hard on "re-inventing the wheel" of GPSDOs, and failed.

One excerpt from the blog post: "The time engine’s job is to interpolate in nanoseconds the granularity required between consecutive PPS signals." That translates to "We reinvented a nanosecond resolution TIC using an expensive FPGA, to measure the phase difference between the oscillator and the GPS PPS".

Lars used a $0.50 4046 and a few discrete components to achieve the same thing, and the STM32 GPSDO uses Erik's version of Lars' TIC that requires a $0.10 74HC74 and a few discrete components, plus a few lines of code in the STM32 MCU. And it probably has better overall resolution than the FacePlant TIC "Time Engine" (implemented in the FPGA).

If your $50 million datacenter cannot afford a pair of good $50 rooftop GNSS antennas then I guess yes, in your case holdover specs still matter in 2021. 

Oh, and the most incredible "feature" of the FacePlant GPSDO "Time Card" is probably the most obvious one, and also the reason I mentioned the FacePlant project in this thread in the first place: they spent > $3,000 and are using an 8-layer PCB with plenty of empty space, but they couldn't fit a $5 32-bit ARM MCU in their design. 

[AndrewBCN]

After checking with Erik, I made one small change to the TIC circuit: the 1N4002 diode is replaced with a 1N5711 Schottky diode with 1ns reverse recovery time or equivalent. The 1N4002 definitely should not be used for the TIC.
Attached the revised schematic.

I have received the components to build the TIC circuit and I'll add it to one of my three STM32 GPSDO prototypes for testing.
An excellent, detailed description of how the TIC works can be found in Lars' documentation, for those interested.

As I wrote before. adding a TIC / phase difference measurement circuit to the STM32 GPSDO allows the implementation of a PLL control loop, or something that has never been tried before AFAIK: a hybrid PLL/FLL control loop.