J. Kissel, L. Sun

While Lilli was confirming that the calibration group's estimate of the calibration uncertainty against our PCAL to DELTAL_EXTERNAL transfer function sweeps (e.g. LHO aLOG 48535) which requires compensation for the artificial delay we add between the actuation and sensing paths, 
    H1:CAL-CS_DARM_CTRL_DELAY_CYCLES
(for explanation as to why, check out T1900169), she found a great deal of confusion when processing sweeps when this delay was 7.0 (prior to Apr 16th) vs. when it was 8.0 (after Apr 16th). Namely, she found that compensating for 8.0 created a HUGE reported systematic error, where as 7.0 did not. Even worse, this did not reconcile with our empirical evidence from ER14, when we would change this delay from 7.0 to 8.0 to 9.0, and it showed *no* impact on the measured transfer function.

Today, we measured the transfer function from just before this integer delay part to just after the delay part set at several integer values in order to settle this confusion once and for all.

We were surprised to find that the transfer function behaved as expected only up to 7.0 clock cycles. Above which (we checked at 8.0, 9.0, 10.0) the transfer function remained as though there was only a 7.0 clock cycle delay.

The first attachment shows the measurement.
The second attachment shows the MEDM screen location of this parameter.
The thirt shows the simulink location in the DARM block of the CAL_CS_MASTER.mdl library.

Thank the flying spaghetti monster that the right answer was ~7.0 clock cycles!

There is obviously some bug in this part, or limitations that we don't understand.
The code lives here:
/opt/rtcds/userapps/release/cds/common/src/RING_BUFFER.c

We leave the delay at 8.0 clock cycles and email Joe Betzwieser, the author of the code.

Note -- LLO is unaffected because they've been using a thiran filter since before O2 so as to get a non-integer clock cycle delay -- i.e. the CTRL DELAY filter. We haven't switched over to using that filter because when we recently created a thiran filter (LHO aLOG 48008), and tried to install it (LHO aLOG 48012) it "didn't work" in that it "created more systematic error than the change between 7.0 and 8.0 clock cycles," but that statement was made before we understand how to correct the PCAL to DELTAL EXTERNAL transfer function. It may be worth exploring again, it may not be. we'll see what the fallout of the bug fix is.