J. Kissel A few weeks ago, my LHO aLOG 64114 showing the comparison actuator noise for HSTSs with only their middle stage (M2) triple-acquisition (TACQ) coil driver modified vs. have both middle (M2) and bottom (M3) stages re-opened the debate as to whether we should downgrade the modification to the M3 stages of SR2 and SRM. However, in passing, our attention was piqued elsewhere -- regardless of the M2 / M3 driver choice -- the model also showed that the P and Y DOFs were dominated by TOP Mass (M1) stage actuator noise -- dominated by DAC noise. That, coupled with the newly available updated ISI models from CSWG aLOG 11236 drove me to dive in to where and how that actuator noise was computed, since my modeling infrastructure really hasn't been touched in that department since 2013. So, I attach two new model sets, both with updated DAC noise models (using E1800243) and updated HAM ISI input models: (1) The H1 SUS SR2 model, which uses - The H1 HAM5 ISI performance model, - 18-bit DAC noise for the M1 stage, - 20-bit DAC noise for the M2 and M3 stages BUT - both the M2 and M3 stages have the modified TACQ driver, and, (2) The H1 SUS FC1 model, which uses - The H1 HAM7 ISI performance model, - 20-bit DAC noise model all three M1, M2, and M3 stages BUT - the M2 or M3 stages TACQ drivers are unmodified, All drivers have their noise computed in the lowest noise switchable state (LP's on and ACQ's off). Both models have my "level 2" improvement in the damping filters, and don't represent the current reality of the damping filters and thus the reality of the BOSEM noise reinjection. However, I'm now much more confident in my ability to install these filters and to have the system be stable without impacting the ISC controls that I was in 2014, or even 2019, so I would be game to install these, if others are. Here're the conclusions from this model set: (a) Indeed, for both SUS, even with a 20-bit DAC, the top mass actuator noise dominates P and Y below ~3 Hz, with the next noise source being an order of magnitude or more away. (b) The statement (a) holds true even if we upgrade the M1 stage to a 20-bit DAC. (c) Even after updating the actuator noise prediction, I found that the 18-bit DAC noise TOP mass driver was consistent with the 2013-2014 noise model, so the LHO aLOG 64114 values for the TOP mass actuator noise are virtually identical. (d) Assuming we're not limited in doing so by how much actuation range we need, we should really consider modifying the frequency response of the Triple TOP driver. (e) Confirming (c) likely means the HLTS (SR3 / PR3 like suspensions) noise model from their level 2 damping filter design (LHO:7907) is correct, and pages 38 and 45 of dampingfilters_HLTS_2013-07-10.pdf show that the HLTSs are *not* limited by the top mass actuator noise at low frequency, in contrast to the HSTSs. (f) The HAM-ISI performance no longer limits any of DOF at any frequency. In most cases, it's *well* bellow the other noises. Great job SEI team! Just keep doing what you're doing. (i) Improving the Vertical CPSs, which reduce table pitch, which reduce table X, which reduces SUSPOINT L takes the ISIS contribution from "a factor of a few" below the BOSEM sensor noise to "almost an order of magnitude below" the BOSEM sensor noise between 1 and 10 Hz. Is this ammo to *not* improve the HAM5 (and HAM4) ISIs in this way, since it won't make a difference in the Optic's displacement? Maybe. (ii) One of the open questions has been about whether the HAM7's Rigid External Support Structure resonances around ~40 Hz will be bad for the filter cavity. That answer is definitively "No." Even with a 20 bit DACs, and an unmodified TACQ drivers on the M2 and M3 stages (as is the case for FC1), the those stages actuator noise, and the BOSEM noise far exceed anything one might see from the RESS resonances.
Arnaud asked: "I see that there is improvement in the top mass actuator noise when converting the top mass DAC to a 20-bit DAC when comparing the total budget of FC1 and SRM, but the HAM-ISI performance also changes for the better, so it's difficult to make the statement of how much improvement an 20-bit DAC would make for a suspension on a HAM5-like ISI. Can you make a plot where you don't change the ISI performance, but improve the top mass DAC?" Yep! Here's the same collection of plots for an imaginary H1 SRM, where: - The ISI performance is using the H1 HAM5 estimate; same as SR2 - I've "upgraded" the top mass DAC to a 20-bit DAC But also, I couldn't resist asking another question: "What if, using a 20-bit DAC, we reverted the M3 stage TACQ driver, but not the M2 stage TACQ driver?" like I was originally budgeting when I asked the question in LHO:64114, but in *that* aLOG, I was still using the 18-bit DAC noise. So for this imaginary SRM, - I've "reverted" the M3 stage TACQ driver to the unmodified, lower range version. Now it's worth comparing all three budgets: :: SR2, - HAM5 ISI seismic input - Both M2 and M3 TACQ drivers modified for increased actuation strength (and thus higher DAC noise injection) - 18-bit, 20-bit, and 20-bit DACs driving M1, M2, and M3 stages, respectively. :: SRM, and - HAM5 ISI seismic input - Only M2 TACQ driver modified for increased actuation strength (and thus higher DAC noise injection) - 20-bit, 20-bit, and 20-bit DACs driving M1, M2, and M3 stages, respectively. :: FC1, - HAM7 ISI seismic input - All lower stage drivers with the original, lower range, lower noise response - 20-bit, 20-bit, and 20-bit DACs driving M1, M2, and M3 stages, respectively. depending on who's asking what question :-).
Note that all the LLO SUS front-ends will only have 20-bit DACs for O4 - we only have l1sush2b, l1sush34, l1sush56 left to do
Here's a diatribe on the code infrastructure to generate the above plots. The top level scripts to create these noise budgets -- along with ~60 other plots that help aide the damping loop design -- are as follows: ${SusSVN}/trunk/HSTS/Common/FilterDesign/Scripts/ design_damping_HSTS_20221005_H1FC1_Updated_DACandISI_Noise.m design_damping_HSTS_20221005_H1SR2_Updated_DACandISI_Noise.m design_damping_HSTS_20221005_H1SRM_Updated_DACandISI_Noise.m These scripts all have identical damping loops, all based on the original 2014 Level 2 from G1401290 damping loop design, BUT there are several improvements / changes to the filters: (1) I include some representative bounce and roll notch filters to more accurately represent their phase loss in the loop performance. Each of these filters are individualized for each suspension, and are already present (so no need to include the particular BR_V or BR_R filters in these scripts, just use what's already there in FM9 there). (2) Now that I better understand how to accurately implement the modeled gain, I've re-jiggered the gain allocation in the filter banks. this way we can have the aesthetically pleasing "-1.0" gain as the exposed gain, and have the gain for each DOF be called out in a "gain_DOF" filter as has now become convention. (3) The only overall filter that's different from the Level 2 design is the Roll filter. I've tried to mess with the Roll DOF's filter to see if I could better reduce the M2 and M3 ring-down times for the 1.5 Hz second roll mode, which have been huge since that 2014 design but had otherwise been lost in the details. I was unsuccessful -- that deserves a whole separate aLOG, and I will. In addition to the slightly modified loop design, having to understand and quadruple check the actuator noise led me to have to modify a lot of the functions that these "designdamping ..." scripts call. Here's a list of those functions, their purpose, and what's changed. - ${SusSVN}/trunk/HSTS/Common/FilterDesign/Scripts/plothstsdampingcontroldesign.m : Function: this is the main script that ingests an arbitrary damping loop design, and creates all of the loop design metrics, including the noise budgets that I've pulled out an shown in the main aLOG. Change: Screwed around with the H1 optic cases to allow for for the various combinations of DACs vs. coil drivers. Added DAC information and coil-driver type info to legends of actuator noise predictions. Added plots of global control transfer functions for all 6 DOFs, not because we're going to globally control roll, but because I wanted to understand why I can't design a loop that kills the 1.5 Hz Roll mode. Also added the undamped transfer functions to the global control plots. - ${SusSVN}/trunk/HSTS/Common/FilterDesign/Scripts/plothstsactuatornoise.m : Function: a sub-function of the overall dampingcontroldesign function that computes actuator noise. Change: Added ability to sub out all the various options for DAC noise curves from E1800243, since old NB code had hard coded in the 18-bit DAC noise model. The required creating a new function listed below. - ${SusSVN}/trunk/Common/MatlabTools/updateddacnoise.m: Function: A very specific function to replace the DAC noise from Chris Wipf's collection of noise curves pre-computed from LISO in the ${NBSVN}/trunk/Dev/SusElectronics/matlab/NoiseData/, with a 16, 18, or 20 bit DAC noise, and then pass it through the requested coil driver function from make_OSEM_filter_model.m. - ${SusSVN}/trunk/Common/MatlabTools/make_OSEM_filter_model.m: Function: This is the giant dictionary of sensor properties, sensor electronics, and coil driver electronics transfer functions that I maintain where you give it a suspension type, and the isolation stage of that suspension, and in what switchable frequency response state you want its coil driver, and it returns all the properties and transfer functions of that stage. Change: this function is by no means perfect, and I always have to double and triple check its output. Usually, for coil drivers, I check it against LLO aLOG 4495, which is the best thing we have that summarizes all the possibilities for all the original aLIGO coil drivers. Today, I found that when I asked for a modified TACQ driver from the M3 stage of the HSTS, it gave me an unmodified TACQ driver instead. Yuck! Now that's fixed. - ${SusSVN}/trunk/Common/MatlabTools/seisHAM.m Function: Produces the HAM ISI model input motion. Change: Added the H1 HAM5 and H1 HAM7 models as discussed in CSWG aLOG 11236.