ELOG 40m

Electronics

Amphony 2500 Headphones

We bought the Amphony 2500 Digital Wireless headphones recently. The other cheapo headphones we have are OK for control room use, but have a lot of noise
and are, therefore, not useful for noise hunting.

The new digital ones are pretty much noise-free. With the transmitter next to rosalba, you can walk halfway down the east arm and all around the MC area
before the reception goes bad. For real noise hunting, we will want to put the transmitter next to the BS chamber and take an analog pickoff from the DC PDs.

In the OMC diagram, we should put an AUDIO filterbank and wire it to the DAC so that we can do arbitrary IIR filtering on the audio signal.

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.

1474

Sun Apr 12 01:19:30 2009

New FE codes for suspensions not successful

Alex recompiled the suspension FE codes for c1susvme1 and c1susvme2 to fix the denormalization problem.
The new modules are in
/cvs/cds/caltech/users/alex/cds/rts/src/fe/40m/losLinux1.o
/cvs/cds/caltech/users/alex/cds/rts/src/fe/40m/losLinux2.o

I tried them today, but c1susvme1 did not work with the new code while c1susvme2 seemed to run ok.
So I reverted the modules (losLinux1.o and losLinux2.o) to the original ones.
The original modules are also backed up as losLinux1.o.11Apr09 and losLinux2.o.11Apr09 in the corresponding target directories.

I reported the problem to Alex.

1473

Sat Apr 11 00:45:41 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 ?

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.

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

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.

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

1468

Fri Apr 10 03:10:08 2009

Laser PM to REFL-DC transfer functions at multiple CARM offsets

I hereby award the previous rainbow transfer functions the plot innovation of the month award for its use of optical frequency to denote CARM offset.

The attached movie here shows the sensing matrix (minus MICH) as a function of CARM offset. There are 3 CARM signals plotted:

GREEN - tonights starting CARM signal - REFL_DC

RED - my favorite CARM signal - REFL 166 I

CYAN - runner up CARM signal - POX 33 I

1467

Fri Apr 10 01:24:08 2009

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

1466

Thu Apr 9 23:20:35 2009

rob

Laser PM to REFL-DC transfer functions at multiple CARM offsets

Quote:

I've plotted some transfer functions showing the response at POB DC to laser frequency (phase) noise. There are transfer functions for multiple CARM offsets. Basically, the transfer function looks like the DARM transfer function when the CARM is at zero offset, and is super-wonky elsewhere. POB-DC is not a good CARM signal for intermediate stages of lock acquisition in a dual-recycled interferometer. We should look into switching back to REFL-DC.

Here are the corresponding transfer functions for REFL-DC.

Attachment 1: CARMoffs1_r.png

Attachment 2: CARMoffs2_r.png

Attachment 3: CARMcarpet_r.png

1465

Thu Apr 9 23:11:27 2009

rob

Laser PM to PO-DC transfer functions at multiple CARM offsets

Attachment 1: CARMoffs1.png

Attachment 2: CARMoffs2.png

Attachment 3: CARMcarpet.png

1464

Thu Apr 9 20:56:12 2009

Restore the alignment. Write elog entries.

HowTo

General

I often find that the mirrors are left mis-aligned (like in X-arm mode) when I come in for the locking, including tonight.
As Rob stated repeatedly in the past elog, leaving the mirrors mis-aligned for a long time without a reason is an abomination.
It will cause a slow drift of the mirrors and the lock acquisition work is severely slowed down as I have to run the alignment script many times.

I also found that the GPIB-Ethernet box (named teofila) was taken away from the SR785 hooked up to the CM board.
I found it connected to Alberto's setup. Instead, another GPIB box was left on the SR785 but not connected.
I couldn't find any elog entry about this.
This is totally unacceptable.
The SR785 has been used as a very important tool for monitoring the AO path loop gain during the power up.
You can use it if you need, but you have to note it in elog.

The other GPIB box left on the SR785 had a wrong name labeled on it. It had a name "ERMINIA", but the IP address written next to the name was actually assigned to "crocetta" in the DNS server on linux1. I don't know who made the label. I put a new and correct label on it.
Now I'm using crocetta for the SR785 so Alberto can keep using teofila.

Anyway, I think recently people are lazy about elog.
Whatever work you did, please put it in the elog even if you think it is trivial.
I also would like to see more detailed elog entries from people. Many of the recent elog entries are too simple or superficial that it is hard for other people to figure out what was really done.

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

1462

Thu Apr 9 11:27:19 2009

vac gauge reading problem

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

1461

Wed Apr 8 18:46:50 2009

DMF, SVN, x2mc, and matlab

General

While waiting for the installation of the 32-bit Matlab 2009a to finish, I tried updating our seisBLRMS.m code.

Although DMF is in SVN, we forgot to check it out and so the directory where we have been doing our mods is not a working copy and our changes have not been captured: Shame.

We will probably have to wipe out the existing SVN trunk of DMF and re-import the directory after checking with Yoichi for SVN compliance.

Also wrote a script: LSC/x2mc, which will transition from regular ETM based X Arm locking to the MC2 based locking. It ran once OK, but I get a segfault on the 'trianglewave' which was trying to run the 'ezcastep' perl script which was calling 'ezcastep.bin'.

I also restarted the seisBLRMS.m on a terminal on Mafalda in the new Matlab 2009a to see if it loses its NDS connection like it did with 2007a. I also reduced the 'delay' parameter to 4 minutes and the 'interval' to 1 minute. This should be so that the total delay is now 5 minutes between seismic noise and seismic trend.

1460

Wed Apr 8 18:18:33 2009

LSC code recompiled with a fix for denormalization problem

Below is the link to the anti-denormalization technique that Rolf and Alex implemented at the sites,
that was pointed out by Chris Wipf from MIT:

http://www.musicdsp.org/files/denormal.pdf

1459

Wed Apr 8 09:36:20 2009

valve condition changed to BG to calibrate the RGA

Vacuum normal valve condition was changed to accommodate SRS-RGA calibration.

The annulus valves were closed to free TP3 to pump on the RGA

VM1 was closed to isolate the RGA from the IFO.

 
 
VM3 opened to TP3.
 
This condition is called back ground (BG) mode. It is where we can calibrate and see the RGA background without the IFO.

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

1457

Tue Apr 7 21:39:57 2009

LSC code recompiled with a fix for denormalization problem

This is not my work but I will put it for the record.

A few days ago, Rob recompiled the LSC code with the fix of the denormalization problem provided by Alex.
Since then, the LSC code has been working fine. I recognize that c1lsc is now less loaded.

I believe Rob only recompiled the LSC code, so there could still be the problem in the suspension controllers.

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

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.

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

1453

Fri Apr 3 14:52:38 2009

Omnistructure

PEM

Guralp is finally back!

After many, many "it'll be there in 2 weeks" from the Guralp people, our seismometer is finally back!

I have it plugged into the Guralp breakout box's Channel 1xyz (so I have unplugged the other Guralp). Both of the Guralp's are currently sitting under the MC1/MC3 chamber.

Before we can have both Guralps up and running, I need to stuff the next 3 channels of the breakout box (back in the fall, I only had Caryn do 1x, 1y, 1z, and now I need 2x, 2y and 2z done with the fancy low-noise resistors), so all the gains match between the 2 sets of channels.

I'm leaving the new Guralp plugged in so we can see how it behaves for the next couple days, until I take out the breakout box for stuffing.

1452

Fri Apr 3 10:01:50 2009

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

1451

Wed Apr 1 23:18:07 2009

rana, koji

No Reference Cavity Required

Koji sent us a note about our "No Reference Cavity Required" entry. I thought that it nicely summarizes the
whole shebang and so I post it here for its pedagogical value.

Generally, frequency stabilization is a comparison of the two
frequency references.

1. In the conventional case you are comparing the NPRO stability with
the RC stability. The NPRO cavity is short and probably placed in a
less stable environment than that of the RC. Therefore, the PDH
signal only feels the frequency fluctuation of the NPRO, resulting
in the laser PZT fast feedback dominated by the NPRO stability. As
the MC length at low frequency is controlled by the mass feedback,
the resulting laser stability through the MC is virtually limited
by the RC stability.

2. On the other hand, you are comparing the stabilities of the NPRO
crystal and the MC cavity in the direct control configuration. The
stability of the MC at high frequency is better than that of the
NPRO. It is opposite at low frequency, of course, because of the
pendulum motion. The resulting laser stability through the MC is
limited by the MC stability.

3. In the CM servo, the length of the MC is stabilized such that the
arm stability is duplicated to the MC. As a result, your MC servo
compares the stability between the NPRO and the arm cavity. Again
at around 1Hz, the arm cavity is noisier than the NPRO. (This is
true at least TAMA case. I am quite unsure about it in the LIGO
long arm cases.)

One useful consequence is that in those configurations, the laser PZT
feedback at around 1Hz represents the stability of the NPRO, the MC,
and (possibly) the arm cavity, respectively. It was clearly seen
Yoichi's e-log entry 1432. At TAMA we call this signal as "MCPZTfb"
and use this for the diagnostic purposes of the suspended cavities. As
the laser fast PZT is rarely replaced and considered as a stable
actuator, this signal is considered as a good reference at low
frequency which is consistent across various configurations
(e.g. before/after replacement of the suspensions etc). Once the
response and the coefficient are calibrated you can easily convert
this signal to the length displacement.

Another remark: In the direct configuration, the frequency stability
of the beam goes through the MC is determined by the MC stablity. It
means that the beam to the arm has essentially worse stability than
the arm stability by factor of L_arm/L_MC. In the 40m case this factor
is just 3 or so. This is ok. However, for the LIGO 4km arm, the factor
becomes something like 300. This means that if you have 1um_rms of the
MC length fluctuation, the arm PDH feels 300um_rms. (Maybe some extent
less because of the common mode rejection of the MC suspensions.)

Yes, the actuator to the MC length is very strong this time, and
should be able to stop this amount of fluctuation easily... if the
things are all linear. I am not certain whether you can acquire the
lock even by this strong actuator when the arm is crazily swinging,
the PDH signals are ringing all the way, etc, etc...Particularly in
the recycling case!

One possible remedy is a technique developed by the German
necromancers, as always. They used the NPRO cavity as a reference
cavity. They actuate the MC length at low frequency. But I don't know
the exact configuration and how they accomplished the CM hand-off. We
have to ask Hartmut.

The other possibility is your adaptive stabilization of the MC by the
FIR technique. So far I don't know how much stability you can improve
in the LIGO 4km case.

There would be many possibilities like feedforward injection from the
green arm locking signal to the MC length, etc, etc.

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.

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

1448

Wed Apr 1 10:22:13 2009

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

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

1446

Mon Mar 30 17:02:46 2009

I aligned the AP OSA, which had been mis-aligned for a while.

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

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.

1443

Mon Mar 30 12:46:36 2009

IOO QPDs were missing the beam

When I re-locked the MC, I wanted to check the trend of the IOO QPDs to see if the input beam pointing has changed.
Then I found that the QPDs were not receiving light.
The attached trend plots show that the QPDs missed the beam on March 23rd.
The IOO-QPD_ANG was installed on Mar 11th by Kiwamu and Kakeru. Since then, they were serving as a reference of the PSL beam pointing.
But there is no record of the past week. This is very bad because then I cannot tell if I should relieve the MC WFS to make the mirrors follow the input beam or not.
I found that someone has moved the beam splitter which picks up the beam going to those QPDs. But there is no elog entry on this around March 23rd.
I re-centered the beam on the QPDs.

Since the X-arm locked to TEM00 with the MC WFS on (i.e. the MC beam axis is following the input beam axis), I guessed that the input beam has not drifted that much. So I relieved the WFS and centered the WFS QPDs.

Attachment 1: IOO-QPDs.pdf

1442

Mon Mar 30 12:29:17 2009

MC1 glitches not seen during the weekend

The attached is the MC trend for the past 12 hours.
There is no MC1 glitches in the OSEM signals. Moreover, the total amplitude of the drift is smaller than it used to be (now the amplitude is less than 100 but it used to be a few hundreds).
There still is a small step in the OSEM signals at around 6AM this morning, but the amount of the jump is very insignificant.
The cause of the glitch in the TMP1, DRUM1 and APTEMP (LL, UL and UR coils respectively) at 7AM is not known.
Since the MC1 has been behaving OK during the weekend, I removed the probes from the MC1 coil driver board and locked the MC.
Hopefully the replacement of the broken connector fixed the problem, but I'm not sure.

Attachment 1: MC_drift.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?

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

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.

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

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

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.

1435

Fri Mar 27 02:40:06 2009

pete

MC glitch investigation

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.

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

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

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

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

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

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

1429

Wed Mar 25 20:41:43 2009