TITLE: 09/01 Eve Shift: 2330-0045 UTC (1630-1745 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY: Commissioning ended early today. Not much luck with IR DIFF today. Camilla did the transition to laser safe this afternoon so the LVEA is in LASER SAFE and ready for tomorrow's activities.
LOG:

Louis, Sheila, TJ, Camilla, Oli

We have been working on changes to lock ALS DIFF on ETMY.  

• We put the negative sign in the LSC output matrix to account for the DARM sign flip from switching arms, we will try to use the same bias and filter signs elsewhere because that seems easiest to keep track of. 
• On Friday we added a flag to lscparams:  no_ETMX_actuation to be set to true when we don't want any actuation on ETMX (basically only for this week when we have a rubbing issue), which also sets a flag that determines which ETM to use for locking ALS DIFF,     ALS_ESD = 'Y'.  We will need to clean this up a bit, but there are two slightly different purposes for the two flags, because we may want to run ALS on ETMY even once the ETMX suspension is fixed and can run slow feedback and WFS. 
• Filiberto got the ESD high voltage driver working: 91750
• Oli and TJ re-ran the baffle align scripts to reset the alignment of the TMSs and ITMs, since we may have wandered off with the X arm alignment with some ETMX shifts that happened on Friday:  91747
• the ETMY LR electrode does not work: 43053.  We changed the EUL2ESD matrix to only drive LL and UR to reduce the cross coupling to pitch from our length drive. (screenshot attached).  
• ALS COMM locked without any issue. This stayed locked while we locked and unlocked ALS diff many times, this is a nice feature compared to locking DIFF by actuating on ETMX.
• ALS DIFF we were able to keep locked by manually setting ALS Y to NO_SLOW_GR_WFS, and setting the DARM gain to 4.  It should be set to 400. 
  • Ramping the gain up to 8 rings up a 1Hz instability after ~10 seconds. 
  • ramping gain to 40 or 400 instantly breaks the lock, probably saturating the ESD.  
  • We tried copying the L1 L2P from ETMX, and turned off the L1 L2Y (was a scalar -0.002) neither of these things seemed to change the outcomes. 
  • We can leave the DARM1 gain at 4 and increase the L3 drivealign gain to 2.  This may be because our UGF is so low that L3 doesn't come above unity gain. 
  • We got a few points of OLG measurement with the gain at 4, attached. 

TITLE: 08/31 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

• Morning started out trying to lock the IMC. The IMC was set to DOWN on Saturday, but in the down state the triggering is still on, so it was triggering the rest of the weekend and the WFS were following. I set the trigger threshold in DOWN to be an absurd number, then Jenne moved the MCs back to their alignments before it was set to DOWN. Then it locked.
• The remainder of the day was spent converting ALS_DIFF to use ETMY
• EX VEA HVAC changes to help stabilize the temperature - 91751

LOG:

CRS_HAM3 and SPIH23_STAT have been enabled and started. There will be a DAQ restart tomorrow to get their freshly created channels.

CRS_HAM3 - Shoshana had written the start of this node earlier, I started it up and made a few edits to get it to work. Jim and I will be making changes to a few of the tests and testing it over the coming weeks.

SPIH23_STAT - A status node to inform of the state of the SPI system. This node is currently empty but will be filled in as person power and time become available.

Both of these nodes have been added to the overview (see top right corner with other STAT nodes), and the alphabetical overview has also been updated.

It took a couple tries last week, but I have taken HAM2&3 calibration transfer functions for SPI QPA and QPDB for pitch and yaw. I did this by using the  excitation in awggui that we have used for the CRS calibration using amplitudes similar to what Huyen used recently, located at /ligo/svncommon/SeiSVN/seismic/HAM-ISI/H1/HAM3/CRS/Templates/dtt/ryexc2.txt. For RY I used an amplitude of 7e3, for RZ I used an amplitude of 10e3. Isolation loops were engaged on both ISI's and they were running nominal blends (no crs on HAM3), but sensor correction and cps diff were both off.  For each measurement I've saved the excitation and relevant sensors timeseries into mat files that I am adding to SeiSVN/seismic/Common/SPI/DATA, as well as scripts for each excitation to get the data, save the timeseries structure and plot the tfs.

The four attach plots are the tfs for each excitation in the order HAM2 RY, HAM2 RZ, HAM3 RY, HAM3 RZ. For each tf, the SPI and CPS seem to agree very well over a few mhz to ~.2hz, the gs13s go a bit higher in frequency, but aren't good witnesses much below .1hz. On each plot I've indicated amplitude  of the spi to cps tf at one frequency point, I think the calibration should be the inverse of these values. I don't remember the units of the QPD channels, it's not cts. 

From those numbers I get:

HAM2 pitch calibration for QPDB is 19829 nrad/?

HAM2 yaw calibration for QPDB is 20400 nrad/?

HAM3 pitch calibration for QPDA is 231430 nrad/?

HAM3 yaw calibration for QPDA is 237700 nrad?

I think the HAM3 pit calibration is roughly inline with the one Arnaud calculated.

Excitations were all ~40minutes long. The timestamps for each injection are:

HAM2 RY: aug 28 2026 0:29:55 utc

HAM2 RZ: aug 28 2026 1:07:29 utc

HAM3 RY: aug 28 2026 2:00:00 utc

HAM3 RZ: aug 28 2026 2:49:14 utc

 Jackie, Oli

Jackie finished retesting the modified HAM-A coil driver chassis that had failed (91418), and they all pass now. Four of the chassis (S1200608, S1201155, S1201162, and S1201165) have the C6 and C20 capacitors as 2.2nF instead of their nominal values, which explains why they deviate from the ideal model at higher frequencies.

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.

[Elenna, Louis]

This a late alog from work done on Friday. Elenna and I were trying to get ALS DIFF to work with ETMY since we are not actuating on ETMX right now. During this process we accidentally kicked the ETMX suspension twice on Friday afternoon (my mistake). This has been shared with Oli, who plans to retake the ETMX health check TFs to determine whether these kicks resulted in any material changes there. Updates regarding getting ALS locked using ETMY will come in another log as that work is ongoing.

Temperature swings at EX have been on the extreme side since powering on cleanrooms in prep for upcoming work. Zone 3 heater coils, which feed the VEA initially had A, B and C temp sensors online. I have since removed two of the three (A & C). Temperature control for the VEA will now to driven solely by sensor B. Will monitor how this changes in the coming days.

R. McCarthy T. Guidry 

WP 13577

Sheila reported the EY ESD bias was not responding. Readback monitor shows output ~200V regardless of requested voltage. I checked the HV and LV power supplies. Both were powered on. One thing to note, the current draw on the positive 430 and negative 430 power supplies were not the same. I went out to the VEA and verified connections near the flange. The shrink tubing used to isolate the SHV connectors from the cable tray were not installed. I reinstalled them. I verified led lights on both the HV and LV ESD drivers. Both look fine. I enabled and disabled the HV outputs on the UK HV driver and heard the relays switching. Next, I powered cycled the chassis by removing the ±18V with the HV outputs disabled. I disconnected the first two SHV cables (Bias and one of the quadrants). To test the remote enable, Louis enabled the outputs from the control room. The bias slowly ramped down to -430V. First Quadrant went to 140V. High voltage disabled. SHV cables reconnected and repeated to drive the outputs. Louis confirmed the bias readback monitor is responding.

F. Clara, L Dartez

The annulus ion pump for BSC10 railed late last night, around 8:50 pm local time.
Nothing to do for now, but soon we will check the annulus ion pump to see what is wrong with it.

Summary: These is no correlation between the DC level of the QPD difference channels and the output voltage noise, suggesting excess resistor noise is not to blame.

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. 

Thus far we have rulled out real motion being the casue of this excess noise, as motion measured by the BSC2 GS13's, propagated down to M1 isn't enough to explain it. Leading suspicions are excess noise arrising from the new resistors used in the whitening changes (which in the past have been observed to cause issues, see ENG Log 1028, for more details) or LED noise. A trait of excess resistor noise is a roughly linear increase with increrasing DC voltage across the resistor. As such I would expect a correlation between the DC difference voltage and the noise on the difference signals if this is the culprit.

In Figure 1, we plot the DC level of each of the 12 difference signals from the LHO BBSS QOSEMs, against the voltage noise level of that signal at 15Hz (frequency away from any suspension resonances). Here we see no clear correlation between the DC level and the noise, indicating that its likely not excess resistor noise driving this. 

Summary: We projected BSC2 SUSP motion as measured by ISI GS13's to the BBSS M1. This shows that seismic motion isn't enough to explain the excess QOSEM noisefloor. 

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 motion expected in the QOSEM readouts as driven by seimic motion coupling from the SUSP down into M1. Figures 1-6 attached below show the euler DOF readouts from the QOSEMs, compared against the motion measured at the SUSP by the ISI GS13's propagated to BBSS M1 using the suspension transfer functions. In these plots we see that Longitdualal SUSP motion has the largest contribution to the measured M1 motion, but not enough to explain the raised QOSEM noisefloor. With that said, these plots do show that ideally SUSP motion should be the dominant noise source for BBSS M1 below 10Hz.

This data was taken from LHO at T0=1470725000.

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.

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.

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.