One possible cause of the DAC overflows we've been seeing (the ETMY saturation warnings) is something at high frequency using up the range of the drive. We only record the last output to the ESD DAC at 2048 Hz, so we don't see anything happening above a kHz. It's possible some high frequency line or feature bumps up against 2^17 counts and that makes the DAC overflow, which then causes a much larger glitch - once there's an overflow the whole thing will go crazy. To try to investigate this, the simplest thing to do is to record a channel like SUS-ETMY_L3_MASTER_OUT_LL_DQ at the highest rate possible, or something equivalent that monitors the actual signal sent to the ESD DAC. Once an ETMY overflow happens, save the data for several seconds around the time somewhere that people offsite can access it, preferably in a common format like ASCII or frames. Some time without an overflow would be good for comparison. Then we can see if there's something using up the drive range, or if it's just something sudden from somewhere else in the DARM loop. A few instances of overflows would be nice. If this is not possible, there's another tack we can take but it's more involved, so I'd prefer this.
If it's any help, we do record H1:SUS-ETMY_L3_ISCINF_L_IN1_DQ at the full rate (16 kHz). In full lock, this is the only signal (other than the calibration line) that is sent to the ESD. With an adequate knowledge of the filters between this channel and the ESD master outs, it should (in theory) be possible to reconstruct the master out signals at the full rate. That was the original motivation for recording this channel at full rate, anyway.
I managed to capture the full data for SUS-ETMY_L3_MASTER_OUT_LL around the time of the most recent glitch. I put it on my account on caltech at /home/jordan.palamos/detchar/ETMY_glitch.txt and also at https://lhocds.ligo-wa.caltech.edu/exports/jordan.palamos/.
The start time is 1125946072.8