Can see that LVEA temperature sensor 5A changed 1.7degF and some of the close optics show alignment drifts with this: PR2, MC2, ITMY. Plot attached. This could be the cause of the last two locklosses today.

Reached NLN at 21:53UTC and while waiting for camera servos to converge we had a lockloss at 21:58UTC 73800. No issues with SQZ FC locking.

After 4 locklosses at LOCKING_ALS (COMM and DIFF beatnotes at -18 and -15), at 18:05UTC I started an initial alinement. IA went smoothly and finished at 18:30UTC. Observing at 19:46UTC.  

NLN at 19:14UTC, I let SQZ_MANAGER try for 8 minutes but it kept failing at TRANSISION_IR_LOCKING, as yesterday 73770. Repeated yesterdays "Issues with SQZ FC Guardian" wiki steps and touched FC2 Pitch. Then had trouble with SQZ_FC  at ENGAGE_FC_ASC step. When Vicky stepped through the guardian this wasn't an issue and it locked fine, we then had the guardian do it and it locked fine. I touched SQZ OPO temperature and SQZ angle, high frequency SQZ looks bad but we are unsure why. 

FM2 DARM2 boost that was tuned on yesterday 73783, 73776 did not come on so I sdf reverted to turn it on. I'll search the alog to find where this needs to be added the ISC_LOCK. Tagging ISC. sdf

This bad high frequency noise was present in the start of most (but not all) of our locks since Tuesday, zoomed out plot. ZM6 alignment shifted Tuesday and is close to saturating. It is also moving a lot at the start of each lock, maybe causing this changing high frequency squeezing. We could repeat Naoki's 73171 offloading.

We can also see in the purple SQZ BLRMS (centered at 4.8kHz) jump at ~ 08:12UTC (1h40 into the lock) the DARM plot shows that the high frequency slowly gets better but at ~ 08:12UTC the noisy region at 4.8kHz and 3kHz suddenly disappears and is replaced by noise at 4kHz (compare purple/yellow traces to red). What would cause this?

Looking at omicron glitches and DARM (red better range than brown), the range drop appears to be in the 20-300Hz region and could be due to squeezing (attached SQZ BLRMS plot: orange trace 150Hz, yellow trace ~350Hz).

This is the first time the CO2X laser has unlocked since the new chiller was installed 73704. On CO2 unlock, the TCS_ITMX_CO2 guardian couldn't find a lock point so stepped the chiller temperature which starts a 5 minute timer before scanning PZT again. Total time down was ~7m30s. This issue has associated FRS#28943. If this happens again we could add a longer timer to IFO_NOTIFY (currently alerts after 3 minutes out of observing) if the CO2s are not nominal.

The PZT has been much noisier since the chiller was swapped 4 days ago, see attached pink trace. Is also noisier than CO2Y.

Reaquired NLN at 06:03, waiting for ADS to converge to go into observing

Another larger incoming EQ from the same spot, holding off on starting an IA and holding in down till it passes in a few minutes.

Added this FM2 boost to ISC_LOCK state LOWNOISE_LENGTH_CONTROL, FM2 is now turned on at the same time as DARM2 FM8 is.

This Calibration-affecting change has been recorded in the H1 Record of Real-Time Calibration Pipeline Parameter Changes (DCC T2300297).

DARM low frequency (< 4 Hz) is highly coherent with ETMX M0 and R0 L damping signals. This might just be recoil from the LSC drive, but it might be worth trying to reduce the L damping gain and see if DARM RMS improves

Bicoherence is also showing that the noise between 15 and 30 Hz is modulated according to the main peaks visible in DARM at low frequency.

We might be circling back to the point where we need to reconsider/remeasure our DAC noise. Linking two different (and disagreeing) projections from the last time we thought about this, it has the correct slope. However, Craig's projection and the noisemon measurement did not agree, something we never resolved.

Projection from Craig: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=68489

Measurement from noisemons: https://alog.ligo-wa.caltech.edu/aLOG/uploads/68382_20230403203223_lho_pum_dac_noisebudget.pdf

I updated the noisemon projections for PUM DAC noise, and fixed an error in their calibration for the noise budget. They now agree reasonably well with the estimates Craig made by switching coil driver states. From this we can conclude that PUM DAC noise is not close to being a limiting noise in DARM at present.

To Chris' point above -- we note that the PUMs are using 20-bit DACs, and we are NOT using and "DAC Dither" (see aLOGs motivating why we do *not* use them in LHO:68428, and LHO:65807, namely that [in the little testing that we've done] we've seen no improvement, so we decided they weren't worth the extra complexity and maintenance.)

If at some point there’s a need to test DAC dithers again, please look at either (1) noisemon coherence with the DAC request signal, or (2) noisemon spectra with a bandstop in the DAC request to reveal the DAC noise floor.  Without one of those measures, the noisemons are usually not informative, because the DAC noise is buried under the DAC request.

Attached is a revised PUM DAC noisemon projection, with one more calibration fix that increases the noise estimate below 20 Hz (although it remains below DARM).