D. Barker, F. Clara, R. Crouch, C. Gray, J. Kissel, M. Pirello, E. von Reis
IIET Tickets 13232 and 20828
ECRs E1900216 and E2100485
WP 10609

We've installed new 20-bit DAC cards for the M2 and M3 stages of SRM and SR2 this morning. In doing so, we've installed all of the front-end code / "model" infrastructure we've prepared to receive that upgrade -- see LHO:64368 and subsequent comments (that aLOG only talks about the USER models, but Dave has also updated the h1susioph34 and h1susioph45 IOP models as well).

Erik and Dave will post more details in their aLOGs, but there was some collatoral damage during the upgrade including 
   - Another "brownout" of a companion IO chassis, h1susauxh56, when powering on / off the h1sush45 IO chassis.
   - Discovered that one leg of the 18 V power strip that powers a lot of the analog signal processing (AA, AI, and coil driver) chasses in the entire SUS-C8 rack (see impacted suspensions in D2100766 and the detailed contents of the rack in page 8 of D1002740)
where it's as of yet unclear if "loosing" the -18 V leg of the power strip was a result of the DAC upgrade or if we just coincidentally discovered it while in that rack. 

As the final step of changing the controls infrastructure, I loaded in the same gain of 4 filter, "20BitDAC" in FM10 of all M2 and M3 COILOUTF filters, turned them on, accepted the filters being ON in both the OBSERVE and safe SDF snap files, and committed the filter files to the userapps repo. 

Further, because we don't think 20-bit DACs *need* any preventative offsets from zero to prevent "DAC glitching" aka "zero-crossing glitches," and we saw no evidence that having them ON improved the situation even for the 18-bit DACs which we *do* think need them, I've turned OFF the offsets that Sheila just installed the other day (from LHO:64326). One less thing to have to remember for us. We're open to re-installing them, but would prefer evidence-based reasoning to do so.

See attached screnshots documenting these configuration changes.