ALS-Y is not locking, the dither align scripts did not help. Trending OSEMs for the PRC and SRC and BS and TESTs masses did not help either, things are in the same spot or adjusting did nothing,

J. Oberling, O. Patane

Today we started to re-center the SR3 optical lever after SR3 alignment was reverted to its pre-April alignment.  That's not quite how it went down, however...

We started by hooking up the motor driver and moving the QPD around (via the crossed translation stages it is attached to), and could not see any improvement to the OpLev signal.  While moving the horizontal translation stage it suddenly stopped and started making a loud grinding noise, like it had hit its, or a, limit.  Not liking the sound of that, we launched on figuring out fall protection to climb on top of HAM4 to investigate.  While the fall protection was getting figured out we took a look at the laser and found it dead.  No light, no life, all dead.  So we grabbed a spare laser from the Optics Lab and installed it (did not turn it on yet).

Once the fall protection was figured out I climbed on top of HAM4 and opened the OpLev receiver.  I couldn't visually see anything wrong with the stage.  It was near the center of its travel range, and nothing else looked like it was hung up.  I removed the QPD plate and the vertically mounted translation stage to get a better view of the stuck stage, and could still see nothing wrong.  Oli tried moving the stage with the driver and it was still making the loud noise, and the stage was not moving.  So it was well and truly stuck.  We grabbed one of the two spare translation stages from the EE shop (where Fernando was testing the remote OpLev recentering setup), tested it to make sure it worked (it did!), and installed it in the SR3 OpLev receiver.  The whole receiver was reassembled and the laser was turned on.  Oli slowly turned up the laser power while I watched for the beam, and once it was bright enough Oli then moved the translation stages to roughly center it on the QPD.

Something interesting, as Oli was turning up the laser power it would occasionally flash bright and then return to the brightness it was at before the flash.  They got it bright enough to see a SUM count of ~3k, and then re-centered the OpLev.  At this point I closed up the receiver and came down from the chamber.  I turned the laser power up to return the SUM counts to the ~20k it was at before the SR3 alignment shift and saw the SUM counts jump just like the beam would flash.  This happened early in the power adjustment (for example: started at ~3k SUM, adjusted up and saw a flash to ~15k, then back down to ~6k) but leveled off once the power was higher (I saw no jumps once the SUM counts were above 15k or so).  Maybe some oddness with a low injection current for the laser diode?  Not sure.  The OpLev is currently reading ~20k SUM counts and looks OK, but we'll keep an eye out to see if it remains stable starts behaving oddly.

The SR3 optical lever is now fixed and working again.

New laser SN is 197-3, old laser SN is 104-1.  SN of the new translation stage is 10371

During today's maint. period I updated the calibration on CAL-CS and restarted the GDS pipeline. The kappas will be reset to 1.

The biggest reason for this update is to account for uncompensated delays left over from the DAC swap (& others that have been in place but that we just never accounted for).

new pydarm H1 ini file
latest pydarm report

Vicky and Naoki aligned the pump ISS AOM 2 weeks ago: 79993, since then it has been steadily drifting (screenshot), such that it looks like it will rail in the next day or so. I went to the table to see if I could adjust the alignment.

start: 52 mW incident on AOM, set drive to 0V, measure 41mW in 0th order beam (78%).  set drive to 5V, 12mW in 1st order beam (23%) and 28mW in 0th order beam.

I tried several rounds of translating and yawing or pitching the AOM, alternating between 0V and 5V drive.  At one point I misaligned the SHG steering mirror with a pico because I was using too long a wrench, so tweaked that up to bring the SHG output back to 75mW, then brought some knobs to continue AOM alignment.  I was able to get 100% throughput or close with 0V drive a few times, but when I looked at where the beams were on the apertures they were obviously off center in yaw for these good throughputs.  When the beams looked more centered on the apertures the throughputs were more like 80%.  I also several times aligned to increase the diffracted power but caused the beam shape to look obviously clipped on the card.

In the end I SAW 15 mW in the diffracted beam with a round beam quality and looking roughly centered on the apertures.  I decided to quit here, and then realized that the input power had increased so that this is only mediocre AOM alignment, similar efficiency to how it started the day.   31.7 mW 0th order, 15.2mW in 1st order with 5V drive (24%), beam quality looks round, 0V drive, 47.2 mW in oth order beam, 63mW input power (75%).  

With the OPO in down, I realinged the pump fiber looking at OPO REFL, and also adjusted the wave plate for the SHG rejected path to minimize the rejected power.  After these, the ISS locked at the nominal set point of 80uW transmitted through the OPO with 3V drive signal, since I've closed up the table this is drifting up, to now 5.4V. 

So the ISS should be in better shape that it was before I started, although the AOM alignment is not improved, the fiber alignment, half wave plate adjustment, and drifts are helping. I think it would make sense to take a beam profiler out to the table and measure the beam size at the AOM, there should be space for a couple of measurements.  On a card the beam looks like it is as large as the apertures. 

Per WP12103

Continuing our work the last few weeks on the LD32 DAC at ETMX here and here, we cleaned up the cabling, added labels to the unlabeled cables, and securely mounted the 2nd PI AI Chassis to the rack.

F. Mera, M. Pirello

Both fire pumps were run for ten minutes this morning between 8:30 and 9:00 AM.

We are holding off on the reboot of the digital video camera servers until Keita is finished with his ALS-EY work. The h1alsey model receives camera data via the CDS_CA_COPY guardian node.

For completeness, here is a list of all the models which depend on the digital video servers for camera data:

Tue Sep 24 08:13:14 2024 INFO: Fill completed in 13min 10secs

Jordan confirmed a good fill curbside.

WP12094

Eric, Dave

Bypass will expire:
Tue Sep 24 10:47:22 AM PDT 2024
For channel(s):
    H0:FMC-CS_FIRE_PUMP_1
    H0:FMC-CS_FIRE_PUMP_2
 

FAMIS Link:  26010

Only CPS channels which look higher at high frequencies (see attached) would be:

1. ITMx St1 V1
2. ITMy St1 V2
3. ETMy St1 H2

TITLE: 09/24 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 4mph Gusts, 2mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.20 μm/s
QUICK SUMMARY:

• We dropped observing at 14:22 UTC for the PEM magnetic injections, the SUS charge will soon follow
• We've been locked for 16:20
• 12 DC chans on the EDC from NUC33

TITLE: 09/24 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 147Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY: H1 remained locked the whole shift with one candidate event. Took some time to try and improve SQZ alignment, although it didn't seem to initially help improve range.

• 23:00 - H1 observing for 45 minutes
• 00:03 - S240924a
• 01:58 - Dropped observing to adjust SQZ alignment - alog80257
• 02:08 - Resumed observing

H1 has been locked for almost 7 hours.

I took H1 out of observing from 01:58 to 02:08 UTC  (3:50 into lock stretch, soon after L1 lost lock) to touch up SQZ alignment since high frequency noise didn't look great. I used the SCAN_ALIGNMENT_FDS and SCAN_SQZANG_FDS states in the SQZ_MANAGER Guardian to do this, and it looks like high frequency noise has improved, but I can't say the same for range (see attached trend of DARM BLRMS above 500Hz and range).

It seems that running these SQZ alignment optimization states somehow made range worse?

EDIT: attaching SQZ BLRMS comparison before/after alignment

TITLE: 09/23 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: Commissioning tasks completed: A2Ls gains, HAM1 PEM shaking tests, phasing POP9. We've been locked for a little over an hour, conditions are calm.
LOG:                                                                                                                                                                                                                                                                                                                                                                                        

• 15:45 UTC lockloss from a HAM1 hepi trip
  • 16:41 UTC back to NLN and commissioning
  • 18:39 UTC Observing
  • 20:19 UTC EQ mode from a 6.0 from Indonesia
• 21:17 UTC lockloss
  • 22:12 UTC observing

TITLE: 09/23 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 13mph Gusts, 8mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.14 μm/s
QUICK SUMMARY: H1 has been locked for about an hour.

• Wind slightly elevated, other ground motion low
• All other systems nominal

This morning we changed the demod phase of the POP 9 sensor.  The overall summary is that this has a very similar impact to adding a PRCL offset, reducing the PRCL to REFL RIN coupling, and slightly increaing power in the PRC, but not changing the coupling of PRCL noise to DARM.  I've turned off the offset, added a new phasing, and updated the PRCL to SRCL subtraction in the LSC input matrix.

More details:

I used a 702.1 Hz frequency noise injection, (template found in userapps/lsc/h1/templates/phase_LSC_sensors_frequency_exc.xml)  and adjusted the POP9 phase to reduce the appearance of the frequency injection in Q (screenshot shows initial to final settings change in Q peak).  I used Elenna's template to make a PRCL injection and measure the coupling to RELF RIN and DARM during this move, see screenshot.  Adjusting the phase reduced the PRCL to REFL RIN coupling in a way that's similar to what Elenna has seen by adjusting the PRCL offset (see 79989 for example). Also similar to what Elenna has seen with the PRCL offset, this has very little impact on the PRCL to DARM coupling.  The ndscope screenshot shows how this impacted REFL and POP powers, you can compare the time when I turned off the offset to the time when I tried reverting the phase to the original setting after finding the new setting, the two things have a simlar impact on the reflected power and the power in the PRC. 

One interesting observation is that the phase that minimized the PRCL to REFL RIN coupling (as shown by the sign flip in the transfer function), is different from the phase that minimzed the frequency injection coupling to POP 9Q, by 2 degrees.  I've left this at the phase that minimizes REFL RIN coupling.  The impact on the power build ups is small enough that this two degree difference can't be evaluated using them. 

Another observation is that the change in phasing doesn't seem to have an impact on the PRCL spectrum, spectrum screenshot. 

Lastly, I did another PRCL excitation to measure the coupling to POP 45 and POP9 I, using the template in userapps/lsc/h1/templates/SRCL/SRCL/SRCL_input_matrix_git_rid_of_PRCL.xml  (excuse the typo).  I used this measurment to try to zero the PRCL coupling to SRCL ((POP45/PRCL)*MTRX_5_3 + (POP9I/PRCL)*MTRX_5_1 = 0, and found that this matrix element needed to be updated from 0.1185 to 0.1408.  This was last updated by Jenne Driggers in 70919.  The update reduced the SRCL to PRCL coupling by about 20dB, shown here. 

Lastly we edited the guardian to not use the PRCL offset, and update the PRCL to SRCL input matrix element, and accepted the new matrix and phasing in SDF (in the observe file, and now also in the safe file).