40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 312 of 337  Not logged in ELOG logo
ID Date Author Type Category Subject
  1282   Fri Feb 6 16:23:54 2009 steveUpdateMOPAMOPAs of 7 years

MOPAs and their settings, powers of 7 years in the 40m

Attachment 1: 7ymopas.jpg
  1281   Fri Feb 6 16:20:52 2009 YoichiUpdatePSLMOPA current slider fixed

I fixed the broken slider to change the current of the PA.

The problem was that the EPICS database assigned a wrong channel of the DAC to the slider.

I found that the PA current adjustment signal lines are connected to the CH3 &CH4 of VMIC4116 #1. However in the database file (/cvs/cds/caltech/target/c1psl/psl.db), the slider channel (C1:PSL-126MOPA_DCAMP) was assigned to CH2. I fixed the database file and rebooted c1psl. Then the PA current started to follow the slider value.

I moved the slider back and forth by +/-0.3V while the ISS loop was on. I observed that the amount of the low frequency fluctuation of the MOPA power changed with the slider position. At some current levels, the ISS instability problem went away.

Kakeru is now taking open-loop TFs and current shunt responses at different slider settings.

  1280   Fri Feb 6 14:49:31 2009 steveSummarySAFETYlaser inventory
40M Laser Inventory at Feb 05, 2009

1, Lightwave PA#102 @ 77,910 hrs 1064nm of 2.8W @ 27.65A
                   NPRO#206 @ 2.4A                    at PSL enclosure............"Big Boy" is waiting for to be retired but not now.

2, Lightwave  NPRO 1064nm of 700mW  #415   at AP table.......cavity length measurements of Alberto

3, CrystaLaser  IRCL-100-1064S, 1064nmS of 100mW  ,sn#IR81132 at east arm cabinet

4, CrystaLaser 1064nm of 180mW # -1274 flq at scattering setup.........flashlight quality

5, RF-PD tester 1064nm of 1.2mW @20mA at SP table

6, Lumix 800-1100nm of 500mW at east arm cabinet

7, JDS-Uniphase 633nmP of 4mW oplev sus laser at 5 places,
    plus four spares in east arm cabinet
The same information is posted at the 40M WIKI also
  1279   Fri Feb 6 10:46:40 2009 KakeruUpdatePSLISS servo and noise
I measured the output noise of eache stage of ISS servo, and calcurated the noise ratio between input and 
output of each stage.
Generaly, each noise ratio corresponds to their transfar function. This means servo filter works well, not 
adding extra noise.

I attache example of them.
For 2nd stage, the noise ratio is smaller than transfar function with a few factor. This is because the 
input noise is coverd by analyser's noise and ratio between output and input looks small.
This means the input noise of 2nd stage was enough small and all stage before 2nd stage work well
Attachment 1: ISS_servo_TF_noise.png
  1278   Fri Feb 6 09:56:11 2009 KakeruUpdatePSLISS servo transfar function

I attache the transfar function of ISS servo.

The 4th stage and variable gain amplifier has alomost same transfar function, so their lines pile up.

Attachment 1: TF_ISSservo_gain.png
Attachment 2: TF_ISSservo_phase.png
  1277   Fri Feb 6 09:52:35 2009 KakeruUpdatePSLCurrent shunt transfar function

I attach the transfar function of the current shunt.
There is a little gap at 10 Hz for phase, but it is a ploblem of measurement and not real one.

Attachment 1: TF_CS_gain.png
Attachment 2: TF_CS_phase.png
  1276   Thu Feb 5 21:42:28 2009 YoichiUpdatePSLMy thoughts on ISS

Today, I worked with Kakeru on ISS.

The problem is sort of elusive. Some time, the laser power looks fine, but after a while you may see many sharp drops in the power. Some times, the power drops happen so often that they look almost like an oscillation.

We made several measurements today and Kakeru is now putting the data together. Meanwhile, I will put my speculations on the ISS problem here.

The other day, Kakeru took the transfer function of the ISS feedback filter (he is supposed to post it soon). The filter shape itself has a large phase margin ( more than 50deg ?) at the lower UGF (~3Hz) if we assume the response of the current shunt to be flat. However, when we took the whole open loop transfer function of the ISS loop, the phase margin was only 20deg. This leads to the amplification of the intensity noise around the UGF. The attached plot is the spectrum of the ISS monitor PD. You can see a broad peak around 2.7Hz. In time series, this amplified intensity noise looks like semi-oscillation around this frequency.

Since it is very unlikely that the PD has a large phase advance at low frequencies, the additional phase advance has to be in the current shunt. We measured the response of the current shunt (see Kakeru's coming post). It had a slight high-pass shape below 100Hz (a few dB/dec). This high-pass response produces additional phase advance in the loop.

There seems to be no element to produce such a high-pass response in the current shunt circuit ( http://www.ligo.caltech.edu/docs/D/D040542-A1.pdf )

This Jamie's document shows a similar high-pass response of the current ( http://www.ligo.caltech.edu/docs/G/G030476-00.pdf  page 7 )

Now the question is what causes this high-pass response. Here is my very fishy hypothesis :-)

The PA output depends not only on the pump diode current but also on the mode matching with the NPRO beam, which can be changed by the thermal lensing. If the thermal lensing is in such a condition that an increase in the temperature would reduce the mode matching, then the temperature increase associated with a pump current increase could cancel the power increase. This thermal effect would be bigger at lower frequencies. Therefore, the intensity modulation efficiency decreases at lower frequencies (high-pass behavior). If this model is true, this could explain the elusiveness of the problem, as the cancellation amount depends on the operation point of the PA. 

To test this hypothesis, we can change the pump current level to see if the current shunt response changes. However, the PA current slider on the MEDM screen does not work (Rob told me it's been like this for a while). Also the front panel of the MOPA power supply does not work (Steve told me it's been like this for a while). We tried to connect to the MOPA power supply from a PC through RS-232C port, which did not work neither. We will try to fix the MEDM slider tomorrow.

Attachment 1: INMONPD_Spectrum_1-10Hz.pdf
  1275   Thu Feb 5 16:21:07 2009 JenneFrogsComputersBelladonna connects to the wireless Martian network again

Symptoms:  Belladonna could not (for a while) connect to the wireless network, since there was a driver problem for the wireless card.  This (I believe) started when Yoichi was doing updates on it a while back.

The system: Belladonna is a Dell Inspirion E1505 laptop, with a Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card (rev 01)

Result:  Belladonna now can talk to it's wireless card, and is connected to the Martian network.  (MEDM and Dataviewer both work, so it must be on the network.)


What I did:

0.  Find a linux forum with the following method:  http://www.thelinuxpimp.com/main/index.php?name=News&file=article&sid=749

The person who wrote this has the exact same laptop, with the same wireless card.

1.  Get a new(er) version of ndiswrapper, which "translates" the Windows Driver for the wireless card to Linux-ese.  Belladonna previously was using ndiswrapper-1.37.

$wget http://nchc.dl.sourceforge.net/sourceforge/ndiswrapper/ndiswrapper-1.42.tar.gz

2.  Put the ndiswrapper in /home/controls/Drivers, and installed it.

$ndiswrapper -i bcmwl5.inf  3.  Get and put the Windows driver in /home/controls/Drivers/WiFi

$wget http://ftp.us.dell.com/network/R140747.EXE
4. Unzip the driver $unzip -a R140747.EXE

5.  Make Fedora use ndiswrapper

$ndiswrapper -m

$modprobe ndiswrapper

6. Change some files to make everything work:

/etc/sysconfig/wpa_supplicant      CHANGE FROM: DRIVERS="-Dndiswrapper"     CHANGE TO: DRIVERS="-Dwext"

/etc/sysconfig/network-scripts/ifcfg-wlan0      CHANGE FROM: BOOTPROTO=none      CHANGE TO: BOOTPROTO=dhcp

/etc/rc.d/init.d/wpa_supplicant        CHANGE FROM: daemon $prog -c $conf $INTERFACES $DRIVERS -B        CHANGE TO: daemon $prog -c$conf $INTERFACES $DRIVERS -B

6.  Restart things

$service wpa_supplicant restart
$service network restart

7.  Restart computer (since it wasn't working after 1-6, so give a restart a try)

8. Success!!!  MEDM and Dataviewer work without any wired internet connection => wireless card is all good again!

  1274   Thu Feb 5 10:42:33 2009 YoichiUpdateGeneralDo we need off-axis parabolic mirrors ? No way !
I made a mistake in estimating the astigmatism problem.
If we use the current MMT1 as it is, this one is already an off-axis parabolic (OAP) mirror.
In this case, the astigmatism of this mirror is very small (if we use it with the correct angle). I did not include this effect in the previous calculation.
It turned out that the maximum achievable mode matching becomes far smaller (only 77%) if we use the OAP for MMT1 and a spherical mirror for MMT2.
This is not acceptable.
The reason behind this is that when we use spherical mirrors for both MMT mirrors, the astigmatism caused by the MMT1 is somewhat canceled by the astigmatism of MMT2. We don't get this cancellation if we mix OAP and spherical mirrors.

We should either (1) change MMT1 to a spherical mirror and keep the length of the input MMT as it is, or (2) change MMT1 to a spherical mirror and elongate the length of the input MMT.
In the case of (1) the maximum achievable mode matching is 94%. The focal length of MMT2 should be 315.6mm.
If we do (2), the mode matching rate can be as high as 99.8%. The focal lengths are MMT1 = -301.3mm, MMT2=558mm. The distance between the mirrors is 262mm.
We have enough space to do this elongation. But we have to mechanically modify the MMT mount.
I prefer (2).

As usual, the document on the Wiki was updated to include the above calculations.
  1273   Thu Feb 5 09:12:29 2009 steveBureaucracySAFETYsafety updates & fire alarm test

The fire alarm test was completed at 13:30 yesterday.


I updated the 40M Emergency Calling List by replacing Rob by Yoichy. The calling order: Vass,  Aso and Taylor.

Rana and Yoichy were added to the "Registered PSL Operator List"  and posted it in the lab. (not in the document, that should be up dated)

We are getting ready for the annual safety audit. It will be held next week  at 14:00 Friday, Feb 13, 2009

Please participate in the preparation by correcting it or just  tell me.


Rod Luna is organizing the pick up of the following old equipment:

HP laser jet  5000n, 3 of 19" 10 base-T network ports and  4 small hubs,

2 Sun monitors, 1 Viewsonic monitor, 7 keypads and

Hitachi scopes 2 of V-355, 2 of V-422, 1 of V-202 and 1 of V-6165



  1272   Wed Feb 4 19:22:57 2009 YoichiUpdateGeneralDo we need off-axis parabolic mirrors ?
I also estimated the mode matching degradation caused by the astigmatism.
Since the incident angles to the mode matching mirrors are not 0, the effective focal lengths in the incident plane and the perpendicular plane are different.
This effect leads to astigmatism of the beam.
When there is astigmatism, the maximum achievable mode matching rate becomes less than 100%.
According to my calculation, the mode matching cannot be better than 94% for the input beam.
For the output mode matching, we can theoretically achieve more than 99% even with the astigmatism.
The difference comes from the fact that the OMMT is longer, thus the incident angle is smaller.

If we don't like this 94%, we have to use off-axis parabolic mirrors, or modify the IMMT to a longer one.
I prefer to make it longer. Just 5" elongation will increase the mode matching rate to 99.4%.
We have a room for this 5" elongation.

Again, the details of the calculation are added to the Mathematica notebook below.

I did mode matching calculations for the new optical layout.
For the input mode matching, we have to change the focal length of the second mirror from 687mm to 315mm and the distance between the two MMT mirrors from 137mm to 149.2mm.
For the mode matching to the OMC, we only have to change the distance between the OMMT mirrors from 384mm to 391mm. No need to change the mirrors.

Details of the calculations can be found in
(Mathematica notebook)
or if you prefer PDF, here
  1271   Wed Feb 4 17:45:39 2009 YoichiUpdateGeneralMode matching of the upgraded IFO
I did mode matching calculations for the new optical layout.
For the input mode matching, we have to change the focal length of the second mirror from 687mm to 315mm and the distance between the two MMT mirrors from 137mm to 149.2mm.
For the mode matching to the OMC, we only have to change the distance between the OMMT mirrors from 384mm to 391mm. No need to change the mirrors.

Details of the calculations can be found in
(Mathematica notebook)
or if you prefer PDF, here
  1270   Tue Feb 3 23:44:44 2009 Kakeru, Peter, YoichiUpdatePSLISS unstability

We found that one OP-amp used in ISS servo oscillated in 10 MHz, 100mV.

Moreover, we found another OP-amp had big noise.

We guess that these oscilation or noise cause saturation in high frequency, and they effect to lower frequency to cause 

 Attached files are open loop transfar function of ISS.

The blue points are open loop TF, and the green line is product of TF of ISS servo filter and TF of current shunt TF of servo filter.

This two must be same in principle, but They have difference f<2Hz and f>5kHz.

Attachment 1: TFgain.png
Attachment 2: TFphase.png
  1269   Tue Feb 3 19:24:14 2009 YoichiUpdateGeneralNew optics layout wiki page
I uploaded a slightly updated version of the new optics layout on the 40m wiki.

I also uploaded the Mathematica notebook I used to calculate various parameters of the new recycling cavities, including the lengths, asymmetry, ROCs, PRM reflectivity and TT-mirror loss margin etc.
It would be nice if someone could check if the calculation is reasonable.
There is a PDF version of the document for non-Mathematica users.
  1268   Tue Feb 3 15:01:38 2009 AlbertoFrogsComputersmegatron slow?

I notice that Megatron is slower than any other computer in running code that invokes optickle or looptickle (i.e. three times slower than Ottavia). Even without the graphics.

Has anyone ever experienced that?

  1267   Mon Feb 2 19:23:53 2009 YoichiUpdateGeneralNew optical layout plan
The attached is a plan of the optical layout in the central part for the upgrade.
I included, the folded recycling cavities, oplevs for the core optics, POX, POY, POB and video views.
I have not worked out how to handle the beams outside the chambers. It should not be that difficult.
I also did not include beam dumps for unwanted beams.

I used pink for main beams, brown for picked off beams, red for oplevs.

Comments, suggestions are welcome.
Attachment 1: 40mUpgradeOpticalLayoutPlan01.pdf.zip
  1266   Mon Feb 2 18:51:02 2009 AlbertoConfigurationGeneralNew Elog 2.7.5 in Service on Nodus

I moved the 40m, the Adhikari Lab and the SUS elogs from Dziban (located in Millikan's 6th floor) to our gateway server Nodus. In this way we should the complete control of it. I also updated the elog manager from the 2.6.5 version to the 2.7.5. Some smoothing of its interface might still be needed these days. We'll be testing it for a while before killing the old one. from now on everybody is invited to use only the new elog address since there will be no record of entries posted in the old one. Let me know of any possible difficulty in having access to it.

 As a reference. The elog runs on background in nodus.

To kill the process:

1) pkill -3 elogd

2) rm -f /var/run/elogd.pid

To restart it:

elogd -p 8080 -c /export/elog/elog-2.7.5/elogd.cfg -D

  1265   Mon Feb 2 18:32:54 2009 AlbertoConfigurationGeneralSome little problem with the new elog

For some reason the new elog does not look exactly like it should. 1) Some of the editing features are not available. 2) The Reply option opens the HTML of the message by default. I think this is happening because Nodus is a Sun of platform and things are a little bit different from linux. I'm working to fix these things. If I make any change and need to restart the elog, I'll try to be very quick. I apologize for the inconveniences.

 I think I solved the problem (as you can probably see).

The cause was that this WYSIWYG interface for HTML is provided by an independent text editor called FCKeditor which is included in the elog. Although the elog installer has a bug and does not unzip properly the relative package. One has to do it by hand. (going to /elog/scripts/ and unzipping fckeditor.zip by hand in the same directory).

  1264   Mon Feb 2 17:25:44 2009 AlbertoConfigurationGeneralSome little problem with the new elog
For some reason the new elog does not look exactly like it should. 1) Some of the editing features are not available. 2) The Reply option opens the HTML of the message by default. I think this is happening because Nodus is a Sun of platform and things are a little bit different from linux. I'm working to fix these things. If I make any change and need to restart the elog, I'll try to be very quick. I apologize for the inconveniences.
  1263   Mon Feb 2 12:35:22 2009 AlbertoConfigurationGeneralNew Elog 2.7.5 in Service on Nodus
I moved the 40m, the Adhikari Lab and the SUS elogs from Dziban (located in Millikan's 6th floor) to our gateway server Nodus. In this way we should the complete control of it. I also updated the elog manager from the 2.6.5 version to the 2.7.5. Some smoothing of its interface might still be needed these days. We'll be testing it for a while before killing the old one. from now on everybody is invited to use only the new elog address since there will be no record of entries posted in the old one. Let me know of any possible difficulty in having access to it.
  1262   Fri Jan 30 19:38:57 2009 KakeruUpdatePSLISS Bad
Kakeru, Peter

We try to improve ISS bord, but there isn't circuit diagram with correct parameters.
We are to measure transfar function and guess each parameter before we desogn new circuit parameters.
  1261   Fri Jan 30 17:30:31 2009 Alberto, JosephbConfigurationComputersNew computer Ottavia set up
Alberto, Joseph,

Today we installed the computer that some time ago Joe bought for his GigE cameras. It was baptized "OTTAVIA".

Ottavia is black, weighs about 20 lbs and it's all her sister, Allegra (who also pays for bad taste in picking names). She runs an Intel Core 2 Quad and has 4GB of RAM. We expect much from her.

Some typical post-natal operations were necessary.

1) Editing of the user ID
  • By means of the command "./usermod -u 1001 controls" we set the user ID of the user controls to 1001, as it is supposed to be.

2) Connection to the Martian network
  • Ottavia was given IP address by editing the file /etc/sysconfig/networ-scripts/ifcfg-eth0 (we also edited the netmask and the gateway address as in the Wiki)
  • In linux1, which serves as name server, in the directory /var/named/chroot/var/named, we modified both the IP-to-name and name-to-IP register files 131.215.113.in-addr.arpa.zone and 131.215.11in-addr.martian.zone.
  • We set the file /etc/resolv.conf so that the OS knows who is the name server.

3) Mounting of the /cvs/cds path
  • We created locally the empty directories /cvs/cds
  • We edited the files /etc/fstab adding the line "linux1:/home/cds /cvs/cds nfs rw,bg,soft 0 0"
  • We implemented the common variables of the controls environment by sourcing the cshrc.40m: in the file /home/controls/.cshrc we added the two lines "source /cvs/cds/caltech/cshrc.40m" and "setenv PATH ${PATH}:/cvs/cds/caltech/apps/linux64/matlab/bin/"
  1260   Thu Jan 29 18:10:13 2009 YoichiUpdatePSLISS Bad
Kakeru, Yoichi

As we noted before, the ISS is unstable. You can see the laser power oscillation around 3Hz.
We took the open-loop transfer function of the ISS around the lower UGF.
The phase margin is almost non-existent.
It was measured with the ISS gain slider at 2dB (usually it was set to 7dB).
So if we increase it by 3dB, it is guaranteed to be unstable.

The higher UGF has also a small phase margin (about 12deg.).
With the ISS gain slider at 2dB, the upper UGF is too low, i.e. the UGF is located at the beginning of the 1/f region.
So we if we make the lower UGF stable by lowering the gain, the upper UGF becomes unstable.

We took out the ISS box from the PSL table.
Kakeru and Peter are now trying to modify the filter circuit to give more phase margin at the lower UGF.
Attachment 1: OPLTF1.png
  1259   Thu Jan 29 17:24:41 2009 KakeruUpdateoplevsarm cavity oplev calibration
I calibrated optlevs again. My previous work has a lot of mistakes, so ignore it.

ITMX pit: 195 microrad/ct
ITMX yaw: 185 microrad/ct
ETMX pit: 303 microrad/ct
ETMX yaw: 296 microrad/ct

ITMY pit: 192 microrad/ct
ITMY yaw: 141 microrad/ct
ETMY pit: 294 microrad/ct
ETMY yaw: 301 microrad/ct

(For ITMY, the data is low quality)

My calcuration and Peter's(based on Royal's report) is different in two point.
i) Royal uses some geometrical factor to calibrate ITM.
ii) Royal fits data to exp(-a^2/(2*w0^2)), and I fit data to exp(-a^2/w0^2).

When I calculate with modification of these differences, my result became almost same value of Peter's one.
Now we are discussing which equation is correct.

But we must do some laser works before it...
  1258   Thu Jan 29 16:50:53 2009 josephb, albertoConfigurationComputersMegatron fixed
The warning light on megatron and the fans at full speed were fixed by not just power cycling, but completely unplugging megatron from power, waiting for a minute, and then reconnecting the power cables.

Apparently, the Sunfire X4600s at Hanford have also had intermittent problems, which required unplugging the machines completely. In their case, they were unable to access the machine normally, nor could they access the the Intergrated Lights Out Manager (ILOM).

Here, we could interact normally with megatron, but were unable to connect to the ILOM. We were able to get BIOS, but unable to change any of the setting for the ILOM connection. Since the ILOM is a seperate processor and effectively always on, even when the power light is off, a normal shutdown won't reset it. Hence the need to completely disconnect the power supply.
  1257   Thu Jan 29 13:52:34 2009 YoichiUpdatePSLLaser is back (sort of)
Here is what I think has happened to the laser.

After the chiller line to the NPRO base clogged, the FSS slow slider went down to keep the laser frequency constant.
It is evident in the attachment 1 that the behavior of the slow slider and the DTEC (diode temp. stabilization feedback signal) are almost the same except for the direction. This means the slow servo was fighting against the increased heat caused by the lack of the cooling from the bottom.
DTEC was doing the same thing to keep the diode temperature constant.

Even though the slow actuator (a Peltier on the crystal) worked hard to keep the laser frequency constant, one can imagine that there was a large temperature gradient in the crystal and the mode shape may have changed.

Probably this made the coupling of the NPRO beam to the PA worse. It may also have put the NPRO in a mode hopping region, which could be the cause of the noisiness.

Right now, the MOPA power is 2.7W.
The FSS, PMC, MZ are locked. At first, the PMC locked on a sideband. I had to twiddle the phase flip button of the PMC servo to lock the PMC. Probably this is another sticky channel, which needs to be tweaked after a reboot of c1psl. I added a code to do this in /cvs/cds/caltech/scripts/Admin/slider_twiddle.

Currently the ISS is unstable. Kakeru and I are now taking OPLTF of the servo.
Looks like the phase margin at the lower UGF is too small.
Attachment 1: SlowDC.pdf
  1256   Wed Jan 28 19:08:50 2009 YoichiUpdatePSLLaser is back (sort of)
Yoichi, Peter, Jenne

We found that the chiller water is not going to the NPRO base. It was hot whereas it was cold when I touched it a few months ago.
I twisted the needle valve on the water line to the NPRO base. Then we heard gargling noise in the pipe and the water started to flow.
The laser power is now climbing up slowly. The noisiness of the MOPA output is reduced.

I will post more detailed entry explaining my theory of what actually happened later.
Attachment 1: Improving.png
  1255   Wed Jan 28 12:51:32 2009 YoichiUpdateComputersMegatron is dying
For the past three days, Megatron has been making a huge noise. Sounds like a fan is failing.
There is an LED with "!" sign on the front panel. It is now orange. Looks like some kind of warning.
We can login to the machine. "top" shows the CPU load is almost zero.
Shall we try rebooting it ?
  1254   Wed Jan 28 12:42:51 2009 YoichiUpdatePSLMOPA dying
Yoichi, Jenne, Peter

As most of you know, the MOPA output power has been declining rapidly since Jan 21. (See the attachment 1)
There was also an increase in the NPRO power observed in LMON, which is an internal power monitor of the NPRO.
Similar trend can be seen in 126MON, which picks up some scattered light from the NPRO but there may be some contributions from the PA output.

The drop in the AMPMON, LMON and CURMON (NPRO current) from the middle of Jan 26 to the end of Jan27 was caused by me.
I tried to decrease the NPRO current to put the NPRO power back to the level when the MOPA output was higher. But it did not bring back the MOPA power.
So I put back the current after an hour. This caused the sharp power drop on Jan26.
By mistake, I did not fully recover the current at that time and left it like that for a day. This accounts for the long power drop period continued until Jan27.

Shortly after I tweaked the current, the MOPA output power started to fluctuate a lot. This drives the ISS crazy.
To see if this was caused by the NPRO or power amplifier,
we decided to fix the 126MON to monitor the real NPRO power.
We opened the MOPA box and installed a mirror to direct a picked off NPRO beam to the outside of the box through an unused hole.
We set up a lens and a PD outside of the MOPA box to receive this beam. The output from the PD is connected to the 126MON cable.
So 126MON is now serving as the real monitor of the NPRO power. It has not yet been calibrated.

The second attachment shows a short time series of the MOPA power and NPRO power. When the beam is blocked, the 126MON goes to -22.
So the RIN of the NPRO is less than 1%, whereas the MOPA power fluctuates about 5%. There is also no clear correlation between the power fluctuation of the MOPA and the NPRO. So probably the MOPA power fluctuation is not caused by NPRO.

At this moment, all the feedback signals (current shunt, slow and fast actuators) are physically disconnected from MOPA box so that we can see the behavior of MOPA itself.
Attachment 1: Recent10Days.png
Attachment 2: 126_MOPA.png
  1253   Mon Jan 26 14:51:54 2009 josephbConfigurationVAC 
We need a new RS-232 to Ethernet bridge in order to interface properly with the new RGA. The RGA has a fixed baud rate of 28.8k, and the current bridge (which used to work with the old RGA) doesn't have that baud rate as an option. Currently looking into purchasing a new bridge, and trying to make sure it can meet the communications requirements of the RGA.
  1252   Sat Jan 24 11:50:24 2009 AlbertoConfigurationElectronicsPhotodiode Filters' Transfer Functions
I found an elog entry by Jenne with the measurement of the transfer functions of the filters of some of our photodetectors. Since it might turn useful to us these days, while I'm thinking about posting them on the wiki sometime, I also copy the link here:
Jenne's on the PD's TF

If we still had the data for those plots, it would be great. Do we have it?
  1251   Fri Jan 23 16:33:27 2009 peteUpdateoplevsx-arm oplev calibrations
ITMXpit 71 microrad/ct
ITMXyaw 77 microrad/ct
ETMXpit 430 microrad/ct
ETMXyaw 430 microrad/ct

As with y-arm, my ITM measurements agree with Kakeru and Royal, but my ETM measurements are not quite a factor of 2 higher. Kakeru and I are investigatin.
  1250   Fri Jan 23 14:00:02 2009 YoichiUpdatePSLPMC transmission is down

The PMC transmission is going down.
I have not relocked the PMC yet.

I tweaked the alignment to the PMC.
The transmission got back to 2.65. But it is still not as good as it was 3 days ago (more than 3).

It is interesting that the PMC transmission is inversely proportional to the NPRO output.
My theory is that the increased NPRO power changed the heat distribution inside the power amplifier.
Thus the output mode shape changed and the coupling into the PMC got worse.
MOPA output shows a peak around Jan-21, whereas the NPRO power was still climbing up.
This could also be caused by the thermal lensing decreasing the amplification efficiency.
Attachment 1: LaserPower.png
  1249   Fri Jan 23 12:48:12 2009 KakeruUpdateoplevsarm cavity oplev calibration
I calibrated optlevs of x and y arm cavity, indipendently from Peter's work.

ITMX pit: 77 microrad/ct
ITMX yaw: 73 microrad/ct
ETMX pit: 280 microrad/ct
ETMX yaw: 263 microrad/ct

ITMY pit: 120 microrad/ct
ITMY yaw: 93 microrad/ct
ETMY pit: 280 microrad/ct
ETMY yaw: 270 microrad/ct

This result is similar to Royal's one (within 30% difference except for ETMX pit), but different from Peter's in ETMY.

The attached figure is the data and fitted curve of ITMX pit.
I took this data for 8s, with 4 Hz excitation.
Attachment 1: ITMX_pitch.png
  1248   Fri Jan 23 10:00:21 2009 steveUpdatePSLPMC transmission is down
The PMC transmission is going down.
I have not relocked the PMC yet.
Attachment 1: pmc4d.jpg
  1247   Thu Jan 22 23:36:50 2009 peteHowTooplevsarm cavity oplev calibration
calibrated the y-arm oplevs. the procedure is contained in a matlab script. the whereabouts of this script will be revealed in a future log entry.

ITMYpit 140 microrad/ct
ITMYyaw 98 microrad/ct
ETMYpit 400 microrad/ct
ETMYyaw 440 microrad/ct (previous measurement gave 420 microrad/ct)


1) Start with a single arm aligned and locked. Dither the mirror tilt in a DOF. Measure arm cavity power and oplev error signal. See the first attached plot.

2) Fit the plot to a gaussian and determine mu and sigma.

3) For a spherical ETM optic, the power in the cavity P(a), as a function of translational beam axis displacement a=R*sin(theta), is proportional to exp[-a^2/(2*x^2)] where x is the waist size (D. Anderson APPLIED OPTICS, Vol. 23, No. 17, 1984). The power as a function of mirror tilt in cts, P(tilt) is proportional to exp[-(tilt-mu)^2 /(2*sigma^2)]. So if R is the mirror radius then theta = arcsin(a/R) = arcsin[(1/R)*(tilt-mu)*x/sigma)].

4) Fit theta versus mirror tilt to get the calibration. See the second attached plot.

5) For a flat ITM optic, mirror tilt causes an angular displacement of the beam. The math for this case is given in Anderson.
Attachment 1: ETMYpitpower.png
Attachment 2: ETMYpitcal.png
  1246   Thu Jan 22 14:38:41 2009 carynDAQPSLMC temperature sensor


I added a channel for the temperature sensor on the MC1/MC3 chamber: C1:PSL-MC_TEMP_SEN.
To do that I had to reboot the frame builder. The slow servo of the FSS had to get restarted, the reference cavity locked and so the PMC and MZ.

Where is this channel?

That's not the name of the channel anymore. The channel name is PEM-MC1_TEMPS. It's written in a later entry.
  1245   Thu Jan 22 12:08:59 2009 peteUpdateoplevsoplev calibration
Following the procedure described in Royal Reinecke's 2006 SURF report, I've calibrated the ETMY yaw oplev DOF. The idea is to sweep the mirror tilt, measuring the transmitted cavity power and the oplev error signal. The cavity power can be related to the mirror tilt in radians following D. Anderson APPLIED OPTICS, Vol. 23, No. 17, 1984.

I've made a simple matlab script which spits out the final number; it calls Royal's perl script to do the sweep. I get 420 microrad/ct for ETMY yaw. In 2006 Royal got 250 microrad/ct. Could something have changed this much, or is one of us wrong? I'll double check my procedure and do the other arm cavity oplevs, and describe it in detail when I have more confidence in it.

Kakeru and I plan to extend this to handle the PRM, SRM, and BS. One script to rule them all.
  1244   Thu Jan 22 11:54:09 2009 AlbertoConfigurationPSLMach Zehnder Output Beam QPD
I rotated by 180 degrees the 10% beam splitter that it is used to fold the beam coming from the Mach Zehnder (directed to the MC) on to the QPD.

The alignment of the beam with that QPD has so been lost. I'll adjust it later on.

The rotation of the BS had the (surprising) effect of amplifying the Absolute Length experiment's beat by 9 times. Maybe because of a polarizing effect of the Beam Splitter which could have increased the beating efficiency between the PSL and the NPRO beams?
  1243   Thu Jan 22 08:34:10 2009 steveBureaucracySAFETYsafety training
Kakeru received 40m safety training yesterday.

He has no authorization to work alone in the high power beam path yet.
  1242   Wed Jan 21 22:53:08 2009 ranaUpdateLSCAS CCD centering and ASDD demod phase
Just my opinion, but I think all we want out of the DD signals is something to control the DRM
and not be sensitive to the carrier and the CARM offset. So if the handoff can be done so that
the lock point is unchanged from single demod then everything is fine.

A second order concern is how the 133 & 199 MHz signals are mixed in order to minimize the
matrix cross-coupling and the SNR of the diagonal elements.
  1241   Wed Jan 21 16:18:17 2009 KakeruUpdateLSCAS CCD centering and ASDD demod phase
I tuned the DD demod-pahse for SRM.
It was tuned as the error singnal is to be 0 when the cavity is locked.

The problem is that the good phase changes if MICH and PRM are handed to DD or not.
This may be a result of the demod-phase of these two signals are tuned to be maximise the error signal, not to be 0-offset.

I will tune these two demod-phases, and write a script to tune.

I tuned the demod-phase for PRCL and SRCL hand-off, but it have not been optimized enoughly.
I continue this work tomorrow.

After Rob's AS beam work, I centered the beam on the AS CCD.
I also optimized the ASDD demod-phase for the MICH signal.
Rob suggested to me that whenever we restart or change the frequency of the DD Marconis, we have to re-optimize the demod-phase
because the initial phase of the Marconi is random. We had the power failure, so it was time to do so.
I confirmed that MICH hand-off from REFL33Q to AS133DDQ is ok.
I will do the same thing for the PRCL, SRCL hand-offs.
  1240   Tue Jan 20 15:28:42 2009 YoichiUpdateComputersloadLIGOData a GUI for mDV

The tool is very nice; I looked at the seismic trend for 16 days (attached).
However, it gives some kind of error when trying to get Hanford or Livingston data.

I fixed it.
You have to click "Load channels" button when you select a new site.
I plotted one minute of MC_F signals from H1, H2, L1 and 40m.
Looks like L1 MC was swinging a lot.
Attachment 1: MC_F.png
  1239   Mon Jan 19 18:21:41 2009 ranaUpdateComputersloadLIGOData a GUI for mDV
The tool is very nice; I looked at the seismic trend for 16 days (attached).
However, it gives some kind of error when trying to get Hanford or Livingston data.
Attachment 1: a.png
  1238   Mon Jan 19 15:10:37 2009 YoichiHowToComputersloadLIGOData a GUI for mDV
I installed loadLIGOData, a product of my weekend project, in /cvs/cds/caltech/apps/loadLIGOData.
This is a Matlab GUI for getting data from nds servers. It uses a modified version of mDV to retrieve data.
You can choose and download LIGO data into Matlab quickly.
I also wrote a GUI to plot the downloaded data easily.
With this GUI, you can plot multiple channel data in a single figure, which is useful to identify the cause for a lock loss etc.
You can change the time axis labels to UTC or Local time in stead of GPS second.

You can run it by typing loadLIGOData in a terminal of a linux machine.
A brief explanation of how to use it is written here:

At this moment, data from test points cannot be retrieved properly (of course there is no way to go back to the past for test points.
But still we should be able to get data in real time.). I'll try to find a solution.
Attachment 1: loadLIGOData.png
Attachment 2: plotLigoData.png
  1237   Mon Jan 19 13:58:53 2009 YoichiUpdateASCBetter ditherServo.pl
Nick Smith (@LHO) tested the ditherServo.pl at Hanford.
He added options to specify exit conditions to the script. Now you can make the script exit when
a condition, such as ArmPower > 1.0, is satisfied, or let it wait until a certain condition is satisfied.

I also modified the script to use ezcastep instead of tdswrite for feedback actuation.
The script now runs ezcastep in the background while the next iteration of the tdsdmd is performed.
Instead of kicking mirrors with a big thrust each time by a single tdswrite command, ezcastep gently moves the mirrors with fine steps.
I also implemented this "background ezcastep" technique in Tobin's tdscntr.pl.

The alignment scripts run smoother now.
  1236   Fri Jan 16 18:45:20 2009 YoichiConfigurationIOOMC_L gain increased by a factor of 2
Rana, Yoichi

Since we fixed the FSS AOM double-pass, which used to be a single-pass, the MC_L gain was too low for
making the cross-over at 100Hz.
Rana increased it by a factor of two. Now it seems that the cross over is ok (attachment 1).

We also noticed that the MC_F spectrum is noisier than before (attachment 2).
The reference is from 6/24/2008.
Attachment 1: MC_F-MC_L-xover.pdf
Attachment 2: MC_F.pdf
  1235   Fri Jan 16 18:33:54 2009 YoichiSummaryComputersc1lsc rebooted to fix 16Hz glitches
Kakeru, Yoichi

There were 16Hz harmonics in the PD3 and PD4 channels even when there is no light falling on it.
Actually, even when the connection to the ADC was removed, the 16Hz noise was still there.

Rob suggested that this might be digital problem, because data is sent to the daq computer very 1/16 of a second.

We restarted c1lsc and the problem went away.
  1234   Fri Jan 16 18:29:08 2009 YoichiUpdateSUSOplevs QPDs centered
Kakeru centered ITMX and BS optical levers with the help of Jenne on the walkie-talkie.
  1233   Fri Jan 16 18:25:32 2009 Yoichi, Kakeru, RanaUpdateLSCArms were unstable
The single arm lock had been unstable for both arms in the past few days.

When an arm was locked by itself, the transmitted power showed a lot of fluctuations (sharp drops).
The first attachment shows the arm power fluctuations in power spectrum and time series.
References are when the boost filters are off for the arm feedback.
You can see that when the boosts are off, the power fluctuates a lot.
Also it is obvious that X-arm is a lot worse than Y.

The second attachment is the comparison of the error signal spectra between boosts on and off.
(PD3_I is the error signal of X-arm, PD4_I is Y arm). References are boost on.
Since the arm power fluctuation was suppressed by the gain increase, it was suspected that the main
reason for the power fluctuation is not alignment fluctuation. Rather, it is length or frequency fluctuation.

Then I took spectra and coherences of PD3_I, PD4_I and MC_F with both arms locked independently.
You can see broadband coherence between PD3_I (Xarm) and MC_F (frequency noise). In contrast the coherence
between PD4_I and MC_F is smaller. This means X-arm is more susceptible to the frequency noise than Y.
What can make a simple Fabry-Perot cavity more susceptible to frequency noise ? An offset ?
So I canceled the X-arm offset at the X-arm filter bank. Bingo ! The arm power fluctuation of X-arm became as small as Y-arm
in the dataviewer.
But what is making this offset ?
After watching the dataviewer screen for a while, the arm power fluctuation became larger again. I had to re-adjust the artificial offset
to minimize the fluctuation. This made me think that the source of the offset must be something to do with alignment.
In this case, clipping of the beam at the PD was very suspicious.
So I checked the centering of the POX and POY PDs. As expected, POX was terribly off-centered.
POY was also not exactly at the center of the plateau of DC output.
After centering those PDs, the large offset in the arm loops went away.
Now the arm powers are stable without artificial offset in the loop filters.
The last attachment shows the comparison of arm power fluctuation before and after the PD centering.
(references are the measurements before the centering).
Attachment 1: TRXY.pdf
Attachment 2: ErrorSignals.pdf
Attachment 3: coherenceBetweenArms.pdf
Attachment 4: ArmPowersAfterPDwasCentered.pdf
ELOG V3.1.3-