J. Driggers, J. Kissel, S. Dwyer

We were unsuccessful at measuring the two things we needed in yesterday's attempt (LHO aLOG 49541) at checking whether the ETMX IFO beam's spot position (i.e. determined by ETMX PUM A2L gains) impacts the sensing function measurement [where the hypothesis is that the confusing, apparently a-causal detuned spring response -- see e.g. LHO aLOG 48083 -- is an artifact of the DARM EXC through all stages of ETMX (including the PUM, which we suspect has L2A2L problems because of the spot position) during the open loop gain transfer function half of the two-part sensing function measurement suite].

Here "unsuccessful" means that we were able to get one half of the measurement -- the swept-sine DARM Open Loop Gain TF, but apparently lost like right at the start of the swept PCAL2DARM transfer function.
However, upon further investigation (details below), we believe the lockloss was NOT caused by starting the PCAL excitation, but by a rather fast run-away (within 5 seconds) of the SRC1 Pitch loop which in turn cross-coupled to the ARM ASC DOFs, and saturated ETMX. This is after ~1000 seconds of being happy in the moved-spot configuration. 

As such, we suggest the following when we try again:
   (1) Pay closer attention to the SRC1 P loop:
        (a) either rephase the AS72 WFS after spots have moved, or
        (b) open the SRC1 P loop during the measurement, and
   (2) Be faster with the measurement.

(2) will be a challenge, given that -- assuming all things the same, we'll only have ~1000 secs, and we *need* a swept sign measurement downs to ~5 Hz in order to really resolve changes in the funky detuned spring. Our suggestion is to lop off data above ~100 Hz, and maybe relax the integration time by a factor of 2.

But at least we now have a path forward to try again.

Investigation Details:
(1) I ran "lockloss select" in a terminal, and selected the appropriate lockloss time from the list. This opened the lockloss tool webpage for GPS time 1243206548.
(2) Browsing through the signals, at the 30 sec and 5 sec prior to lock loss, we immediate saw three suspicious things:
    (a) The ETMX L2 UL and UR (i.e. the PUM stage of ETMX) was the first to saturate, and did so in a rather sudden, but still slow (~5 sec time scale) and in a "runaway" fashion, not in a "oscillation" fashion, nor in a "sudden huge burst." Because the PUM is involved, which is the only stage the ASC system uses for control, this puts ASC signals rather high on the suspect list.
    (b) Scrolling down to the ASC section, we find the CHARD P, (and the remaining arm DOFS in P) show a 0.15 Hz oscillation, which apparently ramps up within the last 5 seconds, and
    (c) SRC1 P shows an interesting "runaway" feature that looks similar to the ETMX saturation.

(3) Upon pulling up these channels in NDSSCOPE -- such that we can investigate the time scale, whether these 30 seconds was similar to the previous many minutes that we had been stably functional in the spot, and to confirm that it wasn't the PCAL measurement's fault -- we confirm that
    (a) The PCAL excitation had started *extremely coincidentally* with the lock loss, but was not the cause. The DARM OLGTF excitation had stopped at 15 seconds before the lock loss, and the PCAL measurement start 1 second after. Neither correlated with the sudden change in character of the ASC signals 5 seconds prior.
    (b) The spot position, driven by the ADS system and triggered by the change in ETMX PUM P2L gain change, had settled (the ADS signal had converged), by ~1000 seconds before the lock loss, so the ~5 sec time-scale of the last-minute runaway or oscillations is not a function of the new spot position.
    (c) The apparent runaway "oscillation" of arm ASC DOFs, and specifically CHARD is a selection bias -- these kind of 0.15 Hz periodic wiggle in the last 5 seconds of the lock are at roughly the same amplitude as similar wiggles within the past ~1000 seconds when we arrive at the new spot position.

From this, we conclude that the SRC1 P runaway was the cause of the lock loss. Thus, we should NOT need to bother to adjust any ASC loop gains, because the lockloss was NOT caused by loop oscillating. We also don't need to worry about running the same templates for the CAL measurements. Thus we suggest the above ideas for trying again.