ELOG 40m

Problems in locking the X arm

This morning for some reason that I didn't clearly understand I could not lock the Xarm. The Y arm was not a problem and the Restore and Align script worked fine.

Looking at the LSC medm screen something strange was happening on the ETMX output. Even if the Input switch for c1:LSC-ETMX_INMON was open, there still was some random output going into c1:LSC-ETMX_INMON, and it was not a residual of the restor script running. Probably something bad happened this monring when we rebooted all the FE computers for the RFM network crash that we had last night.

Restarting the LSC computer didn't solve the problem so I decided to reboot the scipe25 computer, corresponding to c1dcuepics, that controls the LSC channels.

Somehow rebooting that machine erased all the parameters on almost all medm screens. In particular the mode cleaner mirrors got a kick and took a while to stop. I then burtrestored all the medm screen parameters to yesterday Thursday October 9 at 16:00. After that everything came back to normal. I had to re-lock the PMC and the MC.

Burtrestoring c1dcuepics.snap required to edit the .snap file because of a bug in burtrestore for that computer wich adds an extra return before the final quote symbol in the file. That bug should be fixed sometime.

The rebooting apparently fixed the problem with ETMX on the LSC screen. The strange output is not present anymore and I was able to easily lock the X arm. I then run the Align and the Restore full IFO scripts.

1039

Fri Oct 10 10:20:42 2008

Quote:

The front-end machines are all down. Another cosmic-ray in the RFM, I suppose. Whoever comes in first in the morning should do the all-boot described in the wiki.

Yoichi and I went along the arms turning off and on all the FE machines. Then, from the control room we rebooted them all following the procedures in the wiki. Everything is now up again.

I restored the full IFO, re-locked the mode cleaner.

1038

Fri Oct 10 00:34:52 2008

The front-end machines are all down. Another cosmic-ray in the RFM, I suppose. Whoever comes in first in the morning should do the all-boot described in the wiki.

1037

Wed Oct 8 23:18:23 2008

Correlation between the Sorensen switching noise and the FSS error signal

I took some spectra and coherence function of the FSS error signal and the +24V Sorensen power line.
The first plot shows spectra of the two signals. Looks like Sorensen is not responsible for most of the lines
in the FSS error signal.
The coherence function between the two signals supports it (second plot).
Slight coherence can be seen at 23kHz and 98.4kHz but not significant.

I will check the coherence of the power line with the ISS signal next.

Attachment 1: PowerLineSpe.png

Attachment 2: Coherence.png

1036

Wed Oct 8 22:23:43 2008

Electronics work bench cleanup

Electronics

Yesterday, I cleaned up the electronics work bench. I figured that keeping the work bench
in order has larger effect on the work efficiency than buying expensive soldering stations.
Whoever works there should clean up the table after the work to the state shown on
the right side of the picture (at least).
If you leave the bench for a while (more than 30min) but intend to return later and
resume the work, please write your name and time on a piece of paper and put it on the bench.
Otherwise, your stuff can be taken away anytime.

Attachment 1: Cleanup.jpg

1035

Wed Oct 8 21:26:20 2008

Attempt to replace the DC-DC converter (aborted)

Rich, Steve, Yoichi

We opened the MOPA box and inspected our NPRO.
We concluded that this NPRO is different from the ones at the sites.
At the sites, the NPROs have a connector on the board which accepts the output of the DC-DC converter.
Rich's replacement DC-DC converter has a matching connector to it. So replacement of the DC-DC converter is easy.
In our NPRO, there is no such a connector found. The cables coming from the external power supply are directly soldered
on to the PCB (see attm1).

We have to take out the PCB in order to work on it.
As shown in the second picture, there is a D-SUB connector sticking out of the box through the rear panel.
In addition, the PCB is connected to the metal box containing the crystal with an IDE style connector.
This means the PCB is tightly constrained.
To take out the PCB without applying too much stress on it, we have to take off the rear panel.
To do so, we have to remove the screws on the bottom of the NPRO box. That means we have to move the NPRO.
We did not want to do so, because it will screw up the alignment to the amplifier.

The model number of the DC-DC converter looks like NMH0512-something.
According to the datasheet of NMH0512S, the switching frequency is typically 95kHz. We saw 77kHz harmonics in the FSS error signal.
I'm not sure if this is the culprit. I will try to measure the EMI from this guy later.

Attachment 1: DCDC.JPG

Attachment 2: NPRO.JPG

1034

Wed Oct 8 19:17:55 2008

Laser power is slowly recovering

This afternoon we (rich, steve, yoichi) shutdown the laser for the DC-DC converter installation.
(we decided not to do so. Detail will be posted soon.)
After we turned on the laser again,the laser power has been recovering but very slowly.
At the time of writing, the laser power is 2.6W (MOPA_AMPMON).
I think it is because the chiller temparature has not yet settled down (it went up to 25C and slowly coming down, now at 22C).
It will take some hours until the power fully comes back.
Right now I confirmed that at least the MC locks.

1033

Wed Oct 8 12:35:56 2008

josephb

New Network diagram for the 40m

Attached is a pdf of the new network diagram for the 40m after having removed all of the old hubs.

Attachment 1: 40m_network_10-07-08.pdf

1032

Tue Oct 7 21:19:40 2008

IOO

MC_F calibrated spectrum

I updated the plots because I did not take into account the double path AOM effect, which doubles the frequency actuation efficiency. (2008/10/8)

I determined the MC_F counts to the PSL frequency change calibration.
The attachment 1 is the calibrated MC_F spectrum, which is, above the cross over frequency, equivalent to the frequency noise seen by the MC.

The calibration method is the following:

1) I picked spare AD and DA channels (C1:IOO-MC_TMP1 and C1:OMC-SPARE_DAC_CH_16_EXC). C1:OMC-SPARE_DAC_CH_16_EXC is labeled C1:OMC-OSC_FM on the cable.

2) C1:IOO-MC_TMP1 was calibrated by injecting a sine wave of known amplitude and measuring the amplitude in counts in dataviewer.
It was 63uV/cnt.

3) C1:IOO-MC_TMP1 was connected to the feedback BNC connector of the MC board, that is the direct monitor of the feedback voltage to the VCO.

4) C1:OMC-SPARE_DAC_CH_16_EXC was connected to the channel B excitation input of the MC board, which adds the signal to the fast feedback path.

5) Using DTT a swept sine signal was injected to the MC board through C1:OMC-SPARE_DAC_CH_16_EXC, and the transfer function from C1:IOO-MC_TMP1 to the
C1:IOO-MC_F was measured.

6) Using the calibration of C1:IOO-MC_TMP1, the transfer function from the MC_F count to the actual voltage applied to the VCO input was obtained.
(attm2)

7) Using the DC calibration of the VCO input voltage to the VCO frequency change (1.75MHz/V elog:993) and the fact that there is a 1.6Hz pole and a 40.8Hz zero between the VCO input connector and the actual input of the VCO chip, the final calibration transfer function from the MC_F count to the frequency change of the PSL (that is twice the frequency change of the VCO within the bandwidth of the FSS) can be obtained (attm3).

8) The analytic form of the calibration TF is, poles at [1.6Hz, 11.42Hz, 11.42Hz] and zeros at [40.8Hz, 113Hz, 113Hz] with the DC gain of 110Hz/cnt.

Attachment 1: MC_F-spectrum.png

Attachment 2: VCO_VoverMC_F.png

Attachment 3: PSL_FoverMC_F.png

1031

Tue Oct 7 12:17:57 2008

Yoichi, Alberto

I noticed the MEDM screen time was about 7 minutes ahead of the right time. The time on MEDM is read on channel C0:TIM-PACIFIC_STRING which takes it from the C1VCU-EPICS computer. Yoichi found that that computer did not have the right time because one of the startup scripts, ntpd, which are contained in the directory /etc/init.d/ for some reason did not start. So restring it by typing ./ntpd start updated the time on that computer and fixed the problem.

1030

Tue Oct 7 10:49:29 2008

This morning I found that the photodidode of the PLL in the PSL table was not aligned to the beam anymore. The PD support was not tight to the pedestal so that the PD was rotated and completely off of the beam.

It is possible that the BNC cable connected to the PD was pulled very strongly, or the PD was hit so that the support got unscrewed by its pedestal. Anyways, it did not happen spontaneously.

I re-aligned the PD and observed again the beat between the two laser beams. Here are the values from the measurement of the signal from the PD:
I measured the DC values of the hitting power, alternatively occluding one of the two laser beams, and I measured the beat amplitude letting them interfere and reading the peak-to-peak amplitude of the oscillating signal:

main beam DC: 200mV
secondary beam DC: 490
beat: 990mV
beat at the spectrum analyzer (after the two-way splitter of the PLL): -8.40dBm on a noise floor of the photodiode of -75dBm

the frequency of the beast is 8.55MHz and the temperature of the NPRO of the secondary beam, as read from the laser driver display, is 48.7357C.

Alberto

1029

Mon Oct 6 16:41:33 2008

Quote:

Alberto, Joe,

The C1LSC medm screen is frozen and the C1LSC computer is down. We tried to reboot and to restart it first turning off the power and then just rebooting remotely. None of them worked. We check whether any of the cable was unplugged but they were ok. Also all the led turned on to green after rebooting.
Trying to reboot we get the following error message: init_module: device or resource busy.

We called Alex who first suggested to check all the connection and then to swap the timing cable between two Pentek boards but the computer was still down.
It is possible that the board is dead. Alex and Rolf are going to look into this problem and for any spare board.

by now we can't lock any DOF of the IFO.

Alex, Rob, Alberto,

Alex replaced the Pentek board used by C1LSC with a spare one that they had at the Wilson house. That fixed the DMA failure but since the board had a channel broken, one of the channels (POY) was still not available.

Looking at the wiring diagram of the ASC crate, we found that one of the Pentek boards in it was actually not used by anything and thus available to replace the bad one in LSC. We switched the two boards so that now the one that Alex installed is mounted in the ASC crate and it is connected to the cable labeled 1x2-ASC 6.

C1LSC is up again and all the channels in the C1LSC screen, including POY, now seem to be working properly.

1028

Mon Oct 6 12:45:41 2008

Mon Oct 6 10:00:49 2008

Monday morning conditions:

The laser head temp is up to 20.5 C
The laser shut down on Friday without any good reason.
I was expecting the temp to come down slowly. It did not.
The control room temp is 73-74 F, Matt Evans air deflector in perfect position.
The laser chiller temp is 22.2 C

ISS is saturating. Alarm is on. Turning gain down from 7 to 2 pleases alarm handler.

c1LSC computer is down

Attachment 1: htup.jpg

1026

Sat Oct 4 07:23:42 2008

Hi, this is Koji from Japan.

I am afraid that this is a poisonous spider, Latrodectus hasseltii.
In Japanese word "Seaka-goke-gumo" (red-backed widow spider)

I am not an expert of insects, but this type of spider is getting famous in Japan as they were accidentally imported from South-West asia and Austraria to Japan in recent years, and they settled in certain city areas.

It is said that its neurotoxic venom causes unpleasant results such as shock, pain, and inflammation, even it is not too strong to kill human.

Be careful.

Quote:

Found this lady outside the door of the 40m lab a few nights ago.

1025

Fri Oct 3 19:38:02 2008

Found this lady outside the door of the 40m lab a few nights ago.

Attachment 1: DSC_0409.JPG

1024

Fri Oct 3 15:57:05 2008

Last night was basically a repeat of the night before--marginally better locking with the DRMI resonating the +f2
sideband. Several stable locks were achieved, and several control handoffs to DDM signals worked, but never from
lock to lock--that is, a given DD handoff strategy would only work once. This really needs to work smoothly before
more progress can be made.

Also, a 24Hz mode got rung up in one/several of the suspensions--this can also impede the stability of locks.

1023

Fri Oct 3 15:09:58 2008

Last night during locking, for no apparent reason (no common mode), the PSL FAST/SLOW loop starting going just a little
nutz. Attached is a two day plot. The noisy period started around 11-ish last night.

Attachment 1: FASTSLOW.png

1022

Fri Oct 3 12:15:21 2008

This morning, in order to update the threshold values of the alarm handler for the StochMon, I rebooted the C1iool0 computer following the procedure in the wiki, that is telnetting on it and typing CTRL+X. Apparently everything went well in the process.

1021

Thu Oct 2 18:56:19 2008

Resistivity of Suspension Wire

Summary

SUS

Bob and Steve measured the resistance of the suspension wire today:

OD     = 0.0036" =  0.091 mm
Length = 46"     = 1168.4 mm
Resistance     =   33.3 Ohms

resistivity = R * pi * (OD/2)^2
              ----------------- = 1.85e-7 Ohm-meters
                  Length

This was a batch of California Fine Wire from 2001 (same as used at LHO and LLO).

By comparison the standard tabulated resistivity for steels is (http://hypertextbook.com/facts/2006/UmranUgur.shtml):

                  resistivity (Ohm-meter x 10^-7)
-------------     ----------------
304 Stainless       7.2
316 Stainless       7.4
Cast Steel          1.6

This is all to see whether or not the 60 Hz fields produce forces on the suspension wires via coupling with the Earth's DC field.

TBD

1020

Thu Oct 2 16:44:28 2008

The idea is to push the UGF to 10 Hz of the TM oplev servos with quiet HeNe laser.
We measured good intensity noise of JDS 1103P in May 2007 and converted most of the TM oplevs to it.
The ITMs still have the noisy 670nm , 1 mW, diode lasers to begin with.
In order to get 1 mW power returning to the qpds I measured the power going to TMs
and returning on qpds ...so we can select the appropriate laser power for the conversion.

40m optical lever lasers:

HeNe laser JDS 1103P, 633nm, linear polarization 500:1,

ETMX: qpd 0.12 mw (4%) reflected of 3 mW,
ETMY: qpd 0.1o (3.8%) " 2.6
BS: qpd 0.02 ( 2.5%) " 0.8
PRM: qpd 0.01 (1.3%) " 0.75
SRM: qpd 0.08 (10%) " 0.8

Coherent 670 nm Diode Lasers VLM-tm, 0.95 mW, linear polarization 100:1,

ITMX: qpd 0.1 mW (11%) reflected back from TM of 0.9 mW
ITMY: qpd 0.04 (7%) " " 0.6

It seems that JDS HeNe laser 633 nm, linear polarization 500:1, 10 mW will do the job

1019

Thu Oct 2 02:45:50 2008

Locking the DRMI with the +f2 sideband was marginally better tonight. I was able to get it lock stably enough to take transfer
functions and handoff MICH & PRC to double demod signals. After re-alignment, however, behaviour was similar to last night
(locks quickly but only for a few seconds), so that lends some credence to HOM-as-bad-guy theories.

1018

Wed Oct 1 23:21:03 2008

Reference cavity reflection camera

I re-centered the reference cavity reflection camera, which has been mis-aligned for a while.
I also tweaked an input steering mirror to make the alignment better. This resulted in the increase of the transmission PD voltage
from 8V to 9V.

1017

Wed Oct 1 23:05:14 2008

Stefan, Yoichi

We took relative intensity noise (RIN) spectra of the ISS error point and the monitor PD (attm1).
In-loop RIN is the sensor PD and "Out of the loop RIN" is the monitor PD.
The ISS gain slider was at 8dB in this measurement.
It looks normal.
An open loop transfer function of the ISS loop was measured (attm2). The UGF was 22kHz with the phase margin of ~22deg.
We should increase the UGF up to ~60kHz

When we increase the gain up to 14dB, the CS saturation warning comes up in the EPICS screen.
We confirmed this by monitoring the CS drive signal with an oscilloscope.
It is the output of an AD602J, which has +/-3V output range.
By increasing the gain of AD602J, we saw that the output signal hits the rail.
There seems to be a lot of high frequency (100kHz - a few MHz) noise, out of the control band.
We also observed that AD602J itself oscillates at about 10MHz (don't remember the exact number) when the gain is increased.
(We saw this even when the loop is off. There is no such an oscillation in the input to the AD602J).
When we took wide band spectra of the CS drive signal, we saw many large harmonics of ~180kHz. We believe these peaks are limiting
our ISS gain now (causing the CS saturation). The harmonics persisted even when we disconnected the PDs. So it is not coming from the light.
We saw the same harmonics in the power lines. They may be the switching noise of the Sorensens.
We took spectra of those harmonics, but the netgpibdata.py somehow did not save the data from AG4395A correctly. I have to debug this.

Stefan removed DC offsets from the AD829s (many of them are used in the ISS board) by turning the pots for offset adjustment.
This eliminated the problem of getting a large DC CS feedback (observable in C1:PSL-ISS_CSDRIVE_MEAN) when the gain is increased.

During the investigation, I noticed that increasing the PMC gain too much (~22dB) caused an oscillation of the PMC loop and consequently made
the ISS saturate. When the ISS is behaving bad, we should check the PMC gain.

Currently, the ISS is running OK with the gain = 8dB. I modified the mcup script to set the ISS gain to 8dB when the MC is locked.

TO DO:
Wait for Peter's answer about spare ISS boards.
Power line filtering.
Find the cause of AD602J oscillation (Well this is the one mounted upright. So just mounting it normally might solve the problem :-).

Attachment 1: RIN.png

Attachment 2: OPLTF.png

1016

Wed Oct 1 12:09:25 2008

Alberto

"StochMon" added to the Alarm Handler

Quote:

John, Alberto,

we added the four channels of the RF Amplitude Monitor (aka StochMon) to the Alarm HAndler. So far I used just test values for the thresholds of green, yellow and red states and need to update to some reasonable ones. To do that I need to calibrate those EPICS channels. I have the old data saved and I'm now trying to figure out how to properly change the database file.

John, Yoichi, Alberto

We restarted the C1iool0 computer both directly by the main key and remotely via telnet. We had to do it a couple of times and in one occasion the computer didn't restart properly and had connection problem with the newtowrk. We had to call Alex that did just the same thing, but used the CTRL+X command to reboot. It worked and the Alarm Handler now includes the StochMon.

1015

Wed Oct 1 12:05:58 2008

Alberto

"StochMon" added to the Alarm Handler

John, Alberto,

we added the four channels of the RF Amplitude Monitor (aka StochMon) to the Alarm HAndler. First we modified the 40m.alh file just copying some lines and switching the name of the channels to the ones we wanted. Than we also added a few lines to the database file ioo.db in order to define the alrm levels. So far I used just test values for the thresholds of green, yellow and red states and need to update to some reasonable ones. To do that I need to calibrate those EPICS channels. I have the old data saved and I'm now trying to figure out how to properly change the database file.

1014

Wed Oct 1 02:54:03 2008

Tried the spring-y side tonight with a discouraging lack of progress. There were several locks of DRMI+2ARMs with
the +f2 (springy) sideband resonating in the DRM, but they weren't very stable. Moving to just the DRMI and resonating
the +f2, in order to tune up the acquisition and the handoff to the double demod signals, revealed the problem that the
DRM just won't stay locked on the +f2 sideband. It locks quickly, but only for a few seconds. This is different from the
behaviour with the -f2 sideband, which locks quickly and stably. In theory, the two sidebands should behave similarly.
It could be problems with HOMs in the recycling cavities, and so we may try changing the modulation frequency slightly.

1013

Wed Oct 1 02:47:53 2008

PSL ERR & LODET: Too much offset

Looks like there is an anomolous mixer offset correlated with the increase in the LO level. This may be leading to crazy offset locking in the FSS and too much coupling from ISS to FSS.

Attachment 1: Untitled.png

1012

Wed Oct 1 02:10:03 2008

Here's a 2 day trend of the MZ. You can see that there is something bad with ERR - it should really be going to zero.

Also LODET is dead. We need to rejuvinate LODET somehow.

The next plot is a 90 day hour-trend of the same signals. You can see that LODET came back to us between
September 10 and 19 ??? I looked at a 4 year trend and it seems that this signal has always been zero
(nice use of disk space) except for a few days in Nov of 06 and then whatever happend on Sep 10.

Attachment 1: Untitled.png

Attachment 2: Untitled.png

1011

Wed Oct 1 00:24:54 2008

I had mistakenly left the MC boost off during my FAST investigations. The script is now restored.

The ISS is still saturating with gains higher than -5 dB. We need to request a PeterK / Stefan consult in the morning.

Also found the MZ gain down at -10 dB around midnight - need an alarm on that value.

1010

Tue Sep 30 19:50:27 2008

Quicky Summary - more details later

Quicky summary for now, more details later tonight / tomorrow morning:

PMC notch: It's tuned up, but it is out, and it is staying out. It looks like the 18.3kHz junk isn't being helped by the brick, in fact the brick makes it worse. And the notch isn't enough to make the peak go away. Rana's and my conclusions about the PMC: the 18.3kHz resonance is associated with the way the PMC touches its mount. Depending on where we push (very gently, not much pressure) on the PMC, we can make the peak come and go. Also, if the PMC happens to be set nicely on its ball bearings, the peak doesn't appear. More notes on this later.

PMC's RF modulation depth: Since with the PMC's brick off, and the PMC sitting nicely on its ball bearings, we don't see any crazy oscillations, we were able to take the gain slider on the PMC screen all the way up to 30dB. To give us more range, we changed the modulation depth of the RF to 2V, from its previous value of 1V.

Phase of PMC servo: Since the phase of the PMC servo hasn't been set in a while, I eyeballed it, and set the phase to: Phase Flip = 180, Phase Slider = 4.8000 . I measured many points, and will plot a calibration curve later.

I also measured the actual value of the RF out of the PMC's LO board, when changing the RF output adjust slider. Again, will post the calibration later.

The attached PNG shows the PMC spectra from now and from Aug. 30 (ref). As you can see there's been some good reduction in the acoustic noise (red v. orange). The large change in the error signal is because of the much higher gain in the servo now. We'll have to redo this plot once Jenne measures the new UGF.

Attachment 1: mcf.png

1009

Tue Sep 30 13:43:43 2008

Steady progress again in locking again last night. Initial acquisition of DRMI+2ARMs was working well.
Short DOF handoff, CARM->MCL, AO on PO_DC, and power ramping all worked repeatedly, in the cm_step script.
This takes us to the point where the common mode servo is handed off to an RF signal and the CARM offset
is reduced to zero. This last step didn't work, but it should just require some tweaking of the gains
during the handoff.

1008

Mon Sep 29 17:53:33 2008

ISS has been saturating easily.
Today I opened the PSL enclosure to inspect the ISS box. Then I found that the sensor PD was disconnected from the box.
I don't know for how long it has been like this, but it is clearly bad.
I connected the PD and I was able to increase the ISS gain to 0dB (from -5dB).
When I turned off the FSS, I was able to increase the gain further up to 8dB. So the FSS must have been doing something bad to the laser intensity.
The FSS fast path did not get huge kicks when ISS was turned on as observed before. But still the FSS fast signal is wondering around about +/-0.3V.
It does not stop wondering even when the ISS is turned off (even if the CS drive cable is physically disconnected).
I will try to optimize the slow servo.

After Peter tried to optimize the demodulation phase of the FSS (see his entry), I was able to increase the ISS gain to 8dB even with the FSS running.
I haven't fully understood what is behind this behavior.

To investigate what is going on in the ISS, I opened the box and inspected the circuit.
I found many innovative implementations of electric circuit components. See the attached photo. It is a three dimensional mounting of
a surface mount AD602 !
Anyway, the board is somewhat different from the schematic found in the DCC. But I roughly followed the circuit.
I will measure open loop TFs and various signals to see how we can improve the ISS.

Attachment 1: IMG_1671.JPG

1007

Mon Sep 29 15:09:36 2008

steve

almost 4 yrs plot of power & temps

The water chiller is normally running 1.5 C warmer than the laser head temp.
When control room temp is stable and PEM-count_temp is stable we can expect the head temp to be stable 20.0 C

PSL-126MOPA_HTEMP is running warmer in the last ~40 days

The ifo arm thermostate temp settings were raised by 2 F on 8-11-08

Attachment 1: 3.5y.jpg

1006

Mon Sep 29 13:33:39 2008

josephb

Gigabit network finished and conlog available on Nodus

The last 100 Mb unmounted hub has been removed (or at least of the ones I could find). We should be on a fully gigabit network with Cat6 cables and lots and lots of labels.

In other news, the pearl script that runs the web interface on linux1 for the conlog has been copied to /cvs/cds/caltech/apache/cgi-bin/ and is now being pointed to by the apache server on Nodus.

https://nodus.ligo.caltech.edu:30889/cgi-bin/conlog_web.pl

1005

Mon Sep 29 13:23:40 2008

rob

Summary

Laser chiller running a little hot

Quote:

I looked at it some last night and my suspicion was the ISS. Whenever the ISS switch came on the FAST got a kick.

We should try to disable the MC locking and ISS and see if the FSS/PMC/MZ are stable this way. If so this may be
a problem with the ISS / Current Shunt.

My entry about the laser chiller got deleted. The PSL appears to be running with the ISS gain at -5dB, so that's good, but the
chiller is still showing 21+ degrees. It should be at twenty, so there's something causing it to run out of
headroom. We'll know more once Yoichi has inspected the ISS.

In the deleted entry I noted that the VCO (AOM driver), which is quite warm, has been moved much closer to the MOPA.
This may be putting some additional load on the chiller (doubtful given the amount of airflow with the HEPAs on,
but it's something to consider).

1004

Mon Sep 29 11:17:14 2008

steve

horizontal viewports are protected with lexan

SAFETY

The four horizontal viewports of arms are protected
by 3/8" thick, 8.5" OD Lexan disk of MR10 Polycarbonate.

ITMX, ETMX, ITMY and ETMY ccd cameras are not focused now.

1003

Mon Sep 29 01:19:40 2008

Summary

Laser chiller running a little hot

1002

Fri Sep 26 19:18:39 2008

IOO

MC2 is having a bad day

As Steve mentioned earlier in today's elog, MC2 keeps ringing up for no clear reason. It is definitely only MC2 that is ringing up, since it's sensors will read several hundreds of counts, while all the other optics are at regular 2 counts and below on the Watchdog screen.

Preliminary investigation results: Around the time of these "kick up" events, the Ranger seismometer does not see any motion, nor does the set of accelerometers under the MC1 chamber. The set of accelerometers under the MC2 chamber do see activity that is at the same time as these events. These events are not caused just by someone walking around, since Rana went inside and clunked around near MC2 while I watched the sensor levels. MC2's watchdog did not trip.

For further investigation: Why is it that only the MC2 accelerometers are seeing the motion? Similarly, why is MC2 the only optic being kicked? Has anyone done anything lately to the MC2 stack?

1001

Fri Sep 26 19:08:43 2008

Refcav Trans: PD + Camera + Dumps

I went out to improve the Refcav trans path.

I removed all ND filters to get rid of the fringing.

I removed the anodized Al dump that was there. Black anodized Aluminum dumps are forbidden for use as
dumps in any low phase noise setup (such as our frequency stabilization cavity). The scatter was going
directly back into the cavity and making noise. For now its undumped, but Steve will find the
reflections and dump them on unblemished razor blade dumps mounted stiffly.

I will post a photo of the new setup later - the new setup is sketched on the control room markerboard.

The transPD level is now 8 V, up from its previous 3-4 V. We will probably have to also put a lens
in front of it to get the beam size down.

1000

Fri Sep 26 18:35:17 2008

PMC filter is out for tuning

The PMC's new Pomona Box filter is out for tuning. I'd like to get the notch right on the 18.3kHz, rather than being off in 21.7kHz land.

999

Fri Sep 26 16:13:57 2008

IOO

MC_L / MC_F crossover

We were trying to understand why the FAST_F signal had such large excursions (~1V ~ 5 MHz).

Some of this is due to the seismic noise and the resulting MC_F signals. Increasing the MCL
gain reduces it somewhat. But as you can see from the attached loop gain measurement, the
crossover is a healthy 90 Hz with the MCL digital gain = 1. But what's going on in the MC loop
in the 10-20 Hz band? That looks like bad news.

Then I noticed that changing the ISS gain slider puts a large step (~1V) into the FAST. My guess
is that the board has large DC offsets and also much of the switching supply noise. Not sure why
this would be worse than before though.

To prevent large noise in the FAST, I've changed the mcup script to set this gain to -5 dB. Our
intensity noise is now presumably 10-15 dB worse than the nominal good levels we had a year ago.
Needs investigation.

Attachment 1: mcx.png

998

Fri Sep 26 16:08:39 2008

There's been good progress in locking the last couple of nights. A lot of time was wasted before I found that
all the SUS{POS,PIT,YAW} damping gains on the SRM were set to 0.1 for some reason, which let it get rung up
just a bit during bang locking. After setting these gains to 0.5 (similar to PRM and BS), the initial lock
acquisition of DRMI+2ARMs (nospring) got much quicker. Then more time was wasted by sticky sliders on the
transmon QPD whitening gain, causing the Schmitt triggered HI/LO gain PD switch not to happen. This meant
that the arm power was not reported properly when the CARM offset was reduced, and so loop gain normalizations
were not working properly. After all this, by the end of the night last night, reduced the CARM offset such
that stored power in the arms was about half of the max. Should be able to get to full power with another
good night, and then back to springy locking.

997

Fri Sep 26 14:10:21 2008

Lab laptops maintenance

The linux laptops were unable to write to the NFS mounted directories.
That was because the UID of the controls account on those compters was different from linux1 and other control room computers.
I changed the UID of the controls account on the laptops. Of course it required not only editing /etc/password but also dealing with
numerous errors caused by the sudden change of the UID. I had to chown all the files/directories in the /home/controls.
I also had to remove /tmp/gconf-controls because it was assigned the old UID.

Whenever we add a new machine, we have to make sure the controls account has the same UID/GID as other machines, that is 1001/1001.

I did some cleanups of the laptop environment.
I made dataviewer work on the laptops *locally*. We no longer have to ssh -X to other computers to run dataviewer.
The trick was to install grace using Fedora package by

sudo yum install grace

Then i modified /usr/local/stow_pkgs/dataviewer/dataviewer to change the option to dc3 from "-s fb" to "-s fb40m".

996

Fri Sep 26 09:05:47 2008

The MC2 sus damping was restored.

995

Fri Sep 26 00:19:54 2008

Filter-action with the PMC

Written, but not posted on 24Sept2008:

PMC adventures for this evening

Today's mission was to make more progress on increasing the bandwidth of the PMC servo.

First order of business was to improve the performance of the 14.6kHz notch that Rana put in the PMC servo board a few weeks ago to remove the 14.6kHz body mode resonance of the PMC. Looking at the zoomed in TF that I posted Monday (elog #978), we see that there is still a remnant of a peak near 14.5kHz. A first gut-reaction is that the notch is not tuned properly, that we have just missed the peak. As previously noted in the elog, the peak that we are trying to notch out is at 14.68kHz (elog #874). By unlocking the PMC and measuring the transfer function between FP2 and OutMon (OutMon is the monitor for the high voltage going to the PMC's PZT), I measure the transfer function of the notch, and find that it is notching at 14.63kHz. So we're a teensy bit off, but the Q of the notch is such that we're still getting improvement at the peak frequency. After checking that we are hitting the correct frequency, I put a short (just some wire) around R21, which is the R in the RLC notch filter, to increase the depth of the notch. At the peak frequency of 14.68kHz, we see a 2.5dB improvement of the notch. At the actual notch frequency of 14.63kHz, we see a 3.2dB increase in the depth of the notch. So, shorting R21 helped a little, but not a lot. Also, it's clear that we don't get that much more improvement by being on the resonant frequency, so there's no need to go in and tune the notch on the board.

Second order of business was to investigate the 18.34kHz peak in the transfer function. (Rana spent some time Monday night measuring this peak, and determined that it was at 18.34kHz) We decided that the best plan was to re-implement the Pomona Box notch filter that had previously existed to remove a higher frequency body mode, but tuned for the 18.34kHz mode. I am still not entirely sure what this mode is, but clearly it's a problem by about 20dB (on the TF, the next highest peak is 20dB below the 18.34kHz peak). Unfortunately, while the components should, by Matlab calculations, give me an 18.3kHz notch, I ended up with something like a 21.7kHz notch. This notch is approximately -30dB at 21.7kHz, and -20dB at 18.3kHz. I still need to take transfer functions and power spectra of the PMC servo with this new filter in place to (a) confirm that it did some good, and (b) to determine how important it is that the notch be right-on. More likely than not, I'll take the filter out and fiddle with the capacitors until I get the correct notch frequency.

Third on the list was to lock everything back up (FSS, PMC) after my tinkering, and see what kind of gain we get. Rob and I fiddled with the PMC gain, and it looks like the servo oscillates just before we get up to the max slider gain of 30dB. Looking at the power spectra in DTT, we do not see any significant peaks that suggest oscillation, so it is likely that there is some investigation to be done at frequencies above the 7kHz that we were able to look at with DTT (which isn't surprising, since all of this work has been at 14kHz and higher).

A final note is that we see a feature around 9kHz in the transfer function, and it is not at all clear where it comes from. At this time, it does not seem to be the dominant feature preventing us from increasing the gain, but at some point if we want the bandwidth of the PMC servo to be 10kHz, we'll have to figure this one out.

Still on the PMC todo list:

Measure the new transfer function, see if 18.34kHz peak is reduced
Tune Pomona Box notch filter to 18.3kHz instead of the current 21.7kHz
Retake power spectra of different items on top of PMC, compare to see if there is any one configuration that it obviously better than the others.
Find out why the PMC still oscillates when we try to take it up to the max slider gain, and fix it.

PS, is anyone else having trouble getting to the elog from laptops on other parts of the Caltech network (but not LIGO network)? My laptop won't go to the elog, but I can get to the rest of the internet using the Caltech wireless. My computer stopped seeing the elog on Tuesday or so. Joe, do you have any inspiration? Thanks.

994

Thu Sep 25 17:14:31 2008

Attachment 1: vegemite.png

993

Thu Sep 25 15:24:05 2008

I calibrated the VCO driving the AOM for the AO path of the MC feedback.

I injected DC voltage to the VCO and measured the output frequency with the SR620.

The attached plot shows the relation between the input voltage to the VCO and the output frequency.
The coefficient is 1.75MHz/V. Since the AOM is double path, the actual actuation efficiency is 3.5MHz/V.
We can use this value for the calibration of the MC_F. However, the MC_F DAQ channel is sampling the VCO input voltage through a 10Hz high-pass filter.
This filter has to be taken into account to convert the MC_F counts to frequency.
I will measure the transfer function from the VCO input to the MC_F counts tomorrow.

Attachment 1: VCO_Cal.png

992

Thu Sep 25 14:03:08 2008

josephb