There could be POP clipping outside of the PRC, probably in HAM1. This is just based on the two YAW spot move attempts:

• Louis changed PR3 angle in PRMI with PR2_SPOTMOVE such that the POP_AIR moved in +X direction by ~1.7mm and POP_X_SUM dropped: alog 91702
  • (Skip this if you're in hurry: Louis moved PR3 by +2.1urad. The beam position at HAM1 POP viewport should have moved by about 1.7mm in +X direction (the change from black to red path in POP_beam_path.png, beam position is on the left side of POP_beam_spot_pos_VS_PR3.png), DC power in POP_X_SUM dropped to nothing.)
  • (Skip this if you're in hurry: This only moved the beam position at in HAM3 by 100um or less.  The beam radius after 3" fixed mirror is pretty much 2mm. Hard to imagine that this causes a large clipping.)
  • (Skip this if you're in hurry: In PR2_SPOTMOVE state, you move PR3, the guardian moves PR2, PRM and IM4 such that PRC alignment is still intact without changing ITM-PR3 line and without changing IM3-IM4 line. )
• I changed PR3 angle alone in single bounce without any automation such that the POP_AIR moved in -X direction by a HUGE amount (~14mm) and POP_X_SUM only mildly increased by about 14%: alog 91647
  • (Skip this if you're in hurry: I rotated PR3 by -8.8urad. I didn't use PR2_SPOTMOVE so the calculation details are different but this was a huge change in the opposite direction (14mm -X direction on the HAM1 POP_AIR viewport).)
  • (Skip this if you're in hurry: Even then, the beam motion in HAM3 was 1mm or less.)
  • (Skip this if you're in hurry: POP_X_SUM only saw a mild increase. See the right side of POP_beam_spot_pos_VS_PR3.png.

One hypothesis is that the POP path in HAM1 is too low as of now.

When we set up the HAM1 POP path in air in April, the green beam was too high and it was missing the top periscope mirror in HAM1. We used pico in HAM3 to bring the path down (alog 89745). It never made sense and we didn't know why that happened, but we believed that the PR3 angle we were using at the time was good and stuck to that angle.

However, IF PR3 angle in PIT at the time had been wrong, and IF we were now somehow closer to the good PR3 angle in PIT, the entire path would be too low as a result of the April pico adjustment.

In this scenario, the HAM1 top/bottom periscope mirror and the dichroic might look like shown in the bottom of beamPos.png. In this cartoon, the beam size, beam separations and the mirror size are to scale, though we don't know exactly where the beams are. There could be other places where IR is clipped at the bottom, but HAM1 periscope mirrors are most likely because of 45 deg PIT angle.

J. Kissel

I found the SPI L MEAS and REF IFO signals -- namely in its unwrapped phase signal form -- off in the weeds this morning at ~1700 [rad] and ~1000 [rad], indicating that the phase unwrapping algorithm needs to be reset.

I'm probably just gathering statistics here rather than identifying a cause, but since the system is still new, I figure calling out *when* and "what else was going on?" the SPI longitudinal (L) phase signal shows events in which the unwrapping algorithm glitches or drifts off into the weeds is worth it. There were two back-to-back phase excursions on Wednesday 2026-08-26 17:16 and 17:17 UTC (10:16a and 10:17a local PDT). 

Here're a few trends of *some* channels that I thought might be the obvious culprits -- 
    (1) Did the HAM2 or HAM3 (H23) ISIs trip? No.
    (2) Was there large excess motion or glitches in the H23 ISIs? No. (Only X is shown, but I checked Y, Z, RX, RY, and RZ and they also don't show anything)
    (3) Did the SPI's optical levers see anything? Yes, but not excellently correlated.
    (4) Was there main IFO laser light scattered from within the chamber into the SPI? Doubtful. While the IMC was struggling to lock, locking events (i.e. flashes on MC2 TRANS) are not obviously correlated.

I only show the MEAS_A raw phase signal (first row), but the trend of the unwrapped phase shows you that all PDs saw these glitches.

Zooming out, look at the second trends, the phase signal shows that it was "buzzing" at a max and min of -2*pi and +2*pi through out a time from 17:11:32 UTC to 17:17:44 UTC -- which looks very suspiciously like some excitation.
BUT -- the phase excursion doesn't happen until ~80% of the way through whatever excitation this is...

As of this morning -- There haven't been any unwrapped phase excursions since this one.

I've reset the phase unwrapping algorithm on 2026-08-31 16:43 UTC but hitting the H1:SPI-H23_IFO_PHASE_UNWRAP_RESET button, available to hit on each of the MEAS_IFO and REF_IFO CONDITIONING screens, linked from the SPI OVERVIEW.

Summary: QOSEM QPD difference channels are sitting -x2-3 higher than shot noise even at high frequencies, but the measured dark noise is well beneath the shot noise level. Doesn't say much about source of noise, but has to be somewhere in the sat amp or on SUS QOSEMs.

This is one in a series of posts investigating the excess noise seen on the BBSS M1 QOSEMs. In short, at both LHO and LLO, the noisefloor of the QOSEMs appears to be around 8pm/rtHz at 100Hz, quickly increasing to 50pm/rtHz by 1Hz; where we expect the noisefloor to be flat at ~5pm/rtHz across this bandwidth. See more details in LHO alog 91466. 

Here we look at the voltage noise spectrums as measured out of the sat amp at LHO. In Figure 1, we plot the raw QPD sum, X difference and Y difference signals as produced by the sat amp (See the schematic for more details D2500190). The signals have been dewhitened. The difference channels, which give the displacement readout, are sitting a factor of ~2-3x above where the expected shot noise levels is. This is while the measured dark noise of this exact chassis is well below the shot noise level. Note that this measured chassis dark noise was taken prior to the whitening filter changes of ENG Log 1028, so there is a possibility is that these component swaps effected the dark noise, but this is unlikely.

Unsurprisingly, this indicates the problem is somewhere in the sat amp or on the sus QOSEMs, polluting noise into the difference channels. 

(Note: sum channel appears to sit below shot noise level because its an in loop signal due to the sum to led current feedback, see schematic) 

TITLE: 08/31 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, 3mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.07 μm/s 
QUICK SUMMARY: A few dust alarms for the optics lab, EX VEA temp is still  swinging 3F diurnally, all else looks OK.

Following on from yesterday's alog #91730 today I turned off the JAC Heater controller and switched the gain back to -0.1 and the second pole at 1Hz off also.

I then updated the JAC heater guardian so it switches on and off the Beckhoff JAC Heater Controller and also adds in the normalised control signal from the length feedback to the JAC PZT as an error to the Heater control signal.

The code that does this is:

class HEATER_SERVO_OFF(GuardState):
    index = 20
    request = True
    def run(self):
        ezca['JAC-HEATER_CONTROL_LOOP_SWITCH'] = 'Off'
        ezca['JAC-HEATER_CONTROL_VOLTSOFFSET'] = 0
        if beckhoff_check():
            return True
        else:
            notify('Heater off! Check Driver and Beckhoff controller.')
            return False

class HEATER_SERVO_ON(GuardState):
    index = 1
    request = True
    def main(self):
        self.pzt_fb = ezca['JAC-PZT_DRIVER_VOLTS']
        self.pzt_low = ezca['JAC-PZT_DRIVER_PZTHIGH']
        self.pzt_high = ezca['JAC-PZT_DRIVER_PZTLOW']
        self.servo_setpoint = ezca['JAC-HEATER_CONTROL_SETTEMP']
        self.in_loop_sensor = ezca['JAC-HEATER_THERMISTOR_1_TEMPERATURE']
        self.sensor = 1

    def run(self):
        if beckhoff_check():
            notify(f'Servo on with set temperature: {self.servo_setpoint} deg.')
            ezca['JAC-HEATER_CONTROL_LOOP_SWITCH'] = 'On'
            if ISC_library.JAC_locked():
                ezca['JAC-HEATER_CONTROL_VOLTSOFFSET'] = (self.pzt_fb/(self.pzt_high - self.pzt_low))
            else:
                ezca['JAC-HEATER_CONTROL_VOLTSOFFSET'] = 0
            return True
        else:
            notify('Heater off! Check Driver and Beckhoff controller.')
            return 'HEATER_SERVO_OFF'
                
edges = [
        ('HEATER_SERVO_ON', 'HEATER_SERVO_OFF'),
        ('HEATER_SERVO_OFF', 'HEATER_SERVO_ON'),
        ]
 

It is necessary to normalise the PZT fb signal by the total range of the PZT HV driver before adding the signal into the error point to normalise it.

The code should only include the offset from the PZT error point if the JAC is locked, this is because we don't want it adding random offset while the pzt is scanning.

However we do still want the JAC heater locked to its set temperature when the JAC is unlocked.

From the image you can see that the JAC-HEATER_CONTROL_VOLTSOFFSET is zero until we get past the scanning state (number 20) in the JAC locking sequence.

I will leave this servo on all weekend to test it with the new guardian control.

TITLE: 08/28 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

At the  begining of the shift ETMy ESD was being restored and then this allowed Commissioners to work on locking (since ETMx is finicky, they were working on using ETMy (which has its own problems) for ALS DIFF---see Elenna/Louis alogs.
LOG:

• 2342-0118 Started Locking work (elenna, louis, sheila)
  • ISC_LOCK taken to GREEN ARMS MANUAL--->ALSy made it to ETM TMS WFS OFFLOADED ( they started locking after they turned Sheila/Marc turned ON the ETMy ESD at EY...Sheila said they probably could have turned it on from the Corner)
    • Due to ETMx, ALSx only went to LOCKING
    • Worked on ALS DIFF with ETMy (which has the issue of a bad quadrant)
• 2347 DONE:  Tour for SRS visitors (mike,daniel)
• 2349 DONE:  EX grounding studies (robert)
• 2352 DONE:  Checking ESD at EY (sheila, marc)

Oli, Elenna

Today, we tried to balance the coils on the BBSS M2 and M3 stages. I chose to use AS_C as an optical lever, since we have previously observed some strange cross coupling on the BBSS oplev and I didn't want to get confused.

Coil balancing steps:

• I put IFO in single bounce off ITMY with 10 W input power
• I centered the beam on AS_C by running SR2_ALIGN in the ALIGN_IFO guardian
• For M2, I changed the length euler to osem matrix to drive a pringle mode, so I made the UR and LL matrix values negative, while leaving UL and LR positive. Then, I drove a beamsplitter length line at 8.125 Hz from M2 test
• I observed the 8.125 Hz peak in AS_C pitch and yaw and adjusted the coiloutf filter bank gains to minimize the line height. I ensured that the absolute value of the gains still summed to 4 during my changes
• Then, I reset the M2 matrix, repeated the same process for M3

I was able to get a 20 dB reduction in pitch and yaw on M2, but only a decent pitch reduction on M3. I should revisit the M3 measurement again, since I was just guessing which way to go with the gains, and there is probably a much more procedural way to go about this.

Bs M2 shows the improvement in pitch and yaw and the final gains.

BS M3 shows the improvement in pitch and little improvement in yaw, also final gains.

I SDFed these coil gains (91735)

I had previously measured the L2P and L2Y coupling on M2 and M3 before balancing the coils. I remeasured the transfer functions afterwards, again using single bounce to AS_C. There was only a significant difference in the M3 L2Y coupling- I was unable to measure it at all, despite using the same drive as before. I couldn't bump up the measurement drive since I was close to falling off AS_C.

I have attached screenshots of each measurement. The blue reference traces are from before the coil balancing.

I will fit these measurements and implement them in the drivealign matrices. Then, we can check the decoupling of the L2A during PRMI/DRMI locking.

Here are some SDFs of BS, ASC, and LSC before SDF revert today.

FAMIS task complete, started both systems at end stations, left the compressor and dryer units run for 2.5 hours each, found a couple of air leaks, fixed the leaks and the dew point for both systems look good.

Posting some initial plots of SPI DIFF L, doing my best to line up with my results here with alog 73976, where Jeff looks at IMC F length in hz/rthz and compares that to ISI motion. On the attached image, I show spectra for the differential HAM2-3 X super sensors (calculated online in seiproc, using blended cps and gs13s from each chamber), HAM2 and 3 X gs13s and IMC F, all calibrated to hz/rthz using Jeff's factors from 73976. H1:SPI-H23_DIFFDISP_MAIN_OUT_DQ is also calibrated to hz/rthz using the same 70.551 hz/nm Jeff calculated for the ISI. With that calibration, SPI DIFFDISP is still off from the other sensors by about a factor of 3. 

For the second image, I made a new copy of Jeff's template from 2023, re ran it for last night and added SPI DIFFDISP. We don't have CARM yet, so it's not complete, but I updated references. Again, I used Jeff's 70.551 calibration factor to convert SPI DIFFDISP from nm to hz. SPI seems to agree better here, so I'm not sure what the differences are from from first plot. 

Since we were going through sdf revert today I accepted some JAC ASCIMC and LSC model diffs. See first two images.

The next image is some slow controls settings we want to stay constant when the Bekchoff computer restarts. I didn't accept the pole value as I am still making changes to the heater servo this pertains to.

The last picture shows that i unmonitored the input switch, FM1 and FM2 switches on the JAC-L_SERVO filter bank. These are switched on by the guardian when we lock the JAC so we don't want the JAC to unlock when we sdf revert (as happened today before I made this change to the sdf monitor).

Jennie W,

Last night I added a second pole to the JAC controller with the view to increasing the damping. It has not helped (JAC temperature is still oscillating after ~20 hours).

This is no improvement on how long it took to damp when we increased the set power of the JAC on Tuesday 18th alog #91587.

After thinking about it a bit more and comparing the temperature stability before and after I increased the gain magnitude of the servo (also on Tuesday 18th), I think our gain is too high and causing the system to oscillate.

I think the order of operations over the weekend is to remove the second pole, turn down the gain and then set up the guardian node to add in the PZT feedback signal to the heater controller error point. I will test this over the weekend when it won't affect corner commissioning.

TITLE: 08/28 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Corey
SHIFT SUMMARY:

• Started out doing some clipping investigations in single bounce and SR2 AS_C centering on - 91727
• Locked PRMI, maximized by hand, then Louis started spot measuring on PRM, then OLGs on MICH, PRCL - 91726 , 91724
• BS osem calibrations
• PRMI locking but with ALS locked off resonance
  • To get here we went through SDF revert after checking SDFs first

LOG:

I've made plots comparing the M1 stage BSFM BOSEM noise to the BBSS QOSEM noise to see how much better we are. This is similar to the plots TJ O made in 91466. During the time the BBSS data was taken from, we did have the LED sum current feedback switched on, but comparing our BBSS QOSEM noise to the two QOSEM noise floor plots (taken from G2501105 slide 29), it really looks like we are currently being limited by the constant LED current, as if we didn't have the feedback on at all.

We know the sum current feedback loops are doing something because when we first turned them on, they adjusted the sum counts on two of the osems that were reading too high of counts, but based on these plots it doesn't look like they're doing much? TJ O and I will talk with Tom to investigate more.

Results:
/ligo/svncommon/SusSVN/sus/trunk/BBSS/H1/BS/SAGM1/Results/2026-07_OLG_tfs_4_BSFMvsBBSS/allDampRegressCompare_H1SUSBSFMvsBBSS_M1_NoiseComparison_1435435038vs1469227619-1200.pdf
r13134

Loop suppression used to divide out:
BBSS: /ligo/svncommon/SusSVN/sus/trunk/BBSS/H1/BS/SAGM1/Data/Data/2026-07_OLG_tfs_4_BSFMvsBBSS/2026-07_H1SUSBS_M1_CDBIOState1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz_OLGTF.xml
BSFM: /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Data/2023-07-18_1740_H1SUSBS_M1_CDBIOState_1_OLDampingON_WhiteNoise_{L,T,V,R,P,Y}_0p01to50Hz_OpenLoopGainTF.xml

In an attempt to look for obvious clipping in the PRC, I scanned around +/-150 urads from our PR3 alignment while in single bounce and with SR2 following along to keep AS_C centered. This was a painfully slow process as I would move PR3 until SRC2 would near its limiters, wait for it to settle down, then move again. I ended up bumped the SRC2 gains way up to help speed this up, but it only helped a bit. 

I saw no signs of clipping in the +/-150 range, so I continued in yaw until AS_C nsum finally started to decrease. This didn't happen until +500urad in Y from our starting point. We stopped here to run some more pertinent tests. I reverted all alignments back to before this test.

At Sheila's suggestion this morning I measured the beam spot position on PRM in PRMI. The drivealign gains that reduce the A2L coupling are P:0.38, Y:0.81. I used the same procedure as in 91701. This corresponds to an offset from center of 0.713 mm in PIT and 1.52 mm in YAW.

Here are MICH and PRCL OLGs from today while in PRMI.

The annulus ion pump for BSC9 just railed, about 15 minutes ago.
Nothing to do for now, but we will asses ASAP to see what is wrong with it.

[Jim, Shoshana]

Yesterday when I went to put the cover on the CRS to get it ready to move to the clean area right next to HAM3, I noticed one of the flexures (SN 15) was broken [picture attached]. It's unclear how this flexure broke as it had been locked since last Wednesday (?), and it is strange that only one flexure broke.

We decided that it would be better to install a new pair of flexures and re-suspend next to the chamber rather than in the temporary clean room to reduce the risk of them breaking again. So today we wheeled the table the CRS is on to the space next to HAM3 and I re-suspended the CRS there and roughly balanced it.

Following the procedure outlined in E2600210 and work permit 13356,  we moved the CRS to the table and lined everything up so that the CRS baseplate can be bolted directly to the table in one spot.

We installed the fiber feedthrough, and dealt with all the cabling (fiber and DB25) that required Jim to be physically inside the chamber and we'll install the rest of the cable clamps which we can reach from outside the chamber tomorrow and finish connecting all the cables and dog clamping the CRS down (hopefully)