After I took the insulation away from the OCXO's and ran the measurements again for several days, I have decided to put them back on.
Even with the DAC temperature compensation activated, the dependency of my GPSDO systems are too sensitive to the room temperature changes. So much so that I'm loosing lock constantly, while I ran for months without problems when they were boxed in. I only took the insulation away because it seemed that the OCXO oven temperature regulation was misbehaving when the room temperatures were in the order of 30 degrees C, during the current heatwave. My take on that is that maybe the delta temperatures between the ambient and the desired oven temperatures where becoming too small, and the oven jumped to a higher temperature setting.
I think I can live with that effect during a heat wave, rather then having them so sensitive to the room temperatures.
The alternative could be to put my metal enclosed GPSDO system wrapped in insulation inside another plastic enclosure to shield it better from "sudden" room temperature changes.
Has anybody collected experience using that approach?
Whilst that would filter out the effect of sudden changes in ambient temperature, it does have the downside of elevating the operating temperatures of all the other components, notably that of any electrolytic capacitors which are best kept as cool as possible to maximise their limited service lifetime ratings. Solid state devices will generally be more tolerant of elevated temperatures unless they already run hot to begin with at more normal ambient temperatures.
Incidentally, the best OCXOs using true SC cut xtals have their oven temperature set point at 92 deg C, according to this article I found when trying to refresh my memory of the "Facts"
https://4timing.com/techcrystal.htm Istr seeing temperature figures of 75 to 85 deg being mentioned for OCXO oven set point temperatures. That's significantly higher than I'd remembered but it does explain the upper ambient temperature limits of 80 deg I'd seen quoted for some OCXOs.
That higher temperature set point is all to the good since this provides a healthy leeway on just how much thermal insulation you can get away with for any given expected maximum interior case temperature without losing control of the oven set point temperature. With typically less than 100mW for the LDO, the oven controller and the oscillator itself, I guess you can probably take the OCXO's case temperature to within 5 or 10 deg of the oven's set point before compromising its stability.
IOW, your hypothesis over the OCXO switching to a higher set point temperature is somewhat in error, not the least because, should such an algorithm even exist, it seems rather unlikely with this Lars based design that the temperature would have increased to the point where such an action would ever be called upon. The point of the oven is simply to maintain the xtal oscillator at a precise temperature over a very wide range of external temperatures and nothing more. If the external temperature exceeds the manufacturer's limits, there's no fancy algorithm that can rescue the situation.
I'm surmising that since the device controlling the heater current also happens to be the heating element itself (a small tabbed plastic power transistor or two), control could simply take the form of an analogue negative feedback proportional controller (no need for fancy PWM to control a separate resistive heating element to avoid the switching device contributing any of its losses into the mix as well as any spurious switching transient noise from a microcontroller running a PID control algorithm (True SC cut somewhat eases the oven set point temperature precision requirements). However, that article didn't go into such detail with regard to oven controllers - that's just an 'educated' guess on my part and I'm probably way off the mark, being the long suffering serial victim of Sod's Law that I am
.
If you've managed to exclude any highly stressed electrolytics from the design, you could try adding a heating element to keep the interior at a moderately high set temperature, say another five to ten degrees higher than you'd expect to see under maximum temperature heatwave conditions otherwise your best bet would be simply to house the OXCO within its own little thermo regulated housing (assuming it isn't a double ovened OCXO to begin with).
Incidentally, you're not the only one experiencing peculiar VFC variations which, in my case, seem to be an OCXO issue quite possibly related to its oven controller or the 5 to 12v boost converter I'm using to power it. My MK II GPSDO (a modernised version of the James Miller design using a u-blox M8T) has been showing several millivolts variations over and above those expected from ionospheric errors over the past week or so since it was last powered up.
It's well at odds with the experience I'd had with the MK I's "Five Volt" 13MHz OCXO retrace behaviour where, for example, it would lock in at 3.293v and gently drop to 3.289 over the next two or three days before increasing back to the 3.293v mark to resume its 2mV or so per week upward ageing trend.
The MK II did a similar retrace over the first day or two (2.2815v dropping to 2.2791v) before increasing right up to a peak of 2.2860v a few days later only to drop down to around the 2.2835 volt mark where it's been hovering up and down by a millivolt or two ever since, way more than can be accounted for by uncorrected ionospheric errors alone.
It's a real puzzle which warrants further investigation with a Rubidium frequency standard which, according to the rather pompously named "Global Shipping Programme"'s latest email last Wednesday " has cleared customs and is now out for delivery with the courier" (at their Erlanger shipping centre in Kentucky???
).
Presumably, according to my all knowing brother in law, it's now awaiting cargo space on the next available commercial airline flight which, thanks to the Covid 19 travel restrictions, are now in rather short supply.
In the meantime whilst 'm awaiting delivery of that LPRO-101, I might as well carry on monitoring the EFC voltage before opening the MK II up to monitor the OCXO's 12v supply rail (I can already monitor the 5.310v Vcc rail through the sma socket I wired up to let me run FFT spectrum traces of its noise and ripple content via a 4u7 ceramic DC block bypassed with a 1KR to let me measure the voltage with a DMM without any need to open up the enclosure). There seems little point in disturbing it until I've got my Rubidium frequency standard all set up and ready to go.
If you do decide to run that experiment, do take care to avoid thermally overstressing any expensive components. It may fail but even a failed experiment leaves you a little wiser and hopefully not too out of pocket if you took enough care not to overstress anything expensive.
Unless you have a bad one, I rather doubt the OCXO is that sensitive to external temperature shifts as to cause the microcontroller to 'lose it big time'. It's either a flaw in the control algorithm or else a component that has an inordinately high tempco which is not being properly accounted for.
Past temperature related problems with this Lars design all seem to have arisen during initial testing outside of any enclosure where draughts and/or solar insolation have created fast temperature transients which more or less disappear once the project has been installed into its enclosure or simply shielded from those influences. In your case, boxing it up hasn't cured it of its seemingly inordinate sensitivity to external changes of temperature. The problem might simply be a wiring error or else something you've overlooked.
You might need to give it a few more coats of "Good looking at" to figure out the true cause of this temperature induced instability you're experiencing. Otoh, taking a few days break can often work wonders by allowing you to take a fresh look at the problem.
JBG
Home
Help
Search
Login
Register
