40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 55 of 341 Not logged in
ID Date Author Type Category Subject
1230   Thu Jan 15 22:30:32 2009 ranaConfigurationDMFDMF start script
I tried to restart the DMF using the start_all script: http://dziban.ligo.caltech.edu:40/40m/280

it didn't work
1232   Fri Jan 16 11:33:59 2009 robConfigurationDMFDMF start script

 Quote: I tried to restart the DMF using the start_all script: http://dziban.ligo.caltech.edu:40/40m/280 it didn't work

It should work soon. The PATH on mafalda does not include ".", so I added a line to the start_DMF subscript, which sets up the DMF ENV, to prepend this to the path before starting the tools. I didn't put it in the primary login path (such as in the .cshrc file) because Steve objects on philosophical grounds.

Also, the epics tools in general (such as tdsread) on mafalda were not working, due to PATH shenanigans and missing caRepeaters. Yoichi is harmonizing it.
1461   Wed Apr 8 18:46:50 2009 ranaConfigurationGeneralDMF, SVN, x2mc, and matlab

While waiting for the installation of the 32-bit Matlab 2009a to finish, I tried updating our seisBLRMS.m code.

Although DMF is in SVN, we forgot to check it out and so the directory where we have been doing our mods is not a working copy and our changes have not been captured: Shame.

We will probably have to wipe out the existing SVN trunk of DMF and re-import the directory after checking with Yoichi for SVN compliance.

Also wrote a script: LSC/x2mc, which will transition from regular ETM based X Arm locking to the MC2 based locking. It ran once OK, but I get a segfault on the 'trianglewave' which was trying to run the 'ezcastep' perl script which was calling 'ezcastep.bin'.

I also restarted the seisBLRMS.m on a terminal on Mafalda in the new Matlab 2009a to see if it loses its NDS connection like it did with 2007a. I also reduced the 'delay' parameter to 4 minutes and the 'interval' to 1 minute. This should be so that the total delay is now 5 minutes between seismic noise and seismic trend.

15909   Fri Mar 12 03:23:37 2021 KojiUpdateBHDDO card (DO-32L-PE) brought from WB

I've brought 4 DO-32L-PE cards from WB for BHD upgrade for Jon.

Attachment 1: P_20210311_232742.jpg
Attachment 2: P_20210311_232752.jpg
7005   Mon Jul 23 18:16:13 2012 JamieUpdateSUSDQ block added to sus_single_control library parts

I have added a DQ block to the sus_single_control library part.  This means that all sus models will automatically generate DQ channels based on what is specified in this doc block:

#DAQ Channels

SUSPOS_IN1
SUSPIT_IN1
SUSYAW_IN1
SUSSIDE_IN1
ULSEN_OUT
URSEN_OUT
LRSEN_OUT
LLSEN_OUT
SDSEN_OUT
OLPIT_IN1
OLYAW_IN1
OLSUM_IN1


So for instance, for BS will have the following DQ channels:

C1:SUS-BS_SUSPOS_IN1_DQ
C1:SUS-BS_SUSPIT_IN1_DQ
...


etc.  The channels names modified by the activateDQ.py script after install are still modified appropriately.

This is now the place where we should be maintaining DQ channels.

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

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

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

3. To do: Debug ./drstep_bang with just the DRM (no arms).
12069   Mon Apr 11 16:06:30 2016 ericqUpdateLSCDRFPMI Data Archived

I have copied over the complete frame files from two DRFPMI lock acquisitions + locks to /frames/archive. The data should be safe from the wiper script here.

One, under the subfolder DRFPMI_Mar29_cal is the lock where the CAL-DARM channel is properly calibrated at GPS time 1143274087.

The other lock, under DRFPMI_MAR29_nocal, does not have the calibration set up yet, but was a much quicker acquistion (<2 min from ALS acquisition to DRFPMI) and longer lock (~8min).

12053   Tue Mar 29 03:16:21 2016 ericqUpdateLSCDRFPMI Locked Once More

[ericq, Gautam]

Three RF-only locks longer than a minute tonight, out of 5 total attempts.

Last week, I determined that the beam spot on the RF POP PD is too large. This still needs to be fixed. I updated the ASS model to use REFLDC as a PRCL dither error signal; it works.

There seems to be some excess angular motion of ETMY tonight. This is evident in the oplev spectra (as compared to ETMX), and the GTRY camera, and even the retroreflected beam from a misalgined ETMY on the ITMY face when the PRC is carrier locked.

Gautam and I mostly focused on setting up the CAL-DARM_CINV block to produce this (mostly) calibrated spectrum starting from GPS 1143274087. [Darm on unwhitened AS55, DRMI on 3F, one CARM boost]

Here are the control and error signal spectra:

[DTT files attached]

Note to self: archive some of this data

Attachment 1: 2016-03-29_calibdarm.pdf
Attachment 2: 2016-03-29_DRFPMI_errctrl.pdf
Attachment 3: DRFPMI_DTT.zip
11691   Thu Oct 15 03:08:57 2015 ericqUpdateLSCDRFPMI Locked for 20 sec

[ericq, Gautam]

For real this time.

Attachment 1: DRFPMI_locked.pdf
11692   Thu Oct 15 04:14:14 2015 ericqUpdateLSCDRFPMI Locked for 20 sec

Fast ALS was still a problem tonight. I don't think high frequency ALS noise saturating the PC drive is the issue; I put two 10k poles before the CM board (shooting for just 2-3kHz bandwidth), and the PC drive levels would be stable and low up until the lockloss, which was always conincident with a step in the AO gain.

After working with that for a few hours, we turned back to our more standard locking attempts. First, we dither aligned the PRMI, and then centered the REFL beam on REFL11. It's hard to say for certain, but we may have been a little close to the edge of the PD. The only other thing that differed from Monday's attempts was using 6dB less AO gain when trying the up the overall gain.

The script now reliably breaks through to stable high powers, we had a handful of pure-RF locks tonight. The digital DARM gain needs tuning, and the CARM bandwidth still isn't at its final state, but these are very tractable. Off the top of my head, the way forward now includes:

• Set proper final DARM loop shape
• Set final CARM loop shape
• Take full sensing matrix
• Make 1F handoff
• Set up the CAL model to produce (at least roughly) calibrated spectra
• measure noise couplings and other fun stuff

Unrelated: I feel that the PRC angular FF may have deteriorated a bit. I'm leaving the PRC locked on carrier to collect data for wiener filter recalculation.

11693   Thu Oct 15 10:59:12 2015 KojiUpdateLSCDRFPMI Locked for 20 sec

Great job! Many thanks Eric, Gautam, and all the current and past colleagues for your tremendous contributions to bring the 40m to this achievement.

11696   Sat Oct 17 18:55:07 2015 ranaUpdateLSCDRFPMI Locked for 20 sec

in addition to Koji's words I feel like we should also thank those who made small but positive contributions. Its hard not to notice that this locking only happened after the new StripTool PEM colors were implemented...

From the times series plot I guess that the fuzz of the in-loop DARM is 1 pm RMS (based on memory). This means that the ALS was holding the DARM at 10 pm from the RF resonances.

There is no significant shift in the DRMI error signals, so new weird CARM effect. Would be interesting to see what the 1f signals do in the last 60 seconds before RF lock.

For documentation, perhaps Gautam can post the loop gain measurements of the 5 loops on top of the Bode plots of the loop models.

12028   Thu Mar 10 03:03:11 2016 ericqUpdateLSCDRFPMI Power stable, but no RF handoff

[ericq, Gautam]

We worked on getting the DRFPMI back up and running, hoping the ALS performance was good enough.

We did succeed in bringing in enough of the AO path to stabilize arm powers > 100, but failed at the full RF DARM handoff.

REFL165 angle was adjusted to -86 to minimize PRCL in the Q signal.

The AS110 signals are mysteriously huger than they used to be. Whitening gain reduced to 15dB from 27dB. Old trigger thresholds are still fine.

The new AUX X laser has a different sign for the temperature-> frequency coupling, so our usual convention of "beatnote goes up when temp slider goes up" meant the ALSX input matrix elements had to change sign.

We think the POPDC PD (which I think is the POP2F PD) may be miscentered, since in PRMI configuration, its maximum does not coincide with the REFLDC minimum, and leaves a sizeable TEM10 lobe on the REFL camera. This was a pain.

11669   Tue Oct 6 03:30:17 2015 ericqUpdateLSCDRFPMI Progress

[ericq, Gautam]

Highlight of the night: the DRFPMI was held at arm powers > 110 for 20 seconds. ALS feedback was still running though, but so was some nonzero REFL11 AO path action.

In short, time was spent finding the right FM trigger settings to keep the DRMI locked while CARM is fluctuating through resonance, what CARM offset to acquire DRMI lock at, order of operations of turning on AO / turning up overall CARM gain, etc.

Sadly, for the past hour or so, the DRMI has refused to stay locked for more than ~20 seconds, so I haven't been able to push things much further. This is a shame, since I'm very nearly at the equivalent point in the PRFPMI locking script where the ALS control is turned off completely.

11671   Thu Oct 8 04:48:50 2015 ericqUpdateLSCDRFPMI Progress

Progress was made. CARM was stably locked on RF only. DARM was RF only for a few moments before I typed in a wrong number...

A change was made to the LSC model's triggering section to make the DRMI hold more reliably at zero CARM offset. Namely, the POPDC signal now has its absolute value taken before the trigger matrix. Even unwhitened, it occaisionally would somehow go negative enough to break the DRMI trigger.

AUX X laser was acting up again. As before, tweaking laser current is the temporary fix.

11672   Thu Oct 8 13:13:20 2015 KojiUpdateLSCDRFPMI Progress

Please clarify: I wonder if you were at the zero offset for CARM and DARM or not. I am 25% excited right now.

11673   Thu Oct 8 14:14:50 2015 ericqUpdateLSCDRFPMI Progress
 Quote: Please clarify: I wonder if you were at the zero offset for CARM and DARM or not.

Yes, this was at the full DRFPMI resonance.

11674   Thu Oct 8 16:48:23 2015 KojiUpdateLSCDRFPMI Progress

Awesome

11675   Thu Oct 8 21:35:49 2015 ranaUpdateLSCDRFPMI Progress

Give us a lockloss or other kind of time series plot so we can bask in the glory.

11676   Fri Oct 9 09:22:38 2015 ericqUpdateLSCDRFPMI Progress

Look upon this three second lock, ye Mighty, and rejoice!

Attachment 1: oct8_allRF.pdf
11677   Fri Oct 9 11:24:06 2015 JenneUpdateLSCDRFPMI Progress

11725   Mon Nov 2 17:39:01 2015 KojiFrogsGeneralDRFPMI celebration

やったー！Yatta!

Attachment 1: yatta.jpg
8179   Wed Feb 27 02:44:39 2013 JenneUpdateLockingDRFPMI flashes

Before Yuta left, I asked him to restore all optics to last saved values, to avoid hysteresis.

Some interesting modes appear at ETMYT and ETMXT.  The cavities aren't super well aligned right now, especially since we have been seeing this input pointing drift, but it's cool to see our first DRFPMI flashes. SRM, in particular, hasn't been aligned since before pumpdown.  If I misalign SRM, the mode content at the trans cameras improves somewhat, but it still isn't all low-order modes.

Here is the note that I wrote on youtube describing the video:

DRFPMI Flashing

Upper left is AS, upper right is POP
lower left is Xarm Trans (ETMXT), lower right is Yarm Trans (ETMYT)

Arms were last aligned several hours ago, and we know input pointing drifts, so at least some of the higher order modes in the arm transmissions are due to poor input pointing. All optics are "restored" to their last saved values, including SRM, which has not been aligned since before pumpdown.

TRX DC PD values are flashing to as high as 10
TRY DC PD values are flashing to as high as 7

Since uploading the video, I have seen TRY flash (once) to 45.  Yes, forty five!!!  Both arms are usually flashing to ~3ish, with an occasional medium flash (5-10), and then a few rare TRY flashes above 20.

We may have officially lost the bet of having arms locked by 9am Monday, but I think Team Grad Student / Postdoc still deserves some beer from Team Faculty / Staff.

8191   Wed Feb 27 20:10:43 2013 ranaUpdateLockingDRFPMI flashes

If its true that there have been large flashes, then there indeed might be beer. But first I'd have to see a calibrated plot. And make sure that the flashes are not overamplified due to a whitening filter imbalance.

Is it the readout of a PD with no whitening/antiwhitening? IF so, its much easier to believe.

675   Tue Jul 15 12:44:08 2008 JohnSummaryLockingDRFPMI with DC readout
Rob, John

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

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

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

The DARM filters were modified to reduce excess noise around 3Hz. Updating filter coefficients does
not cause loss of lock.
11718   Tue Oct 27 03:56:52 2015 ericqUpdateLSCDRFPMI work

A handful of DRFPMI locks tonight, longest one was ~7 minutes.

EPICS/network latency has been a huge pain tonight. The locking script may hang between commands at an unstable place, or fail to execute commands altogether because it can't find the EPICS channel. This prevented or broke a number of locks.

I made some CARM OLG and crossover measurements, and found the AO gain for the right crossover freq (~100Hz) to be ~8dB different than what's in the PRFPMI script, which is weird. Right now, the CARM bandwidth / ability to turn on boosts is limited by the gain peaking in the IMC CLG due to the high-ish PC/PZT crossover frequency we're using.

Gautam turned on some sensing excitations during the last couple of locks, but they weren't on for very long before the lock loss. Hopefully I can pull out at least some angles from the data.

I'm also more convinced that the PRC angular FF needs retuning; there is more residual motion on the cameras than I'm used to seeing. I've taken more data that I'll use to recalculate a wiener filter tomorrow.

The PMC, ALSX beat and ITMX oplev all needed a reasonable pitch realignment tonight.

11722   Thu Oct 29 03:25:49 2015 ericqUpdateLSCDRFPMI work

[ericq, Gautam]

The length of DRFPMI lock did not increase much tonight, but we got a ~80 second sensing matrix measurement, and got the CARM bandwidth up to 10k with two boosts on.

NB: I did not measure the CARM loop gain at its excitation frequency, so the plotted sensing element is supressed by the CARM loop. However, this is still useful for gauging the size of the PRCL signal vs. the residual CARM fluctuations. The excitations are fairly closely spaced between 309 and 316 Hz.

For comparison, I'm also re-plotting the DRMI sensing measurement from a few weeks back taken at CARM offset of -4. We can see some change in the PRCL sensing, likely due to the CARM-coupled path. MICH/PRCL sadly looks pretty degenerate, but REFL55 looks more reasonable.

I think the main limitation tonight was SRC stability. Even before bringing CARM to zero offset, we would see occasional sharp dives in AS110 power. One lockloss happened soon after such an occurance, but I checked the values, and it was not sufficient to trigger the Schmitt trigger down; instead it may have been a real optical loss of signal. The SRCL OLTF looks sensible.

Random notes:

• Aux X laser was glitching yet again, twiddled laser current to 1.90A from the 1.95A that I twiddled it to on Monday from the nominal 2.0A.
• When aligning the PRMI, I saw both ITMs' oplevs shift by a few urad in both pitch and yaw when engaing/breaking the lock, but this was not repeatable.
• I reduced the AS110 whitening gain by 9dB, since the DC values were a few thousands, and I wanted to make sure there were no stray ADC saturations. This didn't change lock stability though.
Attachment 1: DRFPMI.pdf
Attachment 2: DRMIarms.pdf
11726   Tue Nov 3 03:12:46 2015 ericqUpdateLSCDRFPMI work

Tonight was kind of a wash.

We spent some time retaking single arm scans with Gautam's frequency counting code to confirm the linewidths he measured before his most recent round of code improvements. During this, ETMX was being its old fussy self, costing us gentle realignment time. For the time being, we started actuating on ITMX for single arm locks. Also, out of superstition, I changed the static position offset that had been at +1k for the last N months to -1k.

ETMX broke us out of a few DRFPMI lock trials as well, as did poor SRM alignment. I finally set up dither alignement settings for SRM in DRMI though, which helped (even in the arms-held-off-resonance situation). I still prefer doing the PRM/BS dither alignment in a carrier PRMI lock, because I think the SNR should be better than DRMI.

We know that the ETMX excursions can happen without length drive exciting them, but also that length drives certainly can excite them. For future locks, I'm going to try out avoiding ETMX drive altogether; the sites use a single ETM for their DARM actuation and let the CARM loop take care of the resultant cross coupling, so hopefully we can do the same without angering the mode cleaner.

Anyways, we didn't really ever make it far enough to do anything interested with the DRFPMI tonight

10700   Wed Nov 12 01:30:39 2014 ericqUpdateLSCDRFPMI, PRFPMI HOM resonances

I did some simulations to see if we are susceptible to HOM resonances as we reduce the CARM offset. I restricted my search to HG modes of the Carrier+[-55,-11,0,+11,+55]MHz fields with n+m<6, and used all the real physical parameters I could get ahold of.

In short, as I change the CARM offset, I don't see any stray resonances within 2nm of zero, either in PRFPMI or DRFPMI.

Now, the mode matching in my simulation is not the real mode matching our real interferometer has. Thus, it can't tell us how much power we may see in a given mode, but it can tell us about our susceptibility to different modes. I.e. if we were to have some power in a certain mode coming out of the IMC, or present in the vertex, we can see what it would do in the arms.

Since my simulation has some random amounts of power in each HOM coming into the interferometer, I simply swept the CARM offset and looked for peaks in the power of each mode. Many of the fields exhibited gentle slopes over the range, and we know we ok from 3nm->~100pm, so I made the selection rule that a "peak" must be at least 10 times as big as the minimum value over the whole range, in order to see fields that really do have CARM dependence.

In the following plots, normalized IFO power is plotted and the locations of HOM peaks are indicated with circles; their actual heights are arbitrary, since I don't know our real mode content. However, I'm not really too concerned, since all I see is some -11MHz modes between 2-3nm of full resonance, where we have no problem controlling things... Also, all of the carrier HOMs effectively co-resonate with the 00 mode, which isn't too surprising, and I didn't include these modes in the plots.

Finally, I visually inspected the traces for all of the modes, and didn't really find anything else peeking out.

Code, plots attached.

Attachment 1: HOMs.zip
10705   Wed Nov 12 21:18:32 2014 ericqUpdateLSCDRFPMI, PRFPMI HOM resonances

So, with my last entry, I was guilty of just throwing stuff into the simulation and not thinking about physics... so I retreated to Siegman for some algebraic calculations of the additional Guoy phase accumulated by the HOMs in the arms -> their resonant frequencies -> the arm length offset where they should resonate. Really, this isn't completely precise, as I treated the arms independently, with slightly differing ETM radii of curvature, but I would expect the "CARM Arm" to behave as a sort of average of the two arm cavities in this regard. (EDIT: Also, I didn't really consider the effect of the coupled vertex cavities... so there's more to be done)

The basic idea I used was:

• Assume ITMs are effectively flat, infinite Rc
• Use 40mwiki values for ETM curvatures
• Each additional HG order adds arccos(sqrt(1 - Larm/Rc)) of Guoy phase for a one way trip down the cavity (Eqn 19.19 in Sigman)
• For each HOM order up to 5 of the carrier and first order sidebands, add the appropriate phase shift
• fold it onto +-FSR/2 of the carrier 00 resonance, convert to m

In practice, I threw together a python script to do this all and print out a table. I've highlighted the values within 10nm, but the closet one is 3.8nm

Results:

########## X Arm HOM Resonance Locations in nm ##########
Mode Order:      0     ,      1     ,      2     ,      3     ,      4     ,      5
 
Carrier   :          +0,     +156.21,     -219.58,     -63.376,     +92.832,     +249.04
LSB 11    :     +59.563,     +215.77,     -160.02,     -3.8126,      +152.4,      -223.4
USB 11    :     -59.563,     +96.645,     +252.85,     -122.94,     +33.269,     +189.48
LSB 55    :     -234.18,     -77.975,     +78.233,     +234.44,     -141.35,     +14.857
USB 55    :     +234.18,     -141.61,       +14.6,     +170.81,     -204.98,     -48.776
 
 
########## Y Arm HOM Resonance Locations in nm ##########
Mode Order:      0     ,      1     ,      2     ,      3     ,      4     ,      5
 
Carrier   :          +0,     +154.82,     -222.35,     -67.531,     +87.292,     +242.11
LSB 11    :     +59.313,     +214.14,     -163.04,      -8.218,      +146.6,     -230.57
USB 11    :     -59.313,      +95.51,     +250.33,     -126.84,     +27.978,      +182.8
LSB 55    :     -235.43,     -80.611,     +74.212,     +229.04,     -148.14,     +6.6809
USB 55    :     +235.43,     -141.74,      +13.08,      +167.9,     -209.27,     -54.452

Code is attached. Hopefully no glaring mistakes!

Attachment 1: HOMlist.py.zip
1670   Fri Jun 12 02:01:03 2009 robUpdateComputer Scripts / ProgramsDRM matrix diagonalization

I started two scripts, senseDRM and loadDRMImatrixData.m, which Peter will bang on until they're correct.  They're in the \$SCRIPTS/LSC directory.  The first is a perl script which uses TDS tools to drive the DRM optics and measure the response at the double demod photo-detectors, and write these results to a series of files loadable by matlab.  The second loads the output from the first script, inverts the resulting sensing matrix to get an input matrix, and spits out a tdswrite command which can be copied and pasted into a terminal to load the new input matrix values.

What's left is mainly in figuring out how to do the matrix inversion properly.  Right now the script does not account for the output matrix, the gains in the feedback filters at the measurement frequency, or the fact that we'll likely want the UGF of our loops to be less than the measurement frequency.  Peter's going to hash out these details.

11637   Wed Sep 23 03:08:50 2015 ericqUpdateLSCDRMI + ALS Arms

[ericq, Gautam]

We can reliably lock the DRMI with the arms held off on ALS.

I have not been able to hold it at zero CARM offset; but this is probably just a matter of setting up the right loop shapes with enough phase margin to handle the CARM fluctuations ( or figuring out high bandwidth ALS...)

Right now, it's the most stable at CARM offsets larger (in magnitude) than -1. Positive CARM offsets don't work well for some reason.

The key to getting this to work was to futz around, starting from the misaligned arms DRMI settings, until brief locks were seen (triggering all 3 DRMI DoFs on POP22, since the correct AS110 sign was amiguous). I could tell from how the control signals responded to gain changes that REFL165Q, which was being used as the MICH error signal, was seeing significant cross coupling from both PRCL and SRCL, suggesting the demod angle of REFL165 had to be adjusted. I randomly tweaked the REFL165 demod angle until a 20 second lock was achieved, with excitations running. Then, I downloaded that data and analyzed the sensing matrix. This showed me that the REFL33 demod angle was ok, and the PRCL-from-SRCL subtraction factor determined with the arms misaligned was still valid. The main difference was indeed the SRCL angle in REFL165.

With the REFL165 demod angle properly adjusted, the DRMI would briefly lock, but the DRMI had become somewhat misaligned at this point, and the SRC could be seen to mode hop. Interestingly, the higer order modes had an opposite sign in AS110, with respect to the TM00. At that point, I went back to PRMI on carrier to dither-align the BS and PRM.

With alignment set, the DRMI would lock on TM00 readily, still only triggering on POP22. I set the AS110 angle, and moved SRCL triggering over to that, which sped up acquisition even more. The input matrix and FM gains from no-arms DRMI still work for acquistion; UGF servos were used to adjust overall gains a bit.

At CARM offsets larger in magnitude than -1, the DRMI lock seems indefinite. I just broke it to see how fast it would acquire; 3 seconds.

Lastly, here is the sensing matrix at CARM offset of -4, measured over five minutes. REFL11 is the only degenerate looking PD. Thus, I feel like controlling the DRMI of the DRFPMI should be more managable than I had feared.

(I didn't include/excite CARM or DARM, because I'm not sure it would really mean anything at such a large CARM offset)

Attachment 1: DRMIarms.pdf
11638   Wed Sep 23 10:31:49 2015 ericqUpdateLSCDRMI + ALS Arms

Looking good. How many meters of CARM is '-1 counts'?

11639   Wed Sep 23 12:51:03 2015 JenneUpdateLSCDRMI + ALS Arms

Nice!!

9049   Thu Aug 22 02:40:12 2013 JenneUpdateLSCDRMI Locked for 1+ minute!!!!!!

[Jenne, Koji]

The DRMI has been locked!!  And at least one time, it was for more than one minute!!

We are not 100% sure yet that it's correctly sideband locked.  The test of this was to put a 50% BS in front of the AS camera (so after the beam has gone to AS55), and send the light over to a PDA10CF Thorlabs PD.  I locked the Michelson on carrier for the alignment of this diode.  Then I strung a cable to the control room, and plugged it into the RF spectrum analyzer.  (First, I had turned off the green beat PD power, so there wasn't any RF stuff on the line that I unplugged).  It's hard to watch the screen and a tv / dataviewer at the same time, so I've taken a video, so that we can see the nicely locked round DRMI beam on the AS camera, and the spectrum analyzer.  My phone is working very hard at uploading the video, but we may have to wait until tomorrow for that.  However, I think that we're locked on the 55MHz sideband. (Also, maybe I'm too tired or excited or something, but how do you make the real cameras take video??)

EDIT:  Video uploaded.  Pause the video at 10 seconds, and you'll see that we've got a strong 110MHz peak!!  Hoooray!  The TV in the upper right side of the video is AS.  You can see as we flash, the peaks go up and down.  When there's no resonance, the 110 peak goes away. (Ex., when I'm PRMI locked on the sideband, there isn't a visible peak).

Alignment procedure was as normal:  Lock and align the arms. Misalign ETMs. Check that MICH fringes look good (ASS does a nice enough job that I don't actually lock and align the Michelson anymore).  Restore the PRM.  Lock PRMI.  Tweak PRM alignment to maximize POP110I.  At this point, Koji and I played a little with the PRMI, but when we finished with that, we restored the SRM, and tweaked its alignment by making nice overlap on the AS camera.

Then, we tried some DRMI settings, started seeing some locks, and played a bit with trying to optmize the settings that we have.

DETAILS:

PRMI settings:

PRCL ASC is on (with loop triggering).  MICH gain = -0.8, PRCL gain = +0.05.  FM4, FM5 always on, FM2 triggered.  Loop and filter module triggering on POP22I.  No power normalization.  MICH and PRCL locked on REFL55 I&Q, with 1's in the LSC input matrix.  PRCL actuating on PRM with +1, MICH actuating on BS with +0.5, PRM with -0.267.

I took transfer functions between REFL55 I&Q and REFL11 I&Q, to determine the relative gains and signs.  REFL11I's gain should be -18dB relative to REFL55I, with the opposite sign.  We tried PRMI locking with MICH = 1*REFL55Q and PRCL = -0.125*REFL11I for the input matrix.  Still no power normalization (we haven't used power norm at all today, so I'll quit writing that).

I took transfer functions between REFL55 I&Q and REFL33 I&Q.  REFL33I's gain is -8dB relative to REFL55I, but they have the same sign.  We tried locking PRMI with MICH = 1*REFL55Q and PRCL = +0.6*REFL33I.  Success.

Next up, some Optickle simulations, to help us go in the right direction for DRMI locking.  I checked the signs of the error signals REFL55I (PRM sweep), REFL11I (PRM sweep) and REFL55Q (MICH sweep) in both PRMI and DRMI configurations.  For all of these cases, the signs were the same (i.e. no sign flips needed to happen for DRMI locking, relative to PRMI locking).  I checked the sensing matrices for DRMI and PRMI for those same signals, and took the ratios of the sensing matrix elements.  This gave me the ratio of optical gains for each error signal, in the DRMI case vs. PRMI case, so any servo gain changes should be the inverse of these numbers.  These numbers are all DRMI/PRMI:  REFL55I PRCL response = 0.76, REFL11I PRCL response = 0.99, REFL55Q MICH response = 18.  So, when trying to lock the DRMI, we wanted to keep the gains for PRCL about the same, reduce the servo gain for MICH by a factor of ~20, but keep the same signs for everything.

In doing that, we started seeing some short DRMI locks, so we twiddled some parameters (mostly the elements in the LSC input matrix) a bit.  We eventually settled on:  PRCL = -0.125*REFL11I, MICH = 0.1*REFL55Q, and SRCL = 1.0 * REFL55I.  The output matrix was the same (MICH pushing on BS and PRM, PRCL on PRM), with the addition of a +1 in the SRCL -> SRM element.  For all 3 degrees of freedom (PRCL, MICH, SRCL), FMs 4 and 5 were always on.  For PRCL, FMs 2,3,6 were triggered to come on after 0.5 seconds of delay.  The PRCL FM triggers helped enormously.  I tried several other things, including changing the MICH input matrix element up and down in value, changing the SRCL input matrix element up and down in value, and engaging triggering for a few different filters in the MICH and SRCL degrees of freedom.  However, none of these made things better, and several made things worse.  Most notably, for SRCL, engaging triggering for FMs 2 and 3 kicked the cavities out of lock, which implies that perhaps our gain isn't high enough yet (and thus our UGF isn't very high yet).  I changed FM1 of SRCL to be +3dB of gain (from +10dB), and it would live through that coming on (trigger delayed by 1 sec, then ramping up over 1 second), but within a second after the filter finishing coming on, the cavity would fall out of lock (not violently kicked, just not locked anymore).

At this point, we were trying to figure out a way to confirm what kind of lock we had.  I checked Optickle again, and we do not expect to see a significant change in POP110I between the PRMI and DRMI cases, so that isn't a useful check.  We dreamed of having our AS110 demod board, or the AS OSA set up, but neither of those was going to happen tonight.  Instead, Koji suggested hooking up the PD, and looking directly at the output.

To-do:  Set up the AS OSA.  Also, perhaps temporarily borrow the 110 demod board from POP.  We were triggering on POP22 tonight, and that seemed to work okay.

9050   Thu Aug 22 07:57:57 2013 LisaUpdateLSCDRMI Locked for 1+ minute!!!!!!

Very nice!!  I was wondering, shouldn't the driving matrix be such that MICH pushes on SRM as well?

9051   Thu Aug 22 10:20:32 2013 kiwamuUpdateLSCDRMI Locked for 1+ minute!!!!!!

Wonderful ! I like the video -- the spatial mode looks pretty clean and much cleaner than what I observed in the old days.

9052   Thu Aug 22 13:03:40 2013 JenneUpdateLSCDRMI Locked for 1+ minute!!!!!!

 Quote: Very nice!!  I was wondering, shouldn't the driving matrix be such that MICH pushes on SRM as well?

Hmmm, yes, that's a very good point.  I think you're right, and I'll give that a try today.

9053   Thu Aug 22 13:20:54 2013 KojiUpdateLSCDRMI Locked for 1+ minute!!!!!!

Don't go for a hacky solution. We want to climb a staircase step by step.
Prepare an independent 110MHz demod ports.

 Quote: To-do:  Set up the AS OSA.  Also, perhaps temporarily borrow the 110 demod board from POP.  We were triggering on POP22 tonight, and that seemed to work okay.

9060   Sat Aug 24 00:11:07 2013 KojiUpdateLSCDRMI Locked with improved lock streatches

Friday night locking

Much more stable DRMI lock was achieved, partly thanks to the Friday-night quiet seismic,
and partly because of the improved servo gain and LF boosts

55MHz thru-put

I wanted to confirm the enhancement of the 110MHz signal at the AS port.

As the AS110 PD is placed in the CCD path, there is nothing visible with PRMI.
The Thorlabs PD was moved to the main AS path. Now the AS110 PD is receiving 50% of the power.

With PRMI 110MHz peak was -30dBm (As it was fluctuating, anything more precise number did not make sense)
When the DRMI was locked, the peak was enhanced to 0dBm.

The 2f signal comes from the beat between the sidebands.
Thus the amplitude of the intensity is proportional to the power of the sidebands (assuming the +1 and -1 order sidebands have the same amplitude)
-30dBm -> 0dBm means 31.6 times amplitude of the intensity. Therefore the amplitude transmission of the sidebands is 5.6 times more. (Is this true?)

According to the wiki, the AS port thru-put (i.e. power transmission) for the 55MHz sideband is 0.0026 and 0.43 for PRMI and DRMI respectively.
This corresponds to the amplitude difference of ~13. So we still have only half of the sidebands leaking out from the IFO. This could be attributed
to both the smaller PR gain and SR gain.

Locking setup

Same as the one Jenne used the other day. Later I engaged several additional triggers.
The following is the trigger setting I used

MICH: Delay 2 sec, FM1/FM2/FM3/FM6/FM7

PRCL: Delay 0.5 sec, FM2/FM3/FM6

SRCL: Delay 5 sec, FM1/FM2/FM3/FM6

SRCL FM1 was modified from +3dB to +6dB

Lock stability

Once lock is acquired, it lasts tens of minutes. (see the attached striptool chart.)
Even the lock is lost, it reacquires quickly.

The videos to show the lock acquisition and the in-lock stability are attached below.
The AS port beam is very round. It is not so shaky, but some yaw motion is visible.
The mode at the AS port is defined by the SRM, putting a QPD at the AS port would help to
stabilize the spot.

IFO state upon leaving

I left the 40m with the arms aligned, PRM and SRM slightly misaligned, and LSC setting is for the DRMI locking.

TO DO

- AS110I/Q for triggering

- PRCL/MICH/SRCL normalization

- We should resurrect the IFO config scripts.

- Remove BS->SRCL actuation coupling

- Handing off to 3f signals (preparation for the full lock)

- Improve ALS stability

- SRM ASC: AS QPD for SRM control

Lock Acquisition Video
UL (REFL) / UR (POP)
LL (AS) / LR (PRM Face)

In-lock video
UL (REFL) / UR (POP)
LL (AS) / LR (PRM Face)

Attachment 1: Screenshot-Untitled_Window.png
9061   Sun Aug 25 06:07:11 2013 ranaUpdateLSCDRMI Locked with improved lock streatches

We're ready for using the auto configure.

We can put our scripts for the MICH, PRMI, and DRMI into the IFO CONFIGURE screens for now and then it should be easy to get them into the Guardian once Jamie has the bugs worked out.

This screen can also be used to setup and start the dither alignment for each configuration (once we have one working for DRMI / SRM).

Also, now that the notches/bandstop filters for the violin modes have been move from the SUS into the LSC, we should fix the triggering to engage them a few seconds after the boosts.

13367   Mon Oct 9 01:29:26 2017 gautamUpdateLSCDRMI Nosie Budget v3.0

Summary:

I spent this weekend doing a more careful investigation of the DRMI noise. I think I have some new information/insights. Attachment #1 is the noise budget (png attached because pdf takes forever to upload, probably some ImageMagick problem. The last attachment is a tarball of the PDF). Long elog, so here are the Highlights:

1. Coil de-whitening does result in small improvement in noise in the 60-200Hz band.
2. Above 200Hz, we seem to be limited by "Dark" noise. More on this below.
3. The coupling from SRCL->MICH is the other limiting noise in the 60-200Hz band now.

Sensing Matrix Measurement:

• I rotated the AS55 demod phase from -42 degrees to -82 degrees, the idea being to get more of the MICH error signal in AS55_Q.
• Consequently, the MICH servo gain has been lowered from -0.035 to -0.021. Settings have been updated in the snap file used by the locking script.
• Seems to have worked.
• Attachment #2 is the measured sensing elements.
• One major source of uncertainty in these sensing element numbers is the actuator gains for PRM, SRM and BS. The coil driver electronics for the latter two have been modified recently, and for them, I am using numbers from this elog scaled by the expected factor as a result of removing the x3 gain in the de-whitening boards for SRM and BS.

MICH OLTF

• Measurement was done in lock using the usual IN1/IN2 method.
• Model made by loading the FOTON filters + assumed models for the BS pendulum and AA/AI filters in Matlab, and fitting to an overall gain + delay.
• Attachment #3 shows the agreement between measurement and model.
• The model was exported and used to invert in-loop signals to their out-of-loop counterparts in the noise budget.

DAC Noise

• I had claimed that turning on the coil de-whitening did not improve the MICH noise.
• This was not exactly true - I had only compared MICH noise with the BS de-whitening turned ON/OFF, while the ITM de-whitening was always on.
• Turns out that there is in fact a small improvement - see Attachment #4 (DTT crashes everytime I try to print a pdf, so png screenshot will have to do for now).
• I have also changed the way in which DAC noise is plotted in the Noise Budget code:
• I used to directly convert the measured voltage noise (multiplied by appropriate scalar to account for quadrature sum of 4 coils each in 3 optics) to displacement noise using the sensing measurement cts/m values.
• Now I convert the measured voltage noise first to current noise (knowing the series resistance), then to force noise (using the number 0.016 N/A per coil), then to displacement noise (assuming a mirror mas of 250g).
• Quadrature sum is again taken for 4 coils on 3 optics.
• I've also added the option to plot the DAC noise with the de-whitening filter TF applied (taking care that the maximum of filtered DAC noise / coil driver electronics noise is used at each frequency).
• So the major source of uncertainty in the calculated DAC noise is the assumed actuator gain of 0.016 N/A.

The DAC noise is not limiting us anywhere when the coil de-whitening is switched on.

I think this is the major find.

• The dark noise spectrum is measured with:
• the PSL shutter closed
• the AS55 I and Q analog whitening filters (and corresponding digital de-whitening filters) engaged, to mimic the operating conditions under which the in-lock error signal is acquired.
• Comparing the blue and black traces, it is clear that turning on the analog whitening is having some effect on the dark noise.
• However, the analog whitening filters should suppress the ADC noise by ~30dB @ 100Hz - so assuming 1uV/rtHz, this would be ~30nV/rtHz @100Hz.
• But the measured noise seems to be ~5x higher, with 4*10^-4 cts/rtHz translating to roughly 120nV/rtHz.
• The photodiode dark noise is only 15nV/rtHz according to the wiki. Where is this measured?

So I don't understand the measured Dark Noise level, and it is limiting us at frequencies > 200Hz. Some busted electronics in the input signal chain? Or can the LSC demod daughter board gain of ~5 explain the observed noise?

Shot noise

• The DC power on AS55 photodiode was measured to be ~13mW with the SRM misaligned.
• This corresponds to ~100cts peak amplitude on the ASDC channel (derived from AS55 photodiode).
• In the DRMI lock, the ASDC level is ~200cts.
• I used these numbers, and equation 2.17 in Tobin's thesis, to calculate this curve.

Edit 1730 9 Oct: I had missed out the factor of 5 gain in the demod board in calculating the shot noise curve. Attachment #7 shows the corrected shot noise level. Explicitly:

$n_{\mathrm{shot}} [m/\sqrt{\mathrm{Hz}}] = \alpha \sqrt{2 h \nu \bar{P} (\frac{1}{2} - \frac{1}{4}\mathrm{cos}2\theta)}$, where $\alpha [m/W] = (\mathcal{M}_{\mathrm{MICH}} [V/m] / 5 [V/V] / 420 [V/A] / 0.7 [A/W])^{-1}$is to convert shot noise in W to displacement units.

This is the other find.

• While chatting with Gabriele, he suggested measuring the SRCL->MICH and PRCL->MICH cross couplings.
• I injected a signal in SRCL servo EXC channel, and adjusted amplitude till coherence in MICH_IN1 was good.
• The actual TF measured was MICH_IN1 / SRCL_IN1 (so units of cts/ct).
• My multiplying the in-lock PRCL and SRCL IN1 signals by these coupling coefficients (assumed flat in frequency for now, note that measurement was only made between 100Hz and 1kHz), I get the trace labelled "AUX coupling" in Attachment #1 (this is the quadrature sum for SRCL and PRCL couplings).
• Also repeated for PRCL -> MICH coupling in the same way.
• Measurements of these TFs and coherence are shown in Attachment #5 (again png screenshot because of DTT).
• However, there is no significant coherence in MICH/SRCL or MICH/PRCL in this frequency range.

This seems to be limiting us from saturating the dark noise once the coil de-whitening is engaged. But lack of coherence means the mechanism is not re-injection of SRCL/PRCL sensing noise? Need to think about what this means / how we can mitigate it.

OL A2L coupling

• I didn't measure these
• These couplings would have changed because I modified the Oplev loop shapes to allow engaging of coil de-whitening filters.
• But anyways, their effect will only be below 100Hz because I made the roll-offs steeper.

Still to measure (but not likely to be limiting us anywhere in the current state):

• Laser intensity noise -> MICH coupling (using AOM).
• Laser frequency noise -> MICH coupling (using CM board IN2).
• Oscillator noise (amplitude + phase) -> MICH coupling (using AM/FM input of Marconi).

I've also made several changes to the NB code - will push to git once I finish cleaning stuff up, but it is now much faster to make these plots and see what's what.

Attachment 1: DRMI_NB.png
Attachment 2: DRMI1f_Oct8.pdf
Attachment 3: MICH_OLTF_model.pdf
Attachment 4: MICH_noises.png
Attachment 5: AUX_couplings.png
Attachment 6: C1NB_disp_40m_MICH_NB_2017-10-08.pdf.tar.gz
Attachment 7: MICH_NB_corrected.png
13368   Mon Oct 9 11:55:01 2017 KojiUpdateLSCDRMI Nosie Budget v3.0

My last characterization of the AS55 PD was on Feb 2013. ELOG 8100

There I said the dark noise at the PD output was 16nV/rtHz. I don't have the measurement of the Voltage noise at the output of the demod board.

Note that the PD can only be limited by shot noise when the DC current is larger then 4mA.

13412   Tue Nov 7 17:45:05 2017 gautamUpdateLSCDRMI Nosie Budget v3.1

Some days ago, I had tried to measure the SRCL->MICH and PRCL->MICH cross couplings using broadband noise injected between 120-180 Hz, a frequency band chosen arbitrarily, in hindsight, I could have done a more broadband test. I've spent some time including the infrastructure to calculate "White-Noise TFs" in the noise budgeting code, where a transfer function is estimated by injecting a "broadband" excitation into a channel of interest, and looking at the resulting response in MICH. I figured this would be useful to estimate other couplings as well, e.g. laser intensity nosie, oscillator noise etc.

I estimate the transfer function of the coupling using the relation (MICH is the median ASD of the MICH error signal in the below expression, and similarly for PRCL)

$|H_{cpl}| = \sqrt{\frac{|\mathrm{MICH}^{2}_{\mathrm{exc}} - \mathrm{MICH}^{2}_{\mathrm{quiet}}|}{|\mathrm{PRCL}^{2}_{\mathrm{exc}} - \mathrm{PRCL}^{2}_{\mathrm{quiet}}|}}$

Attachments #1 and #2 show the spectra of the MICH, PRCL and SRCL signals during 'quiet' times and during the injection, while Attachment #3 shows the calculated coupling TFs using the above relation. These are significantly different (more than 10dB lower) than the numbers I reported in elog 13367, where the measurement was made using swept sine. As can be seen in the attached plots, the injected broadband excitation is visible above the nominal noise level, and I calculated the white noise TFs using ~5mins of data which should be plenty, so I'm not sure atm what to make of the answers from swept-sine and broadband injections being so different.

Attachment #4 shows the noise budget from the October 8 DRMI lock with the updated SRCL->MICH and PRCL->MICH couplings (assumed flat, extrapolated from Attachment #2 in the 120-180Hz band). If these updated coupling numbers are to be believed, then there is still some unexplained noise around 100Hz before we hit the PD dark noise. To be investigated. But if Attachment #4 is to be believed, it is not surprising that there isn't significant coherence between SRCL/PRCL and MICH around 100Hz.

Nov 8 1600: Updating NB to inculde estimated Oplev A2L.

Quote:

This is the other find.

• While chatting with Gabriele, he suggested measuring the SRCL->MICH and PRCL->MICH cross couplings.
• I injected a signal in SRCL servo EXC channel, and adjusted amplitude till coherence in MICH_IN1 was good.
• The actual TF measured was MICH_IN1 / SRCL_IN1 (so units of cts/ct).
• My multiplying the in-lock PRCL and SRCL IN1 signals by these coupling coefficients (assumed flat in frequency for now, note that measurement was only made between 100Hz and 1kHz), I get the trace labelled "AUX coupling" in Attachment #1 (this is the quadrature sum for SRCL and PRCL couplings).
• Also repeated for PRCL -> MICH coupling in the same way.
• Measurements of these TFs and coherence are shown in Attachment #5 (again png screenshot because of DTT).
• However, there is no significant coherence in MICH/SRCL or MICH/PRCL in this frequency range.

This seems to be limiting us from saturating the dark noise once the coil de-whitening is engaged. But lack of coherence means the mechanism is not re-injection of SRCL/PRCL sensing noise? Need to think about what this means / how we can mitigate it.

Attachment 1: SRCL_MICH_whitenoise_tf.pdf
Attachment 2: PRCL_MICH_whitenoise_tf.pdf
Attachment 3: MICH_aux.pdf
Attachment 4: C1NB_disp_40m_MICH_NB_2017-10-08.pdf
13415   Wed Nov 8 09:37:45 2017 ranaUpdateLSCDRMI Nosie Budget v3.1

why no oplev trace in the NB ?

 #4 shows the noise budget from the October 8 DRMI lock with the updated SRCL->MICH and PRCL->MICH couplings (assumed flat, extrapolated from Attachment #2 in the 120-180Hz band). If these updated coupling numbers are to be believed, then there is still some unexplained noise around 100Hz before we hit the PD dark noise. To be investigated. But if Attachment #4 is to be believed, it is not surprising that there isn't significant coherence between SRCL/PRCL and MICH around 100Hz

also, this method would work better if we had a median averaging python PSD instead of mean averaging as in Welch's method.

13416   Wed Nov 8 09:59:12 2017 gautamUpdateLSCDRMI Nosie Budget v3.1

The Oplev trace is missing for now, as I have not re-measured the A2L coupling since modifying the Oplev loop shape (specifically the low pass filter and overall gain) to allow engageing the coil de-whitening.

The averaging for the white noise TFs plotted is computed using median averaging - I have used a python transcription of Sujan's matlab code. I use scipy.signal.spectrogram to compute the fft bins (I've set some defaults like 8s fft length and a tukey window), and then take the median average using np.median(). I've also incorporated the ln(2) correction factor.

It seems like GwPy has some in-built capability to compute median (and indeed various other percentile) averages, but since we aren't using it, I just coded this up.

 Quote: why no oplev trace in the NB ? also, this method would work better if we had a median averaging python PSD instead of mean averaging as in Welch's method.

1285   Mon Feb 9 16:05:01 2009 YoichiUpdateLSCDRMI OK

After the ISS work, I aligned the IFO and confirmed that DRMI locks with good SPOB and AS166 values.

7383   Fri Sep 14 00:56:13 2012 JenneUpdateGeneralDRMI aligned

[Rana, Jenne]

We aligned the DRMI, and have concluded that it looks good enough that we should close up and pump down soon. We still need to use the camera to check things, and get all pickoff beams out of the chambers, so don't get too excited yet.

We looked at the mode matching telescope's calculated beam propagation, and since we're using spherical telescope mirrors at non-zero degree incidence angle, we expect an astigmatism about like what we are seeing on the AS camera.  This matches up with the measurements that Mike posted from his and Q's measurements earlier today.  We think that it has 'always' been this way, and someone just picked a camera position such that the beam used to look more round than it does now.

We aren't entirely sure what's up with the SRM - it almost looks like the pitch and yaw are coupled, but it was pretty easy to align the PRMI.  We don't see any evidence of the crazy, crappy beam that we did before the vent.  This means we have fixed most of the bad clipping problems we were seeing over the last ~year.

In the process of aligning the DRMI, we fixed up the input beam alignment - we were not hitting the exact centers of the MMT mirrors (in pitch, mostly), so we fixed that, and propagated the alignment fix through the chain.  In all, we touched the knobs on PZT1, MMT1, MMT2, PZT2.  The beam then went through the SRM, and we touched a few of the output steering mirrors to get the beam centered on all mirrors.

I remeasured the MC spot positions, and they're a little worse than they have been.  Some of the spots seem to be off by 1.75mm (or less) on MC 1 and 3.  The numbers, MC1,2,3 pitch, then MC1,2,3 yaw are:   1.749759        9.744013        1.025681        -0.791683       -1.338786       -1.779958

A question to consider before doing the final-final alignment checking is: do we need to get the MC spots centered better than this, especially in light of the potential PMC axis having moved?

7405   Wed Sep 19 01:08:48 2012 JenneUpdateGeneralDRMI aligned again

The DRMI was aligned once again tonight.

Here's a video: http://youtu.be/Cy8nHL9yMeM  (Can someone please tell me / remind me how to make the elog embed videos?!?)

Description of video:

Video capture of AS camera.
NOTE: The beam is a few centimeters above ETMY with this alignment, so it will not be final.

Beginning is ITMY only.
ITMX is realigned to form MICH.
PRM is realigned to form PRMI.
SRM is realigned to form DRMI.
PRM is misaligned to form SRMI.
ITMX is misaligned to form SRY.

With this alignment, I opened up the ETMY door to find the beam there.  The beam is ~half on, ~half off of the top of the glass baffle.  Not the top of the hole, but the top of the piece of glass.  This means that it's many centimeters too high at ETMY.  This helps explain why, while swinging PZT2 around the other day, I could not see any beam on the cage.  It did, however, look pretty close (within a centimeter....I didn't look closer than that since it was so off in pitch) to centered yaw-wise.

Tomorrow I'd like a Clean assistant to help tweak PZT2 to hit the center of ETMY.  We'll need to put the 45 degree target back on to make sure that we don't end up pointing funny down the arm.  Then I'll realign the DRMI one more time.

Tonight, I can't check the full AS path, or any of the REFL path once it diverges from the main path.  Steve's new contraption (which is awesome!) doesn't have doors/windows yet, so I can't open it to get an IR card anywhere near any optics in the IOO or OMC chambers.  I waved PRM around a bit, but I can't find the beam on the REFL camera, so I definitely need to check that whole path again before we close up.

So, we're not closing up tomorrow, but progress has been made, and we're getting closer.

Note to self:  These are the ITMX, ITMY, PRM, BS, SRM biases with this DRMI alignment.  The DRMI is good, but the arms aren't, so these won't be final.  The saved alignments are still those with (for the Yarm) the beam bouncing several times between ITMY and ETMY.  BS was aligned at the time to hit the center of ETMX, and PRM and SRM should be retro reflecting in that alignment.  So, it's possible, that aligning PZT2 to hit the center of ETMY and restoring all of the optics will get me close to being back to DRMI aligned, but in a condition that the arms are align-able too.

Attachment 1: DRMI_aligned_19Sept2012_ETMYwasHighNeedToFix.png
7415   Thu Sep 20 01:28:14 2012 JenneUpdateGeneralDRMI aligned again, but with good arms

[Jenne, Manasa]

Using the alignment of the PZTs and BS from pre-dinner, where the beam was hitting the center of both ETMs, we aligned the DRMI.  The beam was off on the SRM in yaw by ~half a beam diameter, so I undid Koji's movement of SR2 from a week ago.  I loosened the SR2 dog clamps, touched it gently on the base to do a little bit of angle, then re-clamped it.  Once again, Steve's new brass centering target was awesome, since it was on the SRM while I was moving SR2.

We approximately recentered the beam on the AS camera, although it didn't need much once we got the beam out of the vacuum, by centering it on all of the output AS path mirrors.

We also got IPPOS out of the vacuum.  Manasa was in the process of centering the QPD when the laptop died from too long being unplugged, so we leave that for tomorrow.

Left to do:

REFL path.  REFL is not coming out of the vacuum, and with the light access connector I can't reach any of the REFL steering mirrors, since they're in the center of the IOO table.

IPANG.  Should be easy.

POP, POX, POY.  Need to the the camera-on-a-stick back down to the corner (from ETMY) and point it at the pickoff mirrors to ensure that beam is getting out of the vacuum.

ELOG V3.1.3-