M. Todd, S. Dwyer
This morning Sheila and I went out to HAM7 to move the OPO crystal to try and get rid of some loss, continuing from this work.
We got the translation stage driver out of the SQZ cabinet and after a bit of fiddling with the connector, we were able to see a response in the IR and Green transmission.
From here we moved the OPO to the right and then back to the left, measuring the NLG and Threshold Power at each position:
Position | Max | OPO Therm. | Green Launch | Unamp. | Dark | NLG | P_thres[uW] | P_set [uW] | Notes |
---|---|---|---|---|---|---|---|---|---|
0 | 0.0577 | 30.698 | 0.00663 | 0.0000232 | 8.73 | 90.35 | 80 | 8:58 AM | |
20 | 0.052 | 30.647 | 7.87 | 91.65 | 80 | 9:06 AM | |||
40 | 0.049 | 30.618 | 20.7 | 7.41 | 92.47 | 80 | 9:15 AM | ||
60 | 0.0477 | 30.593 | 19.85 | 7.22 | 92.87 | 80 | 9:21 AM | ||
0 | 0.0494 | 30.61 | 20.5 | 7.47 | 92.36 | 80 | 9:25 AM | ||
-10 | 0.0498 | 30.612 | 20.6 | 7.53 | 92.24 | 80 | 9:33 AM | ||
-20 | 0.0499 | 30.613 | 20.7 | 7.55 | 92.22 | 80 | 9:37 AM | ||
-40 | 0.0502 | 30.616 | 20.8 | 7.59 | 92.13 | 80 | 9:41 AM | ||
-60 | 0.0508 | 30.624 | 21 | 7.69 | 91.97 | 80 | 9:45 AM | ||
-80 | 0.0512 | 30.63 | 21.2 | 7.75 | 91.86 | 80 | 9:52 AM | ||
-100 | 0.0515 | 30.634 | 21.3 | 7.79 | 91.78 | 80 | 9:55 AM |
As you can you see when we "returned" to our starting position our NLG never returned to its starting point. Sheila and I went back into the control room to try and recover the NLG via adjusting the OPO temp, but in un-plugging the driver before digitally closing the connection, we think we kicked the OPO into a very different position than expected. To even get something sensible we had to change the OPO temp by over one degree celcius -- far more than should be necessary to get the Green and IR to be coresonant.
So after lunch, we back into the LVEA and connected the driver again as well as a function generator to the OPO PZT, reading the IR and Green transmissions onto a scope. We also increased the seed power to 2W so that we could see it on the scope more easily. Ensuring the connector was more properly setup, we moved the OPO a BUNCH to the left to get the Green and IR to be co-resonant. After awhile the driver would not let me move it to the left anymore, (though it would let me move to the right a couple steps but then NOT retrace my steps back left...), so we decided to leave it as it was. At the end of it we had moved 22 x 50 steps (+ 1 x 10 steps) to the left, and decided to do the rest of the actuation with the OPO temp.
We measured the NLG in the final position and it was disappointingly low but we decided to regroup and think about things.
Position | Max | OPO Therm. | Green Launch | Unamp. | Dark | NLG | P_thres[uW] | P_set [uW] | Notes |
---|---|---|---|---|---|---|---|---|---|
-1110 | 0.00186 | 30.46 | 15.5 | 3.40E-4 | -2.70E-5 | 5.137 | 99.34 | 80 | |
-1110 | 0.00280 | 3.48E-4 | -2.70E-5 | 7.539 | 121.06 | 105 |
More to come, and more to think about!
$python3 generate_measurement_data.py --WS PS4 --date 2025-06-24
Reading in config file from python file in scripts
../../../Common/O4PSparams.yaml
PS4 rho, kappa, u_rel on 2025-06-24 corrected to ES temperature 299.2 K :
-4.70052522573445 -0.0002694340454223 2.66508565972755e-05
Copying the scripts into tD directory...
Connected to nds.ligo-wa.caltech.edu
martel run
reading data at start_time: 1435423390
reading data at start_time: 1435423770
reading data at start_time: 1435424085
reading data at start_time: 1435424665
reading data at start_time: 1435425020
reading data at start_time: 1435425335
reading data at start_time: 1435425435
reading data at start_time: 1435426070
reading data at start_time: 1435426405
Ratios: -0.46199911560110457 -0.4661225769446798
writing nds2 data to files
finishing writing
Background Values:
bg1 = 9.235188; Background of TX when WS is at TX
bg2 = 5.284960; Background of WS when WS is at TX
bg3 = 9.145166; Background of TX when WS is at RX
bg4 = 5.413446; Background of WS when WS is at RX
bg5 = 9.219525; Background of TX
bg6 = 0.642557; Background of RX
The uncertainty reported below are Relative Standard Deviation in percent
Intermediate Ratios
RatioWS_TX_it = -0.461999;
RatioWS_TX_ot = -0.466123;
RatioWS_TX_ir = -0.455904;
RatioWS_TX_or = -0.461457;
RatioWS_TX_it_unc = 0.092717;
RatioWS_TX_ot_unc = 0.098001;
RatioWS_TX_ir_unc = 0.097458;
RatioWS_TX_or_unc = 0.092076;
Optical Efficiency
OE_Inner_beam = 0.986610;
OE_Outer_beam = 0.990080;
Weighted_Optical_Efficiency = 0.988345;
OE_Inner_beam_unc = 0.062698;
OE_Outer_beam_unc = 0.063147;
Weighted_Optical_Efficiency_unc = 0.088986;
Martel Voltage fit:
Gradient = 1636.767545;
Intercept = 0.229197;
Power Imbalance = 0.991154;
Endstation Power sensors to WS ratios::
Ratio_WS_TX = -1.077445;
Ratio_WS_RX = -1.391120;
Ratio_WS_TX_unc = 0.058121;
Ratio_WS_RX_unc = 0.042422;
=============================================================
============= Values for Force Coefficients =================
=============================================================
Key Pcal Values :
GS = -5.135100; Gold Standard Value in (V/W)
WS = -4.700525; Working Standard Value
costheta = 0.988362; Angle of incidence
c = 299792458.000000; Speed of Light
End Station Values :
TXWS = -1.077445; Tx to WS Rel responsivity (V/V)
sigma_TXWS = 0.000626; Uncertainity of Tx to WS Rel responsivity (V/V)
RXWS = -1.391120; Rx to WS Rel responsivity (V/V)
sigma_RXWS = 0.000590; Uncertainity of Rx to WS Rel responsivity (V/V)
e = 0.988345; Optical Efficiency
sigma_e = 0.000879; Uncertainity in Optical Efficiency
Martel Voltage fit :
Martel_gradient = 1636.767545; Martel to output channel (C/V)
Martel_intercept = 0.229197; Intercept of fit of Martel to output (C/V)
Power Loss Apportion :
beta = 0.998895; Ratio between input and output (Beta)
E_T = 0.993606; TX Optical efficiency
sigma_E_T = 0.000442; Uncertainity in TX Optical efficiency
E_R = 0.994705; RX Optical Efficiency
sigma_E_R = 0.000443; Uncertainity in RX Optical efficiency
Force Coefficients :
FC_TxPD = 7.903342e-13; TxPD Force Coefficient
FC_RxPD = 6.193451e-13; RxPD Force Coefficient
sigma_FC_TxPD = 5.805084e-16; TxPD Force Coefficient
sigma_FC_RxPD = 3.826232e-16; RxPD Force Coefficient
data written to ../../measurements/LHO_EndX/tD20250701/
Comment regarding the missing signal on the EX Pcal MEDM:
We noticed that H1:CAL-PCALX_OFS_DRIVE_MON was not working as expected a few weeks ago. On this expedition to make ES measurements, Dripta and I used a few breakout boards to ensure that the "OFS drive monitor" signal was coming out of the Pcal chassis and into the ADC Chassis. We confirm that there was a signal coming out of the Pcal Interface Chassis back board (D1400149V1), the DB9 output labeled "To Fast ADC", pins 1 and 6 (not the same name but, by process of elimination, we assume that "OFS drive monitor" is, in the drawing, "InLoopOut±") , so we can rule out the Pcal chassis. Due to lack of time, however, we were not able to pinpoint the step at which this signal is lost.
Tony found the next step in our hunt: Page 3 of D1300226V13 shows the ADC side of "To Fast ADC", specifically, "ADC CHAN±00" is assigned, in the drawing, to InLoopOut± . I am tagging CDS for any insight on their side. Discussions and a follow-up plan are in progress to find the signal.
Jeff, Sheila, Elenna
Executive summary: Our input alignment has changed. We know this because the alignment onto IM4 trans has changed. This corresponds to the IMs 1-3 OSEMs showing a change, which corresponds with HAM2 being taken offline to change the power supply.
Today, an H1SEI23 power supply was replaced, and preceding this activity HAM2 and HAM3 were taken offline, 85475.
When HAM2 came back online, the OSEM readbacks on IMs 1-3 showed a change in both pitch and yaw. The table below summarizes how much each suspension's alignment has changed.
IM | Pit change (urad) | Yaw change (urad) |
1 | 2 | 0 |
2 | 66.8 | 2.7 |
3 | 14.8 | 4.3 |
This shift in alignment is also apparent on IM4 trans, which shows the pitch offset has increased by 0.3 and yaw offset by 0.03 (uncalibrated).
We first noticed something had changed when we ran input alignment- I had to move PR2 by 5 microradians in both pitch and yaw just to get the lock to catch, and then the alignment offload further changed the PR2 sliders.
This change is further backed up by the fact that the POP A offsets have changed, and the PRG at 2 W seems to have decreased slightly.
We're not sure how bad of a problem this is. We have been able to lock and power up with no issues. We had a random unrelated lockloss, so I cannot yet see if the buildups at full power once thermalized have changed significantly.
The locking process is now much slower again, since the alignment offsets for the PRM have changed, and the convergence of the PRM ADS tends to set the rate at which we can engage ASC in full lock.
The first two attachments are screenshots show the shift in the IM alignment and IM4 trans alignment. I included the HAM2 ISI guardian state to show this change corresponds with HAM2 going offline.
The third attachment shows how the POP A offset has changed at full IFO 2 W. We can use this scope to adjust the POP A QPD offset and speed up locking, if we want to keep this input alignment.
The fourth attachment shows the ITMX green camera offset screen in full IFO at 2 W. I was watching this screen to confirm the new ITMX green camera offsets I set earlier today were ok. I think the set value differs from the live value here because of the new input alignment.
We sat at full power for 1 hour and had thermalized to a PRG of 49. Trending back to our last lock before maintenance it looks like we achieve about the same PRG in this amount of time, so there is minimal impact on the buildups. There might be a small reduction in the jitter coupling. We should check again when fully thermalized to be sure.
Since we are going to stay this way for at least tonight, I updated the POP A offsets to help shorten ENGAGE ASC FOR FULL IFO. SDF attached.
I ran my damp_regression_compare script (85369) on the suspensions that we swapped the satellite amplifiers for today, BS, PRM, PR3, SRM, and SR3. The results show a decrease in the OSEM noise of at least 2x!
Part of what the script does is save the channel data as a .mat file so it's quicker to run next time, so I'll post that as well as the results.
BS
Results: /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Results/allDampRegressCompare_H1SUSBS_M1_NoiseComparison_1435348334vs1435435046-1200.pdf
r12374
Data: /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Data/dampRegress_H1BS_M1_1435348334_1200.mat
/ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Data/dampRegress_H1BS_M1_1435435046_1200.mat
r12373
PRM
Results: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Results/allDampRegressCompare_H1SUSPRM_M1_NoiseComparison_1435348334vs1435435046-1200.pdf
r12376
Data: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data/dampRegress_H1PRM_M1_1435435046_1200.mat
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data/dampRegress_H1PRM_M1_1435348334_1200.mat
r12375
PR3
Results: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Results/allDampRegressCompare_H1SUSPR3_M1_NoiseComparison_1435348334vs1435435046-1200.pdf
r12380
Data: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Data/dampRegress_H1PR3_M1_1435348334_1200.mat
/ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Data/dampRegress_H1PR3_M1_1435435046_1200.mat
r12379
SRM
Results: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Results/allDampRegressCompare_H1SUSSRM_M1_NoiseComparison_1435348334vs1435435046-1200.pdf
r12378
Data: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/dampRegress_H1SRM_M1_1435435046_1200.mat
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/dampRegress_H1SRM_M1_1435348334_1200.mat
r12377
SR3
Results: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Results/allDampRegressCompare_H1SUSSR3_M1_NoiseComparison_1435348334vs1435435046-1200.pdf
r12382
Data: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/dampRegress_H1SR3_M1_1435348334_1200.mat
/ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/dampRegress_H1SR3_M1_1435435046_1200.mat
r12381
Since a few of the before times I picked for some of the suspensions were during times where they had ISC control on, I've rerun them with a better starting time where there was no ISC control
BS
Results: /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Results/allDampRegressCompare_H1SUSBS_M1_NoiseComparison_1435154988vs1435435038-1200.pdf
r12436
Data: /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Data/dampRegress_H1SUSBS_M1_1435154988_1200.mat
/ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Data/dampRegress_H1SUSBS_M1_1435435038_1200.mat
r12437
PRM
Results: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Results/allDampRegressCompare_H1SUSPRM_M1_NoiseComparison_1435154988vs1435435046-1200.pdf
r12438
Data: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data/dampRegress_H1SUSPRM_M1_1435435046_1200.mat
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data/dampRegress_H1SUSPRM_M1_1435154988_1200.mat
r12438
SRM
Results: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Results/allDampRegressCompare_H1SUSSRM_M1_NoiseComparison_1435154988vs1435435046-1200.pdf
r12441
Data: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/dampRegress_H1SUSSRM_M1_1435435046_1200.mat
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/dampRegress_H1SUSSRM_M1_1435154988_1200.mat
r12441
TITLE: 07/01 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 131Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:
Maintenance Day.
Model changes, then DAQ restart at noon--
LOG:
TITLE: 07/01 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 18mph Gusts, 11mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.05 μm/s
QUICK SUMMARY: H1 has just relocked following the maintenance period today, but currently waiting in OMC_WHITENING to damp some very rung-up violin modes. Meanwhile, Elenna is running jitter noise injections. I'm also aware of the OPO crystal move from today, so I'll be watching SQZ performance this evening and will adjust the temperature if need be.
FAMIS 28412, last ran and analyzed in alog85311
The analysis for this week's ITMX measurements failed again, same as last week, due to too low of coherence (0.01219488098759549, which is below the threshold of 0.1), so there's not a new data point for the ITMX plot. All other QUAD's analyses ran without issue.
Camilla, TJ, Dave:
Last Thursday 26th June 2025 alog85373 I restarted the HWS camera control code. We hoped this would improve the 2Hz noise comb in DARM. Initial results for F-Scan (observing) suggest it has not made much, if any difference.
Attached F-Scans show the spectra on sun22jun2025 and mon30jun2025. The 2Hz comb (blue squares) look unchanged.
More investigation is needed to verfiy we are indeed disabling the frame aquisition on all HWS cameras when H1 is in observation.
Looking at the HWS camera data, Dave's code was successfully stopping the HWS camera dueing NLN from 27th June, as expected 85373.
However, looking at the f-scans from the last week, the 2Hz comb was there until 3rd July but was gone on 4th July and hasn't returned since.
Nothing HWS related should have changed on the 3rd July (ops shift log 85519).
Excellent, thank you Camilla and Dave! This is very helpful.
WP12649 Add h1ascimc WFS_B_DC chans to DAQ
Elenna, Dave:
A new h1ascimc model was installed which adds two 16kHz versions of the WFS_B_DC channels to the DAQ. The new channels are
H1:IMC-WFS_B_DC_[PIT,YAW]_OUT_16K_DQ
A DAQ restart was required.
WP12635 VACSTAT HAM1 update
Dave:
A new H1EPICS_VACSTAT.ini was generated. This removes the temporary H1-PT100B VACSTAT gauge and adds the new HAM1 PT100_MOD2 gauge to the DAQ. After the EDC+DAQ restart, VACSTAT was restarted sans H1-PT100B now it is longer needed by EDC.
WP12637 HWS Camera Control
Dave
As part of getting the HWS camera control system running again, its new IOC was added to the EDC via H1EPICS_HWSCAMCTRL.ini. EDC+DAQ restart was needed
DAQ Restart
Dave, Jonathan, Erik
DAQ was restarted for four changes:
1) New H1ASCIMC.ini, adding two new fast DQ channels.
2) New H1EPICS_VACSTAT.ini, removing obsolete VACSTAT chans associated with H1-PT100B
3) Removed H1EPICS_VACHAM1.ini, which was trending the temporary H1 version ot PT100B
4) Added new H1EPICS_HWSCAMCTRL, new HWS camera control's IOC non-string channels.
This was a very messy restart.
After restarting the h1ascimc model, the 0-leg was restarted. A second restart of GDS0 was needed.
After writing two full frames, FW0 crashed and restarted itself.
Once FW0 was back, the 1-leg was restarted. GDS1 needed a second restart.
About 10 minutes later, FW0 had a second crash. This is not unheard of, but very rare.
In the course of investigating it was discovered that FW1 had an unused 1TB Seagate HDD (sda) which has been generating errors over the past month. We decided to remove this from h1daqfw1 since it served no purpose.
Following the DAQ restart, item 2) removal means I can stop running the temporary EPICS IOC vac_ham1_pressure_converter_ioc. This code no longer runs on opslogin0 in a tmux session.
WP12651 Replace h1seih23 IO Chassis +24VDC power supply
Fil, Marc, Erik, Dave:
h1seih23 was fenced and powered down. The IO Chassis was then powered down and its +24VDC supply was replaced (bad fan bearing). System was powered back up with no issues.
Tue01Jul2025
LOC TIME HOSTNAME MODEL/REBOOT
12:30:40 h1asc0 h1ascimc <<< new model
12:33:47 h1daqdc0 [DAQ] <<< 0-leg restart
12:34:00 h1daqfw0 [DAQ]
12:34:00 h1daqtw0 [DAQ]
12:34:01 h1daqnds0 [DAQ]
12:34:08 h1daqgds0 [DAQ]
12:34:12 h1susauxb123 h1edc[DAQ] <<< EDC restart, VACSTAT, H1-PT100B, HWSCAMCTRL
12:35:18 h1daqgds0 [DAQ] <<< 2nd GDS0 restart
12:38:34 h1daqfw0 [DAQ] <<< FW0 First Crash
12:42:18 h1daqdc1 [DAQ] <<< 1-leg restart
12:42:29 h1daqfw1 [DAQ]
12:42:30 h1daqtw1 [DAQ]
12:42:32 h1daqnds1 [DAQ]
12:42:40 h1daqgds1 [DAQ]
12:43:42 h1daqgds1 [DAQ] <<< 2nd GDS1 restart
13:02:52 h1daqfw0 [DAQ] <<< FW0 Second Crash
13:42:22 h1daqfw1 [DAQ] <<< FW1 restarted to remove faulty sda HDD
14:00:38 h1seih23 h1iopseih23 <<< h1seih23 front end power cycle to replace DC power supply
14:00:51 h1seih23 h1hpiham2
14:01:04 h1seih23 h1hpiham3
14:01:17 h1seih23 h1isiham2
14:01:30 h1seih23 h1isiham3
DAQ Changes (NAME, TYPE, RATE)
+ H1:CDS-HWS_CAM_CTRL_ETMX_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ETMX_START_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ETMX_STATUS 4 16
+ H1:CDS-HWS_CAM_CTRL_ETMX_UPTIME_SEC 4 16
+ H1:CDS-HWS_CAM_CTRL_ETMY_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ETMY_START_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ETMY_STATUS 4 16
+ H1:CDS-HWS_CAM_CTRL_ETMY_UPTIME_SEC 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMX_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMX_START_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMX_STATUS 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMX_UPTIME_SEC 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMY_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMY_START_GPS 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMY_STATUS 4 16
+ H1:CDS-HWS_CAM_CTRL_ITMY_UPTIME_SEC 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_CONN_VALID 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_ENABLED 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_GLITCH 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_GLITCH_GPS 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_DELTAP_300 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_DELTAP_60 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_DELTAP_600 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_DELTAP_TRIP_300 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_DELTAP_TRIP_60 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_DELTAP_TRIP_600 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_INTERCEPT_300 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_INTERCEPT_60 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_INTERCEPT_600 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_SLOPE_300 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_SLOPE_60 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_SLOPE_600 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_SLOPE_TRIP_300 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_SLOPE_TRIP_60 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_LIVE_SLOPE_TRIP_600 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_OPERATIONAL 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_VALID 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_VALUE 4 16
+ H1:CDS-VAC_STAT_LX_X0_PT100_MOD2_VAL_VALID 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_CONN_VALID 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_ENABLED 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_GLITCH 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_GLITCH_GPS 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_DELTAP_300 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_DELTAP_60 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_DELTAP_600 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_DELTAP_TRIP_300 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_DELTAP_TRIP_60 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_DELTAP_TRIP_600 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_INTERCEPT_300 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_INTERCEPT_60 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_INTERCEPT_600 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_SLOPE_300 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_SLOPE_60 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_SLOPE_600 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_SLOPE_TRIP_300 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_SLOPE_TRIP_60 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_LIVE_SLOPE_TRIP_600 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_OPERATIONAL 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_VALID 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_VALUE 4 16
- H1:CDS-VAC_STAT_LY_X0_PT100B_VAL_VALID 4 16
+ H1:IMC-WFS_B_DC_PIT_OUT_16K_DQ 4 16384
+ H1:IMC-WFS_B_DC_YAW_OUT_16K_DQ 4 16384
- H1:VAC-LY_X0_PT100B_GPS_TIME 4 16
- H1:VAC-LY_X0_PT100B_PRESS_TORR 4 16
- H1:VAC-LY_X0_PT100B_UPTIME 4 16
FAMIS 25806
pH of PSL chiller water was measured to be between 10.0 and 10.5 according to the color of the test strip.
E. Capote, J. Kissel, A. Sanchez, D. Barker, E. von Reis
Per WP#12649, the ASCIMC model was updated. Two test points were added to the IMC-WFS_B_{PIT,YAW}_OUT outputs that were then DQed to 16k, see attached screenshot of the new testpoints. These channels are being saved at the higher rate so they can be used as jitter witnesses, see attached screenshot of the channel list. The new channel names are "IMC-WFS_B_{PIT,YAW}_16K_OUT". Erik helped me set up these new test points, and Dave took care of the model and DAQ restart.
Before the model restart, I had checked the ASCIMC model and saw no SDF differences, so I assumed that we were good to go to restart the model. Here are two errors I made:
Once the restart had happened, and SDF reverted, the IMC came back very poorly aligned. Jeff and Tony had to move the IMC PZT offset by "hundreds of counts" to get us back to a good enough alignment to lock. After that, Jeff, Tony, and I proceeded to engage the IMC WFS, and turned up the WFS gain to 0.5 to help the loops converge faster. Once they converged, we took the IMC guardian to "MCWFS offloaded". Here, we made another mistake by forgetting to accept the PZT offsets in SDF, so when ISC_LOCK went through the "SDF revert" state, the offsets were set to some old value, which put the IMC back in a bad alignment. We repeated the process again, and this time remembered to save the new offsets in the SDF. I have attached a screenshot of this change.
Per WP12651 we investigated and replaced the IO Chassis supply for H1SEI23 which supports seismic on HAM 2 & 3. This supply is located in Mezanine rack C3, location U2 Right Side, provides +24V, and measured ~3.5A draw. The fan was chirping and grinding which suggests a failing fan bearing.
Old Supply = S1202002 old fan worn out bearing to be refurbished.
New Supply = S1201919 new fan with ball bearing.
F. Clara
M. Pirello
J. Kissel, O. Patane, F. Clara ECR E2400330 Calling this out explicitly: We have changed the OSEM PD satellite amplifiers on H1SUSPRM, H1SUSPR3, H1SUSBS, H1SUSSR3, and H1SUSSRM top masses; see LHO:85463 We chose to implement ECR E2400330 by modifying spare chassis ahead of time, and installing those modified spares in place of the old chassis (which will become some other suspensions' "new" amps next week). Though the ECR only changes the whitening stage frequency response. However, because the old vs. new chasses have different set of other overall transimpedance gain determining components, the read-back for the OSEM PDs will likely change slightly. Thus, the OSEMs' recast as EULER basis signals will also change slightly, *looking* like an alignment change, even though the alignment of the physical suspension will NOT have changed. This won't be in any consistent direction, and the transimpedance gain is determined by components that have value at any value within the components' tolerance. I attach two examples, H1SUSPR3 and H1SUSBS, of the levels we're talking about -- In the OSEM basis, it's 1-3 [urad], and same in the EULER basis. For the beam splitter, a physical change in alignment of that magnitude would be significant, hence me bringing it up explicitly. So, the new normal for the following suspension alignment starts on 2025-07-01 12:30 UTC: H1SUSPRM H1SUSPR3 H1SUSBS H1SUSSR3 H1SUSSRM We'll definitely have to re-run initial alignment after today's maintenance day, given that (unrelated) - we rebooted the entire electronics racks at EY to replace failing power supplies, - we rebooted the seih23 - we adjusted the green camera alignment
We noticed a failed drive on h1daqfw1. As we were in maintenance we powered down the system and removed the disk. This was a 1TB spinning disk. It was most likely put in to allow us to have large storage if we needed to write frames locally and then move then over the network, this was a very real posibility at point. However we never ended up doing that.
The system was taken down at around 13:38 local time.
F. Clara, E. Capote
Per WP#12646, Fil and I went out to the floor and realigned the ITMX green camera, as Sheila noted it was poorly aligned in alog 84819. (Before we began, Corey transitioned the LVEA to laser hazard per WP#12647).
Before going out to align, I locked the X arm in green only using the camera offsets for the alignment. I offloaded this X arm alignment, so it could be preserved once we moved the camera.
With the X arm still locked, Fil and I connected a computer to the green camera output, which gave us a faster, live view of the camera as we adjusted it. Fil used a Rainbow controller to zoom out very far to reduce our chances of moving the beam too much and losing it. Fil then removed the camera housing cover, and adjusted the nobs on the camera. As he adjusted in the desired direction, I zoomed the camera in slowly, to ensure that we were moving the beam closer to center. We iterated this process several times. The first time Fil went to put the camera cover back on, we noticed that the action of placing the cover bumped the aligment a little bit, so we had to overcorrect in the opposite direction slightly so that the beam stayed centered as Fil replaced the cover. I then tried adjusted the zoom and lens slightly, and decided that the image was well-centered enough to finish the work.
Once we were back in the control room, I updated the camera offsets. I have attached the SDF of these new offsets.
We took open loop transfer functions for some suspensions today. Some were taken so we have 'before' OLG and loop suppression data before we switch out their satamps (ITMX, ITMY), and the rest were after the satamps were switched out (85463) so that we could confirm that they all looked good (PRM, PR3, SRM, SR3).
0.4:10 (old) satamp OLG TFs
ITMX M0
- Measurements taken with suspension in HEALTH_CHECK but with damping loops on
- optic align offsets off, L2->R0 damping off, etc
- We needed to adjust the excitation filters for V and Y, plus lower the amplitude by a factor of at least 5x to keep the suspension dac from overflowing and saturating. These excitation filters were originally matches to the ETM ones, but we had to adjust them.
Data: 2025-07-01_1645_H1SUSITMX_M0_WhiteNoise_{L,T,V,R,P,Y}_0p01to50Hz_OpenLoopGainTF.xml r12366
ITMY M0
- Measurements taken with suspension in HEALTH_CHECK but with damping loops on
- optic align offsets off, L2->R0 damping off, etc
- We needed to adjust the excitation filters for V and Y, plus lower the amplitude by a factor of at least 5x to keep the suspension dac from overflowing and saturating. These excitation filters were originally matches to the ETM ones, but we had to adjust them.
- When trying take Y, there was noise affecting mainly F1/F2/F3 (ndscope1, ndscope2) that was happening every ~4mins. Every time it happened it would cause overflows as well. This made it really hard to get a Y measurement, so the Y here looks pretty bad. We can try another time to get the data for Y. We don't know why this was happening but it stopped once we left HEALTH_CHECK (but it didn't start when we first entered HEALTH_CHECK)
Data: 2025-07-01_1700_H1SUSITMY_M0_WhiteNoise_{L,T,V,R,P,Y}_0p01to50Hz_OpenLoopGainTF.xml r12369
0.1:5 (new) satamp OLG TFs
Note: for all of the following measurements, the OSEMINF FM1 filter had been updated from 10.4:0.38 to 5.31:0.0969 to match the new 0.0969:5.31 satamp (85471)
PRM M1
- Measurements taken with suspension in HEALTH_CHECK but with damping loops on
- optic align offsets off, etc
- We needed to increase the exc gain to match the decrease in damping loop gain (-0.5)
Data: 2025-07-01_1815_H1SUSPRM_M1_CDBIOState_1_WhiteNoise_{L,T,V,R,P,Y}_0p01to100Hz_OpenLoopGainTF.xml r12368
PR3 M1
- Measurements taken with suspension in HEALTH_CHECK but with damping loops on
- optic align offsets off, etc
- We found that some dofs were being very underdriven, so we upped the gain by 10 or 100x
Data: 2025-07-01_1820_H1SUSPR3_M1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz_OpenLoopGainTF.xml r12367
SRM M1
- Measurements taken with suspension in HEALTH_CHECK but with damping loops on AND optic align offsets ON
- We needed to increase the exc gain to match the decrease in damping loop gain (-0.5)
Data: 2025-07-01_1900_H1SUSSRM_M1_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz_OpenLoopGainTF.xml r12372
SR3 M1
- Measurements taken with suspension in HEALTH_CHECK but with damping loops on
- optic align offsets off, etc
- We found that some dofs were being very underdriven, so we upped the gain by 10 or 100x
Data: 2025-07-01_1830_H1SUSSR3_M1_WhiteNoise_Y_0p02to50Hz_OpenLoopGainTF.xml r12371
Main takeaways:
- ITMY Y was bad due to some strange mystery noise and needs to be retaken
- PRM, PR3, SRM, SR3 all had new satamps and updated OSEMINF FM1 filters to match
- SRM measurements were taken with optic align offsets ON
To finish off Fil's work for ECR E2400330 replacing the M1 satamps for BS, PRM, PR3, SRM, and SR3, I replaced FM1 in their OSEMINF filter banks from being z:p = 10:0.4 to z:p = 5.31:0.0969 to properly compensate for the new satamp. I've attached the filter file diffs for each suspension. They've all been loaded in.
Ivey and Edgard,
We just finshed a fit of the Yaw-to-Yaw transfer functions for the OSEM estimator using the measurements that Oli took for SR3 last Tuesday [see LHO: 85288].
The fits were added to the Sus SVN and live inside '~/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/fits_H1SR3_2025-06-30.mat' . They are already calibrated to work on the filter banks for the estimator and can be installed using 'make_SR3_yaw_model.m', which lives in the same folder [for reference, see LHO: 84041, where Oli got the fits running for a test].
Attached below are two pictures of the fits we made for the estimator.
The first attachment shows the Suspoint Y to M1 DAMP Y fit. We made sure to fit the asymptotic behavior as well as we could, which ends up being 0.95x10^{-3} um/nm (5% lower than expected from the OSEM calibration). The zpk for this fit is
'zpk([-0.024+20.407i,-0.024-20.407i,-0.044+11.493i,-0.044-11.493i,0,0],[-0.067+21.278i,-0.067-21.278i,-0.095+14.443i,-0.095-14.443i,-0.07+6.405i,-0.07-6.405i],-0.001)'
The second attachment shows the M1 drive Y to M1 DAMP Y fit. We kept the same poles that we had for the other fit, but manually fit the zeros and gain to make a good match. The zpk for this fit is
'zpk([-0.051+8.326i,-0.051-8.326i,-0.011+19.259i,-0.011-19.259i],[-0.067+21.278i,-0.067-21.278i,-0.095+14.443i,-0.095-14.443i,-0.07+6.405i,-0.07-6.405i],12.096)'
Hopefully Oli and co. will have time to test this soon!
The new filters have been loaded in. Here are the matlab plots for the fits for SUSPOINT_Y_2GAP and for EST_MODL_DRV_Y_2GAP.