40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 228 of 341  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  630   Thu Jul 3 13:12:32 2008 Rob, Yoichi, JohnUpdateLockingMore oscillations
Bounce/ roll filters were added to the short degrees of freedom to reduce the effect of the 24Hz line seen on Tuesday night.

However last night saw the arrival of a new oscillation at ~34Hz. This may be the second harmonic of the MOS roll mode. Reducing the arm offset would cause this oscillation to ring up and break the lock (first plot). This effect was repeatable.

No signal was seen in the oplevs or osems which leads us to rule out alignment problems, at least for now.

Although one can clearly see DARM_ERR increasing as arm power increases adding a resonant gain in the DARM loop had no effect.

We also noticed that x arm transmission was significantly more noisy than the Y (second plot). And showed greater coherence with the increase in DARM noise. Investigations showed that the PD was not the source of the difference.

Turning up the MC gain seems to help a little.

We're now looking at POX as a candidate for RF_CARM (third plot).
  632   Thu Jul 3 16:18:51 2008 robSummaryLockingspecgrams
I used ligoDV to make some spectrograms of DARM_ERR (1), QPDX (2), and QPDY (3). These show the massive instability from 30-40Hz growing in the XARM in the last two minutes of a reasonably high power lock (arm powers up to 30). It's strange that it only shows up in one arm.

CARM is on PO-DC, for both the MCL and the AO path.
DARM is on AS166Q.
  651   Wed Jul 9 12:42:14 2008 JohnUpdateLockingHand off to RF CARM
Rob, Yoichi, John

Last night we were able to reduce the CARM offset to around 80. This was achieved by increasing the DARM gain and
switching to AS_I when AS_Q went bad. This is probably a temporary solution, we will probably switch to DC readout
for DARM as we bring the arms on resonance.

Having reduced the arm offset enough to get us into the linear region of the RF_CARM signal (POX_I) we worked on
analogue conditioning of this signal to allow us to hand over. Lock was maintained for over 20 minutes as we did
this work.

We were able to partially switch over both the frequency and length paths to this new signal before losing lock.
  655   Thu Jul 10 14:59:01 2008 robUpdateLockingRF common mode at zero offset
rob, john, yoichi

Last night we succeeded in reducing the CARM offset to zero.

We handed off control of the common mode servo from PO-DC to POX-I.

We pushed the common mode servo bandwidth to ~19kHz. Without the boosts, it had ~80 degs of phase margin. Didn't measure it after engaging the boosts (Boost + 1 superboost). Trying to engage the second superboost stage broke the lock.

The process is fully scripted, and the script worked all the way through several times.

The DARM ugf was ~200Hz. The RSE peak could clearly be seen. No optical spring, as expected (we're locking in anti-spring mode).

Engaging test mass de-whitening filters did not work (broke the lock).

I'm attaching a lock control sequence diagram and a trend of the arm power during a scripted up-sequence. I think the script can be sped up significantly (especially the long ramp period).

Up next:

Calibrated DARM spectrum
Noise hunting (start with dewhites)
DC - Readout
Lock to the springy side.
  661   Fri Jul 11 23:55:25 2008 alanUpdateLockingRF common mode at zero offset

Quote:
rob, john, yoichi

Last night we succeeded in reducing the CARM offset to zero.



Congratulations! Well done! I look forward to hearing the details and further progress!
  675   Tue Jul 15 12:44:08 2008 JohnSummaryLockingDRFPMI with DC readout
Rob, John

Last night, despite suspect alignment, we were again able to reduce the CARM offset to zero using
the RF signal.We were also able to transfer to dc readout taking calibrated spectra in both states.
DC readout shows a marked improvement over RF above ~1kHz but introduces some noise around 100Hz.
Broadband sensitivity appears to be more than ten times worse than previously. The calibration
being used remains to be confirmed.

Engaging the ETMY dewhitening caused lock to be lost. We'll check this today. The OMC alignment loops
may also need some attention.

We looked at REFL_166 as a candidate for CARM, at present POX still looks better.

The DARM filters were modified to reduce excess noise around 3Hz. Updating filter coefficients does
not cause loss of lock.
  732   Thu Jul 24 03:08:20 2008 robUpdateLocking+f2 DRMI+2ARMS

rob, john, yoichi

Tonight we tried to move the 166MHz (f2) sideband frequency by changing the settings on the Marconi. Reducing the frequency by 4kHz reduced the amplitude of the 166MHz sidebands, but we were still able to lock the DRMI with the +-f2 sidebands by electronically compensating for the gain decrease, and also to lock the DRMI+2ARMs while resonating the -f2 sideband. No luck with the +f2.

Then we larkily tried increasing the frequency by 4kHz, which ~doubled the f2 sideband transmission through the MC. This means our frequencies/MC length have been mismatched for months. Apparently I explained the level of the f2 sidebands by just imagining that I'd (or someone) had set the modulation depth at that level some time in the past.

It's a miracle any locking worked at all in this state. Once this was done and we worked out a few kinks in the script, adjusting some gains to compensate, we managed to get the DRMI+2ARMS to lock a couple of times while resonating the +f2 sideband. It takes a while, but at least it happens. Tomorrow we'll measure the length of the mode cleaner properly and then try again. No need to vent just yet.
  848   Mon Aug 18 17:37:14 2008 robUpdateLockingrecovery progress

I removed the beam block after the PSL periscope and opened the PSL shutter.

There was no MC Refl beam on the camera, so I decided to trust the PSL launch
and aligned the MC to the PSL beam. Here are the old and new values for
the MC angle biases:
 __Epics_Channel_Name______   __OLD_____    ___New___
 C1:SUS-MC1_PIT_COMM          4.490900        3.246900 
 C1:SUS-MC1_YAW_COMM          0.105500	      -0.912500
 C1:SUS-MC2_PIT_COMM          3.809700	      3.658600 
 C1:SUS-MC2_YAW_COMM          -1.837100	      -1.217100
 C1:SUS-MC3_PIT_COMM          -0.614200	      -0.812200
 C1:SUS-MC3_YAW_COMM          -3.696800	      -3.303800

After this, the beam looks a *little low* going into the Faraday Isolator.
Nonetheless, after turning on the IFO input steering PZTs, I was able to
quickly steer the PRM get a beam on the REFL camera and into the REFL OSA.
The PRM optical lever beam is also striking the quad.

I then used the ETMX optical lever as a reference for realigning. After
steering around the input PZTs and ITMX, I saw some flashes in Xarm trans, then got
it locked and ran the alignment script ~5 times. The arm power went
up to 0.9, so I tweaked the MC1 to put the MC refl beam back on MCWFS.
The XARM power then went up to .96. Good enough for now.

Then I started to try and re-align the YARM. Since the oplevs for both ITMY
and the BS are untrustworthy, I first tried to get the beam bouncing off ITMX
and the BS back into the AS OSA, to try and recover some BS alignment. This
didn't work, as the AS OSA may not be a good reference anyways. After
wandering around in the dark for a little while, I decided to try an automated
scan of the alignment space. I used the trianglewave script to scan
the angle biases of BS, ITMY, & ETMY, then looked at the trend of the transmitted
power to find the gps time when there were flashes. I then used
time_machine_conlog to restore the biases to that time. This was close
enough to easily recover the alignment. After several rounds of aligning &
centering oplevs, things look good.

Also locked a PRM. Will work on the DRM tomorrow.

I'm leaving the optics in their "aligned" states over night, so they can
start their "training."

Note: The MC is not staying locked. Needs investigation.

For tomorrow:

lock up the DRM
fix the mode cleaner
re-align mode cleaner to optimize beam through Faraday
re-align all optics again (will be much easier than today)
re-align beam onto all PDs after good alignment of suspended optics is established.
  862   Wed Aug 20 13:23:32 2008 robUpdateLockingDRMI locked

I was able to lock the DRMI this afternoon. All the optical levers have been centered.
  953   Wed Sep 17 12:58:12 2008 robUpdateLockingbad

Locking was pretty unsuccessful last night. All the subparts were locked (ARMs, PRM, DRM) and
aligned, but no DRMI+2ARMs locks. The alignment may have drifted significantly by the time I
got around to working the full shebang, however.

We should get back into the habit of clicking the
yellow "Restore last auto-alignment" button when we finish using the interferometer.
  985   Tue Sep 23 13:25:07 2008 robUpdateLockinga bit better
I've been spending time working on the short DOF loops (PRC,MICH,SRC) in an attempt to make the
initial stage of lock acquisition (the DRMI+2ARMs, no spring) better. This seems to have been
largely successful, as last night there were several locks of the DRMI+2ARMs with pretty short
wait times.

The output matrix for the short DOFs is a bit strange, though. The MICH->PRM element is about
3 times too small, which seems to indicate something broken in hardware. The MICH->SRM element
seems normal, though, which suggests the BS is isn't broken--either the PRM has had a sudden
actuation increase or it's a problem with the sensing.
  998   Fri Sep 26 16:08:39 2008 robUpdateLockingsome progress
There's been good progress in locking the last couple of nights. A lot of time was wasted before I found that
all the SUS{POS,PIT,YAW} damping gains on the SRM were set to 0.1 for some reason, which let it get rung up
just a bit during bang locking. After setting these gains to 0.5 (similar to PRM and BS), the initial lock
acquisition of DRMI+2ARMs (nospring) got much quicker. Then more time was wasted by sticky sliders on the
transmon QPD whitening gain, causing the Schmitt triggered HI/LO gain PD switch not to happen. This meant
that the arm power was not reported properly when the CARM offset was reduced, and so loop gain normalizations
were not working properly. After all this, by the end of the night last night, reduced the CARM offset such
that stored power in the arms was about half of the max. Should be able to get to full power with another
good night, and then back to springy locking.
  1009   Tue Sep 30 13:43:43 2008 robUpdateLockinglast night
Steady progress again in locking again last night. Initial acquisition of DRMI+2ARMs was working well.
Short DOF handoff, CARM->MCL, AO on PO_DC, and power ramping all worked repeatedly, in the cm_step script.
This takes us to the point where the common mode servo is handed off to an RF signal and the CARM offset
is reduced to zero. This last step didn't work, but it should just require some tweaking of the gains
during the handoff.
  1011   Wed Oct 1 00:24:54 2008 ranaUpdateLockinglast night
I had mistakenly left the MC boost off during my FAST investigations. The script is now restored.

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

Also found the MZ gain down at -10 dB around midnight - need an alarm on that value.
  1014   Wed Oct 1 02:54:03 2008 robUpdateLockingbad

Tried the spring-y side tonight with a discouraging lack of progress. There were several locks of DRMI+2ARMs with
the +f2 (springy) sideband resonating in the DRM, but they weren't very stable. Moving to just the DRMI and resonating
the +f2, in order to tune up the acquisition and the handoff to the double demod signals, revealed the problem that the
DRM just won't stay locked on the +f2 sideband. It locks quickly, but only for a few seconds. This is different from the
behaviour with the -f2 sideband, which locks quickly and stably. In theory, the two sidebands should behave similarly.
It could be problems with HOMs in the recycling cavities, and so we may try changing the modulation frequency slightly.
  1019   Thu Oct 2 02:45:50 2008 robUpdateLockingmarginally better
Locking the DRMI with the +f2 sideband was marginally better tonight. I was able to get it lock stably enough to take transfer
functions and handoff MICH & PRC to double demod signals. After re-alignment, however, behaviour was similar to last night
(locks quickly but only for a few seconds), so that lends some credence to HOM-as-bad-guy theories.
  1024   Fri Oct 3 15:57:05 2008 robUpdateLockinglast night, again
Last night was basically a repeat of the night before--marginally better locking with the DRMI resonating the +f2
sideband. Several stable locks were achieved, and several control handoffs to DDM signals worked, but never from
lock to lock--that is, a given DD handoff strategy would only work once. This really needs to work smoothly before
more progress can be made.

Also, a 24Hz mode got rung up in one/several of the suspensions--this can also impede the stability of locks.
  1117   Thu Nov 6 10:06:41 2008 steveUpdateLockingarms lock degradation
I have been locking the arms in the mornings lately.
The daily drift of LSC-TRX is ~ 15% and LSC-TRY ~5%
  1327   Thu Feb 19 23:50:31 2009 peteUpdateLockingaligned pd's on AP table

Yoichi, Peter

While continuing our efforts to lock, we noticed the procedure failed at a point it had gotten past last night:  turning on the bounce/roll filters in MICH, PRC, and SRC.  We checked the MICH transfer function and noticed that the unity gain point was ~10 Hz, well below the bounce modes.   We tried increasing the gain but found saturation, and Rob suggested that there could be misalignment on the AP table, which Steve worked on today.  We went out and found two of the PDs (ASDD133 and AS166) to be badly misaligned probably due to a bumped optic upstream.  We re-aligned.

 

 

  1329   Fri Feb 20 03:52:23 2009 YoichiUpdateLockingLocking Tonight
Yoichi, Peter

Tonight, we had a problem with the DD hand off.
It failed when the RG filters of MICH for the bounce-roll modes are engaged.
The reason for the failure was that the MICH UGF was too low (~10Hz).
As in the Peter's elog entry, we found that the AS PDs are mis-centered.
Even after we fixed the centering, the MICH UGF was still too low. So we increased the MICH feedback gain by a factor of 10.
The reason for the gain decrease is unknown. It seems almost like the BS coils get weaker.
I checked the UGF of the BS OL loops. These are around 4Hz, so fine. We should check the HWP on the AP table tomorrow.

After the DD hand-off goes ok, the switching of DARM signal from DC to RF failed.
I found that the gain and the polarity of the RF signal were wrong.
AS166 is one of the PDs we found mis-centered (and re-centered). But how can you flip the sign of the signal ?

After this, the cm_step script goes until the activation of the moving zero, but fails when the arm power is increased to 0.7.
Also the ontoMCL script succeeds only 50% of the time.
  1334   Tue Feb 24 02:23:40 2009 YoichiUpdateLockingLocking - MC board bad
Rob, Yoichi, Alberto, Kiwamu, Kakeru

We found that the OMC alignment feedback was on for the POS X loop even though the OMC was not locked.
This caused the PZT mirror to be tilted in yaw a lot. This was probably the reason for the mysterious shift in the AS beam last week, because the AS RF beam is picked up after this PZT mirror.
Rob aligned the OMC and we re-centered the AS PDs and the CCD.
This changed the DARM RF gain, so we changed it from 3 to 1. This gain used to be -1. It is still not understood why the polarity was changed.
The MC length was changed ? We should check the sideband transmission.

After this, we reached to the arm power 4. But the IFO loses lock immediately after the moving zero is turned off.
At this stage, the CARM loop bandwidth is supposed to be high enough that the moving zero is no longer necessary.
However, when we measured the MCL loop gain with several different AO path gains, the loop shape did not change at all.
This led us to suspect the AO path may not be connected. The cabling from the common mode board to the MC board seemed ok.
We tested the signal flow in the MC board using a signal generator and an oscilloscope.
Then we found that a signal injected to the IN2 (AO path) does not reach to the TP1A (right after the boost stages), though the signal is visible in the OUT2 (monitor BNC right after the initial amplifier (B-amp) for the AO path). The signal from IN1 (MC REFL) can be observed at TP1A. This means something is broken between the B-amp and the sum-amp in the AO path.
We will check the MC board tomorrow.
  1335   Tue Feb 24 18:42:15 2009 peteUpdateLockingmc board repair
Peter, Yoichi
Last night:


Quote:
However, when we measured the MCL loop gain with several different AO path gains, the loop shape did not change at all. This led us to suspect the AO path may not be connected. The cabling from the common mode board to the MC board seemed ok. We tested the signal flow in the MC board using a signal generator and an oscilloscope. Then we found that a signal injected to the IN2 (AO path) does not reach to the TP1A (right after the boost stages), though the signal is visible in the OUT2 (monitor BNC right after the initial amplifier (B-amp) for the AO path). The signal from IN1 (MC REFL) can be observed at TP1A. This means something is broken between the B-amp and the sum-amp in the AO path. We will check the MC board tomorrow.


Today we examined the MC board. With the extension board in place everything seemed fine. Without the extension board we could replicate the problem. Jiggling the IN2 jack caused the injected signal observed at TP1A to come and go. These jacks are unfortunately mounted directly on the board. We traced the problem to a resistor in this path (R30) which looked fishy. We soldered on a new 2K resistor with OWC and it fixed the problem.
  1336   Wed Feb 25 03:10:24 2009 YoichiUpdateLockingLocking status
Rob, Yoichi, Kakeru, Kiwamu

Tonight, CARM -> MCL hand off was not stable. The MCF signal monotonically went up to +2V after CARM and MCL gain was turned down to zero.
This was repeatable and it only goes up (not down).
After a while, we found that putting sleep (~5sec) between the zeroing of CARM gain and MCL gain prevents this problem.

Handing off of CARM error signal from TR to PODC was also not robust.
It seems that the suitable gain changes every time.

tdsavg started to exit with errors. We rebooted fb40m.
When tdsavg returns an error, the cm_step script tries to write NaN into SPOB DC offset.
To prevent this, I put the tdsavg in a while loop which runs until tdsavg returns something other than NaN.

I was able to hand off to PODC several times, but could not proceed further because the IFO lost lock soon.
  1341   Thu Feb 26 19:59:23 2009 YoichiUpdateLockingDaytime locking
Osamu, Yoichi

We tried locking today from about 2PM.
It took about 1000sec on average to acquire the initial lock.
After the initial lock is achieved, the hand-off/ramp-up steps were reasonably robust, although the AS beam sometimes fluctuates a lot (not good for mental health).

Like last night, the IFO loses lock at around arm-power=8.
We measured the CARM AO path loop gain at arm-power=4. We used the SR785 connected to the A-excitation channel of the common mode board through my TFSR785.py script.

The first attachment is the transfer function measured right after the arm power was ramped up to 4.
The overall bandwidth of the CM servo is only 400Hz. Note that since this is the loop gain of only the AO path, the low frequency gain is eaten by the MCL path.
The second attachment is the same transfer function measured after the AO path gain was increased by 6dB.
It is evident that the AO path is working.
We increased both the AO path and MCL gain by 18dB. The third attachment is the AO path TF in this state.
We then increased the arm power but lost lock at arm-power=6. We should have checked the DARM loop too.
BTW, these plots are automatically generated when you use TFSR785.py for transfer function measurements.


I added -notickle option to c1_watch_dr_bang, since tickling seems to be not necessary during the daytime (actually the initial lock was easier with no tickling).

As the construction work in the next building is now calmed down, I think it is ok to do locking during the day time, though I still plan to come at night.
The improvement of my brain efficiency during the day time may compensate for the longer wait time for initial lock.
  1343   Fri Feb 27 13:49:19 2009 robUpdateLockingthurs night

Could not get past arm power of ~11 or so.  I was suspicious of the transmon high-gain/low-gain PD handover, so I ran the matchTransMon scripts, but that did not help.  I also removed the line in the cm_step script that increased the CM gain by 18dB at an arm power of 4.  The gain of the CM servo will increase naturally as the power in the IFO builds up, so it may not be good to crank it right away.  I tried several other CM gains, and watched the DARM loop, but still could not get past an arm power of ~10-11.  I'm not sure what's wrong, but it may be that mysterious CM-servo/McWFS conspiracy, so we can try turning down the McWFS gain next time.

  1344   Mon Mar 2 03:57:44 2009 YoichiUpdateLockingSunday night locking
Tonight's locking started with a boot fest of the FE computers which were all red when I came in.
It also took me sometime to realize that C1:IOO-MC_F was returning always zero to tdsavg, causing the offloadMCF script to do nothing.
I fixed this by rebooting c1iovme and c1iool0.

Like Rob on the thursday night, I was only able to reach arm power around 10.
This time, I turned down the MC WFS gain to 0.02 (from 0.3).
I also checked gains of most of the loops (MICH, PRC, SRC, DARM, CARM-MCL, CARM-AO).
All the loops looked fine until the lock was lost suddenly. Also the spectrum of MC_F did not change as the arm power was ramped up.
Actually, I was able to reach arm power=10 only once because I spent a long time checking the loop gains and spectrum at fine steps of the arm power.
So it is quite possible that this loss of lock was just caused by a seismic kick.
  1346   Mon Mar 2 21:16:32 2009 YoichiUpdateLockingLow-gain High-gain PD switching may not be working well
Osamu, Yoichi

This afternoon, I run the locking script while doing calculations for the upgrade.
The IFO lost lock even at lower arm powers (around 6) if it was operated for a while (~ 5min).
It seemed as if there were some intermittent glitches (seismic? laser?) causing the lock losses.
We also saw once the TRX and TRY signals saturated at around arm power = 11 when there was a large fluctuation in the arm power.
Osamu suggested that it looked like the high-gain to low-gain PD switching was not working.

I won't come tonight as I may have caught a cold, but if someone comes tonight, it is worth checking the PD switching.
  1350   Tue Mar 3 19:26:44 2009 YoichiUpdateLockingLow-gain High-gain PD switching may not be working well
I checked the switching of the QPDX from high gain to low gain.
Switching happens as expected, but the low gain QPDX output was very low compared to QPDY.
Also the digital gain for the high gain TRX was not matched with the low gain one. So when the switching happens, there is a large jump in the TRX.

I also found that the offset values for the low gain QPDX were totally wrong. I adjusted it.
Then I removed a beam splitter in front of the QPDX to increase the power falling on it.
But still the low gain QPDX output is four times lower than the low gain QPDY.

I'm still working on it. So don't expect the switching to work correctly at this moment.
I'm planning to be back after the dinner.


Quote:
Osamu, Yoichi

This afternoon, I run the locking script while doing calculations for the upgrade.
The IFO lost lock even at lower arm powers (around 6) if it was operated for a while (~ 5min).
It seemed as if there were some intermittent glitches (seismic? laser?) causing the lock losses.
We also saw once the TRX and TRY signals saturated at around arm power = 11 when there was a large fluctuation in the arm power.
Osamu suggested that it looked like the high-gain to low-gain PD switching was not working.

I won't come tonight as I may have caught a cold, but if someone comes tonight, it is worth checking the PD switching.
  1351   Tue Mar 3 23:59:26 2009 YoichiUpdateLockingLow-gain High-gain PD switching may not be working well

Quote:
I checked the switching of the QPDX from high gain to low gain.
Switching happens as expected, but the low gain QPDX output was very low compared to QPDY.
Also the digital gain for the high gain TRX was not matched with the low gain one. So when the switching happens, there is a large jump in the TRX.

I also found that the offset values for the low gain QPDX were totally wrong. I adjusted it.
Then I removed a beam splitter in front of the QPDX to increase the power falling on it.
But still the low gain QPDX output is four times lower than the low gain QPDY.

I'm still working on it. So don't expect the switching to work correctly at this moment.
I'm planning to be back after the dinner.



This sounds like the QPD whitening gain sliders may be stuck. The slider twiddling script should be run, or the sliders should be twiddled by hand.
  1352   Wed Mar 4 03:37:51 2009 YoichiUpdateLockingLow-gain High-gain PD switching may not be working well

Quote:

This sounds like the QPD whitening gain sliders may be stuck. The slider twiddling script should be run, or the sliders should be twiddled by hand.


Yes, it was indeed the whitening gain slider problem.
I moved them and the QPDX gain went up suddenly. I reinstalled the BS in front of the QPDX and adjusted the offsets, gains accordingly.
Now the high-gain to low-gain switching is fine.
  1353   Wed Mar 4 03:50:17 2009 YoichiUpdateLockingStill won't go above arm power 10
Yoichi, Kentaro

The IFO still loses lock at around arm power 10.
I attached time series of various error signals when losing lock.
In all of the three cases, both of the arm powers go up rapidly just before losing lock.
(The first attachment was taken before I fixed the QPDX switching, so you can see saturation in TRX.)
But PD1_DC (the DC power in the PRC) did not go up in the third case.

I should also check correlations with laser power, CARM length (OSEM signals), seismic noise etc.
  1361   Thu Mar 5 05:07:09 2009 YoichiUpdateLockingWednesday night locking
Tonight, I was having a problem with the PO_DC hand-off.
It fails most of the time.
I increased the averaging time for the PD1_DC offset measurement.
I also wrote a script to match the gain of the transmission DC and the PO_DC signals.
This script (/cvs/cds/caltech/scripts/CM/matchPODCGain ) measures the gains of the old (TRX+TRY) and new (PO_DC) signals at 150Hz and returns the optimal value to be put into the input matrix.
cm_step script calls matchPODCGain to determine the matrix element value for the PO_DC signal.

Even with this script, the hand-off was still unreliable.
I checked the AO path loop gain just before the hand off. It looked normal.
Then I realized that the oscilloscope I hooked up to the PO_DC signal using a T-BNC may be introducing some noise into the channel.
So I removed it. Then the PO_DC hand off went well at least once.
The IFO still loses lock at around arm power 10.

I attached time series of the latest lock loss. The second attachment is a zoom of the first one.
This time, there is a glitch in the ETM feedback signals, which is also present in the DARM and CARM and error signals.
I saw this kind of glitches several times today.
  1364   Fri Mar 6 05:44:14 2009 YoichiUpdateLockingLocking distracted by the QPD whitenning problem again
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.
  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.
  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.
  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.
  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.
  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.
  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).
  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.
  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.
  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 ?
  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.
  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.
  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.
  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.

  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.

 

ELOG V3.1.3-