J. Kissel

In continued efforts to reduce the frequency-dependent systematic error in the actuation functions for each stage of ETMX (step ii in LHO:46806's "steps to [actuation function] success"), I've measured all three stages of the ETMX driver electronics using the remote infrastructure of monitor circuits, as was done for ETMY before O1 (see LHO:20846). 

As before, I have to use the secret functionality of the digital requests of the binary I/O switching -- requesting negative state numbers, which gives you control over the COILOUTF filters. This allows one turn off any existing digital compensation, and drive through all the COILOUTF banks simultaneously with DTT. The only difference from the previous attempt at this method: I remembered to set all gains in all COILOUTF for all quadrants to +1.0, so the data is not confused by magnet polarity compensation or gain balancing.

For the Jeff Kissel in 2023 when he has to make these kinds of measurements again, and doesn't want to drive to the end stations and use the mess of electronics -- you still have to:
Now -- although this method is much more convenient and fast, this method has the distinct problem for the coil drivers -- the fast current monitor (aka FAST I MON) circuitry pick offs are up-stream of the output impedance networks of the coil drivers, so one cannot fit and poles and zeros that impact the system's transfer function from that part of the driver (for the UIM driver, the network results in a simple pole-zero pair; for the PUM driver, network is complex and switchable, with a different set of poles and zeros between "on" vs. "off" of the switch). Thus, we're going to try to salvage what we can from the flawed Sunday measurements (LHO:46754), and stitch them together with today's data.

Fitting details and results to come, but the measurement templates live here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Common/Electronics/H1/Data/SUSElectronics/ETMX/
    UIM/2019-02-07/
        2019-02-07_H1SUSETMX_UIMDriver_WhiteNoise_0p1to7000Hz_State1_TF.xml
        2019-02-07_H1SUSETMX_UIMDriver_WhiteNoise_0p1to7000Hz_State2_TF.xml
        2019-02-07_H1SUSETMX_UIMDriver_WhiteNoise_0p1to7000Hz_State3_TF.xml
        2019-02-07_H1SUSETMX_UIMDriver_WhiteNoise_0p1to7000Hz_State4_TF.xml

    PUM/2019-02-07/
        2019-02-07_H1SUSETMX_PUMDriver_SweptSine_0p01to30_State1_TF.xml
        2019-02-07_H1SUSETMX_PUMDriver_SweptSine_0p01to30_State2_TF.xml
        2019-02-07_H1SUSETMX_PUMDriver_SweptSine_0p01to30_State3_TF.xml
        2019-02-07_H1SUSETMX_PUMDriver_SweptSine_0p01to30_State4_TF.xml
        2019-02-07_H1SUSETMX_PUMDriver_WhiteNoise_1to7000Hz_State1_TF.xml
        2019-02-07_H1SUSETMX_PUMDriver_WhiteNoise_1to7000Hz_State2_TF.xml
        2019-02-07_H1SUSETMX_PUMDriver_WhiteNoise_1to7000Hz_State3_TF.xml
        2019-02-07_H1SUSETMX_PUMDriver_WhiteNoise_1to7000Hz_State4_TF.xml

    TST/2019-02-07/
        2019-02-07_H1SUSETMX_ESDLVLNDriver_WhiteNoise_0p1to7000Hz_State1_TF.xml
        2019-02-07_H1SUSETMX_ESDLVLNDriver_WhiteNoise_0p1to7000Hz_State2_TF.xml

As we begin to fit, we're finding that the broad-band excitations are a little lacking in low-frequency data points (and wasting high frequency data points), resulting in a ~3% systematic error in magnitude. Too big! In the future, I may suggest we do as we did for the PUM driver and use a swept sine excitation, and sadly go beyond 0.1 Hz down to 0.05 Hz.