J. Kissel, K. Izumi, E. Hall

We've put together a model of the new DARM loop after (a) all of our core CDS electronics been replaced (DAC, AI filters, AA filters, I/O chassis power supplies you name it), (b) a low-noise, low voltage driver on our ETMY, and (c) reshaping of the hierarchical control scheme to account for the new driver's lack of drive strength. 

The message -- we've still got some work to do to get back to the level of understanding we had of the frequency dependence before the above mentioned changes. As such, we have to inflate the frequency dependent uncertainty in the run back to 50% in magnitude and 20 [deg] in phase. Indeed, because the frequency dependence of residual between model and measurement is so large, it's difficult-at-best to make a statement about the optical gain (overall sensing function scaling factor), even though we have so accurately and precisely measured the actuation scale factors (LHO aLOG 18767).

For the time being, we'll use an optical gain of 1.31e6 [ct/m] in the sensing path, having scaled the model to match the OLGTF measurement at the UGF (for the first two measurements shown). Further, we'll stick with a DARM coupled cavity pole frequency of 355 [Hz], since it had been so for the few lock stretches we'd gotten before all the electronics hubbub.

--------
Details:
The model lives in 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/DARMOLGTFs/H1DARMOLGTFmodel_ER7.m, 
the parameters with which to match the three measurements are in the functions
H1DARMparams_1116854228.m (for 2015-05-28 measurement)
H1DARMparams_1116990382.m (for 2015-05-30 measurement)
H1DARMparams_1117124229.m (for 2015-05-31 measurement)

Since the first 2015-05-28 measurement is with the low noise ESD driver's low pass engaged, and the last 2015-05-31 measurement had a poorly scaled control system (see discussion below), we should use the parameter set and model from the second 2015-05-30 measurement.

TIME DOMAIN CALIBRATORS -- THIS PART'S FOR YOU
The model(s) have been seen saved to the following .mat file:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Results/DARMOLGTFs/2015-06-01_LVLNDriver_DARMOLGTF.mat
(apologies, it still composed of frequency response vectors, I didn't have time to convert everything to LTI objects).
The total actuation function is model(2).par.A.total with a delay of model(2).par.t.actuation microseconds.
The total sensing function is model(2).par.C.total with a delay of par.t.sensing + par.t.armDelay microseconds.
The stuff that's included in this model already that we don't plan on putting in the CAL-CS model that should be included in the GDS pipeline:
Actuation: 
     The digital and analog anti imaging filters -- model(2).par.A.antiimaging.total 
     The super-Nyquist-frequency pole of the new driver -- model(2).par.A.esdDriver.fc (at 2.42e4 [Hz]) << this one's tricky to include given the new hierarchy, just leave it out if you don't get how to do so.
Sensing
     The digital and analog anti aliasing filter -- model(2).par.C.antialiasing.total
     The super-Nyquist-frequency poles of the OMC whitening -- model(2).par.C.uncompensatedomcdcpd.c (at 13.7e3 and 17.8e3 [Hz])
END TIME DOMAIN PART

What we've learn about / explored so far trying to clean up the model:
- We need to invert the sign of the L3 / ESD stage in order to get the phase to even closely match the measurement. We have a couple of theories on this, and our "best" is that the charge is so large on ETMY that it's effectively flipping the sign of the ESD actuator. We saw hints of this during our ALS DIFF and FS MICH actuation coefficient measurements, but didn't need to pay attention to them at the time. Now (not that we weren't before, but), we should perform the same sign checks that Shivaraj and co performed at LLO (see LHO aLOG 18406).
- We've been have problems for the past month or so with our optical gain fluctuating, and I think we've narrowed it down to poor compensation / scaling of the OMC during the hand off to DCPDs. We thing we've addressed this now here: LHO aLOG 18768, but the last open loop gain transfer function (I took it -- LHO aLOG 18733) in which I had incorrectly scaled the DARM loop gain to compensate for the poor scale factor should probably, eventually, be thrown out. I kept it in this data set, simply because we've had so few, and one needs at least three to make a pattern.
- Recall the first measurement was taken with the new ESD driver's low pass filter engaged, and I release while writing this aLOG that I didn't properly include that in the model. However, I've received a spice model of the driver with and without the low pass engaged, so I've fit the poles and zeros to be
par.A.esdDriver.poles_Hz = [159.1 2.42e4]; % [Hz] 
par.A.esdDriver.zeros_Hz = 3189.4; 
see /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts/Spice/model_LVLN_driver_20150601.m
- We did NOT have time enough to include all of the recent measurements of the analog AA and AI filters, but we're currently using the mean of the some 200 measured filters as before, and we don't expect this to have too much of an influence in the gravitational wave band. Certainly not the source of the bonkers frequency repsonse residual we have at the moment.
- We need to include the above poles and zeros properly into the ESDOUTF bank, and change the ESD driver's state machine so that it can handle all of the different configurations of the driver. After ER7.
- Now that we're using a sort of hybrid offloaded AND distributed control scheme for the three actuation stages of ETMY, we needed to rethink the loop math, specifically how each stage should be added together. In short, it changes from a simple
A_TOTAL = LOCK_L1 * SUS_L1toL3 + LOCK_L3 * SUS_L3toL3;
to a nasty
A_TOTAL =   LOCK_L1 * LOCK_L2 * LOCK_L3 * DRIVEALIGN_L1_L2L * SUS_L1toL3 
          + LOCK_L2 * LOCK_L3 * DRIVEALIGN_L2_L2L * SUS_L2toL3 
          + LOCK_L3 * DRIVEALIGN_L3_L2L * SUS_L3toL3

(plus the sign flip in front of the last term mentioned above).
- We've double checked and triple digital filters and gains, which are being read in from the foton file archive, so we're 80% confident (as confident as one can be at 3am) that we're not stupidly loading in bad filters or anything. 

That's all I've got steam for at the moment. I'll see y'all in the morning.