GPSDO phase between PPS and clock

[MIS42N]

Can there really be as much as 30 to 50ns diurnal variation? If this is true, it would neatly explain why I've been banging my head against a brick wall over the past couple of months in my attempts to eliminate a diurnal chill factor effect on my temperature stabilised (and barometrically compensated) rubidium frequency standard (RFS) project.

It is unlikely any single frequency (i.e. L1 band) GPS receiver will do better than this. The solution is to go to a dual frequency GPS receiver like the u-blox ZED-F9T. To quote from the literature "Stress testing absolute timing over 24 hours achieved a tolerance better than +/-10ns with a standard deviation under 3ns.".

Both rubidium and cesium beams are disciplining oscillators, to get better than 10ns deviation in a day is dealing with stability of better than 1 part in 10^-16 which isn't going to happen in your average back yard. The method of detecting the fine transitions at GHz frequencies is not 100%, it involves sweeping a signal from a slightly lower to a slightly higher frequency and looking for a dip or peak. The sharpness of that is affected by many factors one being the Zeeman effect.

So one could chuck the cesium or rubidium and just go for a really good oscillator. I have seen prices in the thousands of dollars. And let the GPS discipline that with a loop time of hours.

[Johnny B Good]

@MIS42N

 Many thanks for confirming my suspicions over the diurnal instability of the GPS system (L1 bound receiver limitations at any rate) and your observations on the stability of commodity class rubidium oscillators and those 'caesium in a box' lab frequency standards (both of which incidentally, are mere 'secondary atomic standards' outside of a nation's time and measurements' lab such as NIST in the USA).

 Incidentally, I'd just received a Sparkfun ZED-9FT  module yesterday morning and did observe that +/- 10ns jitter on its 1PPS (an accumulation of 2ns or so steps over 5 to ten second intervals) compared to the ruby (and my home made GPSDO for that matter!). I couldn't really detect any longer term drift between the ruby and the ZED-9FT over a two hour or so period (hence my throwing my gpsdo into the mix for good measure).

 However, this was only an initial check, using the multi band GNSS/RTK antenna I'd bought at the end of last year with just such a gps receiver upgrade in mind, using its default settings since I couldn't run the later versions of U-centre in my winXP VM needed to access its configuration interface and recognise it as a USB device).

 Unfortunately, the win7 pro 64 VM, after I'd cleared the login password that I hadn't been able to recall despite my password hint, kept complaining about missing components (even after installing the required redistributables) when trying to start version 22 of U-centre after each re-installation attempt, so I was left with no means to properly configure it'

=======================================================================================================
[EDIT 2024-11-20]

The show stopper in this case was simply due to the lack of support for USB-C  in winXP. I got around this issue by using the host serial interface on the I2C pins (unhelpfully labelled as CIPO for the MOSI/TXO and COPI for the MISO/RXI) to connect an FTDI232 serial to USB adapter which allowed U-Centre 8.16 running in the winXP VM to connect to the ZED9 (only after buying a refurbished Thinkpad running win10, of course!).

 I now have it assembled onto 100mm by 100mm single sided copper clad FR4 board that neatly fits into another 100 x 100 x 50 mm extruded aluminium case (as per its MK II M8T predecessor). At the moment, just the bare essentials, I still have to add the LiPo  and its support circuitry and the reverse polarity and over-voltage protection components before I can finally box it up.

 "Bare essentials" in this context does include the the three DC-DC converters which make up the 'power train' to facilitate internal backup power from input voltages ranging from a low of 4.8 to a high of 24 volts at a fully loaded (45mA feeding the GNSS/RTK antenna) warmed up input power of circa 1.9W (peak startup from stone cold power demand of 7 or 8 watts which allows any 2.1A rated USB power source, wallwarts, powerbanks and any other 10W rated PSU sources up to a maximum of 24v to be used)

[/EDIT]
=======================================================================================================

 The core of this and several other problems lies with the fact that my version (17.3) of Linux Mint no longer supports the many and varied dependencies required to upgrade from VBox version 5 to fix the failed EHCI USB options in my windows VMs. Not an issue in the winXP VM when it comes to running the latest (but ancient v. 8.16) compatible version of u-centre  to interact with the M8T modules but a major show stopper as far as re-configuring that nice shiny new ZED-9FT that's now in my possession. :'(

I've been putting this long overdue OS upgrade off for the past two or three years and now see that I have no choice but to face the upheaval involved in such an exercise before I can do anything else with that Sparkfun module.

 Forward planning with the original Linux Mint installations regarding the use of separate partitions for boot, root, home and swapfile, helps minimise the potentially disruptive effects of an OS upgrade exercise but even so, there'll be enough disruption to contend with assuming I do manage to avoid accidentally deleting the existing partition spaces.

 I suppose I should do a complete backup of the boot and system drive (a 240GB SSD) beforehand just to make sure any dramas remain just that (a recoverable drama rather than an irretrievable disaster). I've already created the live USB boot drive to test and install LM 22, now I just have to make sure to create a recovery image of the SSD before taking the plunge so it looks like it might be another day or two (if all goes well) before I can start properly checking out that Sparkfun module (possibly a week or longer if it doesn't go well).


=======================================================================================================
[EDIT 2024-11-20]

 About 2 or 3 weeks after posting that, I decided to make a massive hardware upgrade before making such a major OS upgrade. The reason being that one, I was due a hardware upgrade anyway and two, I might as well combine both tasks to maximise the benefit from the hassle of just doing an OS upgrade.

 I'd reviewed my OS options and had settled on Fedora 37 little realising that the kernel versions being used by the major distros at that time lacked any support for the 2.5 GBe lan ports typical of my chosen MoBo (and many others) at that time which ultimately resulted in a 5 months long protracted upgrade process only resolved by disabling the on-board lan port and fitting a 1GBe PCIe adapter.

 Unfortunately, I now find myself faced with the same OS upgrading issue by failing to notice Fedora's yearly OS update cycle and the need to use the associated upgrade feature that's only good for the next annual upgrade with no means of working around this time limit by upgrading to the next, now out of date version as a means of stepping through the previous versions you'd failed to upgrade to
[/EDIT]
=======================================================================================================

 The only good news to offer is that I seem to have finally optimised the chill factor compensation algorithm I've been trying to fine tune to stabilise the ruby against diurnal temperature variations. The night before, I left my hobby room windows open to lower the ambient temperature to test my attempts to fine tune the base plate temperature control algorithm only to discover that it was reaching the fan cut off set temperature (36 deg C) and undershooting some 200mK or so at just under 15 deg ambient.

 I took advantage of this low temperature opportunity to refine the base plate temperature control and chill factor algorithms whilst awaiting the expected delivery of the SparkFun module. The rebound back to the 36.10 deg +/-20mK region occurred when the room had warmed up to a less chilly 20 to 21 deg but crept up another 20 to 30mK at around 25 to 26 deg room ambient. A small sacrifice of control at the top end for the considerable improvement at the bottom end of the ambient range.

=======================================================================================================
[EDIT 2024-11-20]

All the above chill factor compensation nonsense has long since been discarded. In its place I have modified the innards of the enclosure by adding a couple of exhaust to intake plenum return galleries (40mm PVC pipes) with servo operated flap diverter valves to stabilise the fan intake temperature between a low of 23.5 21.5deg at a 1 -2 deg ambient up to a high of 32 deg at the upper ambient temperature limit of 32 deg.

 I have changed the set temperature to 36.050 deg and it remains stable to within +/- 1mK in the 1 to 12 deg ambient range, degrading to +/- 5mk in the 23 to 28 deg range for about 25% of the time, otherwise maintaining a steady +/- 1mK for the remaing 75% or so. I'm inclined to assume an effect due to the physics package ovens going in and out of sync with each other to disturb the fine balance of my temperature control algorithm.

 The only puzzling aspect being the major improvement at the low end of the ambient temperature range versus the earlier instability with my earlier temperature control efforts. However, a lot of water has spilled over the damn since then,  suffice to say that I have made many improvements to the temperature control algorithm in the meantime, including elimination of any need to shut the fan off and the associated kick startup code.

 One final thought about this puzzle being that it may simply the result of the diverter valves effectively sealing it off from the influence of  any random external drafts of ambient airflow. Indeed, this was the reason why I'd set the plenum target temperature so close to the upper limit in the first place (31.5 deg for the mid point of the +/- 0.5 deg plenum temperature control range of the diverter valves' end to end extremes which corresponds with an ambient temperature range of 19 to 33 deg). If that's the case, I would expect to see such tight +/- 1mK control maintained right up to around the 19 deg mark.

[/EDIT]
=======================================================================================================

 I ran the same test last night with a considerably improved result. Since you'd mentioned the impossibility of stabilising a rubidium to within 10ns drift per 24 hours, I've attached screenshots to show just how close it's possible to approach such a high level of precision in a home lab setting with a repurposed LPRO-101.
=======================================================================================================
[EDIT 2024-11-20]

 Since I've now had a chance to compare the MK II against the ZED9 based MK III gpsdo to observe the diurnal phase shift due to the ionosphere, it seems my results must have been down to pure dumb luck at that time since the MK II drifted some 33ns over each of the 24 hour test runs compared to the MK III.

 Of course, there still remain the GPS system errors and the effect of moisture in the troposphere to contend with which are a common source of error for both GPSDOs and therefore, effectively nulled out of this comparison, leaving only the effect of the ionosphere visible. It's possible that the total 24 hour phase wander with the MK II could have been as much as 40ns which rather makes my "excellent" test results very suspect .

[/EDIT]
=======================================================================================================

 Image1 was taken at 00:55 this morning followed by images captured at 2am and 3 am before I opened the windows and took to my bed. I got up just after 10:30 to check the room temperature (down to 14.5 deg) before capturing the next two images at 10:39 (second of which was after clearing the persistence and closing the windows). The final two in that sequence were grabbed at 12:42 and 13:47 respectively. Image 4 looks like it might have simply been a GPS excursion rather than the ruby deciding to take a sideways excursion (I hope!).

 I'd left the room to warm up a degree before switching on a 500W fan heater to bring the ambient back up to a less chilly 18.5 deg (it's now at 19.5 deg, some 35 minutes after that final screenshot). The XYL has just turned the central heating on so I'll keep running my test whilst that takes over from the fan heater and the temperature continues climbing over the next few hours, this afternoon and into the evening.

 Now that I've reduced the control cycle time from a whopping 420ms down to a less glacial 110ms, I've got some more optimising of the various kick start delays used in the control algorithm to overcome the reluctance of a cheap two phase bldc fan cooler to restart from a standstill so my work on the algorithm isn't quite yet done but it looks like I'm very close to the limits of that hard pressed nano 3 board I'm using.

=======================================================================================================

[EDIT 2024-11-20]

 In the light of my latest temperature control achievements, the above is now ancient and outdated history (I'm happy to say). It seems I was nowhere near being close to the limits of that "hard pressed" nano 3 and the fan controller's performance limits at that time.

 Only now that I've maxed out the cycle time to just 7ms and a +/- 1mK variation from the set base plate temperature over 1 deg (possibly even as low as -5 deg) to around the 19 deg ambient temperature mark only occasionally rising to a +/- 5mK in the 19 to 28 deg range, can I say with some confidence that I've finally reached the limits of that "hard put upon" Arduino nano3 controller.

 I'm only too well aware that holding the base plate to within a mK of a set point is not sufficient by itself when there exists the unknown quantity of internal temperature gradient variations with changes of ambient temperature due to limitations of the thermal insulation around the remaining five sides of the rubidium oscillator.

 The addition of a controlled exhaust air recirculation system helps mitigate this, but it would work more effectively without the 2cm thick foam polystyrene jacket around the LPRO 101 to allow the fan exhaust to cool those remaining five sides with the freed up space used to increase the insulation layer thickness against the interior walls of the case itself.

 However, this would be a major modification I'd rather put off until I can build another rubidium oscillator using a Symmetricom SA.22C I'd bought some two years ago. The problem is that I'd like to assemble (or buy) a similarly "oversized" project case to build this into, using my hard won knowledge and experience gained over the past three years in developing a precise control of temperature over such devices.

 Incidentally, before you ask, yes, I have incorporated barometric pressure compensation (to the tune of 0.8 E-13 per mBar drop in pressure). Indeed this was the motivation to replace my early analogue temperature control setup with a micro controller based solution since there simply weren't any cost effective analogue output barometric sensors avalable to keep this in a purely anaolgue domain and I knew full well that if I had any hope of reaching a frequency stability better than a humble 1E-12, barometric compensation would be an absolute must have feature.

 By the way, if anyone has any helpful suggestions in regard of sourcing such an enclosure (kit or ready built), I'd like it to match within half an inch or so, the dimensions of my existing enclosure which are 12 inch wide by 10 inch deep by 8 inch tall. It needs to be so big to allow me install an effective layer of insulation to minimise the effect of ambient temperature variations.

[/EDIT]

[MIS42N]

@Johnny B Good
I gave up upgrading the O/S on computers a while back. I buy second hand systems with the 'next' operating system installed. This one was 18 months old, still under factory warranty, less than half retail price with monitor thrown in for free. I have a Linux based server for storing files, shared to any computer I put on the network. It has mirrored disks (Raid 1?) so if a disk fails there's a good copy. There's backup hardware if the processor fails. Runs under Ubuntu 16.4 (upgrading from this would be "if it ain't broke, fix it until it is"). As far as possible software is open source so easy to install software on the 'new' computer.

Re my comment about "the impossibility of stabilising a rubidium to within 10ns drift per 24 hours" I think your attention to detail takes it out of the "average back yard" class. If you can achieve that sort of performance day after day you'll prove me wrong. I worked in a standards laboratory for a while, which included a cesium beam timepiece. We were happy if the room temperature was 20±0.5°C, it didn't seem to affect the beam (which probably had its own heater). But we needed to null out magnetic fields and have a Faraday cage around the room to get best results. In those days there was no GPS so long term of WWV and WWVH was the best we could do as a reference. So we never knew how accurate we were (IIRC our accreditation was -2 parts ± 7 parts in 10^-13 to the national standard, so comparison error was larger than the possible difference).

@everybody - to return to the original question

If the aim of the game is to have a frequency standard, then the phase relationship between the GPS signal and the oscillator is arbitrary. The only important thing is it is fixed. If the average phase error for period A (say - 100 seconds) and the average phase error for the following period B (the next 100 seconds) are the same, then the frequency relationship is constant - i.e. they are same. It is good practice to design a GPSDO to achieve this long term, then the GPSDO can be used as a reference for testing rubidium and cesium standards with a long time comparison. A PLL design will achieve this.

If using a PLL design, taking the phase relationship between 1pps and 10MHz doesn't work out. If the 1pps is more than 50ns early or 50ns late then the result is ambiguous. Which is why most designs divide the 10MHz down to a lower frequency before phase locking.

If the aim is to have a time standard, welcome to a world of pain. The phase relationship becomes important as does propagation delay in the antenna lead, ionospheric conditions, equipment design, etc. If a particular phase offset is required, then it can be established at power up and as long as it is maintained then both frequency and phase are correct. An early design of mine worked off an interrupt caused by the 1pps, and required it to arrive a few µs after a clock interrupt so they didn't interfere. It took a few seconds to drift the oscillator the required amount. I could have modified the startup to time the clock startup off an early 1pps but it was not necessary. Fortunately in the current build the 1pps is timed by hardware and the interrupt can be delayed without impact.

[Johnny B Good]

 I've edited my previous post to  show the progress I've made with my rubidium oscillator during the past two years along with the results of a yet to be fully completed MK III ZED9 FT based gpsdo (just the essentials to afford meaningful test results - solderless breadboard prototyping just doesn't cut it for this type of project).

This is by of a heads up on the newly edited previous post for anyone who still has enough of a passing interest to have clicked the notification button to alert them any to any new postings to this topic thread (I just realised that just editing my post might not trigger such a notification).