40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 179 of 341  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  1140   Mon Nov 17 15:07:06 2008 YoichiUpdatePSLReference cavity ring down
I used MATLAB's system identification tool box to estimate the response of the reference cavity, i.e. cavity pole.
What I did was basically to estimate a model of the RC using the time series of the measured input and output power.

First, I prepared the input and output time series for model estimation.
The input is the input power to the RC, which I produced by inverting the PBS reflected light power and adding an offset
so that the signal is zero at t=0. Offset removal was necessary to make sure that the input time series does not give an
unintentional step at t=0.
The output time series is the transmission power of the RC. I also added an offset to make it zero at t=0.
Then I commanded MATLAB to compute the response of a first order low-pass filter to the input and try to fit
the computed response to the measured output by iteratively changing the gain and the cut-off frequency.
("pem" is the name of the command to use if you are interested in).

The result is shown in the attachment.
Blue curve is the input signal (I added a vertical offset to show it separately from the output).
The green curve is the measured output (RC transmission). The red curve is the response of the estimated model.
The estimated cut-off frequency was about 45kHz.

You can see that the red curve deviates a lot from the green curve after t=15usec.
By looking at this, I realized that the bandwidth of the RC cavity servo was too high.
The time scale we are looking at is about 50kHz whereas the FSS bandwidth is about 400kHz.
So when the input light was cut off, the error signal of the FSS becomes meaning less and the
input laser frequency was quickly moved away from the resonance. This is why the green curve does not
respond to the large peaks in the blue curve (input). The cavity was already off-resonance when the input power
showed bumps.

Since the red curve matches nicely with the green curve at the very beginning of the ring down, the estimated 45kHz
cavity pole is probably not that a bad estimate.

To make a better measurement, I will try to reduce the bandwidth of the RC servo by using only the PZT actuator.
If there were no ringing in the input light power, we wouldn't have to worry about the bandwidth of the servo because our
feedback is all made to the laser, not the cavity length.
In order to reduce the ringing in the input power, I asked Bob to make new HV cables using HV grade coax cables.
  1144   Tue Nov 18 19:37:23 2008 YoichiUpdateIOOMC1 OSEM signals sign flipped and c1susvme1 restart problem
Around 2PM, MC1 started to swing crazily.
The damping feedback was not working and it was actually exciting the mirror wildly.
It turned out that the sign of the UR and UL OSEM signals flipped at that time.
Restarting c1sosvme fixed the problem.

While I was looking for the cause of the problem, c1susvme1 and c1susvme2 failed several times.
I don't know if it is related to this problem.
Now it is not trivial to restart c1susvme1. It fails to restart if you just power cycle it.
Alberto and I had to connect an LCD and a keyboard to it to see what was going on. After pushing the reset button on the front panel,
I had to press Ctrl+x. Otherwise, the state LED of c1susvme1 stays red and nothing happens.
After Ctrl+x, the boot screen came up but the boot sequence failed and an error message something the following was shown:
"PXE Boot failed, check the cable"
So I swapped the network cable with c1susvme2, which was already up and running.
This time, c1susvme1 started fine and surprisingly, c1susvme2 stayed alive.
Currently, both c1susvme1 and c1susvme2 are up and running with the LAN cables swapped.
We have to check the LAN cables.
  1177   Fri Dec 5 01:41:33 2008 YoichiConfigurationComputersMEDM screen snapshot now works on linux machines
As a part of my "make everything work on linux" project, I modified 'updatesnap' script so that linux machines can update MEDM screen snapshots.
Now, all 'updatesnap' in the subsystem directories (like medm/c1/lsc/cmd/updatesnap) are sym-link to /cvs/cds/caltech/medm/c1/cmd/updatesnap.
This script will take a window snapshot to a PNG file, and move the old snapshot to archive folders with date information added to the filename.
For compatibility, it also saves JPEG snapshot. Right now, most of 'view snapshot' menus in MEDM screens are calling 'sdtimage' command, which cannot display PNG files. I installed Imagemagick to op440m. We should change MEDM files to use 'display' command instead of 'sdtimage' so that it can show PNG files.
I've already changed some MEDM screens, but there are so many remaining to be modified.

PNG is better than JPEG for crisp images like screen shots. JPEG performs a sort of spacial Fourier transformations and low-pass filtering to compress the information. If it is used with sharp edges like boundaries of buttons on an MEDM screen, it naturally produces spacial aliasing (ghost images).

I also created several sym-links on the apps/linux/bin directory to mimic the Solaris-only commands, such as 'sdtimage', 'nedit' and 'dtterm'.
For example, nedit is symbolic linked to gedit. Many MEDM buttons/menus, which used to be incompatible with linux, now work fine on the linux machines.
  1178   Fri Dec 5 01:58:58 2008 YoichiConfigurationASCtdscntr.pl now works at 40m
Tobin gave me the perl version of tdscntr some time ago.
Pinkesh and I modified and tested it at LHO.
I further modified it today and now it runs fine on the linux machines at the 40m. I haven't tested it with the Solaris machines.
My modifications include changing channel names to 40m ones, and using tdsavg to get QPD data rather than ezcaread.
The use of tdsavg is intended to avoid aliasing problem.
tdscntr.pl is installed in /cvs/cds/caltech/apps/linux/tds/bin

Now, the alignX runs on linux up to the centering of the QPDs.
However, ezcademod seems to behave wrongly on linux. I plan to investigate on this problem tomorrow.
I may try tdsdmd instead.
  1181   Fri Dec 5 20:40:38 2008 YoichiHowToComputersElog multi-keyword search
The current Elog search allows you to look for only one keyword in the text.
You cannot search for two keywords by simply separating them with a white space.
That is, a search term "abc def" matches a literal "abc def", not a text containing "abc" and "def".
This is extremely annoying. However, there are still some ways to search for multiple keywords.
The Elog search fields are treated as regular expressions.
In order to match a text containing "abc" and "def", you can use a search term "abc.*def".
A period (.) means "any character", and an asterisk (*) means "any number of repetition of the preceding character".
Therefore, ".*" matches "any number of any character" i.e. anything.
The search term "abc.*def" works fine when you know "abc" appears first in the text you are looking for.
If you don't know the order of appearance of the keywords, you have two choices: either to use,
The vertical bar (|) means "or". Parentheses are used for grouping.
The first example does exactly what you want. However, you have to list all the permutations of your keywords
separated by |. If you have more than two keywords, it can be a very very long search word.
(The length of the search word is O(n!), where n is the number of keywords).
In the second example, the length of the keyword is O(n). However, it can also match a text containing two "abc".
This means the search result may contain some garbages (entries containing only "abc").
I guess in most cases we can tolerate this.

To automatically construct a multiple keyword search term for the Elog, I wrote a bash script called elogkeywd
and it is installed in the control room machines.
You can type
elogkeywd keyword1 keyword2 keyword3
to generate a regular expression for searching a text containing "keyword1", "keyword2" and "keyword3".
The generated expression is of the second type shown above. You can then copy-and-paste the result to
the Elog search field.
The script takes any number of keywords. However, there seems to be a limit on the number of characters you can type
into the search field of the Elog. I found the practical limit is about 3 keywords.
  1182   Fri Dec 5 21:31:11 2008 YoichiUpdateIOOdrum modes observable without excitation
The calibration of the MC_F feedback is posted in elog:1032.
I'm not sure where Caryn took MC signal, but if you take the signal from the servo out BNC on the MC board, it
directly corresponds to the voltage sent to the FSS VCO.
The DC calibration of the VCO is 1.75MHz/V. Since the AOM is the double-pass, the PSL frequency
change is 3.5MHz/V. At frequencies above 40Hz, the VCO calibration drops by a factor of 39/1000,
because of the pole/zero at 1.6Hz/40Hz in the VCO box.
So at the frequencies of interest (around 30kHz), the servo out voltage can be converted to the PSL frequency
change by 0.137MHz/V.
Since 30kHz is still within the bandwidth of the MC servo, the feedback signal should correspond to the actual
length change of the MC. So the above calibration factor can be used to calibrate Caryn's measurement and check
what Rana suggested.
  1186   Mon Dec 8 11:41:27 2008 YoichiSummaryVACThe rough pump for the TP2 replaced
Bob, Yoichi

The foreline pressure of the TP2 (the foreline pump for the main mag-lev turbo (TP1)) was at 2.8torr this morning
when Bob came in.
Looked like the foreline pump (Varian SH-110) was leaking.
Bob started the backup rough pump in parallel with the "leaking" one to keep the foreline pressure low.
We then closed the valve 4 (between TP2 and TP1) and stopped the TP2 and the SH-110.
We replaced SH-110 with another one, but still the foreline pressure was high.
So we replaced it with yet another one. We also changed the quick coupling fasteners on the SH-110 and wiped the O-rings.
This time, it worked fine and the foreline pressure dropped to around 38 mTorr.

Since there is no valve between the TP2 and the SH-110, we could not keep the TP2 running while we were replacing the
problematic SH-110. This means the TP1 was running without a foreline pump during the work. We tried to minimize the
down time of the TP2. The temperature of the TP1 was 33.6C before we stopped the TP2 and it went up to 37.3C during the
work. It is now coming down to the original temperature.

Since we don't know if the problem was caused by bad SH-110s or leaking quick couplings, Bob is checking these apparently
"leaking" SH-110s.
  1187   Mon Dec 8 11:54:27 2008 YoichiUpdateGeneralIFO mirrors aligned
This morning, I re-aligned the IFO mirrors to see if they were badly moved by the earthquake.
The both arms locked just by the restoring scripts, but the transmission was about 0.7. So I aligned them
with the dithering scripts.
To lock the PRMI, I had to manually tweak the PRM alignment. After running the dithering script, the SPOB
went up to 1200.
I also had to tweak the SRM to get the DRMI locked. After the dithering script, the SPOB was 4200 and REFL166Q
was 3000.
  1188   Mon Dec 8 17:50:21 2008 YoichiUpdateSUSITMY drift
The suspension drift monitor shows that the ITMY alignment was shifted after the earthquake.
Looks like only the UL sensor had a step at the earthquake (see the attachment 1).
So it is probably an electronics problem.
I pushed in the cable between the rack and the ITMY satellite amplifier, but no change observed.
Actually, the ITMY-UL sensor looks like it has been dead before the earthquake.
The second attachment shows a long-term trend of the UL sensor.
The sensor output had been around zero since Nov. 17th.
When I disabled the output of the UL sensor, the sus-drift-mon fields turned green.
So I think the drift-mon's reference values are wrong, and currently the ITMY is in a good alignment.

I also attached the free-swing measurements of the ITMY taken on Aug. 18th and today.
There is no notable change in the resonant frequencies.
  1190   Fri Dec 12 22:51:23 2008 YoichiUpdatePSLReference cavity ring down measurement again
Bob made new HV-cables with HV compatible coaxes. The coax cable is rated for 2kV, which was as high as Bob
could found. I used it with 3kV hoping it was ok.
I also put a series resistor to the pockels cell to tame down the ripples I saw in elog:1136.

Despite those efforts, I still observed large ringings.
I tried several resistor values (2.5k, 1k, 330ohm), and found that 330ohm gives a slightly better result.
(When the resistance is larger, the edge of the PBS Refl. becomes dull).
Since the shape of the ringing does not change at all even when the pulse voltage is lowered to less than 1kV,
I'm now suspicious of the DEI pulser.

Anyway, I estimated the cavity pole using the MATLAB's system identification toolbox again.
This time, I locked the reference cavity using only the PZT feedback, which makes the UGF about a few kHz.
So, within the time scale shown in the plot below, the servo does not have enough time to respond, thus the laser
frequency stays tuned with the cavity. This was necessary to avoid non-linear behavior of the transmitted power
caused by the servo disturbing the laser frequency. With this treatment, I was able to approximate the response of
the cavity with a simple linear model (one pole low-pass filter).

MATLAB estimated the cavity pole to be 47.5kHz.
The blue curve in the plot is the measured RC transmitted power.
The incident power to the cavity can be inferred from the inverse of the red curve (the PBS reflection power).
The brown curve is the response of the first order low-pass filter with fc=47.5kHz to the input power variation.
The blue and brown curves match well for the first 10usec. Even after that the phases match well.
So the estimated 47.5kHz is probably a reasonable number. I don't know yet how to estimate the error of this measurement.

According to http://www.ligo.caltech.edu/~ajw/PSLFRC.png the designed transmission of the reference cavity mirrors is 300ppm (i.e.
the round trip loss (RTL) is 600ppm).
This number yields fc=35kHz. In the same picture, it was stated that fc=38.74kHz (I guess this is a measured number at some point).
The current fc=47.5kHz means, the RTL has increased by 200ppm from the design and 150ppm from the time fc=38.74kHz was measured.
  1191   Tue Dec 16 19:06:01 2008 YoichiUpdatePSLReference cavity ring down repeated many times
Today, I repeated the reference cavity ring down measurement many times to see how much the results vary.

I repeated the ring down for 20 times and the first attachment shows the comparison of the measured and estimated cavity transmission power.
The blue curve is the measured one, and the red curve is the estimated one. There are only 10 plots because I made a mistake when transferring data
from the oscilloscope to the PC, and one measurement data was lost.

The second attachment shows the histogram of the histogram of the estimated cavity pole frequencies.
I admit that there are not enough samples to treat it statistically.
Anyway, the mean and the standard deviation of the estimated frequencies are 47.6kHz and 2.4kHz.
Assuming a Gaussian distribution and zero systematic error, both of which are bold assumptions though, the result is 47.6(+/-0.6)kHz.

Now I removed the Pockels Cell from the RC input beam path.
I maximized the transmission by tweaking the steering mirrors and rotating the HWP.
Since the transmission PD was saturated without an ND filter on it, I reduced the VCO RF power slider to 2.85.
Accordingly, I changed the nominal common gain of the FSS servo to 10.5dB.
  1200   Sun Dec 21 14:18:04 2008 YoichiUpdateComputersRFM network bypass box's power supply is dead
I restarted the front-end computers by power cycling them one-by-one.
After issuing startup commands, most of them started normally at least by looking
at the output from telnet/ssh.
However, the status monitors of the FE computers on the EPICS screen are still red.
I noticed that all the LEDs on the VMIC 5594 RFM network bypass box are off.
According to the labels, fb40m, c0daqctrl, c0dcu are connected to the box.
This means (I believe) c1dcuepics cannot access the RFM network. So we have no control over
the FE computers through EPICS.

I pushed the reset button on the box, power cycled it, but nothing changed.
I checked the fuse and it was OK. Then I found that the power supply was dead.
It is a small AC adapter supplying +5VDC with a 5-pin DIN like connector.
We have to find a replacement.
  1201   Mon Dec 22 13:48:22 2008 YoichiUpdateComputersRFM network bypass box's power supply is dead
As a temporary fix, I cut the cable of the power supply and connected it to the Sorensen power supply +5V on the rack.
Now, the RFM bypass box is powered up, but some LEDs are red, which looks like a bad sign.
I restarted all the FE computers, but this time I got errors during the execution of the startup commands in the VxWorks machines.
The errors are "General Protection Fault" or "Invalid Opcode".
The linux machines do not show errors but still the status lights in EPICS are red.
We need Alex's help. He did not answer the phone, so Alberto left a voice mail.
  1202   Tue Dec 23 10:35:40 2008 YoichiUpdateComputersRFM network breakdown mostly fixed
Rana, Rolf, Alberto, Yoichi

The source of the problem was the RFM bypass box, as expected.
Rana pointed out that the long cable I used to bring the 5V from the Sorensen to the box
may cause a large voltage drop considering that the box is sucking ~3A.
So we connected the cable to another power supply (5V/5A linear power supply).
Then the LEDs on the bypass box turned green from red, and everything started to work.

A weired thing is that when I connected the cable to the wrong terminals of the power supply which
have lower current supply capabilities, the supply voltage dropped to 3V, but still the LEDs on the bypass box
turned green. This means the bypass box can live with 3V.
I noticed that there is a long cable from the Sorensen to the cross connect on the side of the rack, where I
connected my cable to the bypass box. This long cable had somewhat large resistance (1 or 2 Ohms) and dropped
the supply voltage to less than 3V ?
Anyway, the bypass box is now on a temporary power supply. Alberto was assigned a task to find a replacement power

There are two remaining problems.
c1susvme1 fails to start often claiming a DMA error on a Pentek. After several attempts, you can start the machine,
but after a while (1 hour ?) it fails again.
op340m is not responding to ssh login. It responds to ping.
We hooked up a monitor and keyboard (USB because the machine does not have a PS/2 port) to it and rebooted.
At the boot, it briefly displays a message "No keyboard, try TTYa", but after that no display signal.
Steve found me a serial cable. I will try to login to the machine using the serial port.

  1203   Wed Dec 24 10:33:24 2008 YoichiUpdateComputersSeveral fixes. Test point problem remains.
Yesterday, I fixed several remaining problems from the power failure.

I found a LEMO cable connecting the timing board to the Penteks was lose on the c1susvme1 crate.
After I pushed it in, the DMA error has not occured on c1susvme1.

I logged into op340m using a Null Modem Cable.
The computer was failing to boot because there were un-recoverable disk errors by the automatic fsck.
I run fsck manually and corrected some errors. After that, op340m booted normally and now it is working fine.
Here is the serial communication parameters I used to communicate with op340m:
>kermit      (I used kermit command for serial communication.)
>set modem type none
>set line /dev/ttyS0     (ttyS0 should be the device name of your serial port)
>set speed 9600
>set parity none
>set stop-bits 1
>set flow-control none

After fixing op340m, the MC locked.
Then I reset the HV amps. for the steering PZTs.
Somehow, the PZT1 PIT did not work. But after moving the slider back and forth several times, it started to work.

I reset the mechanical shutters around the lab.

I went ahead to align the mirrors. The X-arm locked but the alignment script did not improve
the arm power.
I found that test points are not available. (diag said test point management not available).
Looks like test point manager is not running. Called Rolf, but could not reach him.
I'm not even sure on which machine, the tp manager is supposed to be run.
Is it c0daqawg ?
  1204   Wed Dec 24 12:46:54 2008 YoichiUpdateComputersTest points are back
Rob told me how to restart the test point manager.
It runs on fb40m and actually there is an instruction on how to do that in the Wiki.

I couldn't find the page because when I put a keyword in the search box on the upper right
corner of the Wiki page and hit "enter", it only searches for titles. To do a full text
search, you have to click on the "Text" button.

Anyway, now the test points are back.
  1206   Mon Dec 29 21:38:57 2008 YoichiUpdateComputersSnapshots of MEDM screens
I wrote scripts to take snapshots of MEDM screens in the background.
These scripts work even on a computer without a physical display attached.
You don't need to have X running.
So now the scripts run on nodus every 5 minutes from cron.
The screen shots are saved in /cvs/cds/caltech/statScreen/images/

There is a wiki page for the scripts.

Someone has to make a nice web page summarizing the captured images.
  1207   Mon Dec 29 21:51:02 2008 YoichiConfigurationComputersWeb server on nodus
The apache on nodus has been solely serving for the svn web access.
I changed the configuration and all files under /cvs/cds/caltech/users/public_html/ can be seen under

The page is not password protected, but you can add a protection by putting an appropriate .htaccess
in your directory.
For the standard LVC password, put the following in your .htaccess
AuthType Basic  
AuthName "LVC password"
AuthUserFile /cvs/cds/caltech/apache/etc/LVC.auth
Require valid-user
  1209   Wed Dec 31 22:59:40 2008 YoichiSummaryEnvironmentParticle counts going crazy
Yes it is a new year's eve, and a lot of crazy people are on Colorado to secure seats for the parade tomorrow.
They are burning woods to warm themselves. So smoky smell is floating around in the campus
and naturally the particle count is going up.

Actually at first I thought some building is on fire and called the security. Then they found
that it is the people on Colorado.

Now C1:PEM-count_half is 28400 and it is still climbing up.
  1210   Thu Jan 1 00:55:39 2009 YoichiUpdateASCAlignment scripts for Linux
A Happy New Year.

The dither alignment scripts did not run on linux machines because tdscntr and ezcademod do not run
on linux. Tobin wrote a perl version of tdscntr and I modified it for 40m some time ago.
Today, I wrote a perl version of ezcademod. The script is called ditherServo.pl and resides in /cvs/cds/caltech/scripts/general/.
It is not meant to be a drop-in replacement, so the command line syntax is different. Usage is explained in the comment of the script.

Using those two scripts, I wrote linux versions of the alignment scripts.
Now when you call, for example, alignX script, it calls alignX.linux or alignX.solaris depending on the OS of
your machine. alignX.solaris is the original script using the compiled ezcademod.
In principle, ezcademod is faster than my ditherServo.pl because my script suffers from the overhead of
calling tdsdmd on each iteration of the servo. But in practice ditherServo.pl is not that bad. At least, as far as
the alignment is concerned, the performances of the both commands are comparable in terms of the final arm power and the convergence.

Now the alignXXX commands from the IFO Configure MEDM screen work for X-arm, Y-arm, PRM and DRM. I did not write a script for Michelson, since
it is optional.
I confirmed that "Align Full IFO" works correctly.
  1211   Thu Jan 1 01:07:03 2009 YoichiSummaryEnvironmentParticle counts going crazy
I increased the fan speed of the PSL HEPA filter to the maximum.

Yes it is a new year's eve, and a lot of crazy people are on Colorado to secure seats for the parade tomorrow.
They are burning woods to warm themselves. So smoky smell is floating around in the campus
and naturally the particle count is going up.

Actually at first I thought some building is on fire and called the security. Then they found
that it is the people on Colorado.

Now C1:PEM-count_half is 28400 and it is still climbing up.
  1212   Thu Jan 1 01:15:45 2009 YoichiSummaryVACN2 line leak ?
I've been replacing the N2 bottles recently.
I noticed that the consumption is too high. I had to replace them every two days.
Normally the interval is three or more days.
I suspect there is some leak in the line.

Strangely, it is always the left hand bottle which goes empty. The right hand bottle has been
there for more than a week at about 1000 psi.

We should check it when Steve is back.
  1214   Fri Jan 2 18:49:54 2009 YoichiUpdateLSCLSC modulation frequencies adjusted
I noticed that the IFO did not lock in the MICH configuration.
This was because AS166Q signal was too small.
The demodulation phase seemed not right, i.e. the I-phase signal was larger than Q.
I suspected that the 166MHz modulation frequency was not exactly on the MC FSR, since I just
recovered the number written on the Marconi after the power failure.
I measured the optimal frequency by the method explained in elog:752.
It was 165981500Hz, which is pretty close to the number Rob measured in elog:952, but significantly different from
the label on the Marconi.
I set the frequencies of all the MARCONIs accordingly and updated the labels.

After this, the AS166 demodulation phase was still not good enough (the Q and I signals were about the same).
So I rotated the phase by 45deg. In principle, this should set the demod-phase right for DARM too. Is it correct, Rob ?
I also adjusted the PD offsets. After those adjustments, MICH locks stably with a slightly increased gain (20 as compared to 10 before).
  1223   Mon Jan 12 18:53:03 2009 YoichiUpdateLSCAS CCD centering and ASDD demod phase
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.
  1231   Fri Jan 16 11:28:54 2009 YoichiUpdateComputersLab. laptop needs wireless lan driver update
One of the lab. laptops (belladonna) cannot connect to the network now.
I guess this was caused by someone clicked the update icon and unknowingly updated the kernel, which resulted in the wireless lan driver malfunctioning.
It was using a Windows driver through ndiswrapper.
Someone has to fix it.
  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.
  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.
  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.
  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.
  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.
  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.
  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.
  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.
  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 ?
  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.
  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.
  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.
  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.
  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.
  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
  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
  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.
  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.

  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.

  1284   Mon Feb 9 16:02:42 2009 YoichiUpdatePSLPSL relative intensity noise
I attached the relative intensity noise of the PSL.
There is no bump around the lower UGF (~1Hz), but at the higher UGF (~30kHz) there is a clear bump.
When the ISS gain slider was moved up to 21dB, the peak got milder, because there is larger phase margin at higher frequencies with the current filter design.
We may want to optimize the filter later.
  1285   Mon Feb 9 16:05:01 2009 YoichiUpdateLSCDRMI OK

After the ISS work, I aligned the IFO and confirmed that DRMI locks with good SPOB and AS166 values.

  1286   Mon Feb 9 17:09:51 2009 YoichiUpdateComputersA bunch of updates for the network GPIB stuff.
During the work on ISS, we noticed that netgpibdata.py is very unreliable for SR785.
The problem was caused by flakiness of the "DUMP" command of SR785, which dumps the data from the analyzer to the client.
So I decided to use other GPIB commands to download data from SR785. The new method is a bit slower but much more reliable.

I also rewrote netgpibdata.py and related modules using a new class "netGPIB".
This class is provided by netgpib.py module in the netgpibdata directory. If you use this class for your python program, all technical details and dirty tricks are hidden in the class methods. So you can concentrate on your job.
Since python can also be used interactively, you can use this class for a quick communication with an GPIB instrument.

Here is an example.
>ipython #start interactive python
>>import netgpib #Import the module
>>g=netgpib.netGPIB('teofila',10) #Create a netGPIB object. 'teofila' is the hostname of
#the GPIB-Ethernet converter. 10 is the GPIB address.
>>g.command('ACTD0') #Send a GPIB command "ACTD0". This is an SR785 command meaning "Change active display to 0".
>>ans=g.query('DFMT?') #If you expect a response from the instrument, use query command.
#For SR785, "DFMT?" will return the current display format (0 for single, 1 for dual).
>>g.close() #Close the connection when you are done.

Sometimes, SR785 gets stuck to a weird state and netgpibdata.py may not work properly. I wrote resetSR785.py command to reset it remotely.
Wait for 30sec after you issue this command before doing anything.

I wrote two utility commands to perform measurements with SR785 automatically.
TFSR785.py commands SR785 to perform a transfer function measurement.
SPSR785.py will execute spectrum measurements.
You can control various parameters (bandwidth, resolution, window, etc) with command-line options.
Run those commands with '-h' for help.
It is recommended to use those commands even when you are in front of the analyzer, because they save various measurement parameters (input coupling, units, average number, etc) into a parameter file along with the measured data. Those parameters are useful but recording them for each measurement by hand is a pain.
  1287   Mon Feb 9 19:50:48 2009 YoichiConfigurationPSLISS disconnected
We are doing measurements on ISS.
The ISS feedback connector is disconnected and the beam to the MC is blocked.
  1291   Wed Feb 11 07:28:25 2009 YoichiUpdatePSLPA current and laser output
I think we should also plot the laser power at the MOPA output. The horizontal axis should be the absolute current value read from the PA current monitor channel, not the slider value.

This result is consistent with my hypothesis that the thermal effect is canceling the power change at low frequencies (see elog:1276).
But if it is really caused by thermal effect or not is still unknown.

I'd like to see a larger scan into the lower current region.

I changed the PA current and measured laser output power (monitor PD signal).
The gain of ISS is 13dB
Attached figure is the relation of PA current and the average and standard diviation of laser output.
The average of output power decreas as current increase. It looks something is wrong with PA.
When current is -0.125, 0, 0.5, ISS become ocsilating. This looks to be changed from previous measurement.

I wrote matlab code for this measurement. The code is
This function uses
  1292   Wed Feb 11 10:52:22 2009 YoichiConfigurationDAQC1:PEM-OSA_APTEMP and C1:PEM-OSA_SPTEMP disconnected

During the cleanup of the lab. Steve found a box with two BNCs going to the ICS DAQ interface and an unconnected D-SUB on the floor under the AP table.  It seemed like a temperature sensor.

The BNCs were connected to C1:PEM-OSA_APTEMP and C1:PEM-OSA_SPTEMP.

Steve removed the box from the floor. These channels can be now used as spare DAQ channels. I labeled those cables.

ELOG V3.1.3-