J. Kissel As per our studies on Monday, Keita advised that we engage at least some level of analog low-pass on the QUADs' UIM coil drivers (see LHO aLOG 53376, and subsequent comments.) After we lost lock from an obscene amount of wind, I've now switched the ETMs to be in state 2, with *one* low pass on. This is the state I studied in LHO aLOG 53486. For ETMY, it was as easy as requesting state 2 and accepting it in the SDF system. However, for ETMX, I found that the ALS_DIFF guardian was requesting state 1 after every lock loss. So, I've changed the hard-coded request (which lived in the DOWN state), to be to request state 2. And also accepted this in the SDF. It looks like someone has already requested that the ITMs are in state 4 (with all three z:p = 10:1 filters ON), and accepted as such in SDF. These have been ON throughout the last ~24 hour lock stretch that started at the end of maintenance yesterday. State 4 should be fine as far as actuator saturations because we never send any drive request to the UIM stage of the ITMs. As such, turning on ALL low passes will only filter the DAC noise which is what we want.
I have reverted ETMX's L1 back to state 1. We suspect that this (it having been set to 2) is the reason we've been losing lock in the carm offset reduction sequence lately. Keita pointed out that ETMY needed to be in state 2, since it gets a lot of low frequency actuation but no deliberate high frequency drive. However since ETMX gets length locking signal at a broad range of frequencies, it doesn't have the same quantization noise problems. So, ETMY is left in the lower noise (has an analog lowpass) state 2, but ETMX is back in the higher range (no analog lowpass) state 1. This has been changed in the ALS_DIFF guardian, and Niko is keeping an eye on the channel to make sure it's not written back to 2 somewhere else.
This has been accepted in SDF, so operators should not see an SDF diff when we get to NomLowNoise.
For the brief, 6-day, time period that the UIM LP1 filter was on between 2019-11-27 and 2019-12-03 (naturally, in between the regular calibration measurements that would have helped us quantify it more easily), the poor compensation of this driver's response manifests in systematic error in the DARM calibration. Making a *very* long story short, (a) The systematic error is very small, (of course frequency dependent, but at most) 0.15% and and 0.09 deg, and (b) Performing this study reminded us that the original data upon which the compensation was based (see LHO aLOG 46927) is quite flawed, and this chassis should be remeasured and the compensation updated. Attached is a prediction of what the calibration (response function) systematic error from this configuration change was over those fateful 6 days. For details on how this estimate was created, see PART I of G2000527. The script used to re-fit the data and make all corresponding plots for G2000527 lives here: /ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Scripts/ fit_ETMX_UIM_driver_20190203_IIRrational_20200401.py