At the adapter plates, in 90949, 90917 we moved the ITM IR camera VPs up to the central spot. We plan to rework the camera cans to attach them. Here are the dimensions:

• Camera with lens and Ethernet cable = 9.5"
• ITMX  where can would attach to oplev pier = 10.5"
• ITMY where can would attach to oplev pier = 12" 

Sheila set up a single bounce beam off ITMY, and ran the AS centering loops. We could see beam on AS_C. I ran a quick test by moving the BBSS in pitch and yaw using the sliders. AS_C shows clearly for 6 urad of pitch motion, the only movement on the diode is pitch. 3 urad of yaw motion also only moves in yaw. The oplev shows pitch and yaw movement during both times, which indicates the oplev is a fairly cross coupled sensor.

Based on this test, I don't think we need to do any other work to un-couple the BBSS pit and yaw dofs.

J. Kissel

The QPD channels in the H1SPIH23 PD array have a z:p = 0.39:39.6 Hz whitening filter in their analog transimpedance amplifier (D1001974-v8). As such, I've installed and turned on an "antiWh" compensation filter = zpk([39.8],[0.39],1,"n") in FM2 of all the H1:SPI-H23_OL_QPD_{A,B}_SEG{1,2,3,4} banks, and accepted the turn on in the SDF system and committed the filter filter to the userapps repo rev 35564.

J. Kissel,

Executive Summary
We're continuing to debug issues seen with the IMC locking. One question that came up was whether we *can* confirm that all binary IO switching of the H1SUSMC2 M3 stage coil driver -- an *unmodified* Triple Acquisition Driver (see D0901047-v4) -- using the transfer functions between DAC output and the FASTIMON coil driver monitor circuits. And the real question they *want* answered is "is the BIO on the H1SUSMC2 M3 stage functioning normally, or is that broken and that's what's causing the issues with the IMC?"

The short answer: NO, one cannot confirm the ACQUIRE switching with confidence with any of these coil driver monitor circuits. The TACQ driver is one of those drivers where the monitor pick-offs span a complex switchable output impedance network rather than a simple resistor. As such, neither VMON or the FASTIMON can measure the response of that switchable output impedance network, since you're monitoring the voltage across it. Elenna's TF posted to LHO:91155, which has the TACQ driver frequency response correctly compensated, also shows that at least the analog state matches the digital compensation state.

BUT -- I'm 95% confident that both LP and ACQ filters the H1SUSMC2 BIO switching are working normally, and switching the analog coil driver state. This is based on some weak coil driver monitor transfer function evidence, looking at the BIO monitor readbacks for the M3 Stage, and two decades of experience looking at the function of these things.

DETAILS 

Attached is the simplest cleanest demonstration of the *lack* of visibility of the Acquire Filter: 
    - Excite the transfer function from the DRIVEALIGN L2L filter bank, so you can send excitation to all four coils at once. Make sure there's no filters on, and the gain is set to 1.0.
    - Change the M3 EUL2OSEM matrix to have the L to UL, LL, UR, LR coefficients from 0.25 to 1.0.
    - Use the 'secret' state feature of the binary IO control, to switch the coil driver state to negative; i.e. State 1 = -1, State 2 = -2, State 3 = -3, and State 4 = -4.
    - This allows you to Turn OFF all coil driver frequency response compensation filters. Do so, turn them off, so that you're actually exposing the what frequency response of the coil driver you can measure.  
Templates of the excitations can be found in 
    /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/MC2/SAGM3/Data/
        2026-07-21_H1SUSMC2_M3_L_to_FASTIMON_NoCompensation_tfs.xml
        2026-07-21_H1SUSMC2_M3_L_to_VOLTMON_NoCompensation_tfs.xml

One can see in this "clean" version of the fast-imon TF 1st attachment. One only really sees the response change when the low-pass filter is turned ON vs. OFF. One might argue that there *is* a little change between STATE 1 and STATE2 (turning the Acquire filter ON, bypassing R14), but this is dirt coupling; we expect the zero:pole response to change from (9:82) Hz pair to a (1:46) Hz pair.

My justification that "it's a real change, even though it's dirty," and that the FASTIMON does show that the switch is working -- if I take the same transfer function to the voltmon circuit, 2nd Attachment (which measures the voltage across a single resistor, but *upstream* of the acquire network), one sees no change at all between STATE1 and STATE2. Said differently -- because we *do* see a change in the FASTIMON TF between STATE 1 and STATE 2, albeit not the real TF change which we know we shouldn't be able to see, but still -- a change -- is weak proof that the acquire filter is changing, and the BIO is functional.

Remember:
 - From LLO:4495, for an unmodified TACQ Driver, we expect the poles and zeros to be changing as follows:
        State         Switch State                       Freq. Resp            DC Transconductance
                       ACQ  |  LP                          (z):(p) [Hz]             [mA/V]
        STATE 1        OFF  |  OFF                         (9):(82)                   0.33 
        STATE 2        ON   |  OFF                      (1.05):(46)                    |
        STATE 3        OFF  |  ON                    (9 11 21):(1 82 210)              |
        STATE 4        ON   |  ON                 (1.05 11 21):(1 46 210)              V

 - For bode plots of the frequency response of all these TACQ driver states, and the difference between a *unmodified* vs. *modified* TACQ driver see L1200226.

 - For an info-graphical representation of the state of the digital compensation w.r.t. the analog filter state, see StateMachineDiagrams_TripAcqDriver-v7.pdf from T1100507.

 - In general, none of the SUS coil driver circuit drawings, nor the SUS coil driver monitor circuit drawings show the complete monitor circuit, so it's difficult at best to parse the total circuit system to understand the calibration. Instead, go to CoilDriverMonitorMath_CurrentMonitor.pdf posted as an other file to D070480-v2 for a complete picture of the monitor system, from which you can derive the math. I summarize it here:
   From the second page of that math, you can see that the transfer function between the Fast IMON circuit output voltage, V_IMON can be calibrated into current across the coil, I_coil by the following transfer function:
       V_IMON                 R25         2
      -------- =  2 * Z_out * ---      = --- * Z_out
       I_coil                 R24         3
where, 
     . as part of the design principle, R25 = R35, and R24 = R27 = R29 = R33, and for the D070480-v2 circuit, R25 = 10e3 [Ohm] and R24 = 30e3 [Ohm], hence, R1/R2 = 1/3, and 
     . Z_out, in the case of the TACQ driver is the entire complex switchable impedance network.

 - The list of HSTS with modified vs. unmodified TACQ drivers on their lower stages: LHO:32021

 - There *are* modified "narrow-band" coil driver monitor circuits out there, but they're only in PRM M2 and M3, and PR3 M3; LHO:72837

CamillaC, CoreyG, RyanS (locked up the IMC at low power for us, with help from Sheila & JennieW)

For reference, see the following alogs & DCC page:  alog61866, alog17788, D1201430

Initial delay to this work was trying to get low power (250mW) from the IMC for a beam to use for this check.  However, we now have JAC, so this added some complications for low-power locking; additionally, IMC locking is still fairly new & fresh post-recent-vent-work.  

Once we had a nice beam to work with we went out to HAM2.  Before we went upstairs, we grabbed an IR card, lexan plate (from the standard guillotine), and a CDS laptop.  This time around we don't have the scaffolding at HAM2's West Side, so we decided to climb up from the East Side since we had several blank flange ports to use for hand/foot holds.  For each climb, we stepped on the steel platform above the HEPI cage (but this still would break IMC lock...but it came back fast).  Did NOT use fall protection since there is a handrail right where we would be working atop HAM2.

Steps For The Check:

• Unclamped the Enclosure for the Porcupine Beam Dump Assy (there are 4 latches on each side of the enclosure which clamp onto the base/breadboard) & set it on a cable tray.
• Carefully laid lexan plate over the rooftop viewport (it did not touch the viewport glass and rested on the bolts of the viewport)
• Then took a look at the beam
• At first glance, we had the beam in the ballpark and close (within a beam diameter) of the (1) steering mirror & (2) beam dump plate of the porcupine.  
• But to get a better look at the beam (with her younger eyes!), Camilla came up so she could see the whole process, and she was more mindful of the spot and possible clipping (Keita mentioned we should look for clipping).
• At this point, I went downstairs to the laptop and steered PRM to where Camilla liked the spot best.  I used the OPTIC ALIGN sliders for the moves.  We ended  up moving the PRM in pitch in the positive direction.  
  • For the "new" MISALIGNED state for PRM, Camilla updated guardian files for this (since we don't use OPTIC ALIGN values for misaligning)
• When were were happy with the beam, I went upstairs to help Camilla re-attach the Enclosure to the breadboard. First, remember to remove the lexan plate!  (One latch [south side] is close to Vacuum plumbing, so one has to pre-hold it in a position to fit.)  Also make sure all four latches grab onto the breadboard when securing.

Below are photos from this activity along with "before" photos of beams as we found them.  Camilla will alog the "after" photos of how the beam looked after some PRM tweaks.

As a part of trying to diagnose the mode cleaner locking issues, I ran a transfer function of MC2 M3 to M3 to see if everything looked normal. Unfortunately, there is nothing in the sus svn to provide a reference, so we don't know what it is supposed to look like.

I immediately noticed strange behavior above 10 Hz that is related to the BIO state. I thought I was on to something, however, I found out that this is a long known problem that comes from coil driver coupling to the osem. Nonetheless, here is a measurement, in case anything else jumps out as strange to anyone.

I took two transfer functions in BIO state 4 - Acq On LP On, and one in BIO state 3 (nominal)- Acq Off LP On.

[Oli, Elenna]

Oli has taken some lovely BBSS OLG tfs of the damping loops, which show significant gain peaking for the LPY dofs. Oli and I took time to determine how much we should reduce the gain for each of these dofs to get enough phase back to reduce the gain peaking. For each dof we were able to reduce the gain peaking from roughly 15 dB to 6 dB.

For length and yaw, this is a reduction of gain of a factor of 2, for pitch we needed a factor of 2.5

Based on the loop suppression, each dof still shows 20 dB suppression around the modes, so I think should be good for locking.

I put the new gains into FM4, and SDFed this filter to be on. This ensures that the BBSS epics gain should still be -1 for all dofs.

The only tricky dof was yaw, since there is a sharp feature close to 2.5 Hz. However, the resulting OLGTF looks fine.

The attached plots show reference traces from Oli's measurements, and live traces showing the new damping with the reduced gains. Final image is SDF screenshot.

I took a set of OLGs yesterday for the BBSS now that it's in vac. I was just comparing them to the last BSFM ones that we have from 2023 (in blue), which obviously will look a bit different.

Settings
- BS in HEALTH_CHECK but with:
    - DAMP ON (you need damping on to run OLGs)
- HEPI and ISI are in their nominal ISOLATED states (ISI no ST2 boost)

Data
/ligo/svncommon/SusSVN/sus/trunk/BBSS/H1/BS/SAGM1/Data/2026-07-20_2200_OLG_tfs/2026-07-20_2300_H1SUSBS_M1_CDBIOState_1_WhiteNoise_{L,T,V,R,P,Y}_0p01to50Hz_OpenLoopGainTF.xml
r13075

This doesn't seem to be related to our problem of locking IMC, but anyway I found a funny DAC behavior for MC2 M3 DAC.

See attached, I'm giving a huge offset to the coil output filter so the coil master output (bottom left) becomes larger than 2**27~134million counts most of the time. The user model DAC output (pink on the bottom right) rails as the master out increases, and so does the IOP DAC output (green on the bottom right), but when the master output goes larger than about 2 billion, the DAC outputs flip the sign and so do VOLTMON and FAST_IMON.

If you look at the transition at around 2 billion master out (between two markers), there seems to be a range where the IOP DAC flips the sign while the user model DAC doesn't, and the IMON as well as VOLTMON drops to zero. Here the driver voltage is not following IOP DAC.

Because we are missing the out of vac crs damping driver, we have to use the ISI to damp the CRS down. This is temporary, we will eventually get a driver for the CRS. This works pretty well for the CRS, but imposes CRS motion on the table. This is enabled by setting the HAM3 ISI RY blend to blend 7, and turning up the gain on the INERT_LO path. The minimum effective gain is somewhere around 10-15, 30 works pretty good, we've gone as high as 100.

We turned the damping on this morning, while Jeff was doing some measurements on one of the MC suspensions, we have kept it running at low gain (3) while the IMC started locking, and so far I don't think this gain interferes with the IMC. There is still some crs signal visible on the RY CPS signal. The CRS is still rung up, and I don't think this gain is sufficient to damp the CRS but I don't see any evidence we are causing problems. I do think a gain of 10 would still allow us to lock (if the CRS is not too rung up) and slowly damp the CRS.

Attached trend shows ISI and IMC trends during the IMC locking this morning. Top trace is (blue) the CRS input into the blends in nrad, second trace (yellow) is the damping signal, third trace (green) is the table motion seen by the RY CPS, fourth trace (red) is the gain applied to the damping signal, last trace is the IMC F. The IMC was finally locked at about -15minutes on the X-axis, you can see we left the CRS damping at gain at 3 when they finally locked, the the CPS is still seeing some of 25mhz CRS motion imposed by the damping, but it doesn't really show up in the IMC signal. I think the bigger issue for the IMC at this time was people climbing on HAM2, for some reason this also seems to be a bigger impact on the HAM3 CPS as well, the extra "hair" on the CPS at -5minutes is not due to the CRS.

Currently with a gain of 3 on the CRS damping, the signal is barely visible on the CPS, not visible in the IMC. CRS is moving about 1 urad peak to peak, CPS motion is ~40nrad peak to peak from the CRS damping. The IMC seems to be losing lock from exterior disturbances (people walking nearby or climbing on the chamber) when the CPS peak to peak is over 200nrad.

Jennie W, Sheila D, Ryan S,

This morning Ryan and co were trying to lock at 200mW to allow the porcupine beam dump for the PRM misalignment beam to be checked at low powers. They were having trouble locking JAC at power below 2W. I improved the alignment of the PZT mirror (H1:JAC-PZT_PIT_OFFSET and H1:JAC-PZT_YAW_OFFSET are the channels) an the JM1 suspension while we were locked at 2W so I could look at the transmitted power.

We seem to be falling out in the 'SCANNING' state during locking at 200mW and if we lock at 2W and try and turn down the power it also falls out.

Sheila checked the JAC guardian and found out that the 'JAC_locked' checker function has a threshold of 0.5 which must be passed before we stop scanning the PZT and jump to the LOCKING state.

It uses the Beckhoff channel H1:JAC-TRANS_A_DC_NORMALIZED which gets normalised by H1:JAC-TRANS_A_DC_NOMINAL to do this check. 

H1:JAC-TRANS_A_DC_NOMINAL is a scalar mA value that does not change with input power (Daniel rescaled this value on Monday manually to make the H1:JAC-TRANS_A_DC_NORMALIZED = 1 when the input power is 2W).

This was not happening so the check failed and the guardian jumped to DOWN.

Therefore Sheila has divided the H1:JAC-TRANS_A_DC_NORMALIZED by input power and set the threhold to 0.2, so this check should always come out about 0.5 for a well-aligned JAC and will therefore pass the 0.2 threshold.

I have committed the JAC guardian to the svn at userapps/isc/h1/guardian

Included pic of alignment changes for PZT mirror and JM1 plus input power monitor (H1-IMC_PWRIN_OUT16) and JAC lock check channel (H1:JAC-TRANS_A_DC_NORMALIZED).

Addressed TCS Chillers (Tues [Jul21] 919-934am local time) & CLOSED FAMIS #64385.

For measurements below, measuring from "top" of the red floaty ball.

• TCSx Chiller:  Had level of 29.5 cm.  Added 250mL for 30.6cm.
• TCSy Chiller:  Had level of 10.3 cm.  Added 110mL for 10.5cm.  
• There was no water in the small cup under the slow leak.

Ryan S, Camilla 

We put the nanoscan profiler downstream of ZM2 (between ZM2 and ZM3) in 6 different locations. We used a steering mirror to get the two locations closest to ZM2.

At each location we took data:

• At three different ZM2 PSAMS settings near our nominal (2.65V, nominal 3.15V, 3.65V)
  • so that we can later understand what ZM2 ROC is needed for best FC mode matching
• At two different beam spot heights on ZM2, old (5.85" high) and new (5.75" high)
  • As we expect new to be better as the designed beam height is 5.5" at ZM2 but we cannot reach this without mechanically offloading ZM2 90946.

Data is attached, we also have photos of all data. The photos of each location are attached. 

TITLE: 07/21 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: MAINTENANCE
    Wind: 2mph Gusts, 0mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.09 μm/s 
QUICK SUMMARY: Commissioning of the JAC and more IMC/corner locking work planned for today along with continued leak checking of the vacuum volumes. Looks like the IMC is staying locked nicely with it only dropping out a few times overnight, where most of these correspond wiht JAC unlocking as well.

• Wind and other ground motion low
• Dust counts acceptable
• CDS overview green except for known DAQ-KC0 disconnects
• All other systems nominal

Work stations were updated and rebooted.  This was an os packages update.  Conda packages were not updated.

(Travis, Jordan, Gerardo)

We are using the same setup as before, see here, leak detector attached to the MTP on the XBM.  Today's helium background reported by the leak detector was 2.0x10^-10 torr*l/sec.

List of items that we have leak checked is below, if crossed no signal detected above the background.

Input manifold:
VP5 (+X side)
VP7 (-X side)

Output manifold:
VP5 (-Y side)
VP7 (+Y side)

Filter cavity tube section B:
Bellows flange connecting to FCB1.

X-manifold
A-1C VP4
A-1C VP5
The 8" port on the X-manifold that was blanked off. 

Y-manifold
A-1F VP2
A-1F VP3

HAM5:
A1F2
Viewport, adapter, and components, jig for getting beam from HAM5 to HAM7.

BSC2:
G11
4.5" blank on dome gauge tree adapter.  Was gappy, so new gasket installed and re-torqued.

HAM2:
A2F1
A2F2
A2F4
A1F1 <-- signal detected at 4.7x10^-10 torr*l/sec, we may replace the seal on the next vent.

HAM3:
D4
This flange is divided into 3  4.5" CF ports, two of the 4.5" are fiber ports, both of them were tested and no leak was detected above the background (D4-1J1 and D4-2J1). 
On the last 4.5" port there is a 5WX, and on the first conflat that we tested there is a noticeable gap on the gasket joint, see photo.  A leak was detected, and the signal peaked to 1.2x10-09 torr*l/sec, we may replace the seal on the next vent.
We still have other flanges to test on this cross, and the rest of the chamber, but once again the background on the LD saturated due to the leak, we will continue leak checking once the background drops to acceptable numbers.

Other items left to check:
HAM3:
D4 The rest of the flanges on the cross.
A1F3
A1F4
D3
D2
D6

HAM7 and relay tube will be checked later, once the chamber is closed and pumped down.

IMC Fast path looks good.

I and Elenna went to the floor and measured the OLTF of the IMC loop, injecting into the IMC CM board. UGF was 43.2kHz with 54deg phase margin, a bit high in frequency but not crazy high, and the TF shape was good in amplitude as well as phase. See PXL_20260720_192425851MP.jpg.

FYI the UGF was 38.5kHz back in March 09 2026 (alog 89438).

M3 stage acquire ON/OFF switching question.

We have noticed that the TF from M3 coil input (or drvalign_L2L_OUT) to VOLTMON and FASTIMON changes as Acqire ON/OFF changes. Is this supposed to be the case? And none of these TFs are flat. Is this supposed to be the case?

MC2-MC3-M3_BIO_TF.png shows the TF from M3 DRIVEALIGN_L2L_OUT to FASTIMON for MC2 and MC3 in various BIO states.  State 1 (Acq Off, LP Off) and state 3 (Acq Off, LP On, this is our nominal state) give the same TF, which is different from state 2 (Acq On, LP Off) and state 4 (Acq On, LP On).  We can say that LP On/Off is properly compensated for in digital but I'm not sure if this means that Acq On/Off is not switching in analog, because I don't know how the IMON in implemented.

Caveats: For MC2 all four states were tested. For MC3 only state 2 and 3 were measured. MC2 and MC3 are consistent with each other. TFs are only plotted for LL because all coils look similar.

FYI, on Friday we have tested to acquire in all four of M3 BIO states and never successfully locked IMC with nominal M3 gain for any state. Even if acquire ON/OFF is stuck to one state in analog (which I'm not sure if that's the case), it's not the only problem.

Today I tested locking with state 2, it didn't lock with nominal gain but it locked with the same reduced gain setting we've been using since Friday (ISCINF_L_GAIN=0.035, DRIVEALIGN_L2L_GAIN=0.2). I switched the state back to state 3 after that.

M3 stage comparison with MC1 and MC3

Screenshot_2026-07-20_11-51-08.png shows the M3 stage DRIVEALIGN_L2L_OUT to M3 witness L transfer function for MC1, MC2 and MC3 from left to right. They all look different but MC2 shows an extra bump at 3Hz.

Other observations

IMC sometimes locks without M3 stage feedback, but fails much more often than with M3 stage feedback, seemingly due to larger kick to the FSS.

Once IMC locks, you can easily switch between the following gains. Both seem to be very stable:

I never successfully transitioned to "all full" actuation (i.e. M3 DRIVEALIGN_L2L_GAIN=1 and M3 ISCINF_L_GAIN=1) nor M3 reduced by 0.2 and M1 M2 full (i.e. M3 DRIVEALIGN_L2L_GAIN=0.2 and M3 ISCINF_L_GAIN=1).