This lockloss may have been caused by PI mode 27? It rang up 06:57UTC and was missed by Travis, but seemed to have turned itself around and began to slowly damp itself down. When I got on shift I also missed this mode somehow and it stayed at around 200counts for about 3 hours. I can't imagine that this was healthy.
Images attached to this comment
terra.hardwick@LIGO.ORG - 09:51, Thursday 09 February 2017 (34022)
18037 Hz ETMY mode; It shifted down in frequency (since its really an aliased down mode) during the long lock by ~1/2 Hz. BP filter should be double checked - there's about 2 Hz leeway above and below before you hit another mechanical mode, so BP could be widened. In attached plot, black is beginning of lock, red is during the ring up (27 hrs into lock). Peak at 18040 ish Hz is ETMX mode.
This was damping and below the usual break-lock amplitude when we lost lock, so likely wasn't the cause. I don't see the usual coupling down into DARM frequency bands that usually occur before a PI-induced lock loss.
Images attached to this comment
travis.sadecki@LIGO.ORG - 17:10, Thursday 09 February 2017 (34032)PSL
Clued by TJ's comment in aLog 34018 about having to toggle the Noise Eater after this lockloss, I was curious as the possiblity of this lockloss being due to PSL FSS PZT oscillation. I have seen several locklosses at earlier steps in lock acquisition due to the PZT oscillation earlier in the week. In the attached plot, you can see that the FSS PZT oscillations and Noise Eater issues occur simultaneousely at 10:14:45 UTC. It seems more likely that this caused the lockloss than the 'below-lockloss-threshold' PI mode.
This lockloss may have been caused by PI mode 27? It rang up 06:57UTC and was missed by Travis, but seemed to have turned itself around and began to slowly damp itself down. When I got on shift I also missed this mode somehow and it stayed at around 200counts for about 3 hours. I can't imagine that this was healthy.
18037 Hz ETMY mode; It shifted down in frequency (since its really an aliased down mode) during the long lock by ~1/2 Hz. BP filter should be double checked - there's about 2 Hz leeway above and below before you hit another mechanical mode, so BP could be widened. In attached plot, black is beginning of lock, red is during the ring up (27 hrs into lock). Peak at 18040 ish Hz is ETMX mode.
This was damping and below the usual break-lock amplitude when we lost lock, so likely wasn't the cause. I don't see the usual coupling down into DARM frequency bands that usually occur before a PI-induced lock loss.
Clued by TJ's comment in aLog 34018 about having to toggle the Noise Eater after this lockloss, I was curious as the possiblity of this lockloss being due to PSL FSS PZT oscillation. I have seen several locklosses at earlier steps in lock acquisition due to the PZT oscillation earlier in the week. In the attached plot, you can see that the FSS PZT oscillations and Noise Eater issues occur simultaneousely at 10:14:45 UTC. It seems more likely that this caused the lockloss than the 'below-lockloss-threshold' PI mode.