I haven't found the alog, but there is a known issue with the ETMY ISI coilmon readbacks where they report the ISI coil drivers are tripped, but are in fact not. This seems to clear up after the coil drivers warm up over a few hours. This can be fixed by putting a test offset in the test input field on the BSCISI_COIL_THERMALSTATUS screen ( opened Overtemp link on the lower right of the BSC ISI overview screen). So far I have had to put 0xc, then 0x4 to clear up the coil driver status bitword, as show in the attached screen shot. Probably something wrong with something in one of the coildrivers.

The lights on the front of the coil driver don't seem affected by this, so if the overtemp protection is clear on the chassis in the rack, you need to do a bit of hexadecimal math to do clear the coilmon warning. To clear the current issue with the coilmon bit you need to find the difference between the good bitword (0xf50f0f0f) value and the current (0xf50f0f0b in the screenshot), so 0xf50f0f0f-0xf50f0f0b=0x4 is the value that goes into the test input field. This should go back to 0x0 after what ever component in the rack stops being grumpy.

We have mostly recovered SEI and SUS, SUS pointing is still being verified and the BRSes are having issues. HV still needs to be enabled for further recovery. Team CDS is still working on some issues, IPC errors, long range dolphin, timing error at the CS...

WP 13426

The CRS laser Chassis D2600190 was installed in rack TCS-R2. Chassis houses the CRS laser, mount, and fiber spool. A plexi security cover was installed over the chassis.

J. Oberling, R. Short, P. Thomas

We have recovered the PSL after this morning's power outage.  Once again, the PSL software did not autostart so Patrick was called in to get things up and running.  The system calibrations were all correct this time EXCEPT for the operating hours; we trended these to the time of the power outage and updated them manually (the OPHRS A, or the total system uptime, are still incorrect as this field is not updateable and we lost it over multiple failures of the system to retain the calibration settings).  I've attached a picture of the current settings screen.

The PMC relocked without issue, although it is running a little cooler than usual ( ~304.5 K vs ~306.0 K).  We'll monitor this as the system thermalizes and change the PMC temperature if necessary.  The FSS RefCav also locked without issue.  We have left the ISS off while the system thermalizes, please do not turn it on until things have settled down (hopefully by the end of the day).

Power storm last night tripped all 3 turbos and a couple of aux carts. Pressure rose up to about 2.1x10^-04 Torr, noted on the attached plot.

As I was doing recovery work on the output mode cleaner tube turbo pump, I had just closed the main isolation valve and "reset" the box, I was taking a photo of the as found when we had the 6:01 am power glitch.

I returned to HAM1 SS-500 to check the system, it tripped, and I recovered pumping on the SS-500 system and HAM1 turbo.  Moved back to the OMT turbo pumps system, by now the main isolation valve was closed, restarted the different components and spun up the turbo pump, while this one reached "normal" speed I moved to the other two turbo stations, and repeated the process, soon we had all three turbos back up.

The aux carts were restarted for BSC1 AIP, GV5 AIP, and HAM3 AIP.

The Kobelco compressor made it back on its own, but the dryer tower did not, I restarted it and visually checked the dew point, it was good, reported by the dryer at -63 ^oC.

Attached is a plot of the pumpdown for HAM1 and the corner via PT180 signal from BSC8.

Also I have attached a video capture of the power outage, on the video you can hear the solenoid valves closing for OMT turbo station and other items.

RyanC, Oli

We've gone through all the suspensions and restored the alignment sliders to what they were yesterday (around 2026/07/16 04:11:58 UTC) before the power outage. All slider values have been SDF'd and all is good slider/sdf-wise by 1468256527 (Jul 16 2026 17:01:49 UTC).

A quick look at pointing shows that even though the sliders are all restored, many suspensions have different pointing. Here's a quick look at the difference between most of the suspension pointing before vs after the power outage after restoring OPTICALIGN OFFSETs. Both of these sets have the same offset slider values. Note that at this time the ISIs and HEPIs are all still down.

Once the SEI system is back up I'll be starting to adjust suspension pointing for those that don't match where they were yesterday by adjusting the slider values to get DAMP_IN (driftmon) back.

TITLE: 07/16 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: --
    Primary useism: --
    Secondary useism: --
QUICK SUMMARY:

• There was a power glitch this morning, tons of disconnects
• CS chamber pressures (BSC2, HAM1, HAM6...) are on the order of 10^-6 torr

We had a power glitch at 06:01, most probably due to an electrical storm.

Richard and Gerardo are on-site recovering FAC and VAC.

CDS status: both main DAQ legs are down. All front ends are down. NDS3 (vacuum trends) is up.

Jonathan, Erik,

Per WP 13402 the h1daq 0 systems where update to remove the dolphin interconnect and use ethernet.

The work plan is in T2600271.  The basic work flow:

 * Redirect nds queries to h1daqnds1

 * Move the nds2 and ngdd data feeds to the 1 leg.

   * I was unable to get the ngdd services properly running on h1daqkc1.  I will look into this later.

 * power down the systems.

 * remove the dolphin cards, add in the ethernet nics as needed (some systems already had enough nics)

 * reconfigure the networking.

 * update the dns to drop gds0.

 * start and test services.

We moved the h1daqscript0 to a temporary location so that we could mount sw-msr-daqd1.  After we convert the daqstat ioc to a container we will be able to retire that machine.  Pending daqstat updates I have re-enabled the dc0_epics_mirror and added a dc1_epics_mirror so that we can see the gds broadcast crc.  Note even though the system shows a h1daqgds0 and h1daqgds1 those systems are gone, and the broadcast is being done from dc0 and dc1.

I finished off WP 13401 by configuring the frame writers to use the run number server on in the container cluster.  This will be tested at the next daqd restart.

We still need to pull the dolphin switches out of the racks.

Then there is OS upgrades for the daqd systems.

M. Todd, C. Compton, T. Shaffer

We had a go today at pointing the FLIR Boson+ camera at ITMY with the ring heaters on at 2W per segment. In short, we were not able to see anything with the FLIR Boson+ yet. My feeling is that the camera should definitely be able to see it, as we pointed another hand-held FLIR and were able to see a bright spot where we though the test mass was (though it was pretty out of focus because the hand-held is not as great as the Boson+). The issue with the current setup is the camera pointing is not easily adjusted, and did sit centered in the camera can that we were able to fit on the viewport.

The setup with the guillotine was to take the back off of a camera can and mount the camera in there as best we could without anylenses to maximize our field of view. Then we attached the camera can and removed the guillotine to look at the ITM. We tried removing the background because the image seemed completely saturated as if it was catching a reflection from something. We tried adjusting the aperture to reduce this but had no luck. We tried removing the camera can and pointing the handheld FLIR at the ITM and saw a bright spot that looked like it could be the ITM, so we tried again with the camera can slightly rotated to see if the seating in the camera can was an issue --- again without any luck.

Overall, I think it deserves another test using a pitch-yaw mount or something and a little bit smaller footprint so that it fits in the camera can more easily. Additionally, we should see what the lenses are for the other cameras used pointing at the ITMs, as they will probably be useful. 

I also found a Windows GUI that interfaces with the camera a little more customizably, which may be useful for future tests as well.

Now that we're in vacuum I have switched the QOSEM M1 satamp current from Constant Current mode to Sum Feedback mode. This adjusts the current to maintain 9V on the QPD (T2600172). This means that the SUM channels for F3 and RT have stopped saturating since the current has been slightly lowered to those LEDs.

There was some movement in the QOSEM positions, but nothing moved very much (ndscope). The most movement was on F3 Y, which moved 0.5 µm

TITLE: 07/15 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: 
SHIFT SUMMARY: The CS pumpdown continues, the interlock work was finished up and lasers were recovered, DC0 was worked on by CDS. 

BSC2 pressure is currently at7.01e-06 Torr, BSC8 is at 6.97e-06 Torr, HAM1 is at 9.33e-06 Torr, and HAM6 is at 9.41e-05 Torr.
LOG:

Elenna, RyanS, Oli

Summary: BBSS alignment in vacuum is looking good. It was looking bad earlier but we figured out the issue and now it's looking good.

Whole explanation: I noticed that the BBSS was super Yawed in M1. LF was very large in +Y, RT was very large in -Y, F2 was reasonably large in +X, and F3 was reasonably large in -X (medm). Referencing E2600243, this correlates with a rotation in -Yaw. This was strange, and we noticed that this shift in alignment had happened over a few seconds yesterday 2026/07/14 20:57 UTC (ndscope). At the same time this happened, we had fallen off the OPLEV. After some concern, we were reminded that the models in b2h34 had been restarted yesterday, and so we realized that the OPTICALIGN alignment sliders hadn't been saved in a while and were from back when we had initially been checking BBSS alilgnment into HAM3 (which had a lot of Yaw). We reverted the slider values to what they had been last set to (from Keita's alog 90920, ndscope), and we are looking good on all three stages(medm) and are back on the OPLEV (ndscope). Slider values have been SDF'd (sdf). I will be checking the sliders on the rest of the b2h34 suspensions to make sure we didn't lose any pointing on them due to the model restart either.

July 14 - 15, 2026

Filiberto C., Richard M., Ryan C., Marc P., Tony S., Patrick T.

The TwinSAFE laser safety interlock code has been updated to https://git.ligo.org/cds/ifo/beckhoff/lho-laser-safety/-/commit/88c39ba2a1ff25ce7f710fd496c78f42fb911d38. This is a rewrite using scripts to generate a large part of the code and configuration. It also does the following:
* Adds support for the addition of CHETA.
* Adds a bypass mode that is enabled using a key switch on the wall of the control room. When in this state the lasers will remain on even if an estop is pressed or an enclosure is opened.
* Adds a single channel/medm button to reset all of the function blocks.
* Removes the code and channels for the diode room.

Issues run into:
* The existing version of TwinCAT on h0safety would not open the new safety code that was created with a newer version of TwinCAT. I installed the TwinCAT Package Manager on h0safety and used it to migrate the version of TwinCAT there to 3.1.4026.24.
* There were multiple TwinSAFE boxes that had their hardware address set to 0. Filiberto set the following through their rotary dials/dip switch:
IOT1 -> 205
ISCT1 -> 210
IOT2L -> 215
TCSY -> 220
TCSX -> 225
CHETA -> 230
HWS -> 235
SQZT7 -> 240
SQZT0 -> 245
TCS_INTLK -> 250
* The diagnostic test pulses had to be turned off for the inputs to the CHETA box. That is, 8040:04 Diag TestPulse active, 8050:04 Diag TestPulse active, 8060:04 Diag TestPulse active, and 8070:04 Diag TestPulse active, were all set to FALSE (0) on the alias device (see attached picture).
* The light in the control room used to indicate that the bypass mode is active is not being turned on. Will need to be fixed in hardware.

Each of the doors and emergency stops have been tested.

We have an earthquake mode that allows us to move into higher bandwidth interferometer controls during an Earthquake. Those controls also cause extra noise, as noted in this alog, so we are trying to subtract the injected linnear noise during this mode. Here is a trend of the seismic environment state and the sensmon range channel detector sensitivity. The plot shows that once we transitioned into earthquake mode, we were in earthquake mode for about 15 minutes before a lock loss. It is also visible that the gains are changing on the channels.

Elenna and I decided to try subtracting the noise from the interferometer controls during those 15 minutes starting at GPS 1443544132 and ending at 1443544932, see this alog for reference. I am comparing this GPS time for this earthquake to one hour before so we can know what the sensitivity should look like if we subtract all of the noise. We decided to subtract the channels whose gains changed. The channels subtracted were

H1:ASC-DHARD_P_OUT_DQ,

H1:ASC-CHARD_Y_OUT_DQ,

H1:ASC-DHARD_Y_OUT_DQ,

H1:ASC-CHARD_P_OUT_DQ,

H1:ASC-DSOFT_Y_OUT_DQ,

H1:ASC-DSOFT_P_OUT_DQ,

H1:LSC-MICH_OUT_DQ,

H1:LSC-PRCL_OUT_DQ,

H1:LSC-SRCL_OUT_DQ.

The channel with the greatest noise contribution was H1:LSC-MICH_OUT_DQ, which I determined through taking the coherence of all the LSC and ASC channels and the witness channel. The final subtraction and BNS change are visble in this GWSubtract file. Therefore, if we run a noise subtraction during earthquake mode we know we can get back at least 11 Mpc of sensitivity. This would be useful if we made a detection during earthquake mode, however we could still do better by around 70 Mpc. I plan to make this into a more usable tool and look into what is causing the rest of the noise next. I also plan to look into more channels to see if others might be causing noise as well. Since this is an earthquake mode time, it is possible the earthquake is modulating some of these channels, so a nonlinear noise subtraction may make more sense.

On Monday Marc updated the BBSS M1 QOSEM satamp (91003). Today I updated the satamp compensation filters. These compensation filters were updated in the FM01 spot in the H1:SUS-BS_M1_OSEMINF_{F1,F2,F3,LF,RT,SD}_{SUM,X_RAW,Y_RAW} filter banks. 

Previous filter: zpk([145e-3],[720e-6],1,"n"), named 0.15:7e-4

New filter: zpk([2.89],[14.4e-3],1,"n"), named 2.9:14e-3

Filters were loaded in and H1SUSBS.txt has been committed as r35492.

**These filters are still currently off because we have not turned the whitening on yet