ELOG 40m

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

1457

Tue Apr 7 21:39:57 2009

LSC code recompiled with a fix for denormalization problem

Computers

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.

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

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.

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

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 ?

1474

Sun Apr 12 01:19:30 2009

New FE codes for suspensions not successful

Computers

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.

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

Parallel Optickle

I wrote a parallel version of tickle() function for Optickle.
The attached ptickle.m, which provides ptickle() command, can be used as a drop-in replacement of tickle() command.
Just download it and place it in the @Optickle directory.
This command will run multiple instances of Matlab to calculate the frequency responses in parallel.
The speed gain is roughly proportional to the number of CPU cores you use.

To use multiple cores, you have to run matlabpool() command first. See the comment at the beginning of ptickle.m for more detail.
The progress bar is disabled at this moment because it is not clear for me how to make a single progress bar from multiple instances of Matlab.

I sent the code to Matt, so this may be included in the next release of Optickle.

Attachment 1: ptickle.m

% Compute DC fields, and DC signals, and AC transfer functions
%
% This is a parallelized version of tickle. You have to run matlabpool(n)
% command before using this command. matlabpool(n) will invoke n instances
% of matlab workers in your computer. Once you have started those workers,
% you can reuse them many times (i.e. you don't have to run matlabpoo(n)
% every time you use ptickle). Usually n should be equal to the number of
% CPU cores in your computer, but the Matlab parallel computing toolbox has
% the limit of maximum 4 workers for a local computer. If you use a cluster 
% of computers across a network, this limit does not apply. But I haven't

... 393 more lines ...

1492

Thu Apr 16 17:48:00 2009

AutoDTT

As Peter mentioned in his entry on the last night's locking, I imported AutoDTT from Hanford.
It resides in /cvs/cds/caltech/scripts/AutoDTT/.
The main script is restoreRunSave, which takes three arguments, templete_file_name, result_file_name and log_file_name.
This script opens a template xml file and execute it. Then saves the result in the result file.
You can open the result file in a normal DTT.
You can call restoreRunSave from watch scripts, such as c1_watch_dr_bang.

watchLockLoss is a standalone watch script to detect a lock loss and call restoreRunSave.
It runs both on Linux and Solaris. However on Linux, diag fails 50% of the time with some glibc error.
So it is probably better to run it on op440m.

1493

Fri Apr 17 11:05:22 2009

Thursday night locking status

The last night, it was sort of robust to go up until arm power = 26.
The REFL_DC gain seems to change a lot around this region. So I did fine adjustments of the gain with small incremental steps of the arm power.
This work will continue.
The AutoDTT shows that the lock loss happens with an oscillation of CARM at around 100Hz. This indicates that the cross-over is the culprit.
I was also able to increase the CM UGF up to 10kHz.

1494

Fri Apr 17 11:37:32 2009

AutoDTT

In order to get test point data with AutoDTT, you have to pre-trigger test points you want to use.
This is done by starting a DTT measurement with necessary test points for a few second, then stop it but keep the DTT opened.
I made prepTP script which does this job.
It takes a file name of an XML file, which should include a DTT measurement setup with test point channels you want to open and the trigger time set to "now".
The script will open an xterm and run diag with the XML file. Unlike restoreRunSave script, it does not save the result nor quit diag. Therefore, you can keep the test points as long as you keep the xterm opened. You can manually exit the diag (Ctrl-D) when you no longer need the test points.
watchLockLoss script now calls prepTP at the beginning. Therefore, you have to be able to open an xterm. If you run the script through SSH, make sure that you give -X option to ssh.

1495

Sun Apr 19 03:34:05 2009

Tonight I was able to go up to arm power = 33, by mainly tweaking the DARM gain. A small progress.
In order to give more phase margin to the CARM MC_L path, I added a 300:100 filter to C1:LSC-MC.
To reduce the load to the lsc computer I deleted several filters from the filter bank, which were not used in the locking scripts.
Before I deleted the filters, I checked in the current chans directory into the svn repository.
If you want to restore the deleted filters, go back to the revision 36142.

1498

Mon Apr 20 05:18:42 2009

FM6 and FM10 of LSC-MC were restored

During tonight's locking work, I realized that FM6 and FM10 (both resonant gains around 20Hz) were actually activated by cm_step.
So I restored those filters from the svn history.
Instead, I removed a bunch of unused filters from LSC-DEMOD and LSC-DEMOD_A (moving zero filters) to off load c1lsc.

As for the locking itself, the DARM loop becomes unstable at around arm power = 30. I may have to add a filter to give a broader phase bubble.

1509

Thu Apr 23 16:27:24 2009

Locking with the cryo-pump

The last night, the IFO was unstabler than usual and the locking script often failed before reaching the power up stage.
The failure happened at random points.
I'm not sure if this is related to the operation of the cryo-pump.
The mode cleaner reflection image seemed to move around more than usual. Maybe it was just a high seismic night.

1510

Thu Apr 23 16:35:23 2009

restoreWatchdog script

When the IFO loses lock during the lock acquisition steps, it often kicks the MC2 (through the CM servo) and trips the watchdog.
I wrote a script to restore the tripped watchdog (/cvs/cds/caltech/scripts/SUS/restoreWatchdog).
The script takes the name of a mirror (such as MC2) as an argument.
It will enable the coils and temporarily increase the watchdog threshold to a value higher than the current OSEM RMS signals.
Then it will bring the watchdog back to the normal state and wait for the mirror to be damped. After the mirror is damped enough, the
watchdog threshold will be restored to the original value.
The script will do nothing if the watchdog is not tripped.
I put this script in the drdown_bang so that the MC2 watchdog will be automatically restored when a lock loss kicks out the MC2.

1512

Thu Apr 23 18:09:11 2009

The attached is the trend plot of the MC1 accelerometer for 3 days.
It is evident that the seismic level increased by a factor of two on Wednesday morning (when Steve started the cryopump).

Attachment 1: SeisTrend.pdf

1513

Thu Apr 23 21:13:37 2009

Mag. 4 earthquake in LA tripped the watchdogs of the most optics

Environment

So far, no damage is noticeable.
restoreWatchdog script was useful Smile

-------------------------------------------------------
Magnitude    4.0
Date-Time    * Friday, April 24, 2009 at 03:27:50 UTC
             * Thursday, April 23, 2009 at 08:27:50 PM at epicenter 
Location     33.910�N, 117.767�W
Depth	     0 km (~0 mile) (poorly constrained)
Region	     GREATER LOS ANGELES AREA, CALIFORNIA
-------------------------------------------------------

1514

Fri Apr 24 03:57:30 2009

Tonight, I was able to go up to arm power = 40 by tweaking the DARM demodulation phase.
I think the DARM loop became unstable because the demodulation phase was not right and the error signal contained some junk from I-phase.
I did not do any sophisticated demodulation phase optimization. Rather I just tweaked the phase so that the dark port image becomes stable.
I will do more careful demodulation phase tuning next time.

1515

Fri Apr 24 04:38:49 2009

Quote:

In the next try, I was actually able to go up to arm power = 70 stably.
At this power level we are ready for the RF CARM hand off.

1519

Fri Apr 24 17:26:57 2009

Quote:

There's actually code in place in the LSC to dynamically adjust the demod phase for AS1. I've never made much use of it, because it's possible to get around the problem with some gain tweaking if you start at the right phase, or because I did the DC readout handoff earlier.

Attached is a cartoon showing how the demod phase at the dark port changes as the CARM offset is decreased.

The cartoon is very nice.
I actually changed the demod phase continuously as the CARM offset was reduced to get up to arm power = 70.
As the CARM offset is changed, not only the DARM signal gain but also the phase margin around 100Hz changes if you use a fixed demodulation phase.
So it was necessary to change the demodulation phase to keep the DARM loop stable.

1520

Sat Apr 25 00:45:31 2009

Reflector for the cryopump temperature monitor changed

VAC

The temperature of the cryopump head is monitored by a photo switch looking at an aluminum foil reflector attached to the needle of the temperature gauge.
If the needle moves out of the 14K position, the photo switch will be triggered to close the cryopump gate valve.
However, this photo switch system has been touchy.
Tonight, the switch falsely tripped several times and closed the gate valve, which caused lock losses as the motion of the valve generates a lot of vibrations.
Seems to me, it was caused by the poor/irregular reflection from the wrinkled aluminum foil on the needle.
So I replaced the aluminum foil with a brand-new shiny one.

1521

Sat Apr 25 02:54:25 2009

Reflector for the cryopump temperature monitor changed

VAC

Quote:

The photo switch still trips randomly. We need a better interlock.

1522

Sat Apr 25 03:27:34 2009

Yoichi, Peter,

We are working on the final step of the lock acquisition, RF CARM hand off.
I was able to hand off the CARM error signal to RF once, but lost lock when decreasing the CARM offset to zero (it was too rapid).
I will try to make the process more robust tomorrow.

1523

Sun Apr 26 02:13:18 2009

Two more successes of RF CARM handoff

Tonight, the RF CARM hand off (mostly) succeeded twice.
But still, the IFO lost lock when I reduced the REFL_DC gain in the AO path to zero.

At the beginning of tonight's work, MICH DD hand off failed several times. This was because the the PD9 gains were set to zero.
I found that the offset script, which I called before starting the locking, fails to restore the gain values sometimes.
This happens when ezcaread fails to read the current gain. We have to be careful when running the LSCoffsets script.

1526

Tue Apr 28 04:30:16 2009

Yoichi, Peter

I believe we have succeeded in the full lock of the interferometer with the RF signals.
The lock process is reasonably robust and repeatable.

I did a scan of the RF CARM offset and plotted the arm power as a function of the CARM offset (see the attachment).
The arm power goes maximum at non-zero CARM offset. I guess the RF CARM error signal has some offset.
Maybe the demodulation phase is wrong ? I will tweak this tomorrow.
The script to do this scan can be found at /cvs/cds/caltech/scripts/CM/CARMSweep.

I haven't tried DC readout yet.

Attachment 1: Sweep1.png

1531

Wed Apr 29 04:03:51 2009

CARM RF changed to REFL_2I

Yoichi, Peter

As Rob suggested, the optimal demodulation phase is easier to find for REFL_2I than POX_1I.
Moreover, for 166MHz LO, we have a phase shifter (delay line) already installed. So we can easily change the demodulation phase of REFL_2I.
Tonight, we switched the RF CARM signal to REFL_2I.
To do so, I changed the signal going to the REFL1 input of the common mode board from POX_1I to REFL_2I.
I moved a BNC-T installed at the output of POX_1I to the REFL_2I output to split the REFL_2I signal and send it to the CM board.
Since the gain of the REFL_2I was about 20dB lower than that of POX_1I, I increased the gain of the SR560, which is installed between the REFL_2 demodulation board and the CM board, from 1 to 10.

With some gain tweaks, we were able to hand off the CARM from REFL_DC to REFL_2I. We also succeeded in switching the REFL_2I ADC channel from PD11 to PD2_DC (the output of the length path from the CM board). This switching is necessary in order to engage the boost on the CM board.

There remains some offset in the CARM when the arm power is maximized. This is expected because the REFL_2I demodulation phase is probably not exactly right.
I will optimize the demodulation phase tomorrow.

1534

Thu Apr 30 05:49:06 2009

166MHz LO phase changed

In order to optimize the REFL_2I demod phase, I changed the delay line setting for the 166MHz LO.
Right now, the delay is not yet optimal.
Since the AS166 shares the same LO, the digital demodulation phase of the AS166 had to be changed too.
The DD demod phases and the DD hand off script were also tweaked to improve the resonant condition of the central part.
Now we have more 166MHz coming out of the AS port and the SPOB is larger (more 33MHz resonant in PRC).

Since REFL166 and AS166 demodulation phases are not yet optimized, the cm_step script won't work at this moment.

1536

Fri May 1 01:32:43 2009

166MHz LO phase adjustment

I continued to adjust the REFL_2I demodulation phase.
I first optimized the demod phase for SRCL in the DRMI configuration (the error signals were DDs).
Then I restored the full IFO and offset locked it.
Before handing the DARM to RF, I adjusted the 166MHz delay line to maximize the SRCL signal at REFL_2I.
I did this before the DARM RF hand off because changing the delay line setting also changes the AS166 demodulation phase.
After this, I adjusted the digital phase shifter for AS166 to maximize the DARM signal for this port.

I also adjusted the digital demodulation phase of PD11 (REFL_2I) because the optimal demodulation phase for the initial lock acquisition is somewhat (15deg)
different from the optimal demodulation phase for the SRCL when the central part is locked with the DD signals.
This happens because the resonant condition of the central part (lock points of the recycling cavities) changes when the error signals are switched to the DD signals,
due to the offset in the DD signals. This is not good and should be fixed by the optimization of the DD demodulation phases.

Finally, I reduced the CARM offset to zero and tweaked the delay line a bit to maximize the arm power.

Right now, the locking script runs fine until the end.
At the end of the script, I was able to engage the boost on the CM board.

1541

Sun May 3 22:48:12 2009

Some measurements at the lock point

I attached some measurement results at when the IFO is at the full lock point.

The first plot shows the trend of the arm powers after the interferometer was locked.
The arm powers slowly increased after the lock. This increase is observed every time the IFO is locked.
Probably this is some sort of a thermal effect (mirror lensing, PD efficiency etc).

The second plot is a CARM offset sweep. Even after the demodulation phase optimization, the lock point is not exactly at the resonance.

The third plot is the open loop TF of the AO path. The CM loop UGF is about 20kHz.
The boost and the superboost1 were turned on when this TF was measured. The IFO loses lock if the superboost2 is turned on.

TO DO LIST
Measured the DARM loop shape.
I could not turn on the dewhitening filter for ETMY. ETMX had no trouble. I will check the dewhitening circuit.

Attachment 1: ArmPowerTrend.png

Attachment 2: CARMSweep.png

Attachment 3: CM-AO-Loop-SB1.png

1544

Tue May 5 05:16:12 2009

DC Readout and DARM response

Tonight, I was able to switch the DARM to DC readout a couple of times.
But the lock was not as stable as the RF DARM. It lost lock when I tried to measure the DARM loop gain.

I also measured DARM response when DARM is on RF.
The attached plot shows the DARM optical gain (from the mirror displacement to the PD output).
The magnitude is in an arbitrary unit.

I measured a transfer function from DARM excitation to the DARM error signal. Then I corrected it for the DARM open loop gain and the pendulum response to get the plot below.

There is an RSE peak at 4kHz as expected. The origin of the small bump and dip around 2.5kHz and 1.5kHz are unknown.
I will consult with the Optickle model.
I don't know why the optical gain decreases below 50Hz (I don't think it actually decreases).
Seems like the DARM loop gain measured at those frequencies are too low.
I will retry the measurement.

Attachment 1: DARM-TF.png

1550

Wed May 6 02:39:20 2009

HowTo

How to go to DC readout

I wrote a script called DC_readout, which you can find in /cvs/cds/caltech/scripts/DRFPMI/bang/nospring/.

Currently, the locking script succeeds 1/3 of the time. The freaky parts are the MC_F hand off and REFL_DC hand off.
MC_F hand off succeeds 70% of the time. REFL_DC goes well about a half of the time. Combined, the success rate is about 1/3.
We need some work on those hand offs.
Once you pass those freaky parts, the cm_step script usually goes smoothly and you will reach the full RF lock with the boost and the super boost1 engaged on the CM board.

To go to DC readout from there, run the DC_readout script.
First, this script will put some offset to the DARM loop so that some carrier light will leak to the AS port.
You are prompted to lock the OMC. Move the OMC length offset slider to find the carrier resonance and lock the OMC.
You have to make sure that it is carrier, not the 166MHz sideband. Usually the carrier light pulsates around 10Hz or so whereas the 166MHz SB is stable.
Once you locked the OMC to the carrier, hit enter on the terminal running the DC_readout script.
The script will do the rest of the hand off.
Once the script has finished, you may want to check darm_offset_dc in the C1LSC_LA_SET screen. This value sets the DC offset (a.k.a. the homodyne phase).
You may want to change it to what you want.

1568

Sat May 9 00:15:21 2009

Laser head temperature oscillation

After the laser cooling pipe was unclogged, the laser head temperature has been oscillating in 24h period.
The laser power shows the same oscillation.
Moreover, there is a trend that the temperature is slowly creeping up.
We have to do something to stop this.
Or Rob has to finish his measurements before the laser dies.

Attachment 1: laser.png

1575

Tue May 12 01:11:55 2009

DARM response (DC Readout)

LSC

I measured the DARM response with DC readout.

This time, I first measured the open loop transfer function of the X single arm lock.
The open loop gain (Gx) can be represented as a product of the optical gain (Cx), the filter (Fx), and the suspension response (S), i.e. Gx = Cx*Fx*S.
We know Fx because this is the transfer function of the digital filters. Cx can be modeled as a simple cavity pole, but we need to know the finesse to calculate it.
In order to estimate the current finesse of the XARM cavity, I ran the armLoss script, which measures the ratio of the reflected light power between the locked and the unlocked state. Using this ratio and the designed transmissivity of the ITMX (0.005), I estimated the round trip loss in the XARM, which was 170 ppm. From this number, the cavity pole was estimated to be 1608Hz.
Using the measured Gx, the knowledge of Fx and the estimated Cx, I estimated the ETMX suspension response S, which is shown in the first attachment.
Note that this is not a pure suspension response. It includes the effects of the digital system time delay, the anti-imaging and anti-aliasing filters and so on.

Now the DARM open loop gain (Gd) can also be represented as a product of the optical gain (Cd), the filter (Fd) and the suspension response (S).
Since the actuations are applied again to the ETMs and we think ETMX and ETMY are quite similar, we should be able to use the same suspension response as XARM for DARM. Therefore, using the knowledge of the digital filter shape and the measured open loop gain, we can compute the DARM optical gain Cd.
The second attachment shows the estimated DARM response along with an Optickle prediction.
The DARM loop gain was measured with darm_offset_dc = 350. Since we haven't calibrated the DARM signal, I don't know how many meters of offset does this number correspond to. The Optickle prediction was calculated using a 20pm DARM offset. I chose this to make the prediction look similar to the measured one, though they look quite different around the RSE peak. The input power was set to 1.7W in the Optickle model (again this is just my guess).

It looks as if the measured DARM response is skewed by an extra low pass filter at high frequencies. I don't know why is it so.

Attachment 1: SUS_Resp.png

Attachment 2: DARM_Resp.png

1576

Tue May 12 01:22:51 2009

Using the armLoss script (/cvs/cds/caltech/scripts/LSC/armLoss), I measured the round trip loss (RTL) of the arms.

The results are:
XARM: RTL= 171 (+/-2) ppm
YARM: RTL = 181 (+/-2) ppm

To get the results above, I assumed that the transmissivity of the ITMs are the same as the designed value (0.005).
This may not be true though.

1577

Tue May 12 15:22:09 2009

Quote:

It looks as if the measured DARM response is skewed by an extra low pass filter at high frequencies. I don't know why is it so.

One large uncertainty in the above estimate is the cavity pole of X-arm because I simply assumed that the ITMX reflectivity to be the designed value.
I think we can directly measure the X-arm finesse from Alberto's absolute length measurements (i.e. from the width of the resonant peaks in his scans).
By looking at Alberto and Koji's posts (elog:1244 elog:838), it looks like the FWHM of the peaks are around 3kHz. With the FSR ~ 3.8MHz, it gives a finesse of about 1300, which is reasonable.
Alberto, can you check your data and measure the FWHM more precisely ?
Note that we want to measure the FWHM of the peak in the *power* of the beat signal. The beat amplitude is proportional to the electric field *amplitude* of the transmitted auxiliary laser. What we need to get a finesse is the FWHM of the transmitted laser *power*. Thus we need to take the power of the beat signal.

1593

Sun May 17 14:35:52 2009

I found the VC1 was closed and the pressure was 4.5e-3 torr.
I tweaked the optical sensor (cryopump temperature), and opened VC1.

1660

Sun Jun 7 04:57:39 2009

Quote:

Lock acquisition is proceeding smoothly for the most part, but there is a very consistent failure point near the end of the cm_step script.

Near the end of the procedure, while in RF common mode, the sensing for the MCL path of the common mode servo is transitioned from a REFL 166I signal which comes into the LSC whitening board from the demodulator, to another copy of the signal which has passed through the common mode board, and is coming out of the Length output of the common mode board. We do this because the signal which comes through the CM board sees the switchable low-frequency boost filter, and so both paths of the CM servo (AO and MCL) can get that filter switched on at the same time.

The problem is occurring after this transition, which works reliably. However, when the script tries to remove the final CARM offset, and bring the offset to zero, lock is abruptly lost. DARM, CM, and the crossover all look stable, and no excess noise appears while looking at the DARM, CARM, MCF spectra. But lock is always lost right about the same offset.

Saturation somewhere?

I've seen this before. At that time, the problem was gone spontaneously the next day.

You could stop just before the offset reaches zero and then try to slowly reduce the offset manually to see where is the threshold.

1899

Thu Aug 13 22:53:48 2009

FSS nominal common gain changed, MC WFS centered

Koji, Yoichi

We found that the FSS PC feedback easily goes crazy (saturated).

It was because the common gain was too low. Probably the recent decrease of the

laser power is responsible for this.

We increased the nominal value of the common gain from 12 to 16.5.

The value was chosen just to make the PC path quiet. We should check

the FSS UGF later.

The MC WFS QPDs seemed off centered. So we unlocked the MC and lowered

the input power by the usual MZ half fringe technique.

Actually, the direct reflection beam was not much off the center. In anyway, we adjusted

the beam to the exact center of the QPDs.

The MC now locks fine.

1906

Fri Aug 14 15:32:50 2009

The restart procedures for the various processes running on nodus are explained here:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Computer_Restart_Procedures#nodus

Please go through those steps when you reboot nodus, or notice it rebooted then elog it.
I did these this time.

1909

Sat Aug 15 05:08:55 2009

Summary: DD hand off fails for DRFPMI.

Tonight, I did a lot of house keeping work.

(1) I noticed that the reference cavity (RC) was locked to TEM10.
This was probably the reason why we had to increase the FSS common gain.
I re-locked the RC to TEM00. Now the common gain value is back to the original.

(2) The MC WFS did not engage. I found that c1dcuepics had the /cvs/cds mounting problem.
I rebooted it. Then MC WFS started working.

(3) After checking that the MC WFS QPDs are centered for direct reflection (the MZ half fringe method),
I locked the MC and tweaked the mirror alignment (mainly MC3) to offload the WFS feedback signals.
Now the MC locks to TEM00 robustly.

(4) Since the MC mirror alignment is touchy recently, I did not like the idea of mis-aligning MC2
when you do the LSC PD offset adjustment. So I modified the LSCoffset script so that it will close
the PSL shutter instead of mis-aligning MC2.

(5) I changed the PD11_Q criteria for success in the alignment scripts because PD11_Q is now lower
than before due to the lower laser power.

(6) Since today's bootfest, some epics values were not properly restored. Some of the PD gains were
unmatched between I and Q. I corrected these with the help of conlog.

(7) By checking the open loop TFs, I found that the short DOFs have significantly lower UGFs than before,
probably due to the lower laser power. I increased the gains of MICH, PRCL and SRCL by a factor of 2 for
the full configuration.
For the DRM configuration the changes I made were:

PRC -0.15 -> -0.3
SRC 0.2 -> 0.6
MICH 0.5 -> 0.5

(8) I locked the DRFPMI with arm offsets, then adjusted the demodulation phases of PD6,PD7,PD8 and PD9 (DD PDs)
to minimize the offsets in the error signal, while locked with the single demodulation signals.

Change log:
PD6_PHASE 201 -> 270
PD7_PHASE 120 -> 105
PD8_PHASE 131 -> 145
PD9_PHASE -45 -> -65

(9) I ran senseDRM to get the sensing Matrix for the short DOFs using DD signals in DRM configuration.

(10) Still the DD hand off fails for DRFPMI. It succeeds for DRM.

1916

Mon Aug 17 02:12:53 2009

Rana, Yoichi

All the FE computers went red this evening.
We power cycled all of them.
They are all green now.

Not related to this, the CRT display of op540m is not working since Friday night.
We are not sure if it is the failure of the display or the graphics card.
Rana started alarm handler on the LCD display as a temporary measure.

1917

Mon Aug 17 04:16:13 2009

Reference cavity reflection looks bad

Quote:

Rana, Yoichi
- We also moved the Refcav reflection camera to look at the leakage through a reflection steering mirror so that there's less chance of distortion. There was previously a W1 window in there as a pickofff. Also changed the camera to autogain so that we can see something.

- Re-aligned onto the refl pd.

- Tweaked alignment into RC. Mainly in yaw. Transmission went from 5V to 7V. In your face, Aso!

After our removal of the pick off window and Rana's re-alignment of the beam into the RC, the RC optical gain increased.
FSS was complaining about it by driving the PC feedback crazy.
I reduced the nominal common gain from 12.5dB to 11dB.

1923

Tue Aug 18 14:24:43 2009

Reference Cavity Inspection

Rana, Koji, Yoichi

To see why the reflected beam from the RC is distorted, we took out
the periscope and the iris in front of the RC. The periscope mirrors
had some gunk and dusts on them. We blew nitrogen air onto them to
remove the dust. Since the gunk did not come off with the air, we
wrapped a Q-tip with lens cleaning paper soaked in Methanol, and wiped
the surface of the mirrors. We did this because it was hard to remove
the mirrors from the periscope (they were in a spring loaded mirror
holders. The springs were too strong to safely remove them without
damaging the mirrors).

Looking into the RC from the front mirror revealed nothing obstructing
in the path.

After the cleaning, we put the periscope back and observed the direct
reflection from the cavity (not locked). It was still distorted
exactly like before.

So we did some tests.
First we injected He-Ne to the RC. It turned out that multiple
reflections from the optical window (not AR coated for He-Ne) made it
almost impossible to investigate anything with He-Ne. But this
observation made us to suspect maybe one side of the window is not AR
coated.

We placed the periscope about 50cm away from the RC and injected the
beam from an angle, so that we can observe the direct reflection.

First, we checked the shape of the beam leaving the periscope. It was good.
We then observed the reflected beam from the RC. It was also good, no distortion.
We made sure that it was really the reflection from the mirror, not from the window
as follows.
We measured the separation between the in coming beam to the cavity and the reflected beam
at two locations. From this, we can guess where the two beams intersect (the reflection point).
The estimated reflection point was far inside the RC enclosure, indicating that it was really
reflection from the front mirror of the RC.
Since we did not see any other reflection beam, we concluded that the AR coating of the window
is good.

We checked the direct reflection beam shape with several different incident angles, but the
beam shape was always good.

We put back the periscope to the original position. This time, we put a high reflectivity mirror
after the output mirror of the periscope. The beam coming out of the circulator (PBS) had a good
circular shape. But still if we let the beam reflected by the cavity, the beam shape is distorted.
Something must be happening in the RC. Unfortunately, we could not figure out what it is.

We put everything back to the original configuration, except for the iris, and the RC alignment
was already good (surprise). After Koji's final tweak, the FSS is now doing fine, but still
the reflected beam is ugly.

1934

Fri Aug 21 17:49:47 2009

Upgrade FE conceptual plan

Computers

I started to draw a conceptual diagram of the upgraded FE system.
http://nodus.ligo.caltech.edu:30888/FE/FE-Layout.html
(It takes some time to load the page for the first time)

Some places, tips will pop up when you stop the cursor over an object.
You can also click on the LSC block to see inside.

This is just a start point, so we should add more details.
The source of the diagrams are in the svn:
https://nodus.ligo.caltech.edu:30889/svn/trunk/docs/upgrade08/FE/

I used yEd (http://www.yworks.com/en/products_yed_about.html) to make
the drawings. It is Java, so works on many platforms.

Attachment 1: Picture_2.png

1941

Tue Aug 25 03:30:23 2009

Green lock and phase noise

WIKI-40M Update

While Koji and I were discussing about the green laser lock, we wondered if the common motion of the cavity mirrors,
which won't be suppressed by the green laser servo, will cause any problem to the locking.

Since the common motion of the cavity mirrors is equivalent to the change of the path length from the laser to the
input mirror, it will show up as a phase noise in the error signal.
Unfortunately, since we inject the green laser from the end mirror, this phase noise has opposite sign for the
PSL and the green laser.

I calculated the magnitude of the phase noise using an extremely rough estimate of the common motion of the mirrors.
It is explained in the 40m wiki.
http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/GreenLock

The result plot is attached.
(Probably the seismic noise I used is an over estimate.)

Attachment 1: PhaseNoise.png

1955

Thu Aug 27 12:34:48 2009

Last night, I tried to run locking scripts.
The power went up to 70 a couple of times .
Then it failed to switch to RF CARM.
I was too tired at that time to figure out what is the problem with the switching.
But it seemed to me that the problem could be solved by some gain tweaking.
Looks like the IFO is back to a good state.

1959

Fri Aug 28 12:56:17 2009

RF CARM hand off problem

Last night, the lock script proceeded to the RF CARM hand-off about half of the time.
However, the hand off was still unsuccessful.

It failed instantly when you turn on the REFL1 input of the CM board, even
when the REFL1 input gain was very low, like -28dB.

I went to the LSC rack and checked the cabling.
The output from the PD11_I (REFL_2) demodulation board is split
into two paths. One goes directly to the ADC and the other one goes
to an SR560. This SR560 is used just as an inverter. Then
the signal goes to the REFL1 input of the CM board.

I found that the SR560 was set to the A-B mode, but B input was open.
This made the signal very noisy. So I changed it to A only mode.
There was also a 1/4 attenuator between the PD11_I output and the SR560.
I took it out and reduced the gain of SR560 from 10 to 2.
These changes allowed me to increase the REFL1 gain to -22dB or so.
But it is still not enough.

I wanted to check the CM open loop TF before the hand-off, but I could
not do that because the lock was lost instantly as soon as I enabled the
test input B of the CM board.
Something is wrong with the board ?

Using the PD11_I signal going into the ADC, I measured the transfer functions
from the CM excitation (digital one) to the REFL_DC (DC CARM signal) and PD11_I.
The TF shapes matched. So the PD11_I signal itself should be fine.

We should try:
* See if flipping the sign of PD11_I signal going to REFL1 input solve the problem.
* Try to measure the CM analog TF again.
* If the noise from the servo analyzer is a problem, try to increase the input gains
of the CM board and reduce the output gain accordingly, so that the signal flowing
inside the CM board is larger.

3427

Mon Aug 16 23:39:29 2010

SUS

More TT characterization

Quote:

Things we noticed: Koji and I had been concerned the last time we were looking at TT#2 because the frequency got lower and the Q seemed to get higher when we added the damping to the vertical blades. Yoichi and I did not find that to be true today. We did notice, however, that the EQ stop screws with the viton had been placed in the holes closer to the clamping point, whereas with TT #4 the screws had been placed in the holes farther from the clamping point. We moved the screws on TT #2 to the outer holes, and noticed that the frequency increased slightly, and the Q significantly decreased. We then followed this outer-hole philosophy when installing screws in TT #3.

The inner and outer screw holes of the EQ stop Jenne is talking about are shown in the photo below.

3428

Tue Aug 17 02:07:11 2010