J. Kissel

I've process Craig's sensing function from last night (LHO aLOG 47354), in which he states, the data lives here:
     2019-03-07_H1DARM_OLGTF_5to1100Hz_20min.xml
     2019-03-07_H1_PCAL2DARM_TF_5t1100Hz_8min.xml
I had to finagle the exported data a bit -- the PCAL to DARM TF result appears to have 1 less frequency point (at ~5 Hz) than the DARM OLG TF result, so I just stripped the DARM OLG TF data of that frequency point. Also, there seems to have been a data point with coherence of identically zero which confused the data processing software, so I modified it to be some small non zero value.

The comparison of model to measurement is attached. The numerical answers are
   Optical gain, H_c (ct/m)                 | 3.426e+06 (+1799,-2153) or (+0.0525%,-0.06285%)
   Optical gain, H_c (mA/pm)                | 4.236     (+0.002224,-0.002662) or (+0.0525%,-0.06285%)
   Cavity pole, f_cc (Hz)                   | 394.6     (+1.418,-1.17) or (+0.3594%,-0.2965%)
   Detuned SRC spring frequency, f_s (Hz)   | 2.353     (+0.06679,-0.08249) or (+2.839%,-3.506%)
   Detuned SRC spring quality factor, Q_s   | 0.01186   (+0.003069,-0.001373) or (+25.87%,-11.58%)
   Residual time delay, tau_c (usec)        | -0.4223   (+0.9933,-0.8277) or (+-235.2%,--196%)

The systematic error above ~100 Hz is great -- likely attributed to Stefan's good work compensating the DCPDs (LHO aLOG 47257) and some further good results from fitting the high frequency poles of the OMC DCPD whitening chassis by Lilli (see LHO aLOG 47377). Impressively, the residual time delay (which can be either real unknown delay, or uncompensated high frequency poles) is consistent with zero, within 1 [us].

Low frequency is still a problem -- at the 5% level below 20 Hz, with a 1% wiggle around 80-100 Hz. The good news is -- due to my template tuning (mentioned at the tail end of LHO aLOG 47206), we're now able to resolve some of our detuning again -- and the message is, we definitely have it. given the wiggle at ~90 Hz, I'm wondering if we're on the opposite side of the SRC detuning such that we're seeing pro-spring -- so much so that the ~90Hz wiggle may be the right-half plane poles not perfectly canceling the left real zero, that normal reduce to a single pole frequency when the RSE detuning phase is very close to 90 deg (see discussion of this effect in P1600295, Section 5.2).

I'd like more data with more dense frequency points around 90 Hz and between 20 and 8 Hz to really make conclusive statements about all this, but the message is that the "simple" O2 model of the detuning is failing to replicate the features seen in this plant below 100 Hz -- at the 5% level below 20 Hz.

Most of you will argue this level of systematic error is "good enough" for the sensing function.

If you insist, then populate the CAL-CS_DARM_ERR filter (preferably in new pair of filter banks, please) with the following two filter modules.
    SRCD2N: zpk([394.6064;2.3389;-2.3668],[0.1;0.1;7000],1,"n")gain(553.54)
    Gain: gain(2.919e-07)
and set the CAL-CS_DARM_ERR gain to 1.0.

Since Craig updated the CAL-CS gains on the actuator paths (LHO aLOG 47354) with the numbers from LHO aLOG 47331 (which I argued were good on TST, but still bad on PUM), then we can also run and process the DARM Open Loop gain measurement against the model, and predict the level of systematic error that would remain if we updated the sensing function as above.

See that result attached second.
Unsurprisingy, the residual systematic error looks exactly the residual systematic error in the PUM stage reported in LHO aLOG 47331.

However, the flaws are are all below 30 Hz. So theoretically, this he above sensing function is pushed, we should have little-to-no remaining systematic error above that frequency region.

And one more thing -- you'll have to update the delay between the sensing and actuation paths to 7.0 clock cycles.
See that result attached 3rd. This is consistent with what we've used for O1 (LHO aLOG 22117) and O2 (LHO aLOG 33924). The real delay is 6.89 [16kHz clock cycles], and the difference shouldn't result in that much systematic error. I haven't yet had the time to figure out the Joe Betz / Shivaraj generation of a thiran filter (see hints at LLO aLOG 28268) that allows for non-integer delays.