Displaying report 1-1 of 1.
Reports until 18:45, Tuesday 11 July 2017
H1 ISC (DetChar, OpsInfo, SUS)
jeffrey.kissel@LIGO.ORG - posted 18:45, Tuesday 11 July 2017 (37467)
Evening Update -- Rung up ETMX Violin Mode Reduced in RF; Problems with DC Readout; Confusing Lock Losses
J. Kissel, E. Merilh, P. Thomas, T. Vo, J. Driggers, K. Izumi,

Last night ETMX violin modes 507.159 and 507.194 Hz had mysteriously rung up on Patrick last night, and unfortunately in his attempts to do something about he rung up the mode to all get out (visible way above even an RF DARM spectra). 

After maintenance was complete (around 1:00p local), we were able to smoothly get up ENGAGE_SRC_ASC -- but only after
 -  an initial alignment 
 - a discovery of the YAW input to PRM being off from the ASC model reboot today (Thanks DIAG MAIN!!), and
 - a wrong POP QPD A offset, also from the ASC model reboot (thanks to Kiwmau's detective work).
 
Once that was figured out, I spent the afternoon finding settings of the ETMX MODE6 and MODE7 violin mode damping filter banks that would *damp* the modes instead of exciting them. In the end, what worked was a change *only* in the MODE7 bank: 
    use negative gain, and only FM1 (507.194New) and FM4(100dB) .
(as opposed to what's encoded in guardian and in the violin mode table as positive gain and FMs 1(507.194New), 3(+60deg), and 4(100dB))
With these settings, it was the usual game of watching the control outputs and slowly increasing the gains to preserve one's sanity. 
I also had initial success by *only* using MODE7, and keeping MODE6 low -- this was to get the 507.194 mode down enough below the 507.159 mode that things started behaving more normally (with more gain on MODE6 than 7).

Once all ETMX modes were damped to the noise floor of AS_Q ("RF DARM") -- including extra gain on ETMX MODES 5 and 8 at 506.922 and 507.391 once the above middle two were under control -- and confirmed that neither DCPD were close to saturation, we tried transitioning to DC readout.

This failed on us several times, exactly when the DARM error signal was switched over to the DCPDs.
We explored several reasons as to why this might be going wrong (hanging out in DC_READOUT_TRANSITION), but in the end we only found that the AS_AIR and OMC READOUT ERR signals (which should be ideally unity and flat in this state) had the attached, very weird transfer function (though in truth this is a new lock, the DC gain was only -10 dB in the prior lock).
Even so, we were able to transition that third time.

We're still exploring the fishiness, but quickly running out of steam...
Images attached to this report
Displaying report 1-1 of 1.