Attached are pictures of where the CO2 alignment lasers are hitting near the CPs. Neither look well centered, but it's tough to say since the cloth is held a bit away from the CP and is coming in at an angle. We also don't know where these alignment lasers were hitting before the vent. The TCSX alignment laser was going nicely through the iris, but for TCSY I had bumped one iris during the water line swap (alog90234) bumping it down. 

Both alignment lasers look to be hitting the optic, so I think at this point we will just plan to use the HWS to make any moves with the CO2 once we are closed up and pumped down. 

In the two attached pictures, the bright spot is the oplev, the alignment laser is the faint cross pattern.

I finally got around to doing some slight alignment tweaks this morning following the power outage and PSL recovery a bit over a week ago.

I started with the remotely-controlled picomotors upstream of the PMC to touch up its input alignment with the ISS off:

• TRANS start: 102.6 W
• TRANS end: 103.3 W
• REFL start: 28.5 W
• REFL end: 28.0 W

Some improvement here, but I couldn't quite get the transmitted power back up to the >104 W level it was before the outage. Perhaps amplifier pump diode currents need to be adjusted, or some more invasive alignment tweaks are needed. I then turned the ISS on and adjusted the RefSignal to bring the diffracted power percentage back up to 4% from around 3%, and proceeded with RefCav adjustments:

• TPD start: 440 mV
• TPD end: 490 mV

Again, good improvements, but the highest I've seen this signal get in recent memory is around 550 mV, so the FSS path may need a full tune-up sometime. Not completely surprising, as it's been a while since the last one.

Attaching a screenshot of the quad display after my adjustments for posterity.

Camilla Sheila

Pre door close suspension transfer function health check (taken while ISI was locked) measurements looks good. Oli Took IM1-4 (LHO alog 90579) and they look healthy as well.

I will process and post the results later on, the templates are stored at the following location (given below).

/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/MC1/SAGM1/Data

2026-06-11_1600_H1SUSMC1_M1_WhiteNoise_L_0p02to50Hz.xml
2026-06-11_1600_H1SUSMC1_M1_WhiteNoise_P_0p02to50Hz.xml
2026-06-11_1600_H1SUSMC1_M1_WhiteNoise_R_0p02to50Hz.xml
2026-06-11_1600_H1SUSMC1_M1_WhiteNoise_T_0p02to50Hz.xml
2026-06-11_1600_H1SUSMC1_M1_WhiteNoise_V_0p02to50Hz.xml
2026-06-11_1600_H1SUSMC1_M1_WhiteNoise_Y_0p02to50Hz.xml

/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/MC3/SAGM1/Data

2026-06-11_1630_H1SUSMC3_M1_WhiteNoise_L_0p02to50Hz.xml
2026-06-11_1630_H1SUSMC3_M1_WhiteNoise_P_0p02to50Hz.xml
2026-06-11_1630_H1SUSMC3_M1_WhiteNoise_R_0p02to50Hz.xml
2026-06-11_1630_H1SUSMC3_M1_WhiteNoise_T_0p02to50Hz.xml
2026-06-11_1630_H1SUSMC3_M1_WhiteNoise_V_0p02to50Hz.xml
2026-06-11_1630_H1SUSMC3_M1_WhiteNoise_Y_0p02to50Hz.xml

/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data

2026-06-11_1700_H1SUSPRM_M1_WhiteNoise_L_0p01to50Hz.xml
2026-06-11_1700_H1SUSPRM_M1_WhiteNoise_P_0p01to50Hz.xml
2026-06-11_1700_H1SUSPRM_M1_WhiteNoise_R_0p01to50Hz.xml
2026-06-11_1700_H1SUSPRM_M1_WhiteNoise_T_0p01to50Hz.xml
2026-06-11_1700_H1SUSPRM_M1_WhiteNoise_V_0p01to50Hz.xml
2026-06-11_1700_H1SUSPRM_M1_WhiteNoise_Y_0p01to50Hz.xml

/ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Data

2026-06-11_1800_H1SUSPR3_M1_WhiteNoise_L_0p02to50Hz.xml
2026-06-11_1800_H1SUSPR3_M1_WhiteNoise_P_0p02to50Hz.xml
2026-06-11_1800_H1SUSPR3_M1_WhiteNoise_R_0p02to50Hz.xml
2026-06-11_1800_H1SUSPR3_M1_WhiteNoise_T_0p02to50Hz.xml
2026-06-11_1800_H1SUSPR3_M1_WhiteNoise_V_0p02to50Hz.xml
2026-06-11_1800_H1SUSPR3_M1_WhiteNoise_Y_0p02to50Hz.xml

WP13322. This morning Fil set up the HAM6 High-Voltage Bypass from the CER and then verified that the fast shutter was charged and energized.

This is for SQZ work, when sending the SQZ beam towards HAM5/6 into the OMC, we need high voltage supplied to the fast shutter and OMC PZT in HAM6.

Ibrahim, Oli

Yesterday afternoon the BS was unlocked in chamber and Ibrahim took transfer functions. They look great and everything looks like it did in the test stand.

Settings
- HEPI Locked
- ISI Locked
- DAMP OFF
- OPTICALIGN sliders OFF

Data
/ligo/svncommon/SusSVN/sus/trunk/BBSS/H1/BS/SAGM1/Data/2026-06-10_1700_tfs/2026-06-10_1700_H1SUSBS_M1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz.xml
Results
/ligo/svncommon/SusSVN/sus/trunk/BBSS/H1/BS/SAGM1/Results/2026-06-10_1700_tfs/2026-06-10_1700_tfs/2026-06-10_1700_H1SUSBS_M1_ALL_TFs.pdf
r13035

TITLE: 06/11 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 3mph Gusts, 1mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.10 μm/s 
QUICK SUMMARY:

Expected work today: 
SPI crew is out, and laser safe.
More BSC2 HEPI actuator work. 
Final ISI unlock perhaps?
CRS Chamber side testing?  
BSC2 & HAM3 in chamber work 
TCS HeNe alignment check in BSC1&3
Crane CRS+ table to HAM3 
CRS cable runs.
BBSS model up ? 

WP13311 Check 20it-DACs

Summary of work done as part of the 20bit-DAC issue discovered last week by Sheila when driving FC1 in HAM7. Not all channels of the first 20bit-DAC have been driving since the 13apr2026 upgrade of h1sush7 timing-card firmware, TC-sync-ribbon and RCG5.5.0 to RCG5.5.2.

We have 4 more frontends with 20bit-DACs in the same configuration as h1sush7, they are: h1susb2h34, h1cdsh8, h1oaf0 and h1iscex.

We have been unable to reproduce this issue on the test stand (x7eetest1).

On Tuesday 09jun2026 we investigated the status of h1oaf0's 20bit-DAC and on Wednesday 10jun2026 h1iscex.

-----

h1oaf0: Tue 09jun2026.

The first 20bit-DAC has all 8 channels driven by the h1pemcs model. We used this model to drive the DAC for our tests. This DAC has a "CAL" Anti-Image chassis, each channel has a single ended BNC and a DB9 differential output.

We labeled and disconnected the field cables from the AI for ch0,1,2,3,4,6 (BNC) and ch7 (DB9). Ch5 was not being used.

We drove all 8 channels to 5.0V (262144 counts) and DVM'ed all the channels, no drive on any channel. Note this differs from h1sush7's test Tue02apr2026 where its ch7 DAC-DUOTONE was working but the others were not.

This gave us the opportunity to carefully test each change made on 13apr2026 to narrow down which change caused the issue.

Replace 20bit-DAC: First we replaced h1oaf0's DAC (S2101135) with the one tested on x7eetest1 (S2101117). BROKEN.

Install original Sync Ribbon Cable: replaced the upgraded sync ribbon (with the 2 wire shift) with the original pin-for-pin cable. BROKEN

Install new Sync Ribbon Cable backwards: we put the new ribbon back in, but connected it backwards. BROKEN

No Sync Ribbon Cable: ran with no ribbon cable. BROKEN.

we put the new ribbon back in correctly. Problem does not appear to be related to this cable in any way.

Shift all Cards Left: We then applied the "h1sush7 fix" which is to move all the cards left one slot, moving the 20bit-DAC from A1-4 to A2-1 in the process. NOW WORKING.

Move 20bit-DAC back: With all the other cards still moved left, we returned the 20bit-DAC back to its original slot (A2-1 to A1-4). BROKEN

Downgrade RCG: Erik downgraded all of h1oaf0's models from RCG5.5.2 to RCG5.5.0. BROKEN

Shuffle cards on Adnaco A1: Next the order of the cards on A1 was shuffled

From

To

BROKEN

We put the cards back into their original order.

Downgrade timing card firmware: The timing card was replaced with one programmed with an older version of the firmware (S2101153 with 0x2f4). NOW WORKING.

Upgrade timing card firmware: Marc upgraded the timing card using the JTAG port from 0x274 to 0x635. BROKEN

At this point we a definitive proof that it is the timing card firmware upgrade to 0x635 which breaks the 20bit-DAC. As you can imagine, there has been a lot of discussion between CDS and EE on how this could possibly be the case and we are still mystified.

At this point it appears moving the DAC from A1 to A2 fixes it, but with no insight into the mechanism this is purely empirical. It might be better to downgrade the timing card firmware for systems which do not need the new firmware (i.e. LIGO-DAC and OMC) to the O4 version 0x1f0.

-----

h1iscex: Wed10jun2026

the first 20bit-DAC is driven by two models, h1pemex drives ch0-3, ch4 is unused, h1calex drives ch5-6 and ch7 is driven by the IOP with the DAC-DUOTONE (which is permanently enabled).

We can remotely confirm that the DUOTONE signals in ch6,7 are working. Also Tony confirmed the PCAL chn5 is also working.

At EX, I labeled and disconnected the AI cables. I then connected ch0-3 with BNCs to the PEM-AA chassis for ADC4 ch0-3. I was then able to remotely drive the DAC channels and view the output. I drove with a 0.5V signal, since the PEM-AA has a x10 gain. The ADC recorded a 5V signal on all channels.

All channels on this 20bit-DAC are working. Only ch4 was untested since no model drives this channel. We decided no further investigation of h1iscex is needed.

The field cables were restored, h1pemex's filtermodules used for this test were restored to their original settings.

A plexi security cover was installed over the SPI Laser Chassis. Cover will be locked under normal operating conditions.

While working with Patrick today to deploy an updated IOC packaged in a container we found a problem resolving external hosts in DNS.

After some debugging it was traced down to DNS routing through a container health network that is an internal network.  The health network is an internal network as in not publically accessible, however marking it internal to the container system removed the egress route.  After I reconfigured the network to set internal=false it was able to properly lookup external hosts.

Notes for my future self.  When deploying containers using quadlets on Debian 13, the following is needed to reconfigure a podman network named NET (you must work through podman and systemd, and differing suffix/prefixes are added).

1. stop the systemd service:  systemctl stop NET-network

2. delete the podman network: podman network rm systemd-NET

3. reconfigure the NET.network file (in /etc/containers/systemd for system level networks)

4. systemctl daemon-reload

5. systemctl start systemd-NET

You can also do systemctl cat systemd-NET to verify that its parameters are correct.  Then podman network ls, podman network inspect to check on its full status.

Took some transfer functions of IM1, IM2, IM3, and IM4 now that HAM2 work is basically over. They all look good, even though a couple degrees of freedom (specifically L) don't have the best coherence due to not being able to drive too much in air without saturating

Settings
- ISI Locked
- DAMP OFF
- OPTICALIGN OFF

IM1
Data
/ligo/svncommon/SusSVN/sus/trunk/HAUX/H1/IM1/SAGM1/Data/2026-06-10_2200_H1SUSIM1_M1_WhiteNoise_{L,P,Y}_0p02to50Hz.xml
Results
/ligo/svncommon/SusSVN/sus/trunk/HAUX/H1/IM1/SAGM1/Results/2026-06-10_2200_H1SUSIM1_M1_ALL_TFs.pdf
r13029

IM2
Data
/ligo/svncommon/SusSVN/sus/trunk/HAUX/H1/IM2/SAGM1/Data/2026-06-10_2210_H1SUSIM2_M1_WhiteNoise_{L,P,Y}_0p02to50Hz.xml
Results
/ligo/svncommon/SusSVN/sus/trunk/HAUX/H1/IM2/Results/2026-06-10_2210_H1SUSIM2_M1_ALL_TFs.pdf
r13030

IM3
Data
/ligo/svncommon/SusSVN/sus/trunk/HAUX/H1/IM3/SAGM1/Data/2026-06-10_2210_H1SUSIM3_M1_WhiteNoise_{L,P,Y}_0p02to50Hz.xml
Results
/ligo/svncommon/SusSVN/sus/trunk/HAUX/H1/IM3/Results/2026-06-10_2210_H1SUSIM3_M1_ALL_TFs.pdf
r13031

IM4
Data
/ligo/svncommon/SusSVN/sus/trunk/HAUX/H1/IM4/SAGM1/Data/2026-06-10_2250_H1SUSIM4_M1_WhiteNoise_{L,P,Y}_0p02to50Hz.xml
Results
/ligo/svncommon/SusSVN/sus/trunk/HAUX/H1/IM4/Results/2026-06-10_2250_H1SUSIM4_M1_ALL_TFs.pdf
r13032

This was done on Tuesday, but is being recorded after the fact.

As per WP 13275 h1daqnds3 has been configured as a standalone edc/frame writer/nds1 for the H0:VAC channels.  This is in preperation for CDS upgrades in the next few months.  It will give the vacuum group a view of the H0:VAC channels that should not be interupted by CDS upgrades.

J. Freed, J. Kissel, J. Wright, T. Sadecki, TJ, Shaffer,

Continuing from 90558 (Notes are stored here).Today we completed all of the outside optical fiber install, Feedthrough install, as well as BnK Hammer of ISIK. 

We also had some trouble connecting to the picomotors through CDS but Fil and Co. seems to have fixed the issue.

In order we did:

• BnK Hammered the assembly to confirm secure to ISI and resonances are sufficiently high (~200Hz)
• Finished last PD and Pico bus cable connections to D6 feedthru
• Installed D4 feedthrough pannels
• Installed in chamber fibers but still need to be routed and respooled
• Checked and installed the fiber optic chain from PSL through SPI prep to the HAM 3 D4 feedthrough. This includes
  • SPI Prep mointor channel checks.
  • Optical network power budget (will be added to a separate alog).

TITLE: 06/10 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 11mph Gusts, 5mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.12 μm/s 
QUICK SUMMARY:
SPI Is Shutters and Shutdown, they did not and are not going Laser Haz. So the LVEA remains in LASER SAFE / Bifuircated @ HAM7.
But a lot of work was done for SPI today. 
The cable for the TCS Pico drivers was changed out by fil for the SPI team.

Dave wanted to do a DAQ restart for CRS but ran into Model issues and postponed until tomorrow.
Jonathan is restarting some IOCs for Dave and Patrick's  work.

HAM2 TF were taken after Fil completed Ground Loop checks.
Alignment of Hepi was blocked by potentially metal on metal touching. Jim is contemplating his options.

Fist contact of ITMY completed today. Please see tear off in Control room. 

GRB-Short E64093 @ 23:46 UTC

And all the SUS in HAM2 have been set back to Aligned. 

Ryan, Jason, TJ, Mitch, Jim

Following yesterdays work, Jason and Ryan got new numbers for the alignment of BSC2 this morning, we overshot X by ~.75mm and still needed to rotate RZ by 900mrad. This afternoon, the five of us went to the chamber and made more moves, I think we are very close to done now.

However, I realized when we went back out, that we had collided the -X crossbeam into one of the spring caps on the -X/-Y corner of the chamber. We had just contacted this spring cap, which had already been ground down a tiny bit during the original install. This is on a non-critical part of the spring cap, so I think I will just grind the cap down a little bit more, so we have more like 1mm clearance instead of the .1mm clearance we have now. This will require putting hepi back fully on stops so I can take the load off both springs in this corner and remove the spring cap. This should hopefully be the last major surgery for alignment on the outside. We should be able to start attaching actuators tomorrow, late morning or after lunch.

Mitch, Jim

This morning Mitch and I went to HAM2 and unlocked the table to work on rebalancing the ISI. Table is rebalanced now, RX/RY locked unlocked shifts are around 10urad, RZ was a little bigger at ~15urad. I have not had a chance to do close out tfs.

After that was done, we tried to install the vertical L4Cs but were missing the hardware for the dog clamps. Found some class A stuff in the staging building that works, but when I went to install them to finish, I found one of the helicoils for the V3 L4C was missing. Rahul had some in the triples lab, so I will try to find time to install that tomorrow. The other 2 vertical L4Cs are done though, so the in vac portion of that install is mostly finished. 

We're checking the grounding of things in HAM2. IM4_TRANS QPD, ISS array QPD and all 8 ISS array PDs are fine.

IM4_TRANS and ISS array QPD:

Disconnected the DB25 cable from the transimpedance amp (ISC R4 slot 31) and measured the resistance between the pins and the chamber ground. (Ground potential for the chamber and the racks are significantly different, so we connected one cable directly to the chamber and measured the resistance between that cable and the pins.) 

All pins are isolated from the chamber. pin13 is tied to the shielding.

ISS array PDs:

Disconnected two DB25 cables from the second loop chassis (D1600229) in the PSL rack and measured the resistance between the pins and the chamber ground. Same caveat about chamber VS rack ground.

All pins are isolated from the chamber. Pin 13 is not connected to the shielding. This is fine, as this is a special cable made to convert four pairs of coax cables (total 8 coax) into DB25. Shielding of 8 coax is connected to pin14 through pin21 which are tied to the ground inside the second loop chassis. Pin13 is also connected to the ground inside the chassis. See D1600321.

Fil is done with SUS, some issues were found and he'll work with Rahul to try to fix them. He will also test picomotor grounding later.

[Begum, Camilla, Ryan S., Madi, Sheila]

Measurements taken on 2026-06-08 and 2026-06-09:
After the new OPO installation, beam profiles measured on HAM7 table (Sheila 90345) indicated that the OPO mode is different for the new OPO. This of course would both affect OMC mode matching as well as FC mode matching. The following measurements are beam q-parameter measurements measured on the FC path (green path in attached diagram), for beam upstream of ZM2 (p6,p7,p8,p11,p12) and downstream of ZM2 (p9,p10). The camera/profiler used is Phasics SID4 (MIT unit). 

Phasics camera is capable of giving us a beam waist and how far away that waist is from the camera position (- upstream of cam, + downstream of cam), however the fidelity of these values are dependent on where the camera is placed with respect to the waist: if it is too close to the focal plane (where the beam divergence is small), or if the beam is too large for the sensor the extracted values don't make sense. So, we have measured at least two positions with known distance from each other evaluate the fidelity q parameters obtained. 

Multiple measurements were taken at p10 point, varying ZM2 curvature. The strain gauge values are given in the table, 1.2 V and 6 V strain gauge correspond to 0 and 200 V pzt supply voltage to ZM2 psam. For points p6,7,8,9,10 the A:L2 lens was sitting in the "middle" position, both edges of the stage is lines up with its rail (will add photo here). Below table is from measurements taken on 06-08. The camera reports three numbers for each parameter, major, minor, radial. Major and minor do not necessarily line up with horizontal and vertical axes. The screenshots for each case report what the angle is. The .txt file for each data point also reports wx and wy for the near field beam, so we can potentially infer from there.

There are two readily available beam parameter tuning options we have for the FC path: the ZM2 curvature via psam, and the A:L2 lens via the translation stage it lives on. In the afternoon, we parked the Phasics camera on p11 and p12 positions (between p7 and p8) and recorded beam parameters for A:L2 lens on three positions (middle:0mm, -13mm: lens closer to ZM1 by 13mm, +17mm: lens further away from ZM1 by 17mm). Below table is from measurements taken on 06-09.

Raw data is in the attached .zip 

[Sheila, Karmeng]

Today we checked and managed to reduce some of the saturation on ZM4, and offload it onto ZM6. The changes were undone for now.

We briefly did the power budget check, but the power measured at the output of the SFI1 is fluctuating (between 0.79mW to 1.6mW) when the input to SFI1 is at 0.79mW. The power is stable down the propagation (after AP1 and SFI2), unsure what causes the fluctuation. Will continue to look into this tomorrow.

We also did an OMC scan, the pink trace is the scan when ZM4 is in its original setting (YAW: 1779.5), and the red trace is correspond to ZM4 misalignment (YAW: 1769.5).