TITLE: 09/29 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

Quiet shift with only a brief (& easy) drop from Observing due to SQZ.

Otherwise, locked the entire shift for a lock going on 21.75hrs (so no opportunities to shutt of Annulus Ion Pumps for HAM5/6).
LOG:

• 2339-2350 RyanC dropped by the VPW to check his tire pressure
• 0000-0011 SQZ lockloss & quick recovery (Camilla also left notes in mattermost if there was any troubles with the sqz and locking)

At the top of the hour (within 15seconds), the Squeezer unlocked and took H1 down.  Tony was in here and thought the timing was odd with it happening close to the top of the hour!  (he saw that the PMC went down at 00:00:15).  

The Log for the SQZ MANAGER also notes the PMC as the cause (w/ a message of "LO railing!").

I slowly got SQZ windows opened & got the wiki up and started recovery by Steps:

• #1:  Taking the SQZ MANAGER to DOWN.  Everything came back 
• #2:  Bringing back SQZ_PMC, SQZ_SHG, SQZ_OPO_LR and then SQZ_CLF_LR nodes all to their NOMINAL states
• #3:  This step is where I got a little confused.  The instructions say to take the FC node to GR_LOCKED (got there w/ no problem).  But then the instructions say:  "Trend H1:SQZ-FC_TRANS_C_LF_OUTPUT, if it's peaks are less than 100, follow instructions in below "Issues with SQZ_FC Guardian""."
  • Well, for me, this channel "flat-lined" at about 45-46 counts for GR_LOCKED (I did not see peaks), and this channel has been like this (under 100) for weeks (see attached).
  • So, I opted to NOT follow the Steps for Issues with SQZ_FC Guardian, and at this point, I just took the SQZ MANAGER to FREQ_DEP_SQZ, and this got squeezing & observing back.

TITLE: 09/29 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: We stayed locked the whole shift, 16 hours.
LOG:                                                                                                                                                 

• 15:31 - 18:35 UTC We dropped Observing to do some commissioning, including some PEM and SQZ tests.
• 19:21 - 21:21 UTC SEI to useism
• 20:06 UTC GRB-Short E605563
• 21:22 UTC Optics lab yellow 0.5 dust alarm

TITLE: 09/29 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 5mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.41 μm/s 
QUICK SUMMARY:

Hand Off from RyanC with:

• Target Of Opportunity:  If H1 loses lock and a member of the VAC crew is here, let them know so they can climb on a chamber and adjust a valve.
• H1's been locked over 16hrs, with notes that locking has been straightforward (other than notes of SRM WD trips as of late).
• Seismically, primary µseism band is elevated (mostly just under the 95th percentile). 

During facilities annual flow test and inspection of all site fire hydrants, it was noted that hydrant L9, which resides on the vertex interior nearest the FCE was not fully closing and bleeding a small amount of water. This issue was made worse when an outside group was invited to help troubleshoot the problem and overtightened the stem to the point that it was completely broken. Following this, I (with the assistance of locate) located the service valve and isolated supply of firewater to the hydrant. Given the age of the hydrant, repairing it was cost prohibitive, so a new hydrant was installed. 

It is probably worth mentioning here that the thrust block placed back in ~97' was sizeable. Almost too large for the mini excavator to remove. This came as a big surprise to all involved and should be considered in the future if any hydrant excavation takes place. Also, the as-built location of this hydrants service valve is incorrect. The drawing details the valve being southwest of the hydrant, when it is in fact to the northeast.

E. Otterman R. McCarthy T. Guidry

Sheila, Camilla. Saved to camilla.compton/Documents/sqz/templates/dtt/Fringe_wrapping.xml

ZM2,5 Fridge Wrapping with No SQZ light

As Sheila suggested in 86836, the amount of backscatter we are seeing from SQZ should be due to light from the IFO being backscattered rather than any excess SQZ light. To confirm this I took SQZ DOWN, mis- aligned FC, blocked all three SQZ beams on SQZT0 and re-opened the beam-diverter so that the IFO light could get into HAM7 but there was no SQZ generated light. The ZM2 and ZM5 scatter shelves were the same in both this and the nominal SQZ configurations, confirming all backscattered light is coming from the IFO. Plot attached. This plot does show our ZM5 scatter has increased since 2024, ZM2 is the same.

I did the same with the 30Hz injection too, saved to Fringe_wrapping_nosqz.xml, refs 0-8 are no sqz beams, refs 9-17 are nominal FDS. Plot attached, if anything, the shoulders of the 30Hz peak are larger with no sqz beams, so again, there is no difference. 

ZM2,5 Fridge Wrapping with Different Alignments on OFI_PD_A

In FRS # 35457 and 87071, we theorized that the backscatter could be off the OFI_PD_A which we shows out beam is clipping, when we change the alignment to this PD using ZM4/5, we change the level of light on OFI_PD_A, showing we are clipping and not centered on the PD, but this also changes the level of SQZ so it's hard to compare. Unsure if there's a real difference, plot attached and ndscope. It's possible that with more light on PD_A (less clipping) there is a more scatter and a secondary ZM5 scatter shelf ~25-40Hz. Would want to repeat or misalign more to confirm. 

Other ideas that haven't been done yet: change the temperature of SFI2 and repeat backscatter measurements, repeat above with increased alignment changes the OFI_PD_A changes. 

Mon Sep 29 10:09:29 2025 INFO: Fill completed in 9min 25secs

Note TCs did not saturate at -200C today, weather is changing.

Note that plot is being produced by ndscope-test. The time axis label is no longer being cut.

TITLE: 09/29 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 6mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.42 μm/s 
QUICK SUMMARY:

• We've been locked for 7 hours
• 07:16 UTC Observing
• Secondary microseism is slightly elevated

Got called at 11:50 after PRMI locking failed for the second time. As I was prepping to move some mirrors to try and lock PRMI (initial alignment was done), PRMI locked and then DRMI.

IFO just needed some threat by opservation.

Watched guardian go into NLN as of 07:14 UTC and now OBSERVING.

Reset myself as OWL.

TITLE: 09/29 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Locked for 5 hours. The relock had an odd SRM M3 Wd trip during DRMI acquisition, but once untriped it went through Mich Bright, then PRMI, then it got DRMI. 
LOG:

• 2235 Lock loss
• 0005 Observing
• 0027 S250929c
•  

Looks like when one of the triggers for SRCL turned on, it tripped M3 a handful of seconds later. Another odd thing I'm seeing after I've untripped and tried PRMI is that the triggering seems to be turning on and off rapidly.

1443133532

Nothing obvious.

TITLE: 09/28 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY: Quiet shift, we stayed locked the entire time.
LOG: N/A

The LSC front end has an FPU (floating point unit) error. The recent range drop post glitch looks to line up with a ~50 SNR low frequency glitch as seen on the Omicron plot on nuc27, and 2.5 hours ago there's some extra noise in the low frequency SQZ blrms. The recent glitch look to be from  =< 450Hz, as it's seen only in BAND_1-5.

• 13:16 UTC Observing

TITLE: 09/28 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 4mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.39 μm/s 
QUICK SUMMARY: Locked for almost 7 hours, calm environment.

• 18:22 The SQZ LO lost lock and struggled to relock and delayed the start of the calibration measurement
  • The first issue was the OPO not wanting to lock, following the wiki I started by cycling through DOWN
    • I restored FC2/FC1 alignments based on osems to when we locked the SQZer at the beginning of the lock, no dice
    • I maximized the H1:SQZ-SHG_GR_DC_POWERMON using  SHG_TEC_SETTEMP, accepted in SDF (36.05 -> 35.75)
    • It was still struggling to get a trans of at least 80, it would go right past it. It would get just over 80 then keep adjusting the ISS setpoint and the trans would decrease. I ended up changing the setpoint from 80 to 75 in sqzparams which got it locked.
  • Now the FC won't lock, the green trans is too low, I followed the wiki to maximize it
    • Restored ZM3, moved FC2 to maximize H1:SQZ-FC_TRANS_C_LF_OUTPUT, I couldn't get it above 50. Now it loses it at IR ("CLF frequency out of range")
    • I ran the SCAN_OPO_TEMP state and now it can lock IR
• 19:33 during the calibration measurement it lost lock again
  • The OPO keeps losing lock again. I maximized the SHG temp again, there was a suprising amount of gains still to be had (36.05 -> 35.05). Should I have done this again after running SCAN_OPO_TEMP earlier?
  • FCs not locking again, as soon as the calibration measurement finished it finally was able to hold green lock

Here is a summary of some results from the open loop gain measurements of DHARD Y and CHARD Y, and the implementation of a new CHARD P low pass:

DHARD Y

I measured the DHARD Y open loop gain, results shown here. The dark blue trace shows the original measurement, showing 17 degrees of phase margin and gain peaking of 10 dB. Looking at the loop design, there are three different boost filters applied to DHARD Y, compared here. These boosts in combination seem to be destroying all the phase of the loop. I took a measurement with the 0.9 Hz boost disengaged (FM3), which is shown in the green trace. Then, I disengaged the 0.5 Hz boost (FM4) and remeasured, shown in the red trace. This improved the phase margin to 32 degrees. This obviously resulted in less microseismic suppression. I adjusted the 0.5 Hz boost (FM4) and decided we should operate without the boost in FM3. This plot compares the original loop error signal and RMS with all three boosts (gold), the error signal and RMS without FM3 and FM4 boosts (green) and then error signal and RMS with the updated FM4 boost (red). The RMS increased 50% without both boosts on, the improved boost returns the RMS to that value. There is now more phase margin in the loop. Updated in guardian and ASC high gain script, SDFed (1,2).

CHARD Y

I measured the CHARD Y open loop gain, results shown here. The file had an old reference trace from 2023, shown in bluegreen in the reference. The gray trace shows the first measurement I made today of CHARD Y. The gain appeared to be way too low. I raised the gain to match the old reference, which was a gain increase of 6 dB. Here is a comparison of the RMS of CHARD Y from 14 hours ago (bluegreen reference) and now (red live). The microseism level is the same between these two measurements. Overall, this reduces the RMS of the loop, so I think this is a good adjustment. This is updated in the guardian and ASC high gain script, also SDFed.

CHARD P

I implemented a new CHARD P low pass filter to reduce CHARD P coupling that is apparent in coherence measurements (example).

Here is a comparison of the old controller (red) with the new controller (blue). This replaces the lowpass filter in FM8 with the filter in FM9. I also disengaged the old 200 Hz lowpass that was previously in FM10, as it wasn't doing much. SDFs (1,2). Guardian code and ASC high gain script updated.

The coherence of DARM with CHARD P has reduced, as expected, and increased for CHARD Y, also as expected. I have since created a new lowpass for CHARD Y that should reduce the coherence and is ready for testing at the next opportunity (comparison).

Yesterday I went into the optics lab and re-measured the coupling between input beam motion and PD array. While taking measurements I noticed that the injection could not be seen on the AC readouts of the PDs (example) so I tuned the temperature of the laser via changing the resistance of the controller, I went from ~10kOhms up to 13 kOHms and down to 8kOhms and while I found places where the noise reduced see example of noisy trace here, I couldn't find anywhere with the controller where the trace renamed stably in the non-noisy state. I then decided to tune the pump current down from 130mA to ~100mA and eventually found a somewhat stable place. I still had to wait through some periods of noise to trigger the measurement of the PDs.

I alos increased the modulation ampltitude to 80 mVpp. The counts on the QPD LCD readout were 10672, see image.

When the laser is in its quiet state the AC PD traces should comfortably fit on the screen of the osclloscopes with a 5mV scale, with the laser noisy this is more like 100mV, I also use 100mV scale for the QPD, I didn't change it when I reduced the noise on the laser.

The noisy state for the QPD outputs is here, the quiet state is here.

For each measurement I used a capture range of 400ms on the time axis of the scope and 125 000 samples selected on the 'ACQUIRE' menu.

The final measurements are:

PD 1 - 4 measured at AC: T0012ALL.CSV

PD 5 - 8 measured at AC: T0014ALL.CSV

QPD X, Y and SUM channels measured at AC: T0013ALL.CSV

The two DC measurements are going to be averaged so I didn't wait for a quiet time to measure them.

PD 1 - 4 measured at DC: T0011ALL.CSV 

PD 5 - 8 measured at DC: T0010ALL.CSV

To save you need to click on the menu button and change the resolution to be'Full', the format to be CSV and the channels captured to be 'ALL', the file number will roll over every time you save so you don't need to enter it manually.