Today I rephased the AS WFS 45 segments.
To avoid lockloss, I transitioned the DHARD input matrix to AS WFS 45 A only so I could phase WFS B. Then, I switched DHARD to WFS B and phased WFS A. I switched by using the DHARD blend filters. Set the DHARD_P_B and DHARD_Y_B input matrix values to the desired value, then make sure the DHARD A and B blend filters have the same ramp time. Then, ramp the gain of one blend to zero and the gain of the other to one. I used a similar process here: 85774.
To get the phasing, I drove a DARM line at 255 Hz in DARM2 EXC, after engaging the EBS255 filter in DARM2 FM10. I was able to get good SNR with an excitation of 3000 counts.
I adjusted each segment to reduce the signal in I (red trace) and maximize in Q. I was able to reduce the line height by between a factor of 2 to a factor of 5 on each segment. The phase changes were between 3-6 degrees on each segment. The light pink and blue traces show the phasing before I started.
This change was SFDed in both safe and observe, shown in attachments below. For some reason, AS A RF45 is in the ASCIMC model but AS B RF45 is in the ASC model.
I attached a comparison of the before and after for each segment. (Note, seg2 on WFS 45A had a strange behavior where it appears the line in Q reduced with the phase change, but that reduction was present before I started changing the phase.)
I have reverted these phases since we don't see much benefit to using them right now, and there is a negative impact on the roll mode damping.
I tried testing these phases while relocking. We can still lock RF darm with no problems. However, it doesn't make any difference in our ability to engage DHARD right after RF darm is locked ( in other words, we still can't engage DHARD after RF darm).
Since this doesn't give us any benefit, and screws with our roll mode damping, I say we don't use these new phases.
Sheila, Camilla
We had wanted to turn down the CLF launch power to see if ti had any effect on SQZ noise, but couldn't turn down by a factor of 2. Could only reduce from 0.06 to 0.05. We instead we doubled CLF launch from 0.06 to 0.12mW. Note these numbers were when the OPO was unlocked and the CLF launched changed once it was locked.
| Nominal | Temp. Test | Note | |
| CLF Launch (OPO unlocked) | 0.06 | 0.12 | Changed with Waveplate |
| CLF Launch (OPO locked) | 0.07 | 0.095 | |
| RF6 Demod | -10 | 0 | This looked noisy in test, why? |
| CLF loop gain | 0 | -6 | |
| LO loop gain | -12 | -15 | |
| FC LSC | -1.12 | -0.566 | In sqzparams.py |
| FC ASC | -0.03 | -0.015 | |
| CLF ISS loop gain | 23 | 17 | From CLF AOM medm button |
| CLF ISS setpoint | 0.347 | 0.694 |
After changing the settings attached, ran scan_sqz_ang which only changed angle by 2deg. I don't see any extra noise at low frequeuncy. See attached, SQZ was a little worse at high frequency with the higher CLF. Not that the CLF RF6 was noisy, so maybe something was setup incorrectly.
To relock in the nominal settings, I had to realign ZM3 as the FC ASC had moved this away after the test when the SQZ was taken down, unsure why, maybe the way that I changed the ASC settings.
FAMIS 31104
In general, things in the PSL are looking good after everything done following the power outage a couple weeks ago. There have been a few incursions in the PSL enclosure over the past week, the most consequential being last Tuesday's FSS path tuneup (alog86972). The biggest difference after that is the reading of the FSS TPD (a gauge of RefCav transmission) is now much lower as a result of recalibrating that PD, so this new reading of ~0.54 V can be considered our new "good" level.
ISS diffracted power has been on the rise for some reason; I'll keep an eye on this and check it when H1 is next out of lock. This could be a result of AMP2 output power having come back up slightly after the last incursion and things settling out.
Overnight we had the ifo drop out of Observing briefly between 2205-09-22 08:23 and 08:27 UTC. This was due to the SQZ PMC PZT running out of range and unlocking. It was able to relock by itself and then get back to FDS
We have had a few FOM and workstation problems where the window manager had died. This leaves the windows with a border/titlebar/min max buttons/... In this situation you are unable to move the windows and new windows pile up on top of each other.
This is fixable.
1. get to a terminal window
2. run xfwm4
* This is the window manager that we us in the control room
* With this running you should be able to manipulate windows again
3. log out and log back in to maek sure things have cleared up.
** Note you may also need to do a xfwm4 --relplace first, but that is not certain.
Lockloss at 2025-09-22 14:43 UTC after just over 4.5 hours locked due to earthquake. I took us to ASC Hi Gains once we were passing 700 on peakmon, and it fully transitioned over, but it was still too much movement for the ASC to handle
TITLE: 09/22 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 34Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 2mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.28 μm/s
QUICK SUMMARY: Observing at 153 Mpc and have been Locked for 4.5 hours.
TITLE: 09/22 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: One lockloss with a long recovery, DRMI really didn't want to lock despite having pretty decent flashes after doing an alignment. The winds were moderate starting around 21:00 UTC, and were even worse from 00:00 to 01:00 UTC esp on YARM. We've been lock for a little over an hour.
LOG: No log.
21:51 UTC lockloss
Winds are gusting over 30mph with a 3 min avg of 20mph. Relocking might take a little while. From windy.com (which uses ECMWF, European Centre for Medium-Range Weather Forecasts ) the winds are predicted to get a little worse in the next 2 or 3 hours then calm down around 4/5 UTC.
03:57 UTC Observing
TITLE: 09/21 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 30mph Gusts, 23mph 3min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.28 μm/s
QUICK SUMMARY:
TITLE: 09/21 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY:
Observing and have been Locked for almost 19 hours. Quiet day Observing my entire shift.
LOG:
14:30 UTC Observing and have been Locked for 10.5 hours
20:45 - 20:47 Helicoptor flying overhead Tagging detchar
Sun Sep 21 10:09:04 2025 INFO: Fill completed in 9min 0secs
TITLE: 09/21 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 2mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.22 μm/s
QUICK SUMMARY:
Obsrving at 150 Mpc and have been Locked for almost 11 hours. Secondary microseism is sitting a bit high but is stable.
At the time of starting the calibration suite, we had been locked for 8.5 hours and so were fully thermalized.
Broadband
2025-09-20 18:32:12 - 18:37:23 UTC
/ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250920T183212Z.xml
Simulines
2025-09-20 18:38:50 - 19:02:14 UTC
/ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20250920T183850Z.hdf5
/ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20250920T183850Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20250920T183850Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20250920T183850Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20250920T183850Z.hdf5
Adding a comment here to note two things:
The thermalization adjustment of the SRCL offset appears to still be performing well according to the grafana page.
There is a 2% difference in TST actuation strength between the model that was pushed on 8/23 to the model created from this measurement. This is also reflected in kappa TST being about 1.02 after thermalization. This is likely due to charging. Tagging CAL and SUS.