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.

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

- 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.

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.

[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.

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.

Summary:

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.

Analysis:

Attachment #1: This 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 #2: Maps 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 #3: After 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.

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.

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.

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(PREC,"1")
-        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.

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.

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.

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!

PC_DRIVE is also improving after the last PSL work!

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 nF.  The 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.

 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. 

#!/bin/csh

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

end

echo
date
echo

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).

Finally!

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.

[ 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

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

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.

 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.

 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.

 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.

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.

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.

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

After clicking on the extra MC1 unwhitening filter, I was going to retune the damping gains to give a Q ~ 5 for the suspension. I found it was very over damped. I also checked the other MC SUS. They were all overdamped.

A Q ~ 5 means that the amplitude of the oscillation should drop by 1/e after 5 oscillations. Most of the DOFs were damping in 1-2 cycles. This is good for lock acquisition impulses, but because it ties the suspension to the frame, it reduces the seismic isolation that we get from the pendulum. So we normally want the Q to be ~4-7. Someone more clever can figure out a better local damping servo that minimizes the overall MCF and IMC WFS signals, but that is a project that takes some thought.

in looking closer at the IMC WFS performance I notice 2 issues:

1. the watchdog thresholds are set to 200 mV, but this only made sense back when the OSEM calibration was 2 V/mm. Because of the increased analog gain(?) the RMS value of the watchdog sensors is now ~35 mV for MC1, so it will trip its watchdog and unlock the IMC with a 10x smaller seismic impulse than before. I recommend changing the watchdog thresholds appropriately changing the OSEM sensor signals to something so that its the same for all SUS.
2. For the MC SUS, the F2P or F2A decoupling filters are not on. SO the POS damping loop is injecting a lot of pitch noise into the mirrors. We could perhaps lower the ~1 Hz angular motion by commissioning those filters for the MC optics. Does anyone know why we have several filters in those filter banks? I think we could contain it all in 1, although its fine to make a few different ones with different Q's for testing the performance.

• 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.
  

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.

[Jenne, Den]

We moved the MC approximately back to where the sensors for each optic used to be (mostly touching MC2, but a little bit of MC1 to help the refl get back to its max value).  MC is now locked, and with the help of the WFS it's back to nominal.  I forgot to disable the WFS, so I think we aren't perfectly aligned, but we're close enough for the WFS to get us the rest of the way.  We're heading over to JClub right now, so we're going to leave it as-is.

When I left this morning, Steve was still working with the MC and it was unlocked anyway, I could not check it. By "fine" I meant only watchdogs. The thing is that before starting to work with c1lsc I turned off all the coils. Crazyness that Steve saw was after I turned them on back after reboot. This is a confusing thing - restarting models on c1lsc and burt restoring them is not enough. After I did it, everything at the STATUS MEDM screen was green, but the C1:SUS-???_??PD_VAR values went up after turning on coils. So sus and lsc communicated in a bad manner after the reboot. After restarting x02 model, the watchdogs were fine again.

I've reduced the gains of the damping on all 3 MC SUS by a factor of 3 for overnight observation as part of the ongoing feedforward noise cancellation investigations. I will return them to the nominal values tomorrow morning.

I've restored the damping loop gains to their nominal values. Analysis of the coherence between MCL and seismometer channels under this reduced gain setting is underway, results to follow.

- Turn off the MC autolocker. Relock the MC with only the acquisition settings; no boosts
  and no RGs. This makes it re-acquire fast. Turn the MC-WFS gain down to 0.001 so that
  it keeps it slowly aligned but does not drift off when you lose lock.

- Use low-ish gain on the FSS. 10 dB lower than nominal is fine.

- Setup the o'scope (100 MHz BW or greater) to do single shot trigger on the MC2 trans.

- Flip FSS sign.

- Quickly flip sign back and waggle common gain to get FSS to stop oscillating. MC
  should relock in seconds.

I found a peculiar issue today. The C1:IOO-MC_RFPD_DCMON remains constantly 0. I wonder if the RFPF output is being read properly. I opened the table and used an oscilloscope to confirm that the DC output from the MC REFL photodiode is coming consistently but our EPICs channel is not reading it. I tried restarting the modbusIOC service but that did not affect anything. I power cycled the acromag chassis while keeping the modbusIOC service off, and then restarted teh modbusIOC service. After this, I saw more channels got stuck and became unresponsive, including the PMC channels. So then I rebooted c1psl without doing anything to the acromaf chasis, and finally things came back online. Everything looks normal to me now but I'm not sure if one of the many channels is not in the right state. Anyways, problem is solved now.

A few minutes back, I glanced up at the control room StripTool and noticed that the MCREFL PD DC level had gone up from ~0 to ~0.7, even though the PSL shutter was closed. This seemed bizzare to me. Strangely, simply cycling the shutter returned the value to the expected value of 0. I wonder if this is just a CDS problem to do with c1iool0 or c1psl? (both seem to be responding to telnet though...)

Since things look to be back to normal, I am going to start with my characterization of the various TFs in the IMC FSS loop...

[Jenne Koji]

We decided to check the situation of the REFL MC beam path.

- No resolution of the weird MC REFL DC increase
- The reflection from the PD was adjusted to hit the beam dump
- The MC WFS paths were aligned again

Detail:

We found that the reflected beam from the PD was hitting the mount of the beam dump.
So the entire MC REFL path was steered down such that the last steering mirror does not neet to steer the beam.
When the alignment was adjusted so that the reflection from PD hit the beam dump, the beam spot on the small mirror right before the PD
got a bit marginal but it seemed still OK after some tweak.

Then we looked at the reflection value. It is still about 6.5. No change.

As we messed up the entire MC REFL path, we aligned the MC WFS paths again.
This was done with the unlocked MC REFL beam. Once the cavity was locked,
it turned out that it was enough for the WFS too keep the MC locked.

The beam splitter that directs light into the MC REFL photodiode has not been replaced; there is still a mirror there. Gautam suggested we wait to replace it until the PSL shutter is open so the beam can be aligned. However, this must be done before going to high power.

GV addendum: What I suggested was to try and recover the arm alignment using the current low power configuration after pumpdown - since we were well aligned just before pumpdown, we should be able to recover this alignment pretty easily at low power. After locking both arms and running the dither align (also center all Oplevs), we can go ahead do the following:

• Replace mirror in MC Refl path with 10% reflection BS (Johannes, Lydia and I confirmed that this is on the AP table earlier today). Then align the reflected beam onto the PD using the tiny mirror
• Replace HR mirror in Transmon path at the EY table
• Replace ND filters on Transmon QPDs at EX and EY tables
• Repalce ND filter on Transmon CCD at EY table
• Revert MC autolocker to the nominal version instead of the low power version we have been using during the vent
• Turn up MC to nominal power by rotating the wave plate on the PSL table - confirm that we have nominal levels by measuring with power meter
• Recover single arm locks, green beatnotes etc at nominal operating conditions
   

This measurement was done already about a week ago, in elog 7984.  Can you please describe why the numbers for the last measurement were not believable, and what was done differently this time?