Reports until 18:10, Sunday 02 September 2018
H1 ISC
gabriele.vajente@LIGO.ORG - posted 18:10, Sunday 02 September 2018 (43790)
CHARD YAW

I spent some time taking high resolution transfer functions with noise injections of CHARD yaw. The goal being to understand why we cannot increase the gain, as stated in many previous elog entries (43787, 43784, 43763, etc.)

The noise measurements are consistent with the sweep sine measurements. the plot below shows all three measurements together.

 

However, my conclusion from looking at this open loop transfer function is different from Sheila's and Craig's. My observations are

  1. the loop should indeed be stable if the gain increased by a factor of about 14, so that there are no more unity gain crossing at the resonances. In that configuration the unity gain crossing would be at about 8 Hz, where there is reasonable phase margin and still a bit of gain margin
  2. However, if we trust the measurements, the dip at 1.7 Hz would be dangerously close to unity, and with a phase very close to -180 degrees
  3. Moreover, although the current low gain gives a stable loop, and a higher gain also gives a stable loop, if we slowly increase the gain by a factor 10 or so, it seems to me that we are bound to become unstable at some of the multiple unity gain crossing. In particular, when the gain is increase by about 7 (from 0.3 to 2) the unity gain crossing at 1.7 Hz seems to become unstable. This is consistent with Sheila's anf Craig's observation in 43787)
  4. Additionally, all the lock losses due to CHARD_Y that I observed today were due to a ~1.7 Hz instability, which again seems consistent with my picture

So here's what I tried

  1. added a small resonant gain at 1.8 Hz, with a Q of 10 and 10 dB of gain, just to get that dip a bit higher.
  2. Once in full lock and with all ASC loops engaged
    1. engaged the 1.8Hz resonant gain > all good
    2. switched off the CHARD_Y loop > all good
    3. switched on CHARD again, with very short ramp (1 s) and gain increased by a factor 10 (3 instead of 0.3) > did not work (not surprising after all)
Images attached to this report