PRMI locking summary

[Keita, Louis, Elenna, with input from others]

We locked PRMI again with the stronger BS top mass damping and no oplev damping. I also raised the damping gains of PRM, PR2, SR2 to -1. They have been set to -0.5 for a while now. I have SDFed these gains to -1 to help with locking.

I had some initial trouble locking MICH, and realized that the M3 drivealign gain was incorrectly set. Once I fixed that, it was much better. We need to check the guardian to make sure this gets set correctly.

Using a beamsplitter damping gain of -3 for most DOFs works well. We had some excess 1 Hz motion which I tracked down to having too high gain on BS T, so I've left that dof at -1 gain. SDF 1 2

PRMI locks quickly, and it appears by camera that the BS moves a lot less in this state during locking. However, the buildups were very shaky as we sat in PRMI locked for more than 30 minutes. I looked at the signals and it appears that the largest motion in POPAIR RF18 was around 0.2 and 0.3 Hz. Jim put the beamsplitter ISI in the fully isolated state, and this help reduce the motion.

The rest of the movement occurring while we sit in PRMI seems to be that the BS moves a lot at 0.45 Hz. However this signal is not visible in the top mass osems, so it would probably be better if we could engage MICH ASC.

I had some trouble engaging the BS ASC, which should drive to M2 and M1. I checked the error signals (AS RF45 B Q), and realized it didn't make sense. So I then checked the phasing by driving a MICH length line at 88 Hz. The phasing was very bad, and I fixed it by adjusting the phase by 70 degrees for all four segments. One segment moved the opposite direction of the other three segments, which Keita found was because the relative phase of Q3 compared to Q1, 2, and 4 was off by 180. By flipping the demod phase on Q3, all of th relative phases between the segments was zero. I SDFed these phases.

For good measure I rephased AS A RF45, although I would want to recheck the AS RF45 phasing when we have a DARM signal.

With the rephasing, the MICH ASC error signals looked much more reasonable. I can engage the loops, but the pitch loop runs off after a minute or two, so I might have the gain sign wrong. The guardian is still set to engage MICH ASC FALSE, so it has to be done by hand.

Conclusions from today:

- we can keep locking PRMI/DRMI with no oplev damping

- we can keep locking with high BS damping

- we can have the BS ISI ST2 boost ON when locking PRMI/DRMI

 

***

Right after posting this alog I tried again with MICH ASC.

I feel confident that MICH yaw works with a gain of 0.5. This is flipped sign and slightly larger than the gain setting in the guardian for this state.

I think MICH P works ok with -0.5 gain. I was testing it and all was well until the JAC unlocked itself for a separate reason. It can take MICH P a few minutes to fall over though, so I won't change the guardian setting yet.
However, if you run the MICH ASC, the buildups are much quieter in PRMI.

ETMX L1 LL OSEM investigation continuation explanation

Betsy, Sheila, Camilla, Fil, Oli

The biggest conclusion from today is the concern that we might not be able to really move ETMX without creating the rubbing that seems to be the cause of our L1 LL issues.

Partway through troubleshooting today we changed the EUL2OSEM for ETMX L1 to be the tripod (coil driver switching) version. I only changed this one and not the L1 OSEM2EUL, and have purposely not SDF'd it since we don't know if this is correctly working or if we'll even be able to utilize it. We only did a quick check on whether it was working and it seemed to be super cross coupled, but we didn't look too far into it. I got this matrix from /opt/rtcds/userapps/release/isc/h1/scripts/sus/etmx_l1_out_ll.snap, which is meant to be used when needing to actuate at L1 while swapping the coil driver state for LL.

M0 L2L Transfer function
I took an ETMX M0 L2L transfer function and found that it is seeing rubbing. June 5, 2026 was the last time an M0 L2L TF was taken, and it looks perfect with no rubbing(black trace). This narrows our scope of when we believe something happened to L1 LL osem from between March 5 and August 20, 2026 to sometime between June 5 and August 20, 2026. When I first started the transfer function, LL didn't seem to really be reacting to the excitation even though the other osems on L1 were moving by at least a few hundred counts(L1 OSEMINF). Then 1.5 minutes into the measurement, the LL OSEMINF IN suddenly saw a DC change of 300 counts. At this same time, LR also dropped by ~300 counts, the upper osems saw maybe a bit of motion, and some of the osems on the M0 stage saw movement of up to a few microns as well (OSEMINF_IN, OSEMINF_OUT). 
Data: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGM0/Data/2026-08-25_2030_H1SUSETMX_M0_WhiteNoise_L_0p01to50Hz.xml

R0 L2L Transfer function
We took a transfer function for R0 L2L and found that it also looks like it sees the rubbing. This should rule out rubbing coming from an earthquake stop on M0.
Data:  /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGR0/Data/2026-08-25_2125_H1SUSETMX_R0_WhiteNoise_L_0p01to50Hz_noVoffset.xml

M0 and R0 height adjustments
The LF and RT (Vertical) OSEMs for both M0 and R0 are reading lower than we expect, and although they seem to have been in that configuration for a long time, we're still suspicious of them and wondered if we might be seeing touching due to them being higher than they should be (smaller OSEMINF IN value = more OSEM light occulted by flag). We tried putting Vertical offsets of +/- 200,000 counts in the M0 and/or R0 TEST banks and taking transfer functions, but all the configurations we tried still looked like there was the same amount of rubbing every time.
Some of the measurements we were seeing some 'glitching' happening on LL as well, but for the most part we still weren't seeing much other movement.

	Offset(s)	Data
M0 L2L	M0: -200,000, R0: 0	/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGM0/Data/2026-08-25_2100_H1SUSETMX_M0_WhiteNoise_L_0p01to50Hz_Voffset-200000.xml
	M0: +200,000, R0: 0	/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGM0/Data/2026-08-25_2115_H1SUSETMX_M0_WhiteNoise_L_0p01to50Hz_Voffsetplus200000.xml
R0 L2L	M0: 0, R0: -200,000	/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGR0/Data/2026-08-25_2135_H1SUSETMX_R0_WhiteNoise_L_0p01to50Hz_Voffset-200000.xml
	M0: +200,000, R0: -200,000	/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGR0/Data/2026-08-25_2145_H1SUSETMX_R0_WhiteNoise_L_0p01to50Hz_R0Voffset-200000_M0offset200000.xml

HAM7 Ports Leak Check

(Travis S., Jordan V., Gerardo M.)
We connected the leak detector, Inficon UL5000, to the back the SS-500 aux cart, the leak detector was turned on and left to reach nominal operation.
We started leak checking the viewport on the -Y door, no response from the helium leak detector, but then the leak detector showed a signal when Travis sprayed the +Y door port, signal reached ~ 2.7X10^-09 Torr*L/Sec, but the signal was not fast, it moved slow but with a steady upward trend, we do have a couple of D1100999 viewports, O-ring type.  Travis stopped and we decided to bag the individual ports to leak check, after bagging the ports they were sprayed with helium and no change was noted at the leak detector helium signal.
No leak was detected above the leak detector's background of 2.0X10^-10 Torr*L/Sec.

Attached photo is the initial background.

PCAL End X End station Measurement

Caroline and I went to End X with PS4 and followed the instruction on the DCC doc T1500062.
The Current limit red LED was lit up again. I simply adjusted the voltage down a few thousandths of a volt and the current steadied right up at 10V again. 
The beams were a little offset on the Apature of the RX Sphere when we arrived.  But I did not touch up the alignment this time. I may touch up alignment again next months.
Also we wore gloves this time... that was fun I guess.
 
Commands ran & subsequent output:
anthony.sanchez@cdsws32: python generate_measurement_data.py --WS PS4 --date 2026-08-24
Reading in config file from python file in scripts
../../../Common/O4PSparams.yaml
PS4 rho, kappa, u_rel on 2026-08-24 corrected to ES temperature 299.3 K :
-4.699251194624549 -0.0002694340454223 0.00075040881877916
Copying the scripts into tD directory...
Connected to h1daqnds1
martel run
reading data at start_time:  1471716950
reading data at start_time:  1471717444
reading data at start_time:  1471717888
reading data at start_time:  1471718420
reading data at start_time:  1471719060
reading data at start_time:  1471719400
reading data at start_time:  1471719630
reading data at start_time:  1471720300
reading data at start_time:  1471720660
Ratios: -0.4615405682485709 -0.46591058962067394
writing nds2 data to files
finishing writing
Background Values:
bg1 =        8.879049; Background of TX when WS is at TX
bg2 =        5.011307; Background of WS when WS is at TX
bg3 =        8.896423; Background of TX when WS is at RX
bg4 =        5.129760; Background of WS when WS is at RX
bg5 =        8.965872; Background of TX
bg6 =        0.027675; Background of RX

The uncertainty reported below are Relative Standard Deviation in percent 

Intermediate Ratios
RatioWS_TX_it      = -0.461541;
RatioWS_TX_ot      = -0.465911;
RatioWS_TX_ir      = -0.455518;
RatioWS_TX_or      = -0.460890;
RatioWS_TX_it_unc  = 0.070028;
RatioWS_TX_ot_unc  = 0.067789;
RatioWS_TX_ir_unc  = 0.072976;
RatioWS_TX_or_unc  = 0.075331;
Optical Efficiency
OE_Inner_beam                      = 0.987476;
OE_Outer_beam                      = 0.989974;
Weighted_Optical_Efficiency        = 0.988725;

OE_Inner_beam_unc                  = 0.046927;
OE_Outer_beam_unc                  = 0.047569;
Weighted_Optical_Efficiency_unc    = 0.066821;

Martel Voltage fit:
Gradient      = 1636.904156;
Intercept     = 0.551415;

 Power Imbalance = 0.990620;

Endstation Power sensors to WS ratios::
Ratio_WS_TX                        = -1.078224;
Ratio_WS_RX                        = -1.391522;

Ratio_WS_TX_unc                    = 0.041912;
Ratio_WS_RX_unc                    = 0.038391;

=============================================================
============= Values for Force Coefficients =================
=============================================================

Key Pcal Values :
GS           =      -5.135100; Gold Standard Value in (V/W)             
WS           =      -4.699251; Working Standard Value             

costheta     =      0.988362; Angle of incidence
c            =      299792458.000000; Speed of Light
             
End Station Values : 
TXWS         =        -1.078224; Tx to WS Rel responsivity (V/V)
sigma_TXWS   =        0.000452; Uncertainity of Tx to WS Rel responsivity (V/V)
RXWS         =        -1.391522; Rx to WS Rel responsivity (V/V)
sigma_RXWS   =        0.000534; Uncertainity of Rx to WS Rel responsivity (V/V)

e            =        0.988725; Optical Efficiency
sigma_e      =        0.000661; Uncertainity in Optical Efficiency

Martel Voltage fit : 
Martel_gradient         =        1636.904156; Martel to output channel (C/V)
Martel_intercept   =        0.551415; Intercept of fit of     Martel to output (C/V)

Power Loss Apportion : 
beta          =        0.998895; Ratio between input and output (Beta)  
E_T          =        0.993797; TX Optical efficiency 
sigma_E_T          =        0.000332; Uncertainity in TX Optical efficiency 
E_R          =        0.994896; RX Optical Efficiency 
sigma_E_R          =        0.000332; Uncertainity in RX Optical efficiency 

Force Coefficients : 
FC_TxPD          =        7.900632e-13; TxPD Force Coefficient 
FC_RxPD          =        6.191631e-13; RxPD Force Coefficient 
sigma_FC_TxPD          =        3.624112e-24; TxPD Force Coefficient 
sigma_FC_RxPD          =        2.753947e-24; RxPD Force Coefficient 
data written to ../../measurements/LHO_EndX/tD20260825/ and can be found on the gitlab here. 


 

 

 

OPS Day Shift Summary

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

Very Busy Maintenance Day at the End Stations and the Corner Station. The biggest update is that ALSY now reliably works with WFS Converging! As such, PRMI has been locked consistently with some instability in the BBSS. Commissioners Elenna and Louis are working on improving it in various ways. 

Broken down by station

EX:

PCAL Measurement - Tony and Caroline (PCAL)

• Start Time: 9:55 
• End Time: 12:35
• Details: Needs EX Hazard, ETMX Aligned
• Summary: Success!
• Links: WP 13545, 

ETMX BOSEM Measurements and Troubleshooting - Oli, Fil, Betsy (SUS, EE)

• Start Time: 10:15
• End Time: None
• Details: HEALTH_CHECK state needed for EX Transfer Functions.
• Summary: The TFs taken seem to indicate rubbing in the transfer functions, but OSEM trends seem to imply otherwise. We are still somewhat confused as to what is exactly going on here. This problem has grown to a larger issue that will involve many alogs - will try and update this Alog with these when they come in.
• Links: Alog 91650, Alog 91678

EY:

UPS Access System Replacement - Fil (EE)

• Start: 9:50
• End: 11:40
• Summary: Success!
• Links: WP 13544

Beckhoff Chassis Swap, Repair ALSY WFS Demod RF Level Monitor - Marc (EE)

• Start: 8:40, back out at 11:05 with new ideas
• End: 10:40
• Details: Put SUS_ETMY in SAFE and ETMY ISI in DAMPED as a precaution. Readbacks for two channels are malfunctioning for power in the local oscillator. Troubleshooting pointed to Beckhoff, but a chassis swap seems that this did not fix the problem. Marc has a hunch that he will potentially chase. 
• Summary: Success - faulty connector.
• Links: WP 13548, Alog 91672

Corner:

Gate Valve, Leak Check and Output Tube Gauge Work (Gerardo, Jordan, Travis)

• Start: 8:40, 11:30 (leak checks HAM7)
• End: 10:45 (For Gate Valve and Output Tube Gauge work), 12:00 (Leak Checks HAM7)
• Summary: Success
• Links: WP 13549,

TCS Line Inspection and TCS Inventory Work (TJ, Christina, Camilla)

• Start: 9:20
• End: ~11
• Details: 
  • TCS lines need to be inspected. TJ found glycol dripping along one of the lines that go back to the chiller from the mechanical room. He and Jim are working on removal. 
  • There are old parts and pieces, including an old TCS chiller in the LVEA. These need to be disposed of and inventoried.
• Summary: Success
• Link: Alog 91675, Alog 91674

ITMY Optical Lever Relocated for CHETA:

• Start: 9:15
• End: 10:15
• Summary: Success
• Links: WP 13534, Alog 91667

CDS:

Work stations rebooted

• Link: Alog 91662

Control Room Screens:

• Control room screens had various issues but these were fixed by Erik and Jonathan
  • NUC 28 had a full disk preventing operator control and crashing the computer
  • NUC 20 did not come back after the work station reboot and had to be turned on and manually set up
  • NUC 30 had to be reset
  • NUC 5 plots froze for a bit but a refresh is all it took

Vacuum Electronics Work (Patrick, Jordan, Gerardo, Travis)

• Start: 8:00
• End: 12:40
• Details: Update the configuration and PLC code on H0vaclx to change the BSC8 PT180 gauge from a BSG 450 to a BSC552. This takes the LX Vac readback down for a period of time. DAQ Restart Required After
  • It got delayed, with cooperation with the Vacuum team needed to troubleshoot PT110 (HAM6).
• Links: WP 13532, Alog 91676
• Summary: Success. Only 1 DAQ restart was needed, which was taken care of by Dave and CDS as part of their restart.

CDS DAQ Restart (Dave):

• Start: 12:35
• End: 12:45
• Details: Remove the decommissioned h1daqscript0's CDS LOAD MON channels from the EDC. DAQ+EDC restart needed on a target-of-opportunity. If they can time it with Patrick’s Vacuum Electronics work, then there would only be one restart needed. However, since VAC EE took time, they couldn’t do the restart and by the time they wanted to do their own restart, Tony and Caroline were in the middle of their PCAL measurement at EX. Thus, they are planning to do the restart at around noon, when PCAL is expected to be done. Requires BBSS in SAFE
• Summary: Success! 
• Links: WP 13542, Alog 91671

IOC Container Host Cluster Update (Jonathan):

• Alog 91664, WP 13538

Commissioning/Ctrl Room Work - Started at 12:40 (approx.)

• ISCT1 POP Power Measurement - Alog 91657
• BBSS Damping Loop Lowpass Changes - Alog 91656
• ALSY Locking with WFS - Works!
• ALSX gameplan following ETMX findings of rubbing - Alogs coming soon because this rabbit hole turned into a mole network. - Alog 91678
• PRMI Locking - Works but commissioners are improving it

Other:

• Monthly Churn Test of Fire Pumps - Eric (FAC) - WP 13541

LOG:                                                                                                                                                                                                           

Start Time	System	Name	Location	Lazer_Haz	Task	Time End
15:24	FAC	Kim	EX	N	Technical Cleaning	16:26
16:19	EE	Fil, Oli	EX	N	Troubleshooting	16:47
16:23	VAC	Jordan, Gerardo	LVEA	Y	Gate valve work, Output Tube Guage	18:01
16:23	TCS	TJ	LVEA	Y	Chiller disposal, Line inspection	17:23
16:25	FAC	Kim	EY	N	Technical Cleaning	17:52
16:25	EE	Marc	EY	N	Beckhoff chassis swap	17:47
16:27	FAC	Eric	Wood Shop	N	Fire pump	16:54
16:39	TCS	Jason, Camilla	LVEA	Y	IY Oplev table move to make room for CHETA	17:17
16:41	PCAL	Tony, Caroline	PCAL Lab	N	Grabbing things for EX PCAL Measurement	16:55
16:47	EE	Fil	EY	N	UPS Access System replacement	18:58
16:57	PCAL	Tony, Caroline	EX	Y	PCAL Measurement	19:45
17:11	FAC	Richard	LVEA, Y-arm	N	Walkabout + Y-arm padding accessibility check	17:59
17:18	VAC	Travis	LVEA	Y	Gate Valve and Output Tube Guage work	18:01
17:48	TCS	TJ, Christina	LVEA	Y	Planning of diisposal of old TCS equipment	19:21
17:52	FAC	Kim	LVEA	Y	Technical Cleaning	18:38
18:01	TCS	Camilla	LVEA	Y	TCS Equipment Disposal/Removal/Recycle	19:21
18:08	EE	Marc	EY	N	Continued troubleshooting of local oscillator malfunction	18:55
18:44	VAC	Gerardo, Jordan, Travis	LVEA	Y	HAM7 Leak Checks	19:03
19:45	FAC	Randy	EX	N	Garb room curtain pack-up	22:43
19:46	PCAL	Tony, Caroline	PCAL Lab	N	Pack up PCAL equipments	19:49
20:54	PCAL	Tony, Caroline	PCAL Lab	Local	PCAL Measurements	22:37
20:57	TCS	Camilla	Optics Lab	N	Tidying	21:34
22:52	EE	Marc	LVEA	Y	HAM6 Chassis Inspection	22:59
23:12	TCS	TJ	LVEA	Y	Inventory of chiller equipment SNs and then chiller line management	01:12
23:22	SUS	Sheila, Betsy	EX	Y	Troubleshooting ETMX Issues	01:22
23:25	VAC	Gerardo, Jordan	EX	Y	Parts search	01:25

h1daqnds1 daqd restart related to client request volume

Jonathan found a correlation between the number of NDS requests around 15:15 this afternoon and the crash of nds1-daqd. Plot show number of processes and cpu usage against nds1-daqd uptime. Logs suggest a nds client rapidly asked for data, possibly on cdsws37.

ETMX L1 UL Jumped ~2000 counts twice with Earthquakes

Besty, Oli, Ibrahim, Camilla. Follow on from 91650.

Betsy said that the OSEMINF INMON channels should not change much (over last two years has been < 300 counts) but twice in the last 2 months H1:SUS-ETMX_L1_OSEMINF_UL_INMON  has jumped ~2000 counts, both at the time of large earthquakes and when the EX ISI tripped:

• 24th June 2026 15:15 UTC- plot
• 17th July 2026 14:58 UTC - plot

Strangely this is not the same quadrant that has been the non responding (91650).

PT180 changed to BCG 552, PT140, PT191, PT192, PT193 removed

WP 13532.

Dave, Gerardo, Jordan, Patrick

The EtherCAT configuration and PLC code on h0vaclx have been updated to change the PT180 gauge on BSC8 from a BCG 450 to a BCG 552. In the process I found out that PT140 had been removed in the past month or so, so I also removed it from the configuration and code. I also had errors from PT193, and learned that it was potentially broken, and along with PT191 and PT192 was slated for removal. I therefore asked Jordan to disconnect these from the EtherCAT hub, and removed them from the EtherCAT configuration and PLC code as well.

When I tried to take the system to OP, the second section of the CU1128 EtherCAT hub kept going into an error state. I eventually tracked it down to what I think was a mismatch between the vendor id of the hub in the TwinCAT solution and that of the actual hardware. Oddly I don't remember this being an issue in the past. I could find no indication of what the vendor id was in the solution, other than what the error was reporting, or how to change my script to make it match. I found a way around this by selecting and choosing 'change to compatible type' for each of the three parts of the hub in the generated solution, rescanning the IO tree, and when it showed mismatches in the version numbering, used the dialog box to change what was configured to what was found by the scan. This seemed to fix the problem.

Dave restored the PID and other settings from SDF. The channels have been updated in the DAQ. The tripped high voltages have been turned back on. I have closed the work permit.

TCS chiller lines inspection

FAMIS (no number atm)

This morning I inspected the lines starting from the chillers and then went to each table. Everything looked good: no leaks, stress on pipes, etc.

I did have a scare when I saw liquid pooling around the Leak Detection Dixie Cup (LDDC) on the mech room mezzanine. Turns out it was glycol from the HEPI lines and it just happened to land next to the LDDC after dripping down an extention cord, dripping down two pipes and finally resting next to the cup. Jim was notified, picture sent.

CS HEPI Plumbing leak on Mezzanine

TJ reported this morning that he found glycol from the CS HEPI plumbing on the mechanical room mezzanine this morning. I went and looked, there is a large puddle where the the pump station manifolds are joined to the LVEA piping by some thick rubber hose clamped by pipe clamps. The supply line seems to have a very slow seep that has been dripping onto the mezzanine deck for an unknown period of time. Puddle is in the first image, the leaking connection is the lower yellow boot on the stainless pipe in the second image. I put down a bunch of pads to soak up the glycol and cinched down the hose clamp on the side of the boot that is leaking about 1/4 turn. I will come back and clean up more of the glycol and try to put some clean padding down to try to help with assessing how bad the leak is or if tightening the hose clamp fixes the leak. If this needs replaced it will be a huge mess and probably require shutting HEPI down for an extended time. If that is the case, we can probably lock all the HEPI's in the corner (like LLO does). I would prefer sealing the seep with epoxy if possible.

ALSY WFS Demod Repair Complete

WP13548

Intiially Fil replaced the ALSY WFSA Quad Demod S1001021 with one of our new spares S2600094 due to bad readbacks.  These bad readbacks were caused by corrisoin and shorting due to mouse urine, see first image.  We cleaned up the malfunctioning unit and it tested good.

The spare that was installed exhibited some of the same characteristics, bad readbacks, so troubleshooting lead us to replace the Beckhoff modules.  This did not solve the issue, so we went back to look at the connections, and found that the spare exhibited bad LO and RF monitor channels when a 6k resistor was placed on the bad channels, absent the Beckhoff.  This lead us to believe there was an issue with the chassis, so we swapped back the original WFSA Quad Demod S1001021 and investigated the sprae S2600094.  Visual inspection lead us to these poorly installed zero ohm resistors, see second image, that are positioned right before the final DB9 on the IQ Demod board.  We are now investigating all of the new Quad Demods for the same issue.

Marc P, Fil C, Keita K.

CDS Maintenance Summary: Tuesday 25th August 2026

WP13536 SUS BS additional fast channels

Oli, Dave:

We installed Oli's latest h1susbs which added 13 new fast DQ channels, most at 2k, some at 256Hz. h1susbs model was restarted at 12:37 and the DAQ soon after.

WP13535 Add DAQSTAT channels to DAQ

Dave:

The new DAQSTAT's non-string records were added to the DAQ as EDC channels.

WP13542 Remove h1daqscript0 epics-load-mon channels from DAQ

Dave:

A new H1EPICS_CDSMON.ini was generated sans DAQSCRIPT0 channels. DAQ restart was needed

WP13532 Upgrade VAC LX Beckhoff and IOC, update PT180, remove obsolete gauges.

Patrick, Dave:

Patrick installed the latest VAC LX code and I installed its new INI file into the DAQ. 

Gauges removed: PT140, PT191, PT192, PT193.

PT180 was modified, some channels removed, some added, some stayed the same name.

Note that PT180's MOD1 and MOD2 gauges have been reversed

	Before Today	Now
MOD1	Had been BSC8 gauge, recently has been reading zero	reads ~900
MOD2	Had been reading ~740	Now is BSC8 gauge, reading 7e-08 Torr

DAQ Restart

Jonathan, Dave

We did a DAQ restart, 1-leg and EDC at 12:39, 0-leg at 12:41. Frame writers (which are not restarted with the new code) had caught up with the new run number and were writing identical full frames at 12:44.

HAM3 CRS Noise Budget

Started making a new HAM3 noise budget with the CRS included

• Modified pre-exisiting NB: /ligo/svncommon/SeiSVN/seismic/HAM-ISI/Common/HAM_ISI_Model/HAM_simple/ham_isi_nb_clean.m
• Added new function get_blnd_filters_BP.m which is the same as  get_blnd_filters.m but allows for HAMs to have BP filters

CRS out of loop measurement (1470454819) : Witnesses the table rotation. Looks how we expect it, with the CRS tilt measured more or less matching the predicted noise cure below 1Hz and matching the GS13. (Figure 2)

CRS in loop measurement (1470458418): Figure 3 shows the RY blends on HAM3 with the CRS in loop (i.e. with a bandpass filter),

Figure 4 shows the Noise Budget for the platform, with the GS13 and CRS tilt measurements, the predicted tilt, and the noise contribution from each sensor. The CRS measured tilt falls a bit below the predicted tilt, but this might be from the various sensor noise estimates (most likely CRS) being a bit higher than realitly, or the ground tilt estimate being inaccurate at low frequencies. 

Figure 5 and 6 shows the CRS noise contributions to the CPS and GS13 respectfully

Figure 7 shows the CRS noise budget

These are still a little rough and I'll keep working on them. In particular, I'm slightly confused on why the CRS noise contribution is so dominate in for the GS13.

EY Access System - UPS installed

WP 13544

A Eaton Tripp Lite UPS was installed at EY. The access switch, building cameras and phone were connected to the UPS. Unit failed on 8/06/2026, alog 91438.

POP power measurement on ISCT1

[Jenne, Keita, Louis]

Following up on the POP path issues mentioned in 91647. Keita suggested measuring the power in the POP beam on ISCT1 to 1.) compare it against what we expect to have and 2.) to compare it with different spot positions on PR2. Today we did the initial measurement. We'll need to come back (hopefully tomorrow) to repeat after moving the PR2 spot position. We did the measurement in single bounce with ITMX with 60 W input power (which put 55.3 W at the PRM). Following Keita's suggestion, Jenne turned on POPX centering and noted a POPX NSUM value of 0.76. After each spot position change on PR2 we will remeasure the power in the POP beam just out of the periscope and note any fluctuations in the POPX NSUM (centered). Having both numbers should help us determine if we are clipping upstream or downstream of the dichroic splitter (M10). There is good reason to suspect that we are clipping on the periscope on ISCT1 (see 91647 and 91481).


We grabbed one of the red Thorlabs power meters from the optics lab and placed it just upstream of the POP beam shutter. At first the power meter read about 71 uW steadily. After a few moments, the power meter readout started to fluctuate from about 69 uW to about 72 uW. We couldn't immediately tell what was causing the swinging. The AS Air camera was stable and not swinging. The REFL camera was saturated (most likely because we had the door open on ISCT1). Trending back I found that POPX NSUM and YAW started being very noisy at 1471643523. This lasted for about 30 minutes. I have not been able to find a source. I checked suspensions and QPDs from POPX back to IM4, + PR3, BS, and TMs and could not identify a culprit for the 'swinging'. There was a power glitch in the afternoon before we went out to ISCT1 but Ibrahim reported the glitch timestamp to be 1471640837, about an hour before the POPX issue. I put a screenshot showing POPX NSUM, YAW_OUT and a few other channels I checked during the same time (pop_isct1_shaking.png. There was some JAC-related ASC testing going on at around the same time but none of the trends I checked showed clear correlation to noise in POPX.


===

With 55.3 W at the PRM (taken from IM4 trans, which is assumed to be calibrated to Watts at the PRM), we expect the power coming out of the periscope on ISCT1 to be 

P_isct1 = P_PRM * T_PRM * R_ITMX * 2*T_BS * T_PR2 * R_HAM1_air_bs = 55.4 W * 3.1% * 98.5% * 0.25 * 229e-6 * 90% = 87.2 uW 

With 71 uW measured at at ISCT1, we are missing about 18.5 % of the expected light in the IR POP AIR path.

All optics values were taken from galaxy, with the exception of the BS in HAM1 on the POP Air path. I found this optic on the HAM1 assembly (D1000313) and corresponding bill of materials.

BBSS damping loop

Just for the purposes of commissioning in the short term, I am doing some resdesign of the BBSS damping loop lowpass. Currently, the low passes are customized to each dof, but are roughly 3 Hz low passes with a low-Q elliptical design that gives something like 30-50 dB of attenuation. The rollof is extreme enough that we can't raise the gain. I have created a similar low-Q elliptical at 10 Hz with about 40 dB of attenuation that can be used for every dof. This design should give us plenty of phase to raise the beamsplitter damping gain significantly. I propose we use this design for now while we work on alignment. We can then try disengaging all oplev damping. Oli is working on determining the QOSEM performance, so once we understand it better, we can determine what kind of damping loop we need to meet noise requirements. To be clear, it's not my intention for us to use this design while in observing, just so that we can keep the beamsplitter still while we work on getting DRMI back. Here is a comparison of the current and new low pass

I have confirmed that a larger top mass damping gain is likely to help us lock without the oplev. This is a screenshot of a timeseries during a PRMI locking attempt showing both the BBSS top mass damping error signals and the oplev signals when the oplev damping was off. Both sets of error signals see the motion related to the PRMI locking kicks. I also plotted a spectrum of each signal compared to a quiet time just 5 minutes before (live traces are during locking, refs are quiet time). Both the oplev and osems signals can see the motion well above the noise during this locking time.

I have not yet tried turning up the gain in the damping loops- BS is currently in safe for tuesday work. Will try later today.

***

Edits to add:

Louis and I engaged the new low pass with a gain of -3 instead of -1. We tried step testing with offsets on the top mass, and could see that indeed the ring down from these steps was about a factor of three shorter. We then tried a test offset in length on M3 since that replicates the kick that occurs during PRMI or DRMI locking. The oplev shows that with the higher gain damping, the motion from that kick damps down to the ambient level in about half the time (these are very rough numbers).

Debug of ALS Y WFS auto centering

Keita, Elenna, Jenne

The ALS Y WFS were not working when engaged. I checked the WFS autocentering and we saw that the power on WFS B was very low, indicating clipping. The auto centering servo could not run because the threshhold was too low to engage, but even with sweeping the PZT steering mirror, we could not increase the WFS B sum great than 150 ct. Trending showed that both WFS A and B were close to 3000 ct in March when we last locked ALS on both arms.

We could make large moves in TMSY and ETMY to bring the power up on both WFS, but the autocentering would rail. Keita stated this indicated something was very wrong, and we could be clipped somewhere on the way to WFS B.

Keita and I drove down to EY, and opened the table. We confirmed that WFS A is labeled correctly by covering it with a card. We could see a strange clipping pattern in front of WFS B. We looked along the path and saw that a bundle of cables related to the HWS and the old analog camera placed there were hanging partly in the beam. Once we moved the cables out of the way, the power on WFS B return to 2800 ct, which is nominal. Now the autocentering of WFS B works.

We removed the analog camera from the table, and coiled the remaining cables on top of the cable rack above the table. We also unplugged the power cable for the camera.

Ok, we were confused about why WFS A was not working, but it turns out I accidentally turned off the integrators when we were troubleshooting the WFS earlier today (sorry).

If we request WFS on in the guardian, the WFS engagement causes a lockloss. However if we go to a No WFS slow controls state, and then engage the WFS by hand it does not cause a lockloss. However, the WFS loops are not yet converging.

Image 1 shows the beam clipping on the cables on the table.

Image 2 shows the beams unclipped.

Image 3 shows our cable solution.

***

Edit the following morning to add: given my gaffe regarding the integrators in the auto centering loops, I took a moment to look at the guardian code. When we run 'LOCKED_SLOW_WFS_ETM_TMS' the integrators are engaged by the guardian, but when I was turning on the WFS by hand, I had forgotten to turn on the top mass integrators on ETMY and TMSY. This explains why we engaged the WFS but the loops didn't converge. However, that still doesn't solve the problem, because the reason why I turned the loops on by hand was because running the 'LOCKED_SLOW_WFS_ETM_TMS' was causing a lockloss.

CRS Ellipse Fitting Changes

I re-wrote the ellipse fitting code for the CRS (previously /opt/rtcds/userapps/release/isi/h1/scripts/write_ellipse_values3.py ---> /opt/rtcds/userapps/release/isi/h1/scripts/write_ellipse_values4.py)

While the script works well while the CRS is rung up (i.e. moving a lot), I was running into an error where the previous duration was set much too low (2 seconds), and the CRS wasn't moving enough to get enough data to construct a full ellipse, which would either result in an error or an incorrect fit.

I've made a new version (write_ellipse_values4.py) for when the CRS isn't rung up where you can pick the duration and it can look at data from a earlier time (i.e. ask to use 20 minutes of data starting 20 minutes ago).

I ran the ellipse fitting code for multiple times over multiple periods from over the weekend, while each time gave a slightly different result (listed below), most gave a change of <10% of values vs the current values, with the exception of the HoQI2 y0 Offset, which had a >10% change for all runs and had a max of an 146% change. This either indicates that the HoQI2 signal is drifting significantly, or the original HoQI2 offset used wasn't great.

1600s from  2026-08-24 10:00:00
HOQI 1:
OFFSET X0=-0.0730847 --> -0.07301     [-0.1022% Change]
OFFSET Y0=-0.0595926 --> -0.05879     [-1.35%]
Axes a: 0.794142406 --> 0.77781     [-2.1%]
Axes b: 0.71738585 --> 0.70098        [-2.3%]
Rotation Ang: 146.645-->147.03°        [0.26%]

HOQI 2:
OFFSET X0=-0.0606974 --> -0.06256    [3.1%]
OFFSET Y0=0.00274197 --> 0.00589    [114%] ????
Axes a: 0.6477522995 --> 0.68223    [5.3%]
Axes b: 0.61753553917 -->0.65521    [6.1%]
Rotation Ang: 162.256-->161.22°        [0.64%]
---------------------------------------------------
2026-08-23 10:00:00 3600s

HOQI 1:
OFFSET X0=-0.0730847 --> -0.07455    [2% Change]
OFFSET Y0=-0.0595926 --> -0.06007     [0.8%]
Axes a: 0.794142406 -->  0.78580    [-10.5%]
Axes b: 0.71738585 --> 0.71265        [-0.7%]
Rotation Ang: 146.645-->146.74°        [0.06%]

HOQI 2:
OFFSET X0=-0.0606974 --> -0.06395    [5.4%]
OFFSET Y0=0.00274197 --> 0.00676    [146%] ????
Axes a: 0.6477522995 --> 0.69167    [6.7%]
Axes b: 0.61753553917 --> 0.66174    [7.1%]
Rotation Ang: 162.256-->160.98°        [0.79%]
----------------------------------------------------
2026-08-23 11:00:00 1600s

HOQI 1:
OFFSET X0=-0.0730847 --> -0.07124    [2.5% Change]
OFFSET Y0=-0.0595926 --> -0.05432     [8.8%]
Axes a: 0.794142406 -->  0.75956    [-4.4%]
Axes b: 0.71738585 --> 0.68506        [-4.5%]
Rotation Ang: 146.645-->146.27°        [0.26%]

HOQI 2:
OFFSET X0=-0.0606974 --> -0.06083    [0.22%]
OFFSET Y0=0.00274197 --> 0.00469    [71%] ????
Axes a: 0.6477522995 --> 0.67375    [4.0%]
Axes b: 0.61753553917 --> 0.64620    [4.4%]
Rotation Ang: 162.256-->160.73°        [0.94%]
-----------------------------------------------------
2026-08-23 11:00:00 1000s

HOQI 1:
OFFSET X0=-0.0730847 --> -0.07251    [0.79% Change]
OFFSET Y0=-0.0595926 --> -0.05377     [9.8%]
Axes a: 0.794142406 -->  0.76077    [-4.2%]
Axes b: 0.71738585 --> 0.68627        [-4.3%]
Rotation Ang: 146.645-->145.57°        [0.7%]

HOQI 2:
OFFSET X0=-0.0606974 --> -0.06151    [1.3%]
OFFSET Y0=0.00274197 --> 0.00520    [89.6%] ????
Axes a: 0.6477522995 --> 0.67432    [4.1%]

Rotation Ang: 162.256-->161.59°        [-0.41%]