J. Kissel

Your weekly charge measurement update from H1: ETMX and ETMY ESD systems are showing little-to-no effective bias voltage from accumulated charge. 

Recall we're flipping the bias voltage whenever the given test mass is not in use (i.e. ETMY flipped when DOWN [since 2016 Nov 28, see LHO aLOG 31929], and ETMX flipped when in nominal low noise [since 2016 Nov 03, see LHO aLOG 31172]). Since the regular flipping began, and our duty cycle has been consistently around 50%, we're keeping all quadrants below +/-10 [V] effective bias voltage, which is a small fraction of the requested bias voltage (~400 [V]), which means the actuation strength is changing at the sub-percent level, and is consistent with the uncertainty of the measurement.

We should confirm this by comparing against longitudinal actuation strength, a. la. LHO aLOG 24241.

WP 6428

This morning the CO2 Laser Interlock Chassis D1200745 was replaced. This work is part of the ongoing investigation of the TCS flow sensor alarms/glitches. See alog 32776. Verified trip point for the temperature shutoff of the laser on new chassis. Steps taken to replace chassis:

1. Turn off laser at key
2. Turn off chiller in mechanical room
3. Turn off chassis and unplug all connections
4. Install new chassis, rocker switch set to CW (OPS) position
5. Redo connections to chassis & power on
6. Turn on chiller
7. Check there are no red lights on chassis front panel
8. Key on laser and press gate button
9. Check laser power actually powers on (MEDM screen).

Old Chassis S1302125
New Chassis S1302122

Fil, Richard, Nutsinee, Alastair

FAMIS#4709

I couldnt get the data via the script so I had to get second trends "by hand" in dataviewer. Barbaric.

ETMY Pit is at -12

ETMY Yaw is at -8

ETMX Pit is approaching -10

Krishna

I have modified the C# code in BRS Beckhoff computers used for the angle readout. The code is used to fit the cross-correlation of the patterns in the CCD to infer the position change (=angle) of the patterns. The code used to have a manually adjusted fit parameter. This was unsatisfactory and produced errors in the fit as the beam-balance position changed over time or it's amplitude grew. The noise level in the angle would vary from ~0.2 nrad/rt(Hz) to ~0.4 nrad/rt(Hz). We came up with a better routine than can extract this parameter from the data and use it to correct the fit producing superior results as shown in the attachment. The noise level should now stay below 0.2 nrad/rt(Hz).

The code for both BRS' has been updated.

This should allow us to set higher thresholds for BRSX damper, which will help with the problem in 33028. However, it would still be a good idea for the operator or anyone else to keep the BRSX amplitude small by damping it, whenever we are not observing.

Other updates

I cleared the encoder_value_save.txt file for BRSX, by deleting all characters inside. I suspect the large number of ascii values there were caused by interruption of the ethercat communication to the Beckhoff Motor Controller, likely due to lose wires. The evidence for this is the two drops in the BRSX_BOXBIT in November. It hasn't happened since, but it would be good to investigate it when convenient. After clearing the file, I restarted the computer, restarted the PLC and zeroed the encoder position. After modifying the C# code and restarting it, the damper seemed fine. We'll keep an eye on this.

For BRSY, I noticed a couple of problems with the Diagnostic C# code, which we use when we have to change the centering of the beam-balance. First was that Visual Studio asked me to log in with a Microsoft account id. I created a new one, since I couldn't remember what the old one was. This info will be added to the BRS troubleshooting guide on the DCC to prevent this problem in the future. Second, the C# code would freeze after 11 seconds for no obvious reason. I restarted the Beckhoff computer, after which it worked fine. I wanted to make a note of this here to prevent future surprises.

After consulting with John W. and Bubba G., Jim W. and I decided to postpone the spare seismometer test at BRSY due to the poor road conditions. I'll leave the table with Jim and he will install it at the next available opportunity

WP 6418

After moving minute trend files from h1tw1's SSD RAID, I modified the daqdrc file and restarted daqd on h1nds1 to read the old minute trends from /frames.

The alignment into the reference cavity was tweaked. Transmission signal went
from ~1.6 to ~3.5.  Mostly pitch adjustment on the periscope.

6.4M Kirakira, Solomon Islands

Was it reported by Terramon, USGS, SEISMON? Yes, Yes, No

Magnitude (according to Terramon, USGS, SEISMON): 6.4, 6.4, NA

Location: 108km WNW of Kirakira, Solomon Islands; LAT: -10.2, LON: 161.1

Starting time of event (ie. when BLRMS started to increase on DMT on the wall): ~15:50 UTC

Lock status? Caused lockloss.

EQ reported by Terramon BEFORE it actually arrived? It arrived before my shift started, so not sure.

TITLE: 01/10 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Earthquake
OUTGOING OPERATOR: Jim
CURRENT ENVIRONMENT:
    Wind: 11mph Gusts, 9mph 5min avg
    Primary useism: 0.39 μm/s
    Secondary useism: 0.38 μm/s
QUICK SUMMARY:  Currently Down due to EQ in Solomon Islands that arrived just as shift was starting.
 

TITLE: 01/10 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: EQ, maintenance day
INCOMING OPERATOR: Nutsinee?
CURRENT ENVIRONMENT:
    Wind: 11mph Gusts, 10mph 5min avg
    Primary useism: 0.24 μm/s
    Secondary useism: 0.41 μm/s
QUICK SUMMARY:

I had problems with PI modes 27 & 28 all night, they needed constant attention. 27 broke lock once, and when I got back up, looking at spectra showed that the modes that were ringing up were outside the mode 27 bandpass filter, so I switched from FM5 (18036.5 hz) to FM4(18040 hz), and could at least control the PI for the rest of the night, but it needed frequent tweaks to the PLL phase.

Maintenance has started, Peter headed out to the PSL after an EQ knocked us out, Krishna has started a software upgrade to the BRSs.
 

TITLE: 01/10 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC

• 4:37 TCSy Chiller Low
• 5:25-6:15 IP5 work in Mechanical Room (Gerardo)
• 6:37 Lockloss due to Phillipines EQ
• 6:40 Took ISIs to LARGE_EQ_NOBRSXY
• 7:12 ISIs to WINDY
• 7:42 finally able to get past LOCKING ALS.  Aligned BS in CHECK MICH FRINGES, but PRMI looked dead/misaligned---Tweaked PRM in yaw and had flashes....but handing off to Jim and he's going for an Initial Alignment.
• 8:03 GRB Acknowledged.  H1 & L1 out due to the EQ.  Talked with William P and it sounded like they still had lots of noise preventing locking.

• EQ seen on USGS (thanks Gerardo) & it was already noted on Terramon...thought I had time because R-wave was expected to arrive at 7:09utc (but lockloss at 6:37utc) 
• Magnitude:  7.9
• Location:  Philippines
• Starting time of event:  Observed on BLRMS at 6:35utc 
• Lock status?  H1 broke lock closer to the S&P wave arrival times (vs R-wave time)

LHO DQ summary:

• Excess of glitching starting midday on Jan 06; Andy traced this to the ETMY L2 coil driver, and LHO commissioners power cycled it: alog
  • This glitching may be due sparking associated with very low humidity in the EY VEA.
• RF noise briefly appeared on Jan 05: alog
• 1084 Hz glitches still an issue for the burst search; linked to OMC length noise: alog
• OMC length dither thought to be source of 1084 Hz glitches: alog

Fire alarm follow-up:

• Ed Merilh suggested detchar cut fire alarm out of observing mode data on Jan 05 based on PSL mic: alog. TJ Massinger and Laura Nuttall have generated a DQ flag as suggested and applied it to the CBC search; the burst search will likely follow suit.

For more details, please see the DQ shift pages: 2017Jan02, 2017Jan05

H1 has been in OBSERVING for over 6.5hrs.  Range is a hovering around 60Mpc.

Minimal activity.  Gerardo just arrived to make a cable for an IP5 in Mechanical Room.

Just had a TCSy Chiller Flow Alarm.

On Kissel's suggestion, flagging H1 data from 23:45-1:25UTC, due to snow plowing (by Bubba).  This is for CP2 access for LN2 delivery Tues morning.  Activity could be seen in our 3-10 & 10-30Hz bands.  This brought H1 range down below 50Mpc at times during this period.  Drifts were several feet high & it took him almost 2hrs just to plow just this short section.

TITLE: 01/10 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC

• Sheila took the helm for H1 during the day (see her alogs).  Walked in to an H1 in OBSERVING since ~22:00UTC [2PM PST]).
• ~0:15UTC our range dropped from around 60Mpc to below 50Mpc due to snow plowing around CP2 in preparation for LN2 delivery in the morning.  This increased seismic in the 3-30Hz bands.
• We are currently running with the OMC LSC Servo Gain of 3.0.
• Talked with Jeremy at LLO (& Anamaria) to let them know we are back to Operator coverage at LHO.

J. Kissel

I've noticed the amplitude spectral density of PCALY RX PD looks to be showing the same sort of clipping behavior that was present early last October (Identified in LHO aLOG 30827; Solved in LHO aLOG 30877). I'll send a note to team PCAL and suggest they take a look tomorrow during maintenance.

The attached plot shows the ASD of PCALY RX PD (in PURPLE) and CAL-DELTAL_EXTERNAL (in RED) during the most recent lock stretch (2017-01-09 19:30:49 UTC) compared against PCALY RX PD right after they'd fixed the clipping issue last time (2016-10-26 17:26:40 UTC).

Unclear why the clipping has returned, other than to say that what is a "good" alignment of ETMY that the exit PCAL beams were aligned to may have changed / drifted over time. A 20 day trend shows that clipping only started after the IFO returned to operation on Jan 4th.

This morning we sat in nominal low noise without going to observing from 19:21 to 19:51 UTC (Jan 9th) in a configuration that should be much better for the 1084Hz glitches. (WP6420)  

On Friday we noticed that the 1084Hz feature is due to OMC length fluctuations, and that the glitch problem started on Oct 11th when the dither line amplitude was decreased (alog 30380 ).  This morning I noticed that the digital gain change described in alog 30380 that was intended to compensate for the reduced dither amplitude didn't make it into any guardian, so that we have had a UGF that was a factor of 8 lower than what I used when projecting OMC length noise to DARM: 30510 The first attachment shows open loop gain measurements from the 3 configurations: before oct 11th (high dither amplitude), after october 11th (lower dither amplitude, uncompensated) and the test configuration (lower dither amplitude, compensated).  

We ran with the servo gain set to 24 (to give us the nominal 6Hz ugf) and the lowered dither line amplitude from 19:21 UTC to 19:51 UTC Jan 9th.  You can see the spectrum durring this stretch in the second attached screenshot, in the test configuration the peak around 1083Hz is gone, with just the pcal line visible, and the OMC length dither at 4100Hz is reduced by more than an order of magnitude. You can also compare the glitches from this lock stretch with one from yesterday  to see that the glitches at 1084 Hz seem to be gone. This is probably the configuration we would like to run with for now, but we may try one more test with increased dither line amplitude.  

Other notes because we don't have an operator  today due to weather:

This morning all 4 test mass ISIs were tripped probably from the Earthquake last night that brought the EQ  BLRMS to 10 um/second around midnight UTC.  ITMY tripped again while it was re-isolating, no problem on the second try. 

Richard topped added 400mL to the TCSY chiller around 10:15 or 10:30 local time, since we were getting low flow alarms. The flow alarms came back a few minutes before 11am local time.  

I went through inital alingment witout problems and got to DC_readout transition. Then I measured the UGF of the OMC length loop in preparation for increasing the dither line height   From that measurement and trends it became clear that when the OMC dither amplitude was reduced, the compensation of the OMC digital gain described in didn't make it into the guardian.  This means we have been operating with a UGF in the OMC length loop that was a factor of 8 too low since mid october.  

We arrived in low noise at 19:21 UTC with the OMC ugf increased to 6Hz.  After about a half hour PI modes 27 and 28 rang up, and I wasn't fast enough to get them under control so we lost lock.  

Replaced IP5 controller in mech. room with GAMMA LPC (+) controller (WP 6421). One of two channels of the old controller was faulting "over temperature," a typical error/failure mode on the Varian controllers. LVEA pressures rose slightly due to reduced pumping speed (see aLOG 33070) over weekend. We will update CDS signal cabling (right now pump appears to be in error, but it is actually fully functioning) and reboot Beckhoff at next opportune maintenance period.