@MIS42N
I meant to explain the scope traces - sorry! I'm triggering from CH1 (yellow trace) which is monitoring the GPSDO's 10MHz output. CH2 (magenta trace) is monitoring the output from my very much modified cheap Chinese "toy" FY6600-60M AWG into which I'd fitted a 10MHz OCXO (plus a 5 times clock multiplier chip) to replace the original and rather crap 50MHz smd XO Feeltech had cheaped out on as a clock reference source and, more importantly, had added an external reference input socket to let me injection lock the OCXO to an external atomic clock derived 10MHz frequency reference such as a GPSDO or Rubidium atomic clock.
In this case, I have it locked to my LPRO-101 Rubidium oscillator so that I can dial in calibration adjustments in increments as small as 1uHz (in practice, I'm using 10uHz steps). Basically, the AWG is acting as a proxy for the RFS, allowing me to precisely trim the Rubidium locked frequency without my having to struggle with the RFS's own frequency trimpot, putting unnecessary wear and tear on it just to cater for room temperature variations that will stop being a problem once I've finally completed my RFS project.
In short, CH2 is the Rubidium reference. When their frequencies match exactly, both traces will remain stationary. CH1 being used as the trigger signal will remain fixed whilst any frequency/phase shifts of the Rubidium frequency on CH2 relative to the triggering signal on CH1 will produce a drift or change in phase offset. The use of the word "relative" in the above statement is a vital part of the description since you will observe the same effect (only with an opposite drift direction to the former case) if the triggering signal on CH1 is varying whilst that on CH2 remains rock steady. BTW, in case you missed it, the bottom right hand corner shows the date and time, effectively time stamping each of these screen shots.
What you choose to trigger from, from out of two or more signals being displayed on a CRO, or in this case a DSO, is entirely arbitrary but the general rule is to trigger from the most stable and accurate frequency source (normally a frequency source locked to a lab standard reference such as a GPSDO or RFS).
In this case, there is some conflict over which is the best choice, On the one hand, the GPSDO is frequency stable in the long term but it suffers subsonic phase modulation from the imperfectly corrected electron density of the ionosphere (ionosphere correction data is a standard part of the GNSS message packet payload) whilst on the other hand, the RFS is free of such subsonic phase modulations but suffers a temperature induced frequency drift that is yet to be fully mitigated.
Once I have gotten my LPRO-101 fully stabilised against temperature (and ultimately pressure) variations, I would make this the reference in order to observe the GPSDO's 5ns or so pk-pk phase shifts in rather more detail than I can do right now. Since I'm currently working on improving the RFS's long term frequency stability against variations of ambient temperature, I'm using the GPSDO as the reference, "Warts and all".
By using infinite persistence", I can record not only the subsonic phase shifts which are reflected onto the RFS (magenta trace) but also the hours long drift in frequency of my less than perfect RFS (at least until it slips one whole cycle out of phase with the GPSDO - then I have to clear the traces and start over). I'm aiming to extend this time from some ten hours or so out to two or more days worth before it completes a full cycle of drift.
From my results so far, this does look rather doable, given enough time and effort to get everything just right.
In view of the many sources of error (residual errors after applying the ionospheric correction data being a major one in a single frequency setup) such as tropospheric propagation delay errors, orbital position errors, on board clock timing errors and a few other error sources besides that I can't recall right now, even with a dual frequency setup, it's a bloody minor miracle that it's even possible to achieve metre scale accuracy let alone the centimetre scale accuracy you mentioned. I know it's all based on sound scientific principles but to me, it's verging on it all being an exquisite magic trick.
You mentioned the use of a (damn bloody expensive) dual frequency timing module (not forgetting the additional expense of a dual frequency timing antenna) to eliminate this source of error. However, that still leaves all the other smaller error sources to be dealt with.
The only problem with the hardware PLL is that it lacks the sophistication to do anything more than integrate anywhere from the last 100 to 1000 (and in some cases a little more) second's worth of PWM output to control the EFC voltage whereas the microcontroller can run sophisticated PID algorithms with Kalman filtering capable of dealing with the much longer time scales that can benefit a Rubidium based LO along with logging data to monitor performance and permit post mortem analysis of any rare and unusual events that may pop up. This leaves the microcontroller faced with a game of "Whack-A-Mole" dealing with the issue of temperature effects on the LDO(s) and DAC's voltage references which makes assembling and refining the required algorithms a rather interesting exercise to say the least.
Your last question, in regard of my comment about the correcting adjustment time scales being better suited to a Rb oscillator were based on my perception that you were allowing for a rate of as long as just one adjustment every two hours which few to no OCXOs can sustain the required one cycle drift accuracy for, other than by pure chance. A high quality DOCXO just might manage the required stability with reasonable repeatability but for the two hour and longer time scales I thought you'd had in mind, only a Rb oscillator could reliably meet this requirement, assuming its base plate temperature is kept closely tied to a fixed temperature against ambient temperature variations.
If you also apply barometric compensation as well as maintain tight temperature control of a Rubidium oscillator's base plate, the microcontroller will land up effectively compensating largely for the daily ageing drift rate of <1.67E-12 (one thirtieth of the <5E-11 per month figure quoted by the manufacturer of the LPRO-101).
I'm aiming to create an RFS free from temperature and barometric induced frequency errors, leaving only the ageing drift to contend with. When I've completed those parts of my RFS project, the next obvious step to take will be the addition of a suitable microcontroller based GPSDO to compensate even that small error component. I could land up using a variant of the Lars design or even yours if you manage to reach a successful conclusion.
The barometric compensation part of this project will require the use of a Nano3 anyway just to interface the BMP280 pressure/temperature sensor module and, once I've added that to the mix, I'll be just one small misstep away from falling down the rabbit hole that is microcontroller based GPSDO territory.
Regards, John
PS I started writing this reply several days back but it got hijacked by "Real Life" events in the form of a fuse blowing fault with our 40 year old central heating electrics (a shorted out 47nF 250vac filter cap in the boiler - a free standing cast iron lump heat exchanger model destined to outlive by an order of magnitude longer than all of these new fangled aluminium based condensing types that need replacing every seven years on the average, eating up those modest savings on the gas bill and then some!
).
The original fault was further compounded by a dicky motor in the 3 port mid position diverter valve assembly going into complete failure requiring a second visit by our tame British Gas engineer a couple of the very coldest days of the year later before we could once more enjoy the benefit of a fully functioning central heating system.
Home
Help
Search
Login
Register
Topic: Lars DIY GPSDO with Arduino and 1ns resolution TIC (Read 275761 times)