I've heard two ETMY saturations announced while I've been here, the most recent one at ~17:24 UTC. I also see several large, 1 minute drops in the inspiral range over the course of this lock stretch. Suspecting that all of these gltiches are ETMY saturations, I've trended the saturation channel (H1:FEC-98_ACCUM_OVERFLOW) over the pas 10 hours (starting at 17:25:44) and I see that there are plenty.

Sadly, we *still* can't trend DMT channels in dataviewer (I would love it if someone told me I'm wrong), so I can't quickly put the inspiral range on the same trend plot to see if they're roughly coincident.

To aide in the offline study, I attach the channel map for each OSEM / ESD DAC channel from the Simulink front-end model. Recall you can find out where all of these OSEMs / QUADRANTs I mention are physically by looking at E1000617. Also recall, there are two EPICs channels for saturations one can look at for each DAC channel, the "instantaneous" and accumulative. The instantaneous channels are 
${IFO}:FEC-${DCUID}_DAC_OVERFLOW_${CARDNUM}_${CHANNELNUM}
${IFO}:FEC-${DCUID}_DAC_OVERFLOW_ACC_${CARDNUM}_${CHANNELNUM}

I cite the accumulative channels below.

H1:FEC-98_DAC_OVERFLOW_ACC_0_0 = M0/TOP F1
H1:FEC-98_DAC_OVERFLOW_ACC_0_1 = M0/TOP F2
H1:FEC-98_DAC_OVERFLOW_ACC_0_2 = M0/TOP F3
H1:FEC-98_DAC_OVERFLOW_ACC_0_3 = M0/TOP SD
H1:FEC-98_DAC_OVERFLOW_ACC_0_4 = M0/TOP LF
H1:FEC-98_DAC_OVERFLOW_ACC_0_5 = M0/TOP RT

H1:FEC-98_DAC_OVERFLOW_ACC_0_6 = R0/TOP LF
H1:FEC-98_DAC_OVERFLOW_ACC_0_7 = R0/TOP RT
H1:FEC-98_DAC_OVERFLOW_ACC_1_0 = R0/TOP F1
H1:FEC-98_DAC_OVERFLOW_ACC_1_1 = R0/TOP F2
H1:FEC-98_DAC_OVERFLOW_ACC_1_2 = R0/TOP F3
H1:FEC-98_DAC_OVERFLOW_ACC_1_3 = R0/TOP F4

H1:FEC-98_DAC_OVERFLOW_ACC_1_4 = L1/UIM UL
H1:FEC-98_DAC_OVERFLOW_ACC_1_5 = L1/UIM LL
H1:FEC-98_DAC_OVERFLOW_ACC_1_6 = L1/UIM UR
H1:FEC-98_DAC_OVERFLOW_ACC_1_7 = L1/UIM UR

H1:FEC-98_DAC_OVERFLOW_ACC_2_0 = L2/PUM UL
H1:FEC-98_DAC_OVERFLOW_ACC_2_1 = L2/PUM LL
H1:FEC-98_DAC_OVERFLOW_ACC_2_2 = L2/PUM UR
H1:FEC-98_DAC_OVERFLOW_ACC_2_3 = L2/PUM LR

H1:FEC-98_DAC_OVERFLOW_ACC_3_0  = L3/TST ESD Bias
H1:FEC-98_DAC_OVERFLOW_ACC_3_1  = L3/TST ESD UR
H1:FEC-98_DAC_OVERFLOW_ACC_3_2  = L3/TST ESD LR
H1:FEC-98_DAC_OVERFLOW_ACC_3_3  = L3/TST ESD UL
H1:FEC-98_DAC_OVERFLOW_ACC_3_1  = L3/TST ESD LL
(not the "odd" ordering of the TOP and ESD channels, which are different from "normal" OSEM stages.)

I've written some gwpy code to find ADC/DAC overflows and turn them into DQ segments: github link. It needs gwpy and has to run on a cluster so it has access to the data. If you want to use it in the control room, and gwpy has been installed there, I can easily convert it to use NDS.

To use it on the cluster, do
source ~detchar/opt/gwpysoft/etc/gwpy-user-env.sh
python make_overflow_dq_triggers.py -i H1 -c H1-omc-lsc-etm.txt -s 1121940832 -e 'lalapps_tconvert now'

The config file is attached, as is the code.

The times when the ETMY L3 DACs overflowed in this lock are below. I can scan them to see how big of a glitch they made.

 1121942076.7500 1121942077.0000
 1121950991.2500 1121950991.3750
 1121951661.9375 1121951662.0625
 1121953931.1250 1121953931.2500
 1121955356.8125 1121955356.9375
 1121957517.1875 1121957517.3125
 1121963083.7500 1121963083.8750
 1121966658.3125 1121966658.6250
 1121969119.5625 1121969119.7500

I've made some Omega scans. Here's a link to the directory: LHO webserver

The SNRs of the resulting glitches range from 200 to 3000. The biggest of these are about as bad as the beamtube cleaning glitches. We plan to make some veto flags for overflows like this, but obviously it's best to fix them.

See below for the coherence report.

Minute trends seem to have about a 2 hour delay getting to ldas.
Because of the difference in range of the 2 channels I had to make 2 plots but the drop in range does seem to coincide with the overflow.

I'm not sure if DMT now has access to H1:DMT-SNSH_EFFECTIVE_RANGE_MPC but that data is available via NDS2