Lockloss due to ETM Glitch. H1 Lockloss Tool.

As I was writing this, we lost lock at LOWNOISE_ASC, same as yesterday. There also happened to be a 5.5 EQ passing through (same as yesterday with a more local 3.0 one)

Jennie W, Rahul, Keita

This is just a summary of our work over the last two days trying to repeat the alignment coupling measurements for the replacement ISS array unit (D1101059, unit S1202965). The reason we need to repeat these is because we have now uograded the washer and clamp plate in QPD assembly. See Keita's previous alog for details.

Thursday

First we changed input alignment to get roughly 4 V on each PD in the array, this is acheived by inserting the larger iris and using the two steering mirrors (M2 closest to the array, M1 further towards the laser) to change the input alignment of the auxiliary laser into the unit.

As we have tilted the QPD by adding the new components we need to re-align the QPD to centre the beam (which is split off from the main beam entering the unit by the beam splitter on the elevator assembly which sits at one corner of the ISS array unit).

Then we unscrewed the four screws holding the QPD down (see image) and tried to move the QPD to minimise the coupling from yaw motion if the input beam to pitch. We only managed to minimise pitch coupling and couldn't get it centred on qpd in yaw as the whole QPD unit moves a lot when not screwed down.

We screwed down the QPD but it was still off in yaw by a lot (see image).

As we were adjusting the input alignment mirror to check the coupling I managed to lost the input alignment to the array.

Friday

Today Keita brought the input alignment back by using the beam viewer to check the position on the diodes while changing M2. Then we saw about 3.5-4V on each of the PDs in the array. Next we only undid the two lower screws on the QPD (these hold the QPD unit itself clamped to the platform it sits on, the two upper screws hold in the connector to the back of the QPD and these were only slighly loosened). Keita moved around the unit till the QPD readout showed we were near centred and then we screwed down the unit. It moves alignment while being screwed down probably because of the angle of the QPD relative to the clamp.

For this alignment we used the QPD amplifier unit that gives a live visual readout of the centering.

We also have the option of using another amplifier that gives the QPD X, Y and SUM channels so we can read them on an oscilloscope but these had some weird saw tooth noise on them (see image from Thursday). Keita then discovered that we were using the wrong cable (too low a current rating) for this amplifier, we searched for the correct one but could not find it. We will get back to this on Monday.

Summary: We think we now have the QPD in a good place relative to the PD array as yaw and pitch are fairly decoupled, but maybe the angle of the QPD in rotation is still slightly off as the P and Y motion of the beam are still slightly off from the QPD quadrants. We need a new cable for the ON-TRAK amplifier.

M. Todd, S. Dwyer

This morning we made a change to the thermalization guardian (managed by ISC) with flags that allow the SQZ guardian to turn on the SQZ_ASC in the unthermalized state or this guardian can turn on SQZ_ASC after 75 minutes (thermalized-ish). We also turned the monitoring off so that this switch does not knock out observing.

For more info see:

TITLE: 06/27 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 147Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: We've been locked for just under 5 hours, calm day.
LOG:

• The LOCKLOSS_SHUTTER_CHECK failed at 09:05 UTC, I've added a check in H1_MANAGER to specifically look for the SHUTTER_FAIL state.
• 17:02 UTC lockloss
  • 18:25 UTC I adjusted the OPO temperature while relocking
  • The FC struggled to lock IR and we ended up changing the threshold
  • 19:33 UTC Observing
    • 19:43 UTC We dropped observing for <1min as the SQZ ASC turned on and threw out an SDF diff which I unmonitored

TITLE: 06/27 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 147Mpc
OUTGOING OPERATOR: Ryan C
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 14mph Gusts, 9mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.05 μm/s
QUICK SUMMARY:

IFO is in NLN (since 18:36 UTC) and OBSERVING since 19:33 UTC (4.5 hr lock)

An hour was spent comissioning to fix SQZ ASC, which now runs deeper into thermalization after NLN.

Otherwise, just planning to continue observing as long as possible!

Closes FAMIS 26399. Last checked in alog 85208.

All fans nominal, comparable to last week and within threshold.

Closes FAMIS 26456. Last checked in alog 84705

Trends look normal. SEI BRS Maintenance work in Mid-May was part of vent work and is the only excursion from the threshold lines.

J. Kissel, F. Clara
ECR E2400330

Fil modified another UK SatAmp (D0900900 / D0901284) per ECR E2400330, which means "rev'ing" up the D0901284 circuit board inside from -v4 to -v5.

However, this one, S1000278, seems to have more variability in components that were not changed between channels -- namely if I 
    - fit the measured zero and pole frequency, and 
    - assume that a perfect, as drawn, value for the R181 = R182 resistors (as Fil confirms that these were +/-0.1% resistors)
the total capacitance seems to have a ~2% variability. 

Not unreasonable, given that typical off-the-shelf caps of value 10 [uF] have +/-10% variability, so with two of these caps parallel, you could expect the total capacitance to be between 18 and 22 [uF], or +/-10%.

As such, I propose we set a tolerance for these transfer functions to have the following values at the following "check" frequencies (i.e. logspace(log10(5),log10(50),3), which is a requestable frequency vector on an SR785 frequency response sweep, if fstart = 50, and fstop = 0.5, with N points = 3). These assume values assume 1% variation in transimpedance amp feedback resistor, and 2.5% variation in whitening cap.

    Freq    Mag (Upper Bound)    Mag (Lower Bound)    Phase (Upper Bound)   Phase (Lower Bound)  
    [Hz]    [V/V] or dB([V/V])  [V/V] or dB([V/V])          [deg]               [deg]

    0.5      5.4098 or 14.664       5.0554 or 14.075      -106.23             -106.5

    5.0     38.415  or 31.69       36.671  or 31.286      -135.09             -133.72

    50.     54.987  or 34.805      53.868  or 34.627      -174.2              -173.9

    Freq    Mag Tolerance              db(Mag Tolerance)          Phase Tolerance 
    [Hz]    [V/V] +/- [V/V]         dB([V/V]) +/- dB([V/V])     [deg]  +/-   [deg]

    0.5      5.2313 +/- 0.17847       14.372 +/- 0.29138      -106.36  +/-  0.12754

    5.0     37.547  +/- 0.86844       31.491 +/- 0.19861      -134.41  +/-  0.67952

    50.     54.428  +/- 0.55902       34.716 +/- 0.088757     -174.05  +/-  0.14395

That being said, we wouldn't replace the non-ECR components if the SatAmp didn't pass this test, we'll just use those under-performing SatAmps to be used on low priority stages, i.e. ones not used for damping loop control, i.e. not top mass stages. If many end up exceeding this thresholds, then we can start to prioritize which suspensions get the best.

Fri Jun 27 10:12:24 2025 INFO: Fill completed in 12min 21secs

The filter cavity was having a hard time locking, and it looks like the FC green trans power has been dropping slowly over the last 3 weeks, which seems to be caused by a drop in the SHG power from around 100-110 mW down to 77 mW . 

I adjusted the picos and the SHG temperature, and recovered the SHG power to 86 mW, so there is still a lot of missing power.  The filter cavity locked after this.

I've added a template for this adjustment to userapps/sqz/h1/Templates/ndscope/SHG_alignment_temp_adjust.yaml

Lockloss at 17:02 UTC in NLN while we were waiting for the FC to lock.

TITLE: 06/27 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 9mph Gusts, 4mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.05 μm/s
QUICK SUMMARY:

• We were stuck in PREP_FOR_LOCKING with ISC_LOCK stalled with IFO_NOTIFY and H1_MANAGER asking for help (10:22 UTC)
• As soon as I requested H1_MANAGER back to idle it released ISC_LOCK and we started to lock again
  • At first glance I'm not sure why it was stuck
  • The timer "to NLN with an initial alignment already having run" was why it was calling for help but it should have kept trying to lock itself?

WP12637 Install HWS Camera Controls

TJ, Camilla, Dave:

I made a slight change to my original Dec 2023 hws_camera_control.py code to use the python epics module to do the cagets directly, and to also use this to add caputs which will try, in a non-blocking way, to send the camera's status to a central EPICS IOC.

The central IOC code is hws_camera_status_ioc.py which runs on cdsioc1 under puppet control.

The camera control code runs every minute in an infinite loop. Each loop it checks the status of H1 using Guardian ISC_LOCK (greater or equal to 600 denotes H1 LOCK). If H1 is locked and the camera is on, it turns the camera off. If H1 is not locked and the camera is off, it turns the camera on.

A mini-overview of the 4 HWS cameras (ITMX, ITMY, ETMX, ETMY) is available on the CDS Overview screen. The block is divided into 4 segments, each camera is shown either in SKYBLUE (camera is enabled, images are being taken) or GREEN (camera is disabled, no noise being created).

Note that the color scheme relates to what is nominal for OBSERVE. Green indicates the cameras have power, but their frame acquisition has been disabled.

Clicking on the HWS block on the CDS Overview opens a detailed screen (see attachment). For each camera this shows if the camera is powered (ETMY is the only one powered down) and if the camera is enabled. The control code also reports its current time, its uptime, its start time and details of where and how it is running.

Second attachment shows the four tmux sessions running the control code, and the arguments used.

WP12623 h1asc add fast channels to DAQ

Elenna, Dave:

A new h1asc model was rev-locked and installed. Four new fast DQ channels were added to the DAQ (channel, rate):

> H1:ASC-DC6_P_IN1_DQ, 256
> H1:ASC-DC6_P_OUT_DQ, 512
> H1:ASC-DC6_Y_IN1_DQ, 256
> H1:ASC-DC6_Y_OUT_DQ, 512

DAQ restart needed.

WP12570 Restart Digivideo Cameras with latest pylon

Patrick, Jonathan, Dave:

Jonathan updated pylon on h1digivideo[4,5,6] and restarted all the camera servers on these machines. This should fix the bug of stuck open files accumulating when the camera connection is interrupted.

No DAQ restart needed.

Add PID SMOO channels to vacuum SDF

Dave:

Prior to today's h0vacly restart I added the missing CP PID-control SMOO channels to the vacuum SDF monitor.req and safe.snap files. SDF was restarted 08:29. No DAQ restart needed.

WP12577, 12608, 12615 Upgrade LY Vacuum Controls

Janos, Gerardo, Patrick, Jonathan, Erik, Dave:

Patrick installed a new h0vacly system this morning. Main items are:

• Renaming of FCES Ion pump channels
• Removal of old PT100 channels

Pleae see Patrick's alog for details.

A extended DAQ restart was required, renaming Ion Pump raw minute trend files for uninterrupted lookback and construcing new PT100 (HAM1) raw minute trends following the upgrade of h0vaclx last Tuesday (17th June 2025).

DAQ Restart

Jonathan, Erik, Patrick, Dave:

Immediately following the restart of h1asc at 11:52, the DAQ was restarted using the following procedure:

1. both trend writers were turned off, allowing raw minute trend file changes on a static system
2. ip_copy_scripts.bsh was ran on both TWs, for each Ion Pump channel which is being renamed, this copied the old file into the correct directory for the new file, preserving recent lookbacks.
3. Erik ran his script to merge the previous HAM1 PT100 data sets into the new channel name.
4. A new H0EPICS_VACLY.ini was generated
5. 0-leg was restarted, followed by a EDC restart on h1susauxb123
6. 1-leg was restarted, requiring a second restart of GDS1.

It was at this late point that I remembered that the temporary H1 version of PT100B is no longer needed, and indeed this channel has no data following the removal of the PT100B Volts channel from h0vacly. However since it is still in the EDC, we need to continue running the temporary IOC until the next DAQ restart. I've removed it from edcumaster.txt as a reminder.

GPS Leap Seconds Updates

Jonathan, Erik, Dave:

Erik's FAMIS task reminded us that the leapseonds files expiration date of 30 June 2025 is rapidly approaching. Although no leap seconds are to be applied, the files need to be updated to reset their expiration dates. Please see Erik and Jonathan's alog for more details.

DNS testing 

Erik:

ns1 (backup DNS server) was used by Erik to see if we can reproduce the error whereby loss of connection to GC caused internal CDS name resolution issues. It did not.