Reports until 20:17, Saturday 17 January 2015
H1 PSL (IOO, ISC, PSL)
sheila.dwyer@LIGO.ORG - posted 20:17, Saturday 17 January 2015 - last comment - 21:05, Tuesday 20 January 2015(16132)
PSL Noise eater oscillation

Alexa, Evan, Dan, Sheila

We have been having intermittent problems for the last two or three days.  This evening we traced the problems we've been having with ALS COMM (alog 16129 ) to an oscillation of the PSL noise eater.  The tell tale symptom was amplitude noise at around 900 kHz on the PSL light.  We don't know of a good indicator of this problem from the control room.

We do not know if this was the cause of our mode cleaner lock losses over the last few days (alog 16128 ),  or to tripping of MC1+MC3 suspensions and HAM2 ISI.  

After I toggled the noise eater switch the ISS first loop was unable to lock.  For now we have turned it off. 

We had the outputs held on the IMC WFS DOF4 from late last night until 8 pm today. We didn't see any trips of MC1+MC3 today.  Now we have turned DOF4 back on.

Comments related to this report
koji.arai@LIGO.ORG - 11:43, Sunday 18 January 2015 (16135)

I turned on the ISS first loop. For the OMC characteization, we needed some kind of ISS.

1. Changed REFSIGNAL (H1:PSL-ISS_REFSIGNAL) from -2.248 to -2.135 to match it with H1:PSL-ISS_PDA_AVG
2. Push "On" of AUTOLOCK

This allowed me to engage the ISS loop. The out of loop "lsd" monitor (H1:PSL-ISS_PDB_LSD) shows 1.2e-8/rtHz.

rana.adhikari@LIGO.ORG - 17:58, Sunday 18 January 2015 (16136)

There was recent check of the Noise Eater mon at LLO (log 13353). Wasn't that useful, but the binary NE mon is supposed to tell us when the NE loop is oscillating.

There were also numerous instances of this during eLIGO; the 'solution' then was to turn the servo OFF and then ON. Maybe if the monitor is now mistuned, we should adjust the resonant circuit to operate at 900 kHz.

sheila.dwyer@LIGO.ORG - 11:43, Monday 19 January 2015 (16137)DetChar

Apparently we do have at least two ways to tell this is happenening from the control room, which means we could have some automated error checking for it.  

First, this was already done in the PSL ODC, which seems to have degraded at least at LHO.  (alog 9674)  The PSL ODC screen now looks like the attached screen shot, I don't know what hapened to it but it might be helpfull to restore it.  

The second screenshot shows that the RF mon on the COMM PFD was around -1dBm even when the X arm was unlocked while the noise eater was oscillating.  We can add an error check for this in the COMM PLL beckhoff code.  This is similar to what we did for the end station lasers (alog 10273 )

Images attached to this comment
rana.adhikari@LIGO.ORG - 21:05, Tuesday 20 January 2015 (16172)DetChar, PSL

The attached plots show 2 weeks of the PSL Noise Eater channels as well as the ALS COMM demod mon.

NPRO_NEMON doesn't show any change and I don't know what it is connected to.

NPRO_RRO is the binary indicator of whether the NPRO Relaxation Relaxation Oscillation monitor is indicating a high noise state: around -5800 means OK, around -300 means Oscillating.

COMM DEMOD RFMON shows the non-bandpassed RF noise (in units of dBm):

-35 dBm corresponds to the bare noise on the laser without the arms locked

-1 dBm seems to be what we see with the arms unlocked an the NPRO NE oscillating

+5 dBm corresponds to the X arm locked and there's a good beat note between the green PSL and the green X trans beam

 

* the RRO indicator on the PSL screen had the threshold set too high; I've changed it to now change from green to red at -2000 counts rather than -200 (which would make it always show GREEN)

Images attached to this comment