7:00 Karen, Cris - LVEA cleaning exits

8:18 Betsy - To LVEA

8:42 J. Kissel - To EX to turn on coil driver

8:43 Sudarshan - To EX for Pcal work

8:58 Andres - LVEA for 3IFO work

8:58 Doug - To EX to take pictures

8:59 P. King - To H2 Enclosure

9:00 Bubba - To LVEA Moving SEI stuff

9:25 Andres - Back

9:27 J. Kissel - Back with fixed ETMX sensors

9:39 Doug - Back

9:40 Travis - To LVEA to meet up with Betsy

9:47 Travis, Betsy - Back

9:58 Sudarshan - Out of EX

10:06 Bubba - Back

10:39 P. King - Back

11:47 R. Savage, Nutsinee - To MY for check on storage

At  ~20:15 on Feb 4th, Hugh switched the GS-13s on ETMY ISI to low gain, and these haven't been switched back since. It's not clear if this impacts the performance of the ISI or not. I've attempted to find long stretches where ALS or oplevs were available to say something about the performance with out of loop sensors, but so far I haven't been able to get a clean before AND after spectra. ISI local sensors don't show any difference (see my plots earlier today showing ETMY vs ETMX suspension point motion, ETMX has always been in high gain). I attach a trend from the 4th to the 6th showing ALS CTRL and one of ETMY's GS-13s. The gain switch is pretty obvious on the GS-13 plot. The best I've been able to find is my second attachment, showing ALS CTRL spectra, dashed lines are high gain, solids are low. Only differences I can see are likely due to higher ground as the solid lines were at 21:20 (3:20PM local). ITMY's GS-13s are in high gain for both measurements, and so could be obscuring this measurment. I'll try to get a measurement with both ISI's in high and low gain.

Jim, Krishna, Ryan, Jeff, Sheila, Alexa, Evan, everyone

We have been having trouble keeping the Y arm locked with green, due to cavity motion of about 10 um in about 10 seconds.  The winds at end Y are approaching 40 mph, and have been climbing for an hour and a half.  We have copied the 90mHz blends for X and Y from the ETMX ISI into ETMY and blending high has allowed us to lock ALS for now.  

The attached screen shot shows the Y arm control signal (from the end station PDH with no slow feedback on) in beige, and the X arm in yellow.  The blends were switchd at about -21 minutes.  

The attached plots show:

1. The IPC errors from the corner to end stationfor the past year: ETM control signal
2. The IPC error from the end to the corner for the past year: Red transmitted light power
   The errors got really high after we added WFS and auto-centering.
3. The same as above but for the past 8 days. No IPC errors were detected, since the model was split 3 days ago.

J. Kissel

ETMX UIM Driver's rocker switch tripped last night at 8:44:30 UTC (Feb 06 2015 00:44:30 PST), which cause all OSEM output on the L1 / UIM stage (and the sensor signals as well) to fail. 

I've turned on the rocker switch, and the stage appears functional.

Other points:
-------------
There is no smoking gun for this chassis power outage. There are not enough diagnostic tools in the frames to look at all possible suspects (power surge to the chassis [no power monitors], chassis overheating [no temperature sensors], an inconsequential component on say -- a monitor board -- smoking [only one of the four monitor signals for each channel are stored], too large a current request [the NOISEMON is stored, not the FASTIMON]).

Output request of DAC (from any ISC) does not appear to coincide with trip, but difficult to tell with dataviewer. There is an Longitudinal request to drive really hard, but it's unclear whether it's a the cause of or a result of the driver's power being shut off.

Output request is roughly 42 [mA] (according to FAST_I_MON) on all four coils leading up to trip, switch trips on 3 [A]. Even the sudden, very large output request does not cause any current larger than the 42 [mA] -- as reported by dataviewer / EPICs. Reqrettably, only the severely-high-passed-at-5-[Hz] noise monitor signals are stored in the frames, but I attach the time series of one of the coils anyways to indicate the exact time. It shows a nice smooth ramp down at the time of the chassis power down. 

Serial number of this box is S0900303. I attach pictures of the box after I'd turned it back on. When I first approached the box, the front "power" LED lights were OFF, and the rocker switch was in the opposite (powered off) position. 

I'm not sure if there is good way to make this power shut-down control-room visible. I did notice that all the coil driver monitor signals were frozen at -16 [ct], and that the OSEM sensor speed dials were zero for this stage and this stage alone, which is what immediately clued me in that it was a flaw with the entire coil-driver chassis or satellite amplifier. 

This last happened (according to collective analog CDS crew's memory) on H1 SUS ITMX UIM driver, some time ago, 19 November 2013. See LHO aLOG 8635.

Ed, TJ, Kiwamu,

We fixed an issue associated with the camera servo in the green ASC loops. It is now functional as it should be.

When we were going through the initial alignment sequence this morning, we noticed that the Y arm green transmitted light decreased after the ASC loops were engaged. We figured out that this happened only when the DOF3 (which is the ITMY camera servo actuating on all three suspensions) was engaged. Adter some inspections, we found that the input of M0_LOCK_P(Y) were off on ETMY. Since the camera servo is the only one who actuates on ETM, the servo was introducing some funny imbalanced feedback into the cavity. Bad. We enabled them and confirmed that this fixed the issue.

Also, Alexa told us that she had a similar issue in the X arm green ASC yesterday and she had to switch off the camera servo. Checking M0_LOCK_P(Y) filters in ETMX, we found them also disabled. So we enabled them. We did not check whether this fixed the situation or not, but I believe that this fixed the issue in the X arm as well.

Alexa, Kiwamu

In response to the commissioning alog from the last night (alog 16501), we spent an hour or two to study the DRMI lock acquisition with ETMs miasliged in this morning. The key item we checked this time was the BS limiter. We took a few lock acquisition samples with and without the BS limiter which was suggested by Ryan.

It seems that the limiter improved the locking time. We will tentatively keep the limiter on.

The alignment was adjusted initially so that we observed consistently high build up in each lock. We tried repeating the same test with the arm cavities aligned, but we ran into some aligment issues which prevented us from completing the test with the arm cavities aligned. Note that this limiter method is something we used to use in the past, but  apparently we decided not to use it for some reason at some point.

(The test without the limiter)

(The test with the limiter)

(The limiter)

The limiter resides in BS_M3_ISCINF_LIMIT and the value was set to 5x10⁵ cnts.

To aid in evaluating whether there is any potential wire heating happening with SR3, please see the attached SW rendering of the HAM5 SR3 view as seen from straight in front of SR3.  While there is not a "wire shielding" baffle in front of the SR3 (which there is on PR3), there is a stray light control baffle.  The aperature of the baffle is slightly larger than the distance between the wires on either side of the optic.  From the point of view in the rendering, the +X wire of the SR3 is exposed to incident beam.  The point of view seems to be pretty representative of the incident beam coming from the BS.  Of course, we could have made an error in placing this baffle which may expose more or less of the wire than shown in the rendering. 

(Note, when zoomed in, the wire shown in the rendering is slightly off since the tiny secondary prism in red was added after the fact and the wire trajectory was not updated.  The wire of course goes over this red prism, not through it as shown.)

The rendering attached can also be found on the dcc at:

https://dcc.ligo.org/DocDB/0096/D1201315/004/SR3%20CAD.JPG

Thanks, Eddie S!

Sheila, Elli, Evan, Ryan, Lisa

Apparently today was a particularly bad day for the whole locking business. 
To get the DRMI locking with the arms off-resonant, we had to retune the locking gains
as previous settings were not working, meaning we could not get a single lock of DRMI + off resonant arms in ~ 20 min.

After carefully aligning the DRMI (with no arms), we changed the locking settings as follows:

DRMI ---> DRMI with off-resonant arms

MICH  3 ---> 3 
PRCL 15 ---> 8 (it was 11)
SRCL -50 ---> -40 (it was -45)


 It would be extremely helpful to test these new settings again several times, and do some systematic lock acquisition studies from DRMI to DRMI with off-resonant arms in the morning. It still takes too long to acquire lock. 

We then went through the locking sequence, and stop at some point to give Evan and Elli a chance to measure the opto-mecahnical TF of the DHARD alignment DOF, so we could design a good filter to increase the bandwidth of DHARD, if necessary.  
We broke the lock in the process, and Sheila struggled to get ALS DIFF working right after that. 

While investigating the problem, Ryan found out that we could not get any actuation at all from the ETX L1 stage.  Please investigate/fix this in the morning, a manual reboot at the end station might be required.   

On a positive side:

* Evan and Elli got a good measurement of the DHARD plant and designed a compensation filter for that, so we should be ready to test it;

* ETMY L1 has now a working L2P filter, so we could eventually try DARM actuation to both end masses, if necessary.

Earlier today, with Ryan's encouragement, I turned on more of the I/ETMY isolation loops. Currently these 2 ISI's are running a configuration like LLO's, with all DOFs engaged on St1 and X,Y,Z,RZ running on St2. The St1 RZ loop is running a high (750mhz) blend with no T240. St2 is running the same 250mhz blend on Z and RZ as it was previously running on X and Y. The Stage Guardians for these two chambers have also been modified to turn on these loops, in case we have some traumatic event.

FF is now running on all test mass chambers as well with X&Y running on ETMY, Y on ITMY and X on E/ITMX.

Alastair, Elli, Jamie

We're working on Guardian today, and wanted to install a beam dump at the output of the Y-arm table so that we can play with that laser without injecting power to the CP.  While doing this we discovered the laser was running only at 1/2 power.  The history to this is that a few months ago the same laser was running at half power, and after swapping in a different driver, went back to full power.  The "not working" driver was sent to Caltech where it was found to be working fine.  So this new episode was actually quite useful in finding that a problem still exists.

We went out to the LVEA and found that the power connector at the patch panel is badly connected.  We couldn't effect a permanent solution in the 1hr window we had, but were able to get the laser back to full power again.  These connectors will likely need replaced long term, and we'll start working on a solution to that.

The ouput of the table was found to be dumped to a beam dump already (it has been like this since installation of the table was completed).

Minor changes to the drift monitor threshold updater script:

The log files are now recorded to: "/opt/rtcds/userapps/release/sus/common/medm/sus_driftmon_logs/", and have the following file name structure: SUSDRIFT_{OPTIC NAME}_{START_TIME}-{DURATION}.log (e.g. SUSDRIFT_ALL_1107199664-15.log, SUSDRIFT_MC1_1107199664-15.log)