jeffrey.kissel@LIGO.ORG - posted 12:37, Monday 01 April 2024 - last comment - 10:02, Tuesday 02 April 2024(76842)
OMC ASC Inputs to H1 SUS OMC Drive Path Has Been Doing it Wrong For Years. We Can Fix it Tomorrow.
J. Kissel, [Corroborated by J. Wright and J. Driggers] WP 11797 While upgrading the OMCS_MASTER.mdl library part for the OMC Suspension (which now lives in the h1susifoout.mdl top-level model), I found two distressing things: (1) The OMC ASC signals that are sent from the h1omc.mdl model -- running at 2kHz -- are not anti-imaged at all before being sent to the OMC SUS DAC -- running at 16 kHz. So, we're sending unnecessary imaging noise to the SUS DAC. (2) The OMC ASC L, P, amd Y signals are being sent through a filter bank that does NOT past through the DRIVEALIN matrix, rendering 2019's attempt at diagonalization (LHO:47488) unused. These bugs have been long standing. I see it now as I touch the h1susifoout.mdl and the OMCS_MASTER library part for watchdog upgrades, but I'd previously identified the issue when - I was upgrading the front-end models for O4 (i.e. when the OMC SUS transitioned from the h1susomc.mdl to the h1susifoout.mdl) in 2021 (LHO:59652), and - When we were identifying which SUS models used the broken "TrueRMS" bloick -- there's a preceding note in the simulink model that suggests this has been around since 2015 or earlier. We can fix this tomorrow, with *only* a change to the h1susifoout.mdl and OMCS_MASTER.mdl models, and we're already doing that anyways for the SUS watchdog upgrade. Attached are several series of screenshots showing: (1) The signal path from the h1omc.mdl model where the OMC ASC control signals begin, to where they land in the OMC SUS driving in the EULER basis (again WITHOUT going through the DRIVEALIGN MATRIX) (2) MEDM Screens showing that in practice we only drive L, P, and Y (as one should for an ASC signal) and we don't use T, V, or R drive and likely never will. (3) The existing filters that will need to be copied over, and the DRIVEALIGN gain values that will likely need to be re-addressed -- since effectively we've NOT been using them. Note -- I checked on how this is done at LLO, and they *do* drive through the LOCK banks and DRIVALIGN banks (BUT they don't have any anti-imaging filters in pace either, even though their ISCINF FM1 banks are ON... whoops)... So, when we change the OMCS_MASTER library part, this won't affect them.
Images attached to this report
Comments related to this report
The ASC P and Y filters in play during nominal low noise are as follows:
Bank Module Name Design String
OMC_M1_ASC_P FM0 SUSinvert zpk([0.12+i*3.85;0.12-i*3.85;0.12+i*2.18;0.12-i*2.18],[0.3+i*1.75;0.3-i*1.75],1,"n")
FM10 LP8 zpk([],[2.58028+i*3.68676;2.58028-i*3.68676;1+i*7.93725;1-i*7.93725],1,"n")
OMC_M1_ASC_Y FM0 FM1 zpk([0.033+i*0.54;0.033-i*0.54;0.25+i*3.95;0.25-i*3.95],[1.6;1.6],1,"n")
FM10 LP8 zpk([],[2.58028+i*3.68676;2.58028-i*3.68676;1+i*7.93725;1-i*7.93725],1,"n")
These might be from 2015 -- the only aLOG I can find that even vaguely discusses these filters is LHO:16402.
(Note, these are distinctly separate from the primary OMC ASC control filters that were simiplified by Dan Brown and Evan Hall in 2022; LHO:65861).
Attached are bode plots of these two filters and their products for PITCH (in RED, on the left) and for YAW (in BLUE, on the right).
Note, the FM0 plant inversion filters resolve to have notches at
Notch Freq 1st (Hz) 2nd (Hz)
P DOF 2.21 3.84
Y DOF 0.54 3.94
For comparison, I plotted the M1 [PIT,YAW] to M2 [PIT,YAW] transfer functions from the latest dynamical model from 2021 when I improved the damping loops (LHO:60049) and I get resonances at
Notch Freq 1st (Hz) 2nd (Hz)
P DOF 1.92 3.98
Y DOF 0.46 4.13
So ... maybe when we fix the infrastructrure, we should also update the plant inversion...
Images attached to this comment
Non-image files attached to this comment
LHO aLOG 76856 describes the model prep for fixes made to the h1susifoout.mdl top level part and OMCS_MASTER.mdl library part in order to fix this bug.
J. Kissel, D. Barker, P. Fritschel Model changes described above in LHO:76856 now covered under (fast-track approved) ECR E2400116 and IIET Ticket 30863, escalated to such formality because the SUS-OMC_M1_ASC_[LTVRPY]_IN1 channels *were* in the GDS broadcaster frames which is under strict ECR control. They're now replaced by OMC_M1_LOCK_[LPY]_IN1 (i.e. three less channels because TVR don't exist). After making these changes, the impacted model and library have been committed to the userapps SVN under /opt/rtcds/userapps/release/sus/h1/models/h1susifoout.mdl rev 27374 /opt/rtcds/userapps/release/sus/common/models/OMCS_MASTER.mdl rev 27375
