J. Freed,

I took Phase noise measurements of the 2 channel Keysight 33600A waveform generator for its use in building SPI Pathfinder in the optics lab before install. Going only off of the phase noise graphs, it is sufficient as it shows comparable results to the SRS which had a phase noise considered to be good enough for SPI pathfinder.

Key.png Shows the phase noise results. C1, C2 are the phase noise results for Channel 1 and Channel 2 on the Keysight, respectively. (Set up shown below). Shown for comparison the SRS SG392, which was suggested as a possible frequency source for SPI. The last measurement shown is the direct measurement of phase noise between the 2 channels of the Keysight. This measurement reflects the intended use case of the Keysight for SPI. As we need 2 frequencies at slightly different frequencies locked to each other and SPI will be measuring the output phase difference. Note the 60Hz peak; most likely caused by unclean AC power. This is why we are not using an AC powered device in the final installation. 

Screenshot2025-12-01at50150 PM.png Shows the setup for C1, and C2. measurements. The SRS value was found with the same set up, just replacing the Keysight 33600A with a SRS. The C1-C2 is a direct measurement by plugging both channels into the BluePhase 1000. There is no 10MHz Ext back attachment in this measurment in order to best represent Keysight's theoretical performance in the optics lab.

TITLE: 12/02 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY: Busy day upgrading DAC cards at EY. After suspensions were recovered, we wanted to relock the IFO to ensure the new DACs haven't introduced a problem, so I started an initial alignment. Unsurprisingly, ETMY and TMSY needed quite a bit of adjustment, but otherwise alignment went smoothly. Locking the IFO presented a couple of issues; after DRMI locked, I needed to turn of the SRC1_P loop as it appeared to be pulling alignment away. I turned this off again during ENGAGE_ASC_FOR_FULL_IFO as it appeared to be misbehaving for the second time. Eventually H1 lost lock during MOVE_SPOTS, but we're unsure as of yet what the cause was. H1 is attempting to lock again under the supervision of a few folks still here in the control room.
LOG:

Richard, Jonathan, Fil, Marc, Daniel, EJ, Jeff, Oli, Ryan S, Dave:

h1susey was upgraded from Gen Std DACs (3x18bit, 2x20bit) to 2 LIGO-DACs.

Fil upgraded the three AI chassis to use the new SCSI interface board.

We removed the old Gen Std DACs and installed the two new LIGO-DACs.

The first LIGO-DAC drives the first standard AI, which in turn daisy-chain drives the second standard AI.

The second LIGO-DAC drives the special PI AI chassis.

After the hardware was changed the new h1iopsusey, h1susetmy, h1sustmsy and h1susetmypi models were rev-lock built and installed. A common model change for h1susetmy was accepted for its build.

EJ did a custom build for h1iopsusey due to rev-update issues found for watchdog source files. The user models were built with the production RCG-5.5.2

Following the model starts, the DAQ was restarted for new INI files due to removed DACs in h1iopsusey and h1susetmy.

Jeff, Oli

Since the ETMY and TMSY electronics are now on 32CH, 28-bit DACs, we needed to add a calibration term that would account for the difference in bit count between the old and new DACs. The normal thing to do for these DAC upgrades is to add a gain in the COILOUTF filter banks that was gain(2^(NewBitCount-OGBitCount)). For example, during the conversion of ETMY L1/L2/L3 from their original 18-bit DACs to 20-bit DACs, the calibration was altered by the addition of a filter in their respective COILOUTF banks that was gain(4), since 2^(20-18) = 4.

This time, we needed the change in gain to be between the new bit count, 28, and the original bit count, 18, so gain(2^(28-18)) = gain(2^10)=gain(1024). These filters were added into the FM10 slot of ETMY_{M0,R0,L1,L2,L3}_COILOUTF and TMSY_M1_COILOUTF. In the case of ETMY L1/L2/L3, these gains overwrite the previous 20bitDAC filters since we don't need those anymore.

The other place where we needed to add these conversion filters was for ETMY PI, and even back in May 2025 Jeff had noticed that we had never added in any compensation for the 18-20-bit DAC upgrade (84522). To finally follow through on fixing that we added filter banks into the PI model (88285), which for ETMY PI are called H1:SUS-ETMY_PI_UPCONV_ESDOUTF_LF and H1:SUS-ETMY_PI_UPCONV_ESDOUTF_RT, and I added filters into FM10 for each that had that same gain(1024) in them. I also added these new filter banks to the PI medm screen (screenshot).

All these filters were loaded in, turned on, and accepted as on in safe sdf. We slowly turned everything back on, and it all looks to be working correctly.

Mon Dec 01 10:08:07 2025 INFO: Fill completed in 8min 3secs

J. Kissel, O. Patane
ECRs: E2400409 and E2500296
IIET: 35739 and 35706, respectively
WP: 12901
DWG: D1002741

After 
- Adding/updating DAC calibration compensation gains
- Updating MEDM macros in order to confirm that DAC drive requests made it all the way out to the analog world on the right channels
- Pausing guardians to make sure they didn't take control when we didn't want them to yet,
- Making sure that all DAC requests were OFF
- Untripping watchdogs and turning ON the MASTER SWITCH
- Turning on small offsets to confirm those channel pathways were straight and linear,
- Turning damping loops, one DOF at a time to confirm function and that they had roughly the right ~few second ring-down time
- Turning on the alignment offsets to confirm that the whole suspensions move
- Restoring all nominal ability for ISC output requests by resuming the guardian and running it from SAFE to ALIGNED a time or two,
- Initiallizing new channels in SDF
- Accepting differences in SDF (almost entirely the turning ON of calibration gains for the stages that were 18-bit DACs)

We turned control over to the operations team with the words "all EY suspensions are confirmed functional and ready to use" at Dec 01 2025 ~15:45 PST (after having started at ~08:30 PST this morning; LHO:88274).

[JeffK, Jenne]

Jeff pointed out that the PI damping gain (if no changes were made to guardian) would now be 4x higher than they were throughout O4, due to the work done today.  See alog 88285 for the actual work by Jeff and Oli.  To account for this, the SUS_PI guardian now has a 1/4 in the gain setting line.

Details for remembering later:

In June 2020, we upgraded from 18-bit to 20-bit DACs, and as Jeff notes in alog 88285, we didn't have a place to nicely account for the effective gain change digitally in the PI damping path.  Effectively, we should have put in a filter with gain of 4x to account for the number of bits changed.  Since we didn't, we have been actuating PIs (assuming same digital gains) 4x less during O4 than we had been in O3.  Not a huge deal, since we had PI dampers and PI damping settings that were effective. 

With today's work, Jeff and Oli have put in a digital place to correctly account for the gain change with the new 28-bit DACs.  To keep the 'accounting' neat and tidy, they've put in the whole correction gain from 18-bit to 28-bit (not just 20-bit to 28-bit).  This means that they've put in the forgotten-during-O4 gain of 4x, so if things were left alone in the SUS_PI guardian, we'd be sending 4x actuation strength to the ETMs.  In O4, the 4 PI modes we've been damping have only gone to the ETMs.  Since we don't have automatic gain adjustment in the PI damping guardian, I've divided the gain setting line by 4 in SUS_PI, so that we'll end up with the same actuation strength now as we did have in O4. 

J. Kissel, O. Patane
ECRs: E2400409 and E2500296
IIET: 35739 and 35706, respectively
WP: 12901
DWG: D1002741

Oli was working their way through adjusting the SUS "OUTF" FM10 blocks that are traditionally used to adjust the calibration of the DACs being used, and we re-realized that we've never had a place in the PI model to adjust the DAC gain thru the upgrades from 18- to 20-, and now 28-bit DACs -- see the original discovery back in May 2025 (LHO:84522, which quotes that ETMY's PI DAC had been misalibrated by a factor of 4x since Jun 2020).

In that May 2025 aLOG, I "mildly advocated" for an implementation of ESDOUTF banks like there is in every other SUS drive chain. 
Today, I implemented that change, since (a) the gain difference between a 18-bit and 28-bit DAC is now a factor of 2^10 = 1024x -- much more noticeable, and (b) it's a total no brainer change that's easy to do while we're already restarting this model for the DAC upgrade proper.

The update to the library, 
    /opt/rtcds/userapps/release/sus/common/models
        PI_MASTER_V2.mdl          r26600 --> r34033
is within the ETM_UPCONV_V2 block, which I show in the attached BEFORE vs AFTER.

We have compiled, installed, and restarted h1susetmypi front-end model so that it has this minor change.
Oli will aLOG the installation of the gains.

J. Kissel, D. Barker

As an inadvertent result of us using the new "rev lock" RCG feature during the build of front-end model h1susetmy, we discovered that there was a newer revision of the sub-sub library part used within the QUAD_MASTER library part -- 
    /opt/rtcds/userapps/release/sus/common/models/
        ESD_LINEARIZATION_WITH_CHARGE_MASTER.mdl : r16336 --> r30316
where the latter text shows the userapps svn repo version that the h1susetmy model was last compiled with, and what it will be compiled with if we use latest rev of the model (r34028, see LHO:88282).

The ESD_LINEARIZATION_WITH_CHARGE_MASTER.mdl is *actually* a library, i.e. it contains a library of library parts that can be used for linearization.
One is the ESD_LIN_CHARGE_MASTER, and the other is ESD_LINE_CHARGE_GENERIC_MASTER.

We're 100.0% confident that the h1susetmy, which uses QUAD_MASTER, uses the ESD_LIN_CHARGE_MASTER block, that's poorly commissioned and has its settings configured to not use it.
We're 98.5% that r16336 --> r30316 update to the library is the creation and commissioning of the other ESD_LINE_CHARGE_GENERIC_MASTER block, given Dec 2024 LLO aLOGs like LHO:74555 and 74771. The 1.5% lack of confidence is only that it's challenging to follow LLO's QUAD front-end model's references to libraries.

Anyways -- this is just to say explicitly that we're going forward with using this r30316 version of the library, but it won't change any function or form of the h1susetmy model.

D. Barker, J. Kissel, O. Patane
ECRs: E2400409 and E2500296
IIET: 35739 and 35706, respectively
WP: 12901
DWG: D1002741

Following the solidifying of the wiring plan / IO chassis layout (see LHO:88276), Dave did the lion's share of updating the front-end USER models in prep to the 28-bit 32CH upgrade. I merely reviewed it to make sure we understood all the moving pieces and that the connections to the analog world made sense, and am documenting it here.

Recall -- although the wiring diagram -v11 had shown all 20-bit DACs, in order to best reflect the 2022 ideal as of 
    - TST stage :: ECR E1800306 / IIET: 11689,
    - PUM stage :: ECR E1900216 / IIET: 13232
    - Everything else :: ECR E2100485 / IIET:20828, 
but H1 had not yet achieved that ideal, as we instead put our money toward developing and waiting for the 28-bit 32CH DACs. As such, in the "BEFORE" shots, you'll see the reality of the mix of 18-bit and 20-bit DACs. In short, the QUAD TOP (M0 and R0) and TMTS TOP (M1) had not yet been upgrade to 20-bit DACs. So those stages now "skip a version" and go straight to 28-bit 32CH DACs (D2200368).

Attached are screen-shots of the DAC section of the user models BEFORE vs. AFTER:
    - h1susetmy BEFORE vs. AFTER
    - h1sustmsy BEFORE vs. AFTER
    - h1susetmypi BEFORE vs. AFTER

I also include a view of the 28-bit 32CH DAC card usage from each model that uses it; a view which better shows the consumption of channels by function across USER models.
    - DAC0 AFTER
    - DAC1 AFTER

This view helps identify some index / naming convention issues with DAC1 (see DAC1 usage screenshot). This DAC controls *only* the TST stage ESD, but spans the h1susetmy and h1susetmypi USER models. In both the susetmy and susetmypi models, the card_num parameter is set to 1 (one). HOWEVER, because the h1susetmy model uses both of the new two DACs (card_num=0 and card_num=1), the card_num=1's block name is DAC_1. In h1susetmypi which only uses the second card (card_num=1 ), it's block name is DAC_0. 
It's confusing when you look at it like this, and the RCG (current) forces it to be this way because of IO chassis which have mixed DAC card types (unlike ADCs, which the RCG will happily accept cherry pick ). The solution will be as it has been -- update the MEDM macro files that support the user interface, such that we get the UI showing the signal flow through the USER model output and IOP model output without folks having to think about it.