oli.patane@LIGO.ORG - posted 17:44, Sunday 23 July 2023 - last comment - 14:55, Monday 24 July 2023(71635)
Lockloss
Lockloss at 00:41. Detector moved itself out of Observing and into Commissioning, and then immediately lost lock. Cause not yet known.
Got back to NOMINAL_LOW_NOISE at 2:25, and went back into Observing at 2:26. Damping violins for only 50 minutes!!!!
I wasn't able to find anything about what could have caused this lock loss, but I did notice something that I found interesting, although there might be a very obvious explanation for it.
Looking at the H1:ASC-AS_A_DC_NSUM_OUT16 and H1:SQZ-LO_SERVO_ERR_OUT_DQ channels (Attachment 1), the H1:SQZ-LO_SERVO_ERR_OUT_DQ channel first sees the lockloss only 22ms after it starts. This is still during the initial small change in slope of ASC-AS_A_DC that leads into the large slope and subsequent dropoff.
I've also attached the ISC_LOCK and SQZ_MANAGER logs from when the lockloss occurred. The last four locklosses that we have had (possibly more before that), SQZ_MANAGER has given us the 'SQZ ASC AS42 not on?? Please RESET_SQZ_ASC' message ~0.1 seconds after the lockloss started. At least looking at the ASC and LSC channels that come up in 'lockloss select', none seem to respond to a lock loss that quickly.
Nice alog Oli. If you use the H1:ASC-AS_A_DC_NSUM_OUT_DQ channel (sampled at 2kHz rather than 16Hz) and zoom in on the y-axis you can see that the AS_A channel actually sees a discreet bump and runs away before the SQZ_LO_SERVO shows it's glitch, see attached. The SQZ-LO is locked to the OMC TRANS 3MHz sideband so it probably a sign that the light at the OMC has changed.
The messages in the log about SQZ AS42 is because we have already lost lock but ISC_LOCK hasn't yet realized: see the first "refined time" plot in the lock loss tool where the ISC_LOCK_STATE_N shows the lockloss happened nearly 1 second after H1:ASC-AS_A_DC_NSUM_OUT_DQ sees it happen, is this longer than usual? We expect the SQZ AS42 not to be able to be on when we are unlocked, tagging SQZ.