Reports 1-1 of 1 Clear search Modify search
MIF (General)
hirotaka.yuzurihara - 17:54 Tuesday 05 November 2024 (31501) Print this report
lockloss investigation: 2024/11/05

[Kenta, Ushiba, Dan, Yuzu]

I performed the lockloss investigation for the data on 2024/11/05.

  • For 2024/11/05 14:18:59 JST, the main lockloss cause was the transient behavior of the laser light source for ETMY MN oplev. This issue was sometimes reported. We guess this transient propagates to the suspension control vis the K1:VIS-ETMY_MN_MNOLDAMP_P_OUT_DQ and K1:VIS-ETMY_MN_MNOLDAMP_Y_OUT_DQ.
    • I attached the screenshot of the ndscope around this lockloss (Fig). Check the second row of K1:VIS-ETMY_MN_OPLEV_TILT_SUM_OUT_DQ. The glitch occured before the K1:LSC-AS_PDA1_RF17_Q_ERR_DQ passed zero.

I prepared the ndscope to check it : /users/yuzu/lockloss/MN_OPLEV_GLITCH.yml .

Images attached to this report
Comments to this report:
takahiro.yamamoto - 11:21 Thursday 07 November 2024 (31517) Print this report

I tried to detect this issue in automated process and checked for 152 locklosses from DC lock state since September.
They seems to be detected by using the 1st‐order differentiation of oplev sum.

There were 27 obvious events in this term such as Fig.1.
In addition, there were several events which was slightly difficult to judge a jump in oplev sum was really a cause of lockloss such as Fig.2.

If we set the threshold for minimizing a false detection it's not so difficult. Threshold can be decided from past lockloss events.
On the other hand, it might be difficult to reduce false dismissal cases especially for the case that oplev light became unstable in long term.

Images attached to this comment
Search Help
×

Warning

×