Measured the sensitivity of the new CLF VCO:
| Offset at Tune Input | Tune readback | Frequency (MHz) | Difference (kHz) |
|---|---|---|---|
| -1V | 3.332V | 202.690924 | 436.1 |
| 0V | 4.067V | 203.127060 | 0 |
| +1V | 4.800V | 203.542136 | 415.1 |
which results in ~425kHz/V.
Today I adjusted the PSL pump diode operating currents to attempt to improve PMC Trans while maintaining output power. PMC Trans has been dropping and PMC Refl increasing, and alignment tweaks have not been yielding much improvement; suspect the cause is mode matching changes due to the natural decay of the pump laser diodes. With the ISS OFF I tried several different combinations, but the best was found by asymmetrically pumping both amplifiers slightly; the attachment shows the various steps and how they changed PMC Refl and Trans. I ended up with the following current setpoints (actual current is slightly lower, as seen in the attached trends): PS1 at 9.1A, PS2 at 8.9A, PS3 at 8.9A, and PS4 at 8.8A (PS1 and PS2 supply the Amp1 pump diodes, PS3 and PS4 supply the Amp2 pump diodes). When I re-engaged the ISS I had to adjust the RefSignal from -1.94V to -1.95V to account for the slightly increased power transmitted by the PMC. PMC Trans is currently ~109.0 W and PMC Refl is currently ~16.8 W. Will continue to monitor this.
This closes WP 11806.
04/07/2024 11:32:46UTC A dolphin crash (77040) caused the detector to unlock, tripped HAM1 Hepi, and caused a bunch of front ends to trip. Called Dave and Erik, who were able to fix everything
12:22 ISI ITMX Stage 2 watchdog tripped
I took IMC_LOCK to DOWN, SQZ_MANAGER to DOWN, and manualed ISC_LOCK to IDLE
Before the model restarts that were required, I put the corresponding suspensions into SAFE and the HAMs and BSCs into ISI_DAMPED_HEPI_OFFLINE
Once the CDS issue was sorted out, I untripped all the SUS WDs that had tripped and took the chambers back to ISOLATED/FULLY ISOLATED
13:43 Started relocking, went to GREEN_ARMS_MANUAL before starting an initial alignment
- Having issues with the ALS XARM beatnote
- Tried toggling No Force/Force - didn't work
- Not due to low beatnote
- Reset all optics except sqz to a time when we were in READY two locks ago (1396640117) - worked
14:31 INITAL_ALIGNMENT started
TITLE: 04/09 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 12mph Gusts, 9mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.21 μm/s
QUICK SUMMARY: Oli has been working on realigning after the dolphin crash. Just now trying to finish off and SRC alignment before moving to maintenance mode.
Workstations were updated and rebooted. This was an update to OS packages. Conda packages were not updated.
Oli, Erik, Dave:
Around 04:30 this morning a ADC channel hop on h1iopomc0 caused all of the omc0 models to stop running, and also caused a corner station Dolphin glitch which DACKILLED h1susb123, h1sush34, h1sush56 and h1lsc0.
h1omc0 dmesg:
[Tue Apr 9 04:34:05 2024] rts_cpu_isolator: LIGO code is done, calling regular shutdown code
[Tue Apr 9 04:34:05 2024] h1iopomc0: ERROR - A channel hop error has been detected, waiting for an exit signal.
[Tue Apr 9 04:34:05 2024] h1omcpi: ERROR - An ADC timeout error has been detected, waiting for an exit signal.
[Tue Apr 9 04:34:05 2024] h1omc: ERROR - An ADC timeout error has been detected, waiting for an exit signal.
Initially I thought this was an IO Chassis issue, so we power cycled h1omc0 rather than a restart all of its models (my confusion was because this front end only has one Adnaco, and is running the low-noise ADC). This brought h1omc0 back up and running.
We restarted the models on h1lsc0, which cleared the DACKILL.
Oli put the SUS and SEI for BSC1,2,3 and HAM3,4,5,6 into safe, I SWWD bypassed the SEI IOPs and we restarted the models on h1susb123, h1sush34, h1sush56. All came back with no problems.
I cleared the SWWDs, did a DIAG_RESET and cleared the DAQ CRCs.
Handing over to Oli for IFO recovery.
CDS Overview after DIAG_RESET run on all front ends:
Time of OMC crash:
04:32:45 PDT
11:32:45 UTC
1396697583 GPS
TITLE: 04/09 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 134Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY:
LOG: We stayed locked the whole shift, almost 11 hours as of 07:00UTC. Rode through a 6.0.
The range has been lower tonight, it got a little worse after the SQZer relocked itself. Low frequency noise was esp high.
I noticed in the last hour or so of the shift that there were 3 FEs with CRC errors, H1IOPSUSH2B, H1SUSIM, AND H1SUSHTTS (Tagging CDS)
Those are three processes from the same computer (H1SUSH2B). There is only a single data packet sent from each front-end to the DAQ. I might be more concerned about the red indicators on many front-ends on the CPU overview screen
We've been locked for 6:50, range is lower tonight
A 6.0 from Indonesia rolled through around 00:38 UTC
SQZer lost lock and dropped us from observing at 04:22, will return once it relocks. Back into observing at 04:26UTC
This lockloss was due to the OPO PZT running out of range @40V, plot. There's already a checker in SQZ_MANGER to relock when IFOs unlocked and OPO PZT1 is below 50V but it was at 70V when the IFO locked.
Jennie W, Sheila, Ryan Short
After tuning the CAM1 PIT offset this morning and optimising the A2L gains after that, I tuned down the CAM2 YAW offset just before we went into observing. I chose this direction based on the overnight tests Camilla and I did. In the attached picture the cursor shows where the optimum offset is that improves the circulating arm powers. At each stage I had to wait about 2 minutes for the camera servo to bring the error point (IN1 channel) to the set-point.
The optimum value which increased the build-ups by about 6kW (OFFSET = -422) was set in the guardian (via updating the CAM YAW2 offset in userapps/isc/h1/guardian/lscparams.py) and accepted and monitored in SDF. I loaded the ISC_LOCK and CAMERA_SERVO guardians and made the SDF changes before we went into observing. We still need to optimise the A2L gains to match this change so the noise might not be better.
For reference I include a more comprehensive ndscope with all the channels I was monitoring as we did this.
Jennie W, Sheila
We wanted to inject into individual optics to optimise A2L gains today.
This was because we worried that the CHARD and DHARD injections we made on Friday to evaluate our ITM yaw A2L gains mean that we are moving our ETMs to cancel out the noise on our ITMs.
We injected into the channels of the form H1:SUS_{ETMX,ITMX,ITMY}_L2_LOCK_{Y,P}_EXC.
Today we tuned ETMX Y2L, ITMX P2L, ITMY P2L.
The green traces were measured with the new better value and the blue shows the reference value before injecting. We managed to get gains which decreased the transfer function of that test mass motion to DARM. Although it can be seen from the plots of coherence that the coherence was very small for our injections which might imply that there was some non-linear coupling at the frequencies we injected at.
The starting values are in this image and we changed them to these values.
This means we have finished retuning the camera servo that keeps the spot on the beam splitter constant (CAM1).
We need to retune the camera offsets for servo 2 which moves ITMX and ETMX to keep the spot on ETMX, and then retune the ETMX A2L gains for this new value.
We also still need to retune the camera offsets for servo 3 which moves ITMY and ETMY to keep the spot on ETMY, and then retune the ETMY A2L gains for this new value.
Naoki, Eric
Based on the FIS measurements in 77023, we thought that it was worth taking a look at the FDS for H1:LSC-SRCL_OFFSET1 = -275. Unfortunately, we are unable to see any improvement in DARM relative to our nominal SRCL detuning. We tried two SQZ angles chosen to optimize for mid-band and high freq squeezing respectively. We did not have time to try tweaking the FC detuning, but we don't think it makes sense for this to be a FC detuning issue alone. We were concerned that we might be fooling ourselves since the ifo had come unlocked early in the afternoon, so we checked the FIS trace again and it looked identical to earlier in the day.
We have reverted back to H1:LSC-SRCL_OFFSET1 = -175 for the observing period.
We have realized that our approach of optimizing the FIS spectrum for high frequency squeezing and looking for flatness was error prone. We erroniously assumed that a reduction in low frequency RPN was desireable because it resulted in a flatter spectrum in the mid band and chose H1:LSC-SRCL_OFFSET1 = -275 accordingly. In fact, we were adding an undesireable frequency dependent rotation with an unoptimal SRCL detuning which was rotating our injected squeezing away from driving RPN at low frequencies. In the future, we will optimizing FIS for mid-band squeezing and attempt to tune the SRCL offset to flatten out the spectra at high and low frequencies (ie, eliminate any v-shape in the mid-band optimized FIS spetra).
New Datasets (all for H1:LSC-SRCL_OFFSET1 = -275) :
As WP 11790 I updated the OS and 2fa software on 2fa.ligo-wa.caltech.edu. I ended up doing upgrade here before doing the work at LLO.
Eric, Sheila, Jennie, Naoki, Camilla
Aiming to repeat 68814 O4a FIS SQZ, SCRL offset data set. Nominal H1:LSC-SRCL1_OFFSET = -175, previously looked at in 74373.
Using data from our PSAMS scan 76986, we're set ZM4 to 8.8V (175 offset), leaving ZM5 with -0/7V (100 offset). Reran alignment scripts following 76986. Accepted PSAMs sdf, and alignment sliders.
For FIS took SQZ_MANGER to AUTO to stop ISC_LOCK bringing it to FDS.
PSAMs at 8.8/-0.7
Data with different angles (+/-10deg from SQZ and ASQZ, and +/- midsqz aimed to match no SQZ level) with SRCL1_OFFSET -175. Plot attached.
Data with different angles (+/-10deg from SQZ and ASQZ) with SRCL1_OFFSET -275.
Additional plots for data above:
Note: As a sanity check, we took another NoSQZ trace at H1:LSC-SRCL1_OFFSET = -= -425 and saw that it looked idential to NoSQZ at H1:LSC-SRCL1_OFFSET = -175.
After looking at this scan, we were wondering if H1:LSC-SRCL1_OFFSET = -275 might be a more optimal operating point than H1:LSC-SRCL1_OFFSET = -175. We decided to do a few more FIS measurements at the two candidate operating points:
After rethermalizing, we plan to look at FDS at H1:LSC-SRCL1_OFFSET = -275 and perhaps tweak the filter cavity a bit to see if this SRCL detuning is better or worse in terms of range.
An alternate version of one of the plot from the original post. A few intetrmediate traces are removed and replaced w reference FDS and No SQZ traces.
This could be a bad readback, or real, we are not sure. The signal should be 23dB, but the readback is showing 16.8dB on NDSCOPE and has been trending down for a while, it is throwing an error flag in beckhoff. This signal is located in ISC-R1 slot U16 on the left side. The LO signal is 9MHz and is fed through a delay line chassis, there are also baluns, cabling, etc... We were not able to determine the source of the readback error before noon, so this will have to wait until a maintenance window.
M. Pirello, F. Mera, D. Sigg
Measured RF power at the
The analog readback of the power detector was 5.89V at the front panel. This has been confirmed to be the same as the slow controls readback, which corresponds to 23.3dBm.
Seems like disconnecting and connecting the LO cable" fixed" the problem. Flaky cable and/or connector?
