The ETMY BRS seems to be continuously ringing up. I've tried to make the changes to the thresholds which was the previous fix outlined in 87634 for the same BRS, and will check back in on it later to see if just increasing the thresholds helped at all.

Changed thresholds:

H1:ISI-GND_BRS_ETMY_LOWTHRESHOLD 800-->2000

H1:ISI-GND_BRS_ETMY_HIGHTHRESHOLD 2000-->4000 Changed

Additonally I changed the ETMX BRS drift control to 6.00V and the ETMY BRS to 2.00V to try and better center them

WP13311 Check production first 20bit-DACs

FRS38169

For the five production front ends which have a 20bit-DAC sharing A1 with an updated time card, we have either verified that there is no problem seen (h1susb2h23, h1iscex) or we identified and fixed the problem by either shifting the ADC/DAC cards (h1sush7, h1oaf0) or downgraded the timing card (h1cdsh8).

Attached is a snap shot of our working spredsheet. This will be cleaned up and put into DCC.

TITLE: 06/12 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: 13mph Gusts, 9mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.08 μm/s 
QUICK SUMMARY:

It was requested that I try to trend the Oplevs this morning, but the BS SUS screen is full of white boxes that claim their channels don't exit when NDscoped. Tagging CDS. 

I did however find the Input Pointing Trends button which gave me the following: 
IMs 
BSCs (No motion on the BS channels here though which is some SUS-picious BS)
MCs
PRMs

 

WP13324 Fix h1cdsh8 20bit-DAC

Marc, Fil, EJ, Tony, Dave:

Thursday 11jun2026 work was done on h1cdsh8 to fix its first 20bit-DAC. Prior to this we verified, using h1susfc2 and iop drives, that all 7 channels being used were broken by the timing card upgrade 13apr2026.

We had two options: move all the IO-cards one slot to the left, or downgrade the timing-card firmware. For h1cdsh8 we decided to do the latter. (Note that h1sush7 and h1oaf0 were fixed with the former).

After powering h1cdsh8 down, EJ worked on documenting the BIOS settings for this W22-45 computer. This is to investigate the W22-45 issue we are seeing in the EE shop in which the combination of 0x635 and 20bit-DAC prevents the IOP model from running.

I went to the IO-Chassis in the Filter Cavity End Station building (FCES) and removed the 0x635 card (S2101106) and replaced it with a 0x1f0 card (S2101117) which Marc had reprogrammed.

The only issue was moving the Avago Single Mode SFP from the old card to the new. This SFP was damaged, its pull bar had broken off. Taking the card back to the EE shop, Fil was able to extract the SFP. I found an equivalent spare SFP (the last spare) which is complete with its pull bar.

We think the only difference between the TLZ and the TPZ is the plastic locking mechanism.

Following the upgrade I tested ch7 using the IOP's Duotone loop-back, this is working now (did not work this morning). Tony got h1susfc2 driving again, but I was unable to get the FASTIMON aux channels to verify ch0-5 were driving.

Fil and I went to the IO Chassis and verified ch0-5 were working using a breakout board and DVM. We verified the binary cards were working and that all the SUS chassis were operational. We are handing FC2 over to SUS for verification. 

Erik, Oli

Now that we don't need the BSFM model anymore, we can move the BBSS model over into h1susbs (it was temporarily on h1suslo12). It's been committed to svn as r35313.

I moved the BBSS model from h1suslo12 over to h1susbs. Then I made some more changes to get everything up and running. Both h1susbs and h1suslo12 were successfully able to build on h1build.

Things updated/added/removed:

h1susbs (r35313) - moved what was in h1suslo12 at the time over to h1susbs and then made the following changes:

• Changed dcuid from 188 (h1suslo12) to 31 (h1susbs)
• Changed name of BBSS block from BBSS to BS
• Changed top level channel names from BBSS to BS
• Added in PCIE senders and receivers for ISC, Dither, SUPOINT, IFOTRIG, and CALCS
  • Had a bug where the bus selectors weren't naming themselves properly and so rcg was getting confused, but Erik figured out the issue and we just had to edit the new bus names

BBSS_QOSEM_MASTER (r35312):

• Added M3_WIT_{L,P,Y} to the DAQ channel list (committed to svn as r35296)
• Removed the USER DACKILL because we don't need it anymore (committed to svn as r35312)

h1suslo12 (r35318):

• Reverted back to what it looked like after r34977 (see 90358)

R. Crouch, J. Warner, J. Oberling, M. Robinson

We made some more HEPI moves today to better position the BBS SUS cage.  The results are shown in the 1st attachment.  The deviations listed in the attachment are the deviations from nominal, but that is not our target here.  To better position the BBS optic we are trying to match our position and yaw from the test stand.  As a reminder, I've attached the final SUS cage alignment from the test stand (2nd and 3rd attachments).  The table below shows our current deviations from the test stand alignment (all units in mm):

We wanted to bias to the negative by ~0.3 mm in both X and Y since our BBS test stand alignment had a +0.3 mm deviation in both X and Y position, so this looks pretty good.  The Z axis indicates a potential off level in the cartridge assembly, but one has to be very careful in assessing level based on these measurements.  These measurements are all done in the LHO Global coordinate system, which is tilted w.r.t. the local level in the WBSC2 chamber (see T0900340), so you cannot level to global coordinates; if one did then the suspension would then hang weird as it doesn't care about our different coordinate systems, it just hangs along the local gravity vector.  Jim is planning on using an autolevel to measure the top of the keel mass of the ISI's Stage 2 to see how that looks (similar to what LLO did).

In addition, the yaw of the SUS cage also closely matches our test stand alignment.  Our target, from the 3rd attachment, is 44.9979° from the +X axis and we are currently measuring 45.0025°.  This is a difference of 0.0046°, or ~80 µrad, in the CCW direction, so pretty close to our target.  We won't know for sure how good the pointing alignment is until we can use the BBS OpLev, which is not currently available (the channels do not yet exist, per Oli the plan is to add them next week), but my hope from today's work is that we'll be pretty close.

So next steps are to have the BBS OpLev available so we can assess our pointing alignment and the attachment of the HEPI actuators.  We'll have to measure position again after the HEPI actuators are attached, so we aren't quite done yet.

Sheila, Begum, Keita, Camilla

We followed 80010 to set up, additionally Sheila had us stop the OMC ASC and DC centering loops before running the scan. We moved SRM in Pitch to center beam on AS AIR camera. Cheated the dark offset via adding an offset to H1:OMC-DCPD_SUM_OFFSET.

Started with 1.1mW on SQZt7 IR PD1.06mW on AS_C, 74 and 75 on AS_A and AS_B, 1.06mW on OMC_A and 0.82mW on OMC_B. We were seeing the OMC diodes saturating (via H1:OMC-DCPD_A_WINDOW_EXCEED and H1:OMC-DCPD_B_WINDOW_EXCEED), the same was true after increasing scan length to 200s and reducing SEED input power form 75mW to 50mW in, we checked this did not happen in September 86965. We also turned down the purge air in HAM7, again, did not help.

We tried locking the OMC with the SQZ beam and were unable. 

We did not saturate the PDs with SEED power down to 25mW but the peaks were noisy at the beam was moving and the mis-alignment peak was too large. We got an upper limit of 10% mode mismatch, which is not useful, attached.

We looked back at January data, should be very simular and although the misalignment is bad, the lower limit on modemamthcing is 1.18%, which is very good. See 90598

Ibrahim, Betsy, Anamaria

Upon first in-chamber BBS01 inspection, we found 3 large clumps of spots approximately 100mm from the edge. We're consulting GariLynn at CIT for steps on how to clean.

Acetone swab: We tried to go over the spots with a cotton swab with acetone, but the spots remained.

First contact: We then tried to first contact a small portion with one thin layer, but the spots remained.

While there's no evidence that the beamsplitter was contacted, dinked, touched or scratched in anyway, this might be a cause for the damage. There is texture to the spots upon brushing them with a swab and while it seems more likely that these are above the surface, we are not totally sure.

Hypotheses (and their problems)

1. Peek In-Vac cable scratch: maybe an in-vac cable fell on that area but they would have had to imprint multiple times with some force to show something like this. 

2. Falling foil: maybe a piece of foil fell onto the surface and scratched it that way? No foil was used or wrapped at height during BBS and again, the foil would have had to fall with some heft.

3. There-the-whole-time: Maybe the spots were there the whole time and are invisible to non-chamber conditions. Because this is on the AR side, there is no good scatter plot of the surface. Since we did not see this in normal light conditions, but immediately saw this in chamber (dark) conditions, this may have been there all along. The spots are quite large (as attachments show), so this makes that less likely.

4. Dry first contact: Maybe it's dry first contact? We went over some of the spot with acetone but it stayed. We also first contacted a thin layer on one part but it stayed. The nature of the spots do look like they're small first contact bubbles. We found the first contact sheet that we used on that side and indeed, there are some similar streaks in size but nothing conclusive. We're looking at matching the spot with the first contact to see if there is a streak in this region. Problem is - first contact wouldve come off quick with the acetone treatment. So this is also not likely it.

What to do next:

- Analyze with Dino-Lite: We're going to zoom in on the spots with our DinoLite mount to get a better look. This could tell us if they are truly scratches or stuck particulate.

- Match first contact sheet with spots: Seeing if these spots were visible during FC (done on May 6) - alog 90149. Nothing visible. 

- Anamaria suggested at any rate shining a gaussian beam at it to analyze the damage in a short experiment to characterize. 

TITLE: 06/11 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:
More Fist contacting the Beam Splitter was done along with Top Gunning it as well.
The SEI HEPI Team of  5 has been trying to Align HEPI. 

HAM2 SUS TF were taken.
Viewports inspected by the VAC team.
Jim Is currently taking TFs before floating the ISI in HAM2.

Dave swapped out a timing card WP 13324. 

Fast shutter is now working again, Confirmed by Sheila and Camilla.

GRB_Short E640741 @ 21:33:37 UTC
GRB_Short E640743 @ 21:43:41 UTC

LOG:

We visually inspected the windows on the HAM1-HAM2 septum and wiped the bottom of the cylindrical window recess. I found nothing that might be a structural risk.

IFO REFL window (bottom +Y) had two big particulates as well as tiny ones. Gerardo blew off the big ones using an empty iso-propanohl squirt bottle as an air puffer. After that he wiped the recess for the window and picked up something, which we guess is one of the big particulates that were removed from the window. Tinier particulates stayed. There was also about half to 3/4-inch long line close to the top of the window. It might be surface scratch, didn't move, and might have been there for a long time. Since it's 1/4" or so from the edge of the optic and very far from where the beam will hit I say this is OK.  

Main PSL beam window (top middle) had tiny particulates but no big ones. These were not moving when Jordan tried to blow them off. I say these are fine.

POP/ALS window (top +Y) as well as unused window (bottom -Y)looked fine.

WP 13326

Dave noted we lost Beckhoff channels yesterday around 6PM. Daniel logged in and confirmed terminals missing in Corner Chassis 4. The third EtherCAT coupler was replaced.

Chassis Serial Number S1107450

D. Barker, F. Clara, D. Sigg

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.

Checked the baffles for the CRS on the constructed unit, everything fit fine. 

Spent time doing alignment for the other two constructed HoQIs. 01-SN008 aligned with 87% fringe visibility, this required the retroreflector on the baseplate to be rotated a bit as it wasn't quite in the correct position. 
01-SN007 spent a long time trying to align (this was also worked on the other day with limited success), couldn't get above 60% FV so we decided to take it apart and redo it with the dowel pins in place. After taking it apart we found that the QWP was damaged by the metal screw, honestly quite impressive that it was still seeing 60% FV! See photos. The sin PD cable is also damaged and will need to be fixed before we use this HoQI. 

Assembled the remaining HoQIs including the dowel pins. Need to clean the final HWPs to finish this assembly. Additionally, 01-SN006 has no PDs as it is using the faulty assembly from before, 02-SN006 connector needs to be flipped.

Current HoQI status: 2 aligned on CRS, 1 aligned, 2 with faults, 3 (mostly) constructed waiting to be aligned. 

pic 1 - broken sin pd
pic 2 - broken QWP
pic 3 - serial number for broken sin pd assembly 

[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).