40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 84 of 339  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  1058   Mon Oct 20 12:18:38 2008 AlanUpdateComputer Scripts / Programsburtwb missing on Solaris but installed on linux64

Quote:
c1lsc stalled this evening, so I powercycled it.
After that, I tried to lock arms to confirm the computer is working.
Then I realized that the restore alignment buttons do not work from any control room computer.
I found that it was because burtwb command was missing. For Solaris, looks like there used to be /cvs/cds/epics/extensions/burtwb but now
there is no /cvs/cds/epics directory. I thought there were directories other than "caltech" in /cvs/cds/, weren't there ?
Right now, there is only /cvs/cds/caltech.
Anyway, I installed burt for 64bit linux computer (under /cvs/cds/caltech/apps/linux64/epics/extensions/).
At this moment the alignment save/restore works on allegra (and probably on rosalba), but not on op440m yet.



The automatic backup of /cvs/cds (and /frames/minute-trends ) to the LIGO archive in Powell-Booth,
which runs from fb40m using the scripts in /cvs/cds/caltech/scripts/backup ,
stopped when fb40m was rebooted on June 28, 2008,
and the check_backup script I run to send an email when this happens also failed due to a scripting error.

But we still have a backup of /cvs/cds from June 27.

The backup of /cvs/cds (excluding /cvs/cds/caltech and /cvs/cds/tmp)
circa June 27, 2008
has been restored to
/cvs/cds/recover_20081020 .

Please check to see that it has what we need.

Before moving it over to where it belongs,
it would be really nice to figure out what happened...

Meanwhile, I have fixed the check_backup script and restarted the backup, which will run this evening...
but maybe I should wait till the dust settles?

Now is also a good time to think about whether there is anything else besides for
/cvs/cds and /frames/minute-trends that should be backed up regularly.


- Alan
  1062   Tue Oct 21 16:14:42 2008 steveUpdateGeneraldivergence of He Ne 1035P
The ITM oplevs laser diodes are noisy.
They will be replaced by JDS 1035P
SN T8093307 was measured with the beamscanner.
This will able us to calculate the right lenses to get a small beam on the qpd.

**
The first column is distance from the front face of the laser in cm.
The second column is beam diameter in the horizontal direction in microns.
The third column is the beam diameter in the vertical direction in microns.
(edit by Rana)
Attachment 1: 1035p_divergence.png
1035p_divergence.png
  1063   Tue Oct 21 16:17:45 2008 YoichiUpdatePSLAD797 Oscillation in the FSS board
I checked each op-amp's output in the FSS board to see if any indication of slew-rate saturation can be found.
PA85, which was the most suspicious one, actually has a very large slew rate limit (1000V/usec).
Its output swing was about 5V/usec. So PA85 was ok in terms of slew rate.
However, I found that an AD797 used at the first stage of the PC path was oscillating by itself, i.e. even without the loop closed.
The frequency was about 50MHz and the amplitude was large enough to reach the slew rate limit of this chip (the steepest slope was 30V/usec whereas the slew
rate limit of AD797 is 20V/usec).

I replaced it and another AD797 right after the oscillating one with AD829s. Just replacing the chips caused oscillation of AD829.
It was because there were no phase compensation capacitors connected to the pin 5 of AD829s.
Since the PCB was designed for AD797, there is no pattern for compensation caps. So I ended up putting Mica capacitors (47pF) across the pin 5 and the nearest ground point.
It worked and the oscillation stopped.

As I reported in an earlier elog, stopping the oscillation did not solve the problem of low FSS bandwidth.
  1067   Wed Oct 22 12:37:47 2008 josephbUpdateComputersNetwork spreadsheet
Attached in open office format as well as excel format is spreadsheet containing all the devices with IP addresses at the 40m. Please contact me with any corrections.
Attachment 1: 40m_network_10-15-08.ods
Attachment 2: 40m_network_10-15-08.xls
  1069   Wed Oct 22 17:48:58 2008 YoichiUpdateGeneralLenses for focusing the optical lever laser (Re:divergence of He Ne 1035P)
Steve had difficulty in finding lenses for focusing the HeNe laser for the ITM op-lev.
Following his measurement of the beam divergence, I did some calculation to find a suitable set of lenses and positions.

First, I fitted Steve's data to get the waist size and location of the new HeNe.
The first plot shows the fitting result.
The size of the waist is 0.3mm at -367mm from the laser output (i.e. inside the laser).
(I only used horizontal beam size data.)

Then using the obtained beam parameter, I calculated the propagation of the beam through two lenses.
After playing with the focal length and location of the lenses, I found that with parameters {f1=-0.125m, f2=0.2m, d1=0.2m, d2=0.1m} we get about 1mm beam at the QPD (about 4m away from the laser). f1 and f2 are the focal lengths of the lenses, d1 is the distance from the laser to the first lens and d2 is the distance between the two lenses.
The second plot shows the beam size as a function of the distance from the laser.

The Mathematica notebook used to plot the beam propagation is attached.
By running it on Mathematica 6, you can dynamically change the parameters (focal lengths and locations) by sliders, and the plot (like the one shown in the second attachment) updates in real time. It is cool. Please try it.



Quote:
The ITM oplevs laser diodes are noisy.
They will be replaced by JDS 1035P
SN T8093307 was measured with the beamscanner.
This will able us to calculate the right lenses to get a small beam on the qpd.

**
The first column is distance from the front face of the laser in cm.
The second column is beam diameter in the horizontal direction in microns.
The third column is the beam diameter in the vertical direction in microns.
(edit by Rana)
Attachment 1: BeamProfile.png
BeamProfile.png
Attachment 2: BeamPropagation.png
BeamPropagation.png
Attachment 3: BeamPropagation.zip
  1072   Thu Oct 23 15:27:19 2008 AlbertoUpdateGeneralAbs length
Here are the measurements I've got yesterday. The plot shows the transmitted power after the X arm while sweeping the frequency of the beat between the two lasers. That frequency is changed by scanning the frequency of the local oscillator of the PLL (that is the Marconi).
The X arm cavity has been locked to the TEM00 of the main beam. I tilted ITMX in order to enhance the higher modes of the secondary beam with the purpose of making them beat with the main beam.
Three traces are shown in the plot correspondent to three different measurements in which I clipped the transmitted beam at the X end with a razor blade from up and from the side of the photodiode.
Both the beats of the TEM00 mode of the main laser with the TEM01 and TEM10 modes of the secondary laser are expected to be at 6.2763 MHz. The plot has a candidate peak at 6.325MHz but it does not appear on both the measurements with the blade. the peaks at 3.897MHz and 7.795MHz are the first and the second longitudinal modes of the X arm cavity.
Attachment 1: TRX_aplot_03_04_05_together.png
TRX_aplot_03_04_05_together.png
  1073   Thu Oct 23 18:23:47 2008 AlbertoUpdateGeneralAbs length

Quote:
Here are the measurements I've got yesterday. The plot shows the transmitted power after the X arm while sweeping the frequency of the beat between the two lasers. That frequency is changed by scanning the frequency of the local oscillator of the PLL (that is the Marconi).
The X arm cavity has been locked to the TEM00 of the main beam. I tilted ITMX in order to enhance the higher modes of the secondary beam with the purpose of making them beat with the main beam.
Three traces are shown in the plot correspondent to three different measurements in which I clipped the transmitted beam at the X end with a razor blade from up and from the side of the photodiode.
Both the beats of the TEM00 mode of the main laser with the TEM01 and TEM10 modes of the secondary laser are expected to be at 6.2763 MHz. The plot has a candidate peak at 6.325MHz but it does not appear on both the measurements with the blade. the peaks at 3.897MHz and 7.795MHz are the first and the second longitudinal modes of the X arm cavity.


Today I repeated the measurement and I'm attaching the resulting plot. Still, not clear and (and most of all) not nice.
It seems like tilting ITMX is introducing a lot of unwanted higher modes that don't let us to clearly identify TEM01 and TEM10.
I think I'm going to stop it to get back to technique in which the arm cavity is locked to the TEM01/10 of the main beam.
Attachment 1: TRX_plot_06_07_08_together.png
TRX_plot_06_07_08_together.png
  1074   Thu Oct 23 18:27:04 2008 AlbertoUpdateGeneralAbs length

Quote:
Here are the measurements I've got yesterday. The plot shows the transmitted power after the X arm while sweeping the frequency of the beat between the two lasers. That frequency is changed by scanning the frequency of the local oscillator of the PLL (that is the Marconi).
The X arm cavity has been locked to the TEM00 of the main beam. I tilted ITMX in order to enhance the higher modes of the secondary beam with the purpose of making them beat with the main beam.
Three traces are shown in the plot correspondent to three different measurements in which I clipped the transmitted beam at the X end with a razor blade from up and from the side of the photodiode.
Both the beats of the TEM00 mode of the main laser with the TEM01 and TEM10 modes of the secondary laser are expected to be at 6.2763 MHz. The plot has a candidate peak at 6.325MHz but it does not appear on both the measurements with the blade. the peaks at 3.897MHz and 7.795MHz are the first and the second longitudinal modes of the X arm cavity.


Here is the Matlab code I use to calculate the HOM frequencies.
Attachment 1: HOM_Frequencies.m
% FP Cavity HOM Frequencies Estimate
% Alberto Stochino, October 2008

R1 = 7280;      % Mirror1 radius of curvature
R2 = 57.57;     % Mirror2 radius of curvature
L = 38.458;     % Length of the FP Cavity
n = 1;          % X Order of the Mode
m = 0;          % Y Order of the Mode

c = 299792458;  % Speed of Light
... 11 more lines ...
  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
FSS_OPLTF.png
  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
MC_Loop.png
Attachment 2: OldAndNew.png
OldAndNew.png
  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.
  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
TRX_armTEM00-plot_09-10_together.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.
  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
24OCT08_levels_of_clipping_comparison.png
  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

From

g2=1/g1*(cos(A*L*pi/c))^2

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
24OCT08_TEM10-01_comparison(file12-14).png
  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
Vert1_Noise_24Oct2008.png
  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.
  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 ?


Quote:
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.
  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
IRisin.JPG
  1097   Tue Oct 28 11:10:18 2008 AlbertoUpdateLSCHigher Order Mode resonances in the X arms

Quote:
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
HOM_resonances_Xarm.png
  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
GuralpVert1Noise_mPERs_Ranger.png
  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.
  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
etmy2d.jpg
  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
f.png
Attachment 2: f1.png
f1.png
  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.
  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
  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
2008-11-02_summarizingplot.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
DAQ.pdf
  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
f2.png
Attachment 2: f.png
f.png
  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

MOTIVATION OF THE EXPERIMENT
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.

THE EXPERIMENTAL TECHNIQUE IN BRIEF
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:

TMS=FSR*acos[sqrt(g1*g2)]/pi

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.

EXPERIMENTAL RESULTS
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


CONCLUSIONS
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
2008-11-04_file_02-05.png
Attachment 2: HOM_resonances_Xarm.png
HOM_resonances_Xarm.png
Attachment 3: HOM_resonances_Yarm.png
HOM_resonances_Yarm.png
  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
htpr.jpg
  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
arms.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
  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
acf.jpg
Attachment 2: acc_mc1.jpg
acc_mc1.jpg
Attachment 3: test.jpg
test.jpg
  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
mc-acc.pdf
Attachment 2: mc-acc-quad.pdf
mc-acc-quad.pdf
  1126   Mon Nov 10 11:32:49 2008 robUpdateComputersc1iscex rebooted

it was running a few cycles late
  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.
  1129   Mon Nov 10 19:39:40 2008 steveUpdatePEMthump noise from particle counter
The particle counter is back on the IOOC location on a piece of FOAM
It needs this isolation, so when the pump is running, it's not shaking things.
The counter was counting for 6 sec and it was on holding for 20 mins.
Now I set the counter for 20 sec so it is easy to recognise it's signal and it holds for 2min only.
This will set the alarm handler in action.

Atm1: 40 mins plot
PEM-ACC_MC2_x,y,z up to 13 mins: pcounter at MC2 table, clamped, counting for 20s and holds for 2 mins
PEM-ACC_MC2_x,y,z from 13 to 26 mins: pcounter at MC2 table, not clamped, seated on 2" foam, counting 20s and holds for 2 mins
PEM-ACC_MC1_x,y,z from 26 to 40 mins: pcounter at MC1_IOOC location, not clamped, seated on 2" foam, counting 20s and holds for 2 mins

Rana won the bet



Quote:
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: partcfm.jpg
partcfm.jpg
  1131   Wed Nov 12 11:36:13 2008 JenneUpdatePEMGuralp Breakout Box is ~50% hooked up
The Guralp box is about halfway hooked up now. The seismometer is under the BSC, and the long cable from the seismometer to the breakout box is connected to "Guralps 1 Input" on the front panel. This corresponds to the set of 3 channels that Caryn stuffed with the new fancy-pants resistors few weeks ago. (When we finally get the other Guralp back from the company, we'll have to stuff the next set of 3 channels).

The Breakout Box is on the very top of 1Y1, sitting on top of the black power supplies. This should be fine, but it's pretty toasty hot up there, so if we find that there are problems with running the box at higher-than-room-temperature, step 1 will be to find a new spot for the box. (I'm not at this time anticipating a problem, but you never know....) Steve put a little foot between the Guralp box and the power supply to get some air circulation.

The ADC Octopus cable that Bob made is connected, and going up through the top of the rack. I am now going on a BNC cable hunt to extend this cable over to the PEM ADC. The PEM ADC is in 1Y7, so I'll need some medium-long BNC cable to get there.

The power cable is also ready to be connected to the rack's +/- 15VDC. I'll talk to Bob about getting this done.

Next step: pick some channels on the PEM ADC, and create them in the .ini files
  1134   Fri Nov 14 11:33:19 2008 steveUpdateVACSRS-RGA installed
Old Dycor rga is removed and new SRS-RGA200 installed.
It is pumped down and ready for hooking up its RS-232 output for operation.
  1136   Fri Nov 14 19:20:42 2008 YoichiUpdatePSLReference cavity ring down
Thanks to Bob making the high-voltage BNC cables for the HV pulse generator, I was able to operate the EOM in front of
the reference cavity.

The conceptual setup is the following:
[HV pulse] ----+           +-->-- [PD2]
               V           |
->--[HWP]->-- [EOM] -->-- [PBS] --<->-- [QWP] --<->-- [Reference Cavity] -->-- [PD1]
                           |
                [PD3] --<--+

The high voltage pulse rotates the polarization of the light after the EOM. When the HV is applied, the PBS reflects most of the light
into PD2 (Thorlabs PDA255), shutting down the incident light into the cavity.
The transmitted light power of the reference cavity is monitored by PD1 (PDA255). The reflected light from the reference cavity
is monitored by the DC output of the RF PD (PD3). PD3 is low-passed so the response is not fast.
Thorlabs says PDA255 has 50MHz bandwidth.

The attached plot shows the time series of the above PD signals when the HV was applied.
Input Pulse (blue curve) is the input to the HV pulse generator. When it is high, the HV is applied.
"PBS reflection" (red) is PD2. "Reflection" (green) is PD3. "Transmission" (light blue) is PD1.

The red curve shows huge ringing. At first I thought this was caused by the bad response of the PD.
However, the same ringing can be seen in the PD3 and the peaks match very well.
When red curve goes down the green curve goes up, which is consistent with the energy conservation.
So it looks like the light power is actually exhibiting this ringing.
May be the HV pulse is distorted and the voltage across the EOM is showing this ringing.
I will check the input voltage shape to the EOM using a high impedance probe, if possible.

The green curve shows a slow decay because it has a long time constant. It is not an actual
trend of the reflected light power.

The RC transmission power shows some peaks, probably due to the ringing in the input power.
So just fitting with an exponential would not give a good estimate of the cavity pole.
Even though, we should be able to de-convolute the frequency response of the reference cavity
from the input (red curve) and output (light blue curve) signals.
Attachment 1: RingDown.png
RingDown.png
  1137   Fri Nov 14 20:35:47 2008 ranaUpdatePSLReference cavity ring down
To make the DEI pulser make a fast pulse on the EO shutter EOMs, we had to make sure:

1) the cable had a high voltage rated dielectric. cheap dielectrics show the 'corona'
effect, especially when there is a bend in the cable.

2) the EO has to have a resistor on it to prevent ringing due to the impedance mismatch.

3) We needed ~3.5 kV to get the EO shutter crystal to flip the light by 90 deg.
  1138   Fri Nov 14 22:40:51 2008 YoichiUpdatePSLReference cavity ring down

Quote:

To make the DEI pulser make a fast pulse on the EO shutter EOMs, we had to make sure:

1) the cable had a high voltage rated dielectric. cheap dielectrics show the 'corona'
effect, especially when there is a bend in the cable.


I'll check it with Bob.


Quote:

2) the EO has to have a resistor on it to prevent ringing due to the impedance mismatch.


Did you use a shunt or series resistor ?
If shunt, I guess it has to have a huge heat sink.
Actually, DEI says the pulser does not require any external shunt/series resistors or impedance-matching network.
Looks like it is not true ...


Quote:

3) We needed ~3.5 kV to get the EO shutter crystal to flip the light by 90 deg.


Yes, I adjusted the voltage to maximize the power change and it was about 3.5kV.
  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.
Attachment 1: Fit.png
Fit.png
  1141   Mon Nov 17 16:59:22 2008 JenneUpdatePEMSeismometer hooked up, reading channels on DataViewer
Alberto, Jenne

The Guralp Seismometer is (finally) hooked up to the PEM ADCU. Alberto helped me make channels in the c1pem1 .ini file, which correspond to:

Guralp1 VERT = channel 9 on PEM ADCU = C1:PEM-SEIS_MC1_VERT
Guralp1 NS = channel 10 on PEM ADCU = C1:PEM-SEIS_MC1_NS
Guralp1 EW = channel 11 on PEM ADCU = C1:PEM-SEIS_MC1_EW

We also renamed the Ranger seismometer's channel to C1:PEM-SEIS_MC2_Y from C1:PEM-SEIS_MC1_Y, since tomorrow I'll move the Ranger Seismometer to be underneath MC2's chamber (it's currently sitting somewhere in the middle of the Mode Cleaner).


I can see the VERT and NS channels with dataviewer, but EW looks dead. I need to figure out if this is a bad cable thing, or if the ADC channel is no good, or if something in the box on that channel is no good. All 3 channels were tested and working after all the soldering was completed by Caryn, but something may have come undone while putting the box into its new place in the top of 1Y1. (In dataviewer, it looks like the EW channel is just floating, and not connected to anything.)

Plan of Attack:
* figure out why EW looks dead on Dataviewer
* redo Rana's static Wiener filter analysis, now that we have 2 seismometers (1 Ranger and 1 Guralp)
* work on adaptive Wiener filtering with the Guralp
  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.
  1145   Tue Nov 18 19:44:53 2008 AlbertoUpdateGeneralX Arm Cavity "Negative" FSRs Measured
Previous measurements on the X arm cavity revealed a shift of the frequencies of the cavity resonances from where one would expect these to be by just looking at integer multiples of the cavity FSR. In particular, plotting the resonant frequencies versus the order of their occurrences while sweeping the laser frequency (in our case that of the beat between the two lasers), the linear fit of the data contained an unwanted offset:

resonant_frequency = n x FSR + offset

In part, we attributed this offset to the local oscillator of the PLL, the Marconi, which was not referred to an absolute frequency clock.
For that reason, I connected the Marconi to the RS FS275 which uses the 1PPS from the GPS to generate a 10 MHZ reference signal, and then scanned the cavity again. This time I started from negative beat frequencies, that happen when the frequency of the secondary laser is smaller than the main laser's, to positive frequencies. The way I made sure of the sign of the frequency was looking at the effect of changing the temperature of the NPRO. I decided that negative frequencies where those for which an increase in temperature lowered the beat frequency and positive frequencies those for which increasing the temperature made the beat frequency go up.
I then plotted the data and obtained the attached plot.

The offset was reduced to about 80 Hz (from more than 200 in the previous measurements). I think the residual offset has to do with something that happens in the cavity, something, as Koji found out, related to the alignment of the mirrors.

Thanks to the more data points, the measurement of the FSR improved to (3897627 +/- 5) Hz, which would let us know the measure of the cavity length with an error of 50um, if it weren't for the offset. I have to understand whether and how to take this into account to determine the precision in the cavity length. I guess it depends on whether it is real or it is still a systematic error due to the measurements.
Attachment 1: 2008-11-17_Linear_Fit.pdf
2008-11-17_Linear_Fit.pdf
  1149   Thu Nov 20 09:37:39 2008 steveUpdatePSLMZ vs temp
This 12 days plot shows that it can hold lock if the daily temp variation is not more than 3/4 of a degree C
The MZ is happy if it's HV is above 100V
Attachment 1: mztemp.jpg
mztemp.jpg
  1151   Fri Nov 21 16:11:26 2008 rana, alberto, robUpdatePSLMach Zender alignment
The Mach Zender's dark port DC voltage had gone up too high (~0.5 V)and was turning yellow
on the screen. I re-aligned by touching the knobs on the 166 MHz path. Doing alignment after the
166 EOM had very little effect. The main improvement came from doing yaw on the turning mirror
just ahead of the 166 MHz EOM; this is the one which as no adjustment knobs (duh).

During this procedure, I had the MC off, the ISS off, and the MC autolocker off. After finishing
the alignment, the power on the ISS PDs had railed and the dark port power was ~0.29 V. So we
put in a ND0.2 on the ISS path and now the voltages are OK (~2 V on each PD). We have to remove the
ND filters and change the first ISS turning mirror into a ~10-20% reflector.


So now the MZ alignment seems good; Alberto is on the MC periscope alignment like a cheap suit.
Attachment 1: PB210051-1.JPG
PB210051-1.JPG
  1152   Fri Nov 21 16:52:48 2008 JenneUpdatePEMGuralp seismometer's Channel Problems are solved
PROBLEM noticed earlier this week: It looked like one of the seismometer channels (VERT-1) wasn't working, no matter how I put which channel into which input of the PEM ADCU. Watching the channel on Dataviewer, it looked like the ADC was measuring VERT-1 to be zero (actually measuring zero, not digital noise-type zero). I had checked the ADC by putting in a sine wave with a function generator, and saw on Dataviewer the wave I expected, so I knew that I had the correct channel, and that the channel was good.

SOLUTION: This afternoon I took the box out of the rack and opened it up. As soon as I opened it, I saw that I had left something inside the box which was causing the problem. Back when we were measuring the noise of the box, to ensure that it is lower than the ADC's noise, Rana and I had shorted the test points on the input of the VERT-1 channel with a little piece of wire. It turns out that I had closed up the box without remembering to remove the wire.

CONCLUSION of the story: I took out the piece of wire, and now all three seismometer channels (VERT-1, N/S-1, E/W-1) all work, and all detect me jumping around near the BSC. Since the seismometer breakout box reads a differential measurement, and since the input test points were connected, it was indeed measuring zero. Zero equals zero is all well and good, but it's even better now that it's measuring actual seismic motion.
ELOG V3.1.3-