40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log  Not logged in ELOG logo
Entry  Thu Dec 4 00:26:07 2014, Jenne, Update, ASC, POP yaw razor blade installed ASC_PRCLloop_POP22err.pdfPRC_YAW_QPDvs22_3Dec2014.pdf
    Reply  Tue Dec 9 03:34:52 2014, Jenne, Update, ASC, POP yaw razor tuning PRC_YAW_QPDvs22_8Dec2014.pdf
Message ID: 10768     Entry time: Tue Dec 9 03:34:52 2014     In reply to: 10752
Author: Jenne 
Type: Update 
Category: ASC 
Subject: POP yaw razor tuning 

With the re-do of the IFO alignment last week, I think that the beam was no longer about halfway on the POP22 razor blade.  To fix this, I locked the PRMI on sideband, removed the razor blade, and then put it back in such that it occluded about half of the light.  

I'm not entirely sure why, but when I put the razor in, POP22 went from 104(ish) to 45(ish) but POPDC  went from 5200(ish) to 1600(ish).  [The 'ish'es are because the PRC wasn't angularly stabilized, so there was some motion changing the power levels that leaked out to the POP port].  The ETMs were misaligned, so this should not be a carrier vs. sideband effect, since they'll both share the cavity axis defined by the ITMs and the PRM.  It is possible, although I didn't check, that there is some oplev light scattered into the POP photodiode that is now blocked by the razor blade.  This light would only be at DC and not the 2f frequencies.  Since the signal levels for POP22 vs. POPDC didn't change with and without the table top on (and with and without room lights on), I don't think that it is an effect of ambient light getting into the diode.  To check if it is oplev light I should (a) just look, and (b) try to lock the PRMI without the ITMX oplev laser being on to see if there is a difference in the POPDC signal.

Anyhow, under the assumption that the POP22 signal level is correct, I tuned up the PRCL ASC a little bit.  These changes are now in the carm_cm_up script, and the carm_cm_down script resets things.  Before the PRC is locked, I have FM1 and FM7 (the basic servo shape and a 40Hz lowpass) on, the gain set to zero, and the input off.  After lock is acquired, the input is turned on, and the gain ramps from 0 -> 10 in 3 seconds.  Then FM2 and FM6 (boosts at 1 and 3Hz) are engaged.

In the plot below, the dark blue and red curves were taken when there was no angular control on the PRC.  Pink was taken last week with the old QPD yaw ASC on.  Light blue is today's version of the in-loop performance of the POP22 yaw ASC loop.  I didn't save the trace unfortunately, but the DC QPD saw out-of-loop improvement between about 0.8Hz - 4 Hz. 

Also, has anything happened with the LSC rack in the last few weeks that might be causing lots of 60Hz noise? I saw these large lines last week, but I don't think I remember them from the past.

PRC_YAW_QPDvs22_8Dec2014.pdf

After I got the PRCL ASC working, I tried several iterations of locking.  ETMX is still being annoying, although the last hour or so have been okay.  CARM keeps getting rung up right around the transition to the sqrtInv error signal.  Since CARM and DARM are kind of entangled, it took me a few iterations to figure out that it was CARM that is ringing up, and not DARM.  I'm a little worried about the phase loss from the 1kHz lowpass that we turn on just before the transition to sqrtInv.  I want to keep the lowpass off until after we have transitioned DARM also over to DC transmission.  I tried once, but I lost lock before starting the CARM transition.  Anyhow, the ETM alignment issue is annoying.

Also, Jamie, Q, Diego and I were discussing last Friday, but none of us elogged, that we think there might be something wrong with one of the Martian network switches.  I'll start a separate thread about that right now, but it slows things down when you can't trust EPICS channels to be current, and I (without evidence) am a little worried that this might also affect the fast signals.

ELOG V3.1.3-