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.

This afternoon I recovered the PSL successfully after it had been down since yesterday morning when work on the site laser safety interlock began.

The recovery went as expected and without issue. I've relocked the PMC and FSS, but am leaving the ISS disabled until the amplifiers and PMC have had time to warm up and the output power levels out. Looks like we'll need some alignment touchup into the PMC and RefCav, but that will also wait until things are warmed up, likely sometime tomorrow. Power watchdogs have been enabled for the night.

The chamber managers now better handle the recovery for the case of HEPI's master switch OFF but the ISI's master ON (ie. if HEPI tripped but not the ISI for some reason).

Years ago we added the ISI_DAMPED_HEPI_OFFLINE state to the chamber managers, but one small fallout from that is that if HEPI's master switch was off, but the ISI's master switch was on, when someone would untrip the HEPI, the manager would run through INIT which would immediately jump to turn HEPI back on. This would then potentially retrip the HEPI, frustrating users. I've changed the INIT state to just go to ISI_DAMPED_HEPI_OFFLINE for this case, as it should.

I tested this with SEI_ETMY and SEI_HAM6 by setting the nodes to ISI_DAMPED_HEPI_OFFLINE first, then tripping HEPI by changing the trip level, turning OFF the HEPI master switch, then untripping the HEPI. All tests successful and I loaded this into all other chamber managers.

Matt, TJ, Camilla

Today we did proof of principle measurements of the CHETA beam size using the FLIR camera.

In 13940 the CO2 beam was projected onto black construction paper in the LVEA. Today we projected the CHETA beam (at low power, <100mW) onto the laser curtains in the CHETA lab. We measured it using a ruler with paper markings taped on at 2" increments, it was easier to see the ruler once it was warmed up by our hands.

We also moved the QPD 2" lens 200mm FL into the path 230mm after M4 and 500mm from M4, for both of these, the beam appeared to be ~1" in diameter. The laser curtain was 67" from M4. Photo attached.

Rahul, Sheila

We measured distances in HAM7 on the VIP.  For optic names see D2000021 (A:L2 and A:L3 are actually one lens, we will call it A:L2)

• A:M3 to A:DC2: = 61mm
• D:DC2 to A:L2 = 35+-2mm
• A:DC2 to SFI1 wedge= 215mm
• A:L2 to SFI1 wedge: 
• SFI1 wedge to A:P1 = 257mm
• SFI1 wedge to B:M1= 389mm 
• B:M1 to B:M2= 221mm
• BM1 to B:L1= 87+-3 mm
• B:L1 to B:M2: skip
• B:M2 to B:P1 = 57mm (+-1mm)
• B:P1 to SFI2 wedge: 277+-2mm
• SF2 wedge to B:M3: 57mm
• B:M3 to B:L2= 96 +-2mm
• B:M3 to B:BS1 = 207mm
• B:BS1 to B:M4:97+-2mm
• A:P1 to A:L1: 66+-2mm
• A:P1 to A:M2= 87mm
• A:M2 to A:M1: 41mm
• A:M1 to A:DC1 = 67mm
• A:DC1 to edge of OPO box:63mm

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

Matt, Camilla

On July 9th, we used the Ophir Nanoscan to take data on the CHETA Y-arm Table Laser 0918 with L2 at different locations on the translation stage. Data is attached to D2500319. 

We then used Fintrace to project this to the ITM. Data must be saved with correct file name for this analyzer to work, using logger function of Nanoscan V2 to save. Used command: python beam_profile_analyzer_nonlinear.py /DATA/20260709_0918_after_L2_m10/ --z-offset 245 

At the nominal beam size of ~53mm on the ITMY, the beam size astigmatism is 3.9% which we think is acceptable. 

We also took some data with the analyzer at a fixed position while moving L2 along the translation stage, this is also attached to D2500319. 

[Sheila, Camilla, Ryan, Eric]

We would like to verify that our recent mode measurements after ZM5 ( 90783) and before ZM4 (90815 ) make sense by connecting the two.  We decided to use the q value from the measurement at the nominal ZM2 strain in 90815 (ZM2 strain = 3.15V) and propagate that mode through the path containing ZM4 and ZM5 and calculate the overlap with the q values from 90783 measured at different strain settings for ZM4/ZM5.  The goals here are as follows:

1. Improve our model of the ZM4 - to - SEC path and verify that we're interpreting our mode measurements (with M^2 > 1) correctly.  
2. Determine the ROC for ZM4 and ZM5 as a function of the strain gauge voltage.  This is particularly important since we are going to replace ZM5 and Camille would like to know what ROC to shoot for with the pre-stressing procedure.

First, I address item 1.

Mode Measurements with M² > 1:

Our system seems to be adding some higher order abberations to the beam.  As a result, our mode measurements indicate that we have an M^2 number significantly above 1 (between 1.2 - 1.5 depending on the PSAM settings).  When M^2 is > 1, the presence of HOM content in the beam prevents one from focusing down to as tight of a waist, for the same divergence angle, the beam radius at the waist will be larger by a factor of M.  The thorlabs beam profiler accounts for this by fitting the data to the following formula (which we confirmed by doing our own independent fit):

w(z)² = w_M²[1 +(z - z₀)² (pi*w_M²/(M²*lambda))²]

Where w_M² = M²*w₀²  Is the waist for a beam with M²>1, and w₀ is the waist for the TEM00 component of the beam (ie for M² = 1). 

The q parameter ends up the same as before:

q(z) = (z-z₀) + i*z_R

where z_R = pi*w₀²/lambda = pi*w_M²/(lambda* M²)

Knowing that M² > 1 tells us that our beam is a mixture of TEM00 and some higher order mode content.  However, from the M² value alone we don't know which higher order modes are excited (in principle one might be able to make some rough projections using the surface abberation measurements of the PSAMs from Caltech, but that sounds tricky and is beyond the scope of today's post).  If we want to do mode matching calculations, the only thing we can do at the moment is back propagate the TEM00 component and do all mode calculations for TEM00.  

We use the same beam propagation matricies as always to back propagate the TEM00 component to determine what the TEM00 mode looks like in HAM 7.  

Determination of the ZM4 and ZM5 ROCs

I then took the q value (for the nominal ZM2 = 3.15V) from the measurement before ZM4, back propagated it to ZM4 using our length measurements.  I then propagated the q through ZM4 and ZM5 and calculated the overlap with the q values measured after ZM5 for various values of the ZM4/ZM5 strain gauge settings in ( 90783)

Then, the ROCs for ZM4 and ZM5 were chosen for each strain gauge settings to maximize the overlap.  The overlap is => 98% over the entire 2D grid of ZM4/ZM5 strain gauge values, which gives us some confidence that the ROC values are accurate.  One thing that gives us pause is that the change in ROC for ZM5 doesn't appear to change linearly in diopters with the strain gauge reading.  ZM4, on the other hand is roughly consistant with a 5 mD/V change though because the beam spot is quite small on ZM4, we are relatively insensitive to its ROC value.

These values give the following overlaps for the x and y direction (our mode measurements indicate we have non-negligible asitgmatism on this path) for propagating the nominal q value from (90815 where ZM2 strain = 3.15) to the q vales from ( 90783) .

The fact that this set of ROC values gives good overlap over the entire 2D grid suggests that these ROCs are a resonable model for ZM4 and ZM5 at these strain gauge settings.

Attached is an a la mode file for doing the beam propagation.  One could do some more intellegent fitting of the data to extract the best ROC estimates; I'm just sorta hand fitting it at the moment.

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