TITLE: 07/17 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 16mph Gusts, 10mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.20 μm/s
QUICK SUMMARY:

Observing at 145Mpc and have been Locked for almost 3 hours. Everything is looking good.

TJ, Elenna, Oli, Sheila

I had noticed a bit ago that SR3 M1 DITHER P has been outputting a 32 consistantly (overview). It seems like the OFFSET has been on for most of over 5 years(ndscope1). Over 5 years ago it stopped moving around (ndscope2) and had stayed at 32 almost all the time since then, probably when the SR3_CAGE_SERVO stopped being used. I spoke to Sheila, and she says she knew about it, and that it was just a remnant of the cage servo that no one bothered to offload into the opticalignment sliders, and that we can offload it to the sliders so that it isn't sitting there anymore. We will probably do this at the next lockloss.

Closes FAMIS 26052. Last checked in alog 85627.

"BSC high freq noise is elevated for these sensor(s)!!!

ITMY_ST1_CPSINF_H3"

By eye, BS_ST2 had elevated counts compared to last week. Otherwise, signals are either comparable or lower.

Locking was straight forward, needed to run an initial alignment, but it was all hands off. There were a bunch of SDFs from commissioning today that we knew would be there.

Camilla, TJ, Dave:

On 26jun2025 I started my HWS camera control code on the four HWS machines [h1hwsmsr, h1hwsmsr1, h1hwsex and h1hwsey]. The code disables the HWS cameras when H1 is in observation mode and re-enables them on lock-loss.

Data since that time has shown no clear correlation between HWS camera status and the 2Hz DARM comb. The comb appears to have persisted until the 4th July, at which point it diminished.

Camilla and TJ decided we should try turning off the camera control code and keep the HWS cameras enabled.

Following the 11:43 lock loss this morning (at which point the cameras were enabled by the code) I stopped the camera control python code on all four machines between the times 11:54 and 11:57 PDT. Note that Ctrl-C inside the tmux sessions did not work, I had to "kill -9 " the python processes.

Attached camera control MEDM from 12:03 shows the cam-ctrl agents have stopped, with their GPS times not updating (denoted by purple boxes).

For now I have removed the CCTL (Cam Control) box from the CDS overview, but I am keeping the cam_ctrl_ioc running and the channels remain in the DAQ.

Looking at the measurement of CSOFT from this alog, and also remembering that CSOFT P tends to be highly coherent with DARM from 10-15 Hz, I decided to make some adjustments to the CSOFT P lowpass filter that would both suppress noise around 10 Hz, and also maybe buy back some phase at 1 Hz. I designed a 7 Hz low pass filter with only 40 dB of attentuation. The current lowpass filter design has 60 dB of attenuation, which seems like overkill. I adjusted the low pass to be elliptic, low Q, which gives us back about 5 degrees of phase, but reduces the gain at 10 Hz and above by a factor of 10. I didn't get a chance to try it in lock, but I changed the guardian to engage this filter on the way up to NLN (line 3341 of ISC_LOCK). There will be an SDF diff. The new filter is in FM7, the old filter is in FM9.

Jennie, Rahul

On Tuesday Rahul and I took the measurements for the horizontal coupling in the ISS array currently on the optical table.

The QPD read 9500 e-7 W.

The X position was 5.26 V, the Y position was -4.98 V.

After thinking about this data I realise we need to retake it as we should record the mean value for the DC coupled measurements. This was with a 78V signal applied from the PZT driver and an input dither signal of 2 Vpp at 100Hz on the oscilloscope and I think 150 mA pump current on the laser.

Based on a recent bruco, it appeared that PRCL had relatively high coherence, especially near 100 Hz. I ran an injection today during commissioning to check the coupling. I adjusted the overall PRCL feedforward gain and found a lower coupling when the gain was reduced from 1.3 to 1. As soon as the gain reduced beyond 1, the coupling around 20 Hz started to get worse. I chose to use a new gain of 1, and updated the guardian and SDF. These changes are loaded. I also took a longer measurement of PRCL, on the off chance we want to do another iterative feedforward shaping in the future.

Sheila, Camilla

We ran a couple of squeezing angle scans to check the settings of the ADF servo. 

One thing that we realized is that the ADF Q demod signal is divided by H1:SQZ-ADF_OMC_TRANS_Q_NORM rather than mulitplied which is what we had thought.  We changed the coefficent from 0.18 to 5.8. The first png attachment shows that this transforms the blue ellipse into the orange one.  It would be a bit better if we first adjusted the demod phase to maximize the Q signal, so that the ellipse would be aligned along the axis, and the rescaled version would be more like a circle.  However you can see in the right side plot that this gives us a reasonably linear readback of sqz angle as we change the RF6 demod angle (which is actually cabled up to RF3 phase) about 150 degrees where our best squeezing is.

Camilla turned the servo back on in sqzparams. 

For future reference, a slightly better way to do this would be to move the demod phase to maximize Q, do a scan and set H1:SQZ-ADF_OMC_TRANS_Q_NORM to the ratio (max of Q)/ (max of I).  Then you can do a smaller scan around the point with the best squeezing, and in sqzparams set sqz_ang_adjust_ang to the readback angle that you think is best.

Thu Jul 17 10:07:21 2025 INFO: Fill completed in 7min 17secs

Just some quick directions on how to run a script to get the full 524 kHz DCPD data, and then save it in a useful file format.

The script to save this is in /ligo/home/elenna.capote/OMC_DCPD/H1OMCDPCD_HF.py

Right now it is set to collect data from these two channels (line 62 of the code):

channels = ["H1:OMC-DCPD_A0_OUT", "H1:OMC-DCPD_B0_OUT"]

The amount of time to collect data is set on line 66:

duration = 600  # seconds

To run the code:

> conda activate labutils

> python H1OMCDPCD_HF.py

The files will be saved in /ligo/home/elenna.capote/OMC_DCPD in a new folder labeled with a datetime and "xcorr_data" since I have traditionally used this script to collect data for cross correlation measurements. However, you can change the label on line 71, label="xcorr_data"

The output is a set of 1 second HDF5 frames for each second of data collection (so 600 seconds = 600 files). To put this data into a single .gwf format of the full data length, which can easily be read in with GWPY, use the combine.py script. Copy combine.py into the new directory with the frames and run it. The code generates a file for each OMC DCPD channel at the full rate, and at a decimated 64 kHz rate.

This is a bit odd the way it is set up, but the way this works ensures that even if you have to quit the script early, you don't lose all the data, since it saves each file by the second.

Lockloss at 2025-07-17 04:11 UTC due to a power issue with ETMX and TMSX. Currently in contact with Dave and Fil is on his way in.

ETMX M0 and R0 watchdogs tripped

ETMX and TMSX OSEMs are in FAULT

ETMX ESD off

ETMX HWWD notified that it would trip soon, so SEI_ETMX was preemptively put into ISI_OFFLINE_HEPI_ON to keep ISI from getting messed up when it trips

TITLE: 07/15 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 15mph Gusts, 9mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.14 μm/s
QUICK SUMMARY: We've only been at low noise for 20 min, but magnetic injections are running now. Maintenance day today.

Jim, Elenna

We had a 6.6 earthquake begin rolling in from Panama, so Jim and I tried to take the ASC arm control loops to the high bandwidth state. I also turned off the LSC feedforward which drives the ETMY PUM.

This obviously creates a lot of noise in DARM, but we are curious to see if it helps us ride out a large earthquake.

This consists of:

• turning off low pass and other shaping filters for DHARD P, DHARD Y, CHARD Y and CHARD Y
• adjusting CHARD P and Y gains
• increasing DSOFT P and Y gains
• changing LSC feedforward gains to zero

Some of these things can be done by hand, but others, like transitioning filters and gains together have to be done with guardian code to ensure they are done at the same time. I copied and pasted lines of code into a guardian shell.

These are the lines of code that will do everything I mentioned above:

Jennie W, Rahul

Yesterday we made some measurements to calibrate the spot size on the QPD as we scan the beam position across it.

We used a connector Fil made us to plug in the OT301 QPD amplifier into a DC power supply after checking it contained voltage regulators that could cope with a voltage between 12 and 19 V ( as the unit says it expects DC supply but the previous one we were using was AC with a 100mA current rating and was getting too hot so we assume that was the incorrect one). We hooked it up at 16V (this draws about 150mA of current). The QPD readout looks normal and does not have any of the strange sawtooth we saw with the original power cable.

We moved the M2MS beam measurement system out of the way of the translation stage.

To calibrate the QPD we need to change the lateral position of the M1 mirror and lens to change the yaw positioning on the QPD and measure the X and Y voltages from the QPD.

We need to check we are centred first. The QPD bullseye readout shows the beam is off a tiny bit in yaw but this was as good as we could get at centering the beam when we moved the QPD. All 8 PDs are reading about 4.6 V so this means the beam is well centred in the array plane.

We measure 11000 counts on the bullseye qpd readout at this M1 position.

I plotted the data from lowest reading on the translation stage to highest and fitted the linear region using Calibrate_QPD.m which is attached.

Data is shown in attached pdf.

The slop of the linear region in V/inch is 112 V/inch. Which means to if the beam moved 8.93 e-3 inches on the QPD in yaw, the yaw readout would change by 1 Volt.