We're assembling the first unit that incooporates all upgrades including the QPD tilt and here are minor problems we've stumbled upon. (No ISS array unit with an upgrade to tilt the QPD (E1400231) has been assembled before as far as I see and nobody seems to have cared to update all drawings.)

First picture is an example of the QPD before upgrade. QPD assembly (D1400139) and the cable connector assembly (D1300222) are mounted on the QPD platform by the QPD clamp plate (D1300963-v1, an older version) and a pair of split QPD connector clamps (d1300220). Two pieces of kapton insulation sheets are protecting the QPD assy from getting short-circuited to the platform.

After the upgrade, the QPD assy sits on top of a tilt washer (D1400146, called beveled C-bore washer) that tilts the QPD by 1.41deg in a plane that divides YAW and PIT plane by 45 degrees (2nd picture). The bottom kapton will go between the washer and the QPD platform plate.

Problem 1: Insulation between the QPD clamp and the QPD pins is a bit sketchy.

Titled QPD means that the bottom of the QPD assy is shifted significantly in YAW and PIT. A new asymmetric QPD clamp plate with tilted seating for the screws  (D1300963-v2) has been manufactured to accommodate that. But we have no record of updated kapton insulators, so the center of the clamp bore doesn't agree with the kapton (3rd picture, note that the QPD rotation is incorrect in this picture, which had to be fixed when connecting the cable). Since the tilt washer is not captured by anything (it's just sandwiched between the clamp and the platform plate), it's not impossible to shift the QPD assy such that some of the QPD pins will be grounded to the clamp and thus to the QPD platform plate.

You must check that there's no electrical connection between the QPD assy and the platform each time you adjust the QPD position in the lab.

Problem 2: New QPD connector clamp posts are too long, old ones are too short.

Old posts for the QPD connector are 13/16" long, which is too short for the upgrade because of the tilt washer, see 4th picture where things are in a strange balance. It seems as if it's working OK, but you can wiggle the post a bit so the post slides laterally relative to the clamp and/or the platform, it settles to a different angle and suddnly things become loose. To avoid that, you tighten the screws so hard that they start bending (which may be already starting to happen in this picture).

Also, because the clamp positions are 45 degrees away from the direction of tilt, one clamp goes higher than the other.

To address these, somebody procured 1" and 15/16" posts years ago, but they're just too tall to the point where the clamps are loose. If anything, what we need are probably something like 27/32" and 7/8" (maybe 7/8" works for both).

We ended up using older 13/16" posts, but added washers. Two thin washers for the shorter clamp, two thin plus one thick for the taller one (5th picture). This works OK. Shorter screw is the original, longer screw was too long but it works.

Problem 3: It's easy to set the rotation of the QPD wrong.

When retrofitting the tilt washer and the newer QPD clamp plate, you must do the following.

1. Completely loosen the connector clamps and the QPD clamp to remove the QPD/connector assy as one unit.
2. Put the tilt washer on top of the kapton insulation sheet at the bottom. The notch mark on the washer must be pointing the 45deg edge of the platform plate (D1300719-v2), see the 6th picture.
3. Separate the cable connector from the QPD to free the now-obsolete QPD clamp (-v1) that is captured between the QPD and the connector. I inserted a razor blade between the connector and the QPD assy and pried.
4. Put the assymmetric QPD clamp (-v2) on the top kapton insulation, paying attention to the direction of the new clamp using the 3rd picture as the reference.
5. Make sure that the rotation of the QPD assy is the same as before because the pins of the QPD are not symmetric. There's no physical mark on the QPD assy itself.
   1. If you're unsure, rotate the QPD assy such that the QPD pins will go to the right sockets on the connector using picture 7. Remember that QPD surface faces the platform down and the drawing of the connector is viewed from the top.
   2. After checking it several times, tighten the QPD clamp.
   3. Put the connector on. Again use picture 7 to put it on at the correct angle.
   4. After checking it several times, tighten the connector clamps.

I screwed up and put the QPD on the connector at a wrong angle. It's easy to catch the error because no quadrant responds to the laser, but it's better not to make a mistake in the first place. It will help if the QPD assy barrel is marked at the cathode-anode1 corner.

It seems that D1300222 and D1101059 must be updated. Systems people please have a look.

D1300222: A tilt washer (D1400146), a new QPD clamp (D1300963-v2) and two sheets of kapton insulation are missing. Spacers are longer than 13/16".

D1101059: Explicitly state that part #28 (D1300963, QPD clamp) must be D1300963-v2.

TITLE: 06/23 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 126Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 10mph Gusts, 4mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY: H1 has been locked for 1.5 hours.

• Wind and microseism are low
• All other systems nominal

Sheila reduced the OPO Trans setpoint from 95uw to 80uW (our nominal from before the break), we hope this will make the SQZ less sensitive to chosen angle. She readjusted OPO temp and measured NLG to still be around 8 to 9. We are not sure why this has dropped since last week but she noticed pump depletion when measuring the NLG when the setpoint was at 95uW.

Ansel, Sheila, Camilla

Last week, Ansel noticed that there is a 2Hz comb in DARM since the break, similar to that that we've seen from the HWS camera sync frequency and power supplies and fixed in 75876.  The cabling has not been changed since, the camera sync frequency has been changed.

Our current camera sync frequencies are: ITMX = 2Hz, ITMY = 10Hz. We have typically seen these combs in H1:PEM-CS_MAG_LVEA_OUTPUTOPTICS_Y_DQ. With a 0.0005Hz BW on DTT I can't easily see these combs, see attached.

I have been running opportunistic noise budget injections:

• Pitch and yaw jitter injections on June 5
• MICH P and Y, DC6 P on June 18
• Frequency noise, CHARD P and Y, DHARD P and Y, PRC2 P and Y, and intensity noise on June 23

So far there seems to be no noise contribution from DC6 P and PRC2 P and Y. CHARD noise contributions are also down significantly with the ISI in place.

Lockloss at 2025-06-23 19:58 UTC. A commissioner was running a jitter noise injection at the time of the lockloss, but doesn't think that was the cause of the lockloss.

We took 20 minutes of no-squeezing data for a cross correlation measurement today. I ran a script to collect the full 524 kHz data from DCPD A and B. The data is currently saved in 1 second hdf5 frames in /ligo/home/elenna.capote/OMC_DCPD/252306-092558_xcorr_data

Lockloss at 2025-06-23 17:18 UTC during commissioning after nearly 14 hours of being Locked. Unknown cause

Elenna, Sheila, Kevin, Matt, Camilla

For some thermalization tests, at 17:05UTC we stepped CO2 powers down from 1.7W to 0.9W each into IFO. Expect majority of thermalization to take ~1hour.

Beforehand, Sheila plugged in the freq noise injection cables in the LVEA PSL racks and Elenna turned on the AWG_LINES guardian.

Last week 85000, NLG was measured to be 18.9, now it's measured to be <8. We will look into why is it low.

Ran SCAN_SQZANG_FDS before doing a CO2 step.

Oli, Elenna

Oli and I combed through some of the recent locklosses by hand, and noticed that there are at least two that have a 13 Hz oscillation in the LSC channels just before the lockloss.

1434317297

1434276630

This is reminiscent to us of PRCL losing gain due to thermalization which has caused 11 Hz ring ups before. We should keep an eye out. Note that one of the above locklosses has the "earthquake" tag, but it's very clear that the ring up caused the lockloss.

Oli and I went back about 1 week and checked the NLN locklosses by eye and only found these two so far.

To start, we can periodically check PRCL OLG or other LSC OLGs during thermalization to make sure we aren't losing significant optical gain. Or we can inject a line during commissioning.

At 16:14:31 PDT h1daqdc0 crashed. Its EPICS IOC stopped running resulting in white boxes on MEDM. Last log was 15:56.

I connected a monitor to its VGA port, its console was showing the login prompt. The cursor was not flashing and an attached keyboard was unresponsive.

Erik and I rebooted the machine by pressing the front panel RESET button. It booted and started with no problems.

Currently we don't know why dc0 froze this way.

Ryan S., Elenna

Thge MOVE_SPOTS state is taking 13 minutes (!) to complete, because the YAW3 ADS DOF is very far off and taking a significant time to converge. Both Jenne and I have found that bumping up the YAW3 gain (PRM yaw) slowly helps converge the loops much faster.

Ryan kindly helped me update the state code to slowly increase the gain if the convergence is taking too long. We added a new timer 'ADS', that waits for one minute after the new A2L gains are ramped (so an additional minute after the 2 minute ramp time of the A2L gains). If, after that first minute, there is still no convergence, then the YAW3 gain is doubled. After that, the 'ADS' timer waits 2 minutes, and again doubles the gain. This process can happen up to three times, which should increase the YAW3 gain to a maximum value of 8. Jenne and I have found that the gain can go as high as 10 in this state. The two minute waits give the other ASC, like SRC1 and INP1 Y time to converge as the ADS pulls the PRM in faster. Once the convergence checker returns true, the YAW3 gain is set back to 1.

We will monitor how this proceeds on this locking attempt. I updated the guardian notify statements so it states when the gain is increased.

Oli, Edgard, Jeff, Brian

This post is meant to give a clearer explanation of the work in [LHO:84296] and its many comments. We are trying to find a new set of gains for the M1_OSEMINF filter banks for SR3 to calibrate the OSEMs to be in agreement with the HAM5 GS13s.

To do so, we drive the HAM5 ISI in { X , Y , Z } and record the response of the relevant OSEMs between 5 to 15 Hz.  At these frequencies, the M1 stage of the suspension should start to become inertial, and the M1_DAMP / SUSPOINT response of each individual OSEM should asymptote to -1, because the OSEMs would be measuring their support point on the cage [barring internal dynamics of the cage itself].

To increase the accuracy of the calibration, we use the MATLAB model of the HLTS and use the full extent of the 5-15 Hz data instead of only the asymptotic behavior.

I post here the code used to generate these results. The code requires the new Common/MatlabTools/ExportedModels folder from the SusSVN [LHO:84458]. The detailed results of the calibrations mentioned is shown below.

_____

• We took a series of transfer functions driving HAM5_ISO_{ X , Y , Z } to measure SR3_M1_DAMP_{L,T,V,R,P,Y}. The templates for this measurement are saved in the sus SVN under [HLTS/SR3/H1/Common/Data/]
  • We can see a lot of cross-coupling in some of these transfer functions. For example, the first attachment shows SUSPOINT V to M1 R cross-coupling that ends up being consistent with sensor miscalibration. This miscalibration is also seen in the large V-to-R and R-to-V couplings in the M1 to M1 transfer functions that Oli took in [LHO:83939].
• From the measurements, we reconstruct the following transfer functions:
  • SUSPOINT V to SR3_M1 T1, T2, and T3. Which are the OSEMs related to the V, R, and P degrees of freedom of SR3.
  • SUSPOINT L to SR3_M1 LF, and RT. Related to the L and Y degrees of freedom.
  • SUSPOINT T to SR3_M1 SD. Related to the T degree of freedom
• These transfer functions are shown in the second attachment. Two interesting things to note:
  • None of them asymptote to -1. In amplitude, they hover around 0.75 or so.
  • The Vertical sensors are backwards. This is not important for what we're doing, we will calibrate by using the absolute value.
• We can get the scaling factors needed to make them asymptote to one by fitting the individual OSEM transfer functions to the model.  We fit by using linear regression between 5 and 15 Hz. The scaling factors calculated from the figures in the second attachment are:
  • T1 needs to be multiplied by:   2.4539
  • T2 needs to be multiplied by:   1.4819
  • T3 needs to be multiplied by:   1.4125
  • LF needs to be multiplied by:   1.3206
  • RT needs to be multiplied by:   1.3705
  • SD needs to be multiplied by:   1.3806
• Therefore, after we multiply the OSEMINF gains that were in place at the time of measurement by these scaling factors, the new OSEMINF gains should be:   
  • T1: 3.627
  • T2: 1.396
  • T3: 1.345
  • LF: 1.719
  • RT: 1.490
  • SD:1.781
• The T1 gain is egregiously high, which makes all of us a bit nervous. Oli has been in the process of checking if these numbers actually make sense. These results will be posted in another log... This one is already too long.

Elenna, Evan

We installed new damping filters for PR3 and SR3 M1, largely following Jeff's "Level 2" filter designs (G1400151). In general these filters give less sensor noise injection, especially around 10–20 Hz.

For all DOFs, the filters are arranged as follows:

• The new loop design uses FM1, FM2, FM5, FM9, and FM10
• The old loop design uses FM3, FM4, FM5, FM7, FM8, FM9.

Both configurations use an EPICS gain of −1 in all DOFs. If more damping is needed, the new configurations should be tolerant to a 10 dB gain increase at least, and as a last resort the old configurations can be restored as described above.

OLTFs of the old (gold) and new (red) configurations are shown for PR3. The changes were accepted into SDF for PR3 and SR3.

Step responses showed somewhat less damping than the old design, but no mode seemed egreiously underdamped. Since PR3 and SR3 are not controlled by ISC or ASC, this should not result in any loop stability issues. When doing step responses I noticed glitching whenever I sent signal to the SR3 M1 T1 coil, even with the damping loops off (DAC glitch?).