ELOG 40m

arm cavity oplev calibration

oplevs

I finished a calibration of optical levers.

To calibrate oplevs, I locked appropriate cavity and tilted a mirror.
A cavity with tilted mirror decrease its arm power. So I can know how much the tilt is.
For calibration of ITMX and ETMX, I locked X arm and measured TRX.
For ETMX, ETMY and BS, I locked Y arm and measured TRY
For PRM, I locked PRC and measured SPOB
For SRM, I locked SRC and measured REFL166

I used, for example, C1:SUS-ITMX_OPLEV_PERROR as an oplev signal.

The calibration factors for each mirror is below. The attachment is figures of my fitting.
I used modified equation for ITM calibration from my last calibration, so the value become small around 30%.

ITMX Pitch: 142   microrad/counts
ITMX Yaw:   145   microrad/counts
ITMY Pitch: 257   microrad/counts
ITMY Yaw:   206   microrad/counts

ETMX Pitch: 318   microrad/counts
ETMX Yaw:   291   microrad/counts
ETMY Pitch: 309   microrad/counts
ETMY Yaw:   299   microrad/counts

BS Pitch:    70.9 microrad/counts
BS Yaw:      96.3 microrad/counts

PRM Pitch:   78.5 microrad/counts
PRM Yaw:     79.9 microrad/counts

SRM Pitch:  191   microrad/counts
SRM Yaw:    146   microrad/counts

It looks strange that ITMY, BS and SRM has different value. I think this is a fitting problem.
These data have some asymmetry and cause these 20%-30% difference.
Actually, PRM Yaw has a little asymmetry but the value doesn't differ from Pitch.
This means that this calibration factor potentially has below 30% error.
(These data are the most fine data. I think we must adjust Y arm yaw alignment. The beam spot of ETMY looks too low!)
For SRM, I couldn't get fine data because it was very sensitive to tilt and easily lose its lock.
When I tuned cavity enough, The data become almost flat, so I used detuned cavity.

It is also strange that ITMX and ITMY is different. I guess that this is caused by the difference of the QPD input. The sum of QPD is around 10000 for ITMX and around 4500 for ITMY.
The difference between BS or PRM and SRM is same, I guess. The sum of QPD input for BS and SRM is around 1500, but for SRM, it is around 10000.

I will write more detailed document and upload it with my calibration code.

Attachment 1: oplev.pdf

1404

Sun Mar 15 21:50:29 2009

Kakeru, Kiwamu, Osamu

Some computers are rebooted

Computers

We found c1lsc, c1iscex, c1iscey, c1susvme, c1asc and c1sosvme are dead.
We turned off all watchdogs and turned off all lock of suspensions.
Then, I tried to reboot these machines from terminal, but I couldn't login to all of these machines.

So, we turned off and on key switches of these machines physically, and login to them to run startup scripts.

Then we turned on all watchdogs and restored all IFO.

Now they look like they are working fine.

1411

Fri Mar 20 11:01:02 2009

PEM

particle counts are high

The outside particle counts for 0.5 micron are 3 million this morning at 9am. Low clouds, foggy condition with low inversion layer.

This makes the 40m lab 30-50K

I just turned on the HEPA filter at the PSL enclosure.

Please, leave it on high

Attachment 1: particles32d.jpg

1413

Fri Mar 20 15:37:58 2009

Kakeru

arm cavity oplev calibration

oplevs

I calibrated several oplevs with OSEM signal as a confirmation of my fitting method the method is:

1) I tilted mirrors and get signals from oplevs (C1:SUS-XXXX_OPLEV_PERROR) and OSEM (C1:SUS-XXXX_SUS{PIT/YAW}_IN1).
2) I compared amplitudes of two signals and calculated conversion factors.
3) I calibrated factors above to microrad/counts with
i) The calibration factor of OSEM (2 V/mm)
ii) The calibration factor from count to V of OSEM; 1/16384 V/counts
iii) The shape of whitening filter of OSEM: 30, 100:3 (these values is taken from http://www.ldas-sw.ligo.caltech.edu/ilog/pub/ilog.cgi?group=40m&task=view&date_to_view=04/07/2005&anchor_to_scroll_to=2005:04:07:20:28:36-rana).
iv) The size of mirrors; 125mm for large optics and 75.5mm for small optics.

This calibration has some uncirtainties.

1) The calibration factor of OSEM looks very rough.
2) Output matrixes looks not to be normalized. It looks vary from 0.5 to 1.5 .
3) I don't know where OSEMs are put on mirrors accurately.

So, this calibration is very rough and may have uncertnty of a few factors, I could confirm my fitting calibration in orders.

From this calibration, I got calibration factors listed below.

ITMY Pit: 76 microrad/counts (257 microrad/counts with fitting method)
ITMY Yaw: 58 microrad/counts (206 microrad/counts)
BS Pit : 27 microrad/counts (70.9 microrad/counts)
PRM Yaw : 22 microrad/counts (79.9 microrad/counts)

For the other mirrors, OSEM outputs matrixes are not optimized and I couldn't get fine signals (I think this is not good!).

Each value is smaller than the value calibrated with fitting method in factor 3-4. There looks to be some systematic error, so there must be some difference in parameters used in OSEM calibration.

1416

Sun Mar 22 22:47:58 2009

seisBLRMS compiled but still dying

DMF

Looks like seisBLRMS was restarted ~1 AM Friday morning but only lasted for 5 hours. I just restarted it on megatron;
let's see how it does. I'm not optimistic.

1419

Tue Mar 24 03:05:25 2009

MC1 issue:
The MC1 seems to be drifting still. I found it was off from the SUS drift-mon reference values and restored the alignment using the SUS drift-mon before I went home for dinner.
But when I came back being happy with the Japanese victory over S-Korea at the WBC final, the MC was unhappy again.
I restored the alignment of the MC1 using the SUS drift-mon once again and centered the WFS QPDs.
I will leave the MC unlocked again tonight to see the drift. You are welcome to lock the MC in the morning as I will have corrected enough data by the time people come in.

Computer overloads:
I removed some filters from suspensions to off load susvme computers.
Nonetheless, both susvme1 and susvme2 are still over loaded during the dither alignment. The alignment results are in general ok. So this is not a too serious problem.
But still it would be nice to resolve.

3.8kHz hunting:
I made several measurements of the AO path loop gains (using the SR785) and the transfer functions from the CARM excitation (actuation to the ETMs) to the PO_DC signal as the arm powers are increased.
There is a similar structure as in the AO loop found also in the CARM->PO_DC transfer functions. This implies that the problem is likely to be in the PO_DC sensor not in the MC->VCO actuator. But the MC and the VCO could still be the
cause of the problem because they were in the control loop when the CARM->PO_DC TF were measured.
The peak frequency does not seem to depend on the arm power, but the conclusion is not definite because I was only able to measure the TFs from arm power 5 to 10 (not much difference).
I will make plots and post them later.

To Do for tomorrow:
Tonight the CARM error signal was noisier than the reference spectra (broad band white noise appeared). I should check the beam centering of the SPOB PD.
Also someone should center the oplevs of the mirrors as some of them are off.
Continue to measure the TFs at various power levels.
Try to put another (Thorlabs?) PD at the POB port to get PO_DC from it.

1420

Tue Mar 24 09:04:02 2009

SRM, ITMX, ETMX, ITMY and ETMY lost damping at 4:55am this morning from 4.8 magnitude earthquake.

Their damping were restored.

C1:SUS-ITMX_URSEN_OUTPUT swich was found in off position. It was turned on.

MZehnder and MC were locked.

The WFS qpd spot needs recentering

1422

Tue Mar 24 13:54:49 2009

ITMX, ITMY, BS, SRM, PRM op levs were all recentered. ETM's looked okay enough to leave as-is.

1423

Tue Mar 24 19:55:24 2009

[Rana, Jamie, Jenne]

SPOB DC hasn't been so good lately, so we installed a new PO DC PD on the PO table. We used a 30% reflecting beam splitter (BS1-1064-30-1025-someotherstuff). We didn't check with a power meter that it's a 30% BS, but it seems like that's about right. The beamsplitter is as close as we could get to the shutter immediately in front of the regular POB/SPOB PD's, since that's where the beam gets narrow. The new picked-off-pickoff beam goes to a Thorlabs 100A PD. We haven't yet checked for reflected beams off the PD, but there is a spare razor blade beam dump on the table which can be used for this purpose. The output of this PD goes to the LSC rack via a BNC cable. (This BNC cable was appropriated from it's previous "use" connecting a photodiode from the AP table to a bit of air just next to the LSC rack.) Our new cable is now connected where the old SPOB DC cable used to be, at the input of a crazy Pomona Box tee.

For reference, the new levels of POB DC and SPOB DC, as measured by their BNC DC out connections is ~4mV each. Since the beamsplitter is 70% transmissive, we used to be getting about 5.7mV on each PD.

The new photodiode puts out about 40mV, but it has an ND1.0 filter on, so if more gain is needed, we can take it off to get more volts.

1424

Tue Mar 24 23:23:05 2009

We also found that the SPOB RF cable was going through a splitter before going into the SPOB demod board. The other
input of the splitter was open (not terminated). Using 50m Ohm devices without terminated inputs is illegal. It
makes there be standing waves in the cables and makes the RF phase very dependent on cable lengths. We took away
the splitter and ran the cable straight. So expect some change in the SPOB gain and phase plus some shame.

1426

Wed Mar 25 04:18:28 2009

After the new PO_DC PD was installed, I tweaked several gains to make the locking scripts work right.
First of all, I increased the gain of PD12 (PD12_I is SPOB) by a factor of 1.4 to compensate for the power decrease
by the insertion of the BS. SPOB is used by the PRM alignment script. I was too lazy to modify the scripts.

Then I optimized the SRC DD signal which is taken from the POB.

I also had to do some gain adjustments for the CARM loop.

The attachment (AO path open loop TF) shows a depressing fact that the 3.8kHz peak is still there with the new PO_DC PD. So it was not a problem of the SPOB PD.
Next, I will check the cross over frequencies of the PZT and PC paths in the FSS and the VCO/MCL cross over.

Attachment 1: AO-Loop-p9.png

1427

Wed Mar 25 09:55:45 2009

glitching sensors of MC

SUS-MC1_SENSOR_SIDE and SUS-MC2_SENSOR_UL are glitching

Yesterday's 4.8mag earthquake at Salton Sea is shown on Channel 1

Attachment 1: glitchesofMC.jpg

1428

Wed Mar 25 17:22:58 2009

I made 40k:4k passive filter in a POMONA box and connected it to IN1 (not TEST IN1) of the FSS box.
With this modification and cut-and-tries with the gain sliders, I was able to lock the MC with 80kHz bandwidth by feeding back directory to the laser frequency.
The attached figure shows the open loop transfer function.
The phase margin is thin at 80kHz. Because of this, I could not turn on the MC super boost filters.
But I believe that we can increase the gain further by modifying the filter shape.

I used the following settings:

[MC Board]
C1:IOO-MC_REFL_GAIN 14
C1:IOO-MC_REFL_OFFSET -4.2381
C1:IOO-MC_BOOST1 0   (You can turn it on if you want, but turn it off for locking)
C1:IOO-MC_BOOST2 0
C1:IOO-MC_POL 1   (Minus)
C1:IOO-MC_VCO_GAIN 4
C1:IOO-MC_LIMITER 1 (Disable)

[FSS box]
C1:PSL-FSS_SW1 0 (Test1 ON)
C1:PSL-FSS_INOFFSET 0.1467
C1:PSL-FSS_MGAIN 30
C1:PSL-FSS_FASTGAIN 14 (Do not increase it, at least while locking. Otherwise the phase lag from the PZT loop gets significant and the MC loop will be conditionally stable).

I also turned down the FSS slow servo's RC transmission threshold to zero so that the slow servo works even without the RC locked.

Attachment 1: MC-loop-gain.png

1429

Wed Mar 25 20:41:43 2009

Mode Cleaner Servo Board Transfer Functions (to be updated)

When all things fail (netgpibdata.py is giving me weird data. When I plot the data it has saved from the 4395A, it's some wierd other universe's version of my transfer function. I don't really know what's up. I'm pretty sure I'm getting the 'correct' data, since each TF looks vaguely like it should, but with some crazy humps. I'll talk to Yoichi in the morning about it maybe.) (also, we're low on emergeny floppy discs), you can always take a picture of the Agilent 4395's screen, as shown below.

* Mode cleaner and PMC are both relocked after my shenanigans, and I'll try again in the morning (I assume locking is going on tonight) to get real TF's with real data, as opposed to the photo method.

Note to self: post the data of the TFs in the elog along with the plots, for posterity.

These TFs are of the Mode Cleaner servo board, exciting IN1 (or the 3.7MHz notch pomona box which is connected to IN1), and measuring at the SERVO out of the board.

One with the box, one without the box, and one of just the box for good measure.

Attachment 1: MCwithBoxsmall.JPG

Attachment 2: MCnoBoxsmall.JPG

Attachment 3: PomonaBoxforMCsmall.JPG

1430

Thu Mar 26 00:45:24 2009

Mode Cleaner Servo Board Transfer Functions (to be updated)

Quote:

netgpibdata.py is giving me weird data. When I plot the data it has saved from the 4395A, it's some wierd other universe's version of my transfer function. I don't really know what's up.

Yoichi, in all his infinite wisdom, reminded me that the netgpibdata script saves the data as the REAL and IMAGINARY parts, not the Mag and Phase. Brilliant. Using that nugget of information, here are the TFs that I measured earlier:

The last attachment is the .dat and .par files which contain the data and measurement parameters for the 3 TFs in the plots.

Attachment 1: MCwithandwithoutfilter25Mar2009.png

Attachment 2: PomonaBoxMCfilter25Mar2009.png

Attachment 3: MCServoData25Mar2009.tar.gz

1431

Thu Mar 26 04:01:24 2009

Yoichi, Peter, Jenne

Attached is the open loop transfer function of the FSS as of today with the common gain = 12dB and the fast gain = 16dB.
The UGF is only 250kHz. If we increase the common gain, the PC goes crazy. Exactly the same symptom as before I fixed the oscillating op-amp.

I wanted to check the cross over frequency but there is no excitation point in the fast path nor PC path. Therefore, it is not easy.

Attachment 1: OpenLoopTF.png

1432

Thu Mar 26 04:09:38 2009

Single X arm lock spectra with different MC lock schemes

The attached plots show MC_F, FSS_FAST_F and XARM IN/OUT spectra with different MC locking modes.
The conventional locking means the FSS is used. The direct frequency lock is the new way.
You can see that at low frequencies, the frequency actuator is working hard to suppress the MC pendulum motions.
The X-arm also sees a lot of frequency noise at low frequencies because of this.
The transmitted power of the X-arm fluctuates a lot making it difficult to align the mirrors.

The zoomed plots show that the structures in the kHz band are also present in the case of the direct frequency lock, although the frequencies are somewhat different.

Attachment 1: XarmSpectra.pdf

Attachment 2: XarmSpectraZoom.pdf

1433

Thu Mar 26 04:27:26 2009

3.8kHz peak as a function of the arm power

During the power ramp-up, I actuated CARM using ETMs and measured the transfer functions to the PO_DC at several arm powers.
The peak grows rapidly with the power. It also seems like the frequency shifts slightly as the power goes up, but not much.

Some sort of an RSE peak ? An offset in the PRC lock point ?

Attachment 1: CARM-PODC.pdf

1434

Thu Mar 26 09:08:18 2009

Kakeru

arm cavity oplev calibration

oplevs

I uploaded a document about my oplev calibration.
/cvs/cds/caltech/users/kakeru/oplev_calibration/oplev.pdf

At same place I put my matlab codes for calibration.
/cvs/cds/caltech/users/kakeru/oplev_calibration/oplev_calibration.m

1436

Fri Mar 27 02:50:54 2009

DD demodulation phase suspicious

I noticed that the gain of PD6_Q (before the phase rotation) was 0 whereas PD6_I gain was 15.
This means the demodulation phase of the PD6 had no meaning other than changing the gain.
According to the conlog, it has been zero since March 2nd. I don't know how it happened.

While I was re-adjusting the DD phase, the MC started to unlock frequently (every 10 minutes or so).
MC1 is again drifting a lot (it is getting step-function like alignment changes intermittently).
This practically made it impossible to work on locking. So I decided to fix the MC first.
See Peter's elog entry for the MC work.

1437

Fri Mar 27 15:05:42 2009

MC glitch investigation

Attached plots are the result of the MC1 trend measurement.

See the attachment #1. The first two plots show the drift of the MC1 alignment as seen by the OSEMs. It is terrible. Other MC mirrors also drifted but the scale is smaller than the MC1.

From the VMon channels, you can see that the control voltages were quiet.

The monitor channels we added were:

MC_TMP1 = UL coil bias. Input to the coil driver board.

MC_DRUM1 = UL coil bias. Output of the current buffer.

OSA_APTEMP = LR coil bias. Input to the coil driver board.

OSA_SPTEMP = LR coil bias. Output of the current buffer.

The bias voltages show no drift except for a glitch around 7AM. This glitch did not show up in the SPTEMP channel (LR coil bias output). This was because the probe was connected to the coil side of the output resistor by mistake.

The second attachment shows a zoomed plot of MC1 OSEM signals along with the bias monitor channels (signals were appropriately scaled so that they all fit in +/-1).

There is no correlation between the OSEM signals and the bias voltages.

Since we were only monitoring UL and LR coils, I changed the monitor points as follows.

MC_TMP1 = LL coil bias. Output of the current buffer.

MC_DRUM1 = UL coil bias. Output of the current buffer.

OSA_APTEMP = UR coil bias. Output of the current buffer.

OSA_SPTEMP = LR coil bias. Output of the current buffer.

I will leave the MC unlocked for a while.

Quote:

Yoichi, Pete

The MC loses lock due to glitches in the MC1 coils.

We do not know which coil for sure, and we do not know if it is a problem going into the board, or a problem on the board.

We suspect either the UL or LR coil bias circuits (Pete would bet on UL). If you look at the bottom 4 plots in the attached file, you can see a relatively large 3 minute dip in the UL OSEM output, with a corresponding bump in the LR (and smaller dips in the other diagonal).

These bumps do not show up in the VMONS which is why we are suspicious of the bias.

To test we are monitoring 4 points in test channels, for UL and UR, both going into the bias driver circuit, and coming out of the current buffer before going into the coils.

We ran cable from the suspension rack to the IOO rack to record the signals with DAQ channels.

The test channels:

UL coil C1:IOO-MC_DRUM1 (Caryn was using, we will replace when we are done)

UL input C1:IOO-MC_TMP1 (Caryn was using, we will replace when we are done)

LR coil C1:PEM-OSA_SPTEMP

LR input C1:PEM-OSA_APTEMP

We will leave these overnight; we intend to remove them tomorrow or Monday.

We closed the PSL shutter and killed the MC autolocker.

Attachment 1: MC1_Drift.pdf

Attachment 2: MC2_Drift.pdf

1438

Fri Mar 27 17:52:16 2009

MC glitch investigation

Per Rob's suggestion, I put the probes across the output resistors of the bias current buffers instead of measuring the output voltage with respect to the ground.

This way, we can measure the current flowing the resistor. The change was made around 17:30.

Quote:

Attached plots are the result of the MC1 trend measurement.

See the attachment #1. The first two plots show the drift of the MC1 alignment as seen by the OSEMs. It is terrible. Other MC mirrors also drifted but the scale is smaller than the MC1.

From the VMon channels, you can see that the control voltages were quiet.

The monitor channels we added were:

MC_TMP1 = UL coil bias. Input to the coil driver board.

MC_DRUM1 = UL coil bias. Output of the current buffer.

OSA_APTEMP = LR coil bias. Input to the coil driver board.

OSA_SPTEMP = LR coil bias. Output of the current buffer.

The second attachment shows a zoomed plot of MC1 OSEM signals along with the bias monitor channels (signals were appropriately scaled so that they all fit in +/-1).

There is no correlation between the OSEM signals and the bias voltages.

Since we were only monitoring UL and LR coils, I changed the monitor points as follows.

MC_TMP1 = LL coil bias. Output of the current buffer.

MC_DRUM1 = UL coil bias. Output of the current buffer.

OSA_APTEMP = UR coil bias. Output of the current buffer.

OSA_SPTEMP = LR coil bias. Output of the current buffer.

I will leave the MC unlocked for a while.

1439

Sun Mar 29 13:44:27 2009

ETMY sus damping restored

ETMY sus damping was found to be tripped.

It was retored.

All fluorecent light were turned off. Please try to conserve some energy.

1440

Sun Mar 29 17:54:41 2009

MC1 drift investigation continued

The attached plots show the trend of the MC OSEM signals along with the voltages across the output resistors of the bias current buffers.
The channel assignments are:
MC_TMP1 = LL coil
MC_DRUM1 = UL coil
OSA_APTEMP = UR coil
OSA_SPTEMP = LR coil

Although the amplitude of the drift of MC1 is much larger than that of MC2 and MC3, the shape of the drift looks like a daily cycle (temperature ?).
This time, I reduced the MC1 bias currents to avoid saturation of the ADCs for the channels measuring the voltages across the output resistors.
This may be the reason the MC1 has been non-glitchy for the last day.

OSA_APTEMP (UR Coil) shows a step function like behavior, although it did not show up in the OSEM signals.
This, of course, should not happen.

Today, I went to the MC1 satellite box and found that the 64-pin IDE like connector was broken.
The connector is supposed to sandwich the ribbon cable, but the top piece was loose.
The connector is on the cable connecting the satellite box and the SUS rack.
I replaced the broken connector with a new one. I also swapped the MC1 and MC3 satellite boxes to see if the glitches show up in the MC3.

I restored the bias currents of the MC1 to the original values.

The probes to monitor the voltages across the output resistors are still there. For OSA_SPTEMP, which was saturating the ADC, I put a voltage divider before the ADC. Other channels were very close to saturation but still within the ADC range.

Please leave the MC unlocked at least until the Monday morning.
Also please do not touch the Pomona box hanging in front of the IOO rack. It is the voltage divider. The case is connected to the coil side of the output resistor. If you touch it, the MC1 bias current will change.

Attachment 1: Drift1.pdf

1441

Mon Mar 30 09:07:22 2009

MC1 drift investigation continued

Maybe we can temporarily just disconnect the bias and just use the SUS sliders for bias if there's enough range?

1444

Mon Mar 30 13:29:40 2009

MC1 drift investigation continued

Quote:

Maybe we can temporarily just disconnect the bias and just use the SUS sliders for bias if there's enough range?

We could do this, but I'm suspicious of the cables between the coil driver and the coils (including the satellite box). In this case, disabling the bias won't help.
Since the MC1 has been quiet recently, I will just lock the MC and resume the locking.

1445

Mon Mar 30 15:51:27 2009

HP4291A left the lab to be repaired

Electronics

Eric Gustafson is handling the old HP4291A rehabilitation. Tarac picked both units up today.

March of 2008 Tucker Electronics failed to fix it's intermittent ~25MHz 0.5V oscillation at the swept sine output

See 40m-elog id:398 on 3-24-2008 by Rob Ward

1447

Tue Mar 31 09:42:32 2009

ETMY sus damping restored again

PEM

The Caltech gasoline storage tank is being upgraded.

They are jack hammering and digging with bulldozer 50 yards south of ETMY

1448

Wed Apr 1 10:22:13 2009

VAC

RGA logging is working

Thanks to Joe B who made the SRS RGA working with linux

Last data file logged at 2008 Oct 24 with old Dycor unit

First data file logged at 2009 Feb 10 with SRS

Attachment 1: rga-090401.png

1449

Wed Apr 1 15:47:48 2009

3.8kHz peak looks like a real optical response of the interferometer

Yoichi, Peter

To see where the 3.8kHz peak comes from, we locked the interferometer with the CARM fed back only to ETM and increased the arm power to 4.
The CARM error signal was taken from the transmission DC (not PO_DC).
The attached plots show the CARM transfer functions taken in this state (called ETM lock in the legends) compared with the ones taken when the CARM is locked by the feedback to the laser frequency (called "Frequency lock").
The first attachment is the TFs from the CARM excitation (i.e. the ETMs were actuated) to the TR_DC and PO_DC signals.

The second attachment is the AO path loop TFs. This is basically the TF from the frequency actuator to the PO_DC error signal.
I injected a signal into the B-excitation channel of the common mode board (with SR785) and measured the TF from TP2B to TP2A of the board.
For the ETM lock case, the AO loop was not closed because I disabled the switch between TP2A and TP1B.

The observation here is that even with no feedback to the laser frequency, the 3.8kHz peak is still present.
This strongly suggests that the peak is a real optical response of the interferometer.

To realize the ETM lock with arm_power=4, I had to tweak the CM loop shape.
I wrote a script to do this (/cvs/cds/caltech/scripts/CM/ETM_CARM_PowerUp).
You can run this script after drstep_bang has finished.

Attachment 1: CARM-ETM-EXC.png

Attachment 2: AOpath-TFs.png

1450

Wed Apr 1 16:14:36 2009

3.8kHz peak does not change with SRC offset

Yoichi, Peter

We suspected that maybe the 3.8kHz peak is the DARM RSE somehow coupled to the CARM.
So we added an offset to the SRC error signal to see if the peak moves by changing the offset.
It didn't (at least by changing the SRC offset by +/-1000).
(I had a nice plot showing this, but dtt corrupted the data when I saved it. So no plot attached.)

I also played with the PRC, DARM offsets which did not have any effect on the peak.
The only thing, I could find so far, having some effect on the peak is the arm power. As the arm power is increased, the peak height goes up and the frequency shifts slightly towards lower frequencies.

1452

Fri Apr 3 10:01:50 2009

VAC

rgascan with temp plot

Rga scan of day 231 since pumpdown pd66-m-d231

m stands for maglev pumping speed, vacuum normal condition of valves,

cc4 cold cathode gauge at the rga location,

cc1 is real ifo pressure from the 24" tube at the pumpspool,

PEM-count temp: vac envelope temp at the top of IOO chamber

Attachment 1: pd66tempow.jpg

Attachment 2: rga-090403scan.png

1454

Fri Apr 3 17:20:05 2009

The 3.8kHz peak seems like the DARM RSE (not 100% sure though)

Yoichi, Kentaro,

Last night, we took several measurements of the AO path loop TFs with various offsets/demod. phases tweaked.
The first attachment shows the AO path loop TF as a function of the offset (in counts) added to the DARM error signal.
Though it is a bit crowded plot, you can see a general tendency that the peak becomes lower in height and higher in frequency as
the DARM offset goes from negative to positive. Since the peak height also depends on the arm power and it fluctuates during the measurements,
the change is not monotonic function of the offset though.

Being suspicious of the demodulation phase of the DARM error signal (AS166), we scanned it (see the second attachement).
But there is no significant change.
Note that the phase of the TF is 180 degrees different from the first attachment. This is because I changed the measurement point of the returning signal
on the CM board from TP2A to OUT2 to see POX_1I signal as well. These points should give the same signal for PO_DC except for the sign.

We also took the AO path TFs by changing the MICH offset (the third attachment). Again, there is no big change.

With the CARM locked with the PO_DC signal, we took the transfer function from the AO path actuation signal to the response of the POX_1I (4th attachment).
There is a huge 3.8kHz peak.

Finally, we measured the DARM response by exciting the ETMs differentially (the PDF attachment).
The shape of the 3.8kHz resonance looks like the DARM RSE peak.

It is speculated that somehow the DARM RSE resonance is coupled into the CARM loop. Don't know how though.
I'm now working on an Optickle simulation to get an insight into this issue.

Attachment 1: AO-TF-DARM-OFFSET.png

Attachment 2: AO-TF-DARM-DEMOD-PHASE.png

Attachment 3: AO-TF-MICH-OFFSET.png

Attachment 4: POX_1I.png

Attachment 5: DARM-Loop.pdf

1455

Mon Apr 6 19:09:15 2009

Old Guralp is hooked back up to the ADC

PEM

Old Guralp is hooked back up, the new one is sitting next to it, disconnected for now.

1456

Mon Apr 6 21:50:43 2009

Arm Locking via pushing MC2

LSC

Inspired by our 'No Refcav' scheme here, I was inspired to re-explore the idea of locking the
CARM DOF using only feedback to the MC/laser. Last week I got this to work on the single arm and
full IFO at Livingston.
I also estimate the MC noise there.

Today I found the settings to allow X-arm locking here without any feedback to the ETM or ITM:

- Set the LSC Output Matrix to feed the XARM signal to MC2.
- Turn OFF the input of the LSC-ETMX filter bank (this does not disable tickling).
- Turn OFF FM7 (0.1:10) in MC2-MCL.
- Turn ON MC2-LSC with a gain of 0.2 and FM3 FM4 FM5.

That's enough to lock the arm - its pretty stable. This also assumes that the LSC-MC2 bank has its nominal gain of -0.178.

To determine the gain of +0.2 in the MC2-LSC filter bank, I measured the TF from MC2->PD3_I and from ETMX->PD3_I. I adjusted
the gain to be equal at 150 Hz for acquisition and the sign to be opposite to account for the (-) in LSC-MC2. The TF is
attached.

After locking, I type a zero into the MC2-MCL filter bank and that shuts off the feedback from the MC servo to MC2. This is
now topologically similar to the standard CM servo configuration.

The second attachment has the trends of this locking. You can see that the MC_F goes off into the weeds, but the MCL signal
does not so much. I think maybe the MC length is drifting a lot - not the arm.

The third attachment shows the spectra.

Attachment 1: mc2-xarm.pdf

Attachment 2: Untitled.png

Attachment 3: nohands.pdf

1458

Wed Apr 8 02:47:42 2009

This is a summary of activities in the last few nights, although there is not much progress.

The attachment 1 and 2 show the CARM and DARM responses around 3.8kHz at different arm power levels.
The CARM error signal was PO_DC and the DARM error signal was AS2Q.
The excitations were both applied to the ETMs (I temporarily modified the output matrix so that the unsed XARM filter bank can be used to excite CARM and DARM).
DARM and CARM show very similar behavior as the power goes up.

The third attachment shows transfer functions to various signals from CARM and DARM excitations (ETMs).
Though the plot contains many curves, look at PO_DC curves (green and black).
PO_DC is used as CARM error signal but it has a larger response to DARM than CARM (by 10dB or so).
This is not good.

Although the 3.8kHz problem still exists, tonight I was able to go up to arm power = 80 a couple of times, where we are ready to hand off from PO_DC to the RF CARM signal. The hand off failed. I'm now optimizing the hand off gain, but it is difficult because the interferometer is unstable at this power level.

Attachment 1: CARM_TFs.pdf

Attachment 2: DARM_TFs.pdf

Attachment 3: DARM-CARM-Coupling.pdf

1462

Thu Apr 9 11:27:19 2009

vac gauge reading problem

VAC

Cold cathode gauge CC4 is reading normal.

CC1 is glitching, it is probably dirty.

CC2 is fluctuating too much and it is cutting out for 6-7 minutes. It must be insulated by deposits and there is no emission current.

I think the same goes for P1

They will have to be replaced at the next vent

Attachment 1: vacgflsec.jpg

Attachment 2: vacgflmin.jpg

1463

Thu Apr 9 12:23:49 2009

pete

tuning ETM common mode

Pete, Yoichi

Last night, we put the IFO in FP Michelson configuration. We took transfer functions of CARM and DARM, first using CM excitations directly on the ETMs, and then using modulations of the laser frequency via MC excitation. We found that there was basically no coupling into DARM using the MC excitation, but that there was coherence in DARM using the ETM excitation. Therefore, I tuned the ETM common mode in the output matrix. I did this by taking transfer functions of PD1_Q with PD2_I (see attached plot). I changed the drdown_bang script to set C1:LSC-BTMTRX_14 0.98 and C1:LSC-BTMTRX_24 1.02.

Attachment 1: FPMI-DARM-CARM-ETM-fineScan.pdf

1467

Fri Apr 10 01:24:08 2009

Computers

allegra update (sort of)

I tried to play an .avi file on allegra. In a normal universe this would be easy, but because its linux I was foiled.

The default video player (Totem) doesn't play .avi or .wmv format. The patches for this work in Suse but not Fedora. Kubuntu but not CentOS, etc.I also tried installing Kplayer, Kaffeine, mplayer, xine, Aktion, Realplay, Helix, etc. They all had compatibility issues with various things but usuallylibdvdread or some gstreamer plugin.So I pressed the BIG update button. This has now started and allegra may never recover. The auto update wouldn't work in default mode becauseof the libdvdread and gstreamer-ugly plugins, so I unchecked those boxes. I think we're going to have this problem as long as we used any kind ofadvanced gstreamer stuff for the GigE cameras (which is unavoidable).

1469

Fri Apr 10 04:54:24 2009

Suggested by Rob and Rana's simulation works, I tried to use REFL_DC for the CARM error signal.

My current guess for the cause of the 3.8kHz peak is the following.
The AF sidebands created by the laser frequency drive are reflected by the IFO to the symmetric port if the arms are perfectly symmetric.
However, if there is asymmetry in the arm cavities (such as loss imbalance, ITM transmission difference etc) the sidebands are scattered from the common mode to the differential mode. If our CARM error signal has a large response also to the differential mode (i.e. DARM), the loop is closed. At the DARM RSE frequency, the AF sideband in the differential mode is enhanced and creates a peak in the CARM response.
What Rob's plots show is that PO_DC has a larger response to DARM than REFL_DC has. You can see this from the curves of CARM offset = 0 (black ones).
When the CARM offset is zero, the CARM signal should go to zero. Therefore, the black curves show the residual DARM response. In the case of PO_DC, the black curve is very large suggesting a large DARM coupling.

Now I changed the cabling at the LSC rack to put REFL_DC into the REFL2 input of the CM board.
The REFL_DC signal is put through a 160kHz RC LPF and split to the ADC and the CM board (AC coupled by a large capacitor).
I modified the cm_step script to use PD4_DC as CARM error signal. (The old script is saved as cm_step.podc).
Since the polarity of the REFL_DC signal is opposite to the PO_DC, I flipped the polarity switch of the CM board.
This will flip the sign of the RF CARM signal because this switch flips the polarity of the both inputs.
We have to flip the sign of the RF CARM signal with the SR560 sitting on the LSC rack, which I haven't done yet.

With some tweaks of the gains and addition of two lag-lead filters to PD4_DC, I was able to completely hand off the CARM error signal to REFL_DC.
The attached plot shows the AO path loop gain at arm power = 7. The 3.8kHz is gone, although there is some phase ripple around 3.8kHz.

Since the gain behavior of the REFL_DC is different from the PO_DC, I'm now working on the power up part of the script, adjusting the gains as the power goes up.

Attachment 1: AO-loop-gain-CARM-REFL_DC.png

1470

Fri Apr 10 18:11:18 2009

[Rob, Jenne]

I noticed that the ISS Mean Value and CS Saturation were both RED and unhappy. (The alarms were going off, and they were both red on the MEDM screen). None of the MEDM settings seemed off kilter, so we went out to take a look at the PSL table.

Rob checked that light is indeed going to both of the ISS photodiodes (Morag and Siobhan). Next we checked that all the cables were good, and that the power to the ISS box was plugged in. In this process, Rob wiggled all the cables to check that they were plugged in. Just after doing this, the Mean Value and CS Sat were happy again. Rob thinks the current shunt connection might be bad, but we don't really know which one it was since all of the cables were jiggled between our checking the screens.

Right now, everything is happy again, but as with all bad-cabling-problems, we'll probably see this one again.

I don't know why in particular the connection decided to spaz out this afternoon...I don't think anyone opened the PSL table before Rob and I went to investigate. I was working on the PMC servo (checking the LO levels...to be posted in a couple minutes), but didn't have anything to do with the ISS. After I was done, I put everything back, and locked the PMC and the MC, and everything was good, until some time later when the ISS started flipping out.

1471

Fri Apr 10 19:09:48 2009

I measured the RF LO output level from the PMC's LO board which goes directly into the LO input on the PMC Servo board. This goes hand-in-hand with Rana's thoughts
that we might be giving the PMC mixer a too-low LO value, and we might need to switch out the mixer. Steve ordered some new mixers today to try out.

The RF Output Adjust slider (on the C1:PSL_PMC_PS screen) goes from 0-10V; The nominal value (or at least the value I found it at today) is 2.014V.

To measure the RF level: I unlocked the Mode Cleaner and turned off the ISS servo per Yoichi's suggestion. I then unplugged the input to the PMC servo board's LO input,
and put that cable into a 300MHz 'scope, with 12dB attenuation. The 'scope was AC coupled, with the input set to 50Ohms.

I then changed the RF Output Adjust slider in increments of 0.5, and measured the peak-to-peak values on the scope. In the table and on the plots, I've taken into account
the 12dB attenuation. i.e I actually measured 964mV, so 964mV*10^.6 = 3838mV.

RF Output Adjust	Output measured on scope	Oscillator Output Monitor
[V]	[Vpp]	[no units given on MEDM screen]
	All \pm 0.0159	all of this column is NEGATIVE
0.0000	3.838	0.007
0.5000	3.854	0.007
1.0000	3.838	0.006
1.5000	3.838	0.007
2.0000	3.838	0.006
2.5000	3.838	0.007
3.0000	3.838	0.007
3.5000	3.838	0.007
4.0000	3.838	0.007
4.5000	3.822	0.007
5.0000	3.822	0.012
5.5000	3.790	0.076
6.0000	3.758	0.257
6.5000	3.694	0.555
7.0000	3.615	0.931
7.5000	3.535	1.277
8.0000	3.456	1.532
8.5000	3.392	1.709
9.0000	3.344	1.829
9.5000	3.312	1.908
10.0000	3.296	1.966

I think it's kind of funky that it's so flat for ~half the slider. Also, the third column includes the Oscillator Output Monitor value from the MEDM screen at various RF Adjust slider values. All of these should be negative (i.e. -0.007), but the TABLE function doesn't like "-" signs. I don't know if this information is degenerate with the 'scope measurements, or if it's an indicator of what (might be) wrong.

After finishing, I plugged the cable back into the PMC servo board as it was, turned back on the ISS and relocked the PMC and the MC.

Attachment 1: RFSliderAdjustCalib.png

Attachment 2: RFSliderAdjustCalibWithOsc.png

1472

Fri Apr 10 19:10:53 2009

I don't know who left the X arm locked, but I just ran the Align Full IFO script, so everything is good in case Yoichi/someone comes in to lock the IFO this weekend.

1473

Sat Apr 11 00:45:41 2009

Quote:

I then changed the RF Output Adjust slider in increments of 0.5, and measured the peak-to-peak values on the scope. In the table and on the plots, I've taken into account the 12dB attenuation. i.e I actually measured 964mV, so 964mV*10^.6 = 3838mV.

3.8Vpp is about 16dBm.
The mixer for the PMC demodulator is level 23. So 16dBm is insufficient.
What is the level of the new mixer Steve ordered ? 13 ?

1475

Sun Apr 12 19:27:20 2009

Quote:

3.8Vpp is about 16dBm.
The mixer for the PMC demodulator is level 23. So 16dBm is insufficient.
What is the level of the new mixer Steve ordered ? 13 ?

Since Steve and Jenne were on it, I'm sure they ordered the optimum values...

From the table, it looks like the drive level adjuster is busted. Its not supposed to just give a
1-2 dB change over the full range. We'll have to think about what exactly to do, but we should
probably install the level 13 mixer and put in the right attenuation to make the LO be ~13.5 dBm
including the filter. Also need to calibrate the LO readback on the board like what Peter did for
the FSS.

1477

Mon Apr 13 08:59:57 2009

Quote:

3.8Vpp is about 16dBm.
The mixer for the PMC demodulator is level 23. So 16dBm is insufficient.
What is the level of the new mixer Steve ordered ? 13 ?

I ordered mixers level 13, 17 on Friday and level 23 now.
They should be here Tuesday

NOTE: level 23 power is illegal to use in the 40m lab
They get hot

1478

Mon Apr 13 17:55:37 2009

PSL

PMC LO Mon Calibration

I have calibrated the PMC LO Mon (C1:PSL-PMC_LODET) on the PMC's EPICS screen, by inputting different RF LO levels into the LO input of the PMC servo board.

Since the RF output adjust slider on the PMC's Phase Shifter screen doesn't do a whole lot (see elog 1471), I used a combination of attenuators and the slider to achieve different LO levels. I measured the level of the attenuated RF out of the LO board using the 4395A in spectrum analyzer mode, with the units in dBm, with 50dB attenuation to make it stop complaining about being overloaded. For each row in the table I measured the RF level using the 4395, then plugged the cable back into the PMC servo board to get the EPICS screen's reading.

The last 2 columns of the table below are the 'settings' I used to get the given RF LO level.

RF LO Input to PMC Servo Board [dBm]	LO Mon on EPICS Screen [no units]	RF Output Adjust Slider [V]	Attenuators used [dB]
16.004 +- 0.008	0.1200 +- 0.0003	0	0
15.001 +- 0.004	0.0708 +- 0.0008	0	1
14.079 +- 0.008	0.0318 +- 0.0001	8	1
13.002 +- 0.006	0.0126 +- 0.0004	0	3
11.992 +- 0.010	0.0024 +- 0.0008	0	4
10.994 +- 0.010	-0.0024 +- 0.0003	0	4+1=5
9.993 +- 0.008	-0.0047 +- 0.0007	0	3+3=6

When the new mixers that Steve ordered come in (tomorrow hopefully), I'll put in a Level 13 mixer in place of the current Level 23 mixer that we have. Also, Rana suggested increasing the gain on the op-amp which is read out as the LO Mon so that 13dBm looks like 1V. To do this, it looks like I'll need to increase the gain by ~80.

Attachment 1: LOmonCalibration.png

1480

Tue Apr 14 02:59:02 2009

Yoichi, Peter,

With careful adjustments of the common mode gains, we were able to go up to arm power = 26, sort of robustly (more 50% chance).
At this arm power level, the common mode loop shape still looks good. But the interferometer loses lock easily.
I have to check other DOFs, but the interferometer does not stay locked long enough.
Today, lock losses of the IFO were associated with the lock loss of the PMC whereas the FSS stayed locked.
Probably the AO path got large kicks, which could not be handled by the PMC PZT.

The cause for the IFO lock loss is under investigation.

1482

Tue Apr 14 17:20:36 2009