Shivaraj Kandhasam posted in MatterMost that the EY BRS signal looked off, and had been since last Tuesday (July 22). I talked to Jim about this and indeed the velocity of the BRS was consistently very high. Jim said that it looked like it needed to grab new frames for the C code calculations. Immediately after Jim reset this, by logging into the BRS computer and clicking the "Grab New Frames" button on the GUI, the velocity slowed down and it was quickly brought back to a normal realm.

I trended this back and it's happened a few times, most recently from May 21-June 5. To catch this next time it happens again, I've done two things:

1. Lowered the threshold that the BRS{X,Y}_STAT nodes use before moving into their DAMPER_ON_HIGH_VEL state. When these nodes go to this state, then the ST1 ETM sensor correction nodes will remove the BRS corrected signal from sensor correction, since it assumes that the sensor is not in a reliable state. The velocity during the corrupted frame times tends to be +/- 3600 or so, so I changed the threshold from 10000 to 6800. We rarely get above this value, and when we do it's from maintenance activities, very large earthquakes, or extreme wind to the point where locking isn't happening anyway. This is commonly shared code, so I had to check that this value would work for LLO as well. I've only been able to go back a week or two though before I was running into data issues. I'll double check this with LLO then coordinate with them to update the value if desired.
2. Added a test in DIAG_MAIN to watch the BRS{X,Y}_STAT nodes and if they are in the DAMPER_ON_HIGH_VEL state for more than 6 hours consistently, then it will notify. This should be enough time to let large earthquakes ring down and allow for a dip in extreme winds to reset the timer. This test is not common, but LLO can copy if they so choose.