40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 231 of 344  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  1365   Fri Mar 6 15:23:39 2009 YoichiUpdateLockingLocking distracted by the QPD whitenning problem again
By looking at the time series of DARM signal at the time of a lock loss, the oscillation frequency was about 3.5kHz (see the attm1 and its zoomed version attm2).
I will measure the DARM loop gain around this frequency next.


Quote:
Tonight, I was able to ramp up the arm power to around 20. Then the DARM loop started to oscillate and the IFO lost lock in a few seconds.
I repeated this several times, then realized that the transmission QPDs were not working properly again due to the well known sticky slider problem.
I should have run slider_twiddle script. Since the DARM RF signal is normalized by the sqrt(TRX+TRY), it is reasonable that the DARM loop got unstable.

The fact that I was able to go up to arm power = 20 means there is nothing saturating below this power level.
Attachment 1: lockLoss3.pdf
lockLoss3.pdf
Attachment 2: lockLoss3-zoom.pdf
lockLoss3-zoom.pdf
  1382   Tue Mar 10 04:55:41 2009 YoichiUpdateLockingLocking: 3.7kHz large oscillation
Yoichi, Jenne, Alberto,

As I reported on the last Thursday, there is a large oscillation in CARM and DARM error signals (attm1).
I put notch filters (3.75kHz, Q=10, 30dB) in the CARM and DARM loops. This let us go up to the arm power of more than 20 and stay there for a while.
The dashed curves in the attm1 are the spectra when the notches are off, and the solid curves are when the notches are used.
We could somewhat suppress the DARM peaks but not CARM.
Of course this is clearly not a good solution. We should find the cause of the oscillation and kill it.

Attm2 is the spectrum of the PO_DC signal flowing in the CM board measured by the SR785. More specifically, CH1 is TP1A and CH2 is TP2A of the CM board.
This was taken right after the AO path was engaged. At this stage, the AO path gain is very low. But you can already see a seed of the oscillation in the spectrum.

Attm3 shows the same spectra taken after the arm power is increased to 4 but before the PO_DC hand off. You can see large peaks around 3.75kHz.
After this, the peaks grow as the power goes up.

Attm4 is the loop gain of the AO path after the PO_DC hand off (arm power = 4).
Attm5 is the zoom of the same TF around 3.7kHz. Clearly there is something wrong at this frequency. We should check the CM board and the MC board as well as the SPOB PD.

One time I was able to go up to arm power = 27 or so. At this power level, the DARM loop started to oscillate, probably, around the UGF.
However because of the 3.7kHz problem, we can't stay at this power level long enough to make diagnostic measurements (like open loop TF).
We should tackle the 3.7kHz issue first.
Attachment 1: CARM_DARM_Spectra.pdf
CARM_DARM_Spectra.pdf
Attachment 2: PODC_Spe_AOPath_Engaged.png
PODC_Spe_AOPath_Engaged.png
Attachment 3: PODC_Spe_before_PODC_handoff.png
PODC_Spe_before_PODC_handoff.png
Attachment 4: AOGain3.png
AOGain3.png
Attachment 5: AOGain2.png
AOGain2.png
  1388   Wed Mar 11 16:53:48 2009 YoichiUpdateLockingJunks in around kHz
Rana, Yoichi

Last night, we tried to find out the source of the kHz region peaks in the DARM and CARM error signals.
These peaks are also present in the error signal of the single arm locking by RF (both X and Y).
The attachment 1 shows spectra of MC_F and XARM error signal when XARM is locked by the POX PDH signal.
There is a sharp peak at 3.8kHz in MC_F. This peak was there in a reference spectrum taken on June 24 2008.

In the XARM error signal, there is also a broad peak around 3.8kHz. This peak moves between 3.75kHz and 3.8kHz from time to time.
(the brown curve was taken when the peak moved to 3.75kHz).
Also there is a notch like structure at 3.8kHz in the XARM error spectrum. Looks like the peak in the MC_F is creating a notch here, but
no idea why.

We tapped on the PSL table, the end chambers and the SPOB table and looked at the spectra to see if there is any change.
Rana also developed a cool Walkie-Talkie excitation technique, where he put one of the walkie-talkies on the PSL table by the MZ and yelled at the other one while looking at a DTT screen in the control room.
None of these had any effect on the XARM error, while MC_F responded to the disturbances.

We also turned on and off the steering mirror PZT closed loop buttons, moved the PMC, MZ and the ISS gain sliders and changed the MC gain, offset.
Nothing affected the XARM error.

Osamu found old spectra of the XARM signal (attm2). The legends say DARM but these are XARM signals.
Almost the same structures can be seen including the notch at 3.8kHz. Seems like it's been like this for long time.

We should check, RF-AM, MC coil dirivers, Piezo-Jena noise etc.
Attachment 1: MC_F-XARM.pdf
MC_F-XARM.pdf
Attachment 2: old-xarm.pdf
old-xarm.pdf
  1390   Wed Mar 11 22:57:48 2009 YoichiUpdateLockingCalibrated XARM error signal spectrum
I did a rough calibration of the XARM error spectrum.
See the attached calibrated spectrum.

I started from this Rana's elog entry.
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

I first injected a 20Hz sin signal into C1:SUS-ETMX_LSC_EXC and measured the response to the ETMX SUSPOS.
Using the calibration of the SUSPOS given in the above entry, I calibrated the ETMX coil actuation efficiency.
It was 3.4e-12 m/cnt @20Hz for C1:SUS-ETMX_LSC_EXC.

Then I locked the X-arm and injected a calibration peak at 20Hz.
From the ratio of the peaks in C1:SUS-ETMX_LSC_IN2 and C1:LSC-XARM_IN1, I calibrated the X-arm error signal to be 4.2e-13 m/cnt.
We have to also take into account the cavity pole of the arm, 1525Hz (the design value, may not be actual).
So I used the following calibration in the DTT:

G: 4.2e-13
P: 1525
Z:

Note that the attached spectrum shows the actual motion of the X-arm (or equivalent frequency noise) after suppressed by the feedback servo,
unlike conventional noise spectra showing "virtual" displacement which would have been induced in the absence of servos.
Attachment 1: XarmErrorSpeCalibrated.pdf
XarmErrorSpeCalibrated.pdf
  1393   Thu Mar 12 02:18:42 2009 YoichiUpdateLockingMC_I spectra (RF_AM)
I took several spectra of MC_I signal (see attm1).

The blue curve is when the MC was locked. The green curve (RF_AM) shows the MC_I spectrum when the MC is unlocked and MC2 is mis-aligned,
so that no resonance should happen. The brown curve is when the PSL shutter was closed (dark noise).
There are some structures in the green curve but not at 3.8kHz.

The second attachment compares the MC_I spectrum (the same as the green one in the first attachment) with the Xarm error signal.
Of course these two spectra were taken at different times.

Some of the peaks in the X-arm error signal seem to be coming from the MC RF_AM.
Attachment 1: MC_I_Spe.png
MC_I_Spe.png
Attachment 2: MC_I-Xarm.png
MC_I-Xarm.png
  1399   Fri Mar 13 05:16:21 2009 YoichiUpdateLockingLocking update
Yoichi, Osamu,

With adjustments of the loop gains during the CARM offset reduction, the IFO reaches arm_power = 25 sort of robustly unless the 3.8kHz oscillation rings up.
At arm_power = 25, the CARM and DARM start to oscillate at around 400Hz. Probably I need more gain tweaks.
Annoying thing is that the 3.8kHz oscillation sometimes rings up suddenly and kills the lock.
This can happen anywhere above arm_power = 6 or so.
Because of a strange structure in the CARM loop gain around 3.8kHz, we cannot increase the CARM UGF beyond 1kHz.
The attached plots are the AO path open loop transfer function (attm2 is the zoom of attm1) measured at arm_power = 13.

Tomorrow, I will lock the X-arm and measure the transfer function from the AO path input to the X-arm error signal to see
if there is the same structure at 3.8kHz (X-arm error signal has the 3.8kHz peak).
Attachment 1: AOTF2.png
AOTF2.png
Attachment 2: AOTF2-zoom.png
AOTF2-zoom.png
  1402   Fri Mar 13 22:07:14 2009 YoichiUpdateLockingCalibrated XARM error signal spectrum
Of course I made a mistake.
I put a pole at 1525Hz whereas it should have been a zero.

The correct calibration factor is:
G: 4.2e-13
P:
Z: 1525

I attached a revised spectrum.


Quote:
I did a rough calibration of the XARM error spectrum.
See the attached calibrated spectrum.

I started from this Rana's elog entry.
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

I first injected a 20Hz sin signal into C1:SUS-ETMX_LSC_EXC and measured the response to the ETMX SUSPOS.
Using the calibration of the SUSPOS given in the above entry, I calibrated the ETMX coil actuation efficiency.
It was 3.4e-12 m/cnt @20Hz for C1:SUS-ETMX_LSC_EXC.

Then I locked the X-arm and injected a calibration peak at 20Hz.
From the ratio of the peaks in C1:SUS-ETMX_LSC_IN2 and C1:LSC-XARM_IN1, I calibrated the X-arm error signal to be 4.2e-13 m/cnt.
We have to also take into account the cavity pole of the arm, 1525Hz (the design value, may not be actual).
So I used the following calibration in the DTT:

G: 4.2e-13
P: 1525
Z:

Note that the attached spectrum shows the actual motion of the X-arm (or equivalent frequency noise) after suppressed by the feedback servo,
unlike conventional noise spectra showing "virtual" displacement which would have been induced in the absence of servos.
Attachment 1: XarmErrorSpeCalibrated.pdf
XarmErrorSpeCalibrated.pdf
  1419   Tue Mar 24 03:05:25 2009 YoichiUpdateLockingLocking tonight
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.
  1426   Wed Mar 25 04:18:28 2009 YoichiUpdateLockingTuesday Locking
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
AO-Loop-p9.png
  1433   Thu Mar 26 04:27:26 2009 YoichiUpdateLocking3.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
CARM-PODC.pdf
  1436   Fri Mar 27 02:50:54 2009 YoichiUpdateLockingDD 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.
  1449   Wed Apr 1 15:47:48 2009 YoichiUpdateLocking3.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
CARM-ETM-EXC.png
Attachment 2: AOpath-TFs.png
AOpath-TFs.png
  1450   Wed Apr 1 16:14:36 2009 YoichiUpdateLocking3.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.
  1454   Fri Apr 3 17:20:05 2009 YoichiUpdateLockingThe 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
AO-TF-DARM-OFFSET.png
Attachment 2: AO-TF-DARM-DEMOD-PHASE.png
AO-TF-DARM-DEMOD-PHASE.png
Attachment 3: AO-TF-MICH-OFFSET.png
AO-TF-MICH-OFFSET.png
Attachment 4: POX_1I.png
POX_1I.png
Attachment 5: DARM-Loop.pdf
DARM-Loop.pdf
  1458   Wed Apr 8 02:47:42 2009 YoichiUpdateLockingLocking status
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
CARM_TFs.pdf
Attachment 2: DARM_TFs.pdf
DARM_TFs.pdf
Attachment 3: DARM-CARM-Coupling.pdf
DARM-CARM-Coupling.pdf
  1463   Thu Apr 9 12:23:49 2009 peteUpdateLockingtuning 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
FPMI-DARM-CARM-ETM-fineScan.pdf
  1465   Thu Apr 9 23:11:27 2009 robSummaryLockingLaser PM to PO-DC transfer functions at multiple CARM offsets

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.

 

Attachment 1: CARMoffs1.png
CARMoffs1.png
Attachment 2: CARMoffs2.png
CARMoffs2.png
Attachment 3: CARMcarpet.png
CARMcarpet.png
  1466   Thu Apr 9 23:20:35 2009 robSummaryLockingLaser 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
CARMoffs1_r.png
Attachment 2: CARMoffs2_r.png
CARMoffs2_r.png
Attachment 3: CARMcarpet_r.png
CARMcarpet_r.png
  1468   Fri Apr 10 03:10:08 2009 ranaSummaryLockingLaser 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

  1469   Fri Apr 10 04:54:24 2009 YoichiUpdateLockingREFL_DC for CARM
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
AO-loop-gain-CARM-REFL_DC.png
  1480   Tue Apr 14 02:59:02 2009 YoichiUpdateLockingPower up until 26
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.
  1489   Thu Apr 16 16:26:57 2009 peteUpdateLockingWed. night locking
yoichi, pete

We installed the watchLockLoss script in scripts/AutoDTT/.  This script monitors arm power and uses command line
DTT to save 5 s snapshot of the interferometer when it senses loss of lock.  We ran it on linux and it seemed to
save an xml file about half the time; we'll try it on solaris.  

I managed to get up to arm power of about 20 a couple of times.  IFO lost lock a couple of times after turning
off moving zero.  MC2 would often get tripped by lock loss and need resetting.  Maybe we will try to stiffen the
op levs.
  1493   Fri Apr 17 11:05:22 2009 YoichiUpdateLockingThursday 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.
  1495   Sun Apr 19 03:34:05 2009 YoichiUpdateLockingSaturday night lock
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 YoichiConfigurationLockingFM6 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.
  1500   Mon Apr 20 18:17:44 2009 robSummaryLockingCARM offset/Power rubric

Plotted assuming the average arm power goes up to ~80.  No DARM offset.

Attachment 1: ARMpowersCARM.png
ARMpowersCARM.png
  1509   Thu Apr 23 16:27:24 2009 YoichiUpdateLockingLocking 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.
  1514   Fri Apr 24 03:57:30 2009 YoichiUpdateLockingDARM demod phase
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 YoichiUpdateLockingDARM demod phase

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


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.
  1516   Fri Apr 24 11:34:32 2009 robUpdateLockingDARM demod phase

Quote:

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


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.


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.
Attachment 1: darm_phase_rotate.png
darm_phase_rotate.png
  1519   Fri Apr 24 17:26:57 2009 YoichiUpdateLockingDARM demod phase

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.
  1522   Sat Apr 25 03:27:34 2009 YoichiUpdateLockingLocking status
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 YoichiUpdateLockingTwo 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 YoichiUpdateLockingRF full lock
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
Sweep1.png
  1529   Tue Apr 28 16:36:24 2009 robHowToLockingsetting the RF CARM demod phase

To set the demod phase for RF CARM, sensed at REFL2 (REFL 166I), it suffices to set the demod phase for REFL2 to be the optimal phase for controlling SRCL in a no-arm state.

Attachment 1: CARM_phases_REFL.pdf
CARM_phases_REFL.pdf CARM_phases_REFL.pdf CARM_phases_REFL.pdf CARM_phases_REFL.pdf
Attachment 2: SRCL_phases_REFL.pdf
SRCL_phases_REFL.pdf SRCL_phases_REFL.pdf SRCL_phases_REFL.pdf SRCL_phases_REFL.pdf
  1530   Tue Apr 28 17:51:13 2009 robHowToLockingsetting the RF CARM demod phase

Quote:

To set the demod phase for RF CARM, sensed at REFL2 (REFL 166I), it suffices to set the demod phase for REFL2 to be the optimal phase for controlling SRCL in a no-arm state.

 

For POX33, the ideal phase for single arm locking does not yield a zero-offset CARM signal.  So the offset needs to be manipulated digitally. 

Attachment 1: XARM_phases_POX.pdf
XARM_phases_POX.pdf XARM_phases_POX.pdf XARM_phases_POX.pdf XARM_phases_POX.pdf
Attachment 2: CARM_phases_POX.pdf
CARM_phases_POX.pdf CARM_phases_POX.pdf CARM_phases_POX.pdf CARM_phases_POX.pdf
  1531   Wed Apr 29 04:03:51 2009 YoichiUpdateLockingCARM 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.
  1533   Wed Apr 29 15:56:43 2009 robUpdateLockingeffect of SRCL detune on ARM powers in a CARM sweep

With no DARM offset, sweeping CARM shows an asymmetry between the state where we lock to a DARM spring and the state with a DARM anti-spring.  This is why we have a link between the DARM and CARM optical springs. 

For each DARM detune direction (positive or negative, spring or anti-spring), there is only one CARM direction which can yield a DC-based error signal lock with a CARM offset but no DARM offset, which is what we want.

Attachment 1: CARMsweep_DARMspringnospring.png
CARMsweep_DARMspringnospring.png
  1534   Thu Apr 30 05:49:06 2009 YoichiUpdateLocking166MHz 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.
  1535   Thu Apr 30 15:10:54 2009 robUpdateLockingCARM RF changed to REFL_2I

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



From Optickle simulations, it looks like the SRCL/CARM gain ratio at REFL I2 is about 8e-4. So a 1 nanometer offset in SRCL yields 0.8 picometers of offset in CARM.
  1536   Fri May 1 01:32:43 2009 YoichiUpdateLocking166MHz 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.
  1537   Fri May 1 10:04:10 2009 robUpdateLocking166MHz LO phase adjustment

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



Awesome. Up next: dewhitening.
  1541   Sun May 3 22:48:12 2009 YoichiUpdateLockingSome 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
ArmPowerTrend.png
Attachment 2: CARMSweep.png
CARMSweep.png
Attachment 3: CM-AO-Loop-SB1.png
CM-AO-Loop-SB1.png
  1544   Tue May 5 05:16:12 2009 YoichiUpdateLockingDC 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
DARM-TF.png
  1545   Tue May 5 08:26:56 2009 robUpdateLockingDC Readout and DARM response

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


The optical gain does decrease below ~50Hz--that's the optical spring in action. The squiggles are funny. Last time we did this we measured the single arm TFs to compensate for any tough-to-model squiggles in the transfer functions which might arise from electronics or the suspensions.
  1548   Tue May 5 11:44:33 2009 robUpdateLocking DARM response

Here's the RF DARM optical response, on the anti-spring side, from optickle. Note that for the f1 sideband, changing the demod phase mostly adjusts the overall gain, while for the f2 sideband a change in demod phase alters the shape of the response. This is the quadrature-selecting power of using a single RF sideband as a local oscillator.
Attachment 1: DARMtf_nospring.png
DARMtf_nospring.png
Attachment 2: DARMtf_demodphases.png
DARMtf_demodphases.png
  1550   Wed May 6 02:39:20 2009 YoichiHowToLockingHow 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.
  1557   Thu May 7 18:12:12 2009 peteUpdateLockingarm power curve

I've plotted TRX, TRY, PD12I and PD11Q.  Arm powers after locking increase for a few tens of minutes, peak out, and then decrease before lock is lost.

 

 

Attachment 1: 2009_may_7_powers.jpg
2009_may_7_powers.jpg
  1558   Thu May 7 23:21:04 2009 peteUpdateLockingarm power curve

Quote:

I've plotted TRX, TRY, PD12I and PD11Q.  Arm powers after locking increase for a few tens of minutes, peak out, and then decrease before lock is lost.

 

 

 I should have mentioned that the AS port camera image seems to get progressively uglier over the course of these locks.  Maybe we can use the JoeCam to make a movie of it. 

  1560   Fri May 8 02:08:59 2009 peteUpdateLockinglock stretches

locks last for about an hour.  this was true last night as well (see "arm power curve" entries).   the second lock shown here evolves differently for unknown reasons.  the jumps in the arm powers of the first lock are due to turning on DC readout.  length-to-angle needs tuning.

 

 

Attachment 1: powers_oplev.pdf
powers_oplev.pdf
ELOG V3.1.3-