TITLE: 11/19 [DAY Shift]: 16:00-24:00 UTC (08:00-16:00 PDT), all times posted in UTC
STATE Of H1: Observing @ ~ 80 MPc.
OUTGOING OPERATOR: Nutsinee
QUICK SUMMARY: From the cameras the lights are off in the LVEA, PSL enclosure, end X, end Y and mid X. I can not tell if they are off at mid Y.
Earthquake seismic band is between ~ 0.01 and 0.03 um/s. Microseism has been coming down and is between 0.1 and 0.4 um/s.
Winds are between ~ 0 and 5 mph.
ITMX, ITMY and BS ISI blends are on 45mHz. EMTX X and ETMY Y ISI blends are on 45mHz. ETMX Y and ETMY X ISI blends are on Quite_90.

I've been noticing all night but not sure where from. Those nasty little lines seem to have come with a broad peak at 1040Hz. It's not the violin mode second harmonics (which ends at ~1010Hz).

Found damp settings for 1009.0273 Hz and 1009.6825 Hz (ETMY). Both lines have very low amplitudes to begin with (only a magnitude above the noise floor) so once I was able to damp them slightly I turned the damping off. Here's the table. The BP filters live in ETMY L2 DAMP MODE4 FM7 and FM10.

Livingston seems to be having problems with their front end and won't be up for a while. I'll take some time to work on the 2nd harmonics violin modes.

11/19 Owl Shift 08:00- 16:00 UTC (00:00-08:00 PST)

State of H1: Observing

Out going Ops: Ed

Quick Summary: The ifo lost lock the minute I walked in (after abandoned it early for two nights in a row I don't think it likes me anymore). We are now observing again at 08:35 UTC. I ran into a small problem with the Guardian during Engage ISS 2nd Loop. After 4 minutes Guardian gave me a message that Engaging ISS 2nd Loop fail and once I successfully engaged the loop by hand ISC_LOCK Guardian didn't seem to recognize it. I had to re-request ENGAGE_ISS_2ND_LOOP and do it again.

TITLE:    Nov 18 DAY Shift 00:00-08:00UTC (04:00-00:00 PDT), all times posted in UTC

STATE Of H1: Locking

SUPPORT: Kiwamu

LOCK DURATION: ≈3.5 hours

INCOMING OPERATOR: Nutsinee

END-OF-SHIFT SUMMARY: Lots of little issues that are documented in my activity log. Nutsinee arrived right as the Oklahoma quake broke our lock

ACTIVITY LOG:

01:25 begin initial alignment after Kiwamu re-aligned beam pointing in IMs and MCs

03:13 Locking sequence gave me trouble for a while at DRMI after it locked and dropped. Reverted back to PRMI to tweak. Transistioned to DRMI locked almost immediatley. Stopped at ASC_PART3. made it to Bounce_Violin_Mode_Damping and then broke

03:39 Have had to tweak th COMM VCO due to poor X buildup in FIND_IR. Now haveing Cage Servo issues. Kiwamu is on it.

03:55  back to locking again…

04:23  Diag reset on H1IOPASC0 Timing Error

04:47  IFO locked at NLN/75Mpc. Kiwamu cleaning up SDF after his work.

05:04  Noticed that the Lock Timer wasn’t running so I started it. Not sure if it supposed to be from NLN or Intent bit. It’s ≈10 minutes behind the intent bit.

08:00  Down due to Earthquake. Handing of to Nustsinee.

07:52UTC 

4.7mag in Oklahoma

USGS event link

Ed, Kiwamu,

During the course of relocking effort today, we ran into three issues associated with the guardian automation. Two of them are fixed/improved by editing the guardian codes while we were not able to fix the last one.

Here is some notes.

• Issue 1 (fixed), INPUT_ALIGN of IFO_ALIGN does not lock the X arm.
  • We found that this was due to a too high gain which had been increased in this afternoon (alog 23532) with an aim to improve the loop stability. We reverted the gain back to the nominal of 0.05 in lscparams.py.
  • The new code is submitted to SVN. It works fine with the nominal gain so far. We have no idea why it needed to be increased by a factor of 3. Perhaps related to the bad input pointing (alog 23538) ?
• Issue 2 (fixed), OMC_LOCK was consistently unable to find the carrier resonance.
  • This was found to be due to a unfortunate PZT scan range -- the peak-finding algorithm was unable to identify three high peaks (two from 45 MHz sidebands and one from the carrier). We have been mitigating this issue by adjusting the scan range so that the three peaks are separately captured in different segmented time series. This time, one of the segmented data chunk tended to capture one of the 45 MHz sideband as well as carrier. This situation ended up forcing the algorithm to pick only one of them and abondon the other. This in turn let the algorithem think there were only two peaks. I changed the scan starting voltage from -30 to -24 V so that three peaks are captured in different segments.
  • The latest code (OMC_LOCK.py) and parameter file (omcparams.py) are checked into SVN.
• Issue 3 (not fixed), CAGE_SERVO did not warn us that it was railing.
  • No idea why. It is supposed to give us a notification message when the amount of feedback is high. However it did not behave that way and simply kept servoing SR3 without giving a notification/warning message. We reloaded the code, but it did not seem to enter the if statement in which the warning message is given.
  • We manually offloaded the control signal to the upper stage in SR3.

04:56UTC

MID-SHIFT SUMMARY: Locking is a bit of an arduous task. There has been beam pointing issues, alignment of DRMI issues (not that uncommon), IR resonance issues and Cage Servo issues. Now it seems as though OMC has us stopped on ENGAGE_ASC_PART3. Winds are calm. Seismic environment is ok.

Plot shows two bigh alingment changes:

1) 13 Nov 2015 start at 17:00UTC, first jump 22:00UTC, IM2 Pitch changes 46urad, IM3 pitch jumps 5urad and continues to drift another 5urad.

2) 14 Nov 2015 at 23:00, IM1 Yaw jumps 15urad, and IM4 pitch sees a jump of 50urad - this might be an alignment change.

The first jump in alignment can clearly be seen in channel 9, IM4 Trans Pitch, and ISS Second Loop QPD Yaw.

• IM2 pitch changes 605 to 565
• IM3 pitch cjanges 1948 to 1955, and keeps drifting
• IM4 Trans Pitch sees an alignment change of  -0.41 to -0.2
• ISS second loop goes from 0 to -0.5

The second jump in alignment can clearly be seen in channel 2, IM4 Trans yaw, and ISS second loop pitch.

• IM1 yaw jumps from 18urad
• IM4 pitch changes 60urad
• IM4 Trans yaw changes from 0.069 to 0.189urad
• ISS second loop pitch goes from  -0.18 to -0.378

Currently, Kiwamu is adjusting the alignment.

TITLE: 11/18 [DAY Shift]: 15:00-23:00 UTC (08:00-16:00 PDT), all times posted in UTC
STATE Of H1: Lock acquisition
SHIFT SUMMARY: Initial problems with ESD driver. Ran initial alignment. Offloaded dark offsets for ASAIR_B_RF90. Large earthquake in Solomon Islands. HAM5 ISI, ITMX ISI and SUS SRM watchdogs tripped. Cleared IMC WFS histories to relock IMC. Betsy ran charging measurements while waiting for earthquake to ring down. Guardian glitch. Ran initial alignment. Lost lock after reaching ENGAGE_ASC_PART3 and then after reaching ENGAGE_ASC_PART2. Will stop at ENGAGE_ASC_PART1 to allow Kiwamu to check of ASC loops.
INCOMING OPERATOR: Ed
ACTIVITY LOG:

16:06 Jeff B. to mechanical building to check on TCS chillers
16:12 Jeff B. back from mechanical building
16:57 Jeff B. back from getting garb
17:01 Filiberto and Gerardo back from resetting ESD at end Y
17:01 Filiberto plugging control room GPS clock into IRIGB chassis
17:15 Karen and Christina clearing tumbleweeds off stairs to roof
17:19 Richard and Filiberto to roof to check on dangling cables
17:22 Chris to work on beam tube enclosure 5 doors from end X
17:33 Karen and Christina done clearing tumbleweeds off stairs to roof
17:44 Joe D. to work on X arm beam tube enclosure
Landscapers are bailing tumbleweeds
17:47 TJ reloading diag main to add check for PMC HV
19:06 Travis to LVEA to look for part
19:14 Travis back from LVEA
19:49 Gerardo forklifting diesel container out of bunker
20:09 Joe D. back
20:38 Gerardo done with forklift
20:58 Betsy running charge measurements
21:49 Richard to DC power mezzanine to look at PEM radio
22:01 Betsy done running charging measurements
22:04 Richard tuned PEM radio antenna frequency
22:12 Gerardo using forklift to unload diesel tank at bunker
22:17 Kyle driving down X arm to assess tumbleweed bailing progress
22:29 Gerardo done
22:44 Kyle back

TITLE: Nov 18 EVE Shift 00:00-08:00UTC (08:00-04:00 PDT), all times posted in UTC

STATE Of H1: Locking

OUTGOING OPERATOR: Patrick

QUICK SUMMARY: @ the Lock DRMI 1F stage. µSeis is trending down towards the .5µm/s mark and eq bands have settled back down to .02µm/s territory. Winds are calm again.

I edited lscparams.py to set the initial alignment X arm IR gain higher, to match the gains we're having to enter manually to get the arm to lock in red.

Included below are the line I changed, and the previous comments.

arm_IR_gain['X'] = 0.15 # was 0.05 and doesn't lock, bumped up to 0.15, CV 18 Nov 2015
#was 0.08 until August 18 2015 # was 0.12 as of Apr-16-2015 and bit too high
#arm_IR_gain['X'] = 0.2 #should be 0.2 to acquire lock
 

What was done:

1. RF AM measurement unit (D0900891) installation.
2. Taping down 45MHz cable from the ISC ract to the EOM driver.
3. Rephasing

1. RF AM measurement (D0900891) unit installation

To better diagnose the problem, we inserted RF AM measurement unit (D0900891) between the EOM driver and the EOM.

For connection cartoon, see the first attachment.

The unit was placed on top of the DCPD interface box that was next to the EOM driver.

Couplers are connected back to back such that the first one sees the forward going RF, the second one the reflection from EOM. Insertion loss of one coupler is rated 0.3dB and this was confirmed by the power measurement. Driver output was 23.34dBm (measured by RF meter with 30dBm attenuator), after the second coupler it was 22.67, so the insertion loss of two couplers is 0.67dB. We didn't do anything to compensate, it's not a big deal. But this means that the modulation index is smaller by that much.  

EOM reflection was measured by looking at reverse direction coupler output on the scope, which was about -11.6dBm (about 59.1 mVrms with 50 Ohm input). The reflection from EOM should be something like 20-11.6=9.4dBm, i.e. EOM is only consuming 22.67-9.4 ~ 13.3dBm.

Just so we can, Kiwamu tightened the SMA connectors on the EOM inductor box. We also wiggled various things but didn't get any new insight except that wiggling/tapping power cable/connector on the EOM driver and on +-24V distribution strip didn't do much.

Forward going coupled output was connected to the manually adjusted channel. Front panel was adjusted so the MON voltage becomes closest to zero. That was MON=-300mV at  2.6dBm setting.

Reverse going couple output was connected to the automatically biased channel.

This unit needs >+-28V supply in addition to +-17. Filiberto made a special cable that has bananas for +-30V and usual 3-pin for +-17, and we put a Tenma supply outside of the PSL room for +-30V-ish.

A long DB9 was routed from CER to the PSL rack, and a short one was routed from the PSL rack to the RF AM measurement unit, for DAQ. This was plugged into the spigot that was used for the spare EOM driver unit before (i.e. "RF9" monitors).

H1:LSC-MOD_RF9_AM_ERR_OUT_DQ and H1:LSC-MOD_RF9_AM_CTRL_OUT_DQ are for EOM reflection monitor.

H1:LSC-MOD_RF9_AM_AC_OUT_DQ and H1:LSC-MOD_RF9_AM_DC_OUT_DQ are the channels for forward going RF monitor. AC corresponds to ERR and DC to CTRL.

2. Taping down 45MHz cable

We changed the routing of the RF cable between the driver and the ISC rack. Inside the PSL room, it used to go under the table but over the under-table cable tray, and kind of floating in the air from the floor to the cable tray, and from the cable tray to the EOM driver, pushed by other cables.

We rerouted the cable so that it never leaves the floor, and taped it to the floor using white tape. We also taped down some of the cables that were pressing against the RF cable. See the second attachment.

3. Rephasing

In the lab, the delay of the double couplers alone for 45.5MHz signal was measured to be about 0.8 ns or 13 degrees. Kiwamu made a long cable, we added two N-elbows, and we measured the transfer function from ASAIR_A_RF45_I_ERR to Q_ERR. We ended up having:

Q/I = +4.45 (+-0.14), or 77.3 (+-0.4) degrees.

Before the installation this was 77.5 (+-0.1) deg (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=23254), so this is pretty good.