Reports until 22:16, Saturday 22 August 2015
H1 ISC
evan.hall@LIGO.ORG - posted 22:16, Saturday 22 August 2015 - last comment - 02:44, Tuesday 25 August 2015(20793)
PRM M3 LL ramp-off

Jim, Evan

We have grown tired of the glitching in the PRM M3 LL OSEM, so here is a script that ramps it off in full lock. It gets rid of the glitching and allows us to recover 60ish Mpc range.

Also included is a screenshot of the usual Euler/OSEM matrix for PRM.

Images attached to this report
Non-image files attached to this report
Comments related to this report
andrew.lundgren@LIGO.ORG - 14:29, Sunday 23 August 2015 (20801)DetChar, ISC, SUS
From detchar, here are some glitchgrams to show just how well this works. The PRM M3 LL OSEM was ramped off at 3:43 UTC, and again at 7:13 UTC in a different lock (times gotten by check EUL2OSEM matrix elements). Two glitchgrams are attached which shows that the excess glitchiness goes away as soon as the LL quadrant is disabled. This is fantastic because these are one of our top most worrisome glitch classes from ER7.
Images attached to this comment
jeffrey.kissel@LIGO.ORG - 20:36, Monday 24 August 2015 (20840)DetChar
Hey @DetChar, can you make a glitch-gram of the H1:SUS-PRM_M3_NOISEMON_LL_DQ? 

Evan's gunna make a spectragram to see if it contains the same frequency content as the glitch grams (of DARM and the one you'll make). This "on/off" test of PRM M3 LL, at least shows that the frequency content of the glitching is below 50 [Hz]; if the content is similar in spectragram, we can use that -- a spectragram is much easier to make on the floor and/or at least here on site while the channel is being investigated. 

At this point, the entire drive chain is suspect, and we're not really sure where to start. I worry that starting without a more pointed target, it means we'll be looking for hours, slamming a sledge hammer blindly everywhere, and only come up with more questions. For example, as you know, these NoiseMons can be tricky. This particular PRM M3 LL NoiseMon has passed what tests that have been done on it (see LHO aLOG 17890), but the test is only a "which one of these doesn't look like the other" kind of test, not anything concrete.
evan.hall@LIGO.ORG - 21:08, Monday 24 August 2015 (20842)

Jeff and I looked at a time series trend of the LL noisemon when the interferometer was not locked, in order to give a baseline for diagnostics.

During a quiet time, it seems the peak-peak of the noisemon is about 30 counts, which [accounting for the ADC gain (216 ct / 40 V)] is something like 20 mV pp.

During a noisy time, the peak-peak can go as high as 100 counts, which is something like 60 mV pp.

Non-image files attached to this comment
andrew.lundgren@LIGO.ORG - 02:44, Tuesday 25 August 2015 (20853)DetChar, ISC, SUS
@Jeff - A glitchgram would not be terribly enlightening. Normalized spectrograms actually show these glitches very clearly, and even standard spectrograms are fine. 

These glitches only show up in DARM to about 70 Hz, but they're in PRCL up to 150 Hz (first plot). They're getting fed back to PRM, among other things, so all four quadrants' drive signals look like PRCL. The second plot is the normalized spectrogram of LL MASTER, and it's the same as PRCL. There's also something near Nyquist in the plot, but I think it's just spectral leakage in the spectrogram.

The characteristic of the LL noisemon (third plot), in contrast to the other noisemon, is that the glitches go up to 1 kHz. They happen at the same time as the glitches in MASTER, so below 150 Hz this doesn't tell us anything. But the higher-frequency content indicates that something before the noisemon is creating excess noise. And since the excess noise goes away as soon as the LL drive is zeroed, it's not just a problem in the noisemon.

The noisemon stops showing any glitches once the drive is zeroed, which may be a useful clue. Is it possible to drive a single line in MASTER and see what the noisemon shows?

The first three plots were all normalized spectrograms. The last two are standard spectrograms to show that these glitches do show up there. I used 0.25 sec FFTs with overlap of 0.9.
Images attached to this comment