We have been having locklosses due to the glitches which seem very similar to the ones that happened when we had a laser safety tag hitting the ALS fiber in the HVAC wind.  This seems to have started or gotten much worse on tuesaday.  We looked at fibers in the MSR, and they are still in their protective tubes.  

Does anyone know of work on Tuesday which might have changed something near the ALS fibers?

At the PSL rack, there is still a laser safety tag which is zip tied to the fiber and hanging off of it, causing strain.  I temporarily set this to rest on one of the chassis, but it would be good to remove the tag from the fiber if we can.  

After I touched the fiber the polarization arriving at the end station was wrong.  If looks as though the polarization controller has been in error since Tuesday maintence.  I am not sure what the polarization error means, but it cleared when I turned the box on and hit the reset button. 

To look at the oscilloscope at the PSL racks, run

xvncviewer 10.105.0.120

on a control room computer.  10.105.0.120 is the scope IP address, which must be plugged into port 6 of the PSL rack router.  xvncviewer is the TightVNC remote desktop controller.

Other scope info can be found at http://10.105.0.120/.

During the commissioning meeting today we discussed what to do about the bad lock acquisition. We decided to try the new SEI config which is in Jim's log, and also to revert the TCS pre-load configuration from 50W pre-load to somewhat less (see entry below). Probably, the pre-load was making too much angular instability in the DRMI; too much lensing -> unstable cavities.

Our DRMI lock acquisition speed is now back to less than several minutes, with a few locks this afternoon happening within a couple minutes. This is great. We need to capture this configuration of parameters sothat we don't wander away from the good place.

I've written a new guardian state in ISC_LOCK that will turn on all ASC loops at low bandwidth, wait for convergence of them all, and then increase the bandwidths of the loops.  I have tried this once by hand a day or so ago, but never with the guardian.  This should, however, solve the engage asc locklosses that we have when some of the early loops (eg. PRC2, INP1) pull the IFO alignment somewhere, and the other loops (eg. SRC1 and SRC2) aren't able to follow.  This pulls the recycling gain down, but then when the next loops are engaged all of the buildups get better. 

Since all of the full IFO ASC is in one state, if you were to get to PREP_ASC_FOR_FULL_IFO and just request something at or higher than PREP_DC_READOUT_TRANSITION, the guardian will take you through the new ENGAGE_ASC_FOR_FULL_IFO.  However, if you get to PREP and select one of the old ASC states, like ENGAGE_REFL_POP_WFS, then the guardian will take you through the old set of ASC engagement steps. The attached screenshot of the guardian graph hopefully makes this more clear.

Just like the work I did a couple weeks ago on HAM 4, today I tried to reduce cavity lengths by sending gnd z to HAM3 X. Seems like it works, although the high microseism has made getting good transfer functions difficult today. First attached plot is one of the plots I used to design the filter, but I literally just used the same zpk from the HAM4 z-x filter and matched the gain to the new transfer functions. The solid blue (or purple? I'm not sure) is the  gnd Z to MCF transfer function over the HAM3 x drive to MCF transfer function. The red line is the filter I'm using at HAM4, the gold line is the filter for HAM3. The dashed line is the expected reduction. I tried several times to get the driven transfer function, looking at HAM3 x drive to IMC-F, PRCL, PRM and MC2 M3 length drives, and the filter design ended up being the same. 

The second plot shows an on/off test with only PRMI with no arms. In this state PRCL and MC both see an improvement around the microseism. The dashed lines are with the Z-X sensor correction on, solid lines are with it off. Brown and green are the ground, which didn't change during the test. PRCL went from pink to orange (about 3x lower), MCF went from red to blue (almost 4x lower). Rana doesn't like my colors, and he has a calibrated spectra, so I might post that in a bit.

If people suspect this is causing problems it can be turned off like the SRCL sensor correction at the command line with:

caput H1:ISI-HAM3_SENSCOR_GND_STS_X_WNR_GAIN 0

Patrick, Jeff K., Jim

I have created medm screens to display the ISI GND STS BLRMS for 0.03 - 0.1 Hz and 0.1 - 0.3 Hz. They are in svn under /[cds_user_apps]/trunk/isi/common/medm. I have added links to the sitemap under SEI.

The indicated ranges are as follows:

0.03 - 0.1 Hz:
Green: 0 - 200 nm/s
Yellow: 200 - 500 nm/s
Orange: 500 - 1000 nm/s
Red: 1000+ nm/s

0.1 - 0.3 Hz:
Green: 0 - 500 nm/s
Yellow: 500 - 1000 nm/s
Red: 1000+ nm/s

TITLE: 12/12 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC

STATE of H1: Commissioning

INCOMING OPERATOR: None

SHIFT SUMMARY:

16:00 (8:00) Start of shift

16:15 (8:15) Peter to Optics Lab

16:29 (8:29) Karen to LVEA

17:44 (9:44) Karen to MY, EY

17:47 (9:47) Nutsinee, Terry to HAM6

17:54 (9:54) Terry back from HAM6

18:36 (10:36) Jeff to cleaning area

18:53 (10:53) Jeff back from cleaning area

19:04 (11:04) Peter out of Optics Lab

19:24 (11:24) Karen back from MY

19:52 (11:52) Sheila to LVEA -- talk to Nutsinee about noise levels

20:11 (12:11) Sheila back from LVEA

20:14 (12:14) Robert to EX -- look for electronic noise sources

20:33 (12:33) Nutsinee back from ISCT6

21:30 (13:30) Handing off control to Ed

I have re-adjusted the low ambient hoods on the DCS Mitsubishi outdoor units. I am in contact with the Apollo/Mitsubishi, installer/supplier to try and resolve the winter time issues with this system.   

Apollo was onsite yesterday with TESTCOMM to balance the air system in the OSB HVAC,L {AHU-4}, as we were having issues with the VAVs. Many of the VAVs were consuming more air than needed leaving the end of the line users short of air flow, thus not allowing the heating elements to activate properly. 
Every VAV was readjusted to the correct air flow and all are working correctly now.  

Levels look pretty good compared to previous alogs

SudarshanK, RickS, NikoL, JeffK

Summary

We were planning to do a calibration measurement at ENDY yesterday (2018/10/11) but were not able to complete it because we used all of the allocated time implementing some planned changes and dealing with some unforeseen technical difficulties. We will go back to ENDY Thursday morning to get the calibration done.

Details:

    -  Inspected optics, beam centering, cleanliness look okay

    - New system to capture beam pointing has not been set up in TX

    - Changed RxPD port adapter  to new one (D1300106-v4), with loctite (S/N 016)

    - Changed TxPD port adapter to new one, with loctite (S/N process of elimination)

    - Removed shutter after it was unresponsive and is in the electronics lab for repair.

    - Bring blue box for next calibration because we were not able to use WSPD Mon channel on the Pcal interface because of differential output. 

   - We populated the Pcal MEDM screen to convert the Pcal signals from counts to Volts.

File attached (3.5MB) shows 48 channels side by side, during the power up from 2W to ~34W, from before (left) the PZT swap to after (right).

On page 3, you'll find the IO GigE 2 camera signals, showing the IMC_IN beam (straight shot through the bottom periscope mirror). 

Of course if you read the second plot from the top (green) it's title is  H1:LSC-REFL_A_RF9_I_OUTPUT, and so is Every Plot that's second from the top... 

Here's the real list of the plot titles/channels for each page:

• pg.1     really is H1:LSC-REFL_A_RF9_I_OUTPUT
• pg.2    H1:LSC-REFL_A_RF45_I_OUTPUT
• pg.3    H1:VID-CAM29_X
• pg.4    H1:IMC-PZT_YAW_OUTPUT
• pg.5    H1:IMC-WFS_A_DC_YAW_OUTPUT
• pg.6    H1:SUS-MC2_M3_WIT_YMON
• pg.7    H1:PSL-ISS_QPD_DY_OUTPUT
• pg.8    H1:PSL-PWR_PMC_REFL_OUTPUT
• pg.9    H1:PSL-ISS_QPD_DY_OUTPUT
• pg.10   H1:IMC-MC2_TRANS_SUM_OUT16
• pg.11   H1:IMC-IM4_TRANS_SUM_OUT16
• pg.12   H1:IMC-PWR_IN_OUT16

There are many channels that changed how they behave during the power up, and the centroid on GigE2, on page 3, was the start of my interest, where one can see that the X and Y changes during power up are quite different, and they changed, before to after the PZT swap.

After some failed attempts to install a noise eater: 

• 1 EOM (an amplitude modulator) was thermally unstable above 3mW, even though it was well within the rated max optical intensity (turns out, crystal was LiNbO3, ie not doped with Mg which seems to improve thermal stability).
• Another EOM had RF issues (a phase modulator used as an amplitude modulator with appropriate input/output polarization optics).
• Another (IR) EOM (also a PM used as AM with in/output polarization optics) rejected too much green to be useful.
• One AOM also had RF issues (and was for a wavelength of 1064 nm anyway).

we have now installed a 532 nm 200 MHz AOM from MIT.

Beam profile after this AOM looks fine (attached) with ~45 mW input power. The green pump fiber had to be realigned and again has 83+/-2% coupling efficiency to the patch panel on ISCT6 (so this fiber is fine).

However the power to SQZT6 has dropped recently and is still low, but is clearly not due to any failure of the fibre between the Green input coupler on ISCT6 and the patch-panel on ISCT6. Nutsinee will add a post with more information on this. 

as a test to see how people like it, I changed the .SMOO param on the Wind Speed monitor channels. This does some moving averaging in the server so the traces are easier to read.

This will be reverted on the next reboot, but also can be done at command line by setting the SMOO field to zero. At the moment it is 0.9. See attached plot: left side is quantized and no smoothing.

The CS channel seems to ignore its SMOO, but probably there's a way to get it to SMOO too.

Since Sunday, each day we are spending many hours waiting for DRMI to lock. As people are well aware of, the DRMI here seems to go through phases of good/bad locking. Good locking is where the acquisition time is mostly < 10 minutes. When its bad, it may be 30~60 minutes. As is usual, we sit around wondering if its "the alignment", "the wind", or the "the microseism".

In the LVEA, the common mode rejection of the slab is ~1000 at the microseism peak, so most of the 0.1-0.3 motion that we see in the DRMI comes from differential motion induced by the SEI and SUS.

As an example, I'm attaching the LSC control signals from a DRMI lock earlier tonight, compared to the ground motion. It seems like we're getting around a factor of 10 suppression for MICH/SRCL, but only a factor of 4-5 in PRCL. But actually, its probably even worse. The CAL-CS channels don't take into account the M1 offload (what is the M1 crossover frequency for the length control on SRM and PRM?).

At LLO, Arnaud is looking into some improvements to the ISI controls to make the PRC/SRC HAMs follow the BSCs better. If the main microseismic impact to DRMI locking is the PRC velocity, we would win a lot just by getting a 2x reduction at the microseism.