Adjusted the SQZ FSS beat note by moving the waveplates. The RF demod siganl went from -3.2dBm to +6.5dBm.
J. Kissel
Continuing on the campaign of gathering open loop gain (and loop suppression & closed loop gain TFs), I measured H1SUSPR2's M1 damping loops this morning -- see
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PR2/SAGM1/Data/
2025-07-08_1748_H1SUSPR2_M1_WhiteNoise_L_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1748_H1SUSPR2_M1_WhiteNoise_P_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1748_H1SUSPR2_M1_WhiteNoise_R_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1748_H1SUSPR2_M1_WhiteNoise_T_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1748_H1SUSPR2_M1_WhiteNoise_V_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1748_H1SUSPR2_M1_WhiteNoise_Y_0p02to100Hz_OpenLoopGainTF.xml
SUS was in new HEALTH_CHECK state, but damping loops are *on.*
SEI / HPI / ISI was FULLY_ISOLATED, in its best performing state.
Data analysis and commentary to come.
Tue Jul 08 10:07:26 2025 INFO: Fill completed in 7min 22secs
J. Kissel
Continuing on the campaign of gathering open loop gain (and loop suppression & closed loop gain TFs), I measured the IMC suspension's MC1, MC2, and MC3 M1 damping loops this morning -- see
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/
MC1/SAGM1/Data/
2025-07-08_1636_H1SUSMC1_M1_WhiteNoise_L_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1636_H1SUSMC1_M1_WhiteNoise_P_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1636_H1SUSMC1_M1_WhiteNoise_R_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1636_H1SUSMC1_M1_WhiteNoise_T_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1636_H1SUSMC1_M1_WhiteNoise_V_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1636_H1SUSMC1_M1_WhiteNoise_Y_0p02to100Hz_OpenLoopGainTF.xml
MC2/SAGM1/Data/
2025-07-08_1615_H1SUSMC2_M1_WhiteNoise_L_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1615_H1SUSMC2_M1_WhiteNoise_P_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1615_H1SUSMC2_M1_WhiteNoise_R_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1615_H1SUSMC2_M1_WhiteNoise_T_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1615_H1SUSMC2_M1_WhiteNoise_V_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1615_H1SUSMC2_M1_WhiteNoise_Y_0p02to100Hz_OpenLoopGainTF.xml
MC3/SAGM1/Data/
2025-07-08_1703_H1SUSMC3_M1_WhiteNoise_L_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1703_H1SUSMC3_M1_WhiteNoise_P_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1703_H1SUSMC3_M1_WhiteNoise_R_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1703_H1SUSMC3_M1_WhiteNoise_T_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1703_H1SUSMC3_M1_WhiteNoise_V_0p02to100Hz_OpenLoopGainTF.xml
2025-07-08_1703_H1SUSMC3_M1_WhiteNoise_Y_0p02to100Hz_OpenLoopGainTF.xml
The IMC was brought to OFFLINE beforehand, and I unmanaged the SUS_MC2 guardian to be sure the IMC guardian wouldn't override my wishes.
Each SUS was then brought to the new HEALTH_CHECK state but damping loops are *on.*
SEI / HPI / ISI was FULLY_ISOLATED, in its best performing state.
Data analysis and commentary to come.
FAMIS Link: 26051
Only CPS channels which look (a little) higher at high frequencies (see attached) would be the following:
J. Kissel
Continuing on the campaign of gathering open loop gain (and loop suppression & closed loop gain TFs), I measured H1SUSETMX's reaction chain R0 damping loops this morning -- see
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGR0/Data/
2025-07-08_1630_H1SUSETMX_R0_WhiteNoise_L_0p02to50Hz_OpenLoopGainTF.xml
2025-07-08_1630_H1SUSETMX_R0_WhiteNoise_P_0p02to50Hz_OpenLoopGainTF.xml
2025-07-08_1630_H1SUSETMX_R0_WhiteNoise_R_0p02to50Hz_OpenLoopGainTF.xml
2025-07-08_1630_H1SUSETMX_R0_WhiteNoise_T_0p02to50Hz_OpenLoopGainTF.xml
2025-07-08_1630_H1SUSETMX_R0_WhiteNoise_V_0p02to50Hz_OpenLoopGainTF.xml
2025-07-08_1630_H1SUSETMX_R0_WhiteNoise_Y_0p02to50Hz_OpenLoopGainTF.xml
SUS was in new HEALTH_CHECK state, so R0 tracking is OFF and alignment offsets are OFF, but damping loops are *on.*
SEI / HPI / ISI was FULLY_ISOLATED, in its best performing state.
Data analysis and commentary to come.
Last week I measured the AS RF72 WFS with and without whitening while the IMC was offline. The first attached plot compares the reference traces with the nominal one stage of whitening, and the live traces with no whitening. Based on that result, I determined that we probably should apply another stage of whitening to AS A RF72. Today I applied the second stage of whitening and saw that it makes a small improvement in the dark noise, again taken with the IMC offline. The second attached plot compares the reference traces with one stage of whitening and the live traces with two stages of whitening.
While changing the whitening, I noticed that the overall offsets of each segment change, each one by a different amount. I averaged the input signals over 30 seconds and used those values to update the dark offsets. Some segments are about the same, while others have changed. This SDF screenshot compares the old and new dark offsets for each segment. I also SDFed the second stage of whitening and anti-whitening compensation for all segments.
I also increased the whitening gain of AS A RF72 by 6 dB (from 12 to 18 dB). I compensated that gain change in the anti-whitening filter bank FM6 with a -6 dB gain filter. I'm less certain of the overall effect this will have, but I hope it will help amplify the signal further relative to any ADC noise (see my alog here for reference). We use very little range on these PDs in full lock and during acquisition, so I don't think this will impact locking.
I reran the dark offsets after this change, and have SDFed them below. These diffs appear in both the ASC and CS ISC models. There will be observing diffs that should be accepted!
We decided to quickly take OLTFs for the ITM R0 stages since we didn't have any yet.
Note: These measurements were taken with the 0.4:10 (old) satamp
ITMY R0
- Measurements taken with suspension in HEALTH_CHECK but with damping loops on
- optic align offsets off, L2->R0 damping off, etc
- We needed to lower the excitation amplitude for V (10 -> 2.5) and Y(300 -> 10) to keep the suspension dac from overflowing and saturating. In the case of V, we could get full measurements with the excitation amplitude at 5, but the coherence was poor, so I lowered the amplitude to 2.5 and that worked to make sure the osems weren't being overdriven. These excitation filters were originally matches to the ETM R0 ones, but we had to adjust them.
Data: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/SAGR0/Data/2025-07-08_1510_H1SUSITMY_R0_WhiteNoise_{L,T,V,R,P,Y}_0p02to50Hz_OpenLoopGainTF.xml r12395
J. Kissel
Continuing on the campaign of gathering open loop gain (and loop suppression & closed loop gain TFs), I measured H1SUSITMX's reaction chain R0 damping loops this morning -- see
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMX/SAGR0/Data/
2025-07-08_1530_H1SUSITMX_R0_WhiteNoise_L_0p02to50Hz_OpenLoopGainTF.xml
2025-07-08_1530_H1SUSITMX_R0_WhiteNoise_P_0p02to50Hz_OpenLoopGainTF.xml
2025-07-08_1530_H1SUSITMX_R0_WhiteNoise_R_0p02to50Hz_OpenLoopGainTF.xml
2025-07-08_1530_H1SUSITMX_R0_WhiteNoise_T_0p02to50Hz_OpenLoopGainTF.xml
2025-07-08_1530_H1SUSITMX_R0_WhiteNoise_V_0p02to50Hz_OpenLoopGainTF.xml
2025-07-08_1530_H1SUSITMX_R0_WhiteNoise_Y_0p02to50Hz_OpenLoopGainTF.xml
SUS was in new HEALTH_CHECK state, so R0 tracking is OFF and alignment offsets are OFF, but damping loops are *on.*
SEI / HPI / ISI was FULLY_ISOLATED, in its best performing state.
Data analysis and commentary to come.
J. Kissel
Continuing on the campaign of gathering open loop gain (and loop suppression & closed loop gain TFs), I measured that for H1SUSTMSX M1 damping loops this morning -- see
/ligo/svncommon/SusSVN/sus/trunk/TMTS/H1/TMSX/SAGM1/Data/
2025-07-08_1525_H1SUSTMSX_M1_WhiteNoise_L_0p02to50Hz_OpenLoopGainTF.xml
2025-07-08_1525_H1SUSTMSX_M1_WhiteNoise_P_0p02to50Hz_OpenLoopGainTF.xml
2025-07-08_1525_H1SUSTMSX_M1_WhiteNoise_R_0p02to50Hz_OpenLoopGainTF.xml
2025-07-08_1525_H1SUSTMSX_M1_WhiteNoise_T_0p02to50Hz_OpenLoopGainTF.xml
2025-07-08_1525_H1SUSTMSX_M1_WhiteNoise_V_0p02to50Hz_OpenLoopGainTF.xml
2025-07-08_1525_H1SUSTMSX_M1_WhiteNoise_Y_0p02to50Hz_OpenLoopGainTF.xml
SUS was in HEALTH_CHECK state, with alignment offsets and it's companion QUAD's L2/TMS tracking off, but damping loops turned back ON.
Data analysis and commentary to come.
TITLE: 07/08 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 9mph Gusts, 6mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.05 μm/s
QUICK SUMMARY:
Currently we are in an initial alignment. I'll let that finish and then put the detector in idle
It was only doing input align so I just took the detector to IDLE once that offloaded
Workstations were updated and rebooted. This was an OS packages update. Conda packages were not updated.
Got a notification for H1 assistance. H1 dropped from observing just under 3.5hrs ago. After a couple of PRMI cycles, DRMI did lock within 40min, but immediately lost lock at DRMI LOCKED CHECK ASC. Then an Initial Alignment was immediately run in just under an hour @1024UTC. At this point, H1 attempted lock but had another lockloss at DRMI LOCKED CHECK ASC again, but after this lockloss H1 made it up to CARM 5PicoMeters for the next lockloss. Next attempt made it to a CARM OFFSET Reduction Lockloss. Then after no luck locking PRMI and it being over 3hrs, I got the wake up call.
It's sounding like H1 has been having this Locking ailment as of late.
Going to let it finish a 2nd IA I started at @1253UTC after seeing that PRMI looked fine (flashes looked good on camera and are over 100 counts for POP18/90). Initial Alignment just completed and locking clock is restarting.
(Which is good, because my NoMachine is having the symptom that the mouse pointer does not match it's location in my No Machine session intermittantly (basically I'll have the mouse pointer over a spot, i.e. "X" to close an MEDM window, but when I try to click the "X" with the pointer, the pointer is actually, in the No Machine session, about 10" to the left (or right---basically somewhere else!), so it's hard to operate in my NoMachine session. The mouse would be fine on my laptop's monitor. I've had this issue off and on for a few months. With that said, ....after about 15min, my mouse now works OK in NoMachine!)
H1 is now back to DRMI (after the recent Alignment). Camera flashes look centered and POP18/90 flashes are just under 200. Leaving H1 for automatic operations while I see if I can get return to sleep. At 1325UTC/625amPDT, DRMI locked, btw.
It looks like before Corey was called, there were some locking attempts that got up past DRMI. Before he was called, there were two locklosses from DRMI_LOCKED_CHECK_ASC (which we have figured out was due to some SRC1 offsets being turned on by accident), then one lockloss from CARM_5_PICOMETERS, then two lockloss from CARM_OFFSET_REDUCTION. So that makes a lot more sense as to why it didn't call for three hours!
TITLE: 07/08 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Very quiet shift with H1 observing after getting relocked. I was originally going to drop observing at some point to try SQZ alignment and angle scans to bring the BNS range up, but since the range has actually been improving over the course of this lock stretch and all four detectors are up and observing, I opted not to and we will see how things change overnight. H1 has now been locked and observing for 4.5 hours.
FAMIS 31093
Not much to report this week other than the FSS TPD has drifted down again slightly.
Today we've had to run many initial alignments and mess around with mirror alignments to cajol DRMI into locking. In the first part of the day, we were coming back from a big earthquake which had kept us down for hours. I don't know what we can attribute the struggle to lock to, but it can't be related to the BS heating since we had been down for many hours.
Later in the day, we were relocking after a few hours up, and just after the lockloss we proceeded to DRMI locking. The alignment was very poor. The guardian quickly took us to PRMI and then MICH FRINGES because of the very bad alignment. This is perhaps a sign that the BS slow release method isn't working so well, since it should keep the alignment decent just after lockloss. I cleared the history on the BS M1 pitch lock bank, and proceeded to help the MICH FRINGES and PRMI state by hand. Once we got back to DRMI we were able to lock relatively quickly.
I am suggesting that our DRMI locking problems are "maybe not an alignment issue" because this morning after several alignments, DRMI took a very long time to lock, and just after lockloss in the afternoon, where the slow release method should help keep the alignment good, the alignment was very bad. Maybe we should look into the triggers or engagement of the locking to see if there is a problem there. Just based on my experience this afternoon, I would want to turn off the BS slow release, or recheck that it is doing what we want it to do.
TITLE: 07/07 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 12mph Gusts, 4mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.06 μm/s
QUICK SUMMARY: H1 just lost lock after a couple hours of being locked, so starting relocking now.
Lockloss @ 23:14 UTC after almost 2.5 hrs locked - link to lockloss tool
No obvious cause.
H1 back to observing at 00:46 UTC. Automatic relock except for a small adjustment to FC2 pitch was needed to lock the filter cavity.
I also ran a 'SCAN_SQZANG_FDS' once at low noise to improve the SQZ angle, which helped bring the BNS range up to about 142Mpc, but not quite back to the 150Mpc we were hoping for. Perhaps a SQZ alignment scan would've helped too, but I did not take the time to do that here.
Thought I had posted this before, but couldn't find it, so here it is. Attached plots compare L2L measurements of the HAM1 GS13s on May 21 during corner pumpdown before adding the periscope viton and June 6 the afternoon after we added viton. The Q and frequency of the 71.8hz mode is somewhat reduced, but the neighboring 69.9hz mode is sharper now, so I'm not sure we gained much. The June 6 measurement was collected in air, so I would still like to collect a set of in-vac measurements. This could probably be done on a Tuesday if there isn't too much activity around HAM1.
I took 5-200hz matlab tfs this morning to compare to the 2 previous measurements above. It seems that the damping is quite effective now. I will try to look at the effect on the isolation filter design, maybe we can get some of the loop gain back. It would still be better to move these modes up above 100hz if possible.
