Tony, Dave:

At 10:33 FW went unstable, restarting itself after writing a new frames.

I restarted the daqd process at 10:44 (systemctl restart rts-daqd) which so far appears to have fixed it.

J. Kissel

Seeing the "first light," calibrated SPI Optical Lever amplitude spectral densities in  and , and thinking about ADC noise limitations and the calibration models assumption that the spots are centered on the QPDs drove me to re-check the spot positions on the QPDs. 

Timeline of centering:
    2026-07-17 17:00 UTC (LHO:91124) -- Jennie turned on the SPI laser for the first time since doors went on and the ISIs were isolated, and re-centered *only* QPDB with M_C1 (and thought she had adjusted QPDA centering with M_M1, thought she had mistakenly moved M_M2, but confirmed later she did not; LHO:91219).
    2026-07-23 14:00 UTC (LHO:91218) -- Jim unlocks and restores function of HAM2 HEPI, such that now both HAM2 and HAM3 are fully functional, and remain ISOLATED with corner station sensor correction ON as their nominal condition.
    2026-07-23 20:30 UTC (LHO:91221) -- Jennie re-centered (only) QPDB again using M_C1.
    2026-07-24 16:05 UTC (this aLOG) -- Not knowing that Jennie had yet recentered any QPDs, and finding QPDA PIT's normalized beam displacement at +0.23 [rad], I recentered *both* QPDA and QPDB.

I attach a similar trend of relevant channels including both Jennie's centering work from 2026-07-23 and mine this morning. Similar to Jennie's plots but with thick lines, light mode, and with the y-axes labeled.
I saved this template to 
    /opt/rtcds/userapps/release/spi/h1/ndscope/QPD_Centering.yaml  (rev 35598).


Here're the DC values of the QPDs after this morning's centering (done with the precision one can achieve with a picomotor STEP SIZE of 1 [ct]):
$ gpstime now;z avg -30 H1:SPI-H23_OL_QPD_A_PIT_OUT_DQ H1:SPI-H23_OL_QPD_A_YAW_OUT_DQ H1:SPI-H23_OL_QPD_B_PIT_OUT_DQ H1:SPI-H23_OL_QPD_B_YAW_OUT_DQ -s

t = 
PDT: 2026-07-24 09:27:44.113664 PDT
UTC: 2026-07-24 16:27:44.113664 UTC
GPS: 1468945682.113664

Channel                        t-30 sec average       t-30 standard deviation
H1:SPI-H23_OL_QPD_A_PIT_OUT_DQ -0.0024822048842906954 4.722167842008142e-06
H1:SPI-H23_OL_QPD_A_YAW_OUT_DQ  0.0030039884615689514 5.884913671432033e-06
H1:SPI-H23_OL_QPD_B_PIT_OUT_DQ -0.0022898733150213957 8.094109742945136e-05
H1:SPI-H23_OL_QPD_B_YAW_OUT_DQ  0.008859152471025783  4.6337990240392655e-05

$ gpstime now;z avg -30 -s H1:SPI-H23_OL_QPD_A_PIT_OUT_DQ H1:SPI-H23_OL_QPD_A_YAW_OUT_DQ H1:SPI-H23_OL_QPD_B_PIT_OUT_DQ H1:SPI-H23_OL_QPD_B_YAW_OUT_DQ H1:SPI-H23_OL_QPD_A_SUM_OUT16 H1:SPI-H23_OL_QPD_B_SUM_OUT16

t0 = 
PDT: 2026-07-24 09:54:54.983607 PDT
UTC: 2026-07-24 16:54:54.983607 UTC
GPS: 1468947312.983607

Channel                        (t0-30 sec) average       (t0-30 sec) standard deviation
H1:SPI-H23_OL_QPD_A_PIT_OUT_DQ  -0.002713  3.4e-05
H1:SPI-H23_OL_QPD_A_YAW_OUT_DQ   0.003265  4.2e-05
H1:SPI-H23_OL_QPD_B_PIT_OUT_DQ  -0.002033 10.0e-05
H1:SPI-H23_OL_QPD_B_YAW_OUT_DQ   0.009682 5.3e-05
H1:SPI-H23_OL_QPD_A_SUM_OUT16   25.846691 0.003820814636259141
H1:SPI-H23_OL_QPD_B_SUM_OUT16   29.265472 0.004081774857250754

WP13433 TW1 offload

As Tony mentioned, I did a quick NDS1 restart at 07:57 to get it to serve the past 6 months of minute trends from the archive following this week's copy.

At 08:09 I started the deletion of the old data from TW1's SSD-RAID. This typically takes a few hours. At the start of deletion disk usage was 93%.

TITLE: 07/24 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: CALM
    Wind: 5mph Gusts, 2mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.10 μm/s 
QUICK SUMMARY:
 

The Vacuum pressure is still being pumped down.

CDS team needed to reboot the NDS server again so the NDScope screen shots may stop beifly.

SUS: First stage of PRM seems to be pushing a bit harder than I'd expect given that it's misaligned.

Jeff, Sheila, Fil, Elenna, Oli

The feedthrough cables (air side) for MC2 M2 and M3 have been swapped and now MC2 is back to behaving how we expect it to. Transfer functions for M1 to M1, M2 to M2, and M3 to M3 are correct (red traces) and crossover plots for MCL and M2/M3 are looking good.
Current correct cable numbering for MC2 at the HAM3 D6 feedthrough port is:
D6-F1 -> MC2 M3 (HAM3_020)
D6-F2 -> MC2 M1 (HAM3_001)
D6-F3 -> MC2 M2 (HAM3_019)
This should be updated in the flange layout D1002874, which I don't see the altium file for. Next time we open up HAM3, we should fix this lineup so F1/F2/F3 line up with MC2 M1/M2/M3.

Full troubleshooting:
After lots of troubleshooting and my MC2 M2 and M3 measurements from yesterday, Jeff noted that the M2 to M2 TFs looked a lot like the M3 to M3 Tfs, and vice versa. This was also very suspicious because back in May (90185) there had been a feedthrough swap for the feedthrough that MC2's M1 (T1/T2/T3/LF), M2, and M3 were all connected to, and M1 and (we thought) M2 had been found to be plugged in incorrectly on the vac side. After the plugs going into F1 and F2 had been swapped, we had measured only M1 to confirm that the swap was successful.

A (silly) mistake:
Fil and I went out to HAM3 D6 flange and meant to swap the M2 and M3 cables, but since the flange layout was still listing F1 -> M1, F2 -> M2, F3 -> M3, we swapped the cables connected to F2 and F3, which were actually M1 and M3, respectively. We determined that this was wrong because M1 to M1 and M3 to M3 looked horrible but M2 to M2 looked the same as before (wrong but not different), which means that M2 must have been in the F1 port and so hadn't actually been swapped with M3. We noticed later that this lineup was written in the May 8th MC2 'fix' alog(90185).

Actual fix:
We plugged M3 (HAM3_020) into F1, M1 (HAM3_001) into F2, and M2 (HAM3_019) into F3. Here's a diagram/timeline of this mistake and fixing it.
Everything is looking good for MC2 and it seems like we've been able to go back to using MC2 to lock the IMC normally.

I'll add plots next week comparing MC2 M2 to SRM M3 and vice versa

Jennie W

Today after verifying I didn't need to do any alignment on ISIK itself (SPI bench on HAM3), I used the picomotor on HAM2 (M_C1) to align the beam to the QPD B which resides on ISIK.

I have attached a labelled ndscope showing which channels to look at while changing the M_C1 picomotor.

The yaml files for aligning QPDA and B are saved as QPBa_picos.yaml and QPDB_picos.yaml in userapps/spi/h1/ndscope.

One weird thing I noticed while moving the picomotors is that while moving in small steps of 1 count (speed of the picomotor was set to 'jog' which is 50 Hz), the beam would move in the same direction on the QPD while I change direction on the picomotor.

See an example in this image.

Not sure why this happened as it was not a problem when using larger steps of 10 counts on the picomotor.

With steps of 10 counts the beam goes down in pitch on QPDB which corresponds to down on picomotor controls (channel Y down on picomotor controller).

To go up in yaw on QPD B you need to go right on picomotor controls (channel X up in magnitude).

Summary: QPD A and B are fairly well centred when HAM 2 and 3 are isolated now.

Jennie W

Summary: I didn't move M_M2  picomotor on Friday 17th July.

Last Friday (LHO alog #91124) I centred the QPDB on HAM3 spi bench using M_C1 picomotor (picomotor B  ch7 which is controller 5) on HAM2.

I wrote the log the week after and checking back in the H1:SYS-MOTION_C_PICO_G_CURRENT_X_POSITION I thought I had also moved M_M2 (CH7) on picomotor driver G.

Checking back it turns out the 2000 count jump I was seeing was just the 2000 count difference between the values stored for ch8 and ch7 when I switched the selected motor to channel 7.

See the ndscope picture where the second cursor shows when the green channel H1:SYS-MOTION_C_PICO_B_SELECTEDMOTOR changed from 8 to 7 and you can see that the the yellow channel H1:SYS-MOTION_C_PICO_B_CURRENT_X_POSITION changed up by 2000 counts.

Looking at the Beckhoof screen you can see that when ch8 is selected this stored value (-2000) appears on the screen and is not there when ch7 is selected. I mistakenly thought these were reset when the selected motor was changed.

So no re-alignment of M_M2 is needed.

TITLE: 07/23 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Good progress today towards DRMI, see commissioning notes in alog91211. HEPI was unlocked for HAMs 1 & 2; see alog91218. Dust alarms throughout the day in the LVEA and optics lab. The LVEA remains Laser HAZARD and corner volumes are still pumping down.
LOG:

Over lunch I went to HAM1&2 to unlock HEPI. Not much to say, stops unlocked, signs flipped, iso gains reverted to 1 and everything turned right back on. I can now try to find time to commission St0 ff for HAM2.

• found a bit of clipping on ISCT1 popair shutter, moved shutter, 2 inch lens and bs right after lens in -X direction
• Adjusted alignment onto POPAIR B using PRMI flashes at 10W, then MICH bright at 10W we were able to see a small signal to align this diode to. 
• Also checked alignment onto REFLAIR A using MICH bright. 

• Ran OMC scan to check modulation depth, comparing to 89497.  Modulation depth settings are 27dBm for both 9MHz and 45 MHz, as that alog says they should be.  Modulation depths are about the same as in that alog, (9MHz peak over carrier peak is 0.01, 45 MHz peak/carrier peak is 0.018).  However the carrier peak is about half as large as it should be.  AS_C sees 20mW, we have 8.5W at IM4 trans so we expect 18mW entering HAM6 in single bounce, so this seems OK.  
• With MICH dark locked, Elenna worked on centering POP X, while I went back to ISCT1 to check alignment onto the diodes.  I am sure that the beam is reasonably centered on REFLAIR A, POPAIR B, and POPAIR A (did not check REFLAIR B this time).

I used the earthquake down time from the weekend to look at the health of the BSC2-ISI sensors.

Sensors look OK (including the newly replaced H1 L4C - see alog 90840) except for CPS ST2 H1 (see red curve on the last plot) with large noise below 1Hz. This will need an investigation (I would start by swapping cables at the field box to see if it's an in-chamber issue).

Dtt Template lives under /ligo/svncommon/SeiSVN/seismic/BSC-ISI/H1/BS/Data/Spectra/Undamped/bs_all_sensors.xml 

I tried the heater guardian today with a gain of 0.003 and a set point of 25 degrees seeing as it seems to have reached equilibrium around this value with no loop running and 1W input overnight. It looks like it overshot initially and is turning around and coming back to the set point of 25 degrees C now. Thermistor 1 is the loop sensor but I have marked the turning point on thermistor 2 in the attached picture. We still have some range on the PZT actuator (JAC-PZT_DRIVER_VOLTS is low rate channel from Beckhoff voltage driver and JAC-PZT_DRV_OUT_DQ is front-end PZT feedback channel for fast feedback) and the temperature actuator (JAC-HEATER_POWER_SET). I will get the operator to switch it off when they leave so we don't cause any pressure spikes overnight.

Shoshana, Jim, Arnaud

The x6 HAM3 new CPS boards have been set to the following configuration (as per E2200455): 

• Chassis ungrounded from PCB (P3 jumper removed) - To avoid ground loops (see p33 of the user manual)
• All boards set to slave (P26,27,28 jumpers removed) - This is because the LHO CPS are linked to an external timing chassis and don't need a master board (as per Jim)
• Phase set to 0 (P2 jumper on) - This setting is because the targets are now independant from each other (see point #1 in page 27 of the user manual)

There was some glitching noticed on the channels that were in range prior to this work, which was fixed after this setting change (see attached). Two of the cards were set to Master before and Jim is confident this would have created problems. 

Left to do : 

1- Label the cards at the front of the boards with module SN and corner #
2- Disconnect the grounding to the chamber of the crate on the +Y side 
3- Label the in-air lemo cables with H1, V1, H2 ...
4- Update ICS with the new boards SN
5- Gather the cards that were removed from WHAM3 to send back to microsense for recalibration with a new set of sensors (RMA)

The tracking spreadsheet for this ECR was updated here: E2500184