J. Kissel

Following the measurement & fitting (LHO:61280), and subsequent modeling of systematic error impact of various levels of compensation accuracy (LHO:61985), I've installed the updated compensation (in the ITM[X/Y]_L2_COILOUTF filter bank) for the analog frequency response change to the H1SUSETMY PUM (or "L2") driver (described in E2100204, installed in Dec 2021). 

As with H1 ETMs (see the most details in ETMX LHO:61927 and the less detailed ETMY LHO:61970), I've:
   - Updated the compensation for the thing that actually changed; the low-pass filter engaged when using State 3 or 4 which now has a higher frequency low-pass region a la E2100204,
   - Updated the Acquire filter zs and ps too (i.e. that response which is in all states, differently for OFF vs. ON), since previous compensation was subpar, so that improves the accuracy of compensation for all states
   - Installed AOSEM response compensation for the first time in FM9, and turned it on
   - Made sure all switchable filters were set to have their input "Always ON" and output switch upon "Zero Crossing" with "0.0" threshold
   - Committed the new filter file to the userapps svn
   - Saved FM9 being ON in the sdf system

The first and last attachments are records of the old vs. new filters in each L2_COILOUTF filter banks for ITMX and ITMY, respectively.

This completes the campaign exquisite compensation for all the test masses. 

Here are the consequences for the IFO:

- All the QUAD's PUM stages need to have each set of coils' DC gain rebalanced.

- After which, we can safely assume that all systematic error in calibration of the DARM loop incurred from any actuation of any QUAD's PUM stage, used in the any state, will be negligible at or below the ~0.1% / 0.2 deg.

- We're now compensating for the AOSEM response. This adds a new, ~850 Hz pole to the PUM actuation strength. This has two consequences:
    :: The phase of the PUM actuation at the violin mode frequencies, ~500 Hz, 1000 Hz, 1500 Hz, will be drastically different. We typically need to retune violin mode damping anyways after a big vent, but we should *definitely* need to do it this time. (and preferably after coil balancing).
    :: This will change the response contribution of the ETMX contribution to the DARM loop. DRIVEALIGN filter cross-overs with the TST stage (see, e.g. 2021-04-23_H1_PostO3_pydarm_modelparams_ResponseFunctionContributions.pdf, which *doesn't* account for this change), and the DARM loop actuator loop shaping in general should be re-evaluated.

- It may never have mattered, but *all* the QUAD PUMs are used for arm-cavity alignment control, and this compensation update will decrease the frequency-dependent wiggles and differences between the coils and QUADs that may have impacted the ASC loops. I say "may have never mattered," because the band-width (highest unity gain crossing) is typically no more than a few Hz. BUT, now, there should be *negligible* frequency-dependent wiggles on all the QUAD PUMs actuation, where there maybe have been some before (no one's made the plot, so I can't quantify how bad it was). I'm explicitly thinking about the State 1 and State 2 Acquire filters, which had never been compensated beyond the dead-reckoned zs and ps from the circuit schematic. So, though I may not have quantitative evidence, this can only do good -- and if the systematic error was large before, that could have resulted in, among other things, unwanted length when angle was requested. And we always like reducing any source of A2L cross coupling, so that's nice. One of the other things may be issues we'd have with ASC plant stability, which we had always blamed on dP/d\theta, point absorbers, and other ideas. Again, it can only be better now (well, at least after we balance the DC gain of the coils again).

- Although I'm reasonably confident the having the switching for the filters change to "Always ON" and "Zero Crossing" means that there should be less voltage glitching upon transition from State 1 to State 3, I'm not confident that leaving the "threshold" setting at "0.0" is meaningful. I *think* this threshold is compared against the counts going into? out of? the filter, and the result used as a trigger for the switching. The idea being that if you switch quickly enough, while going through a zero crossing, then you're making the filter switch while passing 0 counts through the filter, so there's no glitch requested. So, I would guess that this needs to be some small, non-zero value of counts rather than exactly 0 (or else the comparison may never produce a "true" condition). 
Why does this matter in the bigger picture scheme of things? Currently, as we get near "NOMINAL LOW NOISE" in the lock-acquisition sequence, we use independently switchable capability of the coils to slowly and carefully (a) transition the DARM / ASC control to only 3 coils, (b) switch the 4th coil, then (c) rinse and repeat until all 4 coils are in the desired low-noise state. This takes a while -- of order minutes. We made the coils independently switchable, and invented this procedure, explicitly *because* when we tried to just switch all the coils at once, we'd get glitching that broke the lock. Maybe, once we confirm how to use the "Threshold" feature on the "Zero Crossing," we might be able to switch all the coils at once without causing glitching, and thus reduce the lock-acquisition sequence time by ~5 minutes. It's worth testing.