J. Warner, H. Radkins, J. Kissel, P. Thomas, M. Ross

We completed the BRS image analysis software updates that had previously been unsuccessful (50178). The new version writes values to TwinCAT at a slightly different rate which is compensated for by changing the pulse check number from 10 to 20 in the following line in the BRS TwinCAT:

IF H1_ISI_GND_BRS_ETMX_PULSECHECK>=10

The last time we attempted the upgrade, TwinCAT threw the an error saying that "ProjectDefaults.opt could not be loaded (Reason: Root element is missing)". We found that this file existed and decided to just move it to another location with the hope that TwinCAT would recreated a non-corrupted version. This appears to have worked and TwinCAT began functioning correctly.

With this fixed the rest of the process was fairly straight forward and we were able to get both BRSs upgraded. To ensure that the new code is functioning as well as the previous version, we compared the online tilt subtraction to an optimal subtraction calculated with mccs2 (shown in the attachments). Both BRSs look like they're functioning perfectly.

Note: this upgrade did not alter the previous versions so, if needed, switching back to the old version consists of just running a different software

We have moved our interferometer spot positions back to those we had before the change on the ~1st of August. See alog 51262 for a summary of why several indicators that the July spots were better for the IFO. 

We have done this by modifying the powerup A2L spot position gains in the lscparams guardian file, so that we will still acquire lock with the beams roughly centered on the optics, but once we start engaging the soft loops we change the A2L gains and go to the final 37W spots, then power up. 

Also, I have reverted the OMC ASC QPD setpoints back to their values from the July time, undoing alog 50973. Hopefully we will see a marked reduction in the number of low frequency glitches.  The OMC ASC setpoints were saved in both observe and safe snap files.

J. Warner, H. Radkins, J. Kissel, M. Ross

FRS Ticket: 13417

The End-X BRS still experienced glitches after the trouble shooting last week (51342) so we decided to disassemble the BRS autocollimator to remove all living or dead insects. After removing the insulation, camera, and light source, we unscrewed the top two thirds of autocollimator optics assembly from the bottom third and thoroughly inspected it for any stowaways. We did not find any insects other than the two dead ones on the lens at the bottom of the tube (pictured in the first and second attachments). We removed these, wiped clean the lens, and reassembled the autocollimator.

In an attempt to block any future thrill seeking bugs, we taped over any gap we found that led into the optics tube (shown in the third and fourth attachments). Once this was done we reinstalled the insulation and closed up the thermal box.

We have not seen any glitches since this work was complete but we will continue monitoring to ensure that the problem is exterminated.

Following up on Sheila's email, I have created new templates for looking into the spectrum of the OSEMs for the following suspensions: ETMX, ETMY, ITMX, ITMY, PRM, SRM. Given below are their location, along with their measurement channels.

ETMX

/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/Common/Data/2019-08-15_2102_H1SUSETMX_OSEM_ASD.xml

H1:SUS-ETMX_M0_OSEMINF_F1_OUT_DQ      H1:SUS-ETMX_M0_OSEMINF_F2_OUT_DQ       H1:SUS-ETMX_M0_OSEMINF_F3_OUT_DQ 

H1:SUS-ETMX_M0_OSEMINF_LF_OUT_DQ      H1:SUS-ETMX_M0_OSEMINF_RT_OUT_DQ        H1:SUS-ETMX_M0_OSEMINF_SD_OUT_DQ

H1:SUS-ETMX_M0_OSEMINF_SD_OUT_DQ     H1:SUS-ETMX_R0_OSEMINF_F1_OUT_DQ        H1:SUS-ETMX_R0_OSEMINF_F2_OUT_DQ

H1:SUS-ETMX_R0_OSEMINF_F3_OUT_DQ      H1:SUS-ETMX_R0_OSEMINF_LF_OUT_DQ         H1:SUS-ETMX_R0_OSEMINF_RT_OUT_DQ     

H1:SUS-ETMX_R0_OSEMINF_SD_OUT_DQ

ETMY

/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMY/Common/Data/2019-08-20_1835_H1SUSETMY_OSEM_ASDs.xml

H1:SUS-ETMY_M0_OSEMINF_F1_OUT_DQ      H1:SUS-ETMY_M0_OSEMINF_F2_OUT_DQ       H1:SUS-ETMY_M0_OSEMINF_F3_OUT_DQ 

H1:SUS-ETMY_M0_OSEMINF_LF_OUT_DQ      H1:SUS-ETMY_M0_OSEMINF_RT_OUT_DQ        H1:SUS-ETMY_M0_OSEMINF_SD_OUT_DQ

H1:SUS-ETMY_M0_OSEMINF_SD_OUT_DQ     H1:SUS-ETMY_R0_OSEMINF_F1_OUT_DQ        H1:SUS-ETMY_R0_OSEMINF_F2_OUT_DQ

H1:SUS-ETMY_R0_OSEMINF_F3_OUT_DQ      H1:SUS-ETMY_R0_OSEMINF_LF_OUT_DQ         H1:SUS-ETMY_R0_OSEMINF_RT_OUT_DQ     

H1:SUS-ETMY_R0_OSEMINF_SD_OUT_DQ

ITMX

/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMX/Common/Data/2019-08-20_1833_H1SUSITMX_OSEM_ASDs.xml

H1:SUS-ITMX_M0_OSEMINF_F1_OUT_DQ      H1:SUS-ITMX_M0_OSEMINF_F2_OUT_DQ       H1:SUS-ITMX_M0_OSEMINF_F3_OUT_DQ 

H1:SUS-ITMX_M0_OSEMINF_LF_OUT_DQ      H1:SUS-ITMX_M0_OSEMINF_RT_OUT_DQ        H1:SUS-ITMX_M0_OSEMINF_SD_OUT_DQ

H1:SUS-ITMX_M0_OSEMINF_SD_OUT_DQ     H1:SUS-ITMX_R0_OSEMINF_F1_OUT_DQ        H1:SUS-ITMX_R0_OSEMINF_F2_OUT_DQ

H1:SUS-ITMX_R0_OSEMINF_F3_OUT_DQ      H1:SUS-ITMX_R0_OSEMINF_LF_OUT_DQ         H1:SUS-ITMX_R0_OSEMINF_RT_OUT_DQ     

H1:SUS-ITMX_R0_OSEMINF_SD_OUT_DQ

ITMY

/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/Common/Data/2019-08-20_1844_H1SUSITMY_OSEM_ASDs.xml

H1:SUS-ITMY_M0_OSEMINF_F1_OUT_DQ      H1:SUS-ITMY_M0_OSEMINF_F2_OUT_DQ       H1:SUS-ITMY_M0_OSEMINF_F3_OUT_DQ 

H1:SUS-ITMY_M0_OSEMINF_LF_OUT_DQ      H1:SUS-ITMY_M0_OSEMINF_RT_OUT_DQ        H1:SUS-ITMY_M0_OSEMINF_SD_OUT_DQ

H1:SUS-ITMY_M0_OSEMINF_SD_OUT_DQ     H1:SUS-ITMY_R0_OSEMINF_F1_OUT_DQ        H1:SUS-ITMY_R0_OSEMINF_F2_OUT_DQ

H1:SUS-ITMY_R0_OSEMINF_F3_OUT_DQ      H1:SUS-ITMY_R0_OSEMINF_LF_OUT_DQ         H1:SUS-ITMY_R0_OSEMINF_RT_OUT_DQ     

H1:SUS-ITMY_R0_OSEMINF_SD_OUT_DQ

PRM

/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/Common/Data/2019-08-20_1932_H1SUSPRM_OSEM_ASDs.xml

H1:SUS-PRM_M1_OSEMINF_LF_OUT_DQ    H1:SUS-PRM_M1_OSEMINF_RT_OUT_DQ    H1:SUS-PRM_M1_OSEMINF_SD_OUT_DQ

H1:SUS-PRM_M1_OSEMINF_T1_OUT_DQ    H1:SUS-PRM_M1_OSEMINF_T2_OUT_DQ    H1:SUS-PRM_M1_OSEMINF_T3_OUT_DQ

SRM

/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/Common/Data/2019-08-20_1907_H1SUSSRM_OSEM_ASDs.xml

H1:SUS-SRM_M1_OSEMINF_LF_OUT_DQ    H1:SUS-SRM_M1_OSEMINF_RT_OUT_DQ    H1:SUS-SRM_M1_OSEMINF_SD_OUT_DQ

H1:SUS-SRM_M1_OSEMINF_T1_OUT_DQ    H1:SUS-SRM_M1_OSEMINF_T2_OUT_DQ    H1:SUS-SRM_M1_OSEMINF_T3_OUT_DQ

Also, please find attached the results from today's measurements, during Tuesday maintenance downtime. Later, I will compare this when the IFO is locked and observing.

M. Pirello, M. Withers:

We began the process of measuring phase noise on the 3.25 MHz RF Oscillator Source in the CER, which provides RF signals for the squeezer. Work on these measurements is onging and will continue next week.

D. Gustafson:

Noise hunting at the ISC racks in the LVEA.

(Tyler G, Gerardo M)

We installed a total of 4 threaded inserts today:

• 3 threaded inserts were installed for the new vertex turbo pump.
• 1 threaded insert was installed at the XBM new turbo pump location.

WP 8169

Isolated the cable trays from the cable tray supports with teflon for the SEI racks in the CER. Isolation is to help control our ground points. Each rack is now tied to building ground at one dedicated point. See alogs 49236, 48539 and 50576 for isolation done on other racks.

I looked at MICH_BRIGHT_ALIGN today, since it's been a problem recently for initial alignment.

It seems that even with just length locked (no ASC yet) we are occcasionally saturating the M2 stage of the suspension.  When this gets really bad (especially if the BS oplev loops start sending out very large signals) we start to constantly saturate the BS, and we are unable to lock or run the alignment loops.  If we were able to catch and hold the length lock, turning on the ADS lines at their former values would start this saturation cycle, and we lose the length lock.

I checked the MICH length OLG, and the loop looks fine. 

I was unable to measure the BS oplev loops, mostly because I wasn't patient enough to tune a template (do we have SUS oplev loop templates?) and my first few guesses of excitation amplitude were too high and caused the BS to saturate.  So, I don't know that it is an oplev loop stability problem, although that would be surprising since it's been fine for years now, and the typical oplev loop shapes are nice and stable.  Turning down the BS oplev loop gains to 100 for pitch (from  300) and 200 for yaw (from 650) seems to be a good compromise of having it on so it damps the BS when we lose lock and having it off so we don't saturate.  We ran through initial alignment with this, and it seems okay.  The DRMI DOWN state already sets these gains back to their nominal values.

Even with the oplev loops turned down a bit, the old ADS dither amplitudes were still causing the BS to saturate and we'd lose lock.  So, I've turned the ADS dither amplitudes down in the PREP_MICH_BRIGHT_ALIGN state to 1000 for pitch (from 30,000) and 300 for yaw (from 3000).  I have not yet done so, but we should probably increase the gain of the ADS loops by a factor of 10 so that these loops don't take so long to converge. 

Separate from the ASC part of MICH, if we were failing to acquire the length lock, guardian wasn't clearing the history of the BS M2 LOCK L filters, which have some high Q features.  So, the align IFO node's down state now clears that history.  This should solve the problem of continuing to saturate the BS when we're starting to try acquiring again (thus guaranteeing that we're going to fail to catch the lock). 

We've run through MICH_BRIGHT_ALIGN succesfully twice now, so it seems like it's okay, although we should increase the ADS loop gain next time we have a moment to test this.

The lowering of the BS oplev loop gains is *not* currently in the guardian, although perhaps we should make it so.

I adjusted the pointing and focus of the HAM2 East door analog camera, and it is now zoomed in on AOE2, a baffle between IM3 and IM4, and the baffle in front of the FI HWP.  I went to adjust the camera on IM1 reflected beam, however the power cable was quite loose, so I pulled the power cable out, and that camera is not powered.  Filiberto checked the cable and it's OK, and he suggested the connector might be the issue.  Will revisit this next week.

Nutsinee Daniel

Following up on alog 51270, we check the RF cables and connections. Some connectors could be tightened further, but no obvious jumps in the CLF power were observed while wiggling cables.

I did the sweep EXCEPT for Robert/PEM set-up (They will address their items as they come out).

I reset both PSL power watchdogs at 15:53 UTC (8:53 PDT).  This completes FAMIS 10724.

TITLE: 08/20 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: Niko
CURRENT ENVIRONMENT:
    SEI_CONF state: SC_OFF_NOBRSXY
    Wind: 5mph Gusts, 3mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY: A few people starting maintenance, just lost lock as well.

TITLE: 08/20 Owl Shift 07:00 – 15:00 (00:00-08:00), all times posted in UTC

STATE of H1: Observing

INCOMING OPERATOR: TJ

SHIFT SUMMARY: Lost some range for a few hours starting around 08:30 UTC, not from wind or ground motion (maybe SQZ). Rode through a 6.3 near Vanuatu around 13:30 UTC.

LOG:

07:00 (00:00) Start of shift

07:10 (00:10) Weak rise in ground motion for ~5 minutes. Strong enough to show up in ASC, weak enough to show up less in  EX than CS and EY. No corresponding EQ’s from SEISMON.

13:16 (06:16) Going to EQ seismic configuration for 6.3 EQ North of Vanuatu.

14:11 (07:11) Back to WINDY_NO_BRSX

14:28 (07:28) Kyle to MX -- grab parts

14:43 (07:43) Kyle back from MX

14:45 (07:45) Starting magnetic injections

14:54 (07:54) Richard to EY -- camera work

14:57 (07:57) Robert to EY -- 48 Hz work

15:00 (08:00) End of shift

The range started decreasing around 08:30 UTC without any corresponding changes in ground motion or windspeed, so I started trending OSEMs/ other channels to look for corresponding changes. I found a candidate in H1:SQZ-DCPD_RATIO_2_DB_MON on the "optimize BLRMS" scopes (found on the SQZ overview medm) and plotted the trend next to the range, which has since come back up (see attached).

After relocking we put the interferometer into Observe.  However, the PEM team has some equipment out on the floor that they'll need to go out to the LVEA to turn off.  So, this 43 second Observe segment should please be marked by DetChar as observing (maybe most pipelines already ignore measurements that short?)