I've made yet more progress with my rubidium frequency reference project over the past seven months. I really need to fabricate a barometric test chamber to fine tune the barometric compensation algorithm. One that can cover a modest +/- 25mBar range and maintain it to within 0.5mBar during settled weather conditions over time periods of a couple of hours or so. Any ideas on how to cheaply fabricate one?
Anyway, I thought it might be of some interest to demonstrate the improvements reflected by the need to now display temperature readings to three decimal places (one milli Kelvin resolution). The attached images represent a short 25 seconds long sequence.
You'll notice one other change, namely the renaming of the "Ambient temperature" readout label to "Plenum temperature". It's from the BMP280 sensor as before - I've simply moved its location from the mouth of the intake vent to in front of the fan intake within the induction plenum chamber. This now controls a set of servo driven flap diverter valves to transition between direct exhaust and total internal recirculation over a 1 degree range centered currently on 31 deg C. I may raise this another degree since once the flow diverter valves have "battened down the hatches" so to speak at an ambient around the 17 degrees mark, this gives me a more stable fan intake temperature which then falls at a steady 100mK per 1K drop in ambient temperature below that transition point.
Trying to maintain temperature control with an 80mm CPU cooling fan being fed directly with raw ambient air below 18 deg is just not possible without resorting to shutting it off and then kick starting when it needs to provide a minimal level of cooling without introducing the Spectre of under and overshooting the target base plate temperature. This "Air Conditioning" of the fan intake plenum worked wonders for temperature control of the base plate over an ambient ranging from 10 to 28 degrees.
I could go on at length about this project but I think it best to save it for a separate thread on the "completed' project at a later date. In the meantime, you can admire
my efforts thus far as demonstrated in the attached pictures.
P.S I've added 4 screenshots of the Arduino serial plots of base plate temperature (a sequence of 6.4 second windows). The vertical scale is milli Kelvins referenced to a 36.000 degrees base line. There are 500 points per window. The control loop is now running at just over 78Hz. The "spikes" have been introduced every 498 th plot to suppress the counterproductive re-scaling that Arduino had cursed their serial plotter feature with (ver 1.8.19 - the ver 2.x.xx plotter is even more useless!).
Without these "spikes" the vertical scaling would be dancing an epileptic jig, defeating the whole point of graphing data in the first place
One good side effect of adding these pulse pairs (0 and 120) being that it allows a simple way to measure the control loop speed by timing each pass through a chosen X axis reference point with a stopwatch (6.4s per pass for a quick 'n dirty check or 64s for ten passes to obtain a more accurate measure).
PPS added three DSO screenshots to illustrate the whole point of this rather protracted project. The first is from midnight the 2nd at 08:09 and the final taken a few minutes ago at 18:00. The DSO (an SDS1202X-E btw) was set to infinite persistence as it has been for the past few years I've had it running 24/7 to monitor the phase drift between the MK II gpsdo and the rubidium reference. CH1 (yellow trace) is triggered by the gpsdo with the ruby on CH2.
The majority of the persistence is being painted by the 20ns diurnal wander of an M8T based G3RUH type gpsdo fed from a multi frequency GNSS/RTK antenna mounted with a clear all round view of the sky. This diurnal phase wander rather muddies the waters when it comes to syntonising the ruby to the atomic clocks world time reference/ frequency standard making it rather difficult to test the efficacy of my attempts to stabilise it against variations of both ambient temperature and barometric pressure. However, I do hope to reduce this effect by completing a MK III using a ZED9T gnss receiver module I'd purchased just over a year ago.
Damn EEVBLOG's 10 file attachment limit ! I've had to drop the first photo of the ruby's oled display.