40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 218 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  8534   Tue May 7 03:25:28 2013 JenneUpdateIOOMC WFS drifting??

I'm not sure why, but starting ~3.5 hours ago, the WFS seem to not be holding the MC in optimal alignment. 

The WFS are definitely engaged and the loops are closed, but every time the MC locks, the WFS pitch and yaw values start drifting off.  In particular, the WFS loop actuation pushing on MC2 is in the many hundreds of counts after ~90 minutes of drift time.  I tried offloading those values by moving the MC2 slider, but then I unlocked the MC to check what that did to the alignment, and it was decidedly bad.  So, I'm not sure what's up with the WFS, but I need to look at it tomorrow.

  1196   Fri Dec 19 14:35:58 2008 Yoichi AlbertoUpdateIOOMC WFS and IOO-POS QPD re-centering
For the past two days, the MC alignment has kept drifting.
This morning, the MC alignment was so bad that it wouldn't lock to the TEM00 mode.
We aligned the MC mirrors manually until the reflection looks like a nice bull's-eye (the WFSs were off at this moment).
Then we un-locked the MC and centered the beams on the WFS QPDs.
Since the QPDs were saturated with the full laser power falling on them, I reduced the PSL power by turning the HWP after the MOPA.
After this, we turned on the WFSs and everything looks normal now.
We will see the trend of the MC related channels to monitor the drift.

Although unlikely, it might be caused by the drift of the input beam to the MC.
We found that the IOO-POS QPD was mis-centered and saturating.
We replaced the BS picking up the beam for the QPD from 33% reflection to 10% one. The QPD was still saturated.
So we put the 33% BS in the beam path to the QPD to further reduce the power. The beam kicked by the 33% BS
is dumped to a black aluminum plate. We should use a better beam dump later.
Now the IOO-POS QPD should tell us some information about the beam pointing of the PSL, though it has no sensitivity
to the relative motion of the PSL table to the vacuum chambers.
  7452   Fri Sep 28 21:17:41 2012 KojiUpdateIOOMC WFS adjustment

MC WFS was fixed. Now it is running constantly with the autolocker.

Found a bug in the IOO screen: All of the 6 WFS signal indicators is liked to the same info (C1:IOO-MC1_PIT_OUTPUT).
Fix this, Jenne! Baaaaagghhhhh! 

What I did:

1. C1:IOO-MC_RFPD_DCMON indicator was saturating. "HOPR" of this entry was  set to 5 by running the following command:


2. Scan MC2 spot position by using /opt/rtcds/caltech/c1/scripts/MC/moveMC2 scripts.
or the adjustment, C1:SUS-MC2_ASCPIT_EXC and C1:SUS-MC2_ASCYAW_EXC were excited with 300cnt at 12Hz and 10Hz, respectively.
The corresponding peaks (i.e. ANgle to length coupling) in C1:IOO-MC_F were monitored on DTT and adjusted so that the peaks are approximately nulled.

3. moveMC2 scripts are not perect to keep the maximum of the transmission. So, the alignment was adjusted with MC1 and MC3.

4. Repeated 2 and 3 until the alignment converges.

5. Once I got satisfied with the MC2 spot position, I went to the MC2 table and aligned the steering mirror before the QPD.

6. As these actions above moves the REFL beam, I went to the MC REFL path and adjusted the MC REFL PD position and the MC WFS spot positions.

7. Checked if the alignment is still good. The MC REFL is 0.50~0.51. Pretty good.

8. Run /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets to register the current WFS offset etc.

9. At this point, MC WFS started working fine. I also confirmed the autolocker worked with this setting.


Checked how the things are going in the morning. There were several unlocks. But the autolocker and WFS kept the cavity lcoked again.
Very good.

Some power fluctuation of ~1% is observed in the MC trans. I checked the PMC trans and found it is also fluctuating by 1% in a coherent way.
So I judge the WFS itself is fine. (See attached)



Attachment 1: MC_WFS_12h.png
  7455   Mon Oct 1 11:08:25 2012 JenneUpdateIOOMC WFS adjustment


Found a bug in the IOO screen: All of the 6 WFS signal indicators is liked to the same info (C1:IOO-MC1_PIT_OUTPUT).
Fix this, Jenne! Baaaaagghhhhh! 

 My bad.  As it turns out, you can't copy and paste between MEDM instances.  It is now fixed.

  10424   Fri Aug 22 15:11:55 2014 andres, nicolasSummaryIOOMC WFS activity

1. Before doing anything, we centered the IOO QPDs.
2. With the WFS enabled, we offloaded the control signals onto the bias sliders. Then we saved the slider values. The MC LSC diode had a DC value of ~0.5
3. Turned down power with half wave plate before PMC.  Power injected to vacuum ~ 100mW.
4. We did a beam scan of MC REFL, it looks smaller than what Andres predicted based on the MC eigenmode by 10-20%.
5. We made many changes on the table, pictures to be added by Andres.
6. We didn't have the 80% reflector we wanted to increase the WFS power, so it's still a 98%.
6. Beams were aligned on MC REFL PL, camera, beam dumps, WFSs.
7. Clean up
8. PSL power increased to 1.2W, MC locked right away.
9 We didn't change the IOO WFS output matrix, but we changed some signs and gains to make everything stable. MC autolocker brings it back from cold just fine.
10. All time bombs that we've left will be E.Q.'s to clean up. Sorry.\
11. Yay

  10425   Fri Aug 22 15:58:02 2014 SteveSummaryIOOMC WFS activity



Attachment 1: GoyphaseSet.png
  455   Sun Apr 27 05:09:30 2008 ranaConfigurationIOOMC WFS Whitening turned on
I hardwired on the MC WFS whitening filters.

The MAX333A switches which choose between whitening and bypass on that board were in the bypass position
because the Xycom220 connections are not there. So the control switch gets +15V but there is no pull
down to set it to the whitened mode.

The least invasive (easiest) change I could do was to tie all of those inputs to ground. This pulls a few mA
through the pull-down resistors but is otherwise innocuous. All of these control lines come in on the A-row
of the P1 connector, so I was able to solder a single wire across all of them to ground them all.

The WFS2 board had a blown electrolytic capacitor on the -15 V line and so there was probably some extra noise
getting in that way. I couldn't find any extra SMD to replace it so I cut the legs off of a 22 uF polarized
tantalum and stuck it in there. Its even close to being the same color. I checked out the other caps, and they were all
close to 68 uF as spec'd. This one had luckily blown open and so didn't suck down the Sorensen and destroy everything.

Plugged everything back in switched the WFS servos back on. Looks good. Took before and after spectra.

In the plot:

GREEN: Open loop dark noise before changes
RED: Open loop bright (MC locked but MCWFS off)
BLUE: Closed loop, MC locked

BLACK: Dark noise after whitening
ORANGE:Closed loop after whitening

The cursor is at 16.25 Hz, the SOS bounce mode.

The I ran the new setMCWFSgains script which uses pzgain to set the UGFs of the 4 loops to 4.01 Hz.
We have in the past had problems with high WFS gains causing instabilities with the CM servo around 10-30 Hz. If this happens we should
just lower the gain by a factor of ~5.
Attachment 1: mcnoise.png
  5840   Tue Nov 8 12:07:08 2011 SureshUpdateIOOMC WFS Servo: suppression of WFS error signals below 3Hz

I switched on the WFS servos with the output matrix (open loop) determined last Friday.  Only the WFS1Pit, WFS2Pit, WFS1Yaw and WFS2Yaw servo filters are now on.   I then adjusted the gains to obtain maximum suppresson of error signals without oscillations in the loops

I now proceed to determine the output matrix again.


  5883   Sat Nov 12 03:46:55 2011 SureshUpdateIOOMC WFS Servo: Open loop gain

[Mirko, Suresh]

I closed the WFS loops and measured the transfer function from IN2 to IN1 testpoints on the WFS1_PIT filterbank. 

We looked at the filter shape consisting of

1) Integrator: zpk([0.8],[0],0.8,"n")

2) zpk([0.8],[100,100],1,"n")

3) zpk([1:10],[3,30],1,"n")

The combined filter shape (along with an added pendulum filter, zpk([ ],0.8,1,"n")  ) is given below



The OL Transfer function measured for WFS1_PIT loop is


 The blue reference is a measurement  without the third "45 deg" filter in the list above.  Without it the UGF is around 1.5Hz and increasing the gain results in additional noise from the servo bump seen in the earlier elog .  With it the UGF is around 3Hz.

The supression of the error signal is shown here


The other WFS loops are expected to have a similar behaviour with the exception of the MC2 QPD channels.  I will measure their OLTF shortly and then proceed with the inclusion of the QPD sensors into the WFS system.



  5884   Sat Nov 12 08:09:47 2011 ranaUpdateIOOMC WFS Servo: Open loop gain

Somehow, I generically don't like the idea of lead filters for the WFS loops. We don't really need so much bandwidth. I think you should include with the servo measurements, a servo model ( on the same plot ) that matches the loop shape.

For example, this means including the 28 Hz ELP in the MC1/3 hardware and MC2 ASCPIT/YAW digital filter banks. BY comparing the model v. measurement we can determine if the cross-coupling due to imperfect output matrix is very serious or not.

In the measurements, the loop with the most low frequency gain looks the most promising.

  5892   Tue Nov 15 01:44:36 2011 SureshUpdateIOOMC WFS Servo: Open loop gain


Somehow, I generically don't like the idea of lead filters for the WFS loops. We don't really need so much bandwidth. I think you should include with the servo measurements, a servo model ( on the same plot ) that matches the loop shape.

For example, this means including the 28 Hz ELP in the MC1/3 hardware and MC2 ASCPIT/YAW digital filter banks. BY comparing the model v. measurement we can determine if the cross-coupling due to imperfect output matrix is very serious or not.

In the measurements, the loop with the most low frequency gain looks the most promising.

WFS1_PIT servo replotted with foton data overlaid:

I included the following filters in foton:

1) Integrator: zpk([0.8],[0],0.8,"n")

2) zpk([0.8],[100,100],1,"n")

3) zpk([1:10],[3,30],1,"n")

4) ELP28

I have unwound the phase by adding or subtracting 180 to portions of the phase data.

And here is the plot for WFS1_PIT.  I will repeat this process for the other three WFS loops tomorrow.



  5904   Wed Nov 16 08:57:08 2011 SureshUpdateIOOMC WFS Servo OLG data and fits

I measured the Transfer Functions between from IN2 to IN1 on the WFS1PIT, WFS2PIT, WFS1YAW and WFS2YAW servo loops. 

Then I used the foton filter profiles of the servo filters in the loop and added another one to simulate the pendulum to generate a reasonable fit to the data.  Only the pendulum filter was hand tweaked since the PIT and YAW pendula have different resonant frequencies.

The filter modules included are:

1) Integrator: zpk([0.8],[0],0.8,"n")

2) Phase lead: zpk([0.8],[100,100],1,"n")

3) 45 deg filter: zpk([1:10],[3,30],1,"n")

4) ELP28: ellip("LowPass",5,1,50,28)

5)Pendulum: zpk([ ],0.03+i*0.82;0.03+i*0.82;],1,"n"  (for YAW)

5)Pendulum: zpk([ ],0.05+i*0.68;0.05+i*0.68;],1,"n"  (for PIT)

The data and fits are below.   The UGF is around 2 to 3 Hz and there is no servo bump at this gain setting.  The fits are poor at and below the resonance because the coherence was poor at these frequencies.  I will have to do a swept sine measurement for these low frequencies.

WFS1PITservo.png  WFS2PITservo.pngWFS1YAWservo.png  WFS2YAWservo.png

  5668   Sat Oct 15 04:53:41 2011 SureshUpdateIOOMC WFS Output Matrix determination

After we had a rough idea of what the output matrix looks like (see this elog),
I tried to measure the transfer function coefs (TFCs) between mirror degrees of freedom and the WFS sensors (WFS1, WFS2 and MC_Trans QPD)
I found that the TFCs that I obtained at 10.15 Hz did not have any resemblance to the previously identified output matrix.

The problem, I realised, arises because the various lockins used
in the C1IOO model do not have the same relative phase; So if we try to excite a mirror with one of them
and demodulate a sensor signal on any of the other lockins the resulting output would not have the correct phase
(relative to the 1st lockin output). As a result unless we can reset the phase of all the lockins
simultaneously, we cannot demodulate multiple signals at the same time. (Joe/Jamie, Is it possible to
reset/reinitialise the phase of the CLK signals of the lockings? )

To get around this problem Koji suggested that I use just one lockin and determine all the 36 elements of the transfer matrix with it one at a
time rather than six at a time. When I did that, I got results consistent with the previoulsly determined outmatrix. It, of course, takes six times longer.

The matrix I first got is this one


MC1P 0.332 0.518 0.316 0.019 0.066 0.000
  5.832 1.892 8.180 38.285 8.807 0.000
MC2P 0.355 1.798 0.342 0.023 0.144 0.000
  72.977 76.683 76.804 -16.364 77.451 71.579
MC3P 0.352 0.394 0.254 0.036 0.023 0.000
  2.005 3.249 6.249 5.712 26.349 NAN
MC1Y 0.051 0.055 0.058 0.788 1.024 0.001
  15.979 -4.487 -9.707 2.642 1.276 0.000
MC2Y 0.142 0.044 0.130 1.966 0.579 0.017
  70.044 83.818 76.397 74.283 76.134 77.269
MC3Y 0.044 0.052 0.022 0.080 0.948 0.194
  22.932 14.227 -45.924 9.677 1.125 1.124
Which can be  recast as below          
MC1P 0.332 0.518 0.316 0.02 0.07 0
MC2P 0.355 1.798 0.342 0.02 0.14 0
MC3P 0.352 0.394 0.254 0.04 0.02 0
MC1Y 0.05 0.05 0.06 0.788 1.024 0.001
MC2Y 0.14 0.04 0.13 1.966 0.579 0.017
MC3Y 0.04 0.05 0.02 0.080 0.948 0.194

MC1P 5.8 1.9 8.2 38.3 8.8 0.0
MC2P 73.0 76.7 76.8 -16.4 77.5 71.6
MC3P 2.0 3.2 6.2 5.7 26.3 NA
MC1Y 16.0 -4.5 -9.7 2.6 1.3 0.0
MC2Y 70.0 83.8 76.4 74.3 76.1 77.3
MC3Y 22.9 14.2 -45.9 9.7 1.1 1.1


Note that when MC2 is excited all the sensors showed a response about 75 deg out of phase with the reference (MC1 --> WFS1_PIT ) This was traced to the fact that while there is a 28Hz Elliptic LP filter on

both MC1 and MC3, while it is absent on MC2.  The Transfer functions  below show the difference in the phase of their response



Since the MC2 POS is used in servos involving MCL we cannot afford to install a 28 Hz LP filter into the MC2 coil drivers.  However a module with the 28 Hz ELP was switched on, in each of the

 MC2 PIT and YAW filter banks.   I then checked to see if this has affected the relative phase of variour sensors.  The Phase angle between I and Q on each sensor channel was checked and corrected. 

Below are the spectra with the "before" and "after" correction of phases.


 WFS1_IQphase20111015_1.pdf        WFS2_IQphase20111015_1.pdf


Obviously this needed adjustment to reduce Q phase.   

  After twealkng the angle "R":

WFS1_IQphase20111015_2.pdf      WFS2_IQphase20111015_2.pdf


And again determined the transfer matrix (below). 

MC1P 0.236 -0.300 0.229 0.049 -0.008 0.000
  0.015 -0.004 -0.027 0.011 -0.019 0.000
MC2P -0.125 -0.962 -0.135 0.114 0.028 0.000
  0.007 -0.052 -0.028 -0.004 -0.002 0.000
MC3P -0.225 -0.254 -0.255 -0.026 -0.010 0.000
  0.004 -0.012 -0.010 0.009 0.002 0.000
MC1Y -0.059 -0.023 -0.040 0.460 0.705 0.001
  0.004 0.003 0.009 0.009 0.017 0.000
MC2Y 0.030 0.190 0.040 -1.144 -0.296 0.015
  0.007 0.006 -0.009 -0.038 -0.009 0.001
MC3Y 0.018 -0.108 -0.018 0.134 -0.832 -0.001
  0.017 0.005 0.001 0.006 -0.016 0.000

MC1P 0.236 0.300 0.231 0.05 0.02 0
MC2P 0.125 0.964 0.138 0.11 0.03 0
MC3P 0.225 0.254 0.255 0.03 0.01 0
MC1Y 0.06 0.02 0.04 0.460 0.705 0.001
MC2Y 0.03 0.01 0.19 1.145 0.296 0.015
MC3Y 0.02 0.11 0.02 0.134 0.832 0.001

MC1P 3.694 0.784 -6.778 13.1 66.67 #DIV/0!
MC2P -3.214 3.100 11.557 -2.05 -4.48 0
MC3P -1.020 2.665 2.158 -19.1 -10.76 NA
MC1Y -3.96 -6.45 -12.14 1.085 1.357 0.000
MC2Y 13.22 41.08 -2.6 1.887 1.706 4.987
MC3Y 42.69 -2.56 -3.73 2.652 1.068 0.000


This time the signals are all nearly in the same phase and in agreement with the  outmatrix estimate made earlier.


I plugged these TFCs into the matrix inversion code: wfsmatrix2.m.   And get the following inverse:


  WFS1P_Act WFS2P_Act MC_Trans_P_Act WFS1Y_Act WFS2Y_Act MC_TRANS_Y_Act
MC1P 1 -0.64        
MC2P -0.27 -1        
MC3P 0.98 -0.65        
MC1Y       -0.26 -1  
MC2Y       1 0.12  
MC3Y       0.16 0.07  


I have ignored the MC2_Trans_P and Y sensors for now.

  5669   Sat Oct 15 10:58:32 2011 ranaUpdateIOOMC WFS Output Matrix determination

In order to save time and sanity, you should not measure the pitch ->yaw and yaw-> pitch. It makes things too complicated and so far is just not significant. In the past we do not use these for the matrix work.

i.e. there should just be a 3x3 pitch matrix and a 3x3 yaw matrix. Once the loops are working we could investigate these things, but its really a very fine tweak at the end. There are quite a few other, more significant effects to handle before then.

To make things faster, I think we can just make a LOCKIN which has 3 inputs: it would have one oscillator, but 6 mixers. Should be simple to make.

  11720   Wed Oct 28 14:07:44 2015 KojiUpdateIOOMC WFS Offsets update

MC WFS offsets were updated to have a better operating point.

  454   Sun Apr 27 02:11:11 2008 ranaConfigurationIOOMC WFS Notes
As noted in the elog from Friday, the WFS has been bad ever since someone switched on the digital whitening filters (FM1 & FM2)
in the MC WFS I&Q filter banks.

On Friday evening, John, Alan, and I went to the rack and verified that although the drawing shows a hookup for the whitening
filters, there is actually no such thing and so we can't have the whitening. So the anti-whitening turns on two lag filters
(2 poles at 4 Hz) and without the hardware this makes the servos unstable by adding 90 deg of phase lag at 4 Hz.

There are still several problems in this system:
- AD797 is used after the mixer. This is an unreliable, noisy part. We need to change this out
  with some OP27s so that this becomes reliable and has a more reasonable noise figure.

- Hard wire the whitening filters ON. We never want these to be off. Then we can turn on the
  anti-whitening. This will give us a factor of 100 better noise without filtering.

- The AD602 on the front of the whitening board has a 100 Ohm internal impedance and the 
  resistor between the demod board and the AD602 is 909 Ohms. This results in dividing the
  signal by 10.

- The signal at the ADC is ~100 cts peak-peak. The full ADC range is, of course, 65000 cts. So
  we could use a lot more gain. The mean quadrant signals are also ~100 cts so we could easily
  up the analog DC gain by a factor of 30 on top of the whitening filter increase.

- The AD602 at the input and the AD620 on the output are both variable gain stages but because
  of our lack of control are set to ambiguous gain levels. We should set the AD602 on the input
  to its max gain of 30 dB. With the -20 dB from the x10 voltage division, this will give us
  an overall gain of 3 for the puny demod signals.

  9207   Sun Oct 6 20:55:08 2013 ranaSummaryASCMC WFS Limits set based on 40 days of trends

MC3 watchdog gets tripped sometimes when lock is lost. I noticed that there were no limits set in the MC WFS drive. The attached plot shows that over 40 days, the OUT16 channels from the WFS don't exceed 1000 counts. So I've set the limit to be 2000 in all 6 of the MC ASCPIT/YAW filter banks. Please don't turn them off.

OUT16 is really not the right way to measure this, but for some reason, we don't have any DQ channels from the MC WFS screen ??? So we're not able to measure the trend of the high frequency drive signal.

So I added the WFS(1,2)_I_(PIT,YAW)_OUT_DQ and WFS(1,2)_(PIT,YAW)_OUT_DQ channels to the c1ioo.mdl at 2048 Hz. I used Jamie's excellent 'rtcds' utility to build and install:

1) after making the edits to c1ioo.mdl I saved the file/

2) sshing to c1ioo

3) rtcds stop c1ioo

4) rtcds make c1ioo

5) rtcds install c1ioo

6) rtcds start c1ioo

7) telnet fb 8087

8) daqd> shutdown

That seemed to do it OK.

Unfortunately, all of the instructions that we have in the Wiki for adding channels and model building are misleading and don't mention any of this. There are a few different methods listed which all instruct us to do the whole make and make install business in a bunch of non existent directories.

Attachment 1: mcwrfs_trend.png
  5683   Mon Oct 17 23:56:34 2011 SureshUpdateIOOMC WFS Integrators switched on and WFS_MASTER screen updated

[Rana, Suresh]

     To see if the loops will stay locked when the Integrators in the servo are switched on, we stayed with the same simple output matrix (just 1 or -1 elements) and switched on the FM1 on all WFS servo filter banks.  We monitored the time domain error signals to see if engaging the locks made the error signals go to zero.  Most of the error signals did go to zero even when an intentional offset was introduced into the MC pitch of the suspension.

      We need to include TestPoints just before the Input Servo Matrix so that we can monitor the error signals without being affected by the gain changes in the WFS_GAIN slider.   These are currently not present in the C1IOO model and the position of the WFS_GAIN also has to be shifted to the other side of the Input matrix.

      The C1IOO_WFS_MASTER screen has been changed to the new one.  This incorporates filter banks for the MC_TRANS_P and _Y channels.  The screen is not yet fully functional but I am working on it and I it will continue to improve it.


  12640   Wed Nov 23 20:08:51 2016 Koji, ranaUpdateIOOMC WFS Demod/Whitening boards removed from the IOO rack

We removed one set of the MC WFS demod board and whitening board from the IOO rack for the investigation.
The MC WFS servo loops are disabled with the EPICS screens.
Let us know when you need the MC WFS boards to be returned to the rack.

This is to investigate the signal chain and fix some issues. We ramped down the -100 V supply for the WFS QPD bias (why is it so big?), but everything else is still on. Koji is doing demod board. Rana will upload a marked up WFS whitening board schematic soon.

  867   Thu Aug 21 17:55:14 2008 ranaHowToIOOMC WFS DC Offsets
I ran the McWFS_dc_offsets script to trim out the DC offsets on the MC WFS DC signals.

Rob says "who cares?"
  868   Thu Aug 21 18:13:24 2008 ranaUpdateIOOMC WFS Control signals not responsible for lock losses
This is a 4 hour, second-trend of the MC WFS error and control signals.

There is no sign that the MC loses lock because of feedback signal saturations.
Attachment 1: Untitled.png
  372   Wed Mar 12 23:05:44 2008 ranaUpdateIOOMC WFS
they are bad, somewhat

please fix
  601   Mon Jun 30 09:46:15 2008 JohnUpdateIOOMC WFS
MC WFS are on. They seem to do some good during the day.
  1556   Thu May 7 17:59:23 2009 AlbertoConfiguration MC WFS
This afternoon the MC could not get locked.
I first checked the Osems values at the MC mirrors and compared them to the trend of the last few hours. That showed that the alignment of the mirrors had slightly changed. I then brought each mirror back to its old alignment state.
That let the LSC loop lock the MC, although the reflected power was still high (1.5V) and the WFS control wouldn't engage.
Since earlier during the day I was working on the AS table, it is possible that I inadvertently hit the MC REFL beam splitter misaligning the beam to the MC WFS.
To exclude that there was a problem in the suspensions, before touching the WFS, I checked that the cables at the MC's ends and those going to the ADC in the rack were well pushed in.
Then I proceeded in centering the beam on both the WFS, balancing the power over the QPDs.
In the end the MC could lock again properly.
  1080   Thu Oct 23 23:09:18 2008 YoichiUpdatePSLMC UGF is now 75kHz
I measured three loop transfer functions of the MC servo.
The blue curve in the first attachment is the overall open loop gain of the servo measured using
the sum-amp A of the MC board (it is the sum-amp in the common part).
The red curve is the transfer function measured by the sum-amp B of the MC board, which is in the VCO path.
Mathematically the measured transfer function is G_vco/(1+G_L), where G_L is the loop gain of the length path
and G_vco is the loop gain of the VCO path.
The green curve is G_L/(1+G_vco) which was measured from dtt by using C1:SUS-MC2_MCL_EXC.
The UGF of the MC loop is 75kHz with the phase margin of 27deg.
The cross over frequency of the two loops is 43Hz. The phase margin there seems OK.

The second attachment is the comparison of the MC open loop TF measured on Sep. 4 (old) and today (new).
The increased bandwidth of the FSS gave us a slight gain in the phase margin and the elimination of
the slight bump in the gain around 150kHz existed in the blue curve.
Attachment 1: MC_Loop.png
Attachment 2: OldAndNew.png
  14950   Tue Oct 8 10:29:19 2019 gautamUpdateIOOMC Transmission scan


There is ~ 7% variation in the power seen by the MC2 trans QPD, depending on the WFS offsets applied to the MC2 PIT/YAW loops. Some more interpretation is required however, before attributing this to spot-position-dependent loss variation inside the IMC cavity.


Attachment #1This shows a scatter plot of the MC2 transmission and IMC REFL average values after the WFS loops have converged to the set offset positions. The size of the points are proportional to the normalized variance of the quantity. The purpose of this plot is to show that there is significant variation of the transmission, much more than the variance of an individual datapoint during the course of the averaging (again, the size of the circles is only meant to be indicative, the actual variance in counts is much smaller and wouldn't be visible on this plot scale). For a critically coupled cavity, I would have expected that the TRANS/REFL to be perfectly anti-correlated, but in fact, they are, if anything, correleated. So maybe the WFS loops aren't exactly converging to optimize the inoput pointing for a given offset? 

Attachment #2Maps of the transmission/reflection as a function of the (YAW, PIT) offset applied. The radial coordinate does not yet mean anything physical - I have to figure out the calibration from offset counts to spot position motion on the optic in mm, to get an idea for how much we scanned the surface of the optic relative to the beam size. The gray circles indicate the datapoints, while the colormaps are scipy-based interpolation. 

Attachment #3After talking with Koji, I explicitly show the correlation structure between the IMC REFL DCMON and MC2 TRANS. The shaded ellipses indicate the 1, 2 and 3-sigma bounds for the 2D dataset going radially outwards. The correlation coefficient for this dataset is 0.46, which implies moderate positive correlation. 🤔 

Scan algorithm:

The following was implemented in a python scipt:

  1. Choose 2 independent random numbers from the uniform distribution in the interval [-0.5, 0.5] (in uncalibrated counts).
  2. One of these numebrs is set as the error point offset for the QPD spot-centering PITCH WFS loop, while the other is the YAW offset.
  3. Wait for 600 seconds - this long wait is required because the step-response time for these loops is long. 
  4. If there is an MC unlock event - wait till the MC relocks, and then another 600 seconds, to give the WFS loops sufficient time to converge.
  5. Once the WFS loops have converged, average a few data channels (MC TRANS, REFL, WFS loop error points etc) for 10 seconds, and write these to a file.

I am now setting the offsets to the WFS QPD loop to the place where there was maximum transmission, to see if this is repeatable. In fact it was. Looking at the QPD segment outputs, I noticed that the MC2 transmission spot was rather off-center on the photodiode. So I went to the MC2 in-air optical table and centered the beam till the output on the 4 segments were more balanced, see Attachment #4. Then I re-set the MC2 QPD offsets and re-enabled the WFS servos. The transmission is now a little lower at ~14,500 counts (but still higher than the ~14200 counts we had before), presumably because we have more of the brightest part of the beam falling on the gap between quadrants. For a more reliable measurement, we should use a single-element photodiode for the MC2 transmission.

  • Overnight, I'm going to run the MC2 spot position scanning code (in a tmux session on pianosa, started ~945pm) to see if we can find a place where the transmission is higher,
Attachment 1: MC2_transmission_scatter.pdf
Attachment 2: transmissionMaps.pdf
Attachment 3: correlStructure.pdf
  5612   Tue Oct 4 14:41:47 2011 JenneUpdateIOOMC Trans channels are digital 0

I relocked the PMC (why is it unlocking so much lately??), and then noticed that even though the MC is locked, MC Trans Sum, P, Y, are all seeing digital zero.  I'm putting Suresh, as IOO guy, in charge of figuring it out.

  5614   Tue Oct 4 15:57:30 2011 SureshUpdateIOOMC Trans channels are digital 0

I thought this problem might be arising because the MC2_TRANS QPD signals are not being passed from the c1mcs to c1ioo models over the rfm.   But there was no way to check if there is any data being picked up in c1mcs model.  So I copied the MCTRANS block from the c1ioo model into the c1mcs.  This block takes the four segments of the MC2_TRANS QPD and computes the pitch, yaw and sum signals from that.   It also exports these into epics channels.  I then recompiled and started the c1ioo c1mcs and c1rfm models. 

Restared fb at

Tue Oct  4 15:19:10 PDT 2011

Koji then noted that the MC2_TRANS filter banks in c1rfm and in c1ioo were showing nonzero values.   So the signals were infact reaching the c1ioo model.  They were being blocked by the INMATRIX (which the autoburt had not restored) of the MC_TRANS block, because all its elements were zero.  We burtrestored the c1iooepics to about 30hrs ago and then MC_TRANS signals were back in the LOCK_MC screen.


  5012   Thu Jul 21 12:19:29 2011 Jamie, KiwamuUpdateIOOMC Trans QPD working, now locking

It turns out that the MC_TRANS_SUM signal was being derived from the SUS-MC2_OL_SUM_INMON channel in the ioo.db file. 

However, this channel name was recently changed to SUS-MC2_OLSUM_INMON (no underscore between OL and SUM) when

I added the new OL_SUM epics channel to the sus_single_control library model (I forgot to mention it in my previous log on this change,

apologies).  This is why there appeared to be no signal.  This was also what was preventing the mode cleaner from locking, since

the MC_TRANS_SUM signal is used as a trigger in the MC autolocker script.

We modified the ioo.db file at /cvs/cds/caltech/target/c1iool0/ioo.db [0,1] to change the name of the channel that the

C1:IOO-MC_TRANS_SUM signal is derived from.  The diff on the ioo.db file is:

--- /cvs/cds/caltech/target/c1iool0/ioo.db	2011-07-21 11:43:44.000000000 -0700
+++ /cvs/cds/caltech/target/c1iool0/ioo.db.2011Jul21	2011-07-21 11:43:36.000000000 -0700
@@ -303,7 +303,7 @@
         field(DESC,"MC2 Trans QPD Sum")
-        field(INPA, "C1:SUS-MC2_OLSUM_INMON")
+        field(INPA, "C1:SUS-MC2_OL_SUM_INMON")
         field(SCAN, ".1 second")
         field(CALC, "A+0.001")

We then rebooted the c1iool0 machine, and when it came back up the MC_TRANS_SUM channel was showing the correct values.

We then found that the MC autolocker was not running, presumably because it had crashed after the channel rename?

In any event, we logged in to op340m and restarted the autolockerMCmain40m script.

The mode cleaner is now locked.

[0] Rana's log where this was initially defined

[1] All of the slow channel stuff is still in the old /cvs/cds/caltech path.  This needs to be fixed.


  5009   Wed Jul 20 23:31:44 2011 SureshUpdateIOOMC Trans QPD is down


The mode cleaner is not locking because the MC Trans QPD signal is not present.  There is light on the QPD when the MC flashes and its position has not shifted.  The cable is plugged in well into the sensor head.  The signal cable is labled "MC2 Opt Lever"  and it arrives on the 1X4 rack along with other Optical Lever cables. Pressing the connector in did not solve the problem.


  2256   Thu Nov 12 16:13:05 2009 AlbertoUpdatePSLMC Trans Offset

On Rana's suggestion I checked the MC transmission QPD (C1:IOO-MC_TRANS_SUM). I found that the readout is almost zero when the MC is unlocked.

I unlocked the Mode Cleaner turning off the LSC control and disabling the autolocker. The QPD reads 0.014. It seems that there is no offset.

I also checked with the IR card around the photodetector and I didn't see any stray beam.

  2258   Thu Nov 12 17:15:43 2009 KojiUpdatePSLMC Trans Offset

OK. I have been keeping my eyes on the MC transmission. In deed, the MC trans has been well kept at around 7.7 since the last PSL work.
Even it was over the 8 today!


On Rana's suggestion I checked the MC transmission QPD (C1:IOO-MC_TRANS_SUM). I found that the readout is almost zero when the MC is unlocked.

I unlocked the Mode Cleaner turning off the LSC control and disabling the autolocker. The QPD reads 0.014. It seems that there is no offset.

I also checked with the IR card around the photodetector and I didn't see any stray beam.


Attachment 1: MC_TRANS.png
  2260   Thu Nov 12 17:42:04 2009 KojiUpdatePSLMC Trans Offset

PC_DRIVE is also improving after the last PSL work!


OK. I have been keeping my eyes on the MC transmission. In deed, the MC trans has been well kept at around 7.7 since the last PSL work.
Even it was over the 8 today!


Attachment 1: PC_DRV.png
  3882   Mon Nov 8 18:30:33 2010 SureshUpdateIOOMC Trans Mon QPD gain increased by 50x

Increased the transimpedance gain of the MC-Trans-Mon QPD ckt

The gain of this QPD was insufficient to see the light transmitted through the MC2.  The resulting voltage output was about  10 steps of the 16-bit ADC card.  As the input power, which is currently held at about 40mW may be increased to the vicinity of 2W (total output of the NPRO) we would have 500 ADC steps.  But the dynamic range of the ADC is 64k and  increasing the gain of this QPD ckt by a factor of 50 would enable us to utilise this dynamic range effectively.  However as we do not need a response faster than 10Hz from this ckt its response time has been limited by increasing the feedback capacitance value.

The ckt diagram for the QPD ckt is D980325-Rev-C1  .  The particular unit we are dealing with has the Serial No. 110.  The resistors R1, R2, R3, R4 are now 499 kOhm.  As per the guidelines in the ckt diagram, we increased the capacitance values C3,C4,C5,C6 to 2.2 nFThe current cut off frequency for the MC-Trans-Mon is 145 Hz (computed).

Initially, while reassembling the QPD unit, the IDC 16 connector to the ckt board was reversed by mistake and resulted in the OP497 chip over-heating.  Consequently one of the opamps on the chip was damaged and showed monotonously increasing ouput voltage.  Todd Etzel gave us a spare OP497 and I replaced the damaged chip with this new one. The chips are also available from  Newark Stock No. 19M8991 . The connector has been marked to indicate the correct orientation. The ckt was checked by temporarily connecting it in the place of the PRM Optical lever QPD.  It worked fine and has been put back in its place at the MC2 Transmission.  The QPD was wiped with a lens tissue+Methanol  to remove dust and finger prints from its surface.

It may need to be repositioned since the beam would have shifted under the MC realignment procedure.




  4106   Tue Jan 4 15:12:33 2011 SureshUpdateIOOMC Trans Mon QPD gain decreased by 10

 Decreased the gain of MC-Trans-Mon QPD ckt

The resistors R1, R2, R3, R4 are now 49.9 kOhm. The previous elog on this subject 3882 has the ckt details. 

  91   Sun Nov 11 21:05:55 2007 ranaHowToSUSMC Touching or not
I wrote a script: SUS/freeswing-mc.csh, which gives the MC mirrors the appropriate kicks
needed to make a measurement of the free swinging peaks in the way that Sonia did.

set ifo = C1
set sus = ${ifo}:SUS-

foreach opt (MC1 MC2 MC3)

  set c = `ezcaread -n ${sus}${opt}_PD_MAX_VAR`
  ezcastep ${sus}${opt}_PD_MAX_VAR +300

  ezcaswitch ${sus}${opt}_ULCOIL OFFSET ON
  ezcawrite ${sus}${opt}_ULCOIL_OFFSET 30000
  sleep 1
  ezcawrite ${sus}${opt}_ULCOIL_OFFSET 0
  sleep 1
  ezcawrite ${sus}${opt}_ULCOIL_OFFSET 30000
  sleep 1
  ezcawrite ${sus}${opt}_LATCH_OFF 0

  ezcawrite ${sus}${opt}_ULCOIL_OFFSET 0
  ezcaswitch ${sus}${opt}_ULCOIL OFFSET OFF

  ezcawrite ${sus}${opt}_PD_MAX_VAR $c



It basically ups the watchdog threshold, wacks it around at the pendulum frequency, and then disables the
optic so that there are no electronic forces applied to it besides the bias. The date command at the end
is so that you know when to start your DTT or mDV or lalapps code or whatever.
  3242   Sun Jul 18 20:50:03 2010 ranaConfigurationIOOMC TRANS optics changed

To make the beam on the MC trans camera bigger, I removed the lens + ND filter that was in that path.

The camera was getting the transmission through a BS1-33 (33% reflector). The reflection went to the TRANS QPD. I changed

the R=33% into an HR mirror (Y1-45P) so now the camera has a nice beam. The QPD was now saturating so I put a ND06 into that path

so now the TRANS_SUM is ~4.5-5 V when the MC is aligned.

The MC was also misaligned and failing to lock all weekend (why??) so I aligned the MC mirrors to get it to acquire again. Since we want to

collect MC seismic data, please make sure the MC is locked and running after finishing with your various MC or PSL work (this means YOU).

  7290   Mon Aug 27 23:52:59 2012 JenneUpdateIOOMC Spots centered


Jamie and I have the MC spots centered.  We did the normal move the input beam, realign jazz for a while, then when we got close, used the "move MC2 spot" scripts to get the MC2 spot back to ~center.

This was way easier when the measurements were real, and not just noise.  Funny that.

The dark blue spot is the farthest from 0 in pitch, and it is 1.04mm.  The cyan and yellow we've done a pretty good job of getting them equally far from zero.  Since we aren't translating the beam, we can't get better than the point at which the cyan and yellow curves cross.

Attachment 1: MCdecenter_26Aug2012.png
  5866   Thu Nov 10 20:20:57 2011 SureshUpdateIOOMC Spot positions have shifted after accelerometer installation on MC2 chamber

[ Jenne, Suresh ]

We were tying the fix the WFS and noticed that the PSL --> MC alignment was poor.   The PMC output was also at about 0.5 instead of its optimal 0.86 .   So Jenne started by first realinging the PMC input and pushed the PMC ouput to about 0.8  

Then we decided to fix the PSL--> MC alignment by using the zigzag.  After Jenne finished that, we realised that it was probably not the best thing to do since the MC2 might have shifted after the accelerometer installation on the MC2 chamber.

So I measured the spot positions and find that the MC2Y has shifted by about 3.6mm and  MC2P has shifted by about a mm.  There is also a shift of 2mm in MC3P, but hopefully it will go away when we adjust the MC2


03Nov2011   0.1354 -0.2522 -0.1383 -1.0893 0.7122 -1.5587
04Nov2011   4.0411 4.4994 3.5564 -1.4170 -0.2606 -1.7109
08Nov2011   4.7341 4.8794  4.3907 1.3542 -3.0508 -1.7167
10Nov2011 ........ 3.9944 3.7676 6.1001 -1.3058 -3.8087 -1.6418


I am going to adjust the MC2 to recover its nominal position as marked above in green

  9714   Tue Mar 11 15:01:28 2014 ericqUpdateComputer Scripts / ProgramsMC Signal Monitoring

Two weeks ago (Feb 26) I took the "Q MON" output of the demodulator that sends its Q output to the MC servo board as the error signal, and connected it to an SR785, so we can occasionally monitor the error signal noise. (Also, I did not appropriately ELOG the fact I touched things...)

I'm working on an automated script to do the monitoring, but the wireless router that the SR785 is connected is wicked slow. I should run an ethernet cable to it...

I'm just figuring I'll look at the full span (~100kHz) spectrum every ten minutes, and compare it to some nominal spectrum from a known-good time, and the last few hours.

  7198   Wed Aug 15 18:56:46 2012 YoichiUpdateIOOMC Servo Transfer Function Measurements

 I started working on the characterization of the MC servo.

The current MC servo topology is shown in the figure attached along with a simplified schematic diagram of the MC board. 

A usual way to measure the open loop gain of this servo is to inject a signal from, say, EXCA of the MC board and measure the transfer function from TP2A to TP1A. It works OK at frequencies around the UGF. The second attachment is the OPLTF measured in this way with the Agilent 4395A. The UGF is about 100kHz with the phase margin of 40 to 50 deg. 

Now we have two issues here. First, I expected the UGF to be more than 100kHz, like 300kHz or so. The phase babble is peaked around 100kHz. According to our old measurement (http://nodus.ligo.caltech.edu:8080/40m/1431) the phase babble peak was at a much higher frequency when the FSS was using the reference cavity. One reason could be that the MC is located much farther from the laser than the reference cavity, so that there is some phase lag caused by the time delay. I will make a model of the MC servo system later to check this theory.

The second issue is that, as you can see in the plot, the OPLTF measurement becomes noisy at lower frequencies. With 4395A, which has the minimum IFBW of 2Hz, OPLTF measurement below 10kHz was impossible with the traditional method. We could use SR785 with a long averaging time to improve the SNR, but it requires a patience which I don't have.

The measurement becomes difficult at low frequencies because the loop gain is too high. When the open loop gain (G) is high, the injected signal (x) from EXCA is immediately suppressed by a factor of 1/(1+G) at TP2A. This makes the injected signal hidden in other noises at TP2A.

How do we solve this problem ? Let's consider a simple servo model shown in the third attachment. A traditional OPLTF measurement is done by injecting a signal from EXC port and measuring the TF from TP2 to TP1. The problem was that at TP2, the signal is attenuated by 1/(1+G1*G2), which is too much when G (=G1*G2) is large. However, at TP3, the attenuated signal is amplified by G1. So the injected signal x becomes x*G1/(1+G) at TP3. If G1's contribution to the overall gain G is large enough,  the signal at TP3 is not so small. Then we can easily measure G2 using TP3 and TP1. In a typical situation, G1 is the transfer function of the electric circuits, which we can know either from standalone measurements or from model calculations, and G2 is an interferometer response, which we want to measure. So, by combining the knowledge of G1 and the measurement of G2, we can obtain the overall loop gain G even at lower frequencies.

 The final attachment shows an example of the measurement of G2. In our case, this is the transfer function from MC_Out_Mon to Q-Mon (see the first attachment) . G1 is the transfer function of the MC board. Since G1 is large at low frequencies, we can measure G2 down to 100Hz with a reasonable integration time (10000 cycles per point).

Last night, I took a bunch of TFs with this method. Now I'm analyzing the data to recover the overall gain G. I will post the results later.

Attachment 1: MC-Diagram.png
Attachment 2: OPLG-10kHz-1MHz.png
Attachment 3: SimpleServoDiagram.png
Attachment 4: OPTG-100Hz-1kHz.png
  7201   Thu Aug 16 01:52:52 2012 YoichiUpdateIOOMC Servo Transfer Function Measurements


Last night, I took a bunch of TFs with this method. Now I'm analyzing the data to recover the overall gain G. I will post the results later.

 I calculated the MC open loop transfer function with the combination method. For that, I made a circuit model of the MC board (from the input to the output). The transfer function of this circuit is calculated by SPICE (attachment1). Then it is multiplied by the measured transfer function from the output of the MC board to the input of the MC board (attachment 2) to get the overall transfer function.

The result is shown in the attachment 3. The blue curve is the OPLTF measured with the traditional method. The red curve is the combination method described above. There are some discrepancies between the two curves. The ratio of the two curves (Traditional)/(Combination) is plotted in attachment 4. It seems there is a pole(s) missing from my model of the MC board at around 1MHz. This may come from the omitted op-amps in the MC board model (there are so many op-amps which have flat responses below 1MHz and I omitted most of those). Also the MC board includes many generic filter stages to customize the frequency response. I will open the MC board box to examine what is actually implemented on the board. 

At low frequencies, the two curves are similar but the slope is still different.

I also had to add 83dB of gain to the combined TF to match with the traditional one. I will check where does it come from.

The MC board model (Altium project) is attached as attachment 6. The schematic is attachment 5.

Attachment 1: MC_Board_TF.png
Attachment 2: OPTG.png
Attachment 3: OPLG.png
Attachment 4: Difference.png
Attachment 5: MC_Board.pdf
Attachment 6: MC_Board.zip
  7202   Thu Aug 16 05:08:38 2012 YoichiUpdateIOOMC Servo Transfer Function Measurements


 Also the MC board includes many generic filter stages to customize the frequency response. I will open the MC board box to examine what is actually implemented on the board. 

 I took out the MC board. Unfortunately, most of the components are surface mounted. So the values of the capacitors are not legible.

I will try my best to guess what is implemented on the board.

Attachment 1: MCBoard1.JPG
Attachment 2: MCBoard2.JPG
  4331   Sun Feb 20 21:22:33 2011 rana, kiwamu, valeraConfigurationIOOMC Servo Change

For some reason, Kiwamu forced us to change the MC servo electronics today. We are now combining it with the FSS box.

The MC Servo by itself was locking by just driving the NPRO PZT. Becuase of the ~30 kHz mechanical resonances of that system, our badnwidth is limited. To get higher bandwidth, we can either use a wideband frequency shifter like the AOM or just use the ole FSS combo of PZT/EOM. The old MC servo was able to get 100 kHz because it used the AOM.

So we decided to try going through the FSS box. The MC servo board's FAST output now goes into the IN1 port (500 Ohm input impedance) of the TTFSS box. This allows us to use the FSS as a kind of crossover network driving the PZT/EOM combo.

At first it didn't work because of the 5V offset that Jenne, Larisa, Koji, and Suresh put into there, so I cut the wire on the board that connected the power to the summing resistor and re-installed the MC Servo board.

We also removed the old Jenne-SURF 3.7 MHz LP between the MC mixer and servo. Also removed the Kevin-box (1.6:40) stuck onto the NPRO PZT.

We have yet to measure the UGF, but it seems OK. The PCDRIVE is too high (~5-6V) so there is still some high frequency oscillation. Needs some investigation.

* To get the FSS SLOW servo to work (change NPRO temperature to minimize PZT drive onto NPRO) I set the setpoint to 5V in the script so that we operate the FSS box output at 5V mean. I set the threshold channel to point to MC_TRANS_SUM instead of RC_TRANSPD. I also had to fix the crontab on op340m so that it would point to the right scripto_cron script which runs the FSSSlowServo, RCThermalPID.pl, etc. I also had to fix scripto_cron itself since it had the old path definitions and was not loading up the EpicsTools.pm library.

** Also, I was flabbergasted by the dog clamping on the last turning mirror into the MC. Barely touching the mount changes the alignment.

  1315   Mon Feb 16 23:09:52 2009 ranaUpdateElectronicsMC Servo Board offset gone bad!

The attached plot shows that someone broke the MC_SUM_MON channel around 10:30 AM this past Wednesday the 11th. This is the EPICS monitor of the MC error point.

Come forward now with your confession and I promise that I won't let Steve hurt you.

Attachment 1: mcoff.png
  706   Mon Jul 21 11:54:00 2008 JenneUpdateGeneralMC Servo Board
I pulled the MC Servo Board again, to check the components that are on the board, and compare them with the schematics. The filters that I'm interested in on the Fast Path haven't been changed. The high pass filters on the Fast Path have been changed.
Component      Schematic      Actual
---------      ---------      ------
C140           10u            open
C144           10u            open
C149           open           a gray Cap.  value unknown
C141           10u            open
C145           10u            open
R97            1.58K          0
R99            open           1130
R103           open           1130
R100           open           0
R104           100            1130
R98            1.58K          open
R109           367            365

Board is back in, and MC locks.
  154   Sun Dec 2 21:02:12 2007 ranaConfigurationIOOMC SUS re-alignment
The spot on MC2 was not centered, so I put it back in the center:

  • Made sure MC trans was high with the WFS off.
  • Moved the Sliders on the MC Align screen until spot was centered (by eye)
  • Moved some more until power was maximized.
  • Unlock MC
  • Center spots on McWFS
  • Re-enable autolocker and McWFS loops.
  155   Sun Dec 2 21:07:39 2007 ranaConfigurationIOOMC SUS re-alignment
you asked for:   diff 2007/12/01,4:58:48 2007/12/03,4:58:48 utc 'MC.*COMM'
LIGO controls: differences, 2007 12/01 04:58:48 utc vs. 2007 12/03 04:58:48 utc
__Epics_Channel_Name______   __Description__________   __value1____     __value2____
C1:SUS-MC1_YAW_COMM                                    -0.273460        -0.503460
C1:SUS-MC2_PIT_COMM                                     3.624020         3.632020
C1:SUS-MC2_YAW_COMM                                    -0.936800        -1.038800
C1:SUS-MC3_YAW_COMM                                    -3.129000        -3.369000
  156   Sun Dec 2 21:13:16 2007 ranaConfigurationIOOMC SUS re-alignment
Attachment 1: e.png
  6244   Fri Feb 3 14:44:33 2012 JenneUpdateIOOMC SUS misalignment

The mode cleaner is a little misaligned in pitch, and is very misaligned in yaw.  The lowest order mode that is flashing is TEM11.

I had a look-see at the SUS sensors, to see if there were any big jumps.  There were moderately sized jumps on all 3 mode cleaner optics.


The MC's lockloss was at ~8:22am this morning, and went along with a giganto kick to the optics.  Steve tells me that Den might have been kicking up optics while doing computer things this morning, before Steve reminded him to shut off the watchdogs.  However, Steve was also taking phots/measuring things near MC Refl, so maybe he's not totally absolved of blame.  But this really looks like the optics settled to different places after big kicks.

I'm going to try to align the MC mirrors to get back to the sensor numbers from early this morning before chaos began.

Reminder / Moral:  Everything cannot be considered to be "working fine" if the MC isn't locking.  See if you can figure out why, and especially if it's something that you screwed up, either fix it, or better yet, ask for help and learn how to fix what you broke.

ELOG V3.1.3-