Haven't figure out the cause, but this lockloss generally follows the pattern that we have seen for other 'DARM wiggle'** locklosses, but there are a couple of extra things that I noted and want to have them recorded, even if they mean nothing.
Timeline (attachment1, attachment2-zoomed, attachment3-unannotated)
Note: I am taking the lockloss as starting at 1402637320.858, since that is when we see DARM and ETMX L3 MASTER_OUT lose and fail to regain control. The times below are milliseconds before this time.
152 - 147ms before LL (yellow box): EX L3 MASTER_OUT channel has a small but sharp drop. This might not actually be anything significant, but the slope of this little drop is much steeper than how EX L3 usually moves. This is not seen by DARM.
116 - 95ms before LL (blue): LSC_DARM_IN1 and DCPD{A,B} are suddenly a bit noisier
96 - 68msbefore LL (pink): glitch
68 - 1ms before LL: DARM and DCPDs go back to looking like normal (the classic requirement of what makes it a DARM wiggle)
0ms (green): DARM/EX L3 MASTER_OUT/DCPDs lose control -> lockloss
It also kind of looks like ASC-CSOFT_P_OUT and ASC-DSOFT_P_OUT get higher in frequency in the ten seconds before the lockloss(attachemnt4), which is something I had previoiusly noticed happening in the 2024/05/01 13:19 UTC lockloss (attachment5). However, that May 1st lockloss was NOT a DARM wiggle lockloss.
** DARM wiggle - when there is a glitch seen in DARM and ETMX L3 MASTER_OUT, then DARM goes back to looking normal before losing lock within the next couple hundreds of milliseconds
06:45 Observing
Haven't figure out the cause, but this lockloss generally follows the pattern that we have seen for other 'DARM wiggle'** locklosses, but there are a couple of extra things that I noted and want to have them recorded, even if they mean nothing.
Timeline (attachment1, attachment2-zoomed, attachment3-unannotated)
Note: I am taking the lockloss as starting at 1402637320.858, since that is when we see DARM and ETMX L3 MASTER_OUT lose and fail to regain control. The times below are milliseconds before this time.
It also kind of looks like ASC-CSOFT_P_OUT and ASC-DSOFT_P_OUT get higher in frequency in the ten seconds before the lockloss(attachemnt4), which is something I had previoiusly noticed happening in the 2024/05/01 13:19 UTC lockloss (attachment5). However, that May 1st lockloss was NOT a DARM wiggle lockloss.
** DARM wiggle - when there is a glitch seen in DARM and ETMX L3 MASTER_OUT, then DARM goes back to looking normal before losing lock within the next couple hundreds of milliseconds