J. Kissel

After 
- the investigations from last month led me to suspect that the systematic error in DELTAL_EXTERNAL calibration was due to an incorrect N 16 kHz delay between the sum of (1/C)*DARM_ERR and A*DARM_CTRL (see LHO:63607) led Evan and I down a grueling rabbit of 
- remembering how hard it is to get the math right when correcting for super-Nyquist effects (hence an versions 5, then 6, then 7 updates to T1900169), and 
- even more so remembering how hard it is to code it up in a DARM loop model in the era when we're using more that one arm to actuate on DARM (see pyDARM release 0.0.3 after the sweeping changes made with Merge Request 118)
has taken us 2 months and we're still not satisfied,

we've become impatient, and just want the calibration to be better. 

As such, today, I used our primary metric for systematic error we can access quickly to fudge the calibration to have less systematic error according to this metric. This "primary metric" is the transfer function between front-end's version of the calibrated data stream, H1:CAL-DELTAL_EXTERNAL_DQ -- nominally in differential arm displacement meters, [m] (as best we can make in real-time), in the presence of excitation from our absolute displacement reference, the Y-end PCAL a la H1:CAL-PCALY_RX_PD_DQ, also nominally in differential arm displacement meters, [m]. Thus we expect this transfer function that should ideally be unity magnitude and zero phase.

Attached are the results. The black traces are before the changes, and red traces are after.

(Eq. 97, which references Eq. 95 if  indicates why this is not a perfect metric. Please note, that Figure 1 is demonstrative of the level of correction one would need to create the perfect metric, the figure has NOT been updated with the true correction for either L1 or H1. As I mentioned, we're still in that rabbit hole.
Note that these DTT templates have *some* version of Eq. 97 installed as a calibration of the display transfer function, at least the "PCAL Correction," or else it would not be even close to flat. But this correction is *definitely* out of date, and has been computed differently for the swept sine vs. broad band version of the transfer function as is evident because the phase answer between these two nominally identical TFs is different.)

The following is a list of what I fudged. These changes were made *solely* based on making the H1:CAL-DELTAL_EXTERNAL_DQ / H1:CAL-PCALY_RX_PD_DQ flat and unity in magnitude. The fudges are not motivated by any measurement of any component, or physics, just my knowledge of what component contributes to the calibration, aka the response function, where (ala plots like this). I can't even claim that what I fudged is the *right* thing to physically fudge -- their may be more complex (namely, frequency dependent) effects going on. 
But alas it makes the H1:CAL-DELTAL_EXTERNAL_DQ / H1:CAL-PCALY_RX_PD_DQ transfer function flat, which makes the general public happy.
    (1) Applied a gain of 1.080 to the (1/C_calcs)*DARM_ERR path, aka "the sensing path." This is equivalent to applying a \kappa_C of 1/1.08 = 1.925. Prior to change the gain was 1.0.
    (2) Applied a gain of 1.010 to the (A_L2_calcs)*DARM_CTRL path, aka "the pum actuation path." This is equivalent to applying a \kappa_P of 1.01. Prior to change the gain was 1.0.
    (3) Applied a gain of 1.045 to the (A_L3_calcs)*DARM_CTRL path, aka "the tst actuation path." This is equivalent to applying a \kappa_T of 1.045. Prior to change the gain was 1.0.
    (4) Reduced the clock-cycles of delay between the sum of the (1/C_calcs)*DARM_ERR and the (A_L1_calcs + A_L2_calcs + A_L3_calcs)*DARM_CTRL path from 8.0 to 7.0 clock cycles.
See SDF screenshot for the exact channel names of what's changed.

For the last change, (4), I acknowledge (and confirmed via measurement again) that this *does not* affect the because of the bug in the RING_BUFFER.c code discussed in LHO:48620. I also confirmed that reducing below 7.0 clock cycles makes the calibration worse, indicating that my suspicion that the new super-Nyquist response of the OMC DCPD Transimpedance amplifier and Whitening Chassis would change this substaintially is unfounded. Indeed, that confirms that the model I had made with a previous release of pyDARM to predict what this should be, in LHO:63607, was wrong.

These changes were made *solely* based on making the H1:CAL-DELTAL_EXTERNAL_DQ / H1:CAL-PCALY_RX_PD_DQ flat and unity in magnitude. The fudges are not motivated by any measurement of any component, or physics, just my knowledge of what component contributes to the calibration, aka the response function, where (ala plots like this). I can't even claim that what I fudged is the *right* thing to physically fudge -- their may be more complex (namely, frequency dependent) effects going on. 
But alas it makes the H1:CAL-DELTAL_EXTERNAL_DQ / H1:CAL-PCALY_RX_PD_DQ transfer function flat, which makes the general public happy.
But, because this is fudged, that means:
    - it doesn't make sense to update the pyDARM model parameter set with this, because
    - these values come with no quantitative uncertainty, and in addition, 
    - because there's no model update, that means we haven't updated the CALCS representation of the model at calibration line frequencies, which means
    - the reported time-dependent correction factors computed from those calibration lines are now wrong in absolute value (e.g. the "measured" cavity pole now reads as 353 Hz, which can't possibly be right), which means
    - any attempt to correct for time-dependence with those numbers will *cause* systematic error, rather than reduce it.

So, it is what it is, and we'll continue to fight the good fight to try understand the problems, ironing out the flaws in the pyDARM model or its parameters in the background, but in the mean time at least between 15 and 1000 Hz, the H1:CAL-DELTAL_EXTERNAL_DQ / H1:CAL-PCALY_RX_PD_DQ transfer function is flat to within 2%, where before it was frequency dependent and as bad as 8-10% low.

I've accepted the changes in SDF.