I've taken a look at DAC MCT glitches as requested by Dan in alog 16707
After running through our usual process to check for DAC glitches coupling into DARM, none of the SUS drive signals seem to be statistically correlated to glitches in DARM when crossing zero or +/- 2^16. I wish I had a smoking gun like we've been able to find with this method in the past, but we've had no such luck.
I wanted to make sure that the triggers indicating these zero-crossings were being generated properly, so I followed up a number of them by hand. They did seem to be reporting the correct times, so it doesn't look like this non-result is a bug in the trigger generation process. I've also generated omega scans for a few times when the ETMX ESD drive signals were crossing -2^16 and didn't see any glitches that looked like the transients we'd normally expect from DAC MCT glitches. This makes me think that the DAC glitches are hiding under the current noise floor (at least in the sense that Omicron doesn't seem to witness them) and will start becoming a more problematic noise source as sensitivity increases.
Is there any way to know when the calibration was last run for the 18-bit DACs? I really would've expected these crossings to cause fairly loud glitches from past experience.
I've attached a normalized spectrogram showing 5 minutes of data from the Feb 13th lock and it looks like there are two separate families of glitches that we can see by eye. One populating the frequency band between ~80 Hz - 300 Hz and one populating the frequency band from ~40 Hz - 100 Hz (which we initially thought might be DAC glitches). I've set some tools running to see if we can identify any of these and we're also doing some by-hand followup of the louder glitches that are likely to show up in omega scans of auxiliary channels.
RCG 2.9, which came with the band-aid, 3/4's of-the-way, fix to the 18-bit DAC Major Carry Transitions (see e.g. G1401269), that we believe lasts for ~1 month (see LHO aLOG 16376), was installed on January 13th 2015 -- see LHO aLOG 16060. This was the last time all IOP models were systematically restarted (the calibration is now performed automatically, but only when a front end's IOP model is restarted -- see T1400570 and Bugzilla Entry 732). Good to hear we have some evidence that the calibration seems to last a little longer at LHO!
Thanks TJ!
The glitches in the spectrogram seem to agree with the breathing that we saw in the control room. With the DAC glitches ruled out, we suspect that this noise is related to input beam jitter, there is some coherence with the IMC WFS signals. Later in the same lock we were able to reduce the noise by changing the BS alignment, so there is likely some bilinear coupling that changes over time. We'll try to get some longer lock stretches for glitch investigations.