From the configuration run (see PSL:2257), I estimated some new PID coefficients. I left PID on for the long weekend with the new coefficient with the initial point about 5 MHz off from lock set point. Apparently, the system never converged (see the orange trace in attached screenshot of StripTool). It instead kept oscillating.
At this point, it seems that maybe the PID control won't work good enough. We need to keep beatnote frequency within 10kHz of setpoint to reach desired resolution range and avoid jumps in Marconi. We either need a new way of temperature control, or if PID works nearby setpoint with no hard changes, we need to reach there with almost zero slope.
This week I started working on a new method to drive the frequency to setpoint with near to zero first derivative. The purpose of this method is to reach close enough to setpoint in a calm manner so that PID can function nicely. If it works out better, it can be used as primary control near setpoint as well.
There would be three codes working together to achieve temperature driving (and/or control).
This plan is in an infant stage. We might need to change a lot of things and models depending on what data is acquired. So, for now, to reduce development time (with a possible chance of failure), I've only incorporated the DataMiner code which is on Git/cit_ctnlab/ctn_scripts/ now. I've also written a DataMinerHelper.py which spans the actuation space slowly while keeping frequency in range so that good knowledge data can be mined. These two codes are near final release.
Depending on what the knowledge data looks like, we will decide if we should go further with this plan. Until then, I'll work on noiseBudget code again.
I have reconfigured the ufc-6000 to have a sampling rate of 0.1 Hz which is minimum possible from design. I have changed ufc2.py to make sure it is set to this sampling rate everytime we read precavity beatnote frequency data.