Much of tonight was spent fighting with ETMX. This time, ASC was definitely off, there was nothing coming out of the ASC filter banks except the static output of the ASS. I tried turning off the 1000 count POS offset, but I think that made it a little worse. I ended up putting the offset back.
It's a little confusing, since it sometimes moves when there is no LSC actuation. However, it definitely moves when there is some LSC actuation. I did a test where every time I enabled the IR arm locking and caught lock, I saw a step in the SUSPIT and SUSYAW error signals. Once lock was aquired, it would settle and stay somewhere. If I unlocked the cavity, there was no "undo" step - it just stayed where it was. I wasn't letting it sit long enough to see if it spontaneously moved during this test.
Here's a plot of this test. The only button I'm touching is the LSC enable button. ASC is off, ASS is frozen (DC values exist, but no dither, no feedback). This was done when the 1000 count POS offset was off. The steps are less bad when the offset is on.
In between fighting with the ETM, I was able to do several trials with the PRFPMI.
I was playing with CARM and ALS fool.
First, I used REFL55 normalized by the sum of the transmissions as the error signal for the MC filter bank and saw that REFL11 (as an out of loop signal) got much more smooth, and centered around zero. However, I wasn't able to get the same thing with REFL11. No matter the sign I used for the MC filter bank, the IFO would squeak (some high freq gain peaking I think), and then I'd lose lock. This was true whether I used REFL11 through the common mode board or just directly into the ADC.
Just now, I did one trial of switching DARM over to AS55Q, just to grab a spectra of the MICH noise that Q and I saw yesterday.
I'm a little confused by some delay that seems to exist between the "A" and "B" error signals (right after the LSC input matrix) and the _IN1 point of the servo filters. I didn't save the measurement (bad Jenne), but there's a ~40 degree difference between DARM_A_ERR/DARM_IN2 and DARM_IN1/DARM_IN2. I don't think there should be anything there. Anyhow, it makes the DARM loop measurements look funny. If you just look at, say, DARM_B_ERR/DARM_IN2, you'll think that there's no way that the loop will be stable. However, it will actually be fine.
For tomorrow, we should take the DARM loop measurement with much less actuation. As with last night, I blew the lock by trying to measure the DARM loop.