Today I was able to drive a line on SRM pitch and yaw, aka SRC1 P and Y, in an attempt to understand how the SRM alignment signal appears in various sensors. Our current configuration has SRM alignment controlled via the AS RF72 signal, which is the beat of the 118 MHz and the 45 MHz.
To do this measurement, I engaged the usual 8.125 Hz notches in the ASC loops, and drove at 8.125 Hz at the SRC1 SM exc point. I measured the signals in the I and Q phase on AS RF72, AS RF45, AS RF36 and POP X RF, which is a 45 MHz demod.
First, it is very hard to drive a large enough signal to even see the line in AS RF72 compared to other sensors. We are currently operating with 1 stage of whitening on RF72, for reference. The attachment shows how the signals appeared in the AS WFS as well as the POP WFS for pitch and yaw.
Once I took this measurement, I looked at the time series of the signals. POPX 45 Q pitch has an offset that corresponds to 1.5 urad of SRM pitch offset. I calculated this calibration factor from my injection: 7.37e-5 SRM pitch urad/POPX pit ct. The POPX Q yaw signal also had an offset, but it was much smaller, only 0.24 urad, calibration factor 3.25e-4 SRM yaw urad/ POPX yaw ct
On June 5, the SQZ team adjusted the SRCL digital offset, and when the SRCL digital offset was zero, the POPX Q offsets corresponded to about 0.09 urad of SRM pitch offset and 0.05 urad of SRM yaw offset (sqz alog).
In the past, we have operated with some SRC1 offset, however, that offset is remarkably small compared to even the dark offsets we have applied to the AS RF72 channels. SRC1 p offset was set to -0.042, SRC1 Y to 0.098, while the four segment dark offsets on RF72 Q are -17.8, 0.2, 2.2, 12.9 (medm screenshot).
Overall, I think we should consider a few things:
Sheila has suggested we open the SRC1 loop and try stepping the offset while monitoring the buildups, the effect of the SRCL offset on SQZ, and the overall offsets in AS RF72 and POPX Q.
Whatever effect alignment offsets in the SRC are having on the SRCL detuning seems to be much smaller in yaw than in pitch.
To calibrate the AS RF72 signals into SRM angle, we can use these factors:
0.274 SRM pit urad/ AS RF72 pit ct
0.173 SRM yaw urad/ AS RF72 yaw ct
Today, Sheila and I followed up on this, and the results are a bit confusing, but somewhat promising.
To start, Sheila reran the "brontosaurus plot" measurement, where FIS is injected to help determine the SRCL offset. She reports this work here.
While she changed the SRCL offset, I once again monitored the AS RF72 and POP X signals. As Sheila changed the SRCL offset, the offset in POPX did change the same way as I saw yesterday, which is not that surprising.
Then, when Sheila set the SRCL offset to zero, I tried opening the SRC1 loop and moving SRM around. The first thing I noticed is that the calibration I calculated yesterday seems bad, since I was adjusting the SRM yaw by 11 urad (according to the slider calibration), but the change in the POP X yaw offset corresponded to less than 1 urad (according to my measured calibration from yesterday).
I moved yaw in only one direction, with the goal of seeing if I could reduce the POP X yaw offset. However, I gave up after 11 urad because it didn't seem to be doing much at all except to small effect on POP X yaw.
Next, I tried moving SRM in pitch. I went the positive direction, and Sheila and I immediately saw the buildups get worse, so then I went the other way and the buildups got better! This corresponded to a 20 urad change in SRM pitch, according to the alignment slider. The change in the POP X pitch offset was minimal.
We also saw kappa C increase quite a bit, almost too good to be true, so we didn't trust the value since we had a large SRCL detuning at the time. Sheila did see that the change in the SRM pitch had an effect on the squeezing as well.
However, Sheila then determined a better SRCL offset of -382, so we went there, and the kappa C leveled off to 1.02, which was better than our current nominal value of 1. This seemed to hold. Then, I stepped the SRM pitch offset back to the starting alignment and the buildups decreased and kappa C went back to 1.
Following the buildups, there seems to be a better alignment of the SRM in pitch. At this time it seems like yaw has no effect, but I only moved in one direction. I think that, whatever the SRCL offset is, we should move the SRM around in pitch and yaw and see if there is an improvement to be found in the buildups. My current hypothesis is that the RF72 dark offsets are creating some alignment offset in the SRC. After we find a good SRM alignment position, we can recheck the SRCL offset, hopefully with both a squeezing measurement and a sensing function.
We should also probably check the whitening on RF72, maybe next Tuesday.
These results are making me think that probably POP X Q would not make a good signal for SRC alignment, since it is dominated by the SRCL offset.
The first ndscope attached are showing the behavior of the POP X and RF72 signals while changing SRM alignment. The second shows the buildups and kappa C when changing SRM pitch and SRCL offset from 0 to -382.
Yesterday 85295 we took HD data just at the nominal 95uW OPO trans setpoint, today we changed the NLG and retook data, saved at /camilla.compton/Documents/sqz/templates/dtt/20250625_HD.xml
Strangely, when I started checking the NLG with 95uW, once the seed was injected, this dropped to 65uW, I then increased injected seed power form 0.5mW to 0.6mW, I also increased the pump power as we were close to the edge of the AOM range.
Used SQZ_MANAGER SQZ_READY_HD (needed to change LO gain, see sdf).
Type | NLG | Angle | SQZ (@500Hz) | DTT Ref |
LO shot noise | N/A | N/A | Used as 0dB | ref 1 |
ASQZ | 10 | (+) 206 | 14.3dB | ref 2 |
SQZ | 10 | (-) 112 | 6.9dB | ref 3 |
Mean SQZ | 10 | N/A | 11.3dB | ref 4 |
ASQZ | 18 | (+) 210 | 17.2dB | ref 5 |
SQZ | 18 | (-) 112 | 7.3dB | ref 6 |
Mean SQZ | 18 | N/A | 14.1dB | ref 7 |
ASQZ | 21 | (+) 210 | 17.5dB | ref 8 |
SQZ | 21 | (-) 110 | 7.4dB | ref 9 |
Mean SQZ | 21 | N/A | 14.7dB | ref 10 |
ASQZ | 14 | (+) 206 | 15.6dB | ref 11 |
SQZ | 14 | (-) 113 | 7.4dB | ref 12 |
Mean SQZ | 14 | N/A | 12.7dB | ref 13 |
OPO Setpoint | Amplified Max | Amplified Min | UnAmp | Dark | NLG | OPO Gain |
95uW | 0.0730506 | 0.002413 | 0.006841 | 8.4e-5 | 10.81 | -8 |
115uW | 0.122166 | 0.002215 | 18.08 | -8 | ||
120uW | 0.141799 | 0.0021763 | 20.99 | -8 | ||
105uW | 0.0942627 | 0.0023351 | 13.95 | -8 |
Plot attached, we think that the SQZ is worse at NLG 10 that the other NLGs and we are considering running with NLG = 14.
Here's a fit of Camilla's data, it shows that our OPO threshold has increased compared to 83070, and we still have the same efficiency for squeezing, which implies 6% unexplained loss, which hasn't been fixed by moving the crystal.
This plot was made using this script
We decided that an OPO TRANS setpoint of 105uW for an NLG of 14 gave us slightly better squeezing, see attached BLRMS. Leaving this in.
If the Operators have any issues keeping the OPO locked at this higher output power, they could lower it slightly following the instructions in 70050 to drop it down to 100uW or 95uW.
Matt Todd, Sheila Dwyer
We moved the OMC alignment a bit in pitch while watching for a response in kappa C. The attached screenshots show the updated pitch offsets that have been accepted in safe and observe. The next screenshot shows us stepping this around.
Overall, we improved the optical gain by something like 0.5 %. We would like to return to the yaw offsets to see if we can recover the 1% optical gain that we lost during the vent.
Lockloss during commissioning at 2025-06-25 17:52UTC after over 5.5 hours Locked. Cause not known, but probably not commissioning related.
18:48 Back to NOMINAL_LOW_NOISE
Within the same ~15 seconds of the lockloss, we turned the CO2 powers down form 1.7W each to 0.9W each. In the hope of doing the thermalization tests we tried last week 85238.
We checked the lockloss today and LSC channels at the time last week we turned the CO2s down and see no glitches corresponding with the CO2 waveplate (out of vac) change, we think the lockloss was unrelated.
Wed Jun 25 10:12:58 2025 INFO: Fill completed in 12min 55secs
MEDM
Confusingly we have been running with two separate copies of the vacuum overview MEDM.
CDS_OVERVIEW has been using /ligo/lho/h0/ve/medm/beckhoff/H0_VAC_SITE_OVERVIEW_CUSTOM.adl (not under any version control)
SITEMAP has been using /opt/rtcds/userapps/release/vacuum/h0/medm/Target/H0_VAC_SITE_OVERVIEW_CUSTOM.adl (under git version control)
It is the second one, which is git controlled, which should be used. I took the opportunity when fixing the MEDMs to remove use of the /ligo files and move CDS_OVERVIEW over to using the Target file.
Changes made to the site overview and committed to git (see attachment) are:
RED - HAM1 now only shows the new PT100_MOD2 gauge
YELLOW - IP24,IP25 have new names
PURPLE - text to show the local git working directory and git repo information
VACSTAT
I added the new HAM1 PT100_MOD2 gauge to VACSTAT last night. Initially I also removed the temporary H1 PT100B gauge, but then remembered this has channels in H1EPICS_VACSTAT.ini which caused EDC disconnects.
So for now VACSTAT has the new H0 PT100_MOD2 (not in DAQ) and the old H1 PT100B (in DAQ, but needs to be removed)
Trip levels were returned to pre-vent values.
I just took some No SQZing time (starting at 2025-06-25 15:01 UTC (1427040078)) and compared it to the pre-vent No SQZ Time of 2025-03-26 16:01 UTC (1427040078). I used the command python3 range_compare.py 1427040078 1434898893 --span 600. I originally wanted to use a time span of half an hour instead of 10 minutes, but the March time had some sort of glitch that messed up its range calculation, and the range calculation for today's time was the same, so I went with 10 minutes. Here's the range comparison.
TITLE: 06/25 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 5mph Gusts, 2mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.06 μm/s
QUICK SUMMARY:
Observing and have been Locked for almost 2.5 hours. Range is okay at 145Mpc, it looks like its been drifting a bit down since the lock started.
Looking at the lockloss from last night (2025-06-25 11:02 UTC - note that the 'refined lockloss time' is one whole second early than the actual lockloss time), it's immediately clear that we lost lock due to a quick ringup, but it is unclear where that ringup came from or what frequency it was actually at. We can see an 8Hz oscillation in DARM one second before the lockloss, but looking at the LSC channels, SRCL sees a 1.5 Hz oscillation right before the lockloss, and PRCL has a 4.5 Hz oscillation (although the PRCL oscillation could be unrelated, although it does look like it grows a bit larger). In the ASC channels, MICH P OUT has a ringup at ~3.8 Hz in that last second, and some of the other ASC channels look like they maybe also have some sort of excursion right before the lockloss.
Signal railed about 5:18 PM local time, I checked trend data for PT120 and PT180 and no pressure rise noted inside the main volume. Attached is 3 day trend of the pump behavior, very glitchy for a long while already.
System will be evaluated as soon as possible. AIP last replaced on 2015, see aLOG 18261.
Lockloss From Nominal_Low_Noise @ 03:01:08 UTC.
I'm not exactly sure what caused this LL .
Ryan S., Elenna
Ryan and I are still trying to speed up the MOVE_SPOTS state. Today, Ryan implemented new code that checks the convergence of the loops and only ramps up the ADS gains of loops that are not yet converged to help them converge faster. This appeared to work well, although the state is still slow. We are now taking the spots to the FINAL spots that the camera servos go to, instead of some old spot, so it's possible that which loops that are far off have changed.
Ryan also pointed out that the ENGAGE_ASC_FOR_FULL_IFO state is taking a while because it is limited by the convergence of the PIT3 ADS. This is likely because the POP A offset used in DRMI ASC is not quite right, so I adjusted it for pitch so the PRM should be closer to the full lock position. SDFed.
With regards to ENGAGE_ASC_FOR_FULL_IFO, the three locks that we've had after the adjustment made yesterday have made the state take an average of 4.5 minutes to get through. Before making this change, it was taking us an average of 8.5 minutes (looking at the four locks before this change), so this has made a big improvement for this state!
However, it looks like the main reason why this state still takes a pretty long time compared to most other states is because it's still needing to wait a long time for the PIT3 and YAW3 ADS to converge (ndscope). Here's the log from this last time that we went through ENGAGE_ASC and you can see that most of the time is waiting for ADS. The actual wait timers in there are only 50 seconds of waiting, so the rest of the wait timers (the one second timers) are just from the convergence checker.
I updated the POP A yaw offset so that PRC1 in DRMI will bring the PRM closer to the full lock point and hopefully make convergence in this state faster.
Range comparison plot:
Command Ran: python3 range_compare.py 1396833438 1434842418 --span 1800
time 1 is April 11th 2024
time 2 is today at 23:20 UTC June 24th 2025
I ran two brucos, one on NOLINES and one on CLEAN.
Overall, the message of Tony's alog is that, relative to our best range, we have lost 10 Mpc by the time we reach 100 Hz, and an additional 5 Mpc by the time we reach 1 kHz. The brucos above show a lot of low level coherence with: MICH, SRCL, PRCL, REFL RIN. There is a chance that making additional improvements to the feedforward can help. Right now it's hard to tell how many Mpc that gets us back, but it's where we should start.
I made a range comparison with a time form last night when we got up to 155Mpc (Jun 25, 2025 05:07:30 UTC (1434863268)) and compared it to a time of good range before the vent, Apr 01, 2025 03:05:42 UTC (1427511960). Here's the range comparison.
This is interesting because it indicates that the range loss at low frequency in DARM now versus right before the vent is much smaller, only 3 Mpc. But looking back to our best range in April 2024, there is even more loss in sensitivity at low frequency.