Summary: H1:SUS-ETMX_M0_DAMP_L_IN1_DQ looks to have been saturating during the long lock and making glitches in DARM at 9Hz.
In Detchar we're looking at the 2015-04-02 lock from ~8-13 UTC, which had good sensitivity and some amount of undisturbed time. The hveto page for that day has several interesting glitch classes. The first round winner is a series of glitches centered at around 9Hz and associated with the SUS ETM* L1/M1 L channels. These glitches seem to only show up in this high sensitivity lock and not the low sensitivity locks around it (perhaps higher RMS on M0 in low-noise configuration?). Checking the raw data, it appears that H1:SUS-ETMX_M0_DAMP_L_IN1_DQ is saturating.
- Figure 1 shows a time-frequency map of all glitches (black circles) and the glitches associated with this mechanism (red pluses).
- Loads of omega scans showing how these glitches show up in DARM and in the SUS channels can be found here.
- Figure 2 shows a spectrogram of the SUS channel lined up with its timeseries. I think the wavy cutoff at the top of the timeseries indicates saturation somewhere a little bit of filtering away from this channel.
- Figure 3 shows the spectrogram of the SUS channel lined up with the spectrogram of DARM. The broad SUS glitches up to 10Hz correlate with DARM glitches at around 8-9Hz.
Note: CIS says this channel is calibrated in um. I don't know whether this is a digital saturation or some physical thing - will consult a SUS expert.
One mystery, to me, is why the glitches occur at GPS times ending in .000, .250, .500, and .750. This might be due to time domain clustering in our glitch algorithm. At first I thought it indicated a digital origin for the glitches, which turns out to have been a red herring.
To follow up on the above, Joe Areeda made omega scans of 50 of these glitches in DARM, a tar file is here. Two examples are attached (each over four different timespans). In these scans, the DARM glitches look like three peaks excited for about a second.
I looked at some of the slow longitudinal channels for ETMX, and it turns out the common tidal control signal for the ETMs was hitting its software limit all throughout Wednesday night.
The first plot attached is a one-hour trend of the ETMX-M0_DAMP_L output, which shows the behavior that Josh found, alongside the common tidal control signal for ETMX (the common tidal signal is the same for both ETMs, so picture this happening for ETMY as well). The DAMP_L channel wasn't saturating, but it was flat-topping whenever the LSC-X_COMM_CTRL signal hit the soft limit at 10 microns. An image of the offending filter bank is also attached.
The 10-micron limit is pretty huge, and we're scratching our heads to figure out how the common tidal drive (which is essentially the low-frequency component of IMC-F) could have acquired such a large DC offset. The third plot is a four-hour trend that shows the offset in IMC-F being offloaded to the tidal as the Guardian state climbs towards low-noise.
The common tidal signal is sent to the L1 stage of both ETMs, where it is combined with whatever other longitudinal drive is beng applied to the optic, and then is offloaded to HEPI. During this lock, ETMY was also being driven by DARM, and the contribution of that signal was enough to provide a smooth control signal to the mass. But ETMX was only getting the common tidal signal, and it was stopping abruptly when it came up against the software limit.
Here's an idea for a control room tool: a script that looks at every CDS filter bank, figures out which ones have their limiter enabled, and checks whether the output is within 10% of the limit value during some span of time.
