40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 280 of 355  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  9014   Thu Aug 15 12:30:17 2013 manasaUpdateGreen LockingLost beat notes

[Koji, Nic, Manasa]

Update from last night.

Koji and I realigned the green optics on the PSL to start working on the ALS.

We set on a beat note search. We couldn't find the beat note between any of the arm green transmission and the PSL green. All we could see was the beat between the X arm and the Y arm green leakage.

Since we had the beatnote between the 2 green transmission beams, we decided to scan the PSl temperature. We scanned the SLOW actuator adjust of PSL; but couldn't locate any beat note. The search will continue again today.

  9015   Thu Aug 15 19:05:07 2013 manasaUpdateGreen LockingALS out of loop noise

Beat notes were recovered for both the arms.

I locked the arms to IR using PDH and measured the ALS out of loop noise at the phase tracker output.

The Y arm has the same 300Hz/rtHz rms. The X arm rms noise measures nearly the same as the Y arm in the 5-500Hz region (X arm has improved nearly 10 times after the last whitening filter stage change  old elog ).

The noise in the ALSX error signals could be related to the bad alignment and conditions at the X end.

Attachment 1: ALS_OutLoop.pdf
  9033   Mon Aug 19 16:18:56 2013 manasaUpdateGreen LockingXend green aligned

ASX scripts for PZT dither have been fixed appropriately. Script resides in scripts/ASX.

You can run the scripts from the ASX medm screen now.

  9065   Mon Aug 26 19:31:22 2013 manasaUpdateSUSPRM, ITMY watch dogs

PRM and ITMY were found with their watchdogs shutdown this afternoon (cause unknown). I re-engaged them.

  9066   Mon Aug 26 19:54:15 2013 manasaUpdateCDSc1als model modified

I had made changes to the c1als model a couple of weeks ago. I had removed all the beat_coarse channels that had existed from pre-phase tracker era.

Also, I forgot to elog about it then. This dawned on me only when I found that c1als isn't working the way it should right now.


  9070   Tue Aug 27 15:44:08 2013 manasaUpdateCDSIssues with ALS fixed

I figured out the problem with ALS from yesterday. While the model was just fine, the medm screens were not checked if they were reading the correct channel names. 

The channel names of the ALS input matrix elements had changed when the coarse channels were deleted from the c1als model. So the error signals were not reaching the servo modules as expected. This is why I was not able to make sense as to what the ALS was doing. 

All is fixed now and should be back to normal

  9079   Wed Aug 28 05:21:58 2013 manasaUpdateCDSCDS svn commits not happening

I am responsible for missed svn commits with als and asx. I have committed them.

But I have not modified anything with ioo in the last few weeks.


  9080   Wed Aug 28 06:17:15 2013 manasaUpdateComputer Scripts / Programsalias for MATLAB2010

Although Matlab 2013 has not been causing any visible trouble so far, it takes a while to startup.

I have added alias 'ml10' to bash to start Matlab 2010 from the terminal for convenience.

  9081   Wed Aug 28 06:26:28 2013 manasaUpdateComputer Scripts / ProgramsASS req and snap files edited

[From yesterday] ASS for X arm was behaving slightly funny over the last couple of days. ASS could not correct the BS misalignment. Jenne pointed out that the LSC output matrix on the ASS medm screen set itself to zeroes whenever we ran the ASS_dither_ON script. I checked the burt request file: ASS_DITHER_ON.req  in /opt/rtcds/caltech/c1/scripts/ASS and found that the LSC output matrix channels were not added to it. I added these channels for both the X and Y arm. Following this, I also edited the corresponding snap file as well. This should now set the LSC matrix to the right values everytime we run the script.

  9082   Wed Aug 28 07:33:51 2013 manasaUpdateLSCMICH locking

I wanted to measure the OLTF of MICH.

What I did:
1. Ran LSC offsets script to zero all the offsets.

2. Restored the IFO configure settings for locking Michelson (locked on AS55Q).

3. MICH wouldn't lock on these settings.

4. The MICH servo was hitting its limits (10000 counts). I checked the filter module. After a little bit of looking into things, I disabled FM3 (0,0:5,5), FM4 (1:10) and FM7 (1:5). FM3 and FM7 were filter modules that were switched ON at the trigger. I set these to manual. Enabling any of the filters (FM3, FM4, FM7) caused MICH to lose lock.

5. MICH gain was changed from -20 to -30. MICH locked with ASDC suppressed to 0.01 counts. I looked at the power spectrum of C1:LSC-MICH_OUT on dtt. //edit: Manasa// The plot (uncalibrated) now shows MICH_OUT power spectrum with MICH PSL shutter closed, free-running MICH and loop-enabled MICH.

6. I then wanted to measure the OLTF of MICH using dtt. A channels were set to C1:LSC-MICH_IN1/C1:LSC-MICH_IN2 and excitation given through C1:LSC-MICH_EXC. But I have not been able to get any good coherence for the measurement as yet.

Attachment 1: MICH.pdf
  9102   Wed Sep 4 16:08:22 2013 manasaUpdateSUSMC2 tickler turned OFF

 [Jenne, Manasa]

While we were trying to relock the MC after Jenne put back the RF box, we found there was some mysterious motion in MC2. After spending time trying to figure out where this was coming from, the source was found to be at LOCKIN2 of MC2 suspension "The MC TICKLERthat was left enabled. This was turned OFF and MC locked just fine after that.


EDIT JCD:  The Tickler should be disabled, if the autolocker is disabled.

  9105   Wed Sep 4 20:47:15 2013 manasaUpdateLSCCalibrated in-loop MICH noise

To estimate in-loop MICH noise:

(a) Calibrate MICH_ERR:

1. Lock the arms for IR using POX11 and POY11.
2. Misalign the ETMs.
3. Obtain the average peak-to peak (bright to dark fringe) counts from the time series of AS55_Q_ERR. I measured this to be d = 6.358 counts.
4. This gives the calibration factor for AS55_Q_ERR [Calibration factor = 2*pi*d/1064/10^-9 = 3.7546x10^7 counts/m]

(b) In-loop MICH noise:

1. Lock MICH using AS55_Q.
2. Since LSC input matrix sets MICH_IN1 = 1* AS55_Q_ERR, the power spectrum measured using dtt and calibrated using the calibration factor from step 4 in (a) gives us the calibrated in-loop MICH noise.

The plot below shows the in-loop MICH noise and the dark noise (measured by closing the PSL shutter):

Compared with old measurements done by Keiko elog 6385 the noise levels are much better in the low frequency region below 100 Hz.
(No, no, no... this is not an apple-to-apple comparison: KA)

Attachment 1: MICH_noise.pdf
  9137   Wed Sep 18 11:29:43 2013 manasaUpdateCDSDataviewer cannot connect to fb

Masayuki pointed out that dataviewer wasn't connecting to the fb this morning.

When I started dataviewer from the terminal I obtained the following error:

controls@pianosa:~ 0$ dataviewer
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Error in obtaining chan info.
Can't find hostname `fb:8088'
Can't find hostname `fb:8088'; gethostbyname(); error=1

I checked the CDS FE status screen and it looks normal. I could ping the fb and ssh to it as well.

I restarted fb to see if it made any difference. telnet fb 8088

It hasn't helped. Anything else that can be done??


  9170   Fri Sep 27 16:02:23 2013 manasaUpdateGreen LockingY arm ALS phase tracking loop gain changed

[Masayuki, Manasa]

While trying to lock the arms using ALS we found that the locks were not very stable and the in-loop noise was higher than seen before.

I looked into things and checked the out-of loop noise for ALS and found that the Y arm ALS noise (rms) was higher than the X arm.

To troubleshoot, I measured the OLTF of the phase tracking loop. While X arm was healthy, things weren't looking good for the Y arm. Sadly, the Y phase tracking loop gain was set too high with a phase margin of -2 degrees. We brought down the gain from 300 to 150 and set the phase margin close to ~55 degrees.

X arm Phase tracker loop:
UGF = 1.8 K Hz
Phase margin = 50 degrees

Y arm Phase tracker loop:
UGF = 1.6 KHz
Phase margin = 55 degrees

Attachment 1: outofloop.pdf
Attachment 2: PTX_OLTF.pdf
Attachment 3: YPT_OLTF_after1.pdf
Attachment 4: YPT_OLTF_before.pdf
  9171   Fri Sep 27 20:28:10 2013 manasaUpdateGreen LockingALS servo

[Masayuki, Manasa]

I. ALS servo loops
After fixing things with the phase tracking loop, we checked if things were good with the ALS servo loops.
We measured the OLTF of the X and Y arm ALS servo loops. In both cases the phase margin was ~20 degrees. There was no room to set enough phase margin. So we looked at the servo filters. We tried to modify the filters so that we could bring enough phase margin, but could not get at it. So we put back the old filters as they were.

 attachment1: OLTF of the ALS XARM and YARM control loops

attachment2: Current phase budget. FM4 and FM10 are the boost filters.

II. ALS in-loop noise
Also, I found that the overall noise of the ALS servo has gone up by about two orders of magnitude (in Hz/rtHz) over the whole range of frequencies for both the arms from the last time the measurements were made. I suspect this could be from some change in the calibration factor. Did anybody touch things around that could have caused this? Or can somebody recollect any changes that I made in the past which might have affected the calibration? Anyways, I will do the calibration again.



Attachment 1: OLTF.pdf
Attachment 2: phase_badget_xarm_ALS.pdf
  9176   Mon Sep 30 17:55:45 2013 manasaUpdateGreen LockingX and Y arm transmission needs to be decoupled

[Masayuki, Manasa]

We wanted to lock both the arms using ALS and get IR to resonate while arms are held using ALS. The X arm was locked using ALS and offsetter2 was used to scan the arm and find IR resonance. The Y arm was locked using ALS. But as the Y arm was brought closer to IR resonance, the X arm ALS loses lock. (attachment 1)

We believe that this comes from the X and Y transmission not being well separated at the PSL table. The PBS is not sufficient to decouple them (A strong beatnote ~35dB between the X and the Y arm green lasers can be seen on the spectrum analyzer).

Decouple the X and Y arm transmitted beams at the PSL table. I am trying to find a wedged mirror/window that can separate the 2 beams at the PSL table before the beat PD (sadly the laseroptik HR532nm optics have no wedge)


Attachment 1: scan2.png
  9178   Mon Sep 30 23:56:19 2013 manasaUpdateGreen LockingALS autolocker flowchart

[Masayuki, Manasa] 

Flowchart for ALS autolocker. The error signal thresholds will be decided by trial and error.


  9195   Thu Oct 3 09:01:06 2013 manasaUpdateGreen LockingALS high frequency noise

 As I was trying to solve the 2 arm ALS problem, I found the Y arm ALS not so stable AGAIN :( . I measured the in-loop noise of the X arm as ~400Hz/rtHz (60 picometers).

I went ahead and checked the out of loop noise of the ALS and found there is some high frequency noise creeping in above 20Hz for the Y arm ALS (blue curve). I checked the UGFs and phase margins of the phase tracker loops and found they were good (UGF above 1.4KHz and phase margins between 40 and 60 degrees).

So the suspect now is the PDH servo loop of both the arms which has to be checked.

Attached is the out-of loop noise plots of X and Y arm ALS.

Attachment 1: ALS_outloop.pdf
  9198   Thu Oct 3 13:54:25 2013 manasaUpdateGreen LockingALS out-of loop noise

We found the PDH servo gain for Y arm green was set at 2 (too low). The gain was set to 8.6 (based on earlier OLTF measurement elog 8817).

The ALS out-of loop noise was remeasured. We also measured the out-of loop noise of each arm while the other arm had no green (shutter closed). There doesn't seem to be any difference in the noise (between green and orange for Y arm and red and pink for the X arm) except that the noise in the X arm was slightly low for the same conditions (blue and red)  when measurement was repeated.

TRANSLATION by Jenne:  We first locked both X and Y for IR using the LSC, and X and Y for green using the analog PDH servos.  We measured the _PHASE_OUT_Hz calibrated error signals for both X and Y in this configuration - this gives us the out of loop noise for the ALS system, the Green and Blue traces in the plot.  We then closed the X end shutter, and measured the Y arm's error signal (to check to see if there is any noise contribution from the suspected X-Y cross beatnote).  Then, we closed the Y end shutter, relocked the Xarm on green's 00 mode, and measured the X arm's error signal.  We weren't sure why the Pink curve was smaller than the Blue curve below a few Hz, so we repeated the original measurement with both arms dichroic.  We then got the Red curve.  So, we should ignore the blue curve (although I still wonder why the noise changed in such a short time period - I don't think we did anything other than unlock and relock the cavity), and just see that the Green and Gold curves look similar to one another, and the Red and Pink curves look similar to one another.  This tells us that at least the out of loop noise is not affected by any X-Y cross beatnote.

Attachment 1: ALS_outloop.pdf
  9219   Tue Oct 8 00:21:01 2013 manasaHowToGreen LockingALS arm stabilization

Step by step procedure for stabilizing arms using ALS servo:

The procedure is the same for both the arms. 

0. Check that the ALS arm servos are turned OFF and not sending any signals to the ETM suspensions. 

1. Find the beat note by varying the laser temperature (moving the slider for SLOW_SERVO2_OFFSET).
Tip: It is easier to have the arms locked using IR PDH while searching for the beat note. Also check the stability of the MC. Unstable MC will cause the PSL temperature to drift and thereby affect the beat frequency.

2. Once you have the beat note, check if the beat amplitude is ~ -15 to -20 dBm. If the amplitude is small, then the alignment needs to be fixed (either the green input pointing at the end tables or the PSL green alignment). This is important because the UGF of the phase tracking loop (should be above 1KHz) changes with the amplitude of the beat note.
Also the beat frequency should be < 100 MHz; preferably below 80 MHz.

3. Disable IR PDH locking if you had used it while searching for the beat note. 

4. Press CLEAR HISTORY button for the phase tracker servo. Check if the phase tracking loop is stable (phase tracker servo output counts should not be ramping up). If the phase tracker is not stable, check the servo gain and phase margin of the loop.

5. Turn OFF all filters in the ALS arm servo filter module except for FM5 (phase compensation filter). With ALS arm servo gain set to zero, enable the arm servo and allow ALS control signals to be sent to the ETM suspensions.

5. Open dtt and look at the power spectrum of the ALS error signal (C1:ALS-BEAT?_FINE_PHASE_OUT_HZ). 

6. Set ALS arm servo gain +/- 0.1 to check the sign of the servo gain. Wrong sign of gain will make the loop unstable (beat note moving all over the frequency range on the spectrum analyzer). If this happens, set the gain to zero immediately and clear history of phase tracker servo. If you have set the correct sign for gain, the servo will stabilize the beat note frequency right away. 

7. Once you know the correct sign of the servo gain, increase the gain in steps while simultaneously looking at the power spectrum of error signal on dtt (it is convenient to set dtt measurements to low bandwidth and exponential measurement settings). Increase the gain until you can see a slight bump close to the UGF of the ALS servo (>100Hz). 
There have been times when this servo gain was in a few hundreds; but right now it varies from +/- 10-20 for both the arms. So we are stepping up gain in steps of +/- 2.

8. Enable filters (FM2, FM3, FM6, FM7, FM8). Wait to see the rms noise of the error signal go down (a few seconds).

9. Enable boost filter (FM10). There also exists a weaker boost filter (FM4) which we don't use any more. 


1. Beat frequency changes affect both the servo gain and sign of gain. So if you lose stability of ALS servo at any point, you should go through all the steps again.

2. At any point if the ALS arm servo becomes unstable (which can happen if the MC loses lock or if the beat frequency was too high ), change the servo gain to zero immediately. Turn OFF all the filters except for FM5 (if they were enabled) and reset phase tracker servo (CLEAR HISTORY button in the phase tracker filter module). Masayuki has written the down script that does all this. The script will detect arm servo loop instability by continuously looking at the feedback signal. Details about the script can be found here

Here is a cheat sheet that can give you an idea of the SLOW SERVO2 offset range to scan in order to find the beat note:

PSL temperature  X offset   Y offset
31.58                     5278       -10890
31.52                     5140       (not recorded)
31.45                     4810       (not recorded)
31.33                     4640       -10440
31.28                     4500       -10340

  9233   Fri Oct 11 00:37:23 2013 manasaUpdateGreen LockingX arm green locking modes

[Masayuki, Manasa]

We have stabilized the ALS for Y arm and concluded that although the PDH servo could be stabilized, it drifts and loses stability over a span of few hours. (See masayuki's elog today)

We wanted to follow the same systematic procedure like in the previous elog to look at the condition of the X arm as well.
In order to stabilize the green PDH servo, we held the arm using the IR PDH and aligned the end-green to the X arm.

We see 2 TEM00-like modes and one oblong TEM00+TEM01 mode that can lock to the cavity. It is not clear to me as yet as to how to differentiate between these 2 TEM-00 like modes and how we should decide between them.

One of the TEM00-like mode is strongly matched to the arm cavity. Normalized GTRX measures 0.6 counts. The other TEM00-like mode is weakly matched to the cavity. Normalized GTRX measures 0.12 counts. This might be the reason why Jenne and Masayuki were seeing a lower beat amplitude. Camera images are shown below.


On another note, we found that an oblong mode (looks like a TEM00+TEM10 mode) also locks to the cavity. The mode looks weird in that, only one half of the mode is seen moving due to seismic noise and the other part does not. I am not sure how I can describe this...so here is a 10 second video of how this mode looks like. 

  9260   Wed Oct 23 00:05:17 2013 manasaUpdateSUSUnstable Y arm ALS points to problems with ETMY suspension

[Masayuki, Manasa]

Looking into control signals and error signals of the Y arm green PDH servo,

1. The saturation of feedback signal (PZT_OUT) at +/-4000 counts (less than 5V) comes from only the readout saturating. The signals looked fine on the oscilloscope.
2. We did a sine sweep at the PZT_OUT and optimized the LO frequency. The LO frequency did not need any change.
3. The error signal has some offset to it. We are not sure where this comes from.

We have been seeing that whenever green loses lock, the spot position moves down in pitch on the ETMYF camera and the GTRY camera. This led us to think about if the lock loss originated from the PDH or from the cavity.

We looked into dataviewer channels of green, IR, oplev and suspension for the following cases:
1. Green and IR PDH locked
2. Green locked and arms flashing for IR
3. Green shutter closed and IR PDH locked
4. Green shutter closed and arms flashing for IR
5. Arms flashing for IR and ETMY oplev servo turned off.

Dataviewer snapshots of glitch in all the above cases are saved in masayuki's folder users/masayuki/ALS/kicked_mirror/

In all the above cases, we could still see the glitch. We could conclude that the problem lied with the ETMY SUS.
Shown below is the dataviewer snapshot of ETMY sus and shadow sensor channels. The glitch exists even when the oplev servo is turned off pointing to problems associated with the ETMY suspension.


  9303   Mon Oct 28 14:12:48 2013 manasaUpdateIOOMode Cleaner relocked


 The MC had been unlocked for the last 4 hours and was crying out to me so I gave it some attention. Its happier now.

From the trend (AtM #1), I saw that the MC2 suspension has moved by ~10 microradians. Since the MC cavity divergence angle is lambda/(pi*w0) ~ 200 microradians, this isn't so much, but enough to cause it to lock on bad modes sometimes. Attackmint too shows that there's not much in monotonic drift over the last 40 nights.

I moved back MC2 to its old alignment with these commands:

ezcaservo -r C1:SUS-MC2_SUSPIT_INMON -s -1017 -g 0.0009 C1:SUS-MC2_PIT_COMM -t 300

ezcaservo -r C1:SUS-MC2_SUSYAW_INMON -s 490 -g 0.0009 C1:SUS-MC2_YAW_COMM -t 332

Then I went out to the table and aligned the beam into MC using the last two steering mirrors good enough so that the WFS coming on doesn't make the visibility any better. In this nominal state, I unlocked the MC and then aligned the reflected beam onto the center of the LSC PD as well as the WFS. The beam on the first WFS is a little small - next time someone wants to improve our Gouy phase telescope, we might try to make it bigger there. On the LSC PD, the beam was off-center by a few hundred microns.

Masayuki was running LAN cables near the MC2 chamber. This caused the MC2 suspension to move and unlocked the MC. I looked at the long term (2 days) and short term (2 hours) trend of the MC suspensions. I restored the old alignment as described above using ezcaservo.

C1:SUS-MC2_SUSPIT_INMON was restored to 1020 and C1:SUS-MC2_SUSYAW_INMON was restored to 490.

Attachment: Dataviewer trend (2 hours)

Attachment 1: Screenshot-Untitled_Window-3.png
  9320   Wed Oct 30 16:46:17 2013 manasaUpdateIOOMC aligned

MC has not been very happy since last night. 

What I did to fix this:

1. Disabled autolocker and WFS and aligned the MC to bring MC REFL down to <0.50

2. When I re-enabled autolocker, MC was losing lock everytime WFS turned ON.

3. I relocked MC, measured the spot positions and moved MC spot positions by running /opt/rtcds/caltech/c1/scripts/ASS/MC/mcassMCdecenter 

4. I reset the WFS offsets by running /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets

5. MC is locked and looks happy right now with REFL DCMON at ~0.5


  9322   Thu Oct 31 15:34:28 2013 manasaUpdateIOOMC not happy since yesterday



8 day minute trend of some of the IMC alignment signals.

That step ~2 days ago in the WFS2 yaw control signal shows that I didn't do such a good job on yaw.

Nic is going to come over some time and give us a new Gouy telescope that let's us have bigger beams on the WFS. At LLO, Hartmut demonstrated recently how bigger beams can reduce offsets somehow...mechanism TBD.

Also, we must angle the WFS and figure out how to dump the reflections at the same time that we rework the table for the telescope.

Steve, can you please put 2 mounted  razor dumps near the WFS for this purpose??    

            Tuesday: Razor dumps are waiting for you.


The MC has not been able to hold lock for over a couple of hours since yesterday. I aligned the MC yesterday (elog 9320) and it lost lock in a couple of hours. I realigned the MC again around noon today only to see it drifting and lose lock again.

I have attached the MC trend for the 2 hours when the MC drifted slowly from its happy to sad state.



Attachment 1: MC_drift.png
  9342   Tue Nov 5 00:39:43 2013 manasaUpdateIOOIFO alignment tuning

Information acknowledged from Steve:

The last steering mirror mount for IR on the PSL was swapped for a more robust one. Prior to swapping the ibeam positions on the PSL IOO QPDS in ang and pos were recorded.

What I did henceforth:

1. Once the last steering mirror was installed, I walked the beam to restore input pointing using the last 2 steering mirrors. It needed a lot of work in yaw as expected.

2. When the input pointing was recovered, MC locked right away in TEM00. I measured the MC spot positions and compared it with Jenne's measurement made prior to the swap. The spot positions were pretty close.

3. The input pointing was adjusted in pitch and yaw (on the last steering mirror) in small steps. MC alignment was recovered and spot positions were measured each time. After several iterations, the MC spot positions were pretty much centered. I recentered the WFS and reset the WFS offsets. MC is now locked with WFS enabled at ~16900 counts.


4. Since the arms were aligned this morning, I used the Y arm as reference and corrected for the input pointing using tip-tilts.

5. Arms locked right away. Note: ASS doesn't seem to be doing it's job. I had to manually align the arms for maximum on TRX and TRY.

6. MICH and PRMI lock were also recovered.

7. I started to check the status with ALS as well. But for reasons unknown, I don't see any ADC counts corresponding to the beat note. Looking at the beatbox there aren't any signs of disconnected cables.  I am saving this as a morning job to fix it.

  9350   Tue Nov 5 19:50:07 2013 manasaUpdateElectronicsIOO rack +/-5V power supplies

The power supply to the ADC box on the IOO rack (that reads the beat I & Q signals) was pulled out because it did not run through any fuse and was connected directly to the power supply. 

There were already connections running from the +/-5 V power supply. They were powering the mode cleaner demod board rack. In order to remove the ADC power connectors from the power supply, I notified Jenne in the control room because turning off the power supply would affect the MC. I switched off the +/-5V power supplies at the same time. The ADC power connectors were removed. The +/-5V power supplies were then turned ON again at the same time. Jenne relocked the MC after this.

I have still not connected the ADC to the fuse rack power supply because this requires the +/-5V power supplies to be turned OFF again in order to pull out new connections from the fuse rack and I need to make a new ADC power connector with thicker wires.

  9356   Wed Nov 6 15:59:41 2013 manasaUpdateElectronicsIOO rack +/-5V power supplies


The power supply to the ADC box on the IOO rack (that reads the beat I & Q signals) was pulled out because it did not run through any fuse and was connected directly to the power supply. 

There were already connections running from the +/-5 V power supply. They were powering the mode cleaner demod board rack. In order to remove the ADC power connectors from the power supply, I notified Jenne in the control room because turning off the power supply would affect the MC. I switched off the +/-5V power supplies at the same time. The ADC power connectors were removed. The +/-5V power supplies were then turned ON again at the same time. Jenne relocked the MC after this.

I have still not connected the ADC to the fuse rack power supply because this requires the +/-5V power supplies to be turned OFF again in order to pull out new connections from the fuse rack and I need to make a new ADC power connector with thicker wires.

I switched OFF the +/-5V power supplies on the IOO rack to hook up the ADC power connectors through 250mA fuses to +/-5V. Since these power supplies were powering the MC demod boards, MC remained unlocked during the process. I turned the power supplies back ON and MC relocked itself after this.

  9391   Fri Nov 15 10:19:26 2013 manasaUpdateCDSCan't talk to AUXEY?



 This problem is now worse - the sliders on IFO_ALIGN for ETMY are white.  I can't telnet to the machine either, although auxex works okay.  Rather, it looks like maybe I'm getting to auxey, but then I'm immediately booted.  I can ping both c1auxex and c1auxey with no problem.

Heeeeelllp please.  Is this just a "shut off, then turn back on" problem?  I'm wary of hard rebooting things, with all the warnings and threats in the elog lately.  I've sent an email to Jamie to ping him.

There are some vague instructions in the wiki, but they begin at doing the burt restores, not actually restarting the computers: wiki  Back in July, elog 8858 was written, from which the wiki instructions seem to be based.  But in the elog it says "...went to the /cvs/cds/caltech/target/ area and started to (one by one) inspect all of the targets to see if they were alive.", but I don't know what "inspected" means in this case.  I probably should, since I've been here for something like a millennia, but I don't.


This is what was done (as I recollect) when we said "inspected":Tenet into the computer, ping them and look at the status. Since c1auxey is not responding, here is how c1auxex responds.

controls@rossa:/cvs/cds/caltech/target 0$ telnet c1auxex
Connected to c1auxex.martian.
Escape character is '^]'.

c1auxex > h
  1  i
  2  -help
  3  --help
  4  h
  5  2
  6  h
  7  -help
  8  i
  9  h
value = 0 = 0x0
c1auxex > i

  NAME        ENTRY       TID    PRI   STATUS      PC       SP     ERRNO  DELAY
---------- ------------ -------- --- ---------- -------- -------- ------- -----
tExcTask   _excTask       fde244   0 PEND          87094   fde1ac   3006b     0
tLogTask   _logTask       fdb944   0 PEND          87094   fdb8a8       0     0
tShell     _shell         ddad00   1 READY         6d974   dda9c8  3d0001     0
tRlogind   _rlogind       fbc11c   2 PEND          2b604   fbbdf4       0     0
tTelnetd   _telnetd       fba278   2 PEND          2b604   fba1a8       0     0
tTelnetOutT_telnetOutTa   db7578   2 READY         2b604   db72e0       0     0
tTelnetInTa_telnetInTas   db6060   2 READY         2b5dc   db5d68       0     0
callback   _callbackTas   f7941c  40 PEND          2b604   f793d4       0     0
scanEvent  ee7ca8         ecacb4  41 PEND          2b604   ecac6c       0     0
tNetTask   _netTask       fd75b8  50 READY         6be6c   fd7550       0     0
scanPeriod ee78f8         ecd554  53 READY         6d192   ecd508       0     0
scanPeriod ee78f8         f23e48  54 DELAY         6d192   f23dfc       0     6
tFtpdTask  _ftpdTask      fb7848  55 PEND          2b604   fb778c       0     0
scanPeriod ee78f8         f266e8  55 READY         6d192   f2669c       0     0
scanPeriod ee78f8         f38678  56 READY         6d192   f3862c       0     0
callback   _callbackTas   f7bcbc  57 PEND          2b604   f7bc74       0     0
scanPeriod ee78f8         f906d8  57 DELAY         6d192   f9068c       0    59
scanPeriod ee78f8         f995ac  58 DELAY         6d192   f99560       0   238
scanPeriod ee78f8         f9c908  59 DELAY         6d192   f9c8bc       0   538
callback   _callbackTas   fa4c1c  65 PEND          2b604   fa4bd4       0     0
scanOnce   ee7764         f9f96c  65 PEND          2b604   f9f92c       0     0
epicsPrint f0501c         e88fa0  70 PEND          2b604   e88f64   c0002     0
ts_Casync  ee5bae         f76b7c  70 DELAY         6d192   f76880  3d0004   178
tPortmapd  _portmapd      fb8d60 100 PEND          2b604   fb8c2c      16     0
EgRam      ea00e4         fa14ac 100 PEND          2b604   fa1458       0     0
CA client  _camsgtask     d85878 180 PEND          2b604   d85774  3d0004     0
CA client  _camsgtask     df91e8 180 PEND          2b604   df90e4       0     0
CA client  _camsgtask     d98bf4 180 PEND          2b604   d98af0       0     0
CA client  _camsgtask     e03cd0 180 PEND          2b604   e03bcc       0     0
CA client  _camsgtask     ddf2b8 180 PEND          2b604   ddf1b4       0     0
CA client  _camsgtask     faaec8 180 PEND          2b604   faadc4       0     0
CA client  _camsgtask     d79f3c 180 PEND          2b604   d79e38       0     0
CA TCP     _req_server    f305dc 181 PEND          2b604   f30540       0     0
CA repeaterf109e2         f215a8 181 PEND          2b604   f21474       0     0
CA event   _event_task    d7fe58 181 PEND          2b604   d7fe10       0     0
CA event   _event_task    d6ce5c 181 PEND          2b604   d6ce14       0     0
CA event   _event_task    dab7e0 181 PEND          2b604   dab798       0     0
CA event   _event_task    d76efc 181 PEND          2b604   d76eb4       0     0
CA event   _event_task    d9bddc 181 PEND          2b604   d9bd94       0     0
CA event   _event_task    d9a864 181 PEND          2b604   d9a81c       0     0
CA event   _event_task    da8d8c 181 PEND          2b604   da8d44       0     0
CA UDP     _cast_server   f2f064 182 READY        efcabe   f2efe4       0     0
CA online  _rsrv_online   f2d84c 183 DELAY         6d192   f2d7bc       0   265
EV save_res_event_task    de88dc 189 PEND          2b604   de8894   3006b     0
save_restor_save_restor   df61cc 190 PEND          2b604   df5c44  3d0002     0
RD save_res_cac_recv_ta   fb47d8 191 READY         2b604   fb46a4  3d0004     0
logRestart f05d42         e861c0 200 PEND+T        2b604   e86174      33  1714
taskwd     ef4d46         e85030 200 DELAY         6d192   e84f7c       0   224
value = 0 = 0x0
c1auxex >
telnet> quit
Connection closed.
controls@rossa:/cvs/cds/caltech/target 0$

  9397   Fri Nov 15 14:08:13 2013 manasaUpdatePSLPSL Innolight shuts down again


I have just turned on the PSL Innolight laser. The laser shut down  with unknown reason a day ago.

PSL NPRO shut down again today for reasons unknown. I was working near the IOO rack and noticed there was no light at both the refl and trans PMC cameras. Jenne and I checked the PSL and found the 'OFF' red switch on the laser driver lit up. Switching ON the green button brought the laser back. PMC and MC autolocked after this.

  9411   Tue Nov 19 14:47:59 2013 manasaUpdateLSCGreen status


After I aligned the IR interferometer (no ASS - we still need to figure out what's going on with that), I am trying to find the green beatnotes for each arm.

First, I locked the green lasers to each arm.

I then went out to the PSL table and aligned the Green Yarm path by overlapping the near-field and far-field of the yarm transmission and the PSL green pickoff.  I then turned on the power for the Beat PDs, since it was off (I confirmed that the outputs were plugged into the beatbox, so they are seeing 50 ohms).  I assume that the beat PDs were off since Manasa pulled the Beatbox last week, but there is no elog reference!!  Anyhow, after seeing a real signal, I maximized the DC power on the beat PD for the Yarm.  I then maximized the light on the DC transmission PD for the Yarm.

I looked at the Xarm, and the near-field alignment looks okay, but I haven't checked the far-field.

I started looking for the beatnotes from the control room:

I am changing the SLOW_SERVO2_OFFSETs by 30 counts, and then unlocking and relocking the arms, and checking to see if I see a peak on the RF spectrum analyser. 

The Y offset started at -10320, and I found a beatnote at -11230 (beatnote is about 26MHz).  The X offset started at 4500.  Going larger seemed to get me to a less bright TEM00 mode, so I switched and have been searching by going down in offset, but haven't yet found the beatnote.  I suspect that I actually need to align the X path on the PSL table.  The Y beatnote is very small, about -30dBm, so I also need to tweak the alignment by maximizing the peak value.

 I found the beatnotes for both the X and Y arm ALS this morning. The beat amplitudes measured -5dBm and -18dBm respectively and occurred at SLOW SERVO2 OFFSET 4550 and -10340. I had to only tweak the Y green PSL alignment to increase the beat amplitude.

I locked both the arms using ALS and they were stably locked until MC unlocked for a moment (nearly 16 minutes).

The only thing missing in the list of things you looked into is the status of the PSL slow actuator adjust. Check if this is near zero.

  9414   Tue Nov 19 21:28:05 2013 manasaUpdateLSCPRMI carrier locking

Since we have never tried to lock PRMI on carrier after the folding mirrors were flipped, I tried to lock PRCL on carrier.

I thought this might give us some idea about the PRC stability for resonance or some clue as to what happens to the PRM suspensions and PRMI stability when we have carrier resonating in the cavity.

I changed the sign of the PRCL gain and also tried increasing the gain. But this did not work and I was not able to carrier lock PRMI. May be I am missing to change some parameter that is very trivial?

  9415   Tue Nov 19 21:59:35 2013 manasaUpdateLSCPRMI carrier locking


Since we have never tried to lock PRMI on carrier after the folding mirrors were flipped, I tried to lock PRCL on carrier.

I thought this might give us some idea about the PRC stability for resonance or some clue as to what happens to the PRM suspensions and PRMI stability when we have carrier resonating in the cavity.

I changed the sign of the PRCL gain and also tried increasing the gain. But this did not work and I was not able to carrier lock PRMI. May be I am missing to change some parameter that is very trivial?

PRMI could not be locked on carrier using 3f. The configuration from the last time when PRMI was carrier locked (elog) were used and PRMI locked on carrier with these settings.

== PRMI carrier ==
  MICH: AS55_Q_ERR, AS55_PHASE_R = -12 deg,  MICH_GAIN = -0.2, feedback to ITMX(-1),ITMY(+1)
  PRCL: REFL55_I_ERR, REFL55_PHASE_R = 70 deg, PRCL_GAIN = 1.0, feedback to PRM

Below is the video capture showing the PRM front and back face when carrier flashes with few second locks.


The demod phase numbers that Manasa is quoting above were correct back in March, when the elog she's quoting from was written.  They are not true now, since we've adjusted things in the last 8 months.  Also, I'm using a gain of -1.5 for MICH, and +1.5 for PRCL.  MICH has no FMs triggered, PRCL has FM 2,3,6 triggered.  Since we won't be using this configuration for full locking, but just for some tests, I'm currently using AS55 Q for MICH, and REFL 55I for PRCL, and using the ITMs to actuate on MICH for today.

  9526   Tue Jan 7 16:41:08 2014 manasaUpdateIOOWFS moving MC suspensions


 The trend shows a big jolt to the MC1/3 pointing this morning at 8:30.

Was anyone working anywhere near there today? There is no elog.

If not, we will have to put a 'no janitor' sign on all of the 40m doors permanently to prevent mops misaligning our interferometer.

The MC trend for the last 2 days shows that the MC suspensions were kicked again earlier today.  Looking back at the suspension channel INMONs along with the MC trans sum shows that the suspensions get kicked everytime MC locks and unlocks. (Attch:1)

So I checked the effect of WFS on the suspensions by disabling and enabling the WFS feedback servo (Attch:2).

Since the IMC is not at it best pointing, whenever the  MC autolocker runs and enables the WFS, the suspensions look like they are getting kicked.  But really, it's just the WFS doing their job. 

Edit, JCD:  What this really means is that our DC MC pointing is bad, and we need to move the MC suspensions to offload the WFS.  (All of the WFS output numbers for MC1 and 3 were around 100, which is pretty big for those numbers).  We should resurrect the WFS offloading scripts so that we can do this more regularly, and not have to do it by hand.

Attachment 1: 2dayMCtrend.png
Attachment 2: WFSvsMCsuspensions.png
  9527   Tue Jan 7 17:16:04 2014 manasaUpdateIOOMC aligned


Edit, JCD:  What this really means is that our DC MC pointing is bad, and we need to move the MC suspensions to offload the WFS.  (All of the WFS output numbers for MC1 and 3 were around 100, which is pretty big for those numbers).  We should resurrect the WFS offloading scripts so that we can do this more regularly, and not have to do it by hand.

 Aligned MC to offload the WFS

1. Turned OFF the WFS feedback servo.

2. Aligned the MC suspensions by moving the pit and yaw sliders. MC trans sum brought from ~11000 counts to ~15000 counts. MC RFPD DCMON reads 0.45 counts.

3. Turned ON the WFS servo. The WFS output now reads in the order of 0 to +/-15.

4. Measured the MC spot positions. The spot positions look like they moved for the better compared to what they were yesterday.


Attachment 1: MCspots.png
  9532   Tue Jan 7 23:09:10 2014 manasaUpdateIOOMC aligned


[Rana, Jenne]

We turned off the WFS servos, and looked at the MC REFL DC, and saw that it was still good, so we said that since the MC spots are pretty good, that we'll keep this alignment for now. 

Rana put the beam back on the center of the IOO QPDs on the PSL table.

We switched a steering mirror in the WFS path that was the wrong handed-ness to be the correct handed-ness, then put the beam on the centers of the WFS.  We turned on the WFS, and everything seems good. 

There were no major drifts in the WFS error signals while we were gone for dinner, so the MC seems okay for now.

 The last 4 hour trend for WFS error signals show some amount of drift. We should still look at the long term trend to solve the issue.

Attachment 1: WFSdrift.png
  9540   Wed Jan 8 17:53:26 2014 manasaUpdateGeneralIFO plan, IPANG telescope

For the IPANG telescope design, we are in the 'beyond the Rayleigh range' regime. So using a single lens to make the beam small is not a great idea. I have put down a solution where we use a pair of lenses; one of which will be mounted in-vacuum in the ETMY chamber and the other on the endtable.
This way we will also allow have some freedom to configure the layout out-of vacuum in case the need arises. The layout will look something like in the cartoon:

I also made a choice of using longer focal length lenses (CVI 2" lenses f =1 m). Below is the beam path summary for IPANG telescope. I have used the waist diameter at the ITM for propagation. The endtable is roughly at 41.2m. The QPD will be placed in front of the waist (w0=47um).

  9587   Thu Jan 30 11:59:03 2014 manasaUpdateCDSfb timing was off


Since this morning, the fb's timing has been off.  Steve pointed it out to me earlier today, but I didn't have a chance to look at it until now. 

This was different from the more common problem of the mx stream needing to be restarted - that causes 3 red blocks per core, on all cores on a computer, but it doesn't have to be every computer.  This was only one red block per core in the CDS FE status screen, but it was on every core on every computer. 

The error message, when you click into the details of a single core, was 0x4000.  I elog searched for that, and found elog 6920, which says that this is a timing issue with the frame builder.  Since Jamie had already set things on nodus' config correctly, all I did was reconnect the fb to the ntp: 

fb$ sudo /etc/init.d/ntp-client restart

As in elog 6920, the daqd stopped, then restarted itself, and cleared the error message. It looks like everything is good again.

I suspect (without proof) that this may have to do with the campus network being down this morning, so the computers couldn't sync up with the outside world.

The above timing problem has been repeating (a couple of times this week so far). It does not seem to be related to the campus network.

The same solution was applied.

  9589   Fri Jan 31 18:41:25 2014 manasaUpdateGeneralIFO alignment update

[EricQ, Gabriele, Manasa]

We found we had lost the Y arm pointing from yesterday. We tried to recover the pointing for a couple of hours and finally decided to take the ETMY heavy door off.

The input beam was aligned to the Y arm. We also got AS and REFL out of vacuum and on the cameras.

We put back the light doors and tried to lock the arms, but did not succeed as yet.

Things to do:
1. Lock arms for IR
2. Realign POP path
3. Recenter all oplevs
4. Try to check the state of PRC after the length change
5. Take in-vacuum pictures

  9596   Tue Feb 4 16:43:50 2014 manasaUpdateGeneralIFO alignment update

[EricQ, Manasa]

We are close to the end of the vent except for a couple of issues.

* POP is not visible on the IR card. But we see POP flashes unclipped on the camera and also spikes in POP DC. So  we are assuming that the POP path hasn't gone far off. If anybody has suggestions for a better method to check this, we could give it a try.

* PRM suspension has not been behaving well. PRM is being kicked around every 5-10 seconds when the PRC is aligned (as seen on REFL camera). We are not sure where this is coming from. The first time we saw this happening was when we were trying to lock PRC at low power even before we took the heavy doors off. So we are pretty sure this is not caused by the foil cover on the OSEMs. We tried turning ON/OFF the oplev servo, turning ON/OFF the damping loops and also checked the connections in the feedthrough and satellite box for the PRM. The OSEM sensor values for the suspension also seem to match the ones on the wiki.


Closeup checklist


  • Center beam on all AS optics

    • We must get images right before closing, right after closing, etc.
  • Make sure REFL is clear
    • dither PRM, see motion on AP tables
  • Make sure AS is clear
    • dither BS/ITM, see motion on AP tables
  • Using IPANG/POS pick-off mirrors, center beams on:
    • IPPOS
    • IPANG (IPANG aligned to be low in pitch. The beam comes out of vacuum unclipped and hits the first steering mirror outside vacuum at its lower edge)
  • Check green alignment in the arms and make sure the transmitted green reaches the PSL table.
  • Check all OpLevs centered, in and out of vacuum

  • Close PSL shutter & green shutters at the ends

  • Check jam nuts
  9597   Tue Feb 4 17:40:19 2014 manasaUpdateGeneralReady for pump down??


* PRM suspension has not been behaving well. PRM is being kicked around every 5-10 seconds when the PRC is aligned (as seen on REFL camera). We are not sure where this is coming from. The first time we saw this happening was when we were trying to lock PRC at low power even before we took the heavy doors off. So we are pretty sure this is not caused by the foil cover on the OSEMs. We tried turning ON/OFF the oplev servo, turning ON/OFF the damping loops and also checked the connections in the feedthrough and satellite box for the PRM. The OSEM sensor values for the suspension also seem to match the ones on the wiki.


This is solved.

The ASC for PRC for left turned ON. Turning it OFF solved the problem.

If there is no feedback regarding the POP alignment or anything to check with modified PRC length, we will close tomorrow morning.

  9601   Wed Feb 5 15:26:57 2014 manasaUpdateGeneralReady for pump down??



 This sounds great! The only suggestion that I have is for checking POP. If you have the beam on the camera, you can hold a card in front of each mirror, and find out where the edge of the beam is. Introduce the card from the side, and watch for the point where you just start to see the beam on the camera be obstructed. Repeat for the other side, and you have an idea of the centering of the beam. 

I think this is most important for the in-vac mirrors, since the beam is large-ish, and we have to hit both steering mirrors at ~45 degrees.

 [EricQ, Manasa]

This check was done and we had to move one of the steering mirrors in pitch. Else, everything was just fine.

In-vacuum pictures of PR2 and PR3 new positions were taken. MC spot positions measured to be < 1mm and oplevs were centered.

  9602   Wed Feb 5 15:39:41 2014 manasaUpdateGeneralWe are pumping down

[Steve, Manasa]

I checked the alignment one last time. The arms locked, PRM aligned, oplevs centered.

We went ahead and put the heavy doors ON. Steve is pumping down now!

Attachment 1: pre_pump_down.png
  9621   Mon Feb 10 22:21:55 2014 manasaUpdateGreen LockingX and Y arm green tuned

Y arm green: Nothing much was disturbed. I touched the steering mirrors and brought GTRY from 0.2 to 0.9.

X arm green: The PDH lock was not very stable mostly because of the low power in green. I changed the oven temperature for the doubler to 36.4 corresponding to maximum green power. GTRX increased from 0.1 to 0.9

Both the X and Y arm green alignment were tuned on the PSL table to their respective beat PDs.

The PSL green shutter was not responding to the medm buttons. I found the PSL green shutter set to 'local' and 'N.O' (these are switches in the shutter controller). I do not see any elog and not sure as to why the controller was even touched in the first place. I set the shutter controls to 'remote' and 'N.C'.

  9624   Tue Feb 11 21:22:02 2014 manasaUpdateGreen LockingALS X and Y arm restored

The X and Y arms were locked successfully using ALS and the arms could be scanned and held to support IR resonance.

The same procedure as in elog 9219 was followed. In-loop noise was measured to be between 200-300 Hz rms for the lock.

ALS settings for the lock

X arm : FM 2, 3, 5, 6, 7, 8, 10  Gain = 11.0
Y arm : FM 2, 3, 5, 6, 7, 8, 10  Gain = 10.0

  9632   Thu Feb 13 13:18:33 2014 manasaUpdateIOOMC needed some help

The MC has been funny since yesterday. I checked the suspensions INMON channels and they seemed ok. So I went ahead and tweaked the alignment with WFS disabled (yesterday). Although the WFS PDs were cenetered at this point, the WFS servo was throwing the MC in a not-so-happy state. We worked with the WFS servo OFF all of yesterday.

This morning,

* I fine tuned the MC alignment from yesterday (TRANS_SUM > 17800 counts)

* measured the spot positions

* recentered the spots on the WFS PDs (was already quite centered)

*reset the WFS filterbank offsets.

The MC has been locked happily since then with autolocker and WFS servo enabled.

  9638   Fri Feb 14 02:33:09 2014 manasaUpdateGeneralMy IFO time summary

MC tuning

Although the morning MC tuning looked stable, Koji pointed out that the MC_REFL_OFFSET was changed from its nominal value.

The offset was reset and this caused drift in the MC_TRANS_SUM.

To fix this:

- disabled the WFS servo

- aligned MC using MC1 and MC3

- centered beam on the MC_REFL

- reset WFS offsets

- locked MC

MC looks happy now.


ALS locking

ALS is in a very different state from a couple of days ago when we could successfully lock the arms and scan.

The green alignment to the arms had drifted.

PSL green alignment on the PSL table was off. The PSL green was not even on the steering mirror. Did anyone work around the PSL table in the last couple of days?

After aligning and finding the beat note, I found the ALS servo very noisy. The error signal had 10 times more rms noise than what was achieved earlier this week and there were some new 60Hz peaks as well.

Overall, we could not do any PRMI+ALS arms today





  9658   Wed Feb 19 18:21:33 2014 manasaUpdateLSCScripts for ALS modified


We need to change several scripts for use with the new ALS-in-the-LSC paradigm:

* Watch arms (to turn off ALS if we lose the beatnote, before pushing optics too hard)

* Find IR resonance

* Offset from resonance

None of these should be difficult, just changing the filter bank names to match the new ones (ex. LSC-XARM rather than ALS-XARM, and LSC-ALSX rather than ALS-OFFSETTER1). 

So far, I have changed the "find resonance" script (ALSfindIRresonance.py).  I believe, in principle, to first order, that my modifications should work, however I have not yet tested the script.  So.  If you use it, watch the output of the script and ensure it's doing what it ought.  I'll check it after the lunch meeting and update this log entry.  (I changed the name of the "OFSFILT" variable, line 26, and also modified line 114.  Both of those lines have comments on how to revert the changes).

I have also changed the "offset from resonance" script (ALSchangeOffset.py).  Again, since I'm not locking right now, I have not tested this script either.  So, pay attention if you need to use it, before I check it.  (I changed the name of the OFSFILT variable, and the check which arm logic around line 37.  Again, both of those lines have comments on how to revert the changes.)

Watch arms script (ALSdown.py) has been modified and now watches the LSC-$ARM filter module instead of the ALS-$ARM filter module. Threshold has been kept the same +/-5000 counts to the ETM suspensions. The script has been tested and works just fine. It exists in the same place scripts/ALS/.

Jenne's modified versions of ALSfindResonance.py and ALSchangeOffset.py were tested and work just fine.

  9695   Wed Mar 5 19:27:24 2014 manasaUpdateIOOMC calmed down

The IMC has not been behaving well since this morning and totally not happy when Q was finishing his measurements. The WFS servo had large offsets in pitch. Looking back at the trend and using ezcaservo to restore the suspensions did not help.

I realigned the IMC and brought TRANS SUM to ~18000 and MCREFL to < 0.5. The spot positions are not very good; nearly 2 mm off in pitch on MC1 and MC3. But after the alignment of MC, the WFS servo offsets were below +/-20.

The MC has been locked stably with WFS servo ON for the last few hours.

P.S. I did not touch the WFS pointing or reset the WFS offsets.

  9696   Wed Mar 5 22:32:21 2014 manasaUpdateLSCStuck at step 2


Step by step description of transition from 2arm ALS to Common/Differential LSC for FPMI

- Step 0: Place the frequencies of the arm green beams at the opposite side of the carrier green.

- Step 1: Activate stablization loops for ALSX and ALSY simultaneously.
  (Use LSC filter modules for the control. This still requires correct handling of the servo and filter module triggers)

- Step 2: Activate stablization loops for ALS Common and Differential by actuating ETMX and ETMY

I locked the arms using ALS error signals and the LSC filter modules. But when I try to acquire CARM and DARM using ALS, the arms lose lock when the matrix elements ALSX to Yarm and ALSY to X arm reach -/+0.9

What I did:

1. ALS locking of arms
(i) Found arm beat notes
(ii) Input matrix POX and POY elements set to '0'
(iii) Aux matrix elements ALSX to Xarm and ALSY to Y arm set to '1'
(iv) Power normalization matrix elements for TRX and TRY set to '0'
(v) Triggers for arm lock over ridden and the FM triggers were set to 'manual'
(vi) Arm servo gains set to '0'
(vii) All but FM5 were disabled
(viii) Phase tracker history reset and servo actuation set to ETMs
(ix) Servo gain increased in steps (+/-10 for the arms)
(x) FM1, FM6, FM7 enabled (see note 1 below)
(xi) FM9 enabled

Arms were locked with ~2000Hz rms

2. CARM and DARM locking
(i) Scanned the arms for IR resonance
(ii) Moved off-resonance (Stepped arm servo offsets by 30 counts)
(iiI) Stepped matrix elements ALSY to X arm and ALSX to Y arm ezcastep C1:LSC-PD_DOF_MTRX_6_29 +-0.1 C1:LSC-PD_DOF_MTRX_7_28 +0.1

Whenever the matrix elements reached -/+0.9, the arms were kicked out of lock. I don't see anything obvious as to why this is happening even after nearly 10+times of redoing.

1. I found the filters for the arm servos different for X and Y. FM1 and FM8 were missing in one of the filter modules. Jenne remembered Rana modifying and removing the unnecessary filters in one arm. We put back FM1 (low pass filter) which might not be necessary for PDH lock but is necessary for ALS. FM8 is now added to FM7.
2. To self : Check ALS Y arm power outlets (60Hz frequency comb seen in the error signal)

ELOG V3.1.3-