Naoki, Vicky
We can ring up the 80.3 kHz PI using the PI damping infrastructure on ETMX. This 80.3 kHz ETMX mode is the real PI mode; this mode aliases down and has previously been observed as a strange 14.7kHz ETMX PI, eg. LHO:68165 in March/April 2023. LLO:64283 first identifies their 14.9kHz PI as an aliased down 80kHz mode; turns out it is the same at LHO.
"Aliased down" here means: we observe this mode by digitizing the 80.3 kHz signal with a sampling rate of 2^16 = 65536 Hz for e.g. the fast-ish channel H1:OMC-PI_DCPD_64KHZ_ADF_DQ. With this aliasing, we expect to observe the 80.3 kHz at:
- 80.3 kHz - 2^16 Hz = 80.300 kHz - 65.536 kHz = 14.764 kHz --> exactly what we saw before!!
- This is dead on where we observe the aliased down 14.764 kHz mode on ETMX in LHO:6816, etc. So, that 14.7kHz is not a drumhead mode; though we do see evidence of the drumhead modes as the forests slightly higher, around 14.9 - 15.1 kHz.
- Totally makes sense because the 14.7kHz mode always seemed suspicious; it has no anamolous peaks and the omc_dcpd_sum spectrum is totally flat around 14.7kHz, unlike / while we see the expected PI forest around 80.3 kHz.
------- we have added some damping infrastructure for the 80.3 kHz mode "29", the guardian has ~2-5 minutes to damp it, we will try. -----------------------------------------------------------
Driving ETMX with H1:SUS-PI_PROC_COMPUTE_MODE29_DAMP_GAIN = 5000, we could ring up the mode, see screenshot. Last 2 locklosses were because of this 80kHz mode, which rung up lockloss in < 1 minute.
In one instance so far, we saw this 80kHz (mode 29) PI ring up by itself (like, H1:SUS-PI_PROC_COMPUTE_MODE29_RMSMON > 0.02). In response, we changed the phase and the mode stopped ringing up and damped - but it wasn't clear to us if this is an ordinary transient or real damping of the mode. The PI guardian will turn on the ETMX master switch and the mode 29 PLL integrator and damping gain, and then try scanning the phase while notifying the user (i.e. it'll step H1:SUS-PI_PROC_COMPUTE_MODE29_PLL_PHASE by 30-90 deg on its slider).
Current summary of PI damping infrastructure:
| PI frequency | PI damping mode number | Test Mass | PI Guardian status | _DAMP_GAIN |
| 10.428 kHz | 24 | ETMY | automated | 1000 |
| 10.431 kHz | 31 | ETMY | automated | 1000 |
|
80.302 kHz (14.7kHz = aliased version of 80.3kHz mode) |
29 | ETMX | almost automated. --> damping automation has not been tested, but is in SUS_PI guardian. We need to see if guardian can sufficiently damp this mode in ~2-5 minutes. |
5000 (though maybe 1000 works too?) |
Edit: Lockloss @ 1365828833 was caused by an earthquake and not this 80 kHz PI, though it was seemingly ringing up at the time. Still not sure what is a normal range yet for 80 kHz PI's RMSMON.
Also -- there was no verbal alert for this incoming earthquake, though SEI configuration moved to Earthquake mode. Not sure if this is normal or not, but the verbal alert would have been helpful.
Finally a lockloss from this 80kHz PI @ GPS 1365840612, see attached. Looks like we have ~2-4 min to catch it for damping before we lose lock. I copied in some basic damping guardian code in (untested), so GRD will attempt PI damping of the 80.3 kHz next time.
Given the realization that this 80.3 kHz is the real mode, note that we do see this 80.3kHz mode ring up in our pi-damping infrastructure for 14.7 kHz at modes{ 15=14.768kHz , 16=14.760kHz} too: screenshot w/aliased modes.
