40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 63 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  8126   Thu Feb 21 12:56:38 2013 JenneUpdateCDSc1iscex dead again

c1iscex is dead again.  Red lights, no "breathing" on the FE status screen.

  8127   Thu Feb 21 13:34:35 2013 JenneUpdateTreasureIR card removed

Quote:

The sensor card on the bottom of the chamber was not salvaged yet.

 Yuta retrieved the IR card that had fallen to the bottom of the IOO chamber, just before we put on the access connector yesterday.  The clean "pickle picker" long grabber tool worked wonders.

  8145   Sat Feb 23 14:52:03 2013 JenneUpdateLSCETMYT camera back to normal

Quote:

 3. Replaced Ygreen REFL camera with ETMYT camera to see transmitted beam mode.

The camera that Yuta means in his elog from last night/this morning is the scattering camera at the Yend.  The reason (I think) that he had to do this is that Manasa and Jan took the cable for the ETMYT camera, and were using it for their scattering camera.  They mention in elog 8072 that they installed a camera, but they didn't say anything about having taken the ETMYT cable.  This is the kind of thing that is useful to elog!

Anyhow, I have removed the Watec that belongs with the scattering setup, that Yuta borrowed, and put it back on the scattering table-on-a-pedestal. I then realigned the usual ETMYT camera (that Yuta moved out of the way to install the borrowed Watec), and put the ETMYT cable back to its usual place, connected to the Sony camera's box on the floor.

tl;dr: ETMYT camera is back to original state.

EDIT later:  I put the Watec back, since it is more sensitive to IR, so now we have a Watec in the regular ETMYT place.

  8149   Sat Feb 23 16:54:24 2013 JenneUpdateLSCcan't lock Y arm

I'm not sure that Yuta had found the real Yarm flashes last night.  When I came in today, the Yarm would flash.  However I found that the SRM was aligned, and if I misaligned it, the Yarm flashes would disappear.  So somehow the beam getting into the cavity was related to the reflection off of the SRM.

Later, I moved the TTs, leaving ITMY and ETMY alone, after having misaligned SRM (and ITMX) and I found flashes.  This wasn't ideal though, since the beam was much, much too high on IPANG (beam was half falling off the top of the lens, although yaw was pretty good).  That was also when I changed out the ETMYT camera the first time around.  The flashes on the new camera were visible, but much dimmer than with the Watec.

I tried locking the Yarm in this state, but I could never achieve a lock, even momentarily.  It almost seemed like I wasn't sending actuation signal out to the coils, although signal appeared all the way through the chain until the LSC signal summed with the local damping signal.  I also switched the LSC output matrix to try actuating on the ITM, but I was also not able to lock then.  I have switched it back to have Yarm actuate on ETMY.  I could see a nice PDH signal on POY, and nice flashes on TRY, but no lock at all.  The trigger was triggering, but still no catching of the lock.  I'm not really sure what's up.

After playing with a non-locking, poorly aligned Yarm, I started over by recentering the beam on IPPOS and IPANG using the TTs, but have not been able to get flashing in the cavity again.  After much fitzing around, I put the Watec back at ETMYT, in hopes that we can see flashes again at some point, since it's more sensitive than the old Sony.  Still no flashes though.

I have to leave, but Yuta and Manasa are here, and so I'm leaving the IFO in their custody.

  8163   Mon Feb 25 22:30:40 2013 JenneBureaucracyGeneralaction items for PRFPMI

 

 CDS:
    - Check out ASS and A2L working -JENNE
    - Are all whitening filters for PDs toggling correctly? -JENNE, JAMIE

PRMI locking:
    - Adjust I/Q rotation angles for error signals -JENNE, YUTA
    - Adjust filters -JENNE, YUTA
    - Coil balancing for BS (and ITMs/ETMs) -YUTA

PRC characterization in PRMI:

    - Measure PR2 loss from flipping -MANASA
    - Measure mode matching ratio -JENNE, YUTA
    - Measure finesse, PR gain -JENNE, YUTA
    - Calibrate PRM and/or ITM oplevs -MANASA, YUTA
    - Measure g-factor by tilting PRM or ITMs -JAMIE, YUTA
    - Calculate expected mode matching ratio and g-factor -JAMIE
    - Calculate expected finesse, PR gain -JENNE
    - Mode match and align aux laser into AS port -EVAN

ALS:
    - What's the end green situation? Optical layout changed? Laser temperature in CDS? -MANASA
    - What's the PSL green situation? Green trans cameras/PD? Design better layout -ANNALISA
    - Make ALS handing off to DARM/CARM LSC script -JENNE, YUTA
    - Demonstrate FPMI using ALS -JENNE, YUTA
    - Phase tracker characterization -YUTA, KOJI

PRFPMI:
    - Measure mode matching between PRC and arms -JENNE, YUTA
    - Measure PR gain -JENNE, YUTA
    - Calculate expected finesse, PR gain -JENNE

Others:
    - Update optical layout CAD after PR2 flipping -MANASA
    - IMC REFL demod phase rotation -EVAN, ANNALISA
    - Look into PMC drift -JENNE, MANASA
    - Measure RFAM contribution to error signals -YUTA

  8165   Tue Feb 26 01:49:27 2013 JenneUpdateLockingPRMI locked

[Jenne, Yuta]

We began the evening, after alignment of all optics was good (arms flashing, PRC flashing, assumed SRM last saved alignment was okay), centering all oplevs and aligning beam onto AS55, REFL11, REFL55 and REFL33 and POPDC.

After a quick check to make sure that the input pointing was still okay for Yarm (TRY was 0.88 when we began PRMI work, which we called okay), we aligned and locked the Michelson with AS55Q.  We were able to use a gain as large (abs val) as -15 before the loop started oscillating.  (ETMs, PRM, SRM all misaligned during this).  We measured the UGF of the MICH loop to be 170Hz, with phase margin of 40 degrees.

We then restored the PRM, and tweaked the pointing until the PRC beam at AS overlapped the MICH beam. 

We then started playing with locking.  We were not very successful in using REFL 11 or REFL 55 (I for both, although we also tried 11Q just for kicks).  We then switched to using REFL33I, and had success!!  We are reliably able to lock to the "sideband", and not so reliably lock to the carrier (by flipping the sign of the PRCL loop gain). I say "sideband" with quotes, since we aren't sure that it is the sideband.  We are, however, confident that it is locking, and it's certainly not locked to the carrier.  Videos are at the bottom of the entry.

A list of some values:

Camera state MICH gain PRCL gain POP DC AS DC REFL DC
AS bright, POP bright -0.045 -4.000 1000 +/- 200 4 +/- 0.5  480
AS dark, POP bright  -0.045  +4.000  300 +/- 20  0.03 +/- 0.02  552 +/- 2
AS, POP flashing  loop off  loop off  flash 25,000 or more  ~5  ~550

 

Other notes:  We changed AS55's demod phase back to 24.5, from it's atmosphere half-cavity value.  The change from the original value was recorded in elog 8030.

We changed REFL11's demod phase back to 150, which is the value that it was when we had PRMI locked on ~July 10th, 2012.  (We looked up the burt snapshot to check).

 

FI back, upper right is POP, lower left is REFL, lower right is AS.  It seems as though we may need to redo coil balancing now that we're at vacuum / with the current OSEM values.

  8171   Tue Feb 26 15:32:47 2013 JenneUpdateLockingFPMI locked

Quote:

P.S. TRX seems to be moving less on the camera because of the oplevs centered and working from last night.

 Ah, yes.  I forgot to mention in my elog last night that Yuta and I found that the ITMX oplev servo had been on, even though the oplev beam was blocked, so ITMX was noisier than it should have been.

  8175   Wed Feb 27 00:08:43 2013 JenneUpdateIOOMeditations on converting TT channels to be more SUS-like

Jamie and I have had a few back-and-forths on this, but I wanted to write down my thoughts on the parts of the SUS infrastructure that we need for the active tip tilts.

I think we want the ASC pitch and yaw filter banks.  I also think we want to change the channel names so that they are C1:SUS rather than C1:IOO, to make scripting easier.  A corollary to this is that we should make the DC bias sliders have the same naming structure as the regular suspensions (C1:SUS-TT#_{PIT/YAW}_COMM).  This makes scripts like the save/restore scripts easier.  If we keep the IOO naming, it would still be convenient to add the _COMM.

I am having trouble imagining what we might want the lockins for, so I propose we leave them out.

Do we want the output matrix (PIT/YAW -> coils) to be a filter bank matrix?  If we want f2a filters, we need to change this to a filter bank matrix.

I also think we want a master on/off switch for the AC actuation (ASC stuff).  We don't have sensors, so we won't have watchdog-ing, but it might be useful to have a 'panic' switch.  Perhaps though if we are careful to set limits on the ASC filter banks, we won't ever have a panic about actuating too hard.

I'm think I'm joining Jamie's side in the medm screen debate....I think we want a separate TT_SINGLE screen, laid out similar to the SUS_SINGLE, but without all of the irrelevant parts.

EDIT:  Yuta just pointed out to me that right now, the TT DC bias sliders are not recorded anywhere (_DQ, conlog,...).  We *must* fix this.

  8176   Wed Feb 27 00:56:01 2013 JenneUpdateASSMotivation for reactivating the ASS

I am putting a little bit of brain power into reviving the ASS, and I want to write down what the motivation is, and what the short and long-term plans are.

Why?

The IFO IR is not optimally aligned right now.  While we were at atmosphere, we should have taken the time to align the green beams to the arms until the greens were both resonating TEM00.  We were lazy, and excited to pump down, so we decided that locking on higher order modes was good enough to ensure the beams came out of vacuum.  Once we were pumped down, ITMY and ETMY were aligned to the green beam axis.  Then, the IR was aligned to this new Yarm cavity axis.  This would have been okay, and pretty close, if we had aligned the green beam all the way (used only the outside steering mirrors to resonate TEM00, after the cavity mirrors were aligned for flashing IR).  After the IR was aligned to the Ygreen axis, the rest of the IFO was aligned to this slightly-incorrect input pointing.  We want to measure the IR spot positions on ITMY and ETMY so that we can tweak the input pointing until we hit the center of both ITMY and ETMY.  Then we will align Ygreen's input pointing to this proper IR cavity axis.  The rest of the IFO alignment will also have to be redone.  This calls for a functioning A2L system, so the measurement part of the ASS.

The immediate motivation for measuring the spot positions is that the current Xarm IR axis is not at all very close to the Xgreen axis.  The other day while we were fixing up the Xend table (note in elog 8162), we found that the TRX beam to the TRX PD and the trans camera was clipped on the 2" harmonic separator (which is the first optic that the transmitted IR beam sees on the end tables).  It was clipping on the left side of the optic, if you are looking at the face of the optic.  This is the more east-erly side of the optic.  We moved that optic to the side so that we were not clipping.  Then, today when Manasa was trying to align the Xgreen beam, she found that it was clipping on the right side of the harmonic separator, the more west-erly side.  I remember seeing that the green beam was roughly centered on the harmonic separator when we were at atmosphere, so this clipping is certainly due to Yuta, Evan and my moving of the harmonic separator.  Since the end green steering optics are not very orthogonal in angle/translation, it is very difficult to translate the beam by a significant amount.  If we keep the current IR alignment, which surely isn't good anyway (you can see on the ETMXF camera that the beam isn't centered), we would probably have to move the Xgreen steering optics, which would be a total pain.  It seems that the better plan is to leave them where they are, and get the IR pointing in the correct direction, and move the harmonic separator back to where it was originally.

Short term (< few days):

Write the arm section of the existing MeasureSpotPositions.py script (in ....../scripts/ASS).  Write a wrapper script that, like ...../scripts/ASS/MC/mcassMCdecenter, calls sets up the lockins, runs MeasureSpotPositions.py, and calculates the calibrated spot positionsUse this information to hand tweak the input pointing, then realign the cavities to the new IR, and the greens to the new cavity axes.

All of the infrastructure for this is already in place in the c1ass model.   The only drawback to the current situation is the LSC output matrix only has one row for ASS, and so only one cavity can be measured at a time.  To make things faster, we could consider increasing the size of the LSC output matrix so that the 2 arms could be measured simultaneously.  This change is low priority for now.

Long term:

Make the full ASS system work. 

A major change from the current situation is that the current ASS cannot actuate on the input pointing (TT1 and TT2 for Yarm, BS for Xarm).  We want a low bandwidth servo to force the input beam to follow the cavity axis.  Implementing this will require some changes to the ASS model. 

Remeasure sensing matrix, test system.

  8178   Wed Feb 27 02:21:55 2013 JenneUpdateASSMotivation for reactivating the ASS

I have modified the MeasureSpotPositions.py script to accept the arms as valid cavities (it used to give an error "Sorry, this only works for MC right now").

There is still no wrapper script to turn on lockins and turn them off after the measurement, so I have not tested the arm A2L yet.  But I should be able to tomorrow, or whenever the IFO is next available.

To-do:

* Write the wrapper script (analog of mcassMCdecenter).

* Fix arm assOff, assDown, assOn, assUp scripts to match the current channel names (which were changed long ago to be human-readable, versus mysterious numbers).

* Test.

  8179   Wed Feb 27 02:44:39 2013 JenneUpdateLockingDRFPMI flashes

Before Yuta left, I asked him to restore all optics to last saved values, to avoid hysteresis.

Some interesting modes appear at ETMYT and ETMXT.  The cavities aren't super well aligned right now, especially since we have been seeing this input pointing drift, but it's cool to see our first DRFPMI flashes. SRM, in particular, hasn't been aligned since before pumpdown.  If I misalign SRM, the mode content at the trans cameras improves somewhat, but it still isn't all low-order modes.

 

Here is the note that I wrote on youtube describing the video:

DRFPMI Flashing

Upper left is AS, upper right is POP
lower left is Xarm Trans (ETMXT), lower right is Yarm Trans (ETMYT)

Arms were last aligned several hours ago, and we know input pointing drifts, so at least some of the higher order modes in the arm transmissions are due to poor input pointing. All optics are "restored" to their last saved values, including SRM, which has not been aligned since before pumpdown.

TRX DC PD values are flashing to as high as 10
TRY DC PD values are flashing to as high as 7

Since uploading the video, I have seen TRY flash (once) to 45.  Yes, forty five!!!  Both arms are usually flashing to ~3ish, with an occasional medium flash (5-10), and then a few rare TRY flashes above 20.

We may have officially lost the bet of having arms locked by 9am Monday, but I think Team Grad Student / Postdoc still deserves some beer from Team Faculty / Staff.

  8180   Wed Feb 27 02:52:40 2013 JenneOmnistructureSAFETYBack door unlocked

Did someone unlock the back door by the (unofficial) bike storage lately?  Out of habit, I checked the door behind me while about to leave, and it is unlocked. 

Please recall that if you leave through that door, it should automatically lock behind you (if it was locked already), however if you unlock and enter through the back door, it stays unlocked until someone locks it again.

(Obviously, I'm locking the door before I actually go).

  8202   Thu Feb 28 14:51:43 2013 JenneUpdatePEM"Rock Monster" causing low frequency noise

Manasa and I have been wondering why the low frequency seismic noise has been different in the last few days/weeks.  I went over to visit the Rock Monster, a.k.a. the Earth Surface Dynamics Laboratory next door, and the grad student turned it up for me (increased water flow significantly) for a few minutes.  Then I came back to look at the BLRMS, and you can see the low frequency increase a few minutes ago, when he turned it up on high.  He said that they run it on low almost all the time, 9am-5pm ish, and on high for an hour or so at a time periodically during the day.

RockMonsterOn_ForFewMinutes.png

  8203   Fri Mar 1 01:17:06 2013 JenneUpdateLSCXarm oscillation

There is an oscillation in the Xarm at 631Hz, which is not in the Yarm.  There is a small peak in POY11_I at this frequency, but only when the Xarm is locked.  If the Xarm unlocks, the peak disappears from POY.  The peak is 3 orders of magnitude larger in POX than in POY, and 4 orders of magnitude larger than the POY noise when this peak is not present.  In the plot, I have turned off the POY whitening, so that its situation is the same as POX (we still need to fix POX whitening switching).  Dark noise (MC unlocked) is the same for both PDs.

POX11_630Hz_osc.pdf

  8204   Fri Mar 1 02:49:34 2013 JenneUpdateASSArm A2L measurement

I haven't finished debugging the scripts so that the measurement is fully automatic, like the MC, but I did measure the arm spot positions just now. 

These numbers aren't especially precise....I just picked numbers off of a StripTool plot, but they give us a good idea of how very far off we are.  Also, I don't know yet which way the signs go...I have to think about that in terms of the direction I mis-balanced the coils.  It's the same convention as the MC though.  You can see in the attached quad camera image (quadrants match the corners of the table) that these numbers aren't unreasonable.

ETMY   ETMX  
Pit 4 mm Pit 4 mm
Yaw -1.5 mm Yaw 6 mm
ITMY   ITMX  
Pit -3 mm Pit -3 mm
Yaw 4 mm Yaw -4 mm

QUAD1_1046168242.bmp

EDIT: It occurs to me now, a little later, that it had been at least half an hour since I last realigned the cavities, so some of this apparent miscentering is due to the input pointing drift. That doesn't account for all of it though. Even when the cavities have very high transmitted power, the spots are visibly miscentered.

  8215   Sun Mar 3 22:16:46 2013 JenneUpdateLSCLSC whitening triggering started

[Jenne, Annalisa]

We have started working on writing the c-code to parse the LSC input matrix, to see which PD is used for what degree of freedom, and to output a trigger for the PD.  The code is in ..../isc/c1/src, and there is a little block in the LSC code to the left of the triggering stuff.  Right now, the output of the c-code just goes to some temporary EPICS channels, so that we can see if things are working before we actually implement it.  At this time, there is no change to how the LSC model runs.

I can't figure out a bug in my c-code though.  Right now it's all commented out, so that the LSC model would start, but if I try to sum all of the elements in an array, the model compiles fine, but it won't start running.  I'm going to ask Jamie about it tomorrow.  I have a less-tidy backup plan if we can't get this figured out.

If I have time on the IFO to check that this works tomorrow, I expect another few hours of work (2?  3?), and then we'll have whitening filter triggering.

  8229   Tue Mar 5 01:43:04 2013 JenneUpdateASSArm A2L measurement script finished

In either .../scripts/XARM or ...../scripts/YARM run either A2L_XARM or A2L_YARM.

The wrapper script will, like the MC script, open a striptool so you can monitor the lockin outputs, setup the measurement, run the measurement, including misbalancing coils on the optics for calibration, and then calculates the spot positions.  It records the measurement in a log file in /data_spotMeasurements under each arm's directory.  The wrapper script then runs the plotting script which reads the logfile, and plots all past measurements.

Here is that plot for the Yarm:

YARMdecenter.png

The first two points were measured within a few minutes of eachother, the third set of points was after input pointing adjustment during IFO alignment.  Clearly the pointing that optimized the cavity transmission (trying to leave the test mass mirrors alone, and only moving TT1 and TT2) does not also give the best spot centering.  I claim that this is a result of the arm being aligned to the green beam, which was never locked to the 00 mode when we were at air.  This is a lesson learned....take the time to deal with the green beams.

  8234   Tue Mar 5 18:36:27 2013 JenneUpdateLSCLSC whitening triggering started

More effort at debugging the LSC whitening. 

Today I tried moving things over to the c1tst model, which runs on the y-end computer, but I crashed c1iscey.  I rebuilt the TST model to a known good state, then cycled the power on c1iscey, and the computer came back up fine. 

I have now backed off and am just writing the code inside a little wrapper script, so that I can just compile and test the code completely independent from the realtime system.  Then once I get all the bugs out, I can try again installing on the actual system.

Still, there are no changes to the functionality of the c1lsc model.  There will not be until I get the c-code for matrix parsing debugged.

The logic, in non-diagram form (I'll make a diagram, but so you can read without waiting):

*** C-code

* Inputs is an array of degree of freedom triggers, the same schmidt triggers used for main LSC locking. (This means it also uses the same thresholds as main triggers.  Side note, now that the WAIT command (see below) works, I want to change the filter module triggers to use the same main trigger, and then just wait a specified time before turning on.)

* Parse the LSC input matrix (internal to the c-code).

     * This tells you which photodiode is being used to control which degree of freedom.

* Multiply rows of the LSC input matrix by the degree of freedom triggers (the same trigger as the main LSC triggers, which is a schmidt trigger).

     * This gives a matrix, where non-zero elements indicate that a photodiode is supposed to be used for a degree of freedom, AND that DoF has been triggered (is locked or has flashed).

* Sum along the columns of the matrix.

     * If a column has a non-zero element, that means that that PD quadrature is used, and has been triggered (by any DoF).

* Apply OR to I and Q quadratures of each PD. 

      * Since the phase rotation happens after whitening and dewhitening, if either I_ERR or Q_ERR is requested (used and triggered), we need to turn on the whitening for both channels.  I am hopeful that this doesn't cause problems for cases when we want to use both quadratures of a PD to control 2 degrees of freedom, but I haven't yet put much thought into it.  COMMENTS WELCOME on this point.

*  Output of c-block is array of PD triggers.  So if either AS11I or AS11Q is triggered, output a "1" for the first element, which corresponds to AS11, etc.

*** LSC model

* Give GoTo/From flag for each DoF trigger to the mux of inputs.

* Go through c-code

* Demux outputs into GoTo/From flags, one per PD (one flag for AS11, one for AS55, and one for ASDC...DC elements count separately, even though they're derived from the same physical PD).

* For each PD, trigger flag goes through WAIT c-code

   * This allows you to define a wait time, in seconds, with an EPICS variable. 

   * Starts counting the wait time as soon as it receives a "1".  Resets counter each time it receives a "0".

    * Output of wait function is ANDed with the current (non-delayed) trigger.

         * This allows for cavity to flash, but if it's not still locked after the wait time, don't actually flip any switches.

* Use delayed ANDed trigger to flip the FM1 switch on both the I and Q filterbank for that PD.

  8246   Wed Mar 6 21:58:39 2013 JenneUpdateElectronicsPOX whitening was fine all along

After my investigations this afternoon (with help from Sendhil and Shivaraj), I do not find any problems with the POX whitening switching.

Earlier this afternoon / evening I was misleading myself into thinking that either the switching component (ADG333ABR) was broken, or that the whitening op amps (LT1124CS8) were broken on the POX I&Q and POY I&Q channels.  I had not realized until Jamie mentioned the possibility, that some of the DC gain stages were on for POX and POY.  POX and POY (I&Q for both) all had +36dB of gain, so when I was injecting my 60Hz sine wave into those channels, the whitening opamps were already saturated, which is why it didn't look like I was getting any gain.  When I set them all to 0dB (which is what AS11 and REFL11, the other 2 PDs using that whitening board, were set to), all 8 channels behaved the same.

The shaped whitening (which is either bypassed or not, depending on the condition of the software "unwhite" switch) is 2 filters in series, each with a zero at 15Hz, and a pole at 150Hz, with DC gain of 0dB.  For a 60Hz sine wave, this gives a factor of ~4 from each stage.  After setting all of the whitening gains to 0dB, I was able to see on all 8 channels of the board an input sine wave, a larger (by 4-ish) sine wave, and then a larger (by 4ish again) sine.  When I looked at the output of the switch of all 8 channels, the signal was either the same as the input amplitude, or the same as after the 2nd whitening stage, depending on the "unwhite" filters.

Before looking at actual signals, Sendhil and I also had checked to see that indeed, the board was receiving the digital signal input to the switch chip, requesting switching based on the state of the "unwhite" filters.

I looked through the elogs, and the only "symptoms" I find are from an IFO check-up session that Koji, Den and I had back in May, where we declared in the elog that POX whitening may or may not be switching.  See elog 6595.  We didn't mention what the actual symptoms we saw were, so unless Koji or Den remember something that I don't, I cannot confirm that we are no longer seeing those symptoms.  However, based on the number of "?" after "POX whitening not toggling the analog whitening", I don't think that we were totally sure that something was wrong in the first place.

Anyhow, the whitening board in the LSC rack labeled "WF1", serving AS11, REFL11, POX11 and POY11 has had a thorough checkup, and I give it a clean bill of health.

  8249   Thu Mar 7 11:43:15 2013 JenneUpdateElectronicsPOX and POY whitening DC gain left low

Manasa and Jan were having trouble locking the Yarm, and asked me to take a look at it.  After a good long time of trying to figure out what was going on, it finally occurred to me that I did not turn the DC gain on POX and POY back to the nominal 36dB.  As soon as I did that, both arms acquired lock.  Ooops.

  8250   Thu Mar 7 12:39:12 2013 JenneUpdateLockingErudite discussion on PRMI locking

[Rana, Jenne, Yuta] (late last night)

After some trouble getting the PRMI to lock with REFL55 I&Q last night, we began to think about the size of signals everywhere, and the coupling of the sidebands in the different cavity configurations.  We have determined that it is possible that the Q phase signal is too small everywhere, so the PRMI will never be easy to lock. The Q phase will be smaller than iLIGO equivalents since the modulation frequencies are lower, and we have a small Schnupp asymmetry. The calculations of signals at each port were all done for the DRMI case, where sidebands get recycled more, so signals get larger.  If locking the PRMI is "hopeless" due to very small signals, we should stop trying, move on with other things, and come back to the corner when we have the DRMI ready. In order to figure out if it is reasonable to keep working on the PRMI, we must calculate the size of all of our signals at each port, and convert them into real units (if we expect a 1mVpp signal at REFL11Q, we're not going to successfully lock MICH with that).

So, we should:

* Calculate sideband signals at AS and REFL, for 11 and 55 MHz, for the PRMI case.

* Convert those signals into physical units (Watts -> Amps -> Volts).

* In parallel, work on dual arm ALS, and FPMI locking.

   * Try using ALS CARM for frequency stabilization.

   * Hand off from ALS CARM and DARM to PSL.

* To do ALS-FPMI, we should:

     * Use A2L to center the IR spots on all arm cavity mirrors.

     * Align green beams to the arms.

    * For each arm, determine which frequency (arm green or PSL green) is higher.

          * Lock the arm in green, align Beat PD. 

          * Push ETM, watch beat in the phase tracker.

          * Repeat for other arm.

     * Use ALS input matrix to construct CARM and DARM signals.

         * Check by shaking ALS-CARM, watch both X and Y beat signals - if they move in the same direction, we were right, but if they move in opposite directions we have flipped CARM and DARM.

    * Send the ALS-CARM signal to MC2, or the analog common mode board.

  8253   Thu Mar 7 18:41:03 2013 JenneUpdateElectronicsPOX whitening was fine all along

Here are the transfer functions that we took back in 2011 (see elog 4915 and replies) for POX:

POX11I.png

POX11Q.png

The table of all whitening filter zpk values is on the wiki: https://wiki-40m.ligo.caltech.edu/Electronics/WhiteningFilters

  8258   Fri Mar 8 13:42:35 2013 JenneUpdateABSLBS installed on ITMY table

Re:  POY beam reduction.

We are able to lock the Yarm with the beam / gain as it is.  I had thought we might need to increase the DC gain in the whitening board by a factor of 2, but so far it's fine.

  8260   Fri Mar 8 16:02:52 2013 JenneUpdateAlignmentGetting closer to beam centering on Yarm

I'm working on getting the input beam centered on the Yarm optics.  To do this, I measured the spot positions, move the tip tilts, realign the cavity, then measure the new spot positions.  While doing this, I am also moving the BS and Xarm optics to keep the Xarm aligned, so that I don't have to do hard beam-finding later.

Here is the plot of spot measurements today.  The last measurement was taken with no moving, or realigning, just several hours later after speaking with our Indian visitors.  I'm closer than I was, but there is more work to do.

YARMdecenter_zoom_8Mar2013.png

  8268   Mon Mar 11 14:10:05 2013 JenneUpdateEnvironmentMC suspensions moved by this morning's earthquakes

None of the suspensions All suspensions were tripped (edited by Manasa; see elog 8271) by this morning's earthquakes, but the MC suspensions are in a different place than they were a day ago.  The big symptom here is that the MCWFS are pulling the mode cleaner slightly out of alignment.  When it first locks, the reflected light is ~0.5, but when the WFS are engaged it goes up to ~0.8.  I'm going to put the MC optics back where they were (according to SUSpit and SUSyaw), and tweak up the MC from there. Probably other optics are affected, but I was going to work on continuing to center the beam on the Yarm optics, so I'll deal with the rest of the IFO in a minute.

Note re: lower plot - the mxstream was down on c1sus and c1ioo, so no fast channels on those computers were recorded for almost a day.  (The plot is one day 4 days long).  I was going to plot the seismic blrms along with the suspension pointing values, but there's no data saved, so there's no point.  Jamie tells me he thinks this spontaneous loss of the mxstream is fixed in the next RCG upgrade, and that we can talk about upgrading the RCG after the LSC meeting, so this data loss is no longer an issue.

EQ.png

MC-SUS-kicked-EQ.png

EDIT:  Plot with 4 days of trend, rather than just 1.  The MC alignment (as measured by MC refl) has been very bad for several days.  I'm going to move the suspensions back to their last good place.  Also, Manasa realigned the MC after the EQ, so I don't actually know where the suspensions got kicked to this morning.

  8269   Mon Mar 11 15:52:46 2013 JenneUpdateIOOMC spots centered, WFS realigned

Looking more into the MC, it appears that no spot centering was done after the power attenuation optics were removed (see elog 8142).  Since Manasa had changed the zig-zag steering after putting in the attenuation optics (elog 7843) the pointing was not correct for the nominal MC.  This is (likely) why Yuta and Manasa found some significant decentering.  If Manasa's tweaks when preparing for vent were primarily in yaw, then this is most definitely what happened.  A note, this is why we should change to inserting the attenuation optics before the PMC, but even so, one should adjust the angle of the PBS, NOT the zig zag optics, to get the input pointing back to the same place.  This is also why it is useful to ensure the attenuation optics do not block the PSL pointing QPD pickoff, so it is easier to adjust the PBS to get back to the original pointing.

In any case, I touched the last zig-zag mirror in yaw today (the top of the knob was moved away from me) to recenter the spots.

MCspots_11Mar2013.png

With the MC unlocked, I centered the WFS.  Now the MC is back to its normal working condition....WFS are on, autolocker is on, reflected DC power is low, etc., etc.

  8272   Mon Mar 11 19:01:21 2013 JenneUpdatePEMproposed seismometer locations

This is my interpretation of where Steve is proposing to place the seismometers (he wrote ITMX southwest, but I'm pretty sure from the photo he means southeast).

I think his point is that these locations are on the less-used side of the beam tube, so they will not be in the way.  Also, they are not underneath the tube, so we will not have any problems putting the covers on/taking them off.

 

 

SeismometerProposedPositions_11March2013.pdf

  8274   Tue Mar 12 00:35:56 2013 JenneUpdateComputersFB's RAID is beeping

[Manasa, Jenne]

Manasa just went inside to recenter the AS beam on the camera after our Yarm spot centering exercises of the evening, and heard a loud beeping.  We determined that it is the RAID attached to the framebuilder, which holds all of our frame data that is beeping incessantly.  The top center power switch on the back (there are FOUR power switches, and 3 power cables, btw.  That's a lot) had a red light next to it, so I power cycled the box.  After the box came back up, it started beeping again, with the same front panel message:

H/W monitor power #1 failed.

Right now the fb is trying to stay connected to things, and we can kind of use dataviewer, but we lose our connection to the framebuilder every ~30 seconds or so.  This rough timing estimate comes from how often we see the fb-related lights on the frontend status screen cycle from green to white to red back to green (or, how long do the lights stay green before going white again).  We weren't having trouble before the RAID went down a few minutes ago, so I'm hopeful that once that's fixed, the fb will be fine. 

In other news, just to make Jamie's day a little bit better, Dataviewer does not open on Pianosa or Rosalba.  The window opens, but it stays a blank grey box.  This has been going on for Pianosa for a few days, but it's new (to me at least) on Rosalba.  This is different from the lack of ability to connect to the fb that Rossa and Ottavia are seeing.

  8275   Tue Mar 12 00:45:50 2013 JenneUpdateIOOMC weird again

~20 minutes ago, maybe right around the time the fb's RAID died (elog 8274) the mode cleaner started behaving weirdly again.  The reflected value is very high, even with the WFS on.  Earlier this evening, I saw that with the WFS off, the MC reflection was high, but the WFS brought it back down to ~0.7 or 0.8.  But now it's ~1.3.  With the WFS off, the reflected value is ~1.1.  I don't really understand.

Also, the PMC has been drifting in alignment in pitch all day, but a lot more later in the day. The PMC trans is 0.800 right now, but it was as high as 0.825 today, and spent most of the day in the high 0.81xxx range today.

I would provide plots, but as mentioned in elog 8274, we can't get data right now.

  8277   Tue Mar 12 11:49:18 2013 JenneUpdateIOOMC weird again

[Manasa, Annalisa, Jenne]

The MC wasn't locking on TEM00 this morning, and the WFS kept pulling the MC out of alignment.  The MC was realigned, and the WFS spots are back to being roughly centered (all of this only touching the MC sliders), but the WFS keep doing bad things.  They're okay, and improve the alignment slightly at first, but as soon as the FM1 integrator comes on, the MC alignment immediately starts going bad, and within a second or so the MC has unlocked.

The WFS are off right now, and we'll keep investigating after LIGOX.

  8279   Tue Mar 12 14:02:22 2013 JenneUpdateAlignmentBeam drift - mystery partially solved?

Steve just told those of us in the control room that the custodian who goes into the IFO room regularly steps on the blue support beams to reach the top of the chambers to clean them.  Since we have seen in the past that stepping on the blue tubes can give the tables a bit of a kick, this could help explain some of the drift, particularly if it was mostly coming from TT2.  The custodian has promised Steve that he won't step on the blue beams anymore.

This doesn't explain any of the ~1 hour timescale drift that we see in the afternoons/evenings, so that's still mysterious.

  8281   Wed Mar 13 02:48:13 2013 JenneUpdateIOOMC all better

Koji reminded me (again....this is probably the  2nd or 3rd time I've "discovered" this, at least) that the script

..../scripts/MC/WFS/WFS_FilterBank_offsets

exists, and that we should use it sometimes.  See his elog 7452 for details. 

 

Notes about using this script:

* Only use it after MC has been very well aligned.  MC REFL DC should be less than 0.5 when the MC is locked (with the DC value ~4.5 with the MC unlocked, as usual).  This is hard to achieve, but important.  Also, check the MC spot centering.

* With the WFS servo off, but the MC locked and light on the WFS diodes, run the script. 

  8290   Wed Mar 13 21:04:37 2013 JenneUpdateGreen LockingPSL green cleaned up

Both X and Y green are aligned such that the arm beams hit the broadband PD.  Also, the 4th port of the combining BS for each arm was used to put a camera and DC PD for each arm.  So, ALS-TRX and ALS-TRY are both active right now.  The camera currently labeled "GRNT" is the Ygreen transmission.  I have a camera installed for Xgreen transmission, but I have not run a cable to the video matrix.  For now, to speed things up, I'll just use the GRNT cable and move it back and forth between the cameras.

  8291   Thu Mar 14 04:20:54 2013 JenneUpdateGreen LockingYbeat attempt

I dedicated my evening to trying to get the Ygreen beatnote (the idea being to then get the Xgreen beatnote).

First up was tweaking up the green alignment.  Per Yuta's suggestion, elog 8283, I increased the refl PD gain by 2 clicks (20dB) to keep the lock super stable while improving the alignment.  After I finished, I turned it back to its nominal value.  I discovered that I need lenses in front of the DC PD (for Ygreen, and I'm sure Xgreen will be the same).  The beam is just barely taking up the whole 2mm diode, so beam jitter translates directly to DC power change measured by the diode.  I ended up going just by the green transmission camera for the night, and achieved 225uW of Ygreen on the PSL table.  This was ~2,000 counts, but some of the beam is always falling off the diode, so my actual counts value should be higher after installing a lens. 

I then opened up the PSL green shutter, which is controlled by the button labeled "SPS" on the shutter screen - I will fix the label during some coffee break tomorrow.  Using my convenient new PSL green setup, removing the DC PD allows the beam to reflect all the way to the fuse box on the wall, so you can check beam overlap between the PSL green and the arm green at a range of distances.  I did this for Ygreen, and overlapped the Ygreen and PSL green. 

I checked the situation of the beat cabling, since Jamie has the beatbox out for whitening filter modifications tonight.  In order to get some signal into the control room, I connected the output of the BBPD amplifier (mounted on the front of the 1X2 rack) directly to the cable that goes to the control room.  (As part of my cleanup, I put all the cables back the way I found them, so that Jamie can hook everything back up like normal when he finishes the beatbox.) 

I then started watching the signal on the 8591E analyzer, but didn't magically see a peak (one can always hope....).

I decided that I should put the offset in the Y AUX laser slow servo back to the value that we had been using for a long time, ~29,000 counts.  This is where things started going south.  After letting that go for a minute or two, I thought to go check the actual temperature of the laser head.  The "T+" temperature on the controller read something like 42C, but the voltmeter which reads a voltage proportional to the temp (10C/V) was reading 5.6V.  I immediately turned off the offset, but it's going to take a while for it to cool down, so I'll come back in the morning.  I want the AUX laser to be something like 34C, so I just have to wait.  Ooops.

Still to do (for the short-term FPMI):

* Find Y beatnote.

* Align Xgreen to the arm - it's still off in pitch.

* Align Xgreen and PSL green to be overlapped, hitting the BBPD.

* Find the X beatnote.

* Reinstall the beatbox.

* Use ALS to stabilize both arms' lengths.

* Lock MICH with AS.

* Look at the noise spectrum of AS - is there more noise than we expect (Yuta and Koji saw extra noise last summer), and if so, where does it come from?  Yuta calculated (elog 6931) that the noise is much more than expected from just residual arm motion.

* Write a talk.

  8293   Thu Mar 14 13:38:29 2013 JenneUpdateGreen LockingPSL green cleaned up

I ran a cable to the GTRX camera.  It is now input #2.  The videoswitch script input naming is modified to match this:  Input 2 used to be "IFOPO", and is now "GTRX".  Input 28 used to be "GRNT", and is now "GTRY".  Both green trans cameras are available from the video screen.

  8294   Thu Mar 14 16:41:48 2013 JenneUpdateGreen LockingYarm ALS laser is funny / dying

Quote (elog 7002, 23July2012):

Jamie and I were doing some locking, and we found that the Yarm green wasn't locking.  It would flash, but not really stay locked for more than a few seconds, and sometimes the green light would totally disappear.  If the end shutter is open, you can always see some green light on the arm transmission cameras.  So if the shutter is open but there is nothing on the camera, that means something is wrong.

I went down to the end, and indeed, sometimes the green light completely disappears from the end table.  At those times, the LED on the front of the laser goes off, then it comes back on, and the green light is back.  This also corresponds to the POWER display on the lcd on the laser driver going to ~0 (usually it reads ~680mW, but then it goes to ~40mW).  The laser stays off for 1-2 seconds, then comes back and stays on for 1-2 minutes, before turning off for a few seconds again.

Koji suggested turning the laser off for an hour or so to see if letting it cool down helps (I just turned it off ~10min ago), otherwise we may have to ship it somewhere for repairs :( 

 This is happening again to the Yend laser.  It's been fine for the afternoon, and I've been playing with the temperature.  First I have been making big sweeps, to figure out what offset values do to the actual temperature, and more recently was starting to do a finer sweep.  Using the 'max hold' function on the 8591, I have seen the beat appear during my big sweeps.  Currently, the laser temperature measurement is at the Yend, and the RF analyzer is here in the control room, so I don't know what temp it was at when the peaks appeared.

Anyhow, while trying to reaquire lock of the TEM00 mode after changing the temperature, I find that it is very difficult (the green seems misaligned in pitch), and every minute or so the light disappears, and I can no longer see the straight-through beam on the camera.  I went down to the end, and the same symptoms of LED on the laser head turning off, power out display goes to ~40mW, are happening.  I have turned off the laser as was the solution last time, in hopes that that will fix things.

Manasa has done some work to get the Xgreen aligned, so I'll switch to trying to find that beatnote for now.

  8297   Thu Mar 14 20:22:33 2013 JenneUpdateGreen LockingXbeat attempt

I aligned the Xgreen and PSL green to overlap on the X beat PD, and reconnected the splitter which combines the X and Y beat signals and sends them to the control room.

I've been stepping the Xend laser temperature offset in steps of 20 counts, making sure the cavity unlocks and relocks on TEM00.  So far I have not seen any beat signals for the Xarm.  I've gone from 0 to 840.

I'll be back in a few hours to keep trying, although interested parties are invited to give it a whirl. 

 

  8298   Fri Mar 15 01:57:02 2013 JenneUpdateGreen LockingX arm green locked in TEM00

This work earlier today had required moving the harmonic separator back closer to its original position, so that the green could get through without clipping.  I locked the Xarm (overriding the trigger) and realigned TRX to the PD and camera.

  8299   Fri Mar 15 02:14:27 2013 JenneUpdateCDSSimulink linking to wrong library part

Jamie and I discovered a problem with Matlab/Simulink earlier today. 

In the end suspension models, there is a subblock (with top_names) for ALS stuff.  Inside there, we use a library part called "ALS_END".  When the model was created, it included the part ...../userapps/release/isc/c1/models/ALS_END.mdl .  However, if you open up the c1scy diagram and look in the ALS block for this part, you see the part that is in ..../userapps/release/isc/common/models/ALS_END.mdl .  Note the difference - the one we want is in the c1 directory, while the one that was created (by Jamie) for the LHO One Arm Test is in the common directory. 

If you compile the c1scy model, the RCG is using the correct library part, so the information regarding which part we want is still in there. 

However, if you delete the ALS_END part from the model, put the correct one in, save, close, then reopen the model, it once again displays the wrong model.  The right click "go to library part" option brings you to the library part that is displayed, which is currently the wrong one.  THIS IS BAD, since we could start modifying the wrong things.  You do get a warning by Matlab about the file being "shadowed", so we should take heed when we see that warning, and make sure we are getting the file we want.

We are currently running Matlab version 7.11.0.584, which is r2010b.  Step 1 will be to update Matlab to the latest version, in hopes that this fixes things.  We also should change the name of our c1 part, so that it does not have the same name as the one for the sites.  This is not a great solution since we can't guarantee that we will never choose the same names as other sites, but it will at least fix this one case.  Again, if you see the warning about "shadowed" filenames, pay attention.

  8300   Fri Mar 15 02:19:01 2013 JenneUpdateGreen LockingYarm ALS laser is funny / dying

I turned the laser back on around 1am.  This is still happening, although right now it is turning off more often than before, maybe every 15 seconds or so.  I am going to turn off the laser for the night.

The measured laser temperature is about 45C (I have a 25,000 count offset in the Y ALS Slow control right now....higher offset, lower temp), although the measured laser temp drops to ~43.5C when the power goes down.

  8302   Fri Mar 15 16:46:52 2013 JenneBureaucracyAuxiliary lockingYend table upgrade - fast track?

In light of the Yend auxiliary laser's ill health, I think we should reconsider the possibility of changing out the Yend laser table next week.

My thinking here is that if whatever the new mode matching solution is for a replacement laser (Tara has borrowed our spare NPRO that used to sit on top of the fridge, or we could take Annalisa's) requires a rework of the table layout, we might as well put the new layout onto the new table.  So, we need to figure out what laser we will put in as the new Ygreen, and what it's waist looks like.  If it just requires a small movement of existing lenses or new lenses in similar positions to the current ones, we can keep living with our current table.  But, if the mode matching solution requires enough changes to distances / lens placement / whatever, we should think seriously about putting in the new table next week.

Here's what I would like to see happen on / before Monday:

Annalisa - Mode matching solution for new laser.  If we get the laser back from Tara, this will involve first measuring the waist, otherwise we already know the waist of the ABSL laser that Annalisa is currently using.

Annalisa and Steve - Find optics for new mode matching in the lab, or order them by Monday afternoon.

Manasa - List of every screw, washer, optic, mount, etc. that will go on the new Y end table, with a notation as to whether or not we have it in-hand, and if not, what needs to happen before we do.  Also, for things that we don't have, I'd like to see a summary of temporary solutions (e.g. keep using current mount for doubling crystal while new one is being machined).

Manasa / Annalisa / Koji - will the new mode matching solution fit within the existing layout, or do we need to redo the table layout?

  8304   Mon Mar 18 12:23:25 2013 JenneBureaucracyAuxiliary lockingYend table upgrade - go fetch NPRO from ATF

Zach has just replied, and said that we should feel free to take the laser from his iodine setup in the West Bridge subbasement, in the ATF lab. 

Annalisa, please ask Koji or Tara to show you where it is, and help you bring it to the 40m.  You should install it (temporarily) on the PSL table, measure the waist, and find the beat in IR.  Elog 3755 and elog 3759 have some of the details on how it has been done in the past.

  8312   Tue Mar 19 19:19:50 2013 JenneUpdate40m UpgradingEndtable upgrade : INVENTORY

Does "Ready (in stock)" for the base plates mean in stock at the company, or in hand and already here in the lab?

For the 2" mirror mounts, are we planning on making a decision soon, or a long time in the future....i.e. is this something that should go in the temporary solution column?

For the mode matching and collimating lenses, do we actually have the ones you want in our lens kits?  A lot of those kits are half empty.

  8334   Mon Mar 25 09:52:22 2013 JenneUpdateComputersc1lsc mxstream won't restart

Most of the front ends' mx streams weren't running, so I did the old mxstreamrestart on all machines (see elog 6574....the dmesg on c1lsc right now, at the top, has similar messages).  Usually this mxstream restart works flawlessly, but today c1lsc isn't working.  Usually to the right side of the terminal window I get an [ok] when things work.  For the lsc machine today, I get [!!] instead. 

After having learned from recent lessons, I'm waiting to hear from Jamie.

  8339   Mon Mar 25 16:51:59 2013 JenneUpdateOpticsupdated calculations of PRC/SRC g-factors and ARM mode matching

I think we like the idea of flipping SR2 better than SR3 for the same ghost beam reasons as PR2 is better than PR3.  There isn't very much free space in the BS chamber, and if we flip PR/SR3, we have to deal with green ghosts as well as IR.

The flipping SR2 case seems okay to me - flipping either one of the SR folding mirrors gives us a slightly better g-factor than the design with infinite curvatures, and flipping SR2 gives us slightly better mode matching to the arm than the flipped SR3 case, but more importantly, there are fewer ghosts to deal with.  I vote we flip SR2, not SR3.

  8347   Tue Mar 26 00:06:37 2013 JenneUpdateLockingAS beam put back on PD

[Jenne, Gabriele]

We aligned MICH (first locked Yarm, but didn't optimize since we don't have TRY, then locked Xarm, then aligned MICH), but there was no beam on AS55.  We went out to check, and the beam was almost not hitting the small steering mirror between AS55.  We adjusted the BS splitting the beam between camera and PD, and got the beam back on AS55. We could then lock MICH.

We also futzed with the REFL55 phase to get PRCL stuff in I, and MICH stuff in Q.  The procedure was to align PRMI, then kick PRM in pos, and adjust the phase so we got signal mostly in I after the kick.  We started at the original value of 60deg, but are leaving it at -20deg.

  8348   Tue Mar 26 00:17:47 2013 JenneUpdateLockingREFL pickoff fraction

To see how much of the light that comes out of the REFL port actually goes to the PDs, I measured the power immediately after leaving the vacuum (~575mW) and in front of REFL11 (~5mW) and REFL55 (~6mW).

So, 0.01 of the power leaving the vacuum actually goes to the REFL PDs. This number will be useful when calculating the actual signals (in volts) that we expect to see.

  8351   Tue Mar 26 11:08:03 2013 JenneUpdateLockingPRMI locking should be possible - let's get it done!

[Jenne, Gabriele, Jamie]

We have looked at Koji's old Finesse code, and determined that the PRMI sensing matrix that he calculated was for the sideband-resonant case.  Thus, this is the sensing matrix we are interested in for locking. Gabriele has confirmed this using independently written code with his software, Mist.

Pics or it didn't happen:

 PRMI_SBres_plot_allTheFs_LowRes.png

The sensing matrix is:

LSC_sigmatrix_PRMI.pdf

Numerical values are on the wiki:  https://wiki-40m.ligo.caltech.edu/IFO_Modeling/SensingMatrix

For any of the REFL PDs (1*f1, 1*f2, 3*f1, 3*f2), the PRCL signal is a factor of ~100 larger than the MICH signal.  Rana assures us that, with some clever triggering, we should be able to lock the PRMI. 

This means that we will not be venting in the next few days to flip the SRC folding mirror.  We will work on PRMI lock (probably first with 1*f, but then quickly moving on to 3*f), and as soon as Annalisa and Manasa have the new ETMY table ready for us, we will then do PRFPMI.  (We can also play with the Xarm green until Yarm green is back).

  8360   Wed Mar 27 15:46:13 2013 JenneUpdateLockingPRMI progress

[Gabriele, Jenne]

We have achieved PRMI locks of the order ~5 seconds! Here is an example lock:

PRMI_sb_27Mar2013.png

This was actuating MICH on the ITMs (+1 for ITMY, -1 for ITMX in the output matrix), and PRCL on PRM (+1). 

PRCL gain was +1, MICH gain was -10.

PRCL signal was normalized with POP22I with a matrix value of 0.003 . (No normalization of MICH).

Both PRCL and MICH were triggered on POP22I with high thresh of 200, low of 50.  MICH and PRCL FM2 (integrators) were triggered on POP22I with thresh of 400 and low thresh of 50.  FMs 4 and 5 were on for both MICH and PRCL always.

We zoomed in on the MICH_OUT signal, and the instability looks like it is around 300 Hz.  We aren't sure what this is.  I think this is a similar frequency to an oscillation that Yuta saw, but I'll have to check the old elogs.

PRM and BS SUS_LSC_POS filter banks both have notches between 1280-1290Hz.  The ITMs do not have this "Vio2" filter.

This is one of the first locks with the new triggering of both the INPUT and OUTPUT of the control filter banks.  I modified the lsc model before lunch. 

To do:  Where is this 300Hz coming from, and what can we do about it?  Why are we losing lock?  It's not due to the oscillation - maybe too much afternoon seismic?  Steve says he went next door and the rock monster / river is on medium/high.

 

  8362   Thu Mar 28 00:31:11 2013 JenneUpdateSUSPRMI optics' oplev servos tuned

[Rana, Gabriele, Jenne, Jamie, Lisa, Rana]

We have tuned the oplev servos for PRM, BS, ITMX, ITMY.  For each, we measured the servo transfer function.  Most had a UGF ~ 3Hz.  For those, we increased the gain by a factor of 2, and engaged the 3.3Hz resonant gains. The other case, such as PRM yaw, the gain was already okay, we just needed to engage the resonant gain.  We also checked the new phase margin, and for some of them switched the elliptic lowpass to 50Hz rather than 30 or 35.

Before and afters:

PRM_OLPIT_tuning_27Mar2013_RedIsAfter.pdf

PRM_OLYAW_tuning_27Mar2013_RedIsAfter.pdf

bs_pit.pdf

bs_yaw.pdf

ITMY_OLPIT_tuning_27Mar2013_RedIsAfter.pdf

ITMY_OLYAW_tuning_27Mar2013_RedIsAfter.pdf

itmx_pit1.pdf

itmx_yaw.pdf

We need to, as a last check, look at the spectra before and after to ensure that no modes (like bounce or roll) are newly excited.

ELOG V3.1.3-