40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 164 of 339  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  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
e.png
  178   Fri Dec 7 00:02:26 2007 ranaSummaryIOOMC/FSS Frequency Noise
The FSS frequency noise is not very bad.

I compared the MC_F spectra between Hanford and the 40m using DTT and its 'User NDS' option.
After Sam, Jenne, and DavidM installed the new MC Servo some time ago, the MC_F spectrum here
has had some whitening before it goes into the DAQ (on board; same as LLO & LHO). The tuning
coefficient of the VCO is also basically the same between all PSLs since everyone has the same
chip in the VCO driver.

Therefore, at the frequencies where the MC gain is more than ~4, the MC_F signal calibration is
the same here as anywhere. Since its the servo control signal, its basically a measure of the
frequency noise incident on the MC -- its just what comes out of the FSS with the table noise on
top. At low frequencies (< 100 Hz) its a measure of the motion of the MC mirrors.

Above 200 Hz ours is the same as theirs; except for the enormous power line spikes. I think that's
either all on the light. But our acoustics are better and the noise above 1 kHz levels off at the
same flat floor (the phase noise of the VCO) as H1. The huge lump around 100 Hz is the MC2 DAC noise and
it goes down to the H1 levels when we flip on the dewhites. The giant excess from 5-50 Hz is just the fact
that our stacks don't do much until 20-30 Hz.

So we can stop blaming the FSS and move on with life as soon as Tobin gets the ISS back in shape.
Attachment 1: fly.pdf
fly.pdf
  304   Sat Feb 9 13:05:48 2008 JohnSummaryIOOPMC camera/ HEPA
I replaced the Gig-E camera on the PMC trans beam. The PZT was close to railing and I wanted to adjust it. I just did a quick job, there is a little scattered light on the image. If Joe is finished with the Gig-E I'll take another look at it.

The HEPA in the PSL table was turned off for some reason. I turned it back on.
  307   Sun Feb 10 21:43:16 2008 robConfigurationIOOMC alignment tweaked

I adjusted the alignment of the free hanging mode cleaner to best transmit the PSL beam.
  357   Tue Mar 4 20:14:02 2008 ranaConfigurationIOOMC Alignment
The MC alignment was pretty far off. We were getting TEM01 mode locks only.
Rather than inspect what happened I just aligned the MC suspensions to get
the transmission higher. Now Matt should be able to lock the X arm and collect
adaptive filter data.
  361   Wed Mar 5 17:35:24 2008 ranaUpdateIOORFAM during MC lock
I used an ezcaservo command to adjust the offsets for Alberto's StochMon channels. They are all
at +2 V with no light
on the RFAM PD (MC unlocked).

Then I looked at 5 minutes of second trend around when the MC locks. Since Alberto has chosen
to use +2V to indicate zero RF and a negative gain, there is a large RF signal when the StochMon
channels approach zero
.

From the plot one can see that the RFAM for the 133 & 199 MHz channels is much worse than for the 33 and 166.
Its also clear that the turn on of the WFS (when the RFAMPD's DC light level goes up) makes the single demod
signals get better but the double demod get worse.
Attachment 1: rfam.pdf
rfam.pdf
  372   Wed Mar 12 23:05:44 2008 ranaUpdateIOOMC WFS
they are bad, somewhat

please fix
  437   Tue Apr 22 17:08:04 2008 CarynUpdateIOOno signal for C1:IOO-MC_L
C1:IOO-MC_L signal was at zero for the past few days
  439   Tue Apr 22 22:51:30 2008 ranaConfigurationIOOMcWFS Status
I've been working a little on the MC WFS in the last few days. I have made many
changes to the sensing matrix script and also to the MCWFSanalyze.m script.

The output matrix, as it was, was not bad at low frequencies but was making noise in
the ~1 Hz band. Turning the gain way down made it do good things at DC and not make
things work higher.

The output matrix generating script now works after Rob fixed the XYCOM issue. Not sure
what was up there. As Caryn mentioned the SUS2.ini channels were all zero after Andrey's
PEM power cycle a few days ago. Rob booted c1susvme to get the SUS1 channels back and
today we did c1susvme2 to get the IOO-MC_L et. al. back.

Even after doing the matrix inversion there is some bad stuff in the output matrix. I
checked that the sensing matrix measurement has good coherence and I measured and set the
MC WFS RF phases (they were off by ~20-30 deg.). Still no luck.

My best guess now is that the RG filters I've used for POS damping and the movement of the
beam on the MC mirror faces has made a POS<->YAW instability at low frequencies. My next
move is to revert to velocity damping and see if things get better. Should also try redoing
the A2L on the MC1-3.
  451   Fri Apr 25 20:53:02 2008 ranaConfigurationIOOMC WFS with more gain
Quick update: we found that the reason for the MC WFS instability was that the digital anti-whitening was one but not the analog whitening.

We turned off the digital filters and were able to increase the gain by a factor of ~30. It is left like this, but if it hampers IFO locking then best to just turn it back down to an overall gain of 0.1 or 0.05.
  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.

  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
mcnoise.png
  489   Tue May 20 18:33:01 2008 Andrey, JohnConfigurationIOOMode Cleaner is locked again

It was noticed by Mr.Adhikari earlier today that the MC became unlocked at about 11AM.

There is no clear understanding what caused the problem.

Trying to restore the modecleaner locking, we noticed with John that the beam was not centered on the wavesensors (WFS1. WFS2 on the screen "C1IOO_LockMC.adl"). We decided to adjust the beam position moving slightly the bias sliders for pitch and yaw degrees of freedom for MC1.
This allowed to make the MC locked.

Old positions for the MC1 sliders: Pitch = 2.9934, Yaw = -0.6168;
New positions --------//---------: Pitch = 3.0604, Yaw = -0.7258.

At the same time, FSS for PSL is still showing the values in the range 0.720 - 0.750 which is lower than the usual values. The indicator for FSS value is yellow when it is below 0.750.
  496   Sun May 25 19:33:16 2008 ranaUpdateIOOMC Bad after Re-alignment
The MC pointing was off and the transmitted power was down after John and Andrey brought it back after the bootfest.

I tried getting it back on Friday but was unsuccessful. Today, after the Phoenix Landing, I got it back to someplace
reasonable, but it still seems to be far off. I will check with Rob before we recenter and of the QPDs.

I had to move all of the MC SUS and also align the beam using the IOO periscope. The attached PDF shows some trends
over the last 80 days. You can see that the drop in MC TRANS is about the same as the drop in PMC TRANS.
Attachment 1: e.pdf
e.pdf
Attachment 2: pmc.png
pmc.png
  503   Thu May 29 15:58:44 2008 JohnSummaryIOOMC realignment
I repeatedly adjusted the yaw of the upper mirror on the input periscope and re aligned the MC. With the PRM aligned I tried to optimise MC transmission and DC refl simultaneously. I subsequently centred the beams on WFS1/2. Attached is a 30 day trend of MC alignment and transmission.
  553   Mon Jun 23 19:33:01 2008 rana, jenneUpdateIOOMC_F Noise check
We looked at the MC_F spectrum because Rob and Yoichi said that it had gone 'all crazy'. It
seemed fine as we looked at it (even with only one boost stage on) so we looked for things
that might be marginal and make it go nuts.

At the error point (Q mon on the demod board and TEST IN1) of the MC Servo board we saw the
old 3.7 MHz signal (comes from the 33 MHz RFAM getting demodulated by the 29.5 MHz MC LO)
and thought that this might cause some worries. So we installed Jenne's passive elliptic
low pass which has a 3.7 MHz zero.

This wiped out the 3.7 MHz noise but we were not able to re-create the extra frequency noise
so its unlikely to have fixed the main problem. However, we leave it in because its good. If
there is a need to revert it, we have left hanging on the side of the rack the old cable which
was a SMA->TNC making a direct, unfiltered connection between the MC Demod board and the MC
servo board.

More before and after results from Jenne tomorrow, but for now here is a calibrated MC_F spectrum
using the new MC_F-Reference.xml template file.

We also noticed that we could make some small effects on the MCF spec by adjusting the PMC gain so
there's probably more hay to be made there using a lead brick and a gain slider. More in Jenne's
entry.
Attachment 1: mcf.png
mcf.png
  554   Mon Jun 23 19:48:28 2008 rana,albertoSummaryIOOStochMon trends (80 days)
Here's a StochMon plot showing the RFAM after the MC. Remember that in these units, 2V means no RFAM
and 0 V means lots of RFAM. Alberto says "the calibration is in Tiramisu". So there you go.
Attachment 1: e.png
e.png
  562   Wed Jun 25 01:30:19 2008 JohnSummaryIOOFrequency noise after the MC
I made some (very) rough estimates of the contribution made to the noise after the mode cleaner by three sources.

Seismic noise - how much of the signal is due to the mode cleaner compenstaing for seismic disturbance of CARM.
Actuator noise - coil drivers and DAC noise.
MC_F - estimate of MC_F suppressed by the loop gain.
Attachment 1: MC2noise080623.png
MC2noise080623.png
  594   Sun Jun 29 19:19:47 2008 ranaSummaryIOOTrends of the PSL/IOO Quads over 1000 days
Only IOO POS has been working for the past 2 years. I guess we should recommission the IOO ANG and REFL QPDs
Attachment 1: a.png
a.png
  596   Sun Jun 29 20:09:40 2008 JohnSummaryIOOmcup and mcdown indicators
I edited the mcup and mcdown scripts so that C1IFO_STATE shows when these scripts are running.

I also added indicators to the LockMC screen.
Attachment 1: mcscreen.png
mcscreen.png
Attachment 2: ifostate.png
ifostate.png
  598   Mon Jun 30 01:49:06 2008 JohnUpdateIOOMC work
I'm in the process of aligning the mode cleaner/ input beam.

I turned off the WFS and cleared their histories, adjusted the input periscope and re-aligned the mode-cleaner accordingly.
I then unlocked the cavity and centred the beams on the WFS.

MC transmission is ~3.3 and the REFL beam looks a little better.

However, turning the WFS on now lowers the transmission. More thought tomorrow.

I'm leaving the MC locked with WFS off.
  600   Mon Jun 30 08:59:23 2008 steveUpdateIOOIOO-MC_DEMOD_LO is low
The alarm handler is beeping relentlessly: asking for help in high partical count and low demod signal
Attachment 1: demlo.jpg_____
demlo.jpg_____
  601   Mon Jun 30 09:46:15 2008 JohnUpdateIOOMC WFS
MC WFS are on. They seem to do some good during the day.
  626   Wed Jul 2 18:30:01 2008 JohnUpdateIOOQPD alignment
I aligned the beams on the following QPDs

IP POS
IP ANG
MC TRANS
IOO POS
Attachment 1: IOO080702.png
IOO080702.png
Attachment 2: MC080702.png
MC080702.png
  694   Fri Jul 18 16:57:37 2008 JenneUpdateIOOCalibrated MC_F
I have calibrated MC_F. The conversion factor is 137.49 MHz/count.

The calibration data taken is attached, along with a calibrated power spectrum.

On the data plot, the x axis is volts from the C1:IOO-MC_FAST_MON channel, with the calibration between FAST_MON and MC_F = -788.18 volts/count.
The linear term of the fit line = -0.085MHz/volt. Error bars are +/- 1 in the last digit of what the spectrum analyzer gave me for frequency (+/- 0.01MHz).

The net conversion factor is then (-788.18)*(-0.085)*(2) = 137.49 MHz/count. The factor of 2 is because the light passes through the AOM twice.

On the power spectrum,
REF0 and REF1 = MC unlocked, HEPAs on, MC Refl gain = 22
REF2 and REF3 = MC locked, HEPAs on, MC Refl gain = 22
REF4 and REF5 = MC locked, HEPAs on, MC Refl gain = 19
REF6 and REF7 = MC locked, HEPAs off, MC Refl gain = 19
Attachment 1: MC_Fcalib.png
MC_Fcalib.png
Attachment 2: 20080717MC_F-MC_I.pdf
20080717MC_F-MC_I.pdf
  696   Fri Jul 18 17:12:35 2008 JenneUpdateIOOChecking out the MC Servo Board
[Jenne, Max]

One of the things that Rana thinks that might be causing my MC_F calibration to be off is that the MC Servo Board's filters don't match those on the schematics. Max and I pulled the MC servo board today to check resistor and capacitor values. Alberto needed the Mode Cleaner, so we put the board back before finishing checking values. We will probably pull the board again next week to finish checking the values.

I haven't checked to ensure that the MC still locks, because Yoichi is doing stuff on the PSL table, but I didn't change anything on the board, and hooked all the cables back where they were, so hopefully it's all okay.
  697   Fri Jul 18 19:15:15 2008 JenneUpdateIOOChecking out the MC Servo Board

Quote:
[Jenne, Max]

I haven't checked to ensure that the MC still locks, because Yoichi is doing stuff on the PSL table, but I didn't change anything on the board, and hooked all the cables back where they were, so hopefully it's all okay.


I put the PMC back and the MC now locks.
  710   Mon Jul 21 19:55:16 2008 rana,jenneConfigurationIOONoise in MC_F
Jenne put the MC board on extender today - its still that way but everything is probably connected (check AO).

We measured the TFs of the DAQ section for MC_F because of how everything looked wrong in the plots Jenne
put in the log earlier. Everything we measured today seemed to jive with the schematic. We also looked up
the original traveler for this board which Betsy filled in years ago: it also is in spec for the DAQ filtering.

So then I looked at the power spectrum of the output signal to the VCO. It had lots of HFC (high frequency crap).
I adjusted the parameters of the FSS (common gain, fast gain, RF phase Astonished) and lowered the MC common gain. This
produced a global minimum in that 4D parameter space.

I think that basically, the FSS gain is too low even with the common gain slider maxed. Having the fast gain up
at 19 dB like I had left it was bad - even though it minimizes the PC control signal, it produces a lot of HFC
up around 100 kHz in MC_F. After John (finally) gets around to measuring the FSS loop we can figure out how to
better tune this. The MC gain then has to be tuned so as to best minimize the HFC given the new FSS gain; there's
basically no coupling from the MC gain to the FSS loop shape so its always best to tune the FSS first. Pleased

The RF phase of the FSS was a mystery - I have no idea why it should do anything and I have never heard of this
and I don't know why I tried it today. But...changing it by ~0.6-0.7 slider units reduced the HFC by another factor
of ~3. Somebody should put this slider into units of degrees.8-)

Here's a table of the changes. Please make these the new nominals:
you asked for:   diff 2008/07/21,13:00 2008/07/22,2:44:16 utc '.*FSS.*|.*MC.*'
LIGO controls: differences, 2008 07/21 13:00:00 utc vs. 2008 07/22 02:44:16 utc
__Epics_Channel_Name______   __Description__________   __value1____     __value2____
C1:IOO-MC_REFL_GAIN                                    22.000000        19.000000
C1:IOO-MC_REFL_OFFSET                                  0.818380         0.818100
C1:PSL-FSS_MGAIN                                       10.000000        30.000000
C1:PSL-FSS_PHCON                                       2.073170         1.413170

The attached plot shows the "SERVO" TNC output of the board; this is supposed to be the same as the voltage going to the
VCO box. So its V/Hz transfer function is flat above 40 Hz. Tomorrow Jenne will post more data and remove the extender
board.

Since I only used an SR785, I only saw noise up to 100 kHz. Its key to use an RF spectrum analyzer when checking out
the FSS and the MC systems.
Attachment 1: SCRN0024.GIF
SCRN0024.GIF
  752   Tue Jul 29 01:03:17 2008 robConfigurationIOOMC length measurement
rob, yoichi

We measured the length of the mode cleaner tonight, using a variant of the Sigg-Frolov method. We used c1omc DAC outputs to inject a signal (at 2023Hz) into the AO path of the mode cleaner and another at DC into the EXT MOD input of the 166MHz IFR2023A. We then moved an offset slider to change the 166MHz modulation frequency until we could not see the 2023Hz excitation in a single-bounce REFL166. This technique could actually be taken a step further if we were really cool--we could actually demodulate the signal at 2023Hz and look for a zero crossing rather than just a powerspec minimum. In any case, we set the frequency on the Marconi by looking at the frequency counter when the Marconi setting+EXT MOD input were correct, then changed the Marconi frequency to be within a couple of Hz of that reading after removing the EXT MOD input. We then did some arithmetic to set the other Marconis.

The new f2 frequency is:

New              OLD
--------------------------
165983145        165977195

  753   Tue Jul 29 09:12:43 2008 KojiConfigurationIOOMC length measurement
I found that the prev modulation freq had been determined with a same kind of measurement by Osamu, which also looked accurate.
http://www.ldas-sw.ligo.caltech.edu/ilog/pub/ilog.cgi?group=40m&task=view&date_to_view=09/12/2002&anchor_to_scroll_to=2002:09:12:17:10:30-ajw

(There is also a document by Dennis to note about this measurement
http://www.ligo.caltech.edu/docs/T/T020147-00.pdf )

So, it means that the round trip length of the MC shortened by 1mm in the 6 years.
New              OLD
--------------------------
27.0924          27.0934    [m]

Quote:
rob, yoichi

We measured the length of the mode cleaner tonight, using a variant of the Sigg-Frolov method.
....
The new f2 frequency is:
New              OLD
--------------------------
165983145        165977195
  757   Tue Jul 29 18:15:36 2008 robUpdateIOOMC locked

I used the SUS DRIFT MON screen to return the MC suspensions to near their pre-quake values. This required fairly large steps in the angle biases. Once I returned to the printed values on the DRIFT screen (from 3/08), I could see HOM flashes in the MC. It was then pretty easy to get back to a good alignment and get the MC locked.
  768   Wed Jul 30 13:14:03 2008 KojiSummaryIOOHistory of the MC abs length
I was notified by Rob and Rana that there were many measurements of the MC abs length (i.e. modulation 
frequencies for the IFO.) between 2002 and now.

So, I dig the new and old e-logs and collected the measured values of the MC length, as shown below. 

I checked the presence of the vent for two big steps in the MC length. Each actually has a vent. 
The elog said that the tilt of the table was changed at the OMC installation in 2006 Oct.
It is told that the MC mirrors were moved a lot during the vent in 2007 Nov.

Note:
o The current modulation freq setting is the highest ever.
o Rob commented that the Marconi may drift in a long time.
o Apparently we need another measurement as we had the big earthquake.

My curiosity is now satified so far.

Local Time	3xFSR[MHz]	5xFSR[MHz]	MC round trip[m]	Measured by
----------------------------------------------------------------------------
2002/09/12	33.195400 	165.977000 	27.09343		Osamu
2002/10/16	33.194871 	165.974355 	27.09387		Osamu
2003/10/10	33.194929 	165.974645 	27.09382		Osamu
2004/12/14	33.194609 	165.973045 	27.09408		Osamu
2005/02/11	33.195123 	165.975615 	27.09366		Osamu
2005/02/14	33.195152 	165.975760 	27.09364		Osamu
2006/08/08	33.194700 	165.973500 	27.09401		Sam
2006/09/07	33.194490 	165.972450 	27.09418		Sam/Rana
2006/09/08	33.194550 	165.972750 	27.09413		Sam/Rana
----2006/10 VENT OMC installation	
2006/10/26	33.192985 	165.964925 	27.09541		Kirk/Sam
2006/10/27	33.192955 	165.964775 	27.09543		Kirk/Sam
2007/01/17	33.192833 	165.964165 	27.09553		Tobin/Kirk
2007/08/29	33.192120 	165.960600 	27.09611		Keita/Andrey/Rana
----2007/11 VENT Cleaning of the MC mirrors
2007/11/06	33.195439 	165.977195 	27.09340		Rob/Tobin
2008/07/29	33.196629 	165.983145 	27.09243		Rob/Yoichi
Attachment 1: MC_length.png
MC_length.png
  770   Wed Jul 30 15:12:08 2008 ranaSummaryIOOHistory of the MC abs length
> I was notified by Rob and Rana that there were many measurements of the MC abs length (i.e. modulation
> frequencies for the IFO.) between 2002 and now.

I will just add that I think that the Marconi/IFR has always been off by ~150-200 Hz
in that the frequency measured by the GPS locked frequency counter is different from
what's reported by the Marconi's front panel. We should, in the future, clearly indicate
which display is being used.
  829   Tue Aug 12 19:48:24 2008 JenneUpdateIOOPRM standoff is in....mostly
Yoichi, Jenne

The missing PRM standoff is now partially installed. The standoff is in, and the wire is in the groove, but we have not finished adjusting its position to make the PRM stand up straight. It turns out to be pretty tricky to get the position of the standoff just right.

We have set up a HeNe laser as an oplev on the flow bench (which we checked was level) in the clean assembly room, and are using it to check the pitch of the mirror. We set a QPD at the height of the laser, and are looking at the single-reflected light. When the single-reflected light is at the same height as the center of the QPD, then the mirror is correctly aligned in pitch. (Actually, right now we're just trying to get the single-reflected light to hit the diode at all...one step at a time here).

We'll continue trying to align the PRM's standoff in the morning.
  837   Thu Aug 14 19:35:54 2008 JenneSummaryIOOPRM in the chamber, ready to pump!
Rob, Yoichi, Jenne, Steve

Summary: Everything is back in the chamber, we just need to put on the big doors, and start pumping in the morning.

After letting the PRM's standoff epoxy cure overnight, it was time to put the optic back in the BS Chamber. Rob put the optic cage back in the chamber, as close to the guide points that Rana had placed as possible. A handy technique was discovered for pushing the cage into place: put a long screw into the table, leaving an inch or so above the table, then use that as a push-off point so that you can push the base of the cage with your thumb. According to Rob, this is probably just about as effective as using a pusher-screw.

The guides were helpful in getting the PRM back to its original position, but one of them was placed in such a way that it could move when pushed against. The clamp that was used as a guide point was placed with one of the screws half on the edge of a hole, so that when the cage was pushed against the guide point, that screw could wiggle around, causing the clamp to rotate thus no longer being a definite guide point.

Just after putting the PRM in place, Rob found the standoff that had gone missing. (see elog #835)

Once the PRM was back in place, we put the OSEMs back, and reinstalled the satellite boxes that had been removed (PRM's, which Ben has fixed - an op-amp was blown, and BS's, which we used over in the clean room with the spare OSEMs). We found a problem with the LR PRM OSEM reading on Dataviewer. It was saturating when the OSEM was just sitting on the table, with nothing between the LED and the sensor. We measured the output from the satellite box with the octopus cables, and measured 2.3 volts, which is too much for the DAQ. It seems fine when we install it in the cage, and the magnet is blocking part of the light. We should investigate the gain of the satellite box when convenient. This is not something that needs to be done prior to pump-down. Also, when we put an allen wrench to block the light while checking which OSEM was which, we noticed that the Dataviewer reading would go down to -2V, then come back to 0V when the light was completely blocked. This may be some incorrect compensation for some whitening. Again, we should look into this, but it is not terribly time-sensitive.

Once the OSEMs were centered, we tried to turn on the damping for the PRM. This was successful, so we are confident that we have put all of the OSEMs back in their correct places.

We found that we were easily able to get the PRM's oplev back on the QPD, so we ~centered the oplev, and then centered all of the PRM's OSEMs. This assumes that the oplev was in a good place, but I think we've determined that this is the case.

We did the same thing for the SRM and the BS, to check the OSEM values before we close up for good. We found that some of the SRM OSEMs were reading low (magnet too far in), and that all of the BS OSEMs were low, perhaps as if the table were tilted a tiny bit after removing and replacing the weight of the PRM. We recentered all of the OSEMs for both of these optics.

We checked that all of the pigtails for the PRM OSEMs were anchored to the PRM cage using some copper wire as tie-downs.

We checked that all of the earthquake stops were within 1mm or so of each of the 3 optics in the BS chamber. The SRM's earthquake stops were fairly far out. One of the bottom ones was far enough that when Yoichi turned it the wrong way (accidentally), it fell out. He put it back in, and adjusted all of the earthquake stops appropriately. This 1mm distance comes from Seji, and the specs for the optics' cages.

We did a look-through of the chamber, and took out all of the tools, and other things that were not bolted down to the table.

We have left the damping of the PRM off for the night.

To do: put the doors back on, and start the pump down.
  849   Mon Aug 18 22:47:12 2008 YoichiUpdateIOOMC unlock study
As rob noted, the MC keeps unlocking in a few minutes period.
I plotted time series of several signals before unlocks.
It looks like the MC alignment goes wrong a few hundred msec before the unlock (the attached plot is only one example, but all unlocks
I've looked so far show the same behavior).
I will look for the cause of this tomorrow.

The horizontal axis of the plot is sec. The data values are scaled and offset-removed appropriately so that all curves are shown
in a single plot. Therefore, the vertical axis is in arbitrary units.
Attachment 1: MC-Unlock.png
MC-Unlock.png
  856   Tue Aug 19 18:55:41 2008 YoichiUpdateIOOMC unlock study update
In entry 849, I reported that the MC transmitted power drops before the sudden unlocks.
However, because C1:IOO-MC_TRANS_SUM is a slow channel, we were not sure if we can believe the timing.
So I wanted to use C1:IOO-MC_RFAMPDDC, which is a fast channel, to monitor the transmitted light power.
However, this channel was broken. So I fixed it. Details of the fixing work is reported in another entry.
The attached plot shows a recent unlock event. It is clear that in the fast channel (i.e. C1:IOO-MC_RFAMPDDC),
there is no delay between the drop of the MC power and the crazy behavior of control signals.
So it was concluded that the apparent precedence of the MC power drop in the slow channels (i.e. C1:IOO-MC_TRANS_SUM)
is just an artifact of timing inaccuracy/offset of the slow epics channels.

Sometime around 5PM, the MC started to be unwilling to even lock. It turned out that the PC drive of the FSS was going
crazy continuously. So I changed the normal values of the common gain and the fast gain, which the mcup script uses.
Now with this new setting, the MC locks happily, but still keeps unlocking.
Attachment 1: MC-unlock.png
MC-unlock.png
  864   Wed Aug 20 18:09:48 2008 YoichiUpdateIOOMC still unlocks
Being suspicious of FSS PC path as the culprit of the MC unlocks, I opened the FSS box and connected a probe to the TP7,
which is a test point in the PC path (before high voltage amplifier).
The signal is routed to an unused fast DAQ channel in the IOO rack. It is named C1:IOO-MC_TMP1 and recorded by the frame
builder. You can use this channel as a generic test DAQ channel later.

By looking at the attachment, the PC path (C1:IOO-MC_TMP1) goes crazy at the same time as other channels. So probably
it is not the trigger for the MC unlock.

Then I noticed the WFS signals drift away just before the unlock as shown in the attached plot. So now the WFS is the
main suspect.
Rob tweaked MC1 pitch to center the WFS QPDs while the MC is not locked. It improved the shape of the MC reflection.
However, the sudden MC unlock still happens. We then lowered the WFS gain from 0.5 to 0.3. Did not change the situation.
It looks like the MC length loop starts oscillating after the WFS signals drift away.
We will measure the WFS and MC OPLTF to see the stability of the loops tomorrow.

Attachment 1: MC-unlock.png
MC-unlock.png
  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
Untitled.png
  872   Fri Aug 22 17:03:41 2008 YoichiUpdateIOOMC open loop TF
I measured the open loop TF of the overall MC loop using the sum-amp A of the MC board.
I used the Agilent 4395A network analyzer and saved the data into a floppy disk. However, the data was corrupted when
I read it with my computer. I had the same problem before. The floppy is not reliable. Anyway, I have to re-measure the TF.
From what I remember, the UGF was around 25kHz and the phase margin was less than 15deg.
Above this frequency, the open loop gain was almost flat and had a small bump around 100kHz.
This bump has a gain margin of less than 4dB (the phase is more than 180deg delayed here).
So the MC is marginally stable and either decreasing or increasing the gain will make it unstable easily.
Probably, the broken FSS is responsible for this. We have to fix it.

During the measurement, I also found that the input connectors (IN1 and IN2) of the MC board are freaky.
These are TNC connectors directory mounted on the board. Gently touching the cables hooked up to those connectors
caused a large offset change in the output.
When Rana pulled the board out and pushed it in firmly, the strange behavior went away. Probably, the board was
not correctly inserted into the backplane.
This could have been the reason for the MC unlocks.
  877   Mon Aug 25 11:43:55 2008 YoichiFrogsIOOMC REFL PD cable had been disconnected through out the weekend
Most of my morning was wasted by the MC REFL PD cable, which was disconnected on the generic LSC PD interface board.
I know who did this. *ME*. When I pulled out the MC board, which is sitting next to the PD interface, on Friday, I must have
disconnected the PD cable accidentally. The connector of the PD cable (D-Sub) does not have screws to tighten and easily comes off.
I wrote this entry to warn other people of this potential problem.
  920   Thu Sep 4 07:46:10 2008 YoichiUpdateIOOMC is now happy
The MC has been locked for more than 12 hours continuously now !
Changes I made yesterday were:
(1) Removed the 20dB attenuator before the EOM.
(2) Reduced the Fast Gain from 21dB to 16dB, which made the PC to be a little bit more loaded (~0.6Vrms).

As Rana pointed out in the meeting, setting the Fast Gain a bit lower may have put the FSS in a stabler state.
Attachment 1: MC-lock.png
MC-lock.png
  921   Thu Sep 4 10:13:48 2008 JenneUpdateIOOWe unlocked the MC temporarily
[Joe, Eric, Jenne]

While trying to diagnose some DAQ/PD problems (look for Joe and Eric's entry later), we unlocked the PMC, which caused (of course) the MC to unlock. So if you're looking back in the data, the unlock at ~10:08am is caused by us, not whatever problems may have been going on with the FSS. It is now locked again, and looking good.
  928   Thu Sep 4 17:17:03 2008 YoichiUpdateIOOMC open loop TF
I measured open loop transfer functions of the MC servo.
The UGF was about 30kHz. Since there was some gain margin at higher frequencies, I increased
the input gain of the MC servo board from 19dB to 22dB. Now the UGF is 40kHz and we have more
phase margin (~30deg).
Attachment 1: MC-OPLTF.png
MC-OPLTF.png
  935   Mon Sep 8 10:57:49 2008 steveUpdateIOOthe psl and mc are back to normal
The alarm handler is silent this morning.
This is almost unbelievably pleasant after two mount of harassment.
The MC did not lose lock for three days.

Atm1: the new fss layout
Atm2: PMC with lead brick
Atm3: 3 days plot
Attachment 1: fss.png
fss.png
Attachment 2: pmcbrick.png
pmcbrick.png
Attachment 3: brick.jpg
brick.jpg
  952   Wed Sep 17 12:55:28 2008 robConfigurationIOOMC length
I measured the mode cleaner length last night:

SR620                Marconi
                     199178070
165981524            165981725
                     132785380
                      33196345


I did the division in Marconi-land, rather than SR620-land.
If someone wants to do this in SR620-land, feel free to do it and post the numbers.
  968   Fri Sep 19 00:06:54 2008 ranaUpdateIOOMC_F: Too much frequency noise around 100 Hz
WE noticed this excess again in MC_F. We tried recentering the WFS, but no effect.

Also no effect from changing the FSS gain, PMC gain, or ISS gain.

Actually, there IS a change when changing the PMC gain -- the ISS can be made to saturate
by lowering the PMC gain by 10 dB. Jenne and I need to finish off the PMC loop.

10 kHz UGF or bust!
Attachment 1: mcf.png
mcf.png
ELOG V3.1.3-