I believe you may be overthinking this 'problem' (mainly on account you seem to be monitoring irrelevant data such as the OCXO's case (?) temperature - it's not entirely clear what's being monitored here - readings far too low to be actual oven temperatures and the "ambient" temperature (is this actual room temperature or that of the air within the enclosure?).
===========================================================================================
[EDIT 2020-08-07]
My bad!
That data is
only irrelevant in the case of a James Miller styled GPSDO design such as I've used in my MKs I and II builds. I apologise for belittling what is actually a vital sensor component in a micro-controller based design. Monitoring the OCXO's case temperature provides a 'catch all' temperature monitoring point to compensate for all sources of temperature variation.
[END_EDIT]
===========================================================================================
The oven control (going by the way my own CQE OCXOs respond to even the briefest of interruptions to their 12v supply) is done using PWM of a constant current supply to the heater (actually a power transistor, not a Ni-Chrome wire heating element) controlled by a simple minded microcontroller algorithm maintaining a thermistor at a fixed resistance value that corresponds to a precise target temperature (to better than +/- 0.5 deg C), usually around the 65 to 85 deg C mark.
I say "simple minded microcontroller algorithm" on account of the way it seems to assume every 'reboot event' can only mean it must be starting from stone cold so turns the heater up to "eleven" whilst it runs through the rest of its reboot initialisation sequence before doing the digital equivalent of exclaiming "Oh, shit! I've overcooked the XO!" and shutting off the heater current which then results in the inevitable under/overshoot wobble you'd normally only expect to witness during an actual cold startup event.
Of course, it may only be my CQE OCXOs that use such a daft reboot algorithm that tests the depth of the water with both feet and plunges straight into its "High speed warmup routine" before testing whether such an action is actually called for. Again
What I'm suggesting is, if possible, log the OCXO's supply rail voltage (and any other supply rails for good measure) to see whether there are any glitch events taking place to trigger these temperature anomalies (which rather look to my mind, more like software/hardware glitches than actual temperature events).
Single ovened OCXOs are influenced by changes of temperature to their immediate surroundings when chasing down parts per trillion stability levels. Double ovened OCXOs are influenced to a lesser extent but still not entirely immune to this effect which is why a modest amount of insulation around a single ovened OCXO can help by reducing internal thermal gradients between the XO, the heater transistor and the sensing thermistor despite the manufacturer's best efforts to keep all three tightly coupled to each other to minimise the effect of these temperature gradients.
Exactly how much insulation can be considered "modest" rather depends on the expected range of operating temperatures within the enclosure. Given enough insulation, even the modest 145mW dissipation from the XO and its LDO (CQE example) may be enough to raise the temperature above the set point in a particularly warm running enclosure on a hot summer's day outside of an air conditioned laboratory environment (a more likely scenario for a typical DIY GPSDO).
To my mind, the only sane way to deal with such temperature variations is to use a double ovened OCXO since trying to compensate for them requires the response to match the actual thermodynamics involved else you risk making the situation worse.
I've been following this thread with some interest since I may find myself having to use a microcontrolled solution to improve on my current hardware PLL controlled GPSDO project where the only major issue I have is due to the unpredictable nature of the ionosphere's effect on the propagation delay of the satellite signals which manifests itself as a variation of 30 to 40ns in the case of the M8N based MK I unit and around 10ns for the M8T based MK II unit I'm currently building. Sadly, even the timing receivers when configured to a fixed location aren't immune to these imperfectly corrected for perturbations in the electron density of the ionosphere
I'm now only awaiting the imminent delivery of panel mount 3.5mm stereo jack sockets to finalise my MK II build. I'm using one to provide a connection to the buffered EFC voltage and a stable 2v dc offset to let me monitor the voltage difference between them on the 1000mV scale of my cheap Mestek DM91A 9999 counts DMM in leu of spending over a hundred quid on a cheap 4 1/2 digit bench meter. I can now monitor variations in EFC voltage in 100uV increments with this cost effective solution - an order of magnitude improvement over using the DM91A just on its own.
Obviously, with no microcontroller nor DAC, I have no simple automated way to log data to generate fancy MDEV or ADEV plots, just observations from 'scope traces comparing both GPSDOs against each other and my stand in for a Rubidium reference, the OCXO in my FY6600, trimmed to within 5ppt by exploiting the 2G tipover effect to fine tune it against diurnal temperature variations and the almost imperceptible daily ageing effect.
It's not an ideal solution but it comes close enough to reveal the slow wobbles of phase shifting for minutes to tens of minutes variations in propagation delay from the changing ionospheric conditions. Unfortunately, the once superb stability of this free running OCXO seems to have gone all to pot this past week or so and it looks like I need to revamp the calibration trimmer circuitry (better 22 turn trim pot and more padding to limit the frequency trim range and quite possibly the use of a 5v CMOS RRO opamp to reduce slider contact resistance volt drop effects).
OTOH, I might just build my own double ovened OCXO using one of my ample stock of 10MHz CQE OCXOs to create a stable enough independent reference to compare the behaviour of my MKs I and II GPSDOs against. I'd like to take the basic hardware PLL based GPSDO to its limit before I start experimenting with microcontroller based designs since it will provide a useful benchmark to test such a new design against.
In the meantime, I wish you all the best with your own Lars based GPSDO design. I think you just need to step back and reconsider other possible causes for your current anomalous results. I know just how easy it is to get stuck down a dead end road where nothing seems to make sense any more.
JBG
Home
Help
Search
Login
Register
