ELOG 40m

Mach Zender alignment

Quote:

So now the MZ alignment seems good; Alberto is on the MC periscope alignment like a cheap suit.

And alignment is now mostly done - MC locks on the TEM00.

                 REFL_DC

Unlocked           4.50  V
Locked noWFS       1.30  V
Locked + WFS       0.42  V

and the 29.5 MHz modulation depth is really small.

We should be able to rerun the Wiener analysis on this weekends MC data.

I don't know what our nominal StochMon numbers now are, but after Alberto tweaks up the alignment he can tell us if the RFAM has gotten any better.

1154

Fri Nov 21 19:47:26 2008

Guralp noise measurement

and here's the spectra with them connected - from the coherences, it looks like it needs to be rotated by 90 deg.

I'll next rename the channels to fix this so that we get good seismic data over the weekend with the MC.

Attachment 1: a.png

1153

Fri Nov 21 17:27:47 2008

Guralp noise measurement

Here is the data from the Guralp Seismometer for the past day or so, before I fixed the VERT-1 channel. The NS and EW show what's going on in the world, and VERT is measuring essentially the noise of the box, through the ADC, in counts.

Attachment 1: guralp_vert_shorted.jpg

1152

Fri Nov 21 16:52:48 2008

Guralp 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.

1151

Fri Nov 21 16:11:26 2008

rana, alberto, rob

Mach 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

1150

Fri Nov 21 16:03:50 2008

I found some black & red "Ninja" alkaline AA batteries in the battery charger. This is dangerous. Please
do not put alkaline batteries in there, only Nimh. If you need help with the battery charger you can
come and talk to me or Rob and we can help you out getting started.

1149

Thu Nov 20 09:37:39 2008

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

1148

Wed Nov 19 18:12:35 2008

new channel for MC drum modes

IOO

I set up the lockin to take the MC Demod Board's Qmon signal, demodulate it at 27.5 kHz, and
put the output into a DAQ channel (I think its either MC_DRUM1 or MC1_TEMPS). However,
the MC_DRUM channel doesn't look like its getting anything in the DTT although it looked fine
on a scope. I used the 'sensitivity' setting of the lockin to make the demodulated signal
large enough but not so large that it would saturate the ADC (+/- 2V).

1147

Wed Nov 19 18:02:18 2008

All the Marconi Set to the Rubidium Frequency Standard

Not sure what was going on before. I changed the frequency counter to use an AC coupled input, and had it average
for 50 seconds. The output now agrees with the Marconi front panel to less than 1 Hz. Its still not 0.000 Hz,
but not bad.

1146

Wed Nov 19 10:32:11 2008

All the Marconi Set to the Rubidium Frequency Standard

I placed the SRS Rubidium FS275 over the PSL rack, next to the frequency counter. This one and the Marconi on the PSL rack have been connected to the 10MHz output of the frequency standard. I set also the first Marconi, the one that used to drive the others, to external, direct frequency reference. Now it reads 166981718 Hz versus 166981725 Hz measured by the frequency counter: 8 Hz difference.

1145

Tue Nov 18 19:44:53 2008

X Arm Cavity "Negative" FSRs Measured

General

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

1144

Tue Nov 18 19:37:23 2008

MC1 OSEM signals sign flipped and c1susvme1 restart problem

IOO

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.

1143

Tue Nov 18 13:28:08 2008

Caryn

new channel for MC drum modes

IOO

Alberto has added a channel for the Mode Cleaner drum modes.
C1:IOO-MC_DRUM1
sample rate-2048
chnum-13648

1142

Mon Nov 17 20:47:19 2008

Caryn

Summary

General

Drove MC at 28kHz to excite drum modes

Rana, Alberto and I observed drum mode frequencies at 23.221kHz(MC1), 28.039kHz(MC2), 28.222kHz(MC3) while driving the mode cleaner. We observed no peaks when we didn't drive the mode cleaner. We used the SR785 to send a ~80mV noise signal in the 28-28.2kHz band to the mode cleaner mirrors via 1Y4-MC1,2,3-POSIN. Then we looked at 1Y2-Mode Cleaner-Qmon on the SR785 and saw peaks.

1141

Mon Nov 17 16:59:22 2008

Seismometer 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

1140

Mon Nov 17 15:07:06 2008

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

1139

Mon Nov 17 11:01:15 2008

HowTo

Calibrating the Frequency Standard of the Marconi

I locked the SRS Rubidium Frequency Standard FS275 to the the 1pps from the GPS. The specs from the manual provide a frequency accuracy of 5x10^-11, that is 5x10-4 @ 10 MHz, since this is the reference signal frequency we're are going to use.
The Marconi internal frequency standard is provided by a TCXO oscillator. The instrument can be set in either one of these ways: 1) Indirect Synchronization, by which the internal TCXO is phase-locked to the external frequency standard (i.e. the SRS FS275 in our case) 2) Direct Sync, in which the internal TCXO is bypassed and the frequency standard is the external one.

I checked the specs of both frequency standards and found:

SRS FS275: 5x10^-11 -> 5x10^-10 Hz @ 10 MHz

Marconi: here what the data sheet says is that "the temperature coefficient is 7 in 10^7 in the temperature range between 0 and 55 C" and so should be also the frequency accuracy.

The SRS FS275 seems more accurate than the TCXO therefore I'm going to set the Marconi on the direct external mode.

Attachment 1: 2023ASeriesOperatingManual.pdf

Attachment 2: SRS_FS275_Rubidium_Frequency_Standard.pdf

1138

Fri Nov 14 22:40:51 2008

Quote:

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.

1137

Fri Nov 14 20:35:47 2008

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.

1136

Fri Nov 14 19:20:42 2008

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

1135

Fri Nov 14 17:41:50 2008

Omnistructure

Sweet New Soldering Iron

The fancy new Weller Soldering Iron is now hooked up on the electronics bench.

Accessories for it are in the blue twirly cabinet (spare tips of different types, CD, and USB cable to connect it to a computer, should we ever decide to do so.

Rana: the soldering iron has a USB port?

Attachment 1: newSolderingIron.JPG

1134

Fri Nov 14 11:33:19 2008

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.

1133

Thu Nov 13 15:50:44 2008

The schematic of the 1Y7 rack that Alan pointed out (see attachment) don't represent anymore the actual rack.
First, with Yoichi we found that the GPS receiver for the 10 MHz is in a different position,
on the other side of the VME computer. It seems to output 1 kHz, which also appears in some modulated way.
This signal is then passed to a board on 1Y7 that seems make just copies of the signal. One of these goes
to an other board in 1Y6 that looks like a GPS receiver but has actually no GPs antenna input. Here it is
not connected to anything, but on its same crate is a the awg computer, so it might be providing the clock
to that by the crate.

We also checked the clock monitor output on the boards in the PSL that provides for the clock to the Penteks
and it seems that these are actually getting 4MHz.

Attachment 1: rackstuff.pdf

1132

Thu Nov 13 11:33:25 2008

Making (good) Matlab figures

HowTo

Treasure

Just a little summary of some useful ways to change plot settings in Matlab that I wanted to share and remember for the future:

http://saig.phys.ualberta.ca/toolbox/Matlab/making_figures.html

1131

Wed Nov 12 11:36:13 2008

Guralp 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

1130

Wed Nov 12 11:14:59 2008

Caryn

MC temp sensor hooked up incorrectly

MC Temperature sensor was not hooked up correctly. It turns out that for the 4 pin LEMO connections on the DAQ like J13, J14, etc. the channels correspond to horizontal pairs on the 4 pin LEMO. The connector we used for the temp sensor had vertical pairs connected to each BNC which resulted in both the differential pairs on J13 being read by the channel.
To check that a horizontal pair 4 pin LEMO2BNC connector actually worked correctly we unlocked the mode cleaner, and borrowed a connector that was hooked up to the MC servo (J8a). We applied a sine wave to each of the BNCs on the connector, checked the J13 signal and only one of the differential pairs on J13 was being read by the channel. So, horizontal pairs worked.

1129

Mon Nov 10 19:39:40 2008

thump 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

1127

Mon Nov 10 16:44:14 2008

particle 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

it was running a few cycles late

1125

Mon Nov 10 11:06:09 2008

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

MC 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

insect killer sprayed at kitchen area !

Bureaucracy

SAFETY

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

Attachment 1: mc-acc.pdf

Attachment 2: mc-acc-quad.pdf

1121

Fri Nov 7 10:52:57 2008

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

AC 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

Computers

ELOG compile on Solaris

From the ELOG web pages:

Solaris:

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

Locking

arms 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

head temp hick-up vs power

MOPA

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

Absolute Length and g-factor measurements conclusions

LSC

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

Attachment 2: HOM_resonances_Xarm.png

Attachment 3: HOM_resonances_Yarm.png

1114

Tue Nov 4 17:58:42 2008

MC 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

Summary

periodic 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

Wiener Filter performance over 5 hours

ASS

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

Wiener Filter performance over 5 hours

ASS

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

Quote:

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:

nodus:elog-2.7.5>make
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

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:

nodus:elog-2.7.5>make
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

alberto

Transverse mode spacing measurement for the X arm

General

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

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

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

Wiener Filter performance over 5 hours

ASS

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