We used to do violin mode and test mass body mode notches in the SUS-LSC filter modules. Now we want them balanced in the LSC and triggered by the LSC, so they're in the filter modules which go from the the LSC output matrix to the SUS.

Today, we were getting ETM violin mode ringups while doing ALS hunt and so we moved the bandstops into the LSC. I also changed the bandstop from a wide one which missed the ETMX mode to a double bandstop which gets both the ETMX and the ETMY mode. See attached image of the Bode mag.

 Not sure why, but Rana and I didn't see the super high Xarm noise with ALS that we reported last night (elog 10382).  

The in-loop ALS noise seems fine.  The out of loop measurement while the ALS is locked is a little tricky, since ALS hold the arms within the POX/POY linear ranges.  

Here is the in-loop noise:

Again unknown, but about 6 hours ago (so ~8am) the offset disappeared. 

Here's a 1-day trend:

One question answered, but another raised. The offset came from LSC-TRY switching to the ETMY-QPD signal from ETMY-TRY (Hi gain pd). 

BUT WHY

[Rana, Jenne, EricQ]

We did several things tonight.  First, a list (so I can remember them all), and then some details.

(1) Jiggled ETMY SUS cables, removed kicks.

(2) Locked X and Y ALS, looked at POX, POY as out of loop sensors.

(3) Measured stuff (?) at the Yend.

(4) Reconnected REFL DC to SR560.

(5) Attempted CARM offset reduction.

Item 1:

When Rana and I started locking this evening, we saw (as Q has been witnessing for a while now) the ETMY kick a lot.  However, it seemed to be kicking even more than usual.  Since Q had been down at the end station recabling things, we wondered if a SUS-related cable got bumped.  Rana went down to the end and pushed all the cables into their receptacles.  One of the last sets that he pushed was the satellite box.  We didn't have walkie-talkie communication, but the DC offset of the ETMY oplevs changed just a minute or two before he returned to the control room.  So, we guess that it was the satellite box cables that were loose.  Unfortunately, there is no clear way to strain relieve them, which is why they can so often be troublesome.  Anyhow, the ETMY hasn't kicked since.

Item 2:

We locked the arms with ALS.  We saw that the POX signal was about 20% of the full pk-pk height of the PDH signal, so it's mostly within the linear range, but not entirely.  It is what it is, however, and we took measurements assuming that it's okay.  I calibrated POX by putting an excitation onto ETMX, and matching the height of the peak in POX and BEATX_FINE_PHASE_OUT_HZ.

Q and Rana had also [remembered / put in / something] a digital readback for the end green PDH error point.  Q went down to the end and gave me a number of 2600 Hz/V for the err mon port of the PDH board, which is what is connected to the ADC.  With that and 20/2^16 V/cts, I had a calibration of 0.8 Hz/ct. 

What we see in this plot is that the green end PDH is not the limiting noise for the POX out of loop measurement of the residual arm motion.  Also, in the multi-color metrology paper, Fig 7 (which is posted in the control room), we see at about a little over 1 Hz a ratio of about 4.5 between the residual motion and the AUX PDH error signal.  In today's plot, I see a ratio of about 20.  I infer from this that the green PDH for the Xarm is fine, and that we may want to re-look at the ALS digital loop, but we should leave the X PDH alone.

Here is the Xarm plot:

Q took the data for the Yarm plot, so hopefully he can give it to us in the morning.  What we did notice was that the noise was much worse for the Yarm.  This prompted Item 3, measuring the loop.

Item 3:

Q and Rana went down to the Yend and measured some things.  They came back, and said that they hadn't changed anything in analog while they were down there.  One thing that Q did note was that we have almost 90 degrees of phase margin (since it's a 1/f loop), and about 10 dB of gain margin, above the UGF.  So, we're in good shape for being able to try triggering the boost on the PDH box.  Q will give us more notes on this work, as well as plots, in the morning.

Item 4:

At some point, I remembered that Q and Gabriele had repurposed the SR560 that we had been using for the REFLDC input to the common mode board.  So, Q went and put it back, so that REFL DC goes into the SR560, and so does a DAC channel so that we can remotely set the offset.  The A-B output goes to the REFL11I whitening channel, since real REFL11I goes into the input of the CM board.  I think that today, the SR 560 was left at a gain of 1.

Item 5:

We decided to carry on and try to reduce the CARM offset some.  An annoyance is that the Yarm still has pretty significant low-frequency noise, but the idea is that if we can get over to the sqrtInvTrans signals, it will be fine.

So, we didn't get much farther than we had in the past, but it was nice to get there at all again.  I ran the carm_cm_up script (many times).  One of the times, all I wanted to do was see how much I could reduce the CARM offset.  CARM was on sqrtInvTrans, DARM was on ALS diff, and I was able to get the arm powers up to about 2.5.  I don't know why I lost lock.  The sqrtInv signals should be good until at least arm powers of 20 or so. 

I was able to see the REFL DC dip, but only a teensy tiny bit.  It went down by maybe 1 count.  Q suggested looking at how deep it could get while leaving CARM and DARM both on ALS, and setting both offsets to 0.  We were seeing arm flashes of about 50 counts, and REFL DC went from 0 to -800.  So, I wasn't seeing much of a REFL dip, but it was definitely there when I went to arm powers of 2ish.

We tried looking at different sqrtInv options for DARM, and haven't come to any real conclusion.  In the plot below, we are looking at a swept sine between DARM_IN1 (ALSdiff) and either MC_IN1 0.3*(sqrtInvX - sqrtInvY) or SRCL_IN1 (TRX - TRY / sqrt(TRX + TRY) ):

We have a few things to add to the to-do list:

* Put UGF servos for LSC loops in place.

* Implement UGF "servos" (per Koji's suggested method) for phase trackers.

* Write a lockloss script that is run by the ALS watch scripts - print a PDF of error and control signals for every lockloss, and save it somewhere.

* Fix up Ygreen modematching on the PSL table.  The X green spot is quite similar on the camera to the corresponding PSL green spot.  However the Y green spot is not at all the same as its PSL green spot. 

We want both the X and Y phase trackers to have the same UGF, so that the X and Y ALS signals are subject to the same phase characteristics and can be nicely decoupled into CARM/DARM. 

I've started implementing a simple normalization scheme that Koji suggested, namely, dividing the I output of the phase tracker by a low passed version of the Q output. (Since the I is servoed to zero, the radius of the error signal in the IQ plane is essentially equal to the Q value) I put some simulink logic into the IQLOCK library part that BEAT[XY]_FINE are instances of to switch the normalization on/off, and to protect from divide-by-zeros. I also exposed the switching and FM on the ALS screen.

I then tried using it, to mediocre results. I put a 10mHz LP in the filter module, found a Y-Arm beat, set the phase tracker gain to give me a 2kHz UGF, and then set the gain of the UGH normalization FM to turn the current average Q to unity. 

I then moved the laser temperature around to get different beatnote locations/amplitudes, hoping that the phase tracker UGF would stay the same when the UGH normalization was on.

It did not.

It did, however, correct it in the right direction... more work will be done with this, to try and make it useful. There's also the unfortunate effect that locking/unlocking the green causes erratic phase tracker output, which messes with the input to the normalizing LP filter, so if one were to leave it switched on, wonky stuff would come out. I don't want to go overboard with triggering shenanigans before I even get it working in the first place, though.  

FYI and FMI

Phase tracker UGF is  Q_AMP * G * 2 PI / 360 where Q_AMP is the amplitude of the Q_ERR output and G is the gain of the phase tracker.

For example: Q_AMP = 270, G = 4000\ => UGF = 1.9kHz

Q put the X PDH box back, so that I could try locking, and remember which end is up after a week away.

I am unable to hold ALS comm/diff for any length of time. Only once today did I hold it through the FM3 boost turn-on.  So, I looked at the individual arms.

Xarm, even though it's the one that Q is seeing this saturation problem with, seems fine. 

Yarm however is having trouble holding lock for more than a few minutes at a time.  The green beam stays locked to the arm for ~infinity, so I'm not so worried about the PDH box right now.  If I look at the error and control points of the ALS digital servo, the Yarm is much more noisy above about 20 Hz.  Something that I might think of for this kind of mismatch at higher frequencies is poorly matched whitening / dewhitening, or none at all for the Yarm, however this doesn't look like that to me.  Based on the shape of the spectra, I don't think that we're running into ADC noise. For this plot, both arms are individually locked with ALS feeding back to the ETM, gain magnitude of 15 (Xarm gets a minus sign because of our temperature / beatnote moving direction convention), FMs 1,2,3,5,6 on.  Something that seems critical for getting the Yarm to have the FM3 boost without losing lock is having the SLOW temperature servos on for a little while so that the PZT output (as monitored on the temp servo screen) for the end lasers fluctuate around zero. Right now, both beatnotes are at about 62MHz, with an amplitude of about -31dBm.

I still need to do a somewhat more thorough investigation of what might be causing the Yarm locklosses.  Is the length-to-angle decoupling worse for ETMY than for ETMX?  Am I moving the arm length so far that the PZT can't follow within its actuation limits?  Does the Yend PDH box have a similar saturation to the Xend box, but somehow (a) worse, and (b) not as obvious so we didn't suspect it before? 

I need to put this plot into calibrated units, and also include the low frequency monitor that we have of the PDH error point (all of which are _DQ channels).

Things to do:

* Figure out Xend PDH box saturation issue.  Is Yend seeing same saturation in the variable gain amplifier?  We have 3 spares of these chips in the Plateau Tournant Bleu, if we need them. 

* Check Yarm ALS stability.  (NB:  The arms have been individually locked for the last 15 min or so while I've been writing, so maybe letting the slow servo settle is the key, and this is not something that needs work).

* Get CARM on DC Trans, DARM on AS55Q (after arm powers of about 1).  Can we see good REFL DC dip?  Should we try using just the transmission PD signal as the error signal for the CM board, if we aren't close enough to resonance to use REFL DC?

From EricQ's simulations reported in elog 10390, we want to transition from ALS comm to DC transmission signals around 500 pm.  However, around 100 pm, the DC transmission signals have a sign flip, so we don't want to have the ALS swing that close to the CARM resonance.  So.  We want to be at about 500 pm, and not touch 100 pm.  So, we don't want our peak ALS motion to go beyond ~400 pm.  Which means that we need to have less than about 40 pm in-loop RMS, to avoid hitting 400 pm.  This is an ALS requirement, but since the analog PDH box is what forces the end laser to follow the arm cavity, and thus give us information about the arm length fluctuations, the PDH residual noise is part of our sensor noise for the full ALS.  So, we need to have the PDH in-loop RMS be less than 40 pm, integrated from a few kHz down to at least 30 mHz. Recall that above the ALS UGF (of about 200 Hz), the sensor noise will be suppressed by 1/f, so we should take that into account when we are looking at the PDH error signal, before we calculate the RMS motion.

Q also measured the in-loop error signal with the current Yend PDH box in elog 10430, and it looks like most of the RMS is coming from a few hundred Hz.  I designed a hack to the PDH board boost that has a zero at about 2kHz, and a gain of 30 at DC, so that we will win by squishing all that RMS.  Also, it shouldn't be too aggressive, so we should be able to leave it on all the time, and still acquire lock of the green laser to the arm, without having to do triggering.

The board schematic is at DCC D1400294.  The boost is also called the "integrator stage", although it will no longer be a simple integrator.

EDIT, JCD:  This cartoon is not correct for the non-boosted state, doesn't include effect of R16.

Okay, went back to the drawing board with Rana and Koji on PDH box stuff.

Currently (at least for the Yend), in the boost OFF state, we have an overall gain of about 50.  This is crazy big.  Also, the zero in the "transfer function stage" is around 1kHz, however our green cavity pole is (calculated) to be around 20 kHz.  Since these are supposed to cancel but they're not, we have a wide weird flat region in our loop TF.

So.  I calculated the changes to the TF stage that I'll need so that I have an increase of about 20 in DC gain, kept the pole at the same ~20Hz, but moved the zero way out to 18kHz.  I also calculated the changes needed for the integrator stage to make it effective at much higher frequency than it was designed for.  Now the pole is at 75 Hz, and the zero will be at 1.6kHz, and the high frequency gain will stay pretty close to the same with and without the boost.

Planned new TF stage:

Planned boost stage (with and without boost activated):

New boost stage only, so you can see the phase:

The schematic, modified to show my planned changes (which I will put in the DCC after I make the changes):

 Going off some discussion we had at lunch today, here is my current knowledge of the state of cavity lengths. 

Acknowledging that Koji changed the sideband modulation frequency recently, the ideal cavity lengths are (to the nearest mm):

• Lprc = c / ( 4 * fmod) = 6.773 m
• Lsrc = c / ( 5 * fmod) = 5.418 m

We when last hand measured distances, after moving PR2, we found:

• Lprc  = 6.752 m = 2.1 cm short
• Lsrc  = 5.474 m = 5.6 cm long. 

However, when I looked at the sideband splitting interferometrically, I found:

• Lprc = 6.759m = 1.4 cm short

This is only 5mm from the hand measured value, so we can believe that the SRC length is between 5 and 6 cm too long. I'm building a MIST model to try and see what this may entail. 

Jenne made her board modifications, and the measured TF agreed with the design. Alas, the green would not lock to the arm in this state. 

I think that the reason is that the new TF does not have nearly as much low frequency gain as the old one, for a given UGF. Thus, for example, the 1Hz noise due to the pendulum resonance, has 30dB less loop gain suppressing it. 

NEED MORE 

Com'on. This is just a 60ppm change of the mod frequency from the nominal. How can it change the recycling cav length by more than a cm?

https://wiki-40m.ligo.caltech.edu/IFO_Modeling/RC_lengths

This describes how the desirable recycling cavity lengths are affected by the phase of the sidebands at non-resonant reflection of the arms.

If we believe these numbers, L_PRC = 6.7538 [m] and L_SRC = 5.39915 [m].

Compare them with the measured numbers

• Lprc = 6.752 m
• Lsrc  = 5.474 m

You should definitely run MIST to see what is the optimal length of the RCs, and what is the effect of the given length deviations.

As EricQ mentioned in last night's elog, the modifications were made to the Yend (SN 17) uPDH board.

R31 became 49.9 Ohms, R30 became 45.3kOhm, R24 became 1.02k, R16 became 1k, a new flying resistor is tombstoned up against R24 and connected by purple wire to C6 and it is 20k.  C28 is 183nF and C6 is 100nF.  These numbers were used in Q's simulation last night.

Koji correctly points out that I naïvely overlooked various factors. With a similar analysis to the wiki page, I get:

• Ideal arm length of 37.795 m
• Ideal PRC length of 6.753 m
• Ideal SRC length of 5.399 m

This means that:

• The PRC, measured at 6.759m, is 6mm long. 
• The SRC, measured at 5.474m, is 7.5 cm long

Next step is to see how this may affect our ability to sense, and thereby control, the SRC when the arms are going. 

MIST simulations and plots are in the attached zip. 

[Rana, Jenne, EricQ]

* Too much gain overall on Yend box, needed attenuator on output to get lock.  Rethought gain allocation.  Resoldered board, installed, Ygreen locks nicely.  Error point and control point spectra, box TF and open loop TF data collected, to be plotted.

* Q replaced the Xend box, with a matching TF.

* Locked both arms individually, Yend has lots of low freq fluctuation, Xend has some.  Can't do out of loop measurement since we're going well beyond the range of the PDH signals (Yarm RIN is between 1/2 and 1.) Plot TRX and TRY spectra with ALS lock vs. IR lock to get an idea of what frequencies we have a problem with.

* Tried comm/diff locking anyway.  Works.  Used cm_up script to get CARM to sqrtInvTrans.  Went to powers of about 0.5 (hard to say really, because of fluctuations), put sine at 611.1 Hz, 200 cts onto ETMs (-1*x, +1*y), looked at TF between ALS diff and AS55Q.  Put that amount into the static power normalization spot for AS55.  In steps of 0.1, reduced ALSdiff input matrix elements and increased AS55->DARM element.  2 (3?) times was able to get to AS55Q for DARM.  Lost lock once unknown reason, while reducing CARM offset.  Lost lock once trying to turn on FM4 LSC boost for DARM.

TRX/TRY spectra:

I locked the arms with IR, and measured the beatnote spectra to get the out of loop noise for the PDH boxes. 

Unfortunately, we don't have a reference saved (that I can find), so we're going to have to compare to an elog of Koji's from a month ago.  I have created an out of loop ALS reference .xml file in the Templates/ALS folder.

As we can see from Koji's elog 10302, the Xarm seems to have stayed the same, but the Yarm seems to have increased by about an order of magnitude below 100 Hz.  :(

This afternoon, after Q and Manasa finished recovering from the activities of the morning, I aligned the IFO, and went to the Yend to touch up the alignment of the green to the arm.  I don't know if it was the alignment (I didn't do the PSL table), or I happened to have a good combination of laser temperatures, or what, but the Yend ALS noise was super good.  After that, the low frequency noise contribution is different lock-to-lock, and I haven't discerned a pattern yet.

One thing that we want to try is to get DARM to AS55 so that we're entirely off of ALS (assuming we've already gotten CARM to sqrtInvTrans).  However, according to Q's simulations, we have to get past arm power of a few before we are within the AS55 linewidth.  I have a DTT running showing me the phase between AS55 and ALSdiff as I reduce the CARM offset, but I haven't been able to get close enough to see the sign flip when CARM is on sqrtInvTrans.  If I just sweep through with both CARM and DARM on ALS, I see the sign flip.  I've tried a few different things, but I have not successfully gotten a transition to AS55 while the arm powers were above 1.  Empirically,  I think I want them at at least 3 or 4.

Koji suggested locking the DRMI rather than PRMI, to widen the AS55 linewidth, but I haven't tried that tonight.  Maybe tomorrow night.

I have made a ruidimentary lockloss plotting script, that I have put in ..../scripts/LSC/LockLossData, but I'm not satisfied with it yet.  Somehow it's not catching the lockloss, even though it's supposed to run when the ALS watch/down scripts run.  I'll need to look into this when I'm not so sleepy.

Q, can you please work on figuring out the phase tracker gain tracker?  It will be nice to have that functional so we don't have to fret about the phase tracker gains. 

Manasa, can you please estimate what kind of mode matching we have on the PSL table between the arm greens and the PSL green?  We *do not* want to touch any optics at this point.  Just stick in a power meter to see how much power we're getting from each beam, and then think about the peak height we see, and what that might tell us about our mode overlap.  If we determine it is total crap, we can think about measuring the beams that go either toward the camera, or the DC PDs, since neither of those paths require careful alignment, and they are already picked off from the main beatnote path.  But first, what is our current efficiency?  Yarm is first, then Xarm, since Yarm seems worse (peak height is larger for non-00 modes!)

We developed a fairly sophisticated lockloss script at the sites, which you could try using as well.  It's at:

USERAPPS/sys/common/scripts/lockloss

It requires a reasonably up-to-date install of cdsutils, and the tconvert utility.  It uses guardian at the sites to determine when locklosses happen, but you can use it without guardian by just feeding it a specific time to plot.  It also accepts a list of channels to plot, one per line.

 Q has pointed out that we expect a sign flip in the AS55 signal for DARM as we reduce the CARM offset in the PRFPMI case.  Koji also mentioned that the SRC will help broaden the DARM linewidth.  I wanted to check and think about these things with my Optickle simulation.  Q is working on confirming my results with Mist.

The simulation situation:  

* The demod phase for AS55 is set in the MICH-only case so that the MICH signal is maximized in the Q-phase.  I do not change the demod phase at all in these simulations.

* Cavity lengths (arms, recycling cavities) are the measured lengths.

* I look at AS55 I and Q as DARM sensors (i.e. I'm doing DARM sweeps) as a function of CARM offset, for both PRFPMI and DRFPMI cases.

Spoiler alert!  Conclusions:

* In the PRFPMI case, the DARM signal shows up with approximately equal strength in the I and Q phases, so we suffer only about a factor of 2 if we do not re-optimize the demod angle for AS55.

* In the DRFPMI case, the DARM signal is a factor of 1,000 smaller in the Q-phase than the I-phase, which means that the ideal demod phase angle has moved by about 90 degrees from the MICH-only case.  We must either use the I-phase signal or change the demod phase by 90 degrees in order to acquire lock.

* In the PRFPMI case, there is a sign flip for DARM on the AS55 PD around 100pm, so we don't want to use AS55 for DARM until we are well inside 50pm, and aren't going to fluctuate out of that range.

* In the DRFPMI case, there is no such sign flip, at least out to 1nm, so we can use AS55 for DARM as soon as we see a viable signal.  This is super awesome. The caveat is that the gain changes significantly as we reduce the CARM offset, so we either need a UGF servo (eventually) or careful watching (for now).

* The AS55 linear(-ish) range is much broader in the dual recycled case, which is yet another reason why getting DARM on AS55 will be easier for DRFPMI.

Why didn't we do it already?

* To put the SRM QPD back, we'd also have to move Steve/EricG's laser.  Since I had other things to do, I left the setup for tonight, but I think I will want it for tomorrow night.

* Monday night (and tonight) we can pretty reliably get DARM onto AS55Q for the PRFPMI case, and I don't know what the cause has been for my locklosses, so I thought I'd try to figure that out first.  

Plots!

First up, the current transition we've been trying to handle, PRFPMI DARM to AS55Q.   I also plot AS55I, and we see that the signals are roughly the same magnitude (the x axis isn't the same between these plots! sorry), so we aren't screwed if we don't change the demod phase angle.  We'll be better off once we can do a re-optimization, but this is assuming we are stuck (at first) with our MICH-only demod phase angle.

Next up, the same plots, but for the DRFPMI case.  Note here that there is a factor of about 1000 in the y-axis scales, and also that there is no switch in the sign of the zero-crossing slope for the I-phase.

And here is the same data (DRFPMI case), but zoomed out for the Q-phase, so you can see the craziness of this phase.  Again, this is much smaller than the signals in the I-phase, so I'm not too worried.

Game plan:

* Steve leaves the SRM oplev back in its nominal location (we can worry about aligning the mirror, and aligning the beam on the PD, but please put it back approximately where it came from).

* Try DRMI + 2 arm locking, which I don't think we have ever actually done before.  Hopefully there won't be any tricks, and we can get to an equivalent place and successfully get DARM to AS55.  

* .... Keep going?

[Jenne, EricQ]

No major progress today.  

I fixed a bug in my lockloss script that was asking it to start gathering data just after the lockloss, rather than some seconds beforehand.  Ooops.  Anyhow, with this handy-dandy plotting, I still don't know why we are losing lock when we have PRMI on REFL33, CARM on sqrtInvTrans, and DARM on AS55.  I don't see any oscillations, just the arm power drops off, and a moment later the POP power drops.  

For example, here is one of the best states we got to tonight.  Data for this is in ..../scripts/LSC/LocklossData/1094369700 .  You can re-create the plot by going to ..../scripts/LSC/LocklossData/  and doing ./PlotLockloss.py 1094369700 .  We had set the triggers for the trans PD/QPD such that we were using the QPD transmission signals the whole time (above trans of 0.2).  We saw that the noise at high frequency during low transmission powers for sqrtInvTrans as an error signal was higher using the QPDs than with the Thorlabs PDs, but that both cases are below the noise for ALS.  The arm powers were pretty steady above 3 for the last bit of this lock stretch.  I lost lock while trying to transition DARM over to AS55Q.  CARM was on sqrtInvTrans(QPDs), PRMI on REFL33 I&Q as usual.

Other things from this evening:

* When I was starting, I saw that when I locked the PRMI, the PRM was oscillating in pitch. Oscillation only happened when PRM pitch oplev was on.  I'm not sure what could have changed to make the oplev loop unstable, but the gain was 7.0, and now I have left it at 5.0.

* I recentered the PRM and ITMY oplevs.

* Plugged in the Yend PDH error monitor and pzt output monitors, since I forgot them last week.  Hopefully this will allow the Yend SLOW servo to work, and keep us away from the limits of the PZT range.

Some small things I did tonight which did little to nothing to help:

• I reset the offsets in the SQRTINV FMs to try and match the DC level of the ALS CARM error signal as best as possible, to avoid moving away from the set-point too much, as I was worried we were wandering into regions of too low optical gain. 
• I turned off the WFS, and hand tweaked the MC alignment. The WFS loops / matrices definitely have some room for improvement, and I was worried that excess angular motion of the MC was coupling into CARM. MC refl is much calmer in the last ~1.5 hrs since I turned off the WFS. 

My main concern with tonights situation was the huge low frequency fluctuations of TRY while CARM/DARM locked on ALS. We saw this being very smooth very recently, but when one arm is fluctuating by multiple line widths, it isn't surprising that locks aren't stable. I want to know why the out of loop stability is so unpredictable. 

Estimate loss along the Y arm beat path:

1. Measured the beam powers (before the beam combiner): 
Y Arm green = 35 uW
Y PSL green = 90 uW

==> P_beat ~ 2 * sqrt (35 uW * 90 uW) ~ 112 uW

2. Expected power of RF signal
Assuming the PD to have transimpedance ~ 2kV/A and responsivity ~ 0.3A/W, 
the expected power of the RF signal = (P_beat * Transimpledance* Responsivity)^2 / (2 * 50ohm) ~ 45uW = -13.5 dBm

3. Measured power of Y arm beat signal

Turned OFF the beat PDs and rerouted the RF cables such that the spectrum analyzer was reading the RF signal from the Y beat PD itself (without any amplifiers or the beat box itself in the path).  
Turned ON the beat PDs and the Y arm beat signal power on the spectrum analyzer measured -58dBm
Even if we consider for losses along the length of the cables, we are still at a very bad state. 

4. Bad mode matching??
I don't think mode matching is our main problem here.
Toggling the shutter several times, even with the non-00 modes, the maximum beat power we can see is -50dBm which is still very far from the actual expected value.

Koji and Manasa did some work on the PSL green situation today (Koji is still writing that log post up), but I just measured the Yarm out of loop sensitivity, and WOAH. 

The beat is -11.5dBm at 42.8 MHz.  Koji said the sweet spot is around 30 MHz.  The out of loop sensitivity is 400 Hz RMS!  Something to note is that the Y beatnote still has a 20dB amplifier before going to the beatbox, but the X does not.  We had been worried about saturation issues with the X, so we took out the amplifier.  However, I might put it back if we win big like this.

Recall from elog 10462 that I had saved a reference of the out of loop noise for both X and Y, but Y was much noisier than X.  The references below are from that elog, and the new Y is in dark blue. (Edit, 9:18pm, updated plot measuring down to 0.01Hz.  This is the new reference on the ALS_outOfLoop_Ref.xml template).

EDIT:  (Don't worry, I'm going to measure X too, but right now the beam overlap on the camera is not good, as if something drifted after Koji and Manasa closed up the PSL table)

Touched up the alignment for X on the PSL table.  Current beatnotes are:  [Y, -13.5 dBm, 74.1 MHz], [X, -22 dBm, 13.9 MHz].  Red is the current X out of loop, and I've saved it as the new X reference on the template.

[Koji Manasa]

We made quantitative inspection of the X/Y green beat setup on the PSL table.

DC output of the BBPD for each arm was measured by blockiing the beams at either or both side of the recombination BS.

The power over lap for the X arm beat note setup was 7.8% and is now 53%.
There is 3dB of headroom for the improvement of the mode overlap.

The power over lap for the Y arm beat note setup was 1.2% and is now 35%.
There is 4dB of headroom for the improvement of the mode overlap.

The RF analyzer monitor for the beat power is about 10dB lower than expected. Can we explain this only by the cable loss?
If not it there something causing the big attenuation?

             XARM   YARM
o BBPD DC output (mV)
 V_DARK:   -  3.3  + 1.9
 V_PSL:    +  4.3  +22.5
 V_ARM:    +187.0  + 8.4

o BBPD DC photocurrent (uA)
I_DC = V_DC / R_DC ... R_DC: DC transimpedance (2kOhm)

 I_PSL:       3.8   10.3
 I_ARM:      95.0    3.3

o Expected beat note amplitude
I_beat_full = I1 + I2 + 2 sqrt(e I1 I2) cos(w t) ... e: mode overwrap (in power)

I_beat_RF = 2 sqrt(e I1 I2)

V_RF = 2 R sqrt(e I1 I2) ... R: RF transimpedance (2kOhm)

P_RF = V_RF^2/2/50 [Watt]
     = 10 log10(V_RF^2/2/50*1000) [dBm]
     = 10 log10(e I1 I2) + 82.0412 [dBm]
     = 10 log10(e) +10 log10(I1 I2) + 82.0412 [dBm]

for e=1, the expected RF power at the PDs [dBm]
 P_RF:      -12.4  -22.6

o Measured beat note power (before the alignment)     
 P_RF:      -23.5  -41.7  [dBm] (38.3MHz and 34.4MHz) 
    e:        7.8    1.2  [%]                         
o Measured beat note power (after the alignment)      
 P_RF:      -15.2  -27.1  [dBm] (26.6MHz and 26.8MHz) 
    e:       53     35    [%]                         
Measured beat note power at the RF analyzer in the control room
 P_CR:      -25    -20    [dBm]
Expected    -17    - 9    [dBm]

Expected Power:
Pin + External Amp Gain (0dB for X, 20dB for Y)
    - Isolation trans (1dB)
    + GAV81 amp (10dB)
    - Coupler (10.5dB)

No breakthroughs tonight. 

DRMI didn't want to lock with either the recipe that we used a year ago (elog 9116) or that was used in May (elog 9968).  Being lazy and sleepy, I chickened out and went back to PRFPMI locking. 

Many attempts, I'll highlight 2 here.

(1) I had done the CARM -> sqrtInvTrans transition, and reduced the CARM offset to arm powers of about 7, and lost lock.  I don't remember now if I was trying to transition DARM to AS55, or if I was just prepping (measuring error signal ratio and relative sign).

(2) I stopped the carm_cm_up script just before it wanted to do the CARM -> sqrtInvTrans transition, and stayed with CARM and DARM both on ALS.  I got to reasonably high powers, and was measuring the error signal ratios I needed for CARM -> REFL DC and DARM -> AS55.  Things were too noisy to get good coherence for the DARM coefficient, but I thought I was in good shape to transition CARM to REFL DC (which looks like REFL11I, since REFLDC goes to the CM board, and the OUT2 of that board is used to monitor the input to the board. )  Anyhow, I set the offset such that it matched my current CARM offset value, and started the transition, but lost lock about halfway through.  CARM started ringing up here, and I think that's what caused this lockloss.  Could have been the CARM peak, which I wasn't considering / remembering at the time.

Daytime activity for Thurs:  Lock DRMI, maybe first on 1f signals, but then also on 3f signals.

I took a quick measurement of the ALS stability, using POX and POY as out of loop sensors, using a CARM calibration line to line POX and POY up to the calibrated PHASE_OUT channels at 503Hz. 

• X arm RMS ~1kHz
  • Could use more low frequency suppression
• Y arm RMS ~200Hz
  
  • 

 Tonight I worked on DRMI locking.  

I think the reason the May2014 DRMI recipe wasn't working for me is because I wasn't including the REFL11 -> SRCL element.  I had left it out because (a) I didn't think we should need it and (b) REFL11 is going through the CM board.  

Tonight, I flipped the switch on the CM screen so that OUT2 was seeing REFL11I, not REFLDC, so I had REFL11 in the usual place.  I reset the demod phase, since we had left it at zero for CM stuff. 

Setting demod phases for PRMI:

I locked PRMI on sideband, REFL 33 I&Q and drove PRM.  REFL55 was at 55deg, and I changed it to 33deg to minimize the peak in the Q-phase.  REFL11 was a 0deg, and I set it to 17deg.  I also checked the AS55 phase in the MICH-only case, and changed it from 14.75deg to 24.75 deg.

The May 2014 recipe (elog 9968) calls for adding 25 degrees to the REFL55 phase, so I put REFL55 at 58deg for DRMI locking.

After that, using the parameters in the May2014 recipe, the DRMI just locked.  Awesome!

I checked the demod phases with DRMI lock.  REFL11 stays at 17 degrees.  If I actuate the SRM, I get the largest peak in the I-phase of REFL55 with a phase of -143deg, but the acquisition is best with phase around 55deg.  [Note, as Q points out, I wonder if SRCL is mostly locked with REFL11I for some magical reason, which is why it didn't matter so much that I put a sign flip into REFL55...I wonder if fixing our macroscopic length offset in SRCL will fix this].  I also changed the REFL165 phase from -155.5deg to +145deg.

By looking at transfer functions at an excitation frequency, I expected that I should be able to hold SRCL and MICH on REFL165, with matrix elements -0.085 for REFL165I->SRCL and -0.23 for REFL165Q->MICH.  I was not able to acquire with these values, nor was I able to ramp the matrix elements while keeping lock.

So, I tried moving PRCL to REFL33I, which did work.  I used 1.245*REFL33I->PRCL, but left SRCL and MICH on REFL55 I&Q, with the REFL11I->SRCL element also there. This is where I started trying to get rid of the REFL11I element, but couldn't maintain lock most times, and could never acquire lock without it.

Next up, checking the MICH->SRCL coupling due to the output matrix.  I did as Koji did in elog 8816 , but first I copied the notches in FM10 of MICH over to PRCL and SRCL (old notch freqs were SRCL=566.1Hz, PRCL=675.1Hz, now they're all 475.1Hz).  I drove BS, and checked that the PRM element minimized the peak in REFL33I, the PRCL error signal.  I also added an SRM element to reduce the peak in REFL55I, the SRCL error signal.  I ended up with 0.5*BS, -0.284*PRM, -1.5*SRM for MICH drive, and unity in the PRM and SRM elements for PRCL and SRCL, respectively.

I measured the SRCL open loop gain, and the UGF was pretty low, so I increased the SRCL gain from 0.2 to 0.5 to make the UGF be around 70Hz.  I measured PRCL and MICH also, and they matched their references.

I worked a little bit on trying to remove REFL11 from the SRCL error signal, but didn't get anywhere.  I'm leaving the IFO to Q for the rest of the night.

To sum up, here is the set of parameters that worked for DRMI locking.  (These are saved as the template on the IFO Config screen.):

DEMOD PHASES:

REFL11:  17 deg

REFL33: 140.5 deg (not changed tonight)

REFL55: 58 deg  (58deg for DRMI, 33deg for PRMI)

REFL165: 145 deg

AS55: 24.75 deg

INPUT MATRIX

MICH = 0.15 * REFL55Q

PRCL = 1.245 * REFL33I

SRCL = -0.09 * REFL11I + 1.0 * REFL55I

DOF Triggers

MICH, PRCL, SRCL all on POP22I, 50:10

GAINS

MICH = 1.0

PRCL = -0.02

SRCL = 0.5

FM triggers 

MICH:  35:2, 2 sec delay, FM 2, 3, 6, 9

PRCL:  35:2, 0.5 sec delay, FM 2, 3, 6, 9

SRCL:  35:2, 5 sec delay, FM 3, 6, 9  (always lose lock trying to engage FM2).

OUTPUT MATRIX

MICH = 0.5 * BS +  (-0.284)*PRM + (-1.5)*SRM

PRCL = 1*PRM

SRCL = 1*SRM

 Since DRMI didn't get fully commissioned, I tried my hand at PRFPMI locking with the newly improved ALS performance. 

ALS seemed reliable, I think my main limiting factor was the PRMI locking. We should set up a restore script for PRFPMI that is a superset of the ALS CARM DARM, because the current restore script doesn't put all the vertex settings back, so I was trying to lock for a while without the FM boosts on PRCL and MICH, which really hurt my stability. 

Transitioning to SqrtInv works fine; a couple of times I've gotten to arm power of ~10, and have been able to sit there for a while as I set up excitation line comparisons with the CM board's REFLDC, but the PRC would always lose it before I did anything interesting. 

The PRMI locks with a reasonable MICH offset, I found that adding a offset of 20 to 40 makes the AS spot visibly dimmer, and ASDC falls to ~0.05 from .1-.2. 

I looked into adding a boost to the CARM loop after transitioning to sqrtInv, but we only have 30 degrees of margin, and the error signal is already fairly white, so there isn't much to do, really. 

The ALS locking script is sporadically hanging a fair while, as well, which is strange. Otherwise, not much to report...

This is great.

And I got confused. Is REFL11 going through the CM board?
If so how the demod phase for REFL11 take an effect for the sensing?

Maybe I understood. CM SERVO SLOW has been connected to REFL11I? whitening.
Therefore using REFL11 in the CM SERVO gives us REFL11I at the usual channels.
And then how can we ensure the gain matching between I & Q?

Then is the next step 3f DRMI? How is REFL165 healthy?
I also wonder how the relative phase and modulation depths improves the sensing matrix.

REFL11 I, as seen in digital land, is connected to the slow output of the CM board. I tuned the demod angle of the REFL11 demodulator board by cable length back in ELOG 9850. It would be good to check that the phase is still good. If the CM board gains are at 0dB, we should be able to used the digital angle adjustment as normal. 

We need to get an interferometric estimation of the SRC length error / SRC sideband splitting, because if the 7.5cm hand-measured error is true, it looks like it might be hard to control the DRMI on 3F. 

I did some DRMI sensing simulations, to get an idea if sensing matrix elements might change as the CARM offset changes. Last night, I tried just going to zero CARM offset on ALS, and was having problems keeping the PRMI locked on REFL33, so I wanted to confirm that it should at least work in theory. 

Thus, I simulated what happens to the sensing matrix element in the vertex DoFs as the CARM offset is reduced, in both the PR and SR cases. I normalized all of the elements to PRCL at zero carm offset, to get an idea of what the good relative gains should be for MICH and SRCL. 

In the end, there don't seem to be significant DC gain changes, or demod angle fluctuations, in either the PRFPMI or DRFPMI case, as the CARM offset changes, which is good.

However, the SRC length as hand-measured, seems to mess up the MICH angle in the DRFPMI case, and really lowers the SRCL signal amplitude. 

To be fair, past efforts of simulating demodulation angles haven't always been borne out on the IFO, so we should still forge ahead experimentally until it becomes apparent that there is a real problem. 

Here are the simulations for the IFO as-is:

(A note on the plots. Though they kind of look like Bodes, they're just the sensing element represented as a complex number in the I-Q plane,I being phase=0 and Q = 90)

All three signals are along the I axis in the DRMI case, which seems like it would be tough to control, since we only have 2 3F diodes... We've been using REFL33Q when PRMIing, which is simulated at around 45 deg; it should be easy to verify this empirically. 

Here are the same plots with the SRC length corrected. Now MICH shows up mostly in the Q phase as desired in the DRMI case. SRCL in REFL165 also wins 20dB of optical gain, as well. 

To drive the point home, here's a simulated scan of AS110 and REFL55 Q to show the effect of the measured length error:

I tried a bunch of times to reduce my CARM offset so I could jump to REFLDC digitally, but I think I'm maybe being a little ambitious with the arm power I'm trying to get to.

I have modified the carm_cm_up script so that it does my new procedure.  Everything is the same through locking the PRCL and MICH on 3f.  Then it reduces the CARM offset to 1.5 nm.  This is where we *used* to transition to sqrtInvTrans.  Now I have it going a bit farther to 0.5 nm, and arm powers of about 1 before doing that transition.  Also, before it transitions it lowers the CARM gain and engages the 1kHz lowpass in FM9.  A gain of about 4 is fine to keep the gain peaking in the CARM loop to only about 10dB, and sets a UGF of 100Hz which is the peak of the phase bubble with the lowpass engaged. 

Once I got to this point (several times tonight), I turned on CARM and DARM oscillations and looked at the transfer functions between (CARM and REFLDC) and (DARM and AS55Q). I have 2 DTT templates setup for this, in /users/Templates/PRFPMI.  These templates assume that you have your new DARM signal (AS55) going to SRCL_IN1 and your new CARM signal (REFLDC, which is actually REFL11I coming through the CM board) going to MC_IN1. 

I'm not sure why I'm losing lock. I don't see anything terribly telling on the time series plots, in particular none of the loops look like they are oscillating.  Here is one of the better examples from this evening:

Other notes:

* I realigned the Xgreen on the PSL table (again) to maximize the beatnote amplitude.  Y was fine, but X was very poorly overlapped on the camera.

* I put the SR785 back by the LSC rack and plugged it into the CM board for transfer functions.  Didn't take any tonight.

* We have a small wishlist for scripting things:  (1) DRMI restore script should reset REFL11 to "normal" REFL11.  (2) CARM/DARM acquisition restore script should reset REFL11 to REFLDC.  (3) CARM/DARM acquisition restore should also set PRMI parameters (as Q noted last week).

I have not had any success the past two days in getting an interferometric measurement of the SRC length. 

So, the question posed at today's meeting was: "How precisely do we need to change the SRC length to be able to lock the DRMI on 3F"

The two ways I could think to quantify this are:

• How much MICH -> [S,P]RCL cross coupling is ok?
• How much [S,P]RCL ->  MICH cross coupling is ok?

REFL33 should have its phase set to put PRCL along I, and REFL165 should have SRCL along I, so the simulation result that matters is the angle of MICH in these planes. The cross couplings are then given by the appropriate trigonometric projections. In the following plots, I used 10% as the acceptable cross coupling in either direction. 

Result:

Thus,

• To limit the MICH -> [S,P]RCL coupling to 10%, we must hit the ideal length within +- 1.2cm.
• To limit the SRCL -> MICH coupling to 10%, we must hit the ideal length within +- 2mm.
• It doesn't look like we can get the REFL33 angle totally to 90 degrees, REFL165 looks more promising.

Code (finesse + pykat + ipython notebook) and plots are attached. 

Tonight was a night of trying to engage the AO path.  The idea was to sit at arm powers of a few on sqrtInvTrans for CARM and ALS for DARM, and try to increase the gain for REFLDC->AO path.

No exciting nit-picky details in locking procedure.  Mostly it was just a night of trying many times. 

The biggest thing that Q and I found tonight was that the 2-pin lemo cable connecting the CM board's SERVO OUT to the MC board's IN2 is shitty.  The symptom that led to this investigation was that I could increase the AO path gain arbitrarily, and have no change in the measured analog CM loop transfer function. We checked that the CM board servo out spit out signals that were roughly what we expected based on our ~2kHz excitation.  However, if we look at digitized signals from the MC board, the noise level was very high, with loads of 60Hz lines, and a teensy-tiny signal peak.  We put a small drive directly into the MC board and could see that, so we determined that the cable is bad.  We have unplugged the white 2-pin lemo, and ran a long BNC cable between the 2 boards.  Tomorrow we need to make a new 2-pin lemo cable so that we can have the lower noise differential drive signal.

After putting in the temporary cable, we do see an excitation sent to the CM board showing up after the MC board.  For this monitoring, the MC_L cable to the ADC has been borrowed, so instead of being the OUT1, the regular length signal, MC_L is currently the OUT2 monitor right after the board inputs. 

At some point in the evening, around 1:15am, ETMX started exhibiting the annoying behavior of wandering off sometimes.  I went in and pushed on the SUS cables to the satellite box, and I think it has helped, although I still saw the drift at least once after the cable-squishing.

Other than that, it has just been many trials.

The best was one where I was holding the arm powers around 4, and got the CM board's AO gain to -8 dB and the MC board's IN2 AO gain to -4 dB. I lost lock trying to increase the CM board gain to -7 dB. 

I took several transfer functions, and used Q's nifty "SRmeasure" script to gather data, and Q made a plot to see the progress.

TF progress plots:

Time series of that lockloss:

I don't know yet if the polarity of the CM board should be plus or minus.  This series was taken with "minus".  But,  since the phase looked opposite of Q's single arm CM board checkout from several months ago, we did a few trials with the polarity switched to "plus".  I thought we weren't getting as high of AO path gains, so I switched back to "minus", but the last few trials didn't get even as far as the plus trials did.  So, I still don't know which sign we want.

[Q, Jenne]

We pulled the old 2-pin lemo cable after I had a look at the connectors.  When I unscrewed the connector on the MC side, one of the wires came off.  I suspect that it was still hanging on a bit, but my torquing it finally killed it. 

We pulled the cable with the idea of resoldering the connectors, but there are at least 2 places where the cable has been squished enough that the shielding or the inner wires are exposed.  These places aren't near enough the ends to just cut the cable short.

Downs doesn't have a spool of shielded twisted single-pair cable, so Todd is going to get me the part number for the cable they use, and I've asked Steve to order it tomorrow. 

For now, we will continue using the BNC cable that we installed last night - I don't think it's worth resoldering and putting in a crappy 2-pin lemo cable that we'll just throw out in a week.

More AO efforts. No huge news. 

Came at AO from each side. For each sign, I lost lock just a few dB from the AO portion of the loop crossing unity gain. Both attempts were about arm powers of 1, which should correspond to ~300pm CARM offset, which I have simulated the crossover as possible with my current loop models (including latest MC loop). The gain steps were usually 6dB in between measurements. 

Positive polarity on CM board screen:

I made it to +5 dB of the last plot here, but the 6th broke it open. Gains on CM In2, CM AO, and MC In2 were -6, -4, -2 on that last, lock breaking, step. 

Negative polarity on CM board screen:

Lost it just 2dB above the last trace. Gains were -6, +1, -2 (So, overall 5dB higher than the other polarization)

Many things happened in between these two lock stretches, but I'm not sure what may or may not have affected things. They include:

• Jenne mentioned PRMI being fussy earlier in the evening. I adjusted REFL33 and POP22 angles during a PRMI lock, while CARM was held away with ALS. My simulations suggest that there are small changes to the 3F sensing when the arms are totally absent, but doing it at a finite CARM offset is closer to where we want it, it seems. 
• I tried using REFL165Q for MICH, since my simulations suggest a better MICH/PRCL angle, which would stave off cross couplings. Lined up excitations, etc., but no luck. 
• I measured the PRMI loops
  • found PRCL to have ~200Hz UGF, 8dB gain peaking. Maybe a little high, but didn't seem terrible. 
  • MICH had UGF of around 20Hz, with the FM gain at 0.8. By the shape of the phase bubble, the loop seems designed for higher bandwidth. I raised the gain to 2.5 for a 70ishHz UGF, and called in FMs 7 and 9 for additional triggered boosts. Things seemed to stay locked pretty well. 
• Lower excitation amplitude the second time around, measuring the AO loop. Looking at the CM output spectra, you can see the excitation wailing away; I wanted to avoid it.

The location of the CARM resonance peak lines up with my simulation, which is good, but there appears to be less phase than expected... I tried making sure that we don't have any whitening uncompensated for, but it looked ok. All my AO path loop model contains is the CM board TF (measured and fitted), the IMC seen as an actuator(measured and fitted), and the REFLDC optical TF (simulated in MIST). Maybe the DC path of whatever diode this is coming from needs to be included...

Discontinuities / glitches could be seen in the CM board fast output when MC board gains were changed, which isn't so nice. Incidentally, I notice now that each lock loss corresponded to a step of AO gain on the CM board.

Back in May I looked at all the glitches that happen when we change the AO gain slider on the CM board - see elog 9938.   I wonder if the MC IN2 gain slider has the same issues.  I think I'll look at this this afternoon. Maybe we can set the CM board gain someplace, and just use the MC IN2 slider (if it's not as glitchy) for the delicate part where we're just about to cross unity, and then later we can again use the CM board's AO gain.

EDIT:  Yes, the glitches on the CM board AO path are *much* bigger, and more frequent.  Interestingly, the biggest glitches were every 4 dB.  When I went from -29 to -28, again from -25 to -24, -21 to -20, etc.  I saw the largest glitches on the MC IN2 slider going -29 to -28 and -17 to -16, but if there were small glitches at other transitions, they didn't hit my trigger levels.  I think next time I try engaging the AO path I'll try to do the delicate stuff by upping the MC IN2 gain rather than the CM board AO gain.

Rather than using a CAD drawing, I used Gabriele's code from ELOG 9590 to try and judge if we could shorten the SRC by the appropriate length, without clipping the SR3-SR2 beam. 

Specifically, I used these lines:

% Move SRM 7.5 towards SR2, parallel to beam

delta=75;

dAS = BS2-AS; % Vector from SRM to SR2

dASmag = sqrt(dAS(1)^2+dAS(2)^2);

dMove = delta*dAS/dASmag; %  delta times unit vector

CS = CS+dMove;

draw_sos(CS, 180/pi*angles)

As a reminder, Gabriele's code used the following logic:

• We know the nominal dimensions of all of the suspensions
• We hand measured various distances between features of the suspension structures. (Corner to corner)
• A global fit, minimizing the maximum error, reconstructed the positions of the suspensions. 
• Beam positions assumed to be ideally aligned. 
• Beam trajectories traced out, and optical path lengths estimated (taking into account changing indices of refraction due to flipped mirrors)

In my opinion, this is the best estimate of beam trajectory that we currently have.

Thus, from looking at the plot above, I claim we can correct the SRC length without clipping the beam by moving the SRM forward by the required 7.5cm.

Although the measured distance may be off on the order of a cm (since our PRC correction had a 0.5cm disagreement between interferometric and hand distance measurements), this will nevertheless markedly improve our 3F DRMI sensing, based on my previous ELOG. 

Hence, given our discussions last week, Jenne and I will proceed to ready the interferometer for venting in the morning, by following the vent checklist.

Our sole objective for this vent is this move of the SRM. 

Steve, please check the jam nuts, and begin the vent when you get in.  Thanks!

I looked at the CAD layout and it seems like we will clearly be clipping POY if we move SRM by 7.5cm. Since POY is not visible at low power, we cannot be sure about the clipping.

We should have a plan B before we move everything. I suggest we move a combination of SRM and SR2 to get the desired SRC length.
Moving SR2 will require extra effort to walk the beam unclipped through all the 6 output steering mirrors that follow; but there will be little room for error if we use irides to propagate the beam through the first 4 mirrors that are in the BS and ITMY chamber.

 I was bad and forgot to elog this yesterday (bad grad student!), but I setup a laser pointer to show us where the POY beam is. 

To do this, I removed the tiny mirror that sends the beam to the POY RF PD (so we do not have POY to lock the Yarm right now.  I think Q has successfully been using AS).  The laser pointer goes through 2 temporary steering mirrors, then passes through the place that the tiny mirror usually sits, and then travels along the POY path into the vacuum system.  The idea here is that we should be able to adjust the laser pointer and the temp steering mirrors, and not touch any of the actual POY mirrors, but still get the green beam to go all the way to ITMY.  Yesterday I confirmed that the laser pointer was hitting the in-vac POY pickoff mirror, and today Q and Manasa are doing final adjustment to get the beam all the way to the ITM. 

I've installed a new 2pin lemo cable going from the CM servo out to in2 of the MC servo board, and removed the temporary BNC. I used some electrical tape to give the cable some thickness where the lemo head screws on to try to strain relieve the solder joints; hopefully this cable is more robust than the last. 

I put an excitation into the CM board, and saw it come out of MC_F, so I think we're set. 

• Beamsplitter was put into MC refl path.
• HWP was rotated to maximize power into PMC. 
• MC autolocker locked, small alignment tweak led to WFS taking over
• Light present on REFL, AS and POP!
• After small adjustments to TTs and ETMY, locked Yarm with AS55, ran ASS. 
• Adjusted AS camera and RFPD alignment for ASS'd AS beam. 
• Left arm locked on AS55, aligned new POY beam onto POY11. Centered ITMY oplev while I was there. 
• After adjusting digital POY11 demod angle with an excitation into ETMY, arms were POX/POY locked and ASS'ed.
• PRM and SRM eyeball aligned

The IFO is ready for 3F DRMI comissioning 

I haven't been able to lock the DRMI tonight, neither with 1F and no arms nor 3F and arms held off with ALS... I tried previous recipes, and new combinations informed by simulations I've run, to no avail. 

I touched the alignment of the green beat PD on the PSL table, since the X beatnote was rather low, but wasn't able to improve it by much. I never took a spectrum, since it wasn't my main focus tonight, but the low frequency motion of both arms on ALS, as observed by RIN, was good as I've ever seen it. 

In our WFS work earlier today, Koji and I reset the WFS offsets, and it actually seems to have helped a good deal, in terms of the "fuzz" of MC REFL on the wall striptool. I had previously presumed this to be due to excess angular motion, but perhaps it is more accurately described as an alignment offset that let the nominal angular motion couple into the RIN more. 

No exciting progress today.  I did PSL green alignment for the Yarm, although I now think that the Xarm green needs realigning too.

Also, I was foiled for a while by ETMX jumping around.  I think it's because the adapter board on the Xend rack didn't have any strain relief.  So, I zip tied the heavy cable in a few places so that it's no longer pulling on the connector.  Hopefully we won't see ETMX misbehaving as often now, so we won't have to go squish cables as often.

I've changed the LSC rack wiring a little bit, to give us some flexibility when it comes to REFL11. 

Previous, the REFL11 demod I output was fed straight to the CM servo board, and the slow CM board output was hooked up to the REFL11I ADC channel. Thus, it wasn't really practical to ever even look at sensing angles in REFL11, since the I and Q inputs were subject to different signal paths/gains. (Also, doing LSC offsets would do wonky things to refl11 depending on the state of the switches on the CM board screen.)

Thus, I've hooked up the CM board slow output into the the previously existing, aptly named, CM_SLOW channel. The REFL11 demod board I output is split to IN1 of the CM board, and the REFL11 I ADC channel. 

So, there is no longer hidden behavior in behind the REFL11 input filters, channels are what they claim to be, and the CM board output is just as easily accessible to the LSC filters as before. 

As part of trying to determine whether we require the AO path for lock acquisition, or if we can survive on just digital loops, I looked at the noise suppression that we can get with a digital loop.

I took a spectrum of POX, and calibrated it using a line driving ETMX to match the ALSX_FINE_PHASE_OUT_HZ channel, and then I converted green Hz to meters. 

I then undid the LSC loop that was engaged at the time (XARM FMs 1,2,3,4,5,8 and the pendulum plant), to infer the free running arm motion. 

I also applied the ALS filters (CARM FMs 1,2,3,5,6) and the pendulum plant to the free running noise to infer what we expect we could do with the current digital CARM filters assuming we were not sensor noise limited.

In the figure, we see that the free running arm displacement is inferred to be about 0.4 micrometers RMS.  The in-loop POX signal is 0.4 picometers RMS, which (although it's in-loop, so we're not really that quiet) is already better than 1/10th the coupled cavity linewidth.  Also, the CARM filters that we use for the ALS lock, and also the sqrtInvTrans lock are able to get us down to about 1 pm RMS, although that is not including sensor noise issues. 

For reference, here are the open loop gains for the LSC filters+pendulum and ALS filters+pendulum that we're currently using.  The overall gain of these loops have been set so the UGF is 150Hz.

It seems to me that as long as our sensors are good enough, we should be able to keep the arm motion down to less than 1/10th or 1/20th the coupled cavity linewidth with only the digital system.  So, we should think about working on that rather than focusing on engaging the AO path for a while.

 [ericq, Jenne]

We attempted some of the same old CARM offset reduction tonight, but from the other direction. (We have no direct knowledge of which is the spring and which is the anti-spring side)

We we able to get to, and sit at, arm powers on the order of 5. Really, we kind of wanted just to push things to try and inform our current ideas of what our limiting factor is, so as to appropriately expend our efforts. 

Candidates include:

• ALS noise causing excess DARM motion
  • Means we need to DRMI to widen DARM linewidth, avoid sign flip in AS55, IR lock DARM sooner
• Intolerable sensor noise makes CARM wander too much, changing our plant more than our loops can handle
  • We should work on having live calibrated CARM spectra during lock attempts, to compare with Jenne's noise estimates, and see where/how/why we exceed it. 
• detuned CARM pole causes loop instability
  • Maybe some sort of notching can get us by
  • AO path could extend bandwidth, getting the pole into the control band 
• SqrtInv signals losing low frequency sensitivity due to radiation pressure, or DC sensitivity due to transmission curve flattening out
  • Bring in AO path for supplementary bandwidth, which lets us turn up loop gain / engage big boosts
  • Or, switch to REFLDC in digital land, which is nontrivial, due to different optical plant shapes.

We took many digital CARM OLTFs at different offsets; it never really looked like a burgeoning pole was about to make things unstable. The low frequency OLTF data had bad SNR, so it wasn't clear if we were losing gain there. We weren't at arm powers where we would expect the DC transmission curve to flatten out yet, from simulations (which is above a few tens).

My impression from at least our last lock loss was a DARM excursion. However, using the DRMI won't get rid of the second two points.

Other thoughts from talking with Rana earlier:

• Is it possible to suppress CARM motion enough that we can use just a digital loop?  Can we do without the AO path?  What would said digital loop have to look like?
• Q points out that there is a zero in the relative transfer function between CARM to transmission, and CARM to REFLDC.  Is that zero invertible?
• We should look at some limits, like saturation limits.  How much will we need to actuate?
• Rana is looking at making a more detailed CARM loop model in simulink to see if we can stay stable throughout our CARM offset reduction journey.

Also, Q and I squished on the suspension connectors earlier tonight.  MC2 was going wonky, which we feared might be because we were in that area working on Chiara earlier.  Then, after squishing the MC connectors, the PRM started misbehaving, so we went and gave all the corner suspension connectors another squish.  No suspension glitching problems since then.

In my previous simulation results, I've always plotted W/m, which isn't exactly straightforward. We often think about the displacement that a given mirror actuator output will induce, but when we're locking the full IFO, radiation pressure effects modify the mechanical response depending on the current detuning, making the meaning of W/m transfer functions a little fuzzy.

So, I've redone my MIST simulations to report Watts of signal response due to actual actuator newtons, which is what we actually control with the digital system. Note, however, that these Watts are those that would be sensed by a detector directly at the given port, and doesn't take into account the power reduction from in-air beamsplitters, etc.

As an example, here are the SqrtInv and REFLDC CARM TFs for the anti-spring case:

The units of the SqrtInv plot are maybe a little weird, these TFs are the exact shape of the TRX W/N TFs with the DC value adjusted by the ratio of the DC sweep derivatives of TRX and SqrtInv. 

All of the results live in /svn/trunk/modeling/PRFPMI_radpressure/