J. Kissel, B. Weaver

We've investigated what we could of this, but there is no aLOG evidence that these phase adjustment filters were intended to be used in the design (what's now left is the same semi-low noise design I made a few years back: see G1300537). They also don't make any sense upon first glance individually, but after staring at the design strings and names it has slowly become clear. We can also narrow down who would attempt such sophisticated trickery without aLOGging, maintaining SDF, committing filter changes to the svn repo, or otherwise cleaning up after they're done...

There are four filters that I've now cleared/completely removed from the H1SUS ETMY M0_DAMP_V filter bank:
    FM6       BS1_4        ellip("BandStop",5,1,40,1,4)
    FM7       -90deg       zpk([-9.8],[9.8],1,"n")
    FM8       +50deg       zpk([5],[50],1,"n")
    FM9       bouncetest   ellip("BandPass",4,1,55,9.5,11)gain(45,"dB")
Guessing what the intent was by the frequencies in question it looks like someone was exploring damping the highest vertical mode (a.k.a. "*the* bounce mode") from the top mass, using top mass OSEMs as the error signal. I'm not surprised it didn't work!

Potentially related aLOGs:
Corey's midnight issue on Thanksgiving: LHO aLOG 31828
My cleanup of ODC state vector Oct 25, where I blindly accepted the new state as OK: LHO aLOG 30849

The last attachment shows a trend of the filter state. The bottom trace is merely a report of the current filter state, and the top trace shows the user-entered EPICs record that is compared against when establishing whether ODC thinks there's OK status. The bottom trace confirms Sheila's suggestion that the filter bank status was changed on Oct 12th 2016 at ~16:50 UTC (which is Oct 12 2016 09:50:00 PDT).