Tonight I followed up on the work that Stefan & I started two weeks ago, and switched the power-up step in the Guardian to come after the transition to DC readout.

Now, the OMC is locked at 2.3W input power, DARM offset = 3.7e-5 counts / 52 pm.  These settings were chosen to provide 20mA at the DCPD Sum.  At the transition to DC readout, the overall OMC-READOUT_ERR_GAIN is set to match the DARM gain on AS_Q, and the power normalization is absorbed by the OMC-READOUT_PREF_OFFSET, as Stefan described in the earlier entry.

During the INCREASE_POWER step the DARM offset (which after the handoff is set via OMC-READOUT_X0_OFFSET, in picometers) is stepped down to maintain the same photocurrent out of the DCPDs.  This *should* maintain the DARM gain through the quadratic scaling of DCPD Sum as a function of DARM offset...but it's not perfect.  I tried this twice today, and after the power-up finished, the DARM loop gain was too low by 30%.  Not sure if this is due to the initial gain matching before the handoff (this step still needs some work, maybe a tdssine measurement would be better), or some non-quadratic change in the response as we go from ~50pm to 16pm.  Stefan, Keita and I observed a small static fringe offset, we should make a careful measurement of DCPDSum vs DARM offset to check that what we think is quadratic really is.

We believe this arrangement is an improvement, because locking the OMC and transitioning to DC readout is more robust at low power, and also I suspect the power-up is more stable on DC readout.  I have increased the PSL waveplate velocity during the power-up (now it's 20, it was 10, not sure about the units), this worked without any trouble.  I am leaving the IFO locked at 23W in the LSC_FF state, with the intent bit set to "Undisturbed."  The range says 65Mpc - could it be true?  Earlier tonight there was a slow angular drift that killed a 23W lock, I am not sure how long we will last.  Also the ITMX oplev loop is ringing for quite some time after each lockloss, it may be a challenge for the IFO to relock on its own.

A screenshot of the new guardian sequence is attached.  I committed the ISC_LOCK.py code before and after the change.  I tested the new sequence twice without a hitch.