Naoki, Sheila, Camilla

In alog74059, it was pointed that the 80Hz BLRMS increased by 1.5dB after FC2 centering on October 27th, and this could be due to FC detuning change caused by the FC2 centering. Today we changed the FC detuning by +- 20 Hz from the nominal -28 Hz, but the nominal detuning seems already optimal as shown in the attached figure. We left the FC detuning at nominal value -28 Hz.

I went back and forth (~5 mins each) with the BS M2 coil drivers between their nominal low noise state, and their higher noise higher range state. 

When in the higher noise state (state 2), there seems to be consistently higher noise between about 55 Hz up to 100 Hz. In the attached plot the blue / green is the nominal low noise state, while red / pink is the high noise state.

I'll work on making this an actual noise projection that we can include in the noise budget, using Craig's code for quad PUM noise as a guide.

We were in the high noise state 2 from 20:56:45 - 21:04:00.  Then in low noise state from 21:06:10 - 21:11:15 (there's a glitch during this time).  Back to high noise from 21:13:20 - 21:19:40 (there's a small glitch during this time).  Back to low noise from 21:21:50 - 21:28:00.  All times UTC on 8 Nov 2023.  After this I handed back to Robert.

Oli Patane, Jeff Kissel

Continuing through our plan(T2300376) for the new O5 A+ suspensions (HRTS, HATS, and BBSS), we have finished, compiled, and installed the Simulink models for HRTS and BBSS onto the Triples and BSC teststands respectively. The models that we installed can be found in /opt/rtcds/userapps/release/sus/x1/models/x1sus{bs,lo1}.mdl.

Also, we are close to done creating the medm suspension overview screens for HATS and HRTS (/opt/rtcds/userapps/release/sus/common/medm/hxts/SUS_CUST_{HRTS,HATS}_OVERVIEW.adl). They still need some editing, but here are the current state of the medm screens for the HRTS and the HATS.

Naoki, Camilla

Last Friday 73773 Nov 3 (black trace, IFO locked 6h30), Naoki found the MICH FF had degraded since measured on Oct 27 (pink trace IFO locked 23h). Today we measured the MICH FF using /lsc/h1/scripts/feedforward/MICH_excitation_comparison.xml after the IFO had been locked 3 hours  (yellow trace) and 7 hours (grey trace). See attached.

MICH FF effectiveness improves as the IFO thermalizes (compare yellow to grey) but also seems to be degrading over ~days (compare grey to black). MICH FF last tuned Oct 12 73420.

Double EndY Station Measurement!
We did the Same Measurement twice in the same configuration to determine if there would be any changes from one hour to the next.   

First ENDY Station Measurement:
During the Tuesday maintenace, the PCAL team(Rick Savage & Tony Sanchez) went to ENDY with Working Standard Hanford aka WSH(PS4) and took End station measurements.
The ENDY Station Measurements were carried out according to the procedure outlined in Document LIGO-T1500062-v15, Pcal End Station Power Sensor Responsivity Ratio Measurements: Procedures and Log, and was completed by 10:30 am.
First Measurement Log
 

First thing we did is take a picture of the beam spot before anything is touched!

Martel votlage injection into the DAQ:
Martel_Voltage_Test.png graph. We also did a measurement of the Martel's voltages in the PCAL lab to calculate the ADC conversion factor, which is included on the above document.

After the Martel measurement the procedure walks us through the steps required to make a series of plots while the Working Standard(PS4) is in the Transmitter Module. These plots are shown in WS_at_TX.png.

Next steps include: The WS in the Receiver Module, These plots are shown in WS_at_RX.png.

Followed by TX_RX.png which are plots of the Tranmitter module and the receiver module operation without the WS in the beam path at all.
The last picture is of the Beam spot after we had finished the measurement.
All of this data is then used to generate LHO_ENDY_PD_ReportV2.pdf which is attached, and a work in progress in the form of a living document.
Note: both measurements are on this Report.

NONE of this data and Analysis has been commited to the SVN as I have been Locked out of the SVN.
But it would have gone here: https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Projects/PhotonCalibrator/measurements/LHO_ENDY/

Then we did the measurement again,
Second Measurement Log
Martel plot
WS @ TX
WS @ RX
TX & RX
LHO EY PD Report V2 for the Second measurement
Final Beam Spot

PCAL Lab Responsivity Ratio Measurement:
A WSH/GSHL (PS4/PS5)FrontBack Responsivity Ratio Measurement was ran, analyzed, and pushed to the SVN.
The analysis of this measurement produces 4 PDF files which we use to vet the data for problems.
raw_voltages.pdf
avg_voltages.pdf
raw_ratios.pdf
avg_ratios.pdf

NONE of this lab data and Analysis has been commited to the SVN.

Obligitory BackFront PS4/PS5 Responsivity Ratio:
A WSH/GSHL (PS4/PS5)BF Responsivity Ratio measurement was ran, analyzed, and pushed to the SVN.
The analysis of this measurement produces 4 PDF files which we use to vet the data for problems.
raw_voltages2.pdf
avg_voltages2.pdf
raw_ratios2.pdf
avg_ratios2.pdf

PS4_PS5 AlphaPrime Lab Trends

This adventure has been brought to you by Rick Savage & Tony Sanchez.

TITLE: 11/08 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Locked for 7 hours. We've been commissioning since 12PT (20UTC), that is now wrapping up but we are going to run a calibration measurement.
LOG:

• 1710 Observing
• 2000 Out if observing for 4 hours of commissioning

The lock-loss-alert system is now running the old, non-Twilio code. Twilio is not able to send text messages until we verify our 'brand' with The Campaign Registry. Today was a registration deadline, so their verification service is very busy.

This means that we are back to using the cell phone providers (Verizon, ATT, etc) to send the SMS texts. I would recommend everyone who depends upon alert texts to send a test message before their shift starts.

This also means that unfortunately voice calling is not available, email and texts only.

Once Twilio is able to send our texts again, I'll switch back to the new software.

I'm not yet sure why, but we have abnormally high coherence with MICH ASC today.  I wonder if this is related to our low PRG, and the fact that the power recycling gain seems to be about 3x more wobbly than normal.

Wed Nov 08 10:11:10 2023 INFO: Fill completed in 11min 6secs

Travis confirmed a good fill curbside. TCs were displaced by ice ball.

Back to Observing after a rough night of earthquakes. Lock acquisition was fully automated which is fantastic to see after large earthquakes!

Our range looks a bit lower over the past 24 hours. Power recycling gain seems to be lower than normal as well. Doesn't seem to be correlated with the higher microseisms that we've been seeing (see attached).

TITLE: 11/08 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Earthquake
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 4mph Gusts, 3mph 5min avg
    Primary useism: 0.10 μm/s
    Secondary useism: 0.25 μm/s
QUICK SUMMARY: A few large earthquakes have been keeping us out of lock overnight, but lock acquisition has recently started. The earth is still moving a bit so we'll see how this goes.

CDS OK, no alarms.

Was alerted at 9:09UTC

IFO was in NLN but could not move into observing due to 2 (attached screenshot) SDF diffs in ALS Y, which I accepted.

IFO reached OBSERVING at 9:21UTC

TITLE: 11/08 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 146Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:

The last few hours of the shift turned out to be eventful with a large earthquake hovering at high seismic levels for 2.5hrs which made locking Green Arms impossible.  In the last 30min of the shift, seismic finally looked like it was sort of coming down, so I attempted an Initial Alignment.  X-arm showed signs of life and eventually was aligned, but the Y-arm gave an error about the Camera Centering being too far off.  I ran a DOWN out of the Initial Alignment due to the Y-arm, to see if I could do anything.  I might have messed up the Xarm because when I tried locking again, X-arm was no longer aligned and had no light in the arm (I returned ETMx & TMSx to where they were when it was aligned).  At this point, I'm letting ISC LOCK take over (both X & Y arms are in INCREASE FLASHES).

Unfortunate timing with the earthquake and frustrating last 30min of the shift.

Addendum:  as I log out, atleast the Y-arm now has life after INCREASE FLASHES and can finally OFFLOAD with a quieter ground.  Xarm....looks a little glitchy, but is trying to offload.....and now it is moving on to FINDING IR.
LOG:

• 0029 Out of PCal Lab (tony)
• 0509 EQ Mode activated (nothing on USGS)
  • 0511 M6.8 Earthquake from Timor/Banda Sea/North of Australia
  • 0512 Squeezer unlocks and drops H1 from Observing
  • 0513 Lockloss
• 0729 Initial Alignment attempted.
  • Unfortunately, something appears amiss with the Y-arm.  It has decent flashes but for the last hour or so it hasn't been able to lock for more than a second or two now.  
  • During the Initial Alignment while ALSY was in the ENABLE WFS state, ALSY gives the note about the "Camera centering being too far off.  Need to turn on slowly." And the node would then be stuck at this point.  I don't see any obvious errors on the ALS screen. 

H1 taken to Earthquake mode at 0509utc; started seeing seismic signal on Picket Fence and seismic blrms.  Squeezer unlocked taking H1 out of Observing and then lockloss 1-min later.  It's been about 15min since the EQ waves hit us and seismic is still increasing (ISC LOCK has x&y arms at INCREASE FLASHES).  Marking time as EARTHQUAKE.

1383346365

This lock loss had another one of the LSC-DARM wiggles ~100ms before the lock loss.

There was HVAC work going on at EX at the time, but I don't see much ground motion at that time, so I'm inclined to rule them out.

Summary:

It seems that the supply voltage for thermistors is oscillating, the frequency depends on whether or not the supply is loaded with thermistors (830mHz open to 1.66Hz fully connected to the in-chamber thermistors), the amplitude of the oscillation jumps seemingly randomly, and this is also happening for the unused Beckhoff module for the yet-to-be-installed second T-SAMS unit, all measured at the back of the Beckhoff chassis. (Can't we measure this from Beckhoff itself, without me going to the floor?)

Fil and Fernando quickly set up the same Beckhoff module in the lab and didn't observe this. Could we swap or maybe restart the modules in the chassis?

As of now, Beckhoff cable is disconnected from the back of the heater driver chassis. (I'm applying DetChar-Request tag just so people know, but we're just changing from one no-comb configuration to the other.)

Detaisls:

Since the past findings about OM2 and 1.66Hz comb (alogs 73367, 73233, 72967 72241 and 72061) didn't make sense, I went to the floor and remeasured the comb in the Beckhoff heater output (which goes to the heater driver input) as well as thermistor pins in the back of the heater driver chassis while Beckhoff connection was intact.

Turns out that all of these things share the same frequency but the voltage across thermistor pins was ~3 orders of magnitude larger than Beckhoff heater driver output pins (pin 9 and 19) (the latter were referenced from the driver board ground as it's common mode for both pins). I used a scope on battery and the thermistor voltage was like roughly 1Vpp 1.66Hz rectangular wave (1st pic). Yellow is the voltage across pin10 and 23 (across thermistor 1), blue is pin9 and 22 (thermistor 2) of the DB25 at the back of the driver chassis when the Beckhoff cable was still connected.  Voltage difference seemed to have come from the temperature difference of the thermistors (I disconnected the Beckhoff cable and measured the thermistor 1 and 2 resistance incl. cables to be 7.41k and 4.08k, respectively). When I disconnected the cable from the chassis and just measured the pin10-23 and pin9-22 voltage coming from the cable (picture 2), they were both about 1.2V pp. This is supposed to be the source voltage for thermisters. The frequency slowed down by about a factor of 2 (832mHz) when the thermistors were disconnected.

For your convenience, below is a table of which pins are what (see e.g. E1100530 and D2000212). Note that thermistors themselves only have two pins, therefore supply and readback pins are bundled together in chamber as shown. Supply is presumably a reference voltage supplied through a reference resistor.

Went to the CER, disconnected the cable from the back of the Beckhoff chassis and did the same measurement. Frequency didn't change but the amplitude was much smaller (~280mVpp instead of 1.2Vpp) for a while, but suddenly the amplitude of the thermistor 1 supply changed back to 1.2V (pic 3). Nuts. When the beckhoff cable was reconnected (and the connection to in-chamber thermistor was restored) the frequency went back to 1.66Hz (picture 4).

Picture 5 shows pin 10-23 (thermistor 1 supply) and pin12-25 (thermistor 1 readback, which is not connected to anything). Picture 6 is the same thing but for the unused Beckhoff unit for the second T-SAMS. It's strange that the same thing is happening in two independent units. Picture 7 is the thermistor 1 supply and pin 6-19 (voltage output for the heater driver). It really seems that this is a problem of the supply voltage.

I checked the 24V power strip for the Beckhoff chassis but it was good (pic 8 and 9).

Fil and Fernando set up EL3692, which is the Beckhoff unit used for Thermistors. They didn't observe this oscillation behavior.

I wanted to do some injections into thermistors to see how this couples to DARM but didn't have time.