For the IPANG telescope design, we are in the 'beyond the Rayleigh range' regime. So using a single lens to make the beam small is not a great idea. I have put down a solution where we use a pair of lenses; one of which will be mounted in-vacuum in the ETMY chamber and the other on the endtable.
This way we will also allow have some freedom to configure the layout out-of vacuum in case the need arises. The layout will look something like in the cartoon:

I also made a choice of using longer focal length lenses (CVI 2" lenses f =1 m). Below is the beam path summary for IPANG telescope. I have used the waist diameter at the ITM for propagation. The endtable is roughly at 41.2m. The QPD will be placed in front of the waist (w0=47um).
 

The above timing problem has been repeating (a couple of times this week so far). It does not seem to be related to the campus network.

The same solution was applied.

[EricQ, Gabriele, Manasa]

We found we had lost the Y arm pointing from yesterday. We tried to recover the pointing for a couple of hours and finally decided to take the ETMY heavy door off.

The input beam was aligned to the Y arm. We also got AS and REFL out of vacuum and on the cameras.

We put back the light doors and tried to lock the arms, but did not succeed as yet.

Things to do:
1. Lock arms for IR
2. Realign POP path
3. Recenter all oplevs
4. Try to check the state of PRC after the length change
5. Take in-vacuum pictures

[EricQ, Manasa]

We are close to the end of the vent except for a couple of issues.

* POP is not visible on the IR card. But we see POP flashes unclipped on the camera and also spikes in POP DC. So  we are assuming that the POP path hasn't gone far off. If anybody has suggestions for a better method to check this, we could give it a try.

* PRM suspension has not been behaving well. PRM is being kicked around every 5-10 seconds when the PRC is aligned (as seen on REFL camera). We are not sure where this is coming from. The first time we saw this happening was when we were trying to lock PRC at low power even before we took the heavy doors off. So we are pretty sure this is not caused by the foil cover on the OSEMs. We tried turning ON/OFF the oplev servo, turning ON/OFF the damping loops and also checked the connections in the feedthrough and satellite box for the PRM. The OSEM sensor values for the suspension also seem to match the ones on the wiki.

Closeup checklist

• Center beam on all AS optics

• GET CAMERA IMAGES OF EVERYTHING

  • We must get images right before closing, right after closing, etc.
• Make sure REFL is clear
  • dither PRM, see motion on AP tables
• Make sure AS is clear
  • dither BS/ITM, see motion on AP tables
• Using IPANG/POS pick-off mirrors, center beams on:
  • IPPOS
  • IPANG (IPANG aligned to be low in pitch. The beam comes out of vacuum unclipped and hits the first steering mirror outside vacuum at its lower edge)
• Check green alignment in the arms and make sure the transmitted green reaches the PSL table.

• Check all OpLevs centered, in and out of vacuum

• Close PSL shutter & green shutters at the ends

• Check jam nuts

This is solved.

The ASC for PRC for left turned ON. Turning it OFF solved the problem.

If there is no feedback regarding the POP alignment or anything to check with modified PRC length, we will close tomorrow morning.

 [EricQ, Manasa]

This check was done and we had to move one of the steering mirrors in pitch. Else, everything was just fine.

In-vacuum pictures of PR2 and PR3 new positions were taken. MC spot positions measured to be < 1mm and oplevs were centered.

[Steve, Manasa]

I checked the alignment one last time. The arms locked, PRM aligned, oplevs centered.

We went ahead and put the heavy doors ON. Steve is pumping down now!

Y arm green: Nothing much was disturbed. I touched the steering mirrors and brought GTRY from 0.2 to 0.9.

X arm green: The PDH lock was not very stable mostly because of the low power in green. I changed the oven temperature for the doubler to 36.4 corresponding to maximum green power. GTRX increased from 0.1 to 0.9

Both the X and Y arm green alignment were tuned on the PSL table to their respective beat PDs.

The PSL green shutter was not responding to the medm buttons. I found the PSL green shutter set to 'local' and 'N.O' (these are switches in the shutter controller). I do not see any elog and not sure as to why the controller was even touched in the first place. I set the shutter controls to 'remote' and 'N.C'.

The X and Y arms were locked successfully using ALS and the arms could be scanned and held to support IR resonance.

The same procedure as in elog 9219 was followed. In-loop noise was measured to be between 200-300 Hz rms for the lock.

ALS settings for the lock

X arm : FM 2, 3, 5, 6, 7, 8, 10  Gain = 11.0
Y arm : FM 2, 3, 5, 6, 7, 8, 10  Gain = 10.0

The MC has been funny since yesterday. I checked the suspensions INMON channels and they seemed ok. So I went ahead and tweaked the alignment with WFS disabled (yesterday). Although the WFS PDs were cenetered at this point, the WFS servo was throwing the MC in a not-so-happy state. We worked with the WFS servo OFF all of yesterday.

This morning,

* I fine tuned the MC alignment from yesterday (TRANS_SUM > 17800 counts)

* measured the spot positions

* recentered the spots on the WFS PDs (was already quite centered)

*reset the WFS filterbank offsets.

The MC has been locked happily since then with autolocker and WFS servo enabled.

MC tuning

Although the morning MC tuning looked stable, Koji pointed out that the MC_REFL_OFFSET was changed from its nominal value.

The offset was reset and this caused drift in the MC_TRANS_SUM.

To fix this:

- disabled the WFS servo

- aligned MC using MC1 and MC3

- centered beam on the MC_REFL

- reset WFS offsets

- locked MC

MC looks happy now.

__________________________________________________________________________________________________________________

ALS locking

ALS is in a very different state from a couple of days ago when we could successfully lock the arms and scan.

The green alignment to the arms had drifted.

PSL green alignment on the PSL table was off. The PSL green was not even on the steering mirror. Did anyone work around the PSL table in the last couple of days?

After aligning and finding the beat note, I found the ALS servo very noisy. The error signal had 10 times more rms noise than what was achieved earlier this week and there were some new 60Hz peaks as well.

Overall, we could not do any PRMI+ALS arms today

Watch arms script (ALSdown.py) has been modified and now watches the LSC-$ARM filter module instead of the ALS-$ARM filter module. Threshold has been kept the same +/-5000 counts to the ETM suspensions. The script has been tested and works just fine. It exists in the same place scripts/ALS/.

Jenne's modified versions of ALSfindResonance.py and ALSchangeOffset.py were tested and work just fine.

The IMC has not been behaving well since this morning and totally not happy when Q was finishing his measurements. The WFS servo had large offsets in pitch. Looking back at the trend and using ezcaservo to restore the suspensions did not help.

I realigned the IMC and brought TRANS SUM to ~18000 and MCREFL to < 0.5. The spot positions are not very good; nearly 2 mm off in pitch on MC1 and MC3. But after the alignment of MC, the WFS servo offsets were below +/-20.

The MC has been locked stably with WFS servo ON for the last few hours.

P.S. I did not touch the WFS pointing or reset the WFS offsets.

I locked the arms using ALS error signals and the LSC filter modules. But when I try to acquire CARM and DARM using ALS, the arms lose lock when the matrix elements ALSX to Yarm and ALSY to X arm reach -/+0.9

What I did:

1. ALS locking of arms
(i) Found arm beat notes
(ii) Input matrix POX and POY elements set to '0'
(iii) Aux matrix elements ALSX to Xarm and ALSY to Y arm set to '1'
(iv) Power normalization matrix elements for TRX and TRY set to '0'
(v) Triggers for arm lock over ridden and the FM triggers were set to 'manual'
(vi) Arm servo gains set to '0'
(vii) All but FM5 were disabled
(viii) Phase tracker history reset and servo actuation set to ETMs
(ix) Servo gain increased in steps (+/-10 for the arms)
(x) FM1, FM6, FM7 enabled (see note 1 below)
(xi) FM9 enabled

Arms were locked with ~2000Hz rms

2. CARM and DARM locking
(i) Scanned the arms for IR resonance
(ii) Moved off-resonance (Stepped arm servo offsets by 30 counts)
(iiI) Stepped matrix elements ALSY to X arm and ALSX to Y arm ezcastep C1:LSC-PD_DOF_MTRX_6_29 +-0.1 C1:LSC-PD_DOF_MTRX_7_28 +0.1

Whenever the matrix elements reached -/+0.9, the arms were kicked out of lock. I don't see anything obvious as to why this is happening even after nearly 10+times of redoing.

Notes:
1. I found the filters for the arm servos different for X and Y. FM1 and FM8 were missing in one of the filter modules. Jenne remembered Rana modifying and removing the unnecessary filters in one arm. We put back FM1 (low pass filter) which might not be necessary for PDH lock but is necessary for ALS. FM8 is now added to FM7.
2. To self : Check ALS Y arm power outlets (60Hz frequency comb seen in the error signal)

MC remained locked with WFS enabled all through last night and this morning. Koji dropped by and looked at the MC. The MC WFS servo, though stable, was at the edge of becoming unstable. This was because I did not touch the WFS pointing on the QPDs yesterday after realigning. So I recentered the WFS, reset the WFS filterbank offsets and reenabled the servo.

I measured the spot positions on MC mirrors for reference.

Spot positions in mm (MC1,2,3 pit MC1,2,3 yaw): [1.405767579680834, 0.79369009503571208, 1.3220430681427462, -1.2937873599406551, -1.1704264340968924, -1.2518046122798692]

[EricQ, Manasa]

ALS common locked by actuating on MC2 and ALS Differential locked by actuating on ETMX and ETMY (Stable lock acquired for over an hour).

Common and Differential offsets were swept to obtain IR resonance in both the arms (arms stayed on resonance for over 15 minutes).

Procedure:

1. Configured LSC settings to allow locking using ALS error signals.

2. Locked common and differential using ALS error signals

Aux matrix
              ALSX    ALSY
------------------------------
XARM    1            -1
YARM    1              1
-----------------------------
X arm servo settings:
FIlters: FM1, FM5, FM6, FM7, FM9
Gain = -8.0

Y arm servo settings:
Filters: FM1, FM5, FM6, FM7, FM9
Gain = +8.0

Out matrix
    XARM    YARM
------------------------
ETMX    1    0
ETMY    0    1
------------------------

3. Transitioned CARM control output to actuate on MC2 instead of ETMX

SUS-MC2_LSC servo gain = 1.0
The transition was done in very small steps : actuating on MC2 in -0.01 steps at the outmatrix upto -1.0 while reducing the ETMX actuation to 0 simultaneously.

DARM still stayed locked only with actuation on ETMY.

4. Transitioned DARM control to ETMX and ETMY.

Used ezcastep to step up DARM control (Y arm output) actuation on ETMX and step down the actuation on ETMY.

Final output matrix
    Xarm    Yarm
-----------------------
ETMX      0    -0.5
ETMY      0     0.5
MC2    -1.0      0
-----------------------

Noise plot in attachment.

5. Finding arm resonance

Used ezcastep to gradually build up offsets in CARM (LSC-XARM_OFS) to find IR resoance in one arm (Y arm).
Introducing a small (order of 0.5) DARM offset (LSC-YARM_OFS) shifted the Y arm off-resonance.
Used CARM offset to get back the Y arm to resonance.
Changing CARM and DARM offsets alternately while tracking the Y arm resonance got us to a point where we had both the arms resonating for IR.

6. At this point the MC decided to give up and we lost lock.

Notes:
1. We found that the WFS2 YAW output filterbank had the output switched OFF (probably accidentally by one of us). This was reenabled. Please be careful while manually turning ON and OFF the MC WFS servos.

Q and I have started to use the ALS slow servo for the end aux lasers while locking the arms using ALS. The servo prevents us from hitting the limits of the PZT range for the end lasers and a better PDH locking.

But keeping the servo ON causes the slow output to drift away making it hard to find the beat note everytime the arm loses lock. The extensive beat note search following the unlock can be avoided by clearing history of the slow servo.

I have modified the IFOconfigure scripts and the corresponding .req files for the X arm and Y arm in burt. I have also added configure scripts to save and restore LSC settings for locking the arms using ALS error signals.

The settings are yet to be saved and the scripts should also be checked if they are working as required.

Off again. Restarted ntp on fb.

I tried to repeat Koji's PRMI lock using REFL165I/Q. I was not able to lock PRMI stably. All I could get was momentary PRMI sb locks (few seconds) using AS55Q for MICH and REFL165Q for PRMI. I tried to transition MICH locks from AS55Q to REFL165I/Q and this did not work well; I lost even the momentary locks.

The demod phases for both AS55 and REFL165 were also very different. 

Input ports:
AS55       WHTN: 21dB  demod phase -78.7deg
REFL165 WHTN: 45dB demod phase -80.7deg

Input matrix:
AS55Q x1.00 MICH

REL165Q x+0.14

Triggers:
MICH POP110I 100up/10down / FM Trig FM2/3/6/7/9 35up 2down 5sec delay
PRCL POP110I 100up/10down / FM Trig FM2/3/6/9 35up 2down 0.5sec delay

Servo:
MICH OFS 0.0 / Gain -10 / Limiter ON
PRCL OFS 0 / Gain -0.023 / Limiter ON

Output matrix:
MICH ITMX -1.0 / ITMY +1.0
PRCL PRM 1.0

 MC2_TRANS path in WFS servo turned OFF.

 Guilty!!

POP path

The POP PD was showing only ~200 counts which was very low compared to what we recollect from earlier PRMI locks (~400 counts). Also, the POP ASC QPD was also not well-aligned.
While holding PRMI lock on REFL55, I aligned POP path  to its PD (maximize POP DC counts) and QPD (centered in pitch and yaw).

X and Y green

The X green totally lost its pointing because of the misaligned PZTs from last week's power failure. This was recovered.
Y arm green alignment was also recovered.

I have included Yarm CESAR to the LSC model. It was just a copy paste of the Xarm CESAR. Since we are now meditating about implementing CCESAR and DCESAR, I did not run or install the model as yet.

Arm lengths measured using ALS. Both the arms were estimated to have the same length (to the order of a centimeter) 37.51 m

How
I used ALS error signal to lock the arms and scanned the arm to find 4 consecutive IR resonances. From the beat note frequencies measured using the spectrum analyser during IR resonance, the FSR, and hence the length of the arms were calculated.

The estimated lengths are not very precise down to a mm given the resolution of the spectrum analyser. We have brought out the rubidium clock to use as reference for the spectrum analyser to challenge the measurements.

[From yesterday]

The MC had not been stable lately with WFS drifting constantly. I checked the servo and found that the MC_TRANS path was still running. It turned out that the autolocker script enables the TRANS path in the locking process. I have turned the MC_TRANS path servo inputs OFF and now it is no more a part of the WFS servo.

P.S. Jenne fixed the PMC alignment mostly in pitch to bring it up to 0.81 from 0.77. But the temperature fluctuations have still not got us to the sweet spot for optimum PMC trans.

Arm lengths were measured using ALS

X arm length = 37.79 +/- 0.05 m

Y arm length = 37.81 +/- 0.01 m

Whats and whys

We want to measure the arm length with an accuracy of say a mm.

This would mean a measurement precision of 1e-3/40=25ppm. (1mm in 40m)

So the required measurement resolution on the spectrum analyser is 25ppm*4MHz=100Hz (assuming the cavity FSR is roughly 4MHz). 

Although the spectrum analyser does not limit the measurement precision, we are limited by the noise in ALS at 1000Hz rms. So we can use ALS only to measure arm length precise to the order of a few mm.

RXA: Not that we really need to right now, but even with an ALS noise of 1000 Hz, we can can do better just by averaging at each resonance point. And fitting a line as you have already done gets even better:

http://en.wikipedia.org/wiki/Propagation_of_uncertainty

The Spectrum analyser was reference locked to the rubidium clock @10MHz for these measurements.

The FSRs of the arms

X arm = 3.9671e+06 +/- 4.8535e+03 Hz

Y arm = 3.9648e+06 +/- 1.1064e+03 Hz

Attachments:

1&2. Plots representing the arm scans showing the beat frequency for which IR resonates in the arm vs the ALS offset (position of the ETM).

3. Data and code (zip file)

P.S. We had trouble scanning the arms using ALS. This was because the slow servo was not enabled. Hence ALS was losing its PDH lock everytime we scanned past a couple of FSRs.

I have noticed that ALS noise has been at 1KHz rms since LSC arm lock servos have been used to lock arms using ALS error signals. May be this has not been given much attention.

But looking more closely at the ALS noise (better dtt resolution for noise power spectrum) , there seems to be too much noise suppression at <1Hz and not much happening at around 10Hz.

Attachment 1 (data files at /users/manasa/data/140421/)

So I made a bunch of transfer function measurements for ALS and phase tracker servo. Koji will be using these and redesigning the servo filters so that we can get more suppression at 10Hz.

Other than this I also found that the Y arm showed more high frequency noise as compared to the X arm. (Edit by manasa: Thinking back now, this could be related to the onset of 60Hz noise at the Y end elog 9838. But still has to be looked at after fixing TRY)

Attachment 2

Tip: Once the arms are ALS locked, enabling the SLOW_SERVO helps hold the lock stably. 

P.S. I realigned the Y green to the arm and brought GTRY to 0.93

To do:

Find out what makes Y arm in-loop noise at high frequency higher than X arm.

 I went to the Y end to look at the TRY 60Hz noise situation this morning. While looking at TRY noise on dtt, I found that just lifting the cable away from the cable bunch that runs out of the table suppressed the noise drastically. 

Attachment 1

I removed the unwanted bnc connector in the path of the already long TRY cable running from the PD to the 1Y4 rack and isolated it from the bunch. TRY became less noisy.

But the noise was back again earlier in the evening and it looks like the noise is very much related to the TRY cable. TRY cable might have moved from its sweet spot while I was around checking cable connections yesterday.

I couldn't find a spare to replace it right away today (We need a BNC to 4 pin lemo).

[Steve, Manasa]

To find noise source

1. Swapped the power cable of the PD and checked that it is connected to the right power source.

2. Changed the aluminium base of the post holding the diode so that the diode is floating

3. Grounded the table and the rack

4. Routed the cable on the other side of the beam tube to isolate it from other cables.

After all the above, we still found that shaking the cable was making TRY noisy.

I pulled out the PD whitening board to replace the 4 pin lemo connector with a bnc connector so that we can swap the cable with a new one. So there is no TRY right now.

The MON outputs of the Y end QPD whitening board were hot earlier today while pulling it out of the crate. After swapping the 4 pin lemo connector with an isolated panel mount bnc connector, I stuck the board back into the crate and this immediately kicked the ETMY suspension. Jenne and I went to the Y end to look at what was going on. We removed the board from the crate after smelling something burning. The MON output ports of the whitening board were super hot this time. There is no sign of any components melting on the board (comparing the board with its pictures that were taken earlier) and a tester board stuck into the crate lights up just fine.

So the back panel is still ok. We need to troubleshoot or replace the whitening board.

Edit, JCD:  The attached photos are from right after I replaced the "Rgain" resistor, elog 9823.  What they show is that it looks like some of the melting / burning may have already been happening before I pulled the board, and I just never noticed :(  In particular, look at the resistors on the main board above the blue "G" sticker.  There isn't a difference that I can tell between this photo from last week, and today's situation. 

The MC was showing slow but periodic alignment drifts and eventually unlocked around noon. I looked up the alignment trend (Attach: 2 day trend)

MC_TRANS_PIT_ERR and MC_TRANS_Y_ERR show that the MC_TRANS servo slowly drifted the IMC alignment causing it to lose lock from time to time (mostly in yaw).

To confirm that the drift was NOT due to off-centering in the MC2_TRANS QPD, I turned off the WFS servo, moved MC2 to recenter the trans beam on the QPD, and re-enabled WFS servo.

MC_TRANS path in WFS is still left enabled.

[Koji, Manasa]

The Y arm locks stably for IR PDH now.  

The reason for ETMY getting kicked during lock acquisition was finally found to be related to the limiter value set in the Y arm servo. We reduced the limiter value unintentionally and found that the lock acquisition stayed smooth. The limiter value was stepped in 1000s from 7000 and eventually found that the ETMY suspension was kicked when we try to acquire lock with the limiter value was set at 11000. 

The limiter for X arm at 11000 is not causing any trouble at the moment.

In the process, we did a bunch of things through the evening to troubleshoot IR locking of the Y arm.

Earlier today running the IFO configure script did not restore the arms to lock and both the ETMs needed to be aligned to lock the arms. The arms stayed locked for 15 minutes and the Y arm lost lock eventually leaving the ETMY in a misaligned state. 

The state of the Y arm was similar to what Jenne has explained in ELOG where the ETMY was kicked during lock acquisition and would move to a misaligned state.

To trouble shoot, there were several things that were done. A few of them might not have any direct correlation to the locking issue but could just be a coincidence.  

1.  The trigger time for the filters in the arm filter modules were set such that they switch on after the SUS violin filters. Arm FM trigger time = 3 s (previously set at 0.1s) and SUS violin trigger time = 1s. This reduced the number of lock loss events.

2. There was some drop in transmission when the bounce filter of Y arm (FM6) turned ON. This was fixed by changing its ramp time (initially set at 1s). The filter has been modified to turn on immediately upon arm lock acquisition before the other triggered filters in the filter module turn on.

3. The QPD and SUS signal cables running to the rack were checked to be intact. Koji found some of them to be loose. But this had no evident correlation with the arm locking problem.

4.The oplev and PD alignment was checked at the Y end. The high gain trans PD for Y arm was checked for good alignment by looking at TRY. It was found that the EXIT light at the Y end is injecting some noise to the transmission PD. 

5. The ETMY was given offsets in PIT, YAW and POS and the OSEM sensor values were checked to see if the suspension is behaving well. It was behaving well.

c1sus and c1isey were not talking to fb. The usual mxstream restart did not help.

Restarted fb

>>ssh fb

>>telnet fb 8087
shutdown

All lights on the FE status screen are green now.

Note that Steve did an mxstreamrestart earlier today because the same machines c1sus and c1isey were not talking to fb.

I. The Y arm stayed stable through last night and I have saved the arm lock settings to IFOconfigure.

II. ALS X arm noise measurements

I looked at the before and after noise of ALSX.

Settings:
Phase tracker gain = 85
Xarm servo gain = -17

The rms in loop noise has dropped from 3KHz to 500 Hz.

Attachment 1: Phase tracker OLTF

Attachment 2: Free running noise and in loop noise

Attachment 3: Out of loop noise (measured with arms locked using PDH for IR)

Attachment 4: ALS arm servo OLTF

xml data files can be found in /users/manasa/data/140430/

I found MC unlocked this morning. I looked at the 2 day trend of the MC suspensions and found MC2 suspensions have been misaligned.

I used Rana's ezcaservo trick to recover MC lock. This brought the MC_REFL down to 0.7 counts. I did the rest of the alignment by moving the MC2 suspension sliders only. MC_REFL is down to 0.45-0.5 counts and TRANS_SUM is at ~16300.

Also, I found the WFS servo was left turned OFF. I re-enabled them as well.

Attached is the measurement of the transfer function from ITMX oplev error in yaw to the ALSX error signal.

The arm was locked to the IR using POX and the green beat frequency (between X arm trans in green and PSL green) in this case was 27MHz.

The transfer function looks mostly flat between 1Hz - 30Hz at 700-800 Hz/urad. The DC shift that Jenne measured from the time series is ~500 Hz/urad.

So far I have not been able to measure the TF below 1Hz without the arm losing its lock. Updates will follow.

Data xml file can be found in /users/manasa/data/140521/

Below are the transfer functions measured between the angular (pit, yaw) motion of X arm mirrors and the ALSX error signal. The measurements were again made for 1Hz-30Hz.

The transfer functions are mostly flat.

ITMX P - 200-300 Hz/urad (beat freq = 45 MHz)

ITMX Y - 700-800 Hz/urad (beat freq = 27MHz)

ETMX P - 500-600 Hz/urad (beat freq = 56 MHz)

ETMX Y - 1000-2000 Hz/urad (beat freq = 62.5MHz)

Data xml files can be found in /users/manasa/data/140521/

The Y arm green transmission had come down to 0.3 and the green steering mirrors on the Y end table required some minor alignment adjustments to bring back transmission to around 0.75 counts.

I realigned the MC mirrors and brought down MC_REFL to 0.42 and MC_TRANS_SUM came up to ~ 17400 counts.

I measured the spot positions after alignment. MC1 and MC3 are slightly off in pitch :

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
[2.0535418031770249, 0.84870716159663184, 1.9759940800847962, -1.6706240175650202, 0.089441353070240759, -1.0339963871771678]

I reset the WFS filterbank offsets and engaged the MCWFS servo. Atleast now the MC is not being thrown out of lock with WFS enabled. I have NOT touched the alignment to the WFS PDs.

I made my attempts trying to figure out what was wrong.

Checking if we are at the right X end laser temperature: 
I aligned the arms and found the Y beatnote.I blocked the light falling on the X beat PD so that the RF analyser was only looking at the output from the Y beat PD. AT the RF analyser, I found the strong Y-PSL beatnote, the X-Y beat note and a weak  X-PSL beatnote. This confirmed that we have the X end laser at the right temperature to be able to detect the beatnote. Unblocking the light on the X beat PD did not bring in any additional peaks. 

Checking the RF cabling from the X beat PD to the beat box:
I swapped the RF cables such that the signal from the Y beat PD output was going to the X input on the beatbox. I could still see the beatnote on the RF analyser. This confirmed that there aren't any broken RF cables along the X path.

Checking X green PSL alignment:
I replaced the X beat PD with the Y beat PD to check if the alignment of X&PSL green are alright. I could find the X beat note this way without any alignment tweaking.

I suspect we probably have some RF component burnt in the X beat PD. Do we have any spares lying around? There is a Koji's box with a PD having the same serial number.

IFO status report for anyone who is looking to do some locking tonight : 
The Y beat PD is back along the Y path and I have confirmed the presence of Y-PSL beat note after replacing the PD.
The X beat PD has been removed and now rests on the electronics bench for checking. 

While aligning the arms today, I noticed that enabling LSC would cause misalignment of the ETMY suspension. I haven't tried to find out what has been causing this. Could be something similar to what was noticed with the ETMX suspension a couple of weeks ago elog9969.  

Ant season has set in. I spotted and killed  a few ants around the optics and the enclosure of the PSL table yesterday. TIme for our pest control crew to get busy!

A recap of the ringdown measurements made at the 40m in mid 2012, the hardware that was installed for the same and results from the measurements.

IMC ringdown:

Hardware installed 
A trans PD was installed (elog 7122).
This PD does not exist in the trans path anymore.

Measurements
The polarity in the MC servo was flipped with the MC WFS disabled and the PD trans signal was used to look at the cavity ringdown. 
Ringdown time = 13 us
Cavity finesse from the measurement = 453 (inconsistent with actual finesse). 

Attachment: Ringdown measurement and fits

PMC ringdown:

Hardware installed
The AOM was installed before the PMC. The AOM was driven by the driver installed on the PSL table. (RF power ~1.5W @ 80MHz @1.0V modulation input). An RF switch was installed to control the AOM driver input. ZASWA-2-50DR+ was installed.
Note: The AOM was used by the ISS crew after this. So the RF switch has been removed and the AOM is no more a part of the ringdown setup.

Measurements
No measurements were made as we could not obtain relevant TTL signals to control the switch remotely.

MC autolocker and Ottavia

I assume that the MC was left with a fully functioning autolocker enabled and running on ottavia last night.

But as of this morning, the MC autolocker is NOT running alright. The MC was in an unlocked state and the autolocker has been doing nothing to the servo sliders.  I think this was the state of MC since last night as seen on the stripchart.

Since the autolocker has been left to run on ottavia, I tried to look at the cronlogs to see if it running the autolocker script at all. I looked at the list on ottavia and it has the MCautlocker on it cronjobs list and yet doing nothing.

Later, I did a softreboot on ottavia when I could not ssh into it from rossa or pianosa. ssh to ottavia now works just fine.

I am leaving Ottavia at this and returning to the more important job of fixing the MC. I locked the MC manually and am now working on the alignment.

Framebuilder

Also, the CDS FE status screen had red lights blinking as if it required an 'mxstream restart'. I did the same and it did not fix the problem. So I tried to restart fb using the usual 'telnet fb 8087'; but could not restart fb that way.

Attached: FE status screen

The IMC stayed locked last night, but with  a high REFL ~3.0. I found the WFS servo OFF; so went ahead and enabled it. (Did somebody disable it for reasons not elog'd?)

MC returned to a happy state. But the WFS offsets are quite large. So I tweaked the alignment and got MC REFL down to ~0.45 and MC TRANS SUM to ~16500 counts. MC WFS offsets also dropped significantly after this without any need to touch the alignment to the WFS PDs.

PMC was relocked.

MC did not need any fixing to its alignment. I had to lock it manually and autolocker is set running now. So that should take care of things

The arms were aligned and ASS'd for IR PDH.

Green light PDH locks to the arms alright.

I moved stuff on the PSL table to accommodate the PMC ringdown setup.

I used the beam that leaks from the steering mirror at the PMC transmission that was dumped to a razor blade dump. I installed a Y1 to steer the beam to the ringdown PD. Power in the beam 75mW.

Results are in here elog 

The RF cables have been routed incorrectly. The cables run to the module from the front of the rack. We cannot close the doors to the racks if they are to remain this way.

I have asked Nichin to reroute the cables properly.

 It was ~7.5mW and measured ~2V at the PD output (given its range 0-5V ) on the oscilloscope . So PD is safe !

After the fits, here are the numbers!

* We have a huge difference to the AOM switching time that was measured. The spec sheet mentions acoustic velocity in the material to be 4.2 mm/us and the well matched diameter in the AOM to be 1100 um. This would give a switching time ~ 200 ns. We could probably be having a much smaller beam size in the AOM for the measured switching time.

* The PMC  parameters that I had been referring to from the wiki were actually wrong and which was the reason for the mismatch that I was finding. I modified the wiki according to the found references to the actual measurement here: PMC parameters The measured values now and then match pretty well.

* Since the AOM does not change the power of the output beam by very much, what we see is actually a step response. Also, we have a lot of noise in the data obtained at the PD. 

RXA: some more comments...

1. The fact that the AOM can only modulate the power by a tiny bit means that it is very mis-aligned or that the driver is broken.
2. You need to take into account the AOM step time in the calculation of the PMC step time. Its not a step response if the input step is not a step, but a exponential.
3. I wouldn't trust that old John Miller entry for the PMC Finesse. As you can see from his elog, even he didn't trust it.
4. As we were discussing before, making a little step is not the same as a full ringdown. cf. G000413 and T900007

I think we should revisit the AOM alignment because the last time it was aligned, PMC trans dropped from 0.84 to 0.15 (a little more than 80%) for 0-1V modulation input to the AOM driver [elog]. The drop in power right now is ~10-15% only.

I could not find any elogs of AOM alignment touchups after Oct 2012.
But can the ISS team throw some light on the status of AOM when they were installing the ISS servo before we decide on touching the AOM alignment? [elog]