TITLE: 06/30 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:
Busy Maintenance Day with lots of activity in/at/around BSC2 to help make Dome install tomorrow happen. B&K, SQZ, CRS activities also continued.
LOG:
Rahul, Ibrahim, and I B&K'd the BBSS and ITMX today. Rahul and Ibrahim were in chamber managing the cables and covers, while I was on the laptop outside. I still need to process the results, but this alog's existence means that it happened.
Per ECR E2600223, a ZV-800 style viewport was installed on the G11 port (+X, +Y, middle port) of BSC2. The First Contact that was applied after inspection was removed. No smudges were noted except the outside edge, ~1/4" from the metal flange where the FC didn't cover.
A scratch was noted on the chamber conflat flange (see pic), but the actual knife edge ding associated was very small.
Betsy, Arnaud, Jeff, Oli
Physical movements made in L, T, and V match up with movement read out in EUL basis channels and OSEM basis channels.
Last wednesday (06/24/2026), after we did some checks at the QOSEM sat amp (90758), Betsy and Arnaud went into BSC2 to make some physical movements on the BS so we could check that our channels were displaying movement in the correct directions.
Three physical movements were made:
L
- Pushing in -L direction
- OSEM2EUL matrix says that F2 and F3 are in same direction as L movement (+)
- Push happened at 2026/06/24 22:42:37 UTC and lasted about 30 seconds
| L [um] | F2 [cts] | F3 [cts] | |
| Before Push | 84.3 | 12933.1 | 8629.5 |
| During Push | -179.2 | -2860.8 | -1732.5 |
| Direction | - | - | - |
| Correct Direction? | YES | YES | YES |
T
- Pushing in +T direction
- OSEM2EUL matrix says SD is in the opposite direction as T movement (-)
- Push happened at 2026/06/24 22:40:31 UTC and lasted about 18 seconds
| T [um] | SD [cts] | |
| Before Push | -65.4 | 8217.1 |
| During Push | 201.5 | -3553.7 |
| Direction | + | - |
| Correct Direction? | YES | YES |
V
- Pushing in -V direction
- OSEM2EUL matrix says LF and RT are in the opposite direction as V movement (-)
- Push happened at 2026/06/24 22:34:10 UTC and lasted about 2.5 minutes
- This was done by pushing down the top vertical earthquake stop on M2
| V [um] | LF [cts] | RT [cts] | |
| Before Push | 45.7 | -3519.5 | -8447.6 |
| During Push | -222.6 | 28267.6 | 27984.7 |
| Direction | - | + | + |
| Correct Direction? | YES | YES | YES |
It still looks reasonable.
Before I started touching the BS, only ITMY reflection of SQZ beam was visible in AS camera and nothing in ISCT1 camera.
Betsy found that the ITMX and ITMY reflection of SQZ beam were already almost on top of each other in HAM3.
I moved BS in YAW by negative 51 counts and the differential Michelson alignment was already good, MICH fringe was visible in both of the cameras, therefore BS alignment itself is still reasonable.
On ISCT1 camera, the beam position looked different from what it used to be last Thursday (see today's video of MICH fringes PXL_20260630_202239770TS.mp4 and compare that with alog 90759). Whatever is causing this, it's not BS because BS itself cannot cause common MICH change for SQZ beam that goes to ISCT1.
I noticed that the OMC suspension was saturating but couldn't immediately see why (no ASC output or integrators left on, sliders haven't moved recently). I trended back to see when the suspension moved and found that it coincided with the Guardian machine reboot (alog90824), and trending more things I saw that the inputs to the lock filters went quickly from some thousands of counts to zero. These come from the M2 stage "ISC input filters," which also at the time of the Guardian reboot went from some thousands of counts to zero. Sheila suggested just moving the OMC back to its OSEM positions before the reboot, so that's exactly what I did. The OMC suspension is no longer saturating.
This morning Randy and I moved the IOT2L ISC table back into place on the +Y side of HAM2. Fil can now cable it back up, although the cleanroom leg is very near all of the cable plug ins on the +X side so we may need to make a cleanroom shift.
Then it will need bellows reattached and eventually beam checks to realign.
End X BRS has been drifting more out of rang over the past week. The BRS originally got out of range a month ago (LINK ALOG) I'm boosting the drift control (H1:ISI-GND_BRS_ETMX_HEATCTRLIN) from 4V-->8V to try and get it back to the temperature the plate was before it started to get out of range.
The original temperature is ~36, and right now H1:ISI-GND_BRS_ETMX_HEATTEMPL is reading 27.0, but I'm hesitant to max out the drift control as it was set to 6V when it was last in range.
I'll check back in on it later today/this week
Moved the heat control down to 6V because 8V increased it up to 41
I ended up using the pico motor and remote mass adjuster to try and re-balance. Here are some of the relevant alogs: 76888 75802 80183 84434
From an earlier alog we had calculated ~3.2 counts per step, currently DRIFTMON=~12220, so it should move 3.8k steps, but from other times it's been moved it seems like the steps per count might be less, so I'm going to start with a smaller step amount and check back in later today or tomorrow morning.
Channel 5 of ISC_CUSST_PICOMOTOR_CONTROLER_SIMPLE
To couple :-1.5k in steps of 100, waited a couple of minutes for it to damp down
-2k in 100 step chunks, I don't know if moving in smaller chunks did anything, but it somehow felt better
+1.25k to decouple
Total moved: -2250 steps
Rebooted at 1601 UTC. All nodes came back without issue. New Epics addresses are in.
Ryan S, Camilla, Sheila
We put a temporary steering mirror into HAM7, upstream of ZM4 sending the beam out to SQZT7 to try to measure the M^2 and beam astigmatism before ZM4. Location of mirror attached. Repeated with different ZM2 PSAMs values.
The M^2 data is attached but seemed debatable, with high with M^2 values: > 1.5 when we expect <1.2 to align with 90783. Maybe as the beam was large at the Thorlabs M^2 head, but it was smaller than specs, ~5mm diameter when max was 9mm diameter.
This morning Ryan and I moved the steering mirror to downstream of ZM4 and repeated these measurements, with different ZM4 PSAMs values and then with ZM4 PSAMs back to nominal and a few different ZM2 PSAMS settings. Data attached.
Yesterday we moved the flipper mirror picking off the beam into the M^2 2" off the nominal path, today we moved it back to be in the nominal Homodyne/IR PD path.
TITLE: 06/30 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: 13mph Gusts, 7mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.12 μm/s
QUICK SUMMARY:
Ops workstation (cdsws29) was stuck recovering from morning reboot (hit the on/off button to restore). nuc23 & nuc22 look like they partially came back (will need to log back into them to sort their app windows.
BSC2 SEI work continues (w/ L4C swap & other final checks), FARO measurements may be complete (but FARO remains set-up outside HAM3 just in case). SQZ work continues as well as HAM3 activities and also transfer functions for ITMy.
FOM notes:
Workstations were updated and rebooted. This was an OS packages updated. Conda packages were not updated.
This afternoon, after IAS verified the BBSS had not moved much, Mitch and I went up above and started unlocking the ISI to rebalance. This actually went pretty smoothly. Unlocked st2 after getting a locked reference position for the CPS and loosening the balance mass lock nuts, balanced the ISI, initially using just the raw vertical cps local readout in counts, then looking at the cartesian cps in Z,Rx&RY when the balance was close. When that was done, we pulled the screws holding the st1 balance masses and unlocked st1. Small adjustment on st1, relocked both stages, locked down balance masses again and unlocked one final time to check both stages were still good. Z I left a little high to account for buoyancy, RX and RY residuals were all under 10urad. RZ residuals were higher, I think we swung about 20 urad between locked and unlocked, but I think that measurement is less repeatable between lock and unlock. We re-locked the ISI and have some clean up tomorrrow, we put our removed balance masses on top of st2 under the cover, because we didn't have bags or labels.
Tomorrow we will replace the bad L4C on st1, unlock and do final checks. HEPI seemed to ring up when I tried turning on the loops this morning, I'm hoping that is because the ISI was locked and that was changing the HEPI plant or because of work in chamber, so that needs to verfied in addition to ISI close out tfs.
BSC2 balance mass notes and pictures from Jim
Eric, Ryan S, Camilla, Sheila
All week we have been working on getting a set of OMC scans and beam profile measurements for different psams. We have both sets of data now, with plots and scripts coming soon next week.
OMC scans
We started with a script that Begum gave us from HAM6 work at LLO. We set up ASC loops to go from ASA and AS B DC signals to ZM4 and ZM5 (as described in 90742). We struggled a while to lock the OMC on the seed beam in air, hampered by 90754. With that noisy OMC lock, yesterday Camilla manually aligned OM3 and the OMC suspension carefully to maximize the 00 transmission. We then added offsets to H1:OMC-ASC_QPD_{A,B}_{PIT,YAW}_OFFSET, which is not the usual location for OMC QPD offsets. We will need to get rid of these offsets before we go back to locking.
OMC A offset: PIT 0.088 YAW: 0.133 OMCB offset: PIT 0.27 YAW: -0.22
We found that we were able to move the psams, whih misaligns the OMC terribly, run the centering loops to the ZMs, then run the OMC QPD loops to bring the 1st order peaks back down to a couple % of the 00 peak repeatedly. We spent some time modifying and then debugging the script that Begum shared with us.
It takes in a list of ZM4 and ZM5 strain gauge values, moves the psams servos target to that point and waits 30 seconds with the ZM centering loops on (it doesn't check the acutal value of the strain gauge, perhaps this would be a good thing to add next time). It then turns on the OMC QPD loops for 20 seconds. It then takes a 100 second ramp of the OMC PZT, and saves the times and ZM strain gauge targets into a yaml file.
There is a template you can use to watch all this at userapps/sqz/h1/Templates/ndscope/OMC_psams_scans_monitor.yml The script that runs these sweeps is at sqzutils, or /ligo/gitcommon/squeezing/sqzutils/omc_scans_sweep_psams.py There is also a script there that loads the data, identifies the peaks and estimates mode mismatch and misalignment there, analyze_psam_omc_sweeps.py. A preliminary plot is attached (apologies for the color choices and linear y scale here).
M2 profile measurements
Eric and Ryan S took a series of M2 profiler measurements of the beam on SQZT 7 today, doing the alignment procedure at each strain gauage setting (they didn't adjust ZM alignments). Their data is in here, we will post some plots of this next week.
Note about ZM5 strain guage
While Eric and Ryan were making beam profile measurements, they ran into a situation where ZM5 would not go the strain guage setting of 2. I was able to get it to go to 2 manually, but noticed that there were times when the strain gauge voltage dropped to zero, similar to a problem seen at LLO HAM6 recently. We should follow up on this next week.
More on the ZM5 strain gauge issues -
While Eric and I were taking beam profiles and moving to the last step for the ZM5 PSAM (requesting 2V), the strain gauge readback voltage fell to -2.8V and got stuck, shown at the T-cursor in the first attached ndscope. Changing the requested voltage away from 2V did not affect the strain gauge's behavior or the voltage sent to the PZT, which looked to be railed close to 200V. Eventually Sheila was able to unstick the voltage and get the strain gauge back to 2V by stopping the servo and clearing its history.
This is reminiscent of behavior seen at LLO with one of their new HAM6 PSAMS, OMA2, where after scanning the PZT to the edge of its range, the strain gauge would show open loop for a few seconds, then return to normal (LLO:alog80740 and FRS 37456). We haven't run the repeated scans with ZM5 like LLO did with their OMA2, but we looked for other times recently when the ZM5 PSAM showed weird behavior and found a time earlier that day during one the the OMC scans; see the second ndscope. It's possible that when this happened to Eric and I on Friday, the strain gauge would have fixed itself after a few seconds like in LLO's case, but the integrators in the servo kept the voltage railed.
LLO's solution for this was to fully swap out the optic and its attached PZT/strain gauge assembly, so while we think about this, we are assessing what spares exist that could potentially be swapped in.
ome information about these data:
The first attachment shows the beam parameters measured on SQZT7 propagated to the AR side of SRM (after reflecting off SRM), this can be compared to the second attachment to 90345. These results are different from what we had back in May while the chamber was under vacuum and before our realignment.
THe next two plots show the measured OMC scans, with the same data as plotted above. In the scans with ZM5 strain gauge at -4.5V the 4th order mode is large, so I've also identified it for those scans where it is above 0.005 mA.I'm estimating the mismatch as ( mean height of 2nd order + mean height of 4th order)/(sum of mean heights of 0, 1, 2, 4 orders) in the legend in this second plot, which makes the mode mismatch worse for the ZM5 -4.5 V plots than what is listed above.
The last attachment is an attempt to summarize this data. The bottom two panels show the same data as in the stem plot. The the left panel shows the M^2 value as a function of strain gauge, this does seem to have a dependence on ZM5, which visually looks correlated with the values for which the propagation model is underestimating the mode mismatch for ZM5. Eric will add some thughts about M^2 and the OMC scans. The top right panel shows the overlap between the vertical and horizontal measured qs. Our worst astigmatisms are in the same region of psams settings as the best mode matchings. If this is 1%, and the overlap in one direction is perfect the overall mode matching would be 100*(1-sqrt(1*0.99))=0.5%.
During this PSAMS strangeness, at two times when the ZM5 strain gauge was reading -2V, the applied PSAMS voltage was 88V and 184V, see attached. This seems to be too big of a difference in applied voltage to be only caused by hysteritis. We are not the sure -2V strain gauge reading while there was 184V applied is reliable. This happened twice, the second time the strain gauge read -2.7 while the applied voltage was 194V, attached.
Shoshana, Michael, Oli, Arnaud
CRS is ready for installation in chamber
Next:
Test that positive HOQI signal corresponds to the corner cube moving away from the sensor (same convention as OSEMs)
Calibrate the HOQI PDs to power
Install the fiber feedthrough and start cabling up in chamber