40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 219 of 330 Not logged in
ID Date Author Type Category Subject
16261   Tue Jul 27 23:04:37 2021 AnchalUpdateLSC40 meter party

[ian, anchal, paco]

After our second attempt of locking PRFPMI tonight, we tried to resotre XARM and YARM locks to IR by clicking on IFO_CONFIGURE>Restore XARM (POX) and IFO_CONFIGURE>Restore YARM (POY) but the arms did not lock. The green lasers were locked to the arms at maximum power, so the relative alignments of each cavity was ok. We were also able to lock PRMI using IFO_CONFIGURE>Restore PRMI carrier.

This was very weird to us. We were pretty sure that the aligment is correct, so we decided to cehck the POX POY signal chain. There was essentially no signal coming at POX11 and there was a -100 offset on it. We could see some PDH signal on POY11 but not enough to catch the locks.

We tried running IFO_CONFIGURE>LSC OFFSETS to cancel out any dark current DC offsets. The changes made by the script are shown in attachment 1.

We went to check the tables and found no light visible on beam finder cards on POX11 or POY11. We found that ITMX was stuck on one of the coils. We unstuck it using the shaking method. The OPLEVs on ITMX after this could not be switched on as the OPLEV servo were railing to limits. But when we ran Restore XARM (POX) again, they started working fine. Something is done by this script that we are not aware of.

We're stopping here. We still can not lock any of the single arms.

Wed Jul 28 11:19:00 2021 Update:

[gautam, paco]

Gautam found that the restoring of POX/POY failed to restore the whitening filter gains in POX11 / POY11. These are meant to be restored to 30 dB and 18 dB for POX11 and POY11 respectively but were set to 0 dB in detriment of any POX/POY triggering/locking. The reason these are lowered is to avoid saturating the speakers during lock acquisition. Yesterday, burt-restore didn't work because we restored the c1lscepics.snap but said gains are actually in c1lscaux.snap. After manually restoring the POX11 and POY11 whitening filter gains, gautam ran the LSCOffsets script. The XARM and YARM were able to quickly lock after we restored these settings.

The root of our issue may be that we didn't run the CARM & DARM watch script (which can be accessed from the ALS/Watch Scripts in medm). Gautam added a line on the Transition_IR_ALS.py script to run the watch script instead.

Attachment 1: Screenshot_2021-07-27_22-19-58.png
16264   Wed Jul 28 17:10:24 2021 AnchalUpdateLSCSchnupp asymmetry

[Anchal, Paco]

I redid the measurement of Schnupp asymmetry today and found it to be 3.8 cm $\pm$ 0.9 cm.

### Method

• One of the arms is misalgined both at ITM and ETM.
• The other arm is locked and aligned using ASS.
• The SRCL oscillator's output is changed to the ETM of the chosen arm.
• The AS55_Q channel in demodulation of SRCL oscillator is configured (phase corrected) so that all signal comes in C1:CAL-SENSMAT_SRCL_AS55_Q_DEMOD_I_OUT.
• The rotation angle of AS55 RFPD is scanned and the C1:CAL-SENSMAT_SRCL_AS55_Q_DEMOD_I_OUT is averaged over 10s after waiting for 5s to let the transients pass.
• This data is used to find the zero crossing of AS55_Q signal when light is coming from one particular arm only.
• The same is repeated for the other arm.
• The difference in the zero crossing phase angles is twice the phase accumulated by a 55 MHz signal in travelling the length difference between the arm cavities i.e. the Schnupp Asymmetry.

I measured a phase difference of 5 $\pm$1 degrees between the two paths.

The uncertainty in this measurement is much more than gautam's 15956 measurement. I'm not sure yet why, but would look into it.

 Quote: I used the Valera technique to measure the Schnupp asymmetry to be $\approx 3.5 \, \mathrm{cm}$, see Attachment #1. The data points are points, and the zero crossing is estimated using a linear fit. I repeated the measurement 3 times for each arm to see if I get consistent results - seems like I do. Subtle effects like possible differential detuning of each arm cavity (since the measurement is done one arm at a time) are not included in the error analysis, but I think it's not controversial to say that our Schnupp asymmetry has not changed by a huge amount from past measurements. Jamie set a pretty high bar with his plot which I've tried to live up to.

Attachment 1: Lsch.pdf
16275   Wed Aug 11 11:35:36 2021 PacoUpdateLSCPRMI MICH orthogonality plan

[yehonathan, paco]

Yesterday we discussed a bit about working on the PRMI sensing matrix.

In particular we will start with the "issue" of non-orthogonality in the MICH actuated by BS + PRM. Yesterday afternoon we played a little with the oscillators and ran sensing lines in MICH and PRCL (gains of 50 and 5 respectively) in the times spanning [1312671582 -> 1312672300], [1312673242 -> 1312677350] for PRMI carrier and [1312673832 -> 1312674104] for PRMI sideband. Today we realize that we could have enabled the notchSensMat filter, which is a notch filter exactly at the oscillator's frequency, in FM10 and run a lower gain to get a similar SNR. We anyways want to investigate this in more depth, so here is our tentative plan of action which implies redoing these measurements:

Task: investigate orthogonality (or lack thereof) in the MICH when actuated by BS & PRM
1) Run sensing MICH and PRCL oscillators with PRMI Carrier locked (remember to turn NotchSensMat filter on).
2) Analyze data and establish the reference sensing matrix.
3) Write a script that performs steps 2 and 3 in a robust and safe way.
4) Scan the C1:LSC-LOCKIN_OUTMTRX, MICH to BS and PRM elements around their nominal values.
5) Scan the MICH and PRCL RFPD rotation angles around their nominal values.

We also talked about the possibility that the sensing matrix is strongly frequnecy dependant such that measuring it at 311Hz doesn't give us accurate estimation of it. Is it worthwhile to try and measure it at lower frequencies using an appropriate notch filter?

Wed Aug 11 15:28:32 2021 Updated plan after group meeting

- The problem may be in the actuators since the orthogonality seems fine when actuating on the ITMX/ITMY, so we should instead focus on measuring the actuator transfer functions using OpLevs for example (same high freq. excitation so no OSEM will work > 10 Hz).

16303   Mon Aug 30 17:49:43 2021 PacoSummaryLSCXARM POX OLTF

Used diaggui to get OLTF in preparation for optimal system identification / calibration. The excitation was injected at the control point of the XARM loop C1:LSC-XARM_EXC. Attachment 1 shows the TF (red scatter) taken from 35 Hz to 2.3 kHz with 201 points. The swept sine excitation had an envelope amplitude of 50 counts at 35 Hz, 0.2 counts at 100 Hz, and 0.2 at 200 Hz. In purple continous line, the model for the OLTF using all the digital control filters as well as a simple 1 degree of freedom plant (single pole at 0.99 Hz) is overlaid. Note the disagreement of the OLTF "model" at higher frequencies which we may be able to improve upon using vector fitting.

Attachment 2 shows the coherence (part of this initial measurement was to identify an appropriately large frequency range where the coherence is good before we script it).

Attachment 1: XARM_POX_OLTF.pdf
Attachment 2: XARM_POX_Coh.pdf
16304   Tue Aug 31 14:55:24 2021 ranaSummaryLSCXARM POX OLTF

this model doesn't seem to include the analog AA, analog AI, digital AA, digital AI, or data transfer delays in the system. I think if you include those you will get more accuracy at high frequencies. Probably Anchal has those included in his DARM loop model?

16320   Mon Sep 13 09:15:15 2021 PacoUpdateLSCMC unlocked?

Came in at ~ 9 PT this morning to find the IFO "down". The IMC had lost its lock ~ 6 hours before, so at about 03:00 AM. Nothing seemed like the obvious cause; there was no record of increased seismic activity, all suspensions were damped and no watchdog had tripped, and the pressure trends similar to those in recent pressure incidents show nominal behavior (Attachment #1). What happened?

Anyways I simply tried reopening the PSL shutter, and the IMC caught its lock almost immediately. I then locked the arms and everything seems fine for now .

Attachment 1: VAC_2021-09-13_09-32-45.png
16322   Mon Sep 13 15:14:36 2021 AnchalUpdateLSCXend Green laser injection mirrors M1 and M2 not responsive

I was showing some green laser locking to Tega, I noticed that changing the PZT sliders of M1/M2 angular position on Xend had no effect on locked TEM01 or TEM00 mode. This is odd as changing these sliders should increase or decrease the mode-matching of these modes. I suspect that the controls are not working correctly and the PZTs are either not powered up or not connected. We'll investigate this in near future as per priority.

16368   Thu Sep 30 14:13:18 2021 AnchalUpdateLSCHV supply to Xend Green laser injection mirrors M1 and M2 PZT restored

Late elog, original date Sep 15th

We found that the power switch of HV supply that powers the PZT drivers for M1 and M2 on Xend green laser injection alignment was tripped off. We could not find any log of someone doing it, it is a physical switch. Our only explanation is that this supply might have a solenoid mechansm to shut off during power glitches and it probably did so on Aug 23 (see 40m/16287). We were able to align the green laser using PZT again, however, the maximum power at green transmission from X arm cavity is now about half of what it used to be before the glitch. Maybe the seed laser on the X end died a little.

8331   Fri Mar 22 01:28:56 2013 ManasaUpdateLasersBeam profile of NPRO from ATF

The NPRO from ATF has been installed on the POY table.

I have been making measurements to characterize the beam profile of this laser. I am using an AR coated laser window as a beam sampler at 45deg and the razor blade technique to measure the beam size along z. Details of the procedure along with analysis and results from this will follow.

231   Thu Jan 10 00:12:01 2008 tobinSummaryLockingDR
[John, Tobin, Rana]

1. We found SUS_BS_SENSOR_UL to have a ratty signal and low DC value. Twiddling the cables at the BS satellite amplifier and vacuum feedthrough brought the signal back (to 0.667V), but it is still spiky, spiking up to a couple times per second. Rana suggested that these spikes might be scattered YAG laser light (as hypothesized in August). The spikes go away when we misalign the PRM or either ITM, and when we unlock the mode cleaner, lending credance to this theory. SUS_BS_SENSOR_UR also spikes, but much less frequently. We turned off C1:SUS-BS_ULSEN_SW2 and continued.

2. After dither alignment the oplev beams were centred and we were able to lock DRM plus either arm reliably (however locking in this state broke ./drstep_bang at the first Going DD''). We ran scripts/DRFPMI/bang/nospring/drdown_bang and were subsequently able to lock DRFPMI (i.e., full IFO) a couple times.

3. To do: Debug ./drstep_bang with just the DRM (no arms).
313   Tue Feb 12 16:39:52 2008 robUpdateLockingreport

Did some locking work on DRFPMI on sunday and (with John) on monday nights. So far progress has not been terribly encouraging.

Problems include the DD_handoffs not working and the CARM->MCL handoff not working so well. To get around the DD signals trouble, I decided for now to just ignore 67% of the DD signals. We should be able to run with PRC & MICH on single demod signals, and SRC on a DD signal. This seems to work well in a DRMI state, and it also works well in a DRMI+2ARMs state.

The CARM->MCL handoff actually works, but it doesn't take kindly to the AO path and it doesn't work very stably. I guess this was always the most fragile part of the whole locking procedure, and it's fragility is really coming to light now. Investigation continues.
362   Thu Mar 6 00:17:37 2008 robUpdateLockingDD handoff working
Got the DD (double demod) handoff scripts working tonight, with just the DRMI. So, now acquisition with the single demod signals is working well, and handoffs to all double demod signals using the input matrix ramping worked several times with the scripts. Up next will be more work with the DRM+ARMs.
366   Mon Mar 10 02:05:08 2008 robUpdateLockingDRMI+2ARMs working better

Some encouraging progress on the locking front tonight. After the work on the DRM loops last week and a review of the settings for initial lock acquisition (loop gains, tickle amplitude, filter states, so on), the DRMI+2ARMS locking is working pretty well. That's to say, it takes from 5-15 minutes generally for the IFO to lock in the offset CARM state, with the arm powers at 0.5. It's then possible to raise the arm powers slightly, and handing off control of CARM to MCL works at low power, but engaging the AO path (using PO_DC as an error signal) is not working so well. Taking swept sines indicates that the PO_DC should be a good error signal. The next good thing to try might be just using PO_DC as an error signal for the length path, without using the AO path at all, to see if it's something in the hardware.
442   Thu Apr 24 14:10:26 2008 robUpdateLockinglocking work
Rob, Johnnie

We made some progress on locking last night (Wed night), namely that we were able to handoff (briefly) the CARM-MCL path the REFL-DC error signal. We tried this because we suspect that the reason the PO-DC is not a good CARM error signal is because at low powers, the dc light level in the recycling cavity is dominated by the +f2 RF sideband. Thus, REFL-DC should work a bit better at low powers, which it did. It wasn't super stable, though, so this will require a bit of work to make the transition reliable & stable. The next things to work on include setting the AO path gain properly and possibly going to higher arm powers before handing off (thus increasing the discriminant).

Another thing we found is that the alignment scripts are not working in an ideal fashion. Running the alignment scripts for the two arms (XARM & YARM) leaves the Michelson badly misaligned, making it impossible to get good DRM alignment. This will have to be fixed.
531   Thu Jun 12 01:51:23 2008 robUpdateLockingreport
rob, john

We've been working (nights) on getting the IFO locked this week. There's been fairly steady incremental progress each night, and tonight we managed to control CARM(MCL) using PO-DC, with the CARM(AO) path also on PO-DC. In the past, reaching this state has usually meant we're home free, as we could just crank the gain on the common mode servo and merrily reduce the CARM offset. Tonight, however, this state has been very twitchy, and efforts to ramp up the gain have been unsuccessful.

I've attached a diagram which I hope makes clear where we are in the stages of lock acquisition.
Attachment 1: lock_control_sequence.png
532   Thu Jun 12 15:09:33 2008 alanUpdateLockingreport
Rob: Awesome figure. As you can imagine, I have lots of questions, and hope that you will consider this figure to be the beginning, leading to ever-more detailed versions. But for now, I just want to ask whether you understand *what* is twitchy, and what the twitchiness does to prevent you from taking this further?
533   Thu Jun 12 15:55:15 2008 robUpdateLockingreport

 Quote: Rob: Awesome figure. As you can imagine, I have lots of questions, and hope that you will consider this figure to be the beginning, leading to ever-more detailed versions. But for now, I just want to ask whether you understand *what* is twitchy, and what the twitchiness does to prevent you from taking this further?

I definitely don't understand what's twitchy, but I have suspicions. Tonight we'll try to start by revisiting the other loops (the non-CARM loops) and see how they're dealing with the changing power levels. It may be that the DARM loop is going unstable due to gain variations (due to either increasing power or to rotation of demod phase) or it could be the PODD (or SPOB) saturating with increased power in the recycling cavity. I just hope the glitchiness doesn't have a digital origin.
568   Wed Jun 25 13:56:56 2008 JohnSummaryLockingTuesday night locking
Rob, John

Worked to try and reduce the CARM offset using the dc arm transmissions before changing to SPOB DC. This proved somewhat unsuccessful, the offset couldn't be reduced to more than five (arms storing 5x more power than single arm cavity lock).
573   Thu Jun 26 12:30:40 2008 JohnSummaryLockingCARM on REFL_DC
Idea:

Try REFL_DC as the error signal for CARM rather than PO_DC.

Reasoning:

The PO signal is dominated by sideband light when the arms are detuned so that any misalignment in the recycling cavity introduces spurious signals. Also, the transfer function from coupled cavity excitation to REFL signal is not so steep and hence REFL should give a little more phase. Finally, the slope of the REFL signal should make it easier to hand over to RF CARM.

Conclusion:

The REFL signal showed no clear improvement over PO signals. We've gone back to PO.

During the night we also discovered that the LO for the MC loop is low.
582   Fri Jun 27 14:36:39 2008 JohnSummaryLocking
Rob, Yoichi, John

Some progress last night:

Switched back to SPOB_DC for CARM.

Shaped the MC LSC loop to reduce excess noise in the 20-30Hz band. Likely the most significant change.
Could this be due to fan noise from the laptop on the SPOB table?

Brought in the AO path earlier (at low gain).

Reduced offset to 6 and increased MC gain before handing off to SPOB. Ramped up AO and MC gain then switched off the
moving zero.

Looks like PD11 is the most promising candidate for RF CARM although the demod phase needs attention.
Attachment 1: gettingcloser.png
623   Wed Jul 2 13:56:10 2008 Rob, Yoichi, JohnUpdateLocking24.5 Hz resonance
Work continues on trying to reduce the CARM offset using dc signals from PO_DC. Got up to arm powers of
~35 last night.

We found that progress was stymied by an oscillation around 24 Hz. This oscillation was clearly visible
in the intensity of the light at REFL, PO and TrX.

Initially we suspected that this oscillation was due to an instability in the CARM loop. We attempted to
solve the problem by tuning the crossover frequncy of the AO and MC_L paths and shaping the MC_L loop to
reduce the impact of the 24 Hz noise.

After some quick tests we found that the 24 Hz signal was present even when dc CARM was used. It appears
that the peak is in fact due to a SOS mechanical resonance. We currently suspect a roll mode.

We're going to check that PRC, MICH and DARM have filters to attenuate the 24 Hz line. We'll also look at the
SUS_POS bandstop filters to see where they are centred.

The ISS was behaving strangely again. Constantly saturated at 5dB of gain. Someone needs to look a this.
Attachment 1: locking080702.png
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).
Attachment 1: LOL.png
Attachment 2: NoisyX080702.png
Attachment 3: POXforCARM080702.png
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.
Attachment 1: darm_specg.png
Attachment 2: qpdx_specg.png
Attachment 3: qpdy_specg.png
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.
Attachment 1: LongLock080709.png
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.
Attachment 1: lock_control_sequence_worked.png
Attachment 2: trendpowerbuild.png
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.
Attachment 1: flatlissa.png
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%
Attachment 1: arms.jpg
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.
Attachment 1: CM1.png
Attachment 2: CM2.png
Attachment 3: CM3.png
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.
ELOG V3.1.3-