Oli, Camilla
ISC_LOCK takes longer to recognize and move to the LOCKLOSS state when a lockloss occurs than we want it to, sometimes leading to confusion regarding lockloss causes. Example: 71659
The part of ISC_LOCK that determines whether we have lost lock is in the is_locked function in ISC_library.py(attachment1). The current parameters for determining a lockloss rely on the H1:LSC-TR_X_NORM_INMON channel - once that channel's value falls below 500, ISC_LOCK will recognize that we have lost lock and will take us to the LOCKLOSS state.
Currently, when we are locked LSC-TR_X_NORM_INMON sits right around 1540, and when a lockloss happens, it takes ~0.55-0.65s after the lockloss start (based on ASC-AS_A_DC_NSUM_OUT) to drop below 500, and then takes another ~0.07-0.15s for ISC_LOCK to register this and take us to LOCKLOSS. To minimize this latency, since LSC-TR_X_NORM_INMON never gets below 1450 once we reach NOMINAL_LOW_NOISE, Camilla and I think it would be useful for the LSC-TR_X_NORM_INMON is_locked threshold value to be raised significantly to allow ISC_LOCK to register locklosses faster than it is currently. By raising the threshold to 1300 for example(attachment2), the time between the lockloss start and ISC_LOCK changing states would be reduced by a factor of 2-3.
During locking, state 420 (CARM_TO_ANALOG) is the first state to refer to the value of TR_X to determine a lockloss, and then every state after that is also looking at TR_X. By the time we reach CARM_TO_ANALOG, the value of TR_X is already at 1500, but it dips down and will sometimes near 1300 when between states 508-557(attachment1). Because of this, we we are wanting to create a new dof specifically for when we are in NOMINAL_LOW_NOISE to get passed into the is_locked function that checks that the value of TR_X is above 1300.
