Onsite internet has been down for about 1.5 hours now and CDS and GC are working on bringing it back
Naoki, Camilla
When we got to NLN at 2024/03/21 17:38UTC the SQZ_PMC wasn't locked, SQZ manager didn't realize this and was still trying to lock the SHG and OPO. We've now added a @PMC_checker to SQZ_MANGER to check that the SQZ_PMC guardan is in LOCKED.
Sheila, Camilla
We started to repeat the ADF scan from 76561 after the IFO had been locked only ~20minutes. Using 'ezcastep H1:SQZ-ADF_OMC_TRANS_PHASE -s '180' '+6,12'', lost lock before the scan finished. Leaving H1:SQZ-ADF_OMC_TRANS_PHASE to 100 so we can do this again once relocked.
Plan to repeat once the IFO is thermalized (~4+ hours). In theory the optimum ADF phase setting shouldn't change, want to confrim this.
Restarted 180s steps of 6deg at 18:52UTC, NLN since 18:45UTC. Again lost lock before we could take a thermalized data set but there seems like a lot of rotation that could be an indication of the SRCL detuning changing as we powerup.
Naoki and I are leaving H1:SQZ-ADF_OMC_TRANS_PHASE at 118deg but still want to redo the scan with a thermalized IFO.
Thu Mar 21 10:13:07 2024 INFO: Fill completed in 13min 3secs
Gerardo confirmed a good fill curbside. Plot shows new -120C trip temp.
[Gabriele, Sheila, Louis]
We changed the OMC lock dither frequency to 4190 Hz.
As mentioned in LHO:76582, we moved the OMC Lock dither frequency from 4100 Hz to 4101 Hz and saw the 4Hz bump in the OMC lock control loop error signal, H1:OMC-LSC_I_OUT, move to 5Hz as the ramp progressed.
This confirms that the 4Hz bump was due to mixing between the frequency of the OMC lock dither (nominally, 4100 Hz) and the 4096 Hz. It's not completely clear why 4096 Hz is special now but we note that it's equal to 16384 Hz / 4. This bump wasn't present in O4a so why is here now?
In any case, moving the lock dither frequency up to 4190Hz should take care of this issue. We expect the bump to move up to 94Hz, well above the UGF of the OMC lock loop where it won't dominate the error signal RMS.
We also had to change a band pass filter in OMC-LSC_PD_IN, to center around 4190 Hz instead of 4100 Hz. The old band pass is FM7, the new is FM8. If we stick to 4190 Hz dither, we need to update guardian.
The bump at 4 Hz in the OMC error signal is gone.
I accepted the new dither frequency and bandpass filter settings in SDF (observe and snap).
And indeed the bump moved to 94 Hz
[Jennie, Louis, Gabriele]
This morning we carried out some tests to understand if the excess DARM noise could be OMC length noise. We increased the OMC in-lock residual length RMS (by changing the loop gain and by injecting a 4 Hz line), and changed the OMC lock offset. We expect the coupling from OMC length to DARM to scale linearly with both the RMS and the offset.
More details will follow in comments, but we increased the OMC length RMS by about a factor 10 and saw no visible change in the DARM noise in the bucket. We also added several lock offsets and saw no change in DARM noise in the bucket.
So the DARM excess noise is not OMC length noise.
During the test we injected a 135 Hz OMC length line, and checked that the coupling scales as expecetd with the RMS and the offset.
We lost lock at the end of the ramp when we were changing the OMC length dither frequency from 4100 Hz to 4101 Hz with a 30 second ramp. We saw that the 4 Hz bump in the error signal was moving toward 5 Hz during the ramp: this confirms that the origin of the 4 Hz bump is due to some "beat" between 4100 Hz and 4096 = 16348/4 Hz
We measured the DARM / OMC_PZT transfer function at 135 Hz during the offset tests, and found a very linear trend without any significant offset, as expected
Test times
Reference quiet time 1395060517 1395061305
Gain change test
gain 24 1395062380 1395062849
gain 12 1395063409 1395064053
gain 48 1395064462 1395064825
4 Hz injection
gain 0.0015 1395065763 1395066089
gain 0.0030 1395066112 1395066455
gain 0.0060 1395066476 1395066784
gain 0.0120 1395066802 1395067093
Offset test
100e-6 1395068536 1395068841
200e-6 1395068876 1395069277
300e-6 1395069301 1395069708
0 1395069732 1395070085
-100e-6 1395070107 1395070514
-200e-6 1395070532 1395070878
-300e-6 1395070904 1395071331
The graphs where we increased the gain of the OMC length loop are shown in the first image.
The graphs where we we dithered athe OMC PZT2 at 4Hz with increasing amplitude (while keeping loop gain constant at 24) are shown in the second image
The graphs where we offset the OMC loop error point - ie. changed the error point on the fringe we lock to is shown in the third image, while keeping the loop gain constant.
The top trace is DARM-DELTAL_EXTERNAL_DQ calibrated into m/root Hz using the calibration on the 15th March.
The bottom is the error point of the OMC length loop taken at OMC-LSC_I_OUT_DQ.
Fourth graph is because I had to remeasure the 100e-6 offset again starting at 1395068244 GPS as there was a glitch somewhere in the 1395068536 GPS measurement.
All measurements used 289 averages, BW 0.5 Hz, 50 % overlap and so each measurement used 290s in total.
TITLE: 03/21 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 11mph Gusts, 8mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.21 μm/s
QUICK SUMMARY:
We've been locked for 9.5 hours! More commissioning!
TITLE: 03/20 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:
A return to Observing for H1 (first time since mid-Jan, and a return to Triple Coincidence with Virgo + both LIGO detectors for the first time since O3!)---this occured after about 90min of Commissioning work. It was a little bit of a rocky start with a wind storm with sustained winds in the 20mph range for almost half the shift (and gusts above 40mph). This made for several hours of down time (forgot to mark as "WIND" with OBSERVATORY MODE unfortunately). Eventually able to get back to Observing toward the end of the shift.
LOG:
After our windstorm, finally ready to get back to OBSERVING, but we had SDFs for PR3 (I could have sworn we had SDFs for PR3 at the beginning of the shift when we were racing to address the piles of SDF Diffs we had so we could get to Observing.). At any rate, the (3) channels are for Enabling the Input for (3) PR3 channels (see that attached photo of the SUSPR3 Diffs which were ACCEPTED).
Winds really picked up a bit shortly after we went to Observing. Have run an alignment, but the last 90mins have seen little action beyond DRMI....made it to OFFLOAD DRMI once. Will hold for an hour at LOCKING ARMS GREEN for an hour (and while I make lunch).
In addition to the BSC10 accelerometer, the amount of floor motion also increases over the past 6 weeks, though not in a sudden fashion.
This does not correspond to the time of the most recent fan swap, judging by fan accelerometers.
New EX and EY Accelerometer Power Conditioners were installed 30 January 2024. This is roughly the same time as some of these jumps in the trend. The EY BSC 10 accelerometer cable had a questionable connector but still functioned so I believe we left it, it may need to be replaced.
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=75592
We replaced the loose connector but did not see any effect on the signal. While down there we looked at the output and found that channel 5 output was very noisy, and looking back at the notes in my prior ALOG, channel 5 = PEM EY BSC ACC X and back then it did not register as an accelerometer. I assume this accelerometer is not functional or the cabling is not correct. We plan to go back on Tuesday and track down the issue with this accelerometer and possibly repair the channel in the power conditioner chassis.
Other notes
The INPUT to CH3 on the power conditioner is "TBL-Y" accelerometer cable. When unplugged this affected "BSC-Y" signal plot.
The INPUT to CH4 on the power conditioner is "BSC-Z" accelerometer cable. When unplugged this affected "BSC-Z" signal plot. (this one was correct)
Looking back at my analysis of the drawings in the linked ALOG, the above note matches the drawings in the DCC D1300773. I propose we assume the cables are swapped incorrectly but labeled correctly, and we rearrange the cables to match the drawing.
Marc, Fil, Gerardo, Janos
Refer to LHO:76728.
Naoki, Daniel, Nutsinee
Today we increased RF6 from -22dBm to -13 dBm and 8 dBm. We saw excess noise at 8 dBm above 300Hz but no excess noise at -13dBm. REF 12 is the squeezing at -22dB before we started the test. Using the time from alog76553. REF9 and REF10 both show squeezing at -13dBm RF6 at different squeeze angle where one has a better sensitivity at low frequency bucket. REF13 shows squeezing at 8dBm RF6. The excess noise above 300Hz cannot be improved with squeeze angle. Investigation is required.
We turned off ADF sqz angle servo during the test. We readjusted the ADF squeeze angle demod phase and accepted the new value in the SDF.
We are parking RF6 at -12dBm. Since Daniel didn't like the unlucky number 13.
| Loop | Was (-22dBm RF6) | Now (-12 dBm RF6) |
| CLF gain | 10 | 0 |
| LO gain | -7 | -12 |
| FC LSC gain | -2.6 | -0.86 |
| FC ASC gain | 0.1 | 0.03 |
The -22dBm, -12dBm, 8dBm RF6 correspond to 9 uW, 28 uW, 420 uW CLF REFL power.
We rechecked the FDS -22dBm time as the time in the above plot wasn't sqz opitmized to the bucket. Can see in attached plot, CLF at -22dBm and -13dBm have the same SQZ in the bucket, as expected.
Looking back at the past data it seems we may not have adjusted the CLF ISS gain properly during the test causing our sqz level to be stuck at 3dB at kHz region. CLF_REFL_DC was oscillating when RF6 was at -13 dBm and at 8 dBm. This looks like an easy fix and we should try again at some point.
Daniel Nutsinee
Reducing the gain didn't seem to fix the oscillation. We cranked up the CLF power so the RF6 read 6dBm and went out to look at the signal on the scope. We saw 60kHz beat note on the OPO refl and a crooked 105kHz sinewave on the CLF refl. We don't know where the 60kHz beat on the OPO refl came from. We couldn't make any improvement by changing the CLF ISS gain.
After some investigation we realized the oscillation disappeared when we unplugged the RLF. The oscillation came back when the RLF was plugged back in. The oscillation associated with the RLF seemed obvious only when we operated at high power. Next time we try high CLF power again we should attenuate the RLF RF output to the AOM.
The funny thing was PMC refl saw this oscillation as well. We hope this was just an electronics cross talk.
For even higher CLF power with +6dBm at the RF6 demod, we set the CLF servo IN2 gain to-18dB (from 0dB), the CLF ISS gain to 0dB (from 17dB), and the ISS input set point to 2.037 (from 0.347).
Naoki, Nutsinee, Camilla
We turned the SQZ_ANG_ADJUST servo back to it's O3a nominal ADJUST_SQZ_ANG_ADF. Changed sqzparams.use_sqz_angle_adjust to True and reloaded SQZ_MANAGER and SQZ_ANG_ADJUST.
Set H1:SQZ-ADF_OMC_TRANS_PHASE as 133deg, new scan (as in 76434) running now to check what angle is best for total squeezing.
Accepted at H1:SQZ-ADF_OMC_TRANS_PHASE = 120. This seems to give us the best range but not high frequency SQZ. Plot attached.
We optimized the sqz angle after high CLF test and readjusted the AADF demod phase.
We should check the ADF offset with a more themalized IFO as the SQZ angle servo seems to have pulled even the yellow BLRM to a worse location, see attached.
The commissioners are aware of this now and some people are looking into it, but it seems that the new DARM offloading scheme has been sending big kicks (a few 10s to 200 microns) to the ETMX HEPI at almost every lockloss from NLN. This doesn't seem to be happening with ETMY. On attached trends, top blue trace is the ISC tidal signal sent to ETMX HEPI, yellow is the ISI watchdog state, bottom is the ISC LOCK state number. The ISI doesn't trip every time, but it's happend 5 times just over the last week. This isn't normal behavior, but it seems like we've just been ignoring this for a while. I recall having this happen a bit before the end of O4a, and we added a filter to the input to the HEPI model, but that just seems to slow the kick a bit.
Louis and I modified the aL1L3 filter (FM6) in ETMX_L1_LOCK_L by replacing the single pole at 50 Hz with a complex pair at 30 Hz, so that this offloading filter rolls off like 1/f above 30 Hz. Since the output of L1_LOCK_L is offloaded to HEPI, we suspect that this is what was causing the kick at EX. No DARM control is directly applied to EY, so that would explain why EY does not trip. The most recent lockloss did not trip anything.
It didn't trip the ISI, but we still are spiked up to about a third of the actuators drive range on the last lockloss. I'm less worried about tripping the ISI than I am about damaging something on the suspension or HEPI. attached trend shows the ISC signal to ETMX HEPI and the drives on the horizontal actuators at the last lockloss.
Evan added a 0.1Hz low pass filter into FM3 of H1:LSC-X_ERR_TIDAL_ERR, and for symmetry into H1:LSC-Y_ERR_TIDAL_ERR. Turned on filters and sdfs. We expect this to stop the kicks and not effect the slower tidal offloading: titdal to UIM is ~0.03Hz, to HEPI would be even slower 68749.
Since the 0.1Hz LP has been added, the two locklosses have not kicked the HEPI. See attached zoomed out and zoomed in plots.
[Jennie, Evan, Gabriele]
We tried again to move the input beam pointing in-lock, similarly to what was done in 76359.
First we moved IM1 and IM3 in pitch, looking at IM4_TRANS and POP_LF. We could increase the power in IM4, and we moved until we reached a maximum in POP_LF. Half way during the test we switched back to ADS from cameras, but it turns out that the PRM ADS was moving in the wrong direction. We went back to camera servos (restoring the original, correct offsets) and helped PRM along to speed up the camera servo convergence.
When we reached this maximum of POP_LF by moving pitch IM1 and IM3, we checked DARM: there was more noise in DARM at low frequency and around 100 Hz, the range was lower, but coherence with jitter was unchanged. Evan tried to improve things by tuning the SQZ, without luck.
We then moved to yaw, and we could improve IM4 and POP_LF further. Unfortunately we lost lock during the test. We don't believe we caused the lock loss.
The change in input beam alignment had a good effect on the optical gain, KAPPA_C increased by 2% (yaw being the most effective direction). For comparison IM4_TRANS improved by 6.6%, POP_LF improved by 2.8%
The arm power also increased proportionally to LSC-POP and ASC-POP. I think this means that moving the input pointing we were fixing some clipping in the PRC. It's worth repeating the test: we could go back to the pitch position we found (by moving IM1, IM3 with a long ramp, and also moving PRM to the new value, and maybe also IM4?). From there we can restart the yaw motion, which seemed promising.
I reverted the alignment changes to IM1, IM3 and PRM. See attched images of the SDFs for SUSPRM and SUSIM models.
For future reference, here are the moves we did (in SUS offset sliders) or loops did for us (in M1 DAMP IN units, should be the same as sliders)
| Optic (pitch) | Initial value | Final value | Change |
| IM1 (us moving) | 7794 | 2900 | -4894 |
| IM3 (us moving) | -7576 | -5376 | +2200 |
| IM4 (loop) | -2862 | -2731 | +131 |
| PRM (loop helped by us) | -1314 | -1132 | +182 |
| PR2 (loop) | -484 | -516 | -32 |
| PR3 | none | ||
| BS | none |
Internet has been restored!