Yet another DIY GPSDO - yes, another one

[Johnny B Good]

 That does rather beg the question as to what you're intending to use a 10MHz reference for. Correct me if I'm wrong but would I be right in assuming you intend to recalibrate some HF radio gear?

[thinkfat]

Johnny B Good I read your message and frankly it's mostly over my head.  All I want is 10 MHz but it appears that getting it isn't as simple as I expected.  While I have an engineering degree, it predates all this modern stuff by many years.  I have a reasonable grasp of the fundamentals and more, and have texts which I can peruse, but I am mostly lost in this morass of integrated circuits, digital technology, and software.  I don't hide behind my age, since I don't see that as a factor.  But my proclivities and talents lie elsewhere than what it seems to require to manage a project such as this.

So I was hoping Andrew would supply a circuit board and I could install the components and have a complete project.

If someone can give me a simpler route to my destination, I am ready to try it.

What Johnny tried to tell you in his usual elaborate ways, is not to be afraid. Even with a ragtag assembly like his, good results can be achieved.

[AndrewBCN]

Just to get back on topic, attached is a picture of the tiny WeAct STM32F411CEU6 Black Pill MCU development board, the "brains" in this project that Bob has been waiting upon for the last month or so. Note it also includes an onboard LDO 3.3V regulator which provides 3.3V to the OLED display and other modules. The STM32F411CEU6 chip includes a 32-bit ARM Cortex-M4 processor running at 100MHz, 128kB RAM and 512kB of flash memory and various peripherals, which help reduce the BOM of the GPSDO to a handful of parts.

The WeAct STM32F411CEU6 Black Pill costs around €5.50 plus shipping and taxes from the recommended seller on AliExpress. Delivery in 10 days usually. If anybody wants one pre-programmed with the latest version of the STM32 GPSDO firmware I can ship it worldwide at cost (please PM me if interested, do not post on this thread), but I strongly recommend that one program it oneself, as part of the learning experience and the entire operation takes a few seconds at most.

[erikka]

Andrew,
W.r.y the choice of adding the phase detector.
Lars could not directly count 10MHz due to the low clock speed of the nano so he had to count 2.5MHz and lost a factor 4 accuracy compared to directly counting the 10MHz.
The phase detector in theory can have a (sub) 1ns resolution (10e-10) of the 10MHz edge but as the 1PPS has jitter in the order of 21ns. The increase in resolution versus counting 2.5MHz (400ns) is only about a factor 20 and versus counting 10MHz it is only a factor 5. To have a practical below 1ns 1PPS timing measurement accuracy I do average over at least 40 seconds.
The advantage of the phase detector in my view is not so much the fact it can detect a correct phase at high accuracy (1ns) as the counting of pulses also can do this given enough time,  but the phase detector gives a (almost) linear reading of the amount of deviation allowing a P controller to very quickly steer the 10MHz to the right value.
Below a log of a hot start. The phase detector starts to contribute at 0:01:00 with a first measure phase error of 15.5 (7.7ns error, 6.0e-9 correction) and in two steps this error is reduced to 0.2ns or -8.0e-11 correction at 0:03:07

Code: [Select]

Waiting for GPS
0:00:05 dur=4 acount=864 dcount=27872 calfact=0 xtal=10000000000 corr=0.0e0 dac = 2047
0:00:08 dur=2 acount=4999999 dcount=-1 calfact=0 xtal=10000000000 corr=0.0e0 dac = 2047 Lock
0:00:13 dur=4 acount=9999999 dcount=-1 calfact=0 xtal=10000000000 corr=0.0e0 dac = 2047 Lock
0:00:22 dur=8 acount=19999999 dcount=-1 calfact=10 xtal=10000000000 corr=10.0e-11 dac = 2057 Lock
0:00:39 dur=16 acount=40000000 dcount=0 calfact=0 xtal=10000000000 corr=-10.0e-11 dac = 2047 Lock
0:01:00 dur=40 p_average=15.05 phase=-1.00 calfact=602 xtal=10000000000 corr=6.0e-9 dac = 2649
0:01:47 dur=80 p_average=-4.32 phase=-1.00 calfact=516 xtal=10000000000 corr=-8.6e-10 dac = 2563
0:03:07 dur=160 p_average=-0.43 phase=779.16 calfact=508 xtal=10000000000 corr=-8.0e-11 dac = 2555


[erikka]

I'm doing an experiment with using a SI5351 as GPSDO clock output generator. The XTal on the SI5351 module is removed and the OXCO 10MHz is used as the PLL reference for the SI5351.
By avoiding fractional dividers the 10MHz output of the SI5351 to the STM32 (or 2.5MHz for the LARS GPSDO) and also additional 100MHz or other frequencies outputs can be generated. And the SI5351 also acts as a buffer for the OXCO.
The SI5351 is perfectly happy with the 10MHz reference and the phase noise is outstanding. No fractional spurs at all. The datasheet mentions a limited PLL reference clock range but this only applies when used with an XTal, not when using an external oscillator.

[erikka]

In view of your stated requirement for a basic 10MHz reference, may I suggest that you start with the most basic of GPSDO projects as outlined by Gyro in this topic thread here:-

 https://www.eevblog.com/forum/projects/my-u-blox-lea-6t-based-gpsdo-(very-scruffy-initial-breadboard-stage)/msg929133/#msg929133

 As he mentions, it was inspired by James Miller's simple GPSDO (a small factoid I'd forgotten when I first described my own initial GPSDO projects as being inspired by this version, namely the circuit diagram he'd attached in the final thread posting).

Bob
I tried this by setting the output of a NEO-7M to 10MHz and using a 7474+7400 phase frequency comparator (an XOR would have worked too) to lock the 10MHz OXCO using a loop filter with a corner frequency of about 0.1Hz. Locking is very quick but.....
When looking at the 99th overtone of 10MHz (990MHz) on a SA the SA can show 1Hz changes in frequency, which is 0.01Hz of 10MHz or 10e-9 accuracy and the locked frequency of the OXCO jumps 0.01Hz up and down every second as the NEO-7M is dithering its output frequency. You will never see this when measuring the frequency of the 10MHz signal as you have to average over a long period for sufficient accuracy.
Or was I doing something wrong here?

[AndrewBCN]

Hi,
I have very good news: Erik (erikka) has kindly agreed to allow me to include his 1ns resolution phase difference measurement circuit (inspired by and an improvement on Lars' similar circuit) in the final STM32 GPSDO schematic.

I am including the footprints in the PCB for the components for Erik's phase detector, these can be optionally populated or not: a 74HC74 dual flip-flop and a handful of passive components.

The inclusion of Erik's circuit makes it possible for the STM32 GPSDO to use two different control loops, FLL or PLL, or even a hybrid FLL/PLL control loop: this is now up to the imagination and talent of the programmer.

As far as I know this will make the STM32 GPSDO quite unique in the world, as the only GPSDO to include both FLL and PLL functionality. It's probably the ideal platform for experimentation with GPSDO concepts and algorithms, at this point.

I am working on finalizing the schematic for the STM32 GPSDO and I already got started on the PCB layout.

In summary: the basic version of the STM32 GPSDO requires three modules and a handful of passive components plus a GPS antenna, costs around €25, can be assembled on a breadboard in a couple of hours and outputs a stable 10MHz +/- 0.01Hz signal (that's 1ppb or 10E-9). The three essential modules fit in the palm of one's hand (see picture below).

The maximum configuration including all the bells and whistles will include a quality 5V power supply and allow exploration of 10E-10 and 10E-11 territory, algorithms for improved holdover performance, comparisons of PLL vs FLL vs hybrid PLL+FLL control loops, etc, etc, etc. All that while still remaining under €40 total BOM cost (+ PCB cost) and fitting on a small 150x100mm PCB. And oh yes, did I mention the STM32 GPSDO can be controlled from any smartphone using the (optional) Bluetooth module? 

And of course one can assemble the STM32 GPSDO "à la carte", meaning with the optional modules of one's choice.

So again: the good news is that Erik has kindly agreed to allow me to include his 1ns resolution phase detector circuit. I have included it in the second sheet of the schematics, see attached KiCad schematics sheet.

[Johnny B Good]

@erikka

 First things first, my name is John (it's hidden away in my sig line at the bottom of each of my posts  ). The 7474+7400 phase frequency comparator (PC2 option in the 74HC4046) has the charm of being insensitive to the duty cycle as well as outputting a voltage in response to frequency difference between the ref and sig inputs.

 In this case, assuming you've configured the PPS for a 50% duty cycle 10MHz output, a simple XOR phase detector (PC1 option) would have served just as well (or even better, depending on your needs). I tried the PC3 charge pump option of the 4046 but this had too large a deadband to be of any value in this application so I went back to the PC1 option in my MK II design.

 Unless you're using a screened feed for the PPS output (with a 33ohm series resistor to attenuate the high frequency harmonics), the 10MHz square wave (a rather respectable looking square wave I might add) is likely to impair reception of the SV signals (as I noticed when I tried experimenting with different PPS output frequencies (1MHz and 10MHz settings). I stuck with the 100KHz option as used by Gyro and for much the same reason that he chose this as a more optimised setting than the 10KHz only option provided by the Jupiter T GPS engine that had allowed James Miller to simplify his GPSDO design (avoiding the need to divide the 10MHz OCXO frequency output by 10,000,000 in order to phase lock it to the 1PPS as had been the case with earlier designs).

 One thing I did notice when phase locking on the 1 and 10MHz PPS output settings was the speeding up of acquiring a lock between the OCXO and the GPS. A not unexpected result after my doomed to total failure trying to get a cheap M6N to emulate a 1KHz signal on its PPS line where the process could at best, only be described as "Glacial" (those early pioneers using a 10,000,000 divider to lock to the 1PPS line must have had inexhaustible supplies of patience

 Still, since you really need to allow the OCXO a good ten minutes of warm up time, fast lockup to the GPS is not a particularly high requirement since all that does is have the PLL chase a rapidly moving target as well as impose an otherwise needlessly high switching performance requirement on the PLL circuit and raise the power density of the switching harmonics in the L1 band.

 Whether you're phase locking at 10MHz or, more sanely, 100KHz, provided you're using a long time constant filtered output from the PLL to drive the VFc pin on the OCXO (buffered or not), the jitter and sawtooth corrections will more or less disappear into the noise leaving only the inescapable effects of space weather (changes in the ionosphere) and to a lesser extent variations of "precipitatable moisture content" in the stratosphere to contend with.

 Ionospheric effects seem to account for around 6 or 7ns pk-pk phase shifts with my L1 band NEO M8T. A much more expensive multiband ZED9 timing module can eliminate this type of error on the fly for each and every SV signal but not the order of magnitude less variations in the ToF due to the stratospheric moisture content variations (nor for the remaining errors in the GNSS system (clock timings and orbital positions of the SVs themselves as well as a bunch of other lesser sources of error within the system as a whole).

 There's only so much you can do with a James Miller type of GPSDO design despite its excellent performance compared to those microcontroller based units. I suspect this may have been more to do with his choice of OCXO (a low phase noise Axtal IIRC) than anything else. Longer time constants can help reduce the effects of fluctuations in the GPS signals but this relies on the medium term (hours long) stability of the OCXO or DOCXO being used.

 It's possible to make a hardware LPF with a time constant as high as 5000 seconds but even if the LO was stable enough to take advantage, this isn't the optimum way to filter out the GPS errors. Doing this filtering in software is a more optimal solution but it lets in a whole host of temperature related issues that can't neatly be swept under the carpet as is the case with a simple hardware filtered PLL solution.

 However, when it comes to disciplining a Rubidium oscillator (essentially to take care of the ageing effect), a software approach is really the only effective solution since we can now realistically integrate a whole 24 hours' worth of GPS timing data, allowing our GPSDRO to closely approach the 10E-14 limit of the GPS system clock.

 Although I've been extolling the simple charm of a hardware PLLed GPSDO, I'm reading these microcontrolled GPSDO project threads to acquire ideas on how to best implement my own variation of a microcontroller solution to turn my RFS project into a GPSDRO.

 Despite my avoiding the use of a microcontroller so far in my RFS project, it has become rather obvious that I've reached the stage where I now have to compensate for barometric changes which means I'll need to use one of my stock of three Nano 3 modules simply to convert the I2C output of a BMP280 sensor into an analogue control voltage to feed into the external C Field adjustment pin on the LPRO. Inevitably, once I've got that far, it becomes rather obvious that I can also use it to control the fan cooler much more intelligently than that thermal controller breadboard lashup I've got set up on the bench.

 Ultimately, I'll be using it (or a second one) in a GPSDRO setup. However, I started to suspect that a Nano 3 might not be up to this task so when I spotted a link in one of Banggood's many spam mails to a RPi pico board, I took a closer look. At something like 12 quid delivered from China for just one board, I decided to shop around and landed up buying a pair for just less than Banggood's price delivered from the UK based PiHut in less than a week.

 It struck me that the Blackpill is like a Nano 3 on steroids. You could say the same for the RPi pico but it's more like a Blackpill on steroids with its Dual-core ARM Cortex M0+ processor, flexible clock running up to 133 MHz, 264kB of SRAM, and 2MB of onboard Flash memory. Best of all, like the Blackpill, it too can be programmed using the Arduino IDE.

 Either of these two "Nano 3 on steroids" modules will do the job with plenty of left over power to spare and It seems to me that AndrewBCN's code should run on either of these modules but I haven't dared to take a peek at his code to check

[bob91343]

John, I think you were asking me my application for the 10 MHz.  I simply want it as a standard for my counter.  Most of the time I deal with frequencies in the HF range but I want the confidence that I feel when my source is a couple of orders of magnitude more accurate than the counter.  And I want verfification of my rubidium standard, which otherwise runs off at its own pace with no way to see how good it is.

So 1 ppb is good enough for most of what I do but a little better would be welcome.

[Johnny B Good]

 I'm using an Efratom LPRO-101 rubidium oscillator so I only have datasheets and manuals for this model of rubidium oscillator as my guide. I can only speak for that model which has an internal 10 turn trimpot to adjust the frequency (as well as an external C field input pin) which, according the the manual specifies an adjustment range of >+/-1E-9 (one part in a billion) for either input going on to state that the internal and external adjustments are summed together followed by mentioning a >1.5E-9 adjustment range individually. I think they'd gotten things a little mixed up and I suspect they meant that the adjustments combined could provide in excess of +/-1.5ppb and a guarantee of at least a +/- 1ppb for each input.

 I would expect the FEI models to have similar fine tuning options with very much the same adjustment ranges, implying that if you preset the internal pot to its mid position, you'd almost certainly land up well within +/-1ppb without any need to calibrate it against another atomic standard such as a GPSDO. In other words, it's very likely to exceed you requirements as it stands without any further adjustment.

 Incidentally, the ageing error is given as less than 50ppt per month and less than 1ppb per decade according to this Symmetricom telecoms information leaflet (attached below).

 Whilst accepting such calibration accuracy on blind faith in the manufacturer's specifications does go against the grain, for the moment that's your best option until you can compare it against a GPSDO (whether borrowed, begged or stolen or courtesy of an obliging friend).

 JOOI, what brand/model of Rubidium oscillator do you have (there's more than just the Efratom/Symmetricom LPRO and FEI  models to choose from)?

[bob91343]

Electronic Research Model 130.

[Johnny B Good]

Electronic Research Model 130.

 Thanks (I think...  )

 I did a search for that model but only found 4 pictures which led to a couple of ebay sellers who offered zero information other than pictures (one with a date code of 95-23, presumably week 23 in 1995).

 They've most likely simply repackaged one of 'the usual suspects' (Efratom LPRO or FE-5680A or WHY) in an enclosure of their own design. Have you taken a peek inside to see what they've actually used?

[thinkfat]

I suggest getting a LPRO. I have good experience with them, they are usually reasonably priced, a quite modern design that has only few unobtainable components should the need to repair them arise. Solid performance.

[Johnny B Good]

I suggest getting a LPRO. I have good experience with them, they are usually reasonably priced, a quite modern design that has only few unobtainable components should the need to repair them arise. Solid performance.

 I wholeheartedly agree with that conclusion. Just over a year back when I was researching purchasing options on rubidium oscillators, I swiftly came to the conclusion that the LPRO 101 was the best bet over the more ubiquitous FE-5680A (and its many many variants).

 The two main reasons being its much cleaner output and, perhaps more importantly, the much greater availability of meaningful service manuals and user guides and a greater proliferation of repair and configuration/setup youtube videos and articles. The sheer number of various options mostly under the single model number of FE-5680A in the case of the FE inc brand units meant you couldn't be certain as to what you'd land up purchasing - the FE inc units were pretty much a crap shoot so best left untouched as far as I was concerned hence my purchasing an LPRO-101 from (as I later discovered) fellow EEVBlog member testpoint1, last August for just under £200 shipped to the UK from Massachusetts, USA. My recent search for info on that rare Electronic Research Model 130 of Bob's revealed that the prices on these rubidium oscillators are still climbing skywards!

  a prime example of "supply and demand effect" being so strongly evident with ebay (and Amazon) sellers. It's not just limited to rubidium oscillators, of course. I had a taste of this last year when I purchased my first NEO M8T module at a bargain knockdown price of just 41 quid from an Amazon seller who, just a few weeks later, started selling them for just 24 quid each of which I snapped up another two, only to discover a few more weeks afterwards that he'd jacked the price right up to 61 quid a pop - one of the few times that I've been in the right place at the right time! 

 BTW, I've attached a screenshot showing the result of a 12 plus hours overnight run comparing the RFS against the GPSDO using infinite persistance to record the 6ns GPS wobble and 18ns RFS drift after finally managing to re-syntonise the RFS around 3am yesterday.

 There's probably a strong element of serendipity involved (the barometric readings had dropped to a low of 979mB by then- it's now been showing 981mB over the past 4 hours and may continue a modest rise over the next 24 hours).

 The key improvement over my earlier temperature stabilisation experiments lies in my upgrading the 3 or 4mm thick wrapping of polyethylene foam packaging material I'd applied as an afterthought when I'd deluded myself that I'd found just the right size of enclosure for the project (there wasn't any room to use more insulation). I've ditched that enclosure entirely and wrapped it up in a 2cm thick layer of polystyrene foam which now makes the attached fan cooled heatsink almost entirely the sole arbiter of the LPRO's temperature with a much reduced internal thermal gradient variation from changes in the ambient temperature.

 I'm building myself a custom sized enclosure to allow the insulation to be supplemented by another two centimeter's worth of polystyrene foam which means the otherwise hidden barometric effect on frequency stability will need to be addressed to effect any further improvement. This means I'll need to throw a nano 3 at the task (analogue output barometric sensors are as rare as rocking horse droppings if you exclude the rather expensive industrial standard 4 to 20mA types making the 2 quid BMP280 sensor the only sane option).

 Since I can't avoid adding a nano 3 without foregoing the benefit of barometric compensation, I'll be maximising the benefit by making the nano 3 take care of the temperature control as well, neatly doing away with the current analogue controller lashup.

 I've got a couple of those new fangled RPi pico boards (basically a Blackpill on steroids) which could do both these jobs and that of a GPSDRO with resources to spare but I think I'll split the GPSDRO and environmental regulation on separate microcontrollers since the nano 3 will create a standalone RFS setup independently of whatever GPSDRO software experiments I may care to run on the RPi pico board.

[bob91343]

I have not opened my Electronic Research Model 130.  I am loath to do so for fear of damaging it.  Once I get this GPSDO running I will have less to lose.  As it is, too many things need doing around here and it overwhelms me such that I don't do any of them.  I did pull out the TS-940S transceiver and got it running properly again so that's a good thing.

I do believe the model 130 is simply someone else's standard unit packaged with a power supply.  It has a lamp to indicate warming up and one to indicate lock.  Not even a power switch.

https://testequipment.center/Product_Documents/Electronic-Research-130-Specifications-F561E.pdf

https://www.popscreen.com/prod/MTgxOTYxOTIy/Electronic-Research-Company-ERC-Model-130-Rubidium-Reference-Oscillator-R1192A

[Johnny B Good]

 @bob91343

 Thanks for posting those links. I'd already discovered those pictures but the pdf link provided some useful data. The specifications are pretty well run of the mill for these surplus Rb oscillators and seem a close match to those for the LPRO. The 5E-10 per year ageing figure neatly ties in with the 10 year ageing figure of <1E-9 for the LPRO (the annual ageing rate typically slows down over the years).

 I can understand your reluctance to poke around the innards. "If it ain't broke, don't fix it!". However, you may have to if it turns out to be in need of a re-calibration once you do sort out a GPSDO to test it against.

 Talking of which, I have another screenshot at the 22+ hours mark in my current frequency stability test. If I'm still up and about when it completes the full 24 hour run, I'll be posting a final screen shot in another two hours or so.

[Johnny B Good]

 As promised in the previous post, I'm providing the final screenshot of a 24 hour run which has used the DSO's infinite persistence to record the relative shifts in phase between the Rb oscillator (trigger source CH2) and the GPSDO's 10MHz output (CH1).

 The persistence shows a total of some 24ns shift in phase relative to the trigger source of which at least some 6ns worth will be that due to the effects of the ionosphere on the GPS signal. This suggests a net drift of the Rb oscillator of around 18ns in the past 24 hours (the test run had been started with both traces aligned with each other just after 3am the day before).

 This translates to a frequency difference of 2μHz or an error of 2E-13 against the GPS master clock. I've now cleared and realigned the two traces as of 03:54 BST to observe another 12 or 24 hours' run to see how long it takes before it starts drifting off frequency. I expect the error to increase from now on in, it's not a question of if, only one of when.

[bob91343]

When I first got the Model 130 I beat it against the HP 10811 in my counter.  I set the Lissajous as steady as I could, which was excellent.  After several minutes it had drifted one cycle or so at 10 MHz but for the casual observer it was stationary.

Months later I warmed up the model 130 again and ran the same test.  To my joy and amazement, the Lissajous was pretty much steady as before.  So maybe it's not right on frequency, but it's certain matched between the two 10 MHz signals.  The GPSDO will allow me to compare it to whatever the scientific world now uses as a standard.  Once I do that comparison, I can adjust the two local sources such that all three signals are zero beat, or as close as my patience (and the phase noise) will allow.

Why I get pleasure from all this is a mystery.  However, I do, and once it all gets synchronized I will have as good a frequency standard as I can get.  While the lab at WWV might have better signals, there is no way I know to make any further comparison, without spending considerable money by shipping my gear to Colorado.

[MIS42N]

If all that is needed is a 10MHz reference with +-0.01 accuracy (i.e. 1 part in 10E-9) then this circuit does it. It has a GPS module and two ICs; a PIC16F1455 to do the the heavy lifting and a 74HC04 to output 10MHz square wave into 50Ω. I have tried several versions of this and 1 part in 10E-9 is easy, 1 part in 10E-10 is not so. Of course, being locked to GPS its long term accuracy is however long you want to run it. I intend to get a PCB made for it when I figure which version of the micro USB port will be used, there appears to many options.

The design is supposed to be somewhat flexible in that either it is run off a 5V USB charger or some other supply through a barrel connector and a 7805 regulator, just mount the appropriate bits. It has a serial output for debugging and logging, but the one LED indicates a lot of status - e.g. lock is a double flash per second, achieved 10E-9 is single flash per second. It also has signals for no input (OCXO not running so PIC running off internal clock), no serial input from GPS, indication of satellites before getting a fix (e.g. receiving less than 4 satellites will not achieve a fix). I have been writing it up here https://www.eevblog.com/forum/projects/budget-gpsdo-a-work-in-progress/ but been busy with other things for a few weeks.

[AndrewBCN]

Just to get back on topic, attached are the three sheets for the schematic of the STM32 GPSDO, rev. 0.4, with the optional 5V low noise power supply, sensor modules and output buffers and most importantly, the (also optional) 1ns resolution phase difference measurement circuit by Erik (erikka).

The software source code - actually an Arduino sketch - is available in my GitHub repository here: https://github.com/AndrewBCN/STM32-GPSDO

As duly noted in the schematic and in the GitHub repository, this project is entirely Open Source. More specifically, the software is under a GPL V3 license and the hardware is under a Creative Commons - Attribution - ShareAlike 3.0 license, described here: https://creativecommons.org/licenses/by-sa/3.0/

The next chapter in this project/adventure is the PCB which I am also designing with KiCad. I have started work on the PCB design already but I expect it will take me a few weeks. And just as a reminder: the basic version of the STM32 GPSDO can be assembled and tested on a $3 breadboard in a couple of hours, provided one has the three main modules at hand: the u-blox Neo M8N module, the STM32F411CEU6 "Black Pill" and the 10MHz OCXO (see attached picture).

[erikka]

A question to the esteemed and knowledgeable visitors of this topic.
As far as I am able to judge there are at least two ways to gather information for the OCXO control loop.

• Take per PPS a TIC value either from counting the 10MHz pulses or optionally extended with a value from a phase detector and feed this TIC into a PI(I)D controller to determine t o set to what DAC voltage when needed
  
• Count 10MHz pulses, optionally extended with phase measurement, over a certain large  (40-400) number of PPS and use that number to calculate a new value for the DAC (if needed)
  

In the  leapsecond GPSDO simulator method #1 is used, Andre and Lars also use(d) method #1. Roland used method #2 in his very simple, but functional GPSDO
Is there any clear advantage of either method #1 or #2?

[AndrewBCN]

A question to the esteemed and knowledgeable visitors of this topic.
As far as I am able to judge there are at least two ways to gather information for the OCXO control loop.

• Take per PPS a TIC value either from counting the 10MHz pulses or optionally extended with a value from a phase detector and feed this TIC into a PI(I)D controller to determine t o set to what DAC voltage when needed
  
• Count 10MHz pulses, optionally extended with phase measurement, over a certain large  (40-400) number of PPS and use that number to calculate a new value for the DAC (if needed)
  

In the  leapsecond GPSDO simulator method #1 is used, Andre and Lars also use(d) method #1. Roland used method #2 in his very simple, but functional GPSDO
Is there any clear advantage of either method #1 or #2?

Erik, my understanding is that what you describe as control loop method #2 is just the same as control loop method #1, but averaged over a time interval of 40-400 seconds. This "averaging" mathematically has the same effect as the "low pass filter" in an analog PLL or the "time constant" in Lars' GPSDO or the overlapping 1s/10s/100s/1000s/10000s time intervals in my FLL GPSDO.

The mathematical analysis of closed control loops has decades of history and I would say it's pretty much established science, so I would prefer to point you to this Wikipedia article rather than discuss it here in this thread: https://en.wikipedia.org/wiki/PID_controller

Note that since you, Lars and myself are using MCU's in our control loops, we can program whatever control loops we want. But from my limited experience I would say even a simple control loop does a good job of rapidly stabilizing an OCXO to 1ppb.

So If you are curious, I would suggest you read more about control loop theory, and then program and experiment with various algorithms yourself, you'll learn a lot while doing so! 

[Johnny B Good]

@bob91343

 Why you get pleasure out of such activity is really no mystery As pretty well everyone here knows full well, it comes from that warm glow of 'a strong sense of achievement'. In your case from being able to improve the accuracy of your HP10811 against a (secondary) Atomic Standard and later discovering months afterwards that both had remained 'in calibration', proving that both were remarkably stable frequency references under the quite reasonable assumption that this wasn't likely to be due to both having coincidentally suffered exactly the same ageing induced error.

 I swiftly discovered in my late teens (just over half a century ago now ) never to trust that even well respected manufacturers 'had done the right thing' in regard of both design and calibration so learned very early on to ignore that old adage "If it ain't broke, don't fix it!".

 I became rather interested in high quality audio recording (a logical step from my interest in amateur radio) so had purchased an Akai 4000D way back in 1967/8 which proved to have a mismatch between the record and playback heads which I belatedly discovered when downmixing my stereo recordings into mono to dub onto mono cassettes for portable convenience (I'd already dubbed a hundred or more vinyl albums by then so it was a particularly egregious discovery - no great problem with today's computerised audio processing but a disaster back then).

 When I upgraded to an Akai GX630DB a few years later, I was mindful of this issue and the possibility of other 'design errors' so made sure to order a full service manual from Akai before the supply dried up (When I'd placed an order with Rank Xerox for an M8 service manual, they'd been obliged to ship me a photocopy of their own service manual copies - two in fact!).

 I'm glad I did because when I'd read an otherwise glowing review of the GX630DB in Studio Sounds magazine, spoilt only by the discovery of a replay clipping issue (at the +8dB VU level) when testing with recordings made at high levels on another brand of machine, it led me to take a closer look at the replay circuitry, notably the Dolby processing boards where I discovered the emitter follower output stage was biased at quarter of the rail voltage rather than the expected mid point voltage. I calculated a resistor capacitor biassing network that would maintain the audio gain but shift the emitter voltage to the mid point to eliminate the asymmetric clipping that had reduced the clipping level by some 6 or 7 dB.

 It was only several months later that I saw the original Dolby circuit published in a Wireless World article which revealed that I had only managed to reverse engineer away the penny pinching bodge that Akai had inflicted and restore it back to the full Dolby reference standard. You may well imagine my sense of satisfaction and smugness (don't hold back on the 'smugness' )

 The story with the Dolby boards didn't end there since the stereo Dolby board used in the record amp chain had been likewise afflicted which neatly explained why a gross intermodulation would arise with high levels of bass, an effect which I'd initially assumed to be a limitation of ferrite over mu-metal used in Akai's Glass Xtal heads.

 Since the bass boost part of the recording EQ had been applied before going through the Dolby circuit on the quite reasonable assumption that the Dolby processing ignores the extreme low bass content (the high frequency record EQ boost being applied to the final stage after the Dolby circuit), this too needed to be brought back to standard.

 The only difference this time being that I didn't need to replace the resistor in the emitter follower with a constant current generator circuit as I had done with the replay boards to avoid the onset of asymmetric clipping with output loadings above a minimum limit of 3K impedance. The use of a resistor, in this case 3kR, in an emitter follower compromises the clipping limit in an asymmetric way even for reasonably high impedance loads of 10K (I had decided on this extra modification to the Dolby reference design on the basis of "Why only do a half assed job whilst you have the opportunity to a full assed one to make it more robust against any unusually low loadings that may get connected to the line out sockets?). The output loading on the record boards was well defined so didn't require this level of robustness.

 That investment in a workshop manual had more than paid for itself. Not only was I able to add more upgrade modifications (Xtal locked bias oscillator, 12 step switch adjustable bias, HF EQ and record amp sensitivity levels to optimise for a wide range of tape formulations that could be noted against each reel of tape for future reference) as well as allow me to troubleshoot a sudden capstan speed instability due to a shorted out 1N4001 diode in the bridge rectifier part of the servo circuit which controlled the direct drive capstan motor, not once but twice - second time round I used higher voltage 3A rated diodes to avoid any further repeat performances.

 The result of that hard won experience with kit that turns out to 'broken by design' (Transam Tuscan S100 bus computer kit, anyone? and of course that classic of "Bean counteritus gone mad", the wonderful Feeltech FY6600 'modify to your heart's content' project) means I rarely apply the adage "If it ain't broke, don't fix it!" unless it's so complex that I wouldn't know where to start looking for things in need of improvement such as that LPRO 101 where there's some risk of making things worse for no effective gain.

 I don't need to open it up since I've been able to see more than enough photographs of its innards published on the interweb and in all the various downloaded maintenance and repair guides and manuals I've collected. I'm seeing no hint of any issues in its operation to warrant deeper investigation so I'll wait until the time, if ever, to deal with any problems that may arise.

 Right now, the only minor concern is over the lamp photocell output voltage being a little lower than I'd have preferred. It was measuring 4.975v when I first got it some 12 months ago and is now at 4.912v with most of the drop seemingly having taken place as a result of powering it down rather than actual run time. Extrapolating the rate of fall implies it won't reach its 3 volt end point for another decade or two so I'll 'make hay while the sun shines' and ignore the urge to check on certain critical resistors and a decontamination of a quarter of a century's worth of pollution on the glassware inside the physics package for another year or three.

 Incidentally, when I checked on the drift rate of the Rb oscillator some 4 hours after re-aligning the traces for another test run, it had drifted by some 55ns and then a further 55 ns or so another four hours later.

 Checking the heatsink temperature with my IR thermometer showed it had warmed up by a good half degree C. I guess I must have disturbed my breadboard lash up sufficiently to introduce the half degree error when I'd disconnected the long redundant scope probe I'd been using to monitor the PWM fan motor drive signal up until a couple of weeks ago.

 Solderless breadboards have their charms but stability of their connection points ain't one of them, especially when mV levels of voltage stability are a critical requirement of the circuit lash up as it was in this case. Fortuitously, after fiddling with the breadboard at 1pm, that drift has, rather gratifyingly, been slowed right down to 1ns per hour over the past 6 hours.

 Soldering the components onto a PCB would fix that issue but since I now want to use a nano 3 for the task, I'll skip that step and commit to getting to grips with the Arduino IDE and write (or modify) a fan controller sketch of my own. I've been putting this step off for long enough. I've seen ample enough 'proof of concept' with my breadboard testbed now to take that next step.

 It's not as if programming is an alien art so much as it being over 30 years since I last coded anything in Z80 assembler and even longer since I last used TCL BASIC (that Transam Tuscan kit I'd alluded to earlier) and before that, Sinclair BASIC on the original ZX80.

 My main problem is that I've finely honed my otherwise useful skills in procrastination to such an extreme as to be counterproductive in making further progress in a hobby that now routinely makes use of microcontrollers as a cheaper alternative to the more traditional analogue solutions of yesterdayyear. Even my writing style is afflicted by this.

[iMo]

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

[AndrewBCN]

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.