40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 315 of 337  Not logged in ELOG logo
ID Date Author Type Category Subject
  1127   Mon Nov 10 16:44:14 2008 steveUpdatePEMparticle counter at MC2
The particle counter was moved to MC2 table temporarily.
It is clamped to the table at the south west corner.
It is pumping for 20s and waiting for 2 minutes now.
  1126   Mon Nov 10 11:32:49 2008 robUpdateComputersc1iscex rebooted

it was running a few cycles late
  1125   Mon Nov 10 11:06:09 2008 robHowToIOOmode cleaner locked

I found the mode cleaner unlocked, with (at least) MC1 badly mis-aligned. After checking the coil alignment biases and finding everything there looking copasetic, I checked the trends of SUS{PIT,YAW,POS} and found that both MC1 and MC3 took a step this morning. The problem turned out to be loosed/jiggled cables at the satellite amplifiers for these suspensions. Giving them a good hard push to seat them restored the alignment and the mode cleaner locked right up.
  1124   Fri Nov 7 18:38:19 2008 AlbertoDAQPSLMC temperature sensor hooked up
Alberto, Rana,
we found that the computer handling the signals from ICS-110B was C1IOVME so we restarted it. We changed the name of the channel to C1:PEM_TEMPS and the number to 16349. We tracked it up to the J14 connector of the DAQ.
We also observed the strange thing that both of the differential pairs on J13 are read by the channle. Also, if you connect a 50 Ohm terminator to one of the pairs, the signal even get amplified.

(The name of the channel is PEM-MC1_TEMPS)
  1123   Fri Nov 7 16:05:55 2008 steveBureaucracySAFETYinsect killer sprayed at kitchen area !

Bob and I cleaned out the sink area and sprayed
Spectracide's BUG STOP insect killer solution on the shelfs and sink
table top area.

NO eating or coffee drinking till Monday

This is an effort to stop the ants coming.
  1122   Fri Nov 7 15:58:10 2008 ranaUpdatePEMAC is back on
I'll bet Steve a dollar that it is mechanical. The attached PDF compares all of the accelerometers from right now.

You can see that the RMS in MC2 is way bigger than MC1.

In the second PDF file you can see the time series. I had to play around a lot with DTT to get it to work. The DTT/Foton
combo on Allegra is not stable, so make sure your work early and often.

In the plots shown, I am bandpassing the time series from 600-700 Hz. I found that doing so allowed the burp in MC1 to remain
large and reduce the extraneous fuzz in MC2. As you can see there is no such noise in MC2.

So its a noise around 600-700 Hz that comes on quickly and then shuts off after several seconds. Its also very periodic in that
it comes on around every 20 minutes. Steve also tells me (although he refuses to put in the elog) that it started up around
August 20th (?). I feel like someone in the 40m lab ought to be able to guess what this is at this point.

Please convince Steve to elog his findings about when the noise started.

If one goes out there and stands next to it when the trend predicts its happening it becomes clear what it is.
Attachment 1: mc-acc.pdf
Attachment 2: mc-acc-quad.pdf
  1121   Fri Nov 7 10:52:57 2008 steveUpdatePEMAC is back on
The 20 minutes and 6 sec thumps are not related to the 40m ac units
This period is precisely right on so it is not likely mechanical as a source.
The time and frequency domain of this signal at attachment 2&3

First I had the chilling water cut off and later I turned off the fans
as 5 hrs temp plot shows
Attachment 1: acf.jpg
Attachment 2: acc_mc1.jpg
Attachment 3: test.jpg
  1120   Fri Nov 7 08:08:00 2008 steveUpdatePEMAC turned off in IFO room
All tree AC units in IFO room 104 switched off at 7:45am
I'm looking for the periodic thump signal in the Vertex area
noted in entry 1113 of PEM-ACC_MC1
  1119   Thu Nov 6 22:07:56 2008 ranaConfigurationComputersELOG compile on Solaris
From the ELOG web pages:


Martin Huber reports that under Solaris 7 the following command line is needed to compile elog:

gcc -L/usr/lib/ -ldl -lresolv -lm -ldl -lnsl -lsocket elogd.c -o elogd

With some combinations of Solaris servers and client-side browsers there have also been problems with ELOG's keep-alive feature. In such a case you need to add the "-k" flag to the elogd command line to turn keep-alives off.
  1117   Thu Nov 6 10:06:41 2008 steveUpdateLockingarms lock degradation
I have been locking the arms in the mornings lately.
The daily drift of LSC-TRX is ~ 15% and LSC-TRY ~5%
Attachment 1: arms.jpg
  1116   Thu Nov 6 09:45:27 2008 steveUpdateMOPAhead temp hick-up vs power
The control room AC temp was lowered from 74F to 70F around Oct 10
This hold the head temp rock solid 18.45C for ~30 days as it shows on this 40 days plot.
We just had our first head temp hick-up

note: the laser chiller did not produce any water during this period
Attachment 1: htpr.jpg
  1115   Wed Nov 5 12:41:36 2008 AlbertoUpdateLSCAbsolute Length and g-factor measurements conclusions
Absolute Length and g-Factor Measurement for the 40m Arm Cavities, Summary of Results

Lately locking the interferometer in the so called spring configuration (SRC on +166 MHz sideband) has been difficult and a possible resonance of an higher order mode of the +166 MHz sideband in the arms was
hypothesized as the cause. We wanted to know the frequencies of the HOMs of the sidebands and see where they are, relatively to the carrier resonance.

A second laser beam from an NPRO is injected into the interferometer through the AS port. The beam is mode matched to the arm cavities so that it can resonate inside of these. The secondary beam interferes with
the PSL beam and the incident intensity on one end mirror, excluding by now any higher mode, is I(t)=I1+I2+(interference terms)*exp[-i*(f1-f2)*t]. The last term comes from the beat between the two fields at the
relative frequency of the two lasers. For beating frequencies multiple of the FSR of the cavity, the beat gets transmitted and appears at the trans PD.
Whereas the PSL has a constant frequency, the NPRO frequency fluctuates, so that the relative phase between the two is not constant. To prevent that, a PLL servo locks the phase of the NPRO to that of the PSL.
The result is a beat frequency at the steady and tunable value set by the local oscillator of the PLL.

Length Measurement
One arm at a time, the cavity is locked to the TEM00 mode of the main laser. The beat frequency is then scanned for a few cavity FSRs and the transmitted power is measured. A linear fit of the resonant frequencies gives
us the FSR of the cavity.

g-factor Measurement
For non-planar Fabry-Perot cavities, the HOMs of the laser are not degenerate and resonate in the cavity at frequencies different from the correspondent fundamental mode. The shift in frequency is measured by the
Transverse Mode Spacing (TMS) and it is a function of the g-factors of the cavity:


with g1=1-L/R1, where L is the cavity absolute length and R1 the radius of curvature of the input mirror, and similarly for g2 for the end mirror.
We measured the TMS by means of the beat between an HOM of the main laser and the TEM00 of the secondary beam. To do that we locked the cavity to either TEM01/10 and looked at the transmitted power for frequencies
of the beat around the TMS expected from the design parameters of the cavity.
Since the phase of the intensity of the beat between TEM01/10 and TEM00 has only DC components if measured across a symmetric portion of the spot, it is necessary to brake the symmetry of the incident beam on the
PD by chopping it just before it hits the sensor.
We approximated g1=1 for the ITMs. The effect of an astigmatic ETM is to brake the degeneracy of the TEM10 and TEM01 modes and split their resonant frequencies. By measuring that shift, we can evaluate the radius
of curvature of the mirror for the axis of the two transverse modes.

X Arm
FSR     =  (3897627 +/- 5 )   Hz
L       = (38.45833  +/- 0.00005) m
g2x     =   0.31197  +/- 0.00004
g2y     =   0.32283  +/- 0.00004
R-ETM_x = (55.8957   +/- 0.0045) m
R-ETM_y = (56.7937   +/- 0.0038) m

Y Arm
FSR     = ( 3879252 +/- 30 )  Hz
L       = (38.6462   +/- 0.0003) m
g2x     =   0.31188  +/- 0.00004
g2y     =   0.32601  +/- 0.00004
R-ETM_x = (56.1620   +/- 0.0013) m
R-ETM_y = (57.3395   +/- 0.0011) m

The attached graphs,one for the X arm and the other for the Y arm, plot the distributions of the first HOMs of the sidebands near the carrier resonance in the arm cavities. As it appears, the resonances of
the +166 sideband are far enough for not resonating in the arm cavities if the arms are locked to the carrier.
We have to look for something else to explain the locking problem of the interferometer in the spring configuration.
Attachment 1: 2008-11-04_file_02-05.png
Attachment 2: HOM_resonances_Xarm.png
Attachment 3: HOM_resonances_Yarm.png
  1114   Tue Nov 4 17:58:42 2008 AlbertoDAQPSLMC 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.
  1113   Tue Nov 4 01:03:01 2008 ranaSummaryPEMperiodic thump noise in MC1_ACC
There seems to be a periodic thump seen by the MC1 Accelerometers as well as the surrounding optics.

The first 5 hour minute-trend plot shows the periodic thumping as well as the one large saturating event which ruins the
Wiener noise subtraction.

The second plot is a 30 minute second-trend zoom in.
Attachment 1: Untitled.png
Attachment 2: Untitled2.png
  1112   Tue Nov 4 00:47:53 2008 ranaUpdateASSWiener Filter performance over 5 hours
Same as before, but now with a working Ranger seismometer.

In the spectrogram, the color axis is now in dB. This is a whitened spectrogram, so 0 dB corresponds to
the average (median) subtraction. The color scale is adjusted so that the large transients are saturated
since they're not interesting; from the DV trend its some kind of huge glitch in the middle of the
night that saturated the MC1 accelerometers only (maybe a pump?).

The attached trend shows the 5 hours used in the analysis.
Attachment 1: f2.png
Attachment 2: f.png
  1111   Mon Nov 3 22:35:40 2008 ranaUpdateASSWiener Filter performance over 5 hours
To speed up the Wiener filter work I defined a 256 Hz version of the original 16kHz IOO-MC_L signal. The
attached plots show that the FE decimation code works correctly in handling the anti-aliasing and
downsampling as expected.
Attachment 1: DAQ.pdf
  1110   Mon Nov 3 21:38:32 2008 YoichiConfigurationGeneralnew elog

I tried to recompile the elog from the source code but the way gcc is called must be wrong because I get this error message:

gcc -DHAVE_SSL -o elog src/elog.c -lsocket -lnsl -lssl
src/elog.c:45:25: openssl/ssl.h: No such file or directory
src/elog.c:329: error: parse error before "SSL"

The location of ssl.h is a bit strange in the sunfreeware version of OpenSSL. Since elog does not use configure script, you have to
edit Makefile and add an appropriate -I option to an appropriate variable definition (probably LIBS or CFLAGS, because the elog Makefile does
not use INCLUDES).
If you don't understand what I'm saying, just wait for me.
  1109   Mon Nov 3 19:18:47 2008 AlbertoConfigurationGeneralnew elog
Phil Ehrens kindly poured our elog's content in a CD that now is here at the 40m.
I've been trying to install the 2.7.5 version of the elog on Nodus, a Sun machine, but the installing procedure is different from linux and I dont' know it. I tried to recompile the elog from the source code but the way gcc is called must be wrong because I get this error message:

gcc -DHAVE_SSL -o elog src/elog.c -lsocket -lnsl -lssl
src/elog.c:45:25: openssl/ssl.h: No such file or directory
src/elog.c:329: error: parse error before "SSL"
src/elog.c: In function `ssl_connect':
src/elog.c:331: error: `SSL_METHOD' undeclared (first use in this function)
src/elog.c:331: error: (Each undeclared identifier is reported only once
src/elog.c:331: error: for each function it appears in.)
src/elog.c:331: error: `meth' undeclared (first use in this function)
src/elog.c:332: error: `SSL_CTX' undeclared (first use in this function)
src/elog.c:332: error: `ctx' undeclared (first use in this function)
src/elog.c:340: error: `ssl_con' undeclared (first use in this function)
src/elog.c:341: error: `sock' undeclared (first use in this function)
src/elog.c: In function `retrieve_elog':
src/elog.c:383: error: `SSL' undeclared (first use in this function)
src/elog.c:383: error: `ssl_con' undeclared (first use in this function)
src/elog.c: In function `submit_elog':
src/elog.c:631: error: `SSL' undeclared (first use in this function)
src/elog.c:631: error: `ssl_con' undeclared (first use in this function)
make: *** [elog] Error 1

Joe, Yoichi, anyone else knows how to do that?
  1108   Mon Nov 3 19:12:27 2008 albertoUpdateGeneralTransverse mode spacing measurement for the X arm
I know a lot of expectations have been building up on these days in the scientific community at the 40m towards a conclusive elog entry about the g-factor measurement of the X arm cavity.
The reason of the delay is that the results are still under review by the author. It turned out that the measurements of the transverse mode spacing have been performed on the beat
of the TEM02/20 and TEM00 modes between the two laser beams instead of on the beat between 00 and 01/10. However, the results posted on the elog in the last weeks seem likewise correct,
in particular my plot of the HOM of the sidebands.

Anyways, lately I have been trying to repeat the measurement on the beat of TEM01/10 with 00 but, despite all the efforts and the countless configurations tried (on the locking of
the arm, on the tilt of the mirrors, on the injection of the secondary beams, on the chopping with the blade), only the beat of TEM10 has been measured - although quite clearly -
whereas that of TEM01 has so far hidden itself.

The search continues but even if it does not succeeds, a summarizing document is going to be posted soon.

Here I attach a plot that shows the kind of difficulties trying to detect TEM10. The red neat peak is the beat of TEM01 whereas the other curves are some of the resulting
resonances after trying to couple TEM10 with 00 (or vice versa, according to whether I'm locking the cavity to the 00 mode of the main laser or to that of the secondary beam).
Attachment 1: 2008-11-02_summarizingplot.png
  1107   Mon Nov 3 09:59:47 2008 steveUpdatePSLPSL HEPAs turned on
The psl enclosure HEPAs were tuned on.

Loose paper drawing was found on the psl inside shelf.
This can fall down into the beam and ignite a tragedy.

Thanks for the color coded correction. My spell checker is not reliable
  1106   Sun Nov 2 21:37:22 2008 ranaUpdatePEMRanger recovery
The ranger signal has been bad since around 11 AM on Oct 25 (last Saturday). There are no elog
entries from that day, but I am quite sure that someone must have been working around the PSL
rack area.

It looks like what happened is that someone moved the chair with the monitor on it and/or the wooden
stool next to it. That put tension on the cable connecting the SR560 and the seismometer. The SR560
connector now seems loose and I think probably the cable ground wasn't connected. I swapped the
cable over to the "B" side of the SR560 and the ranger signal is now reasonable (very small offset
and normal seismic signal).

Please be careful when working around there. Everyone always says "I didn't do anything" or "it doesn't
effect anything".

We need to clean up the cabling around there in addition to running a new power cable for the RF amplifier
on the POY table.

I have also reduced its sample rate from 2048 to 512 Hz. The data are OK after 909640694.

I also increased the sample rate of AS_MIC from 2048 to 16384 Hz but that one seems to be broken
---->> the microphone seems to be either disconnected or broken.
  1105   Sun Nov 2 20:44:58 2008 ranaUpdateASSWiener Filter performance over 5 hours
I took one 2 hour stretch of data to calculate a MISO Wiener filter to subtract the Ranger seismometer
and the 6 Wilcoxon accelerometers from the IOO-MC_L channel. I then used that static filter to calculate
the residual of the subtraction in 10 minute increments for 5 hours. The filter was calculated based upon
the first 2 hours of the stretch.

The MC lock stretch is from Oct 31 03:00 UTC (I think that we are -8 hours from UTC, but the DST confounds me).
So its from this past Thursday night.

I wrote a script (/users/rana/mat/wiener/mcl_comp.m) which takes the static filter and does a bunch of loops
of subtraction to get a residual power spectrum for each 10 minute interval.

In the attached PNG, you can see the result. The legend is in units of minutes from the initial t0 = 03:00 UTC.

BLACK-DASHED -- MCL spectrum before subtraction

I have also used dashed lines for some of the other traces where there is an excess above the unsubtracted data.
Other than those few times, the rest are all basically the same; this indicates that we can do fine with a very
slow adaptation time for the feed-forward filters
-- a few hours of a time constant is not so bad.

After making the plot I noticed that the Ranger signal was totally railed and junky during this time.
This probably explains the terrible performance below 1 Hz (where are those Guralps?)

The second attached image is the same but in spectrogram form.
Attachment 1: f.png
Attachment 2: f1.png
  1104   Sun Nov 2 20:21:58 2008 ranaConfigurationloreHP 5550dtn (Grazia) set up on allegra
I set up printing to grazia from allegra. The CUPS interface was not as straightforward as Tobin had made it seem in the Wiki. I had to type in the IP address and port number by hand.

The steps (AFAIR):
1) Goto http://localhost:631/
2) Click on "Add Printer"
3) Choose HP JetDirect
4) Use the correct address (socket://
5) Choose HP and the 5550 postscript driver as the options
6) Try to only print useful stuff and not kill too many trees.
  1103   Fri Oct 31 08:52:19 2008 steveUpdateSUSETMY damping restored
ETMY watchdogs were tripped yesterday morning also. This is a problem that existed some months ago.(?)
Our seimo channels are inactive.
Attachment 1: etmy2d.jpg
  1102   Thu Oct 30 20:39:47 2008 carynConfigurationPEMtemperature sensor
We attached the temperature sensor box to the MC1/MC3 chamber with a C-clamp. We connected the temp sensor to a 2nd box with a short BNC. Bob set up a power cable coming from the X-end towards the MC1/MC3 chamber(Thanks, Bob!) We soldered the end of Bob's power cable to a plug and attached it to the 2nd box (The power supply enters through the 2nd box). A ~20ft BNC cable connects the output signal of the 2nd box to the tall thing by the PSL where all the signals go labeled 1Y2. Once we had everything connected, we put in the fuses for the power supply. So, now the temperature sensor is receiving power. We checked that the power supply was working (we measured +15.08V and -14.95V, and we wanted 15V and -15V so it's OK for now). Tomorrow we will modify C1IOOF.INI file and reboot the frame builder.

About sensor-
There is an LM34 (looks like a transistor) glued w/ epoxy and thermal paste to the inside of a Pomona box ~1"x"1.5"x2". The lid to the box is covered with a 1-2mm thick piece of copper and a little thermal paste is sandwiched between the Pomona lid and the copper piece. A C-clamp attaches the copper piece to the chamber. A BNC is connected to one side of the box (the side with less copper)

About power supply box-
There is a power regulator and an op-amp inside a Pomona box ~2.5"x4"x2". The power regulator is attached to the center of lid of the pomona box with a screw and washer. There's a power plug on the front of the box
Left:+15V:red wire
Center:GND:white wire
Right:-15V:black wire
There are 2 BNC connections on the sides of the box. The left BNC connection is for the output signal and the right BNC connection is for the temperature sensor (if the power plug is coming out of the box towards you).

Sensor location-
Chamber which contains MC1/MC3. On the door facing towards the Y-end. On the bottom-left side. Behind the door. Attached with a C-clamp.

Power supply box location-
Chamber which contains MC1/MC3. On some metal leg thing near the floor facing towards the Y-end. Attached with a zip-tie

Power supply-
Coming from the X-end from a tall thing with all the fuses labeled 1X1
Fuse 160:+15V:red wire
Fuse 171:GND:white wire
Fuse 172:-15V:black wire

Going towards the PSL to the tall thing labeled 1Y1 on the rack labeled SN208
J12 (which we believe corresponds to 50-51 and channel number 13650)
Temperature sensor is connected to J12 with a ~20ft BNC attached to a BNC2LEMO connector we found lying around
  1101   Thu Oct 30 11:07:25 2008 YoichiUpdateComputersWireless bridges arrived
Five wireless bridges for the GPIB-Ethernet converters arrived.
One of them had a broken AC adapter. We have to send it back.
I configured the rest of the bridges for the 40MARS wireless network.
One of them was installed to the SR785.
I put the remaining ones in the top drawer of the cabinet, on which the label printers are sitting.
You can use those to connect any network device with a LAN port to the 40MARS network.
  1100   Wed Oct 29 12:54:28 2008 JenneUpdatePEMCalibrated Guralp Noise compared to average ground motion
Here is a calibrated noise plot of the Guralp seismometer box. This is the same noise measured on Friday, measured at TP3 (just after the first gain stage), with the inputs shorted.

The Guralp calibration is:
                TP3 noise
noise in m/s = -------------------
                 10 * 802(V/(m/s))
The 10 is from the gain of 10 between the output of the seismometer and the input of the breakout box, and the 802 V/(m/s) is from the calibration data that came with the seismometer.

From elog 881 by Rana, in the ~1-50Hz band, the calibration of the Ranger seismometer is 488*10^6 counts/(m/s). Using DataViewer, I estimated that the nighttime ground motion measured by the Ranger is ~3500 counts, and the max daytime ground motion is ~8000 counts. This is what was used for the nighttime/daytime lines in this plot.

It seems like the noise of the Guralp box is fine just as it is, and we don't need to worry about replacing the first gain stage (differential instrumentation amp) with a lower-noise op-amp, since at even the lowest freqs, we have almost a factor of 100 at night, and better than that at higher freqs.

NOTE about the plot: the legend isn't showing the correct colors for the night and day motion - obviously the nighttime motion is the lower RED line, and the day is the higher GREEN line.

Yet another note: When I was measuring the counts on the Ranger, I forgot to subtract the mean, so these numbers are overestimating the ambient ground motion. The blue curve is correct however.
Attachment 1: GuralpVert1Noise_mPERs_Ranger.png
  1099   Wed Oct 29 12:23:04 2008 YoichiConfigurationPSLMZ alignment touched and the alarm level changed
Since the MZ reflection is alarming all the time, I tried to improve the MZ alignment by touching the folding mirror.
I locked the X-arm and monitored the transmitted light power while tweaking the mirror alignment to ensure that the output beam pointing is not changed.
I changed the alignment only a little, almost like just touching the knob.
The reflected power monitor was around 0.6 this morning and now it is about 0.525. Still large.
I changed the alarm level (HIGH) from 0.5 to 0.55.
  1098   Tue Oct 28 12:01:01 2008 josephbConfigurationComputerslinux2

I have removed linux2 and its cables from the control room and put it into 1Y3 along with op340m.

When Joe next comes in we can ask him to Cat6 it to the rest of the world, although it already
seems to me that the CDS hub/switch next Alberto's desk is too full and that we need to purchase
a 48 port device for there.

Note I still need to remove a fair bit of cabling no longer in use from the Martian network switch next to Alberto's desk. There's actually about 8-10 cables there which show no connectivity and are not being used. So there's really about 33% of the ports open in the control room hub, it just doesn't look like it.

As for linux2, I'll probably just connect it to the 1Y2 or 1Y6 Hubs when I get the chance.
  1097   Tue Oct 28 11:10:18 2008 AlbertoUpdateLSCHigher Order Mode resonances in the X arms

Recently we had been having some trouble locking the full IFO in the spring configuration (SRC on +166).
It was thought that an accidental higher order mode resonance in the arms may have been causing problems.

I previously calculated the locations of the resonances using rough arm cavity parameters(Elog #690). Thanks to Koji
and Alberto I have been able to update this work with measured arm length and g factors for the y arm (Elog #801,#802).
I have also included the splitting of the modes caused by the astigmatic ETM. Code is attached.

I don't see any evidence of +166MHz resonances in the y arm.

In the attached plot different colours denote different frequencies +33, -33, +166, -166 & CR.
The numbers above each line are the mn of TEMmn.
Solid black line is the carrier resonance.

I plugged the measures of the length of the X arm and radius of curvature of ETMX I made in to John's code to estimate the position of the resonances of the HOM for the sidebands in the X arm. Here's the resulting plot.
Attachment 1: HOM_resonances_Xarm.png
  1095   Mon Oct 27 14:48:27 2008 YoichiConfigurationPSLEO shutter installed to the reference cavity
I'm now preparing for cavity ring down measurements of the reference cavity.
An EOM for polarization rotation is installed between the two steering mirrors for the reference cavity.
The location is before the polarized beam splitter (used to pick-up the reflected light from the cavity) and
after the half-wave plate. So we should be able to use the PBS as a polarizer.
While setting up the high voltage pulse generator, I realized that we don't have enough cables for it.
It uses special kind of connectors (Kings 1065-N) for HV connections. We need three of those but I could find
only two. I asked Bob to order a new connector.

For the moment, the EOM is left in the beam path of the reference cavity until the connectors arrive (Wed. or Thu. this week)
and the measurements are done.
The EOM distorts the beam and degrades the mode matching to the reference cavity.
I optimized the alignment of the crystal so that the RC transmission is maximum.
Even though, the transmission of the reference cavity is down from 2.8 (without EOM) to 1.7 (with EOM).
I increased the common gain of the FSS from 7dB to 10dB to compensate for this.
The mode clearner locks with this configuration.

If the EOM is really disturbing, one can just take it out.
Since I did not touch the steering mirrors, the alignment to the reference cavity should be recovered immediately.
  1094   Mon Oct 27 11:23:10 2008 steveUpdatePhotosnew Olympus camera with IR vision
The IR blocker was removed from our new Olympus camera
SP 570UZ camera.
It has image stabilization, zoom 26-520 mm (20x optical)
and 10.7 Mpixel
Attachment 1: IRisin.JPG
  1093   Mon Oct 27 11:16:23 2008 AlbertoConfigurationIOOStochMon Calibration
I implemented the calibration for the four channels of the StochMon in the ioo EPICS database. Now the output of those channels, as shown in the medm screen, gives the peak-to-peak amplitude in voltage of each frequency from the RFAMPD at the transmission of the MC, normalized by the DC output from the same photodiode.

Basically the calibration takes into account the following factors:
- two in series RF preamplifiers, currently laying on the PSL table near the RFAMPD, with gains of 19 dB and 17 dB, respectively
and, inside the StochMon blue box:
- a resonant band-pass filter with the following gains h_f(f) for each of the frequencies of interest: 33MHz -39.5 dB; 133MHz -40.8 dB; 166MHz -49.0 dB; 199MHz -45.0 dB
- a power detector that provides an output voltage linearly proportional to the input power in dBm, with a factor alpha of proportionality equal to an average value of -0.0271 V/dBm for all the frequencies

The calibration that relates the output voltage from the PD to the output voltage from the StochMon is then obtained as:

V_pd(f) = sqrt(2*R*P0)/h_f(f) * 10^( (Vo-q)/(20*alpha) )

where R=50ohm, P0=1mW and q=0.772 V, the latest being the offset in the calibration of the power detector (that is its output for a 0 dBm input).
  1092   Mon Oct 27 10:02:16 2008 YoichiUpdateComputer Scripts / ProgramsSVN medm problem
I tried to check out medm directory both from my laptop and nodus.
I did not get the error.
Have you already fixed it ? Or maybe it is to do with the version of the svn used to checkout ?

As we've seen in the past a few times, there's something wrong with the files in the trunk/medm area.
I get the following error message when doing a fresh checkout:
A    c1/lsc/help/C1LSC_LA_SET.txt
svn: In directory 'c1/lsc/help'
svn: Can't copy 'c1/lsc/help/.svn/tmp/text-base/C1LSC_RFadjust.txt.svn-base' to 'c1/lsc/help/.svn/tmp/C1LSC_RFadjust.txt.tmp.tmp': No such file or directory
It looks like that there are some .svn files which have been checked in as if they're some kind of source code instead of just maintenance files.
We probably have to go through and clean this out and then remove these excess files somehow.
  1091   Sun Oct 26 21:02:18 2008 ranaUpdateComputer Scripts / ProgramsSVN medm problem
As we've seen in the past a few times, there's something wrong with the files in the trunk/medm area.
I get the following error message when doing a fresh checkout:
A    c1/lsc/help/C1LSC_LA_SET.txt
svn: In directory 'c1/lsc/help'
svn: Can't copy 'c1/lsc/help/.svn/tmp/text-base/C1LSC_RFadjust.txt.svn-base' to 'c1/lsc/help/.svn/tmp/C1LSC_RFadjust.txt.tmp.tmp': No such file or directory
It looks like that there are some .svn files which have been checked in as if they're some kind of source code instead of just maintenance files.
We probably have to go through and clean this out and then remove these excess files somehow.
  1090   Fri Oct 24 22:30:38 2008 Jenne,ranaUpdatePEMNoise from Guralp Seismometer
Attached is a Power Spectrum of the noise on the Vert1 channel of the Guralp seismometer. The noise is in the several hundreds of nV/rtHz up near 50Hz and higher, but is in the several microV/rtHz range at lower frequencies. Our high frequency noise is almost definitely below the noise of the ADC, but the lower frequencies, where we actually care, it's not as clear.

To Do list:
  • Measure the noise of the ADC - is the Guralp Box lower for all frequencies?
  • Use conversion factors to convert this measured noise into the minimum ground motion that we can measure. Is this at least a factor of 100 lower than our regular ground motion?

** UPDATE: This is actually the noise of the Guralp breakout box, not the Guralp itself. It is the noise measured on the output of the box
with the input shorted. The board is configured to have a gain of 20 (10 from the AD620 and 2x for differential drive). We also measured
directly at the AD620 output and all of this noise comes directly from that chip. If Jenne calculates that this noise is too high we would
have to find a replacement with a better low frequency floor (e.g. LT1012 or LT1007 depending on the Guralps source impedance).
Attachment 1: Vert1_Noise_24Oct2008.png
  1089   Fri Oct 24 21:49:15 2008 JenneConfigurationPEMShort Seismometer Cable
Bad news regarding the cable that goes between the Guralp seismometer and the box that I've been working on: it's too short by about a factor of 2. Dang it. I've placed the seismometer underneath the Beam Splitter Chamber (where it needs to go), and started running the cable toward the ADC rack where box was planned to go, and as Rana guessed earlier tonight, the cable isn't nearly long enough. We have some options: the seismometer can go back into the half-height rack near the BS, SRM, PRM oplev's optical table where I think it used to be, or it can go into the rack with the Kepco high voltage power supplies and the laser's supply. The cable won't reach any farther than that.

I think that we can just add BNC extensions onto the octopus cable that Bob made for the Guralp box, so all we need to figure out after we decide on a rack is the power for the box.
  1088   Fri Oct 24 20:54:41 2008 ranaConfigurationComputerslinux2
I have removed linux2 and its cables from the control room and put it into 1Y3 along with op340m.

When Joe next comes in we can ask him to Cat6 it to the rest of the world, although it already
seems to me that the CDS hub/switch next Alberto's desk is too full and that we need to purchase
a 48 port device for there.
  1087   Fri Oct 24 18:05:01 2008 AlbertoUpdateGeneralAbs length: transverse mode spacing measured for the X arm
The ETMX suffers of astigmatism. I measured the following frequencies for the higher order modes:
- f_01 = 6317500 +/- 500 Hz
- f_10 = 6305500 +/- 500 Hz



where A= (fsr-f_i), fsr=(3897654+/-15)Hz (see elog entry 956), L=(38.4580+/-0.0003)m, g1=0.9947 (from R1=7280m), I get the following values for the g-factor coefficients:

g2_x = 0.3164 +/- 0.0002
g2_y = 0.3209 +/- 0.0002

from which we have the radius of curvature of ETMX:

R_x = 56.26 +/- 0.01 m
R_y = 56.63 +/- 0.01 m

The specs for the mirror have R2= 57.57 m (unc).

So, they seem conditions similar of those of ETMY that Koji measured:

Rx = 56.1620 +/- 0.0013 [m]
Ry = 57.3395 +/- 0.0011 [m]

for which L_yarm: 38.6462 m +/- 0.0003 m
Attachment 1: 24OCT08_TEM10-01_comparison(file12-14).png
  1086   Fri Oct 24 17:21:13 2008 AlbertoUpdateGeneralAbs length: the right amount of beam clipping
I found the reason why the peak at about 6.3MHz appeared only on the TEM10 mode: the blade was clipping the beam too much and it was probably totally killing the mode. I'm attaching a plot that shows that difference when I did that.
Attachment 1: 24OCT08_levels_of_clipping_comparison.png
  1085   Fri Oct 24 15:05:13 2008 steveUpdateVACrga is out of order
The old Dycor RGA is out of order.
I'm getting ready to purchase an SRS instrument.
  1084   Fri Oct 24 11:42:48 2008 AlbertoUpdateGeneralAbs length: locking the X arm cavity in TEM01/10
I went back to lock the arm cavity in either TEM01 or TEM10 mode. Attached are the results. We still have several resonances which we can't clearly identify. I expect TEM01/10 to be at 6.276MHz but we don't have a peak exactly there. What we have is:
- a peak at 6.320MHz in the measurement of the TEM01 mode (the one with the lobes of the spot almost on the vertical axis)
- a peak at 6.590MHz in both the TEM01 and TEM10 measurements.

I'm either missing the real TEM01/10 mode or the peaks at 6.590MHz are those. If that were true, that would mean that the radius of curvature of ETMX is 49.29 m instead of 57.57 m as listed in the IFO data sheets. I think it's much more likely that the measurements are missing the right peaks.
Attachment 1: TRX_armTEM00-plot_09-10_together.png
  1083   Fri Oct 24 11:21:26 2008 peteConfigurationPSLFSS LO input calibrated in dBm
Based on the measurements described in my previous elog, I created a new calc record in the file /cvs/cds/caltech/target/c1psl/psl.db
grecord(calc, "C1:PSL-FSS_LOCALC")
        field(SCAN,".1 second")

After restarting scipe3 to load this change, I told C1PSL_FSS.adl to look at this record instead of *LODET. That MEDM screen now shows LO input calibrated in dBm.

For reference, the operators available for use in the CALC field are listed in the EPICS Record ref manual, Chapter 9. The manual can be found here:

Yoichi said he was fixing an SVN problem, so I have not yet committed the two files I changed: /cvs/cds/caltech/target/c1psl/psl.db and /cvs/cds/caltech/medm/c1/psl/C1PSL_FSS.adl.
  1082   Fri Oct 24 11:09:08 2008 steveUpdateSAFETYmore lexan plates under cameras
The MC2, MC3&1 and BSC-SUS cameras were repositioned somewhat in the
process of placing lexan disks under neat them.
MC1&3 will have to be readjusted.

Now all horizontal viewports are protected.
  1081   Fri Oct 24 10:06:16 2008 YoichiConfigurationIOOMC gain and FSS gain changed
Following the measurements of MC and FSS loop gains, I modified mcup script to set the MC VCO gain to 2dB (it was -4dB before).
I also changed the normal value of the FSS common gain to 7dB. The open loop transfer functions posted in the previous two entries
were measured with those settings.
  1080   Thu Oct 23 23:09:18 2008 YoichiUpdatePSLMC UGF is now 75kHz
I measured three loop transfer functions of the MC servo.
The blue curve in the first attachment is the overall open loop gain of the servo measured using
the sum-amp A of the MC board (it is the sum-amp in the common part).
The red curve is the transfer function measured by the sum-amp B of the MC board, which is in the VCO path.
Mathematically the measured transfer function is G_vco/(1+G_L), where G_L is the loop gain of the length path
and G_vco is the loop gain of the VCO path.
The green curve is G_L/(1+G_vco) which was measured from dtt by using C1:SUS-MC2_MCL_EXC.
The UGF of the MC loop is 75kHz with the phase margin of 27deg.
The cross over frequency of the two loops is 43Hz. The phase margin there seems OK.

The second attachment is the comparison of the MC open loop TF measured on Sep. 4 (old) and today (new).
The increased bandwidth of the FSS gave us a slight gain in the phase margin and the elimination of
the slight bump in the gain around 150kHz existed in the blue curve.
Attachment 1: MC_Loop.png
Attachment 2: OldAndNew.png
  1079   Thu Oct 23 21:52:27 2008 YoichiUpdatePSLFSS UGF now 450kHz
I measured the open loop transfer function of the FSS, for the first time after I mitigated the oscillation.
The attached plot shows the comparison of the OPLTF before and after the oscillation was mitigated.
Blue curves are when AD797 was oscillating, and the red ones are after AD797s were replaced by AD829s.
The FSS gain slider values are the same for the both measurements.
There is a notable difference in the shape of the TF.
Right now the UGF is around 450kHz with the phase margin of 50deg.
When the gain is increased by a few dBs in the common gain slider, the PC path becomes saturated.
This might be caused by the peak in the OPLTF at 1.7MHz sticking out of the 0dB line.
Another peak at 770kHz is also annoying.
Too bad that I did not take the TF above 1MHz before the oscillation was mitigated.
Also at 100kHz, the new TF has a lower gain than the old one, although it looks like the slope of the red curve is getting steeper and
it is catching up the blue one at lower frequencies.
I will measure the TF below 100kHz later.

With this bandwidth, I was able to increase the MC gain further.
I will report on the MC open loop measurements soon.
Attachment 1: FSS_OPLTF.png
  1078   Thu Oct 23 20:47:28 2008 peteConfigurationPSLFSS LO calibration for MEDM
Today I took a quick series of measurements to calibrate the FSS LO power measurement in the MEDM. This was done by using the spec.an. to measure the 21.5 MHz peak in dBm at the LO input to the FSS box on the PSL table, and recording the MEDM value, for attenuations applied at the FSS REF box output ranging from -5 dBm to -30 dBm.

I measured the loss due to the BNC cable I used, which was (19.66-19.50) dBm. I accounted for this and plotted ln(MEDM) vs. dBm on the attached plot. A linear fit of this gives the CALC field of a calc record for the IOC db:

Since no one knew how to do this nonlinear conversion in EPICS I will describe how to do it in detail tomorrow. It is simple, although it requires power cycling the scipe3 bunch (typing "reboot" or "ctl-x" at the command prompt took it down, but it did not come back). I did power cycle those computers a few times today.
Attachment 1: fss_lo_calibration.png
  1076   Thu Oct 23 18:51:19 2008 AlbertoMetaphysicsComputerseLog
I checked it and the latest version of the elog software, the 2.7.5 (we have the 2.6.5) has, among new nice features, the very good ability to fit the entries into the screen width without showing kilometric lines like we see now. Should we upgrade it?
  1075   Thu Oct 23 18:45:18 2008 AlbertoOmnistructureComputer Scripts / ProgramsPython code for GPIB devices developed for the Absl length experiment
I wrote two Python scripts for my measurement that can be also used/imitated by others: sweepfrequency. py and HP8590.py. The first is is the one that we run by a Python interpreter (just typing "python <name script> <parameters>"from the terminal). It manages the parameters that we have to pass it for the measurement and calls the second one, HP8590.py which actually does most of the job.

Here what it does. It scans the frequency of the Marconi and, for each step, searches the highest peak in the Spectrum Analyzer (which is centered 50 KHz around the frequency of the Marconi). It then associates the amplitude of the peak to the frequency of the Marconi and write the two number in two columns of a file.
The file name, the GPIB-to/LAN interface IP address, the frequency range, the frequency step amplitude and the number of measures we want it to average for each step, are all set by the parameters when we call sweepfrequency.py.
More details are in the help of the function or just looking at the header of the code.

I guess that one can perform other similar measurement just with little changes in the code so I think it could turn out useful to anyone else.
Attachment 1: HP8590.py
# This function provides the measuremeent of the peak amplitude on the spectrum analyzer
# HP8590 analyzer while sweeping the excitation frequency on the function generator.
# Alberto Stochino 2008

import re
import sys
import math
from optparse import OptionParser
from socket import *
... 55 more lines ...
Attachment 2: sweepfrequency.py
## sweepfrequency.py [-f filename] [-i ip_address] [-a startFreq] [-z endFreq] [-s stepFreq] [-m numAvg]
## This script sweeps the frequency of a Marconi local oscillator, within the range
## delimited by startFreq and endFreq, with a step set by stepFreq. An arbitary
## signal is monitored on a HP8590 spectrum analyzer and the scripts records the
## amplitude of the spectrum at the frequency injected by the Marconi at the moment.

## The GPIB address of the Marconi is assumed to be 17, that of the HP Spectrum Analyzer to be 18

## Alberto Stochino, October 2008
... 51 more lines ...
ELOG V3.1.3-