I brought one CPU (Dell T3500) and one 28" monitor from Mike Pedraza's office in Downs to the 40m. It is on Steve's desk right now, pending setup. The machine already has Solidworks and Altium installed on it, so we can set it up at our leisure. The login credentials are pasted on the CPU with a post-it should anyone wish to set it up.

Jenne, Koji

The cause of the decrease was found and the problem was solved. We found this entry, which says

Yoich> We opened the MOPA box and installed a mirror to direct a picked off NPRO beam to the outside of the box through an unused hole.
Yoich> We set up a lens and a PD outside of the MOPA box to receive this beam. The output from the PD is connected to the 126MON cable.

We went to the PSL table and found the dc power cable for 126MOPA_AMPMON was clipping the 126MON beam.
We also made a cable stay with a pole and a cable tie.

After the work, 126MON went up to 161 which was the value we saw last night.

We also found that the cause of the AMPMON signal change by the DAQ connection, mentioned in this entry:

Jenne> 6.  We teed off of the AMPMON photodiode so that we could see the DC values on a DMM. 
Jenne> When we used a T to connect both the DMM and the regular DAQ cable, the DMM read
Jenne> a value a factor of 2 smaller than when the DMM was connected directly to the PD.

We found a 30dB attenuator is connected after the PD. It explains missing factor of 2.

While my checks of the AO signal path have thrown up some unanswered questions, I don't think there's any evidence in those measurements to suggest the AO crossover can't be realized. Thinking about it today though - I was wondering if it could be that the IN1 gain slider of the CM board is configured optimally. Looking back at some data, when the ALS CARM offset is zeroed, the CM_SLOW digitized data has a peak-to-peak range of ~200 cts. This is paltry. One possibility is that as I am upping the AO path gain, I'm simply injecting the electronics noise of the CM board into the IMC error point. I'd say it is safe to up the IN2 gain by 20dB to -12 dB, in which case the peak-to-peak would be ~2000 cts, still only 10% of the ADC range. It'll be straightforward to re-scale the CARM_B loop gain to account for this. Let's see if this helps.

I'd also like to measure the spectrum of the REFL11_I signal in a few different states. I think I should be able to do this using the OUT2 of the CM servo board. These are the things to try tonight:

• Try CARM RF handoff with CM_SLOW gain starting at -12dB instead of -32dB.
• Measure spectrum of REFL11_I when it is in the linear range.

 The other day, Jenne and I were comparing my MIST simulation to her Optickle simulation for the CARM transfer functions I posted some days ago. She told me that the arms are not exactly where they should be for the whole "PRC length tuning to account for sideband reflection phase off resonant cavity" deal. 

Specifically, as in the wiki (but with newer modulation frequencies), I calculated the ideal arm length to be 37.795 m some time ago, when doing PRC length simulations, and Jenne has told me that the X arm is more like 37.6m, and Y is 37.9. So, I updated my simulations, and found the following:

This does weird things to the f2 sideband buildup on resonance in the PRFPMI configuration:

(POP is way huger than than the TR's, because the POP pd's are artificially "inside" the cavity, whereas TRX/Y is actually transmitted through an ETM)

This is not necessarily directly something to worry about, but I think the following may be. It looks like this arm length mismatch actually causes the PRCL demodulation phase in REFL 165 to change dramatically with the CARM offset. (REFL33 seems fine, though. 5 degrees causes less than a 1% effective gain change.) 

My simulations don't include any signal recycling yet, so I don't have anything to show if there is a similar effect for SRCL, but it wouldn't surprise me... 

Koji and I taked about cleaning up some of the flaky cable situation on the PSL table a while ago. The changes were implemented and are documented in Attachment #1. Now the Pomona box between the Thorlabs HV Driver and the NPRO head is sitting on the PSL table (sandwiched between some teflon pieces I found in cabinet S4 along the south arm), and the cables between these two devices are better strain relieved. I turned off the Thorlabs HV supply while working on the PMC table. The IMC could be locked after this work. Probably won't solve the long standing FSS mysteries but probably can't hurt.

Unrelated to this work: I also removed a Bias tee that was just hanging out on top of the FSS electronics, which was used for the modeSpec project.

The Backstory:

Kevin was working on characterizing all of our RF photodiodes for the upgrade, and he discovered that REFL11 didn't work, as described in elog 3890.  Rana was working on fixing it, but then he went off to Japan.

Today's Activities:

I visually inspected the components inside the RF cage on the REFL 11 circuit board inside the PD.  Most of them were okay, but the connection between L5 and C33 (the big tunable inductor and the next capacitor in the path) was totally flaky.  the leg of the inductor had been soldered directly to the trace on the PCB, and the inductor was a little bit tipped over, and pulling the trace off the board.  I wiggled it a little while trying to see what was going on, and the trace broke.  Since there is nothing going on between L5 and C33, just the trace, I used a piece of resistor lead to attach the two.  The connection now seems very robust.  I'm a little worried about the connection between the inductor and the board on the other side, but I can't see it since it's under the inductor itself.

Also, the soldering of L4 (a standard surface mount component type body) to the board seemed totally shoddy.  I was desoldering the first side, and the whole inductor popped off.  It was clear that the inductor was making a physical connection to the board, but not a nice solid electrical connection.  So I resoldered it on.  (On Alberto's schematics, it is listed as a 633nH inductor.  I can't find any of this value, so I just put the same one back on.  The best I could do to confirm the component was still okay was measure its resistance, and compare that to a similar inductor of a similar value.  It seemed okay.)

After that I powered up the PD, and took an electrical transfer function, just to have a look-see.  It seems kind of okay, although the resonance seems to be closer to 13MHz than 11MHz. 

Since we would like to remove the capacitor that is in parallel with the diode itself, which will then change all of the resonant conditions on other components, I didn't worry too much about the resonant peak for tonight.  We're going to have to look in on this though.

Also, I'm leaving the optical check-out for Kevin, so he will let us know if I magically fixed the PD, or if it needs some more work.

Photos of the circuit board (mostly Alberto's mods) before and after I fitzed with it are on Picasa

The Future:

More testing. Probably more fixing.

Earlier today, I did some simulations that suggested that PRC lengths on the order of a cm from our current estimated one could result in degenerate PRCL and MICH signals in REFL165 at 3nm CARM offset. I attempted more demod-angle derived cavity PRC length measurements with REFL11 and REFL55, but they weren't consistent with each other...

In any case, adding dual recycling, even with a SRC length off by 1cm in either direction, doesn't seem to exhibit the same possibility, so I spent some time tonight seeing if I could make any progress towards DRMI locking. 

I was able to lock SRY using AS55 in a very similar manner to PRY, after adjusting the AS55 demod angle to get the error signal entirely in I. I used this configuration to align the SRM to the previously aligned BS and ITMY. Oddly, I was not able to do anything with SRX as I had hoped; the error signal looks very strange, looking more like abs(error signal). 

I then was able to lock the SRMI on AS55 I & Q, the settings have been saved in the IFO configure screen.  I've used AS55Q for PRMI locking with a gain of -0.2, so I started with that; the final gain ended up being -0.6. PRMI/PRY gain for prcl is something like 0.01, so since I used a gain of 2 for locking SRX, I started the SRCL gain around 0.02, the final gain ended up being -0.03. I basically just guessed a sign for AS110 triggering. Once I lucked upon a rough lock, I excited the PRM to tune the AS55 angle a few degrees; it was luckily quite close already from the SRY adjustment. AS110 needed a bigger adjustment to get the power into I. (AS55: -40.25->-82.25, AS110: 145->58, but I put AS55 back for PRMI)

I briefly tried locking the DRMI, but I was really just shooting in the dark. I went back and measured various sensing amplitudes/angles in SRMI and PRMI configurations; I'm hoping that I may be able to simulate the right gains/angles for eventual DRMI locking.

 Q EDIT: THIS IS WRONG. I LOCKED PRC ON THE CARRIER

 As Koji measured the other day: MICH and PRCL seem very degenerate in the 3f REFL PDs. 

I'm using this as a motivation to do some simulation in MIST and try to understand the best way to implement the 3F locking scheme. Hopefully my thinking below isn't nonsense...

First, I modeled the PRC with no arm cavities and the estimated cavity length I got with the PRM kick measurement, and looked at the REFL sensing matrix.

This agrees with the observed degeneracy. I then modeled the case of the PRC length that gives coincident SB resonance, again with no arm cavities.

Now there is good separation in REFL165. (REFL33 still looks pretty degenerate, however). This raised the question, "What does the angle between MICH and PRCL in REFL165 do as a function of macroscopic PRC length?" 

• We see ~90 degrees at coincident resonance
• Shortening the cavity, which we did to account for the arms, quickly shrinks the angle
• Presuming we moved to make the cavity 4cm shorter implies we had ~45 degrees between MICH and PRCL in REFL165 before the move. (Is this consistent with earlier observations?)

To me, this implies that locking the PRC on 3F from scratch won't be simple. However, the whole point of the PRC length choice is to have coincident SB resonance when the arms are resonating.

So: even if we're not spot on, we should be relatively close to the PRC length where having arms resonant gives us simultaneously resonant upper and lower sidebands, where MICH and PRCL should be orthogonal-ish. I.e. building up a little bit of IR power in the arms may start to break the degeneracy, perhaps allowing us to switch from 1F to 3F locking, and then continue reducing the CARM offset. 

So, I ultimately want to model the effect of arm power buildup on the angle between MICH and PRCL in the 3f PDs. This is what I'm currently working on. 

So far, I have reproduced some of the RC modeling results on the wiki to make sure I model the arms correctly. (I get 37.7949 m as the ideal arm length for a modulation freq of 11.066134 MHz vs. 37.7974m for 11.065399 MHz as stated on the wiki). Next, I will confirm the desired PRC length that accounts for the arms, and then look at the MICH vs PRCL angle in the REFL PDs as a function of arm power or detuning. 

 Q EDIT: THIS IS WRONG. I LOCKED PRC ON THE CARRIER

Koji noted oddities in the sensing matrix results I had gotten; namely that the plots showed REFL33 not changing at all, when we know for a fact that this should not be the case. 

Gabriele lent his eyes to my code, and came up with the idea that the modulation depths I was using were maybe not ideal (.1 for both 11 and 55). This affects REFL33 in that it is not simply Carrier * 33Mhz + 11Mhz * -22Mhz but also 22MHz * 55MHz, etc. 

I got more realistic values from Jenne (0.19 for 11MHz and .26 for 55Mhz) and re-ran the code, with more realistic results. The behavior for 165 has remained the same, but the other signals are more well behaved. 

Moral of the story: the modulation depths affect the 3f signals in a complicated way.

Disregard previous ELOGs, I had the PRC locked on carrier 

Locked on the sideband, the MICH / PRCL angle is much less sensitive to the PRC length, and shouldn't in fact be as degenerate as we've seen in reality. 

So, my simulations no longer provide any reason for the 3F signals to be so degenerate. 

[Jenne, Koji]

I moseyed into the control room this morning, to find ITMX and ITMY both with their watchdogs tripped.  ITMY (new convention) wouldn't damp.  Koji discovered that there was a sign flip in 2 of the sensors.  A set of reboots of c1susvme1&2 fixed the problem. 

A side note:  For the ETMs, the OSEM sensor readouts are gigantic (~20,000), whereas for the similar channels on all other optics, the readouts are on the order of 1.  After some looking around, it seems that this is just the way things have been (for at least 100 days), and the filters in the SUSPOS and other SUS filter banks have a high pass filter to take care of this.  It's weird, but it seems to be the way it is, and the ETMs damp, so it's all good.

The pumpdown seems to be progressing smoothly, so I think we are going to stick with the plan decided on Wednesday, and vent the IFO on Monday at 8am. I decided to do some checks of the IFO alignment.

I turned on the PSL again (so goggles are advisable again inside the VEA until this work is done), re-locked the PMC, and opened the PSL shutter into the vacuum (still low power 100 mW beam going into vacuum). The IMC alignment required minor tweaking, but I recovered ~1300 cts transmission which is what it was --> so we didn't macroscopically change the input pointing into the IMC while working on the IOO table.

Centering the ITMY oplev spot, there is a spot on the AS camera roughly centered on the control room monitor, so the TT pointing must also be pretty close.

Then I centered the ITMY oplev spot to check how well-aligned or otherwise the Michelson was - the BS has no Oplev so there was considerable angular motion of the Michelson spot, but it looked like on average, it was swinging around through a well aligned place. I saved the slow bias voltages for the ITMs and BS in this config.

Then I re-aligned ETMX and checked the green transmission - it was okay, ~0.3, and I was able to increase it to ~0.4 using the EX green PZT mirrors. So far so good.

Finally, I tried to lock the X-arm on IR - after zeroing the offsets on the transmission QPD, there seems to be a few flashes as the cavity swings through resonances, but no discernible PDH error signal. Moreover the input pointing of the IR into the X arm is controlled by the BS which is swinging around all over the place right now, so perhaps locking is hopeless, but the overall alignment of the IFO seems not too bad. Once ETMY is cleaned and put back in place, perhaps the Y arm can be locked.

I shuttered the PSL and inserted a manual beam block, and also turned off the EX laser so that we can vent on Monday without laser goggles.

*Not directly related to this work: we still have to implement the vacuum interlock condition that closes the PSL shutter in the event of a vacuum failure. It's probably fine now while the PSL power is attenuated, but once we have the high power beam going in, it'd be a good to revert to the old standard.

• UPS batteries
• 2x HEPA filters
• VWR chemicals (methanol)

These boxes were moved from the 40m hallway to the inside of the VEA so that we have some space to walk around. You can find some pictures here.

[Rana, Jenne]

We discovered to our great dismay that several important channels (namely C1:IOO-MC_L, but also everything on c1susvme2) are not being recorded, and haven't been since May 17th.  This corresponds to the same day that some other upgrade computers were installed.  Coincidence?

We've rebooted pretty much every FE computer and the FrameBuilder and DAQ_CONTROL approximately 18 times each (plus or minus some number).  No matter what we do, or what channels we comment out of the C1SUS2.ini file, we get a Status on the DAQ_Detail screen for c1susvme2 of 0x1000.  Except sometimes it is 0x2000.  Anyhow, it's bad, and we can't make it good again. 

I have emailed Joe about fixing this (with some assistance from Alberto, since we all know how much he likes doing the Nuclear Reboot option for the computers :)

This has been fixed, thanks to some help from Alex. It doesn't correspond to new computers being put in, but rather corresponds to a dcu_id change I had made in the new LSC model.

The fundamental problem is way back when I built the new LSC model using "lsc" as the name instead of something like "tst", I forgot to go to the current frame builder master file (/cvs/cds/caltech/chans/daq/master) and comment out the C1LSC.ini line. Initially there was no conflict with c1susvme, because the initially was dcu_id 13. The dcu_id was eventually changed to 10 from 13 , and thats when it conflicted with the c1susvme2 dcu_id which was also 10. I checked it against wiki edits to my dcu_id list page and I apparently updated the list on May 20th when it changed from 13 to 10, so the time frame fits.  Apparently it was previously conflicting with C0GDS.ini or C1EXC.ini, which both seem to have dcu_id = 13 set, although the C1EXC file is all commented out. The C0GDS.ini file seems to be LSC and ASC test points only.

The solution was to comment out the C1LSC.ini file line in the /cvs/cds/caltech/chans/daq/master file and restart the framebuilder with the fixed file.

 Just as I expected, since these hunuman didn't actually check MC_L after doing this stuff, MC_L was only recording ZERO. Joe and I reset and restarted c1susmve2 and then

verified (for real this time) that the channel was visible in both the Dataviewer real time display as well as in the trend.

The lesson here is that you NEVER trust that the problem has been fixed until you check for yourself. Also, we must always

specify a very precise test that must be used when we ask for help debugging some complicated software problem.

• Adjusted the PMC alignment
• Adjusted the IMC length offsets for the MC servo and the FSS servo
• Adjusted the MC alignment. Ran /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets
 
• The Yarm servo was oscillating. Reduced the servo gain from 0.2 to 0.08.
 
• AS Camera & AS port alignment was adjusted. Now the spot is at the center of the AS camera.
• Cleaned up the ASC offsets on the suspensions (i.e. C1:SUS-***_(PIT|YAW)_OFFSET) by replacing them by the BIAS adjustment.
• Saved the alignment values
• Locked the PRMI with SB with REFL55I for PRCL and AS55Q for MICH
• Aligned the PRM, then checked the alignment of the REFL PDs
• The best POP110I was 500cnt.
• Found REFL165 output was disconnected. It is now restored.
   
• Used the LSC lockins to figure out the demod phases and the signal amplitudes (relative)

PRCL: 100cnt -> PRM 567.01Hz

Signal in demod Q ch were minimized

REFL11I -19.2deg demod I, Lockin I out (C1:CAL-SENSMAT_PRCL_REFL11_I_I_OUTPUT) 12.6 cnt
REFL33I +130.4deg 1.70cnt
REFL55I +17.0deg 2.30cnt
REFL165I -160.5deg 27.8cnt

MICH: 1000cnt -> ITMX(-1) & (ITMY +1.015 => Minimized the signal in REFL11I to obtain pure MICH)

REFL11I   +0.0     REFL11Q   +0.119
REFL33I   +0.023 REFL33Q   -0.012
REFL55I   +0.023 REFL55Q   -0.113
REFL165I +0.68   REFL165Q +0.038

It seems that REFL165 has almost completely degenerated PRCL and MICH.

• Try to replace ITMX/Y with BS (+0.16) / PRM (-0.084)

 ITMX(-1)/ITMY(+1.015) actuation was cancelled by BS (+0.16). This introduces PRCL in REFL11I. This was cancelled by PRM (-0.084)

REFL11I   +0.0     REFL11Q   +0.13
REFL33I   -0.012  REFL33Q   0.025
REFL55I   +0.041 REFL55Q   -0.45
REFL165I +0.69   REFL165Q +/-0.02

Again, It seems that REFL165 has almost completely degenerated PRCL and MICH.

Locking info:

PRCL:
[Signal source] REFL11I (-19.2deg) x 0.16, OR REFL33I (+130.4deg) x 2.0, OR REFL55I (+17.0deg) x1.0, OR REFL165I (-160.5deg) x0.05
[Trigger] POP110I(-81deg) 100/10, FM trigger 35/2, delay 0.5sec FM2/3/6/9
[Servo] FM4/5 always on. G=-0.02, Limitter ON
[Output] PRM x+1.00

MICH:
[Signal source] AS55Q (-5.5deg) x 1, OR REFL11Q x 0.25, OR REFL55Q x-0.06
[Trigger] POP110I 100/10, FM trigger 35/2, delay 5sec FM2/3/9
[Servo] FM4/5 always on. G=-10, Limitter ON
[Output] ITMX -1.0 / ITMY +1.0 (or +1.015), OR PRM -0.084 / BS +0.16

We made an attempt at cleaning up the phase camera setup electronics.

We have moved a portion of the electronics onto the SP table (specifically the mixer, splitters, amplifiers, and associated power).  We put away a large number of cables which were unneeded, both BNC and power cables. The Innolight Mephisto power supply and one signal generator are still behind 1Y2 on top of a non-functioning VME crate.  The second VME crate was put along the south arm where two other VME crates already were.  We placed a fair number of BNC cables and power cords back on their cable racks or approriate storage space, so the rats nests of cables has been reduced.

We moved one power strip from plugging in beyind 1Y1, to the far side of the SP table (closer to the 1Y3 rack), and also found and plugged in another power strip (also on the far side of the SP table) and placed this underneath the SP table to be able to power the signal generator and Innolight Mephisto laser (its not plugged in currently, but we'd like to do so next week).

I pushed a notebook and a Finesse model for comparing different LO phase locking schemes. Notebook is on https://git.ligo.org/40m/bhd/-/blob/master/controls/compare_LO_phase_locking_schemes.ipynb,

Here's a description of the Finesse modeling:

I use a 40m kat model https://git.ligo.org/40m/bhd/-/blob/master/finesse/C1_w_initial_BHD_with_BHD55.kat derived from the usual 40m kat file. There I added and EOMs (in the spaces between the BS and ITMs and in front of LO2) to simulate audio dithering. A PD was added at a 5% pickoff from one of the BHD ports to simulate the RFPD recently installed on the ITMY table.

First I find the nominal LO phase by shaking MICH and maximizing the BHD response as a function of the LO phase (attachment 1).

Then, I run another simulation where I shake the LO phase at some arbitrary frequency and measure the response at different demodulation schemes at the RFPD and at the BHD readout.

The optimal responses are found by using the 'max' keyword instead of specifying the demodulation phase. This uses the demodulation phase that maximizes the signal. For example to extract the signal in the 2 RF sideband scheme I use:

pd3 BHD55_2RF_SB $f1 max $f2 max $fs max nPickoffPDs

I plot these responses as a function of LO phase relative to the nominal phase divided by 90 degrees (attachment 2). The schemes are:

1. 2 RF sidebands where 11MHz and 55MHz on the LO and AS ports are used.

2. Single RF sideband (11/55 MHz) together with the LO carrier. As expected, this scheme is useful only when trying to detect the amplitude quadrature.

3. Audio dithering MICH and using it together with one of the LO RF sidebands. The actuation strength is chosen by taking the BS actuation TF 1e-11 m/cts*(50/f)**2 and using 10000 cts giving an amplitude of 3nm for the ITMs.

For LO actuation I can use 13 times more actuation strentgh becasue its coild drivers' output current is 13 more then the old ones.

4. Double audio dithering of LO2+MICH detecting it directly at the BHD readout (attachment 3).

Without noise considerations, it seems like double audio dithering is by far the best option and audio+RF is the next best thing.

The next thing to do is to make some noise models in order to make the comparison more concrete.

This noise model will include Input noises, residual MICH motion, and laser noise. Displacement noise will not be included since it is the thing we want to be detected.

We found c1lsc, c1iscex, c1iscey, c1susvme, c1asc and c1sosvme are dead.
We  turned off all watchdogs and turned off all lock of suspensions.
Then, I tried to reboot these machines from terminal, but I couldn't login to all of these machines.

So, we turned off and on key switches of these machines physically, and login to them to run startup scripts.

Then we turned on all watchdogs and restored all IFO.

Now they look like they are working fine.
 

At the suggestion of Rana and Koji, I have worked out some design parameters for a Stewart platform to be used as a vibration isolation device or as a platform for characterization of suspensions.  I have made some initial guesses about the following design requirements:

• linear travel: 40 microns peak to peak (based on SOS design requirements in LIGO-T950011)
• angular travel: 3 mrad peak to peak (based on SOS design requirements in LIGO-T950011)
• payload mass: 5 kg (wild guess of mass of loaded SOS)
• payload moment of inertia: 0.01 kg m^2 (wild guess)
• bandwidth: 500 Hz (suggestion of Rana and Koji: ~kHz)

From these assumptions, I have worked out:

• peak actuator force: 0.88 kN
• minimum radius of top platform: 15 cm
• minimum radius of bottom platform: 30 cm
• minimum height: 26 cm

The combination of high force, high speed, and ~micron travel limits seems to point to piezoelectric actuators.  PI's model P-225.80 would meet the peak push-pull force requirement, but I have not yet determined if it would meet the bandwidth requirement.  Apparently, typical piezoelectric actuators can exert a greater push force than pull force; wonder if one could use an actuator with a smaller force range than the P-225.80 if the actuator is biased by compression.  (Is this what is meant by a "preloaded" actuator?) 

I have attached a PDF explaining how I worked out the actuator force and platform dimensions.  (I'll try to dice up this PDF and put the contents in the Wiki.)  I also have a plant model in MATLAB with which I have been playing around with control schemes, but I don't think that this is ready to show yet.

Here are some tasks that still remain to be done for this preliminary case study:

• select sensing technologies: integrated linear encoders and/or strain meters, inertial sensing, optical levers, etc.
• study joints: Koji and Rana suggest flexures; I need to propose the joint geometry and material
• study internal modes of the platforms and actuators themselves
• build noise budget

I'd like to ask for input principally on:

• appropriateness of my design assumptions
• piezo actuators currently in use in the lab

 Edit: I also added a Mathematica notebook with the inverse kinematics (mapping from platform state to leg lengths) of the platform. 

 I've been getting a simulation going with the eventual goal of simulating CESAR-type signals for CARM. So for I've only been using MIST, though I'm still thinking about what to do for a fully time domain approach. (For example, maybe a mixture of simulink and analytical equations? We'll see how painful that gets...)

Anyways, with the parameters I have for the 40m, I've set up a simulation, where I can do things like a "static" CARM scan.

(i.e. PRMI perfectly locked. Ask what different PDs see if the arms were just statically sitting at some CARM offset)

PDH signals are there in the REFL diodes. The coupled line width here looks smaller than the ~40pm number I've heard before, so I should check my parameters. (Likely culprit, I'm using nominal R and T for the arm cavities)

I've also done the slightly more sophisticated thing of looking at the transfer function from CARM motion to different PDs, at different CARM offsets. For TRX and REFLDC, these seem to match up qualitatively to some plots that Kiwamu has done for aLIGO, with frequencies shifted by the relative arm length factor of 100. (Q's left, K's right, Y-axis on mine are W/m with 1W input the IFO)

We can also look at the PDH diodes (revised from my initial post. Had an error in my code): 

That's where I've gotten so far!

A big factor in how much IFO locking activities can take place is how cooperative the IMC is.

Since the c1psl upgrade, the IMC duty cycle has definitely deteriorated. I took a measurement of the dark noise at the IMC error point with 1 Hz FFT binwidth, with all electrical connections to the IMC servo board except the Acromag and Eurocrate power disconnected. I was horrified at the prominence of 60 Hz harmonics - see Attachment #1. In the past, this kind of feature has been indicative of some error in the measurement technique - but I confirmed that the lines remain even if I unplug the GPIB box, and all combinations of floating/grounded inputs that I tried. We know for sure that there is some excess noise imprinted on the laser light post upgrade. While these lines almost certainly are not responsible for the PCdrive RMS going bonkers, surely this kind of electrical situation isn't good?

Attachment #2 shows the same information translated to frequency noise units, taking into account the complementary sensitivity function, L/(1+L) - the sum contribution of the 60 Hz peaks to the RMS is ~11.5% of the total over the entire band (c.f. 1.7 % that is expected if the noise at multiples of 60 Hz was approximately equal to the surrounding noise levels). Moreover, the measured RMS is 55 times higher than a LISO model. 

How can this be fixed?

Some tests done today:

All of these tests were done with the PRMI locked with carrier resonant in the recycling cavity (i.e. sidebands rejected to REFL port). I then actuated the BS length DOF with a sine wave at 311.1 Hz, 40 cts amplitude (corresponding to ~8 pm of peak-to-peak displacement).

1. Attempt to balance the DCPDs
   • I tried to tune the digital gains of the two DCPDs so as to minimize the appearance of this line in the SUM channel
   • but no matter how I tuned the gains, I couldn't make the line in the SUM channel disappear entirely - in fact, the best I could do was to make the line height in SUM and NULL channels (yes I recognize the poor channel name choice, I'll change "NULL" to "DIFF" at the next model recompile) the same. See Attachment #1.
   • The lobes around the main peak are indicative of some scattering?
   • Attachment #2 shows a wider frequency range. The homodyne phase isn't controlled, so the "NULL" channel is not necessarily measuring the correct quadrature to be sensing MICH motion.
   • I think I can back out something about the contrast defect from this fact, but I need to go back to some modeling.
2. A simple test of the homodyne phase actuator
   • I wanted to check that this PI S320 piezo actually allows me to actuate the optical path length of the local oscillator.
   • I'm using the OMC HV driver to drive said PZT - so there are two DAC channels available, one to dither the optic and one to apply a control signal. I think mainly this is to avoid using up DAC range for the dither signal, the overall dynamic range is still limited by the HV supply.
   • I can't find the maximum voltage that can be applied on the datasheet - so conservatively, I limited the HV output to saturate at 100 V DC, as this is the maximum for the S330 piezos used for green steering, for which there is a manual.
   • The S320 manual does say the full stroke of each PZT element is 10 um - so the actuation coefficient is ~100 nm/V. I then drove this actuator with a sine wave of 500 cts amplitude, at 314.1 Hz (corresponding to 15 nm of motion). With only the LO beam incident on the PDs, I saw no signal in either DCPD - as expected, so this was good.
   • Then, with the PRMI locked, I repeated the test. If there is no DC light field (as expected for the PRMI in this configuration), I wouldn't expect this drive signal to show up in the DCPDs. But in fact, I do. Again, this supports the presence of some (for now unquantified) contrast defect.

While it would seem from these graphs that the RIN of the LO beam at these frequencies is rather high, it is because of the ADC noise. More whitening (to be installed in the coming days) will allow us to get a better estimate, should be ~1e-6 I think.

I was just playing today, still need to setup some more screens, DTT templates etc to do more tests in a convenient way.

I manually aligned the IMC. Spot positions are all < 1.5mm. PMC trans of ~0.74, MC2 Trans of ~15400, MC Refl ~0.4, which is better than its been for some time now.

Somehow the WFS DC offsets were off, which made it look like it was impossible to center the beam on WFS2. The script for setting these wasn't working so I fixed it, ran it. WFS and MC2 trans offsets were set, WFS are back on and have been holding MC REFL nice and low for ~3 hours.

Arms were dither aligned, wrote the offsets to SDF files. Oplevs need centering. No further daqd crashes.

• Empty N2 replaced. 
• Logged back into zita and started the StripTool traces (even though we keep the TV off nowadays).
• c1susaux acro-crate power cycled to re-enable PRM suspension control (all other vertex optics also now respond to slow bias voltage sliders being moved).
• c1iscaux needed a hard reboot as it wasn’t seen on martian. I power cycled the crate for good measure.
• Marconi turned back on with correct frequency/amplitude.
• c0rga is now seen again on martian network. I re-enabled the RGA scanning so that it takes a scan every morning at 4am. 
• The forepumps for TP2/TP3 are noisier than I remember. The former has ~10,000 hrs on the clock. How often does the tip seal replacement need to happen?
• HV supplies for ASX/ASY PZTs re-energized.
• IFO re-aligned for locking.
• c1oaf and c1daf models restarted. c1oaf required the usual start/stop/start sequence to make the DAQ errors go away, and luckily the FE didn’t crash when the model was unloaded.
• POX/POY/PRMI 1f carrier/green locking all was smooth.
• For some reason, the PRC angular FF filters i trained no longer do anything good (but MCL is still good). collected 20mins of PRMI 1f locked data for investigations.

The optomechanics stock in the lab was in a sad state. We have obtained the following from Thorlabs in the last two months:

1. 6 pcs each of DT12 and DT12B compact translation stages (for lens mode matching).
2. 3pcs each KM100PM + PM3 cube beamsplitter mounts (for polarization control).
3. 1 Post / spacer kit for height adjustment.
4. 3 pcs ea of K6XS + AD11F + F220APC for fiber applications.

I have used some of these for the ari BHD setup. The unused items are stored in the shelves that house the optomechanics ~halfway down the east arm. I'm wondering what's a good setup to document the stock of this stuff so we can always have a healthy stock of optomechanics (at least the non speciality ones like posts, spacers etc). It sucks to realize at 0000hrs that you're missing a 3mm shim or 250mm converging lens or something.

[Rana / Kiwamu]

 As a part of the ALS noise budgeting we took a look at the Y end PDH setup to see if we are limited by an effect from the Amplitude Modulation (AM).

(AM transfer function)

(Y table setup needs more improvements)

• Use washers
• Beam clipping in Green Faraday and the very last mirror
• Use two screws and wide base plate
• Tune PPKTP PID parameters
• Remove flipper mirror
• Move the mechanical shutter to where the beam size is smaller
• Put a beam damp for the reflected light from the PD
• Cable rack
• Improve the incident angle on the last two launching mirrors

What is meant by the "average response of 50 dB"? Is this dB[ RIN / Hz ] or something? Also, do you mean the average over a broad band or the average response at the chosen modulation frequency over several trials? I don't really understand what measurement was done.

 I think I solved the problem (as you can probably see).

The cause was that this WYSIWYG interface for HTML is provided by an independent text editor called FCKeditor which is included in the elog. Although the elog installer has a bug and does not unzip properly the relative package. One has to do it by hand. (going to /elog/scripts/ and unzipping fckeditor.zip by hand in the same directory).

Tried to lock the interferometer but arm power didn't get over 65.

Tonight, after the weekend, I resumed the work on locking.

When I started the Mode Cleaner was unlocked because the MZ was also unlocked.

I aligned the MZ and the transmitted power reached about 2.5

Initially the interferometer lost lock at arm power of about 3-4. It looked like the alignment wasn't good enough. So I ran the alignment scripts a few times, first the scripts for the single parts and in the end the one for the full IFO.

Then I also locked again the MZ and this time the transmitted power got to about 4.

In the following locking attempts the the arm power reached 65 but then the lock got lost during the handing of CARM to C1:LSC-PD11_I

I'll keep working on that tomorrow night.

• Re-aligned and locked the arm cavities for IR and green.
• Re-set trans normalization because after the c1iscex and c1iscey reboots, these didn't come back to the old values.

[EricQ, Jenne]

We wanted to make the PRMI lock more stable tonight, which would hopefully allow us to hold lock much longer.  Some success, but nothing out-of-this-world.

We realized late last week that we haven't been using the whitening for the ASDC and POPDC signals, which are combined to make the MICH error signal.  ASDC whitening is on, and seems great.  POPDC whitening (even if turned on after lock is acquired) seems to make the PRMI lock more fussy.  I need to look at this tomorrow, to see if we're saturating anything when the whitening is engaged for POPDC.

One of the annoying things about losing the PRMI lock (when CARM and DARM have kept ALS lock) is that the UGF servos wander off, so you can't just reacquire the lock.  I have added triggering to the UGF servo input, so that if the cavity is unlocked (really, untriggered), the UGF servo input gets a zero, and so isn't integrating up to infinity.  It might need a brief "wait" in there, since any flashes allow signal through, and those can add up over time if it takes a while for the PRMI to relock.  UGF screens reflect this new change.

Unfortunately, we only had one good CARM offset reduction to powers of about 25, but then my QPD loop blew it. We spent the vast majority of the night dealing with headaches and annoyances. 

Things that were a pain:

• If TRX is showing large excursions after finding resonance, there is no hope. These translate into large impulses while reducing the CARM offset, which the PRMI has no chance of handling. The first time aligning the green beat did not help this. For some reason, the second time did, though the beatnote amplitude wasn't increased noticibly. 
  • NOTICE: We should re-align the X green beatnote every night, after a solid ASS run, before any serious locking work. 
  • Afterwards, phase tracker UGFs (which depend on beatnote amplitude, and thereby frequency) should be frequently checked. 
• We suffered some amount from ETMX wandering. Not only for realigning between lock attempts, but on one occasion, with CARM held off, GTRX wandered to half its nominal value, leading to a huge effective DARM offset, which made it impossible to lock MICH with any reasonble power in the arms. Other times, simply turning off POX/POY locking, after setting up the beatnotes, was enough to significantly change the alignment. 
• IMC was mildly tempermental, at its worst refusing to lock for ~20min. One suspicion I have is that when the PMC PZT is nearing its rail, things go bad. The PZT voltage was above 200 when this was happening, after relocking the PMC to ~150, it seems ok. I thing I've also had this problem at PZT voltages of ~50. Something to look out for. 

Other stuff:

• We are excited for the prospect of the FOL system, as chasing the FSS temperature around is no fun. 
• UGF servo triggering greatly helps the PRMI reacquire if it briefly flashes out, since the multipliers don't run away. This exacerbated the ALS excursion problem. 
• Using POPDC whitening made it very tough to hold the PRMI. Maybe because we didn't reset the dark offset...?

Preparations

- According to Diego's report, the MC WFS gains were too high. We'll fix this later by tweaking the servo shapes.
But for now, all of the WFS gains were reduced by 40%.
i.e. WFS(1|2)(PIT|YAW) gains from 5 to 3, MC2TRANS(PIT|YAW) gains from 50 to 30.

- Aligned IMC carefully and ran the offset nulling script. MC REFL became 0.435~0.445 and MC TRANS was ~16600.

- Locked the arms and ran ASS.

PRMI

- Started locking PRMI. I just used REFL33I&Q as suggested by the configure script. The PRMI locking was not so robust.
Particularly, the third violin mode of PRM and BS seemed to get excited and dominated the signals.
I modified Vio3 filter in the violin filter for BS and PRM to include zero at 1921Hz where the growing peak was seen.

- We probably want to start from the 1f signals for DRMI lock acquisition. So I wanted to check how REFL11s are.
Measured the demod phase and relative gain between 33I and 11I. (By the way, REFL11I whitening gain was lowered to 0dB).
REFL11I had about x10 gain and the same phase compared to REFL33I. The demod phase for REFL11 was +21deg.
Also checked REFL55 phase and gain. 55Q has almost the same gain as 33Q. And the adjusted phase was 25deg.
These were just rough adjustment of the demod phases.

- Then the servo configuration was transtioned to Configuration 1 (below), and then Configuration 2.

- This configuration was very stable and the PRMI stayed locked about ~1 hour. During this long lock, I could measure 
PSDs, sensing matrix, and etc. Also I could play with the PRM ASC. I wasn't sure if the POP is actually stabilized or not.
(I have no data)

- I noticed that something was ringinging up at 1883Hz. Another 3rd order viloin mode???

- The lock was lost due to too strong injection. But also it reacquired without touching.

- Precise demod phase adjustment has been done by elliminating PRCL from the Q signals.

REFL11 16.75
REFL33 133.0
REFL55 31.0
REFL165 -142 
AS55 -53

- Configiration1 (REFL11I&REFL55Q)

REFL11: WTN 0dB PHASE 21deg, REFL11I x0.1 -> PRCL
REFL33: WTN 30dB PHASE 145deg
REFL55: WTN 21dB PHASE 25deg, REFL55Q x1 -> MICH

PRCL: GAIN -0.04 FM4/5 ON, Triggered FM 2/3/6/9, Servo trigger: POP22I 50up 10down, No Normaization.
MICH: GAIN 10 FM4/5 ON, Triggered FM 2/3/6/9, Servo trigger: POP22I 50up 10down, No Normaization.

PRCL -> PRM +1
MICH -> PRM -0.2625, BS +0.50 BS

- Configuration 2 (REFL11I&Q)

Same as above except:
REFL11Q x-0.1 -> MICH

Calibration

Let's use these entries 

PRM: http://nodus.ligo.caltech.edu:8080/40m/8255
PRM:  (19.6 +/- 0.3) x 10^{-9} (Hz/f)^2 m/counts

BS/ITMs http://nodus.ligo.caltech.edu:8080/40m/8242
BS     = (20.7 +/- 0.1)    x 10 ^-9 / f²
ITMX = (4.70 +/- 0.02)  x 10 ^-9/ f²
ITMY = (4.66 +/- 0.02) x 10 ^-9/ f²

- PRCL Calibration

Lockin oscillator module 675.13Hz 100 -> +1 PRM

Measurement bandwidth 0.1Hz -> Signal power BW 0.471232 (FLATTOP window)

C1:SUS-PRM_LSC_IN1: 118.99 cnt/rtHz => 5.12pm/rtHz
REFL11I: 17.84  cnt/rtHz => 3.49e12 cnt/m
REFL33I:  2.28  cnt/rtHz => 4.46e11 cnt/m
REFL55I:  0.158 cnt/rtHz => 3.09e10 cnt/m
REFL165I: 1.63  cnt/rtHz => 3.19e11 cnt/m

- MICH Calibration

Lockin oscillator module 675.13Hz 100 -> -1 ITMX +1 ITMY

Measurement bandwidth 0.1Hz -> Signal power BW 0.471232 (FLATTOP window)

C1:SUS-ITMX_LSC_IN1: 121.79 cnt/rtHz => 1.26pm/rtHz
C1:SUS-ITMY_LSC_IN1: 121.79 cnt/rtHz => 1.25pm/rtHz
REFL11Q:  0.0329   cnt/rtHz => 1.32e10 cnt/m (PRCL/MICH ratio 265)
REFL33Q:  0.00773  cnt/rtHz => 3.09e9  cnt/m (144)
REFL55Q:  0.001645 cnt/rtHz => 6.58e8  cnt/m (47)
REFL165Q: 0.00374  cnt/rtHz => 1.50e9  cnt/m (213) !?
AS55Q:    0.0696   cnt/rtHz => 2.78e10 cnt/m

Openloop TF measurements
Servo filter TF measuremnts

The UGFs were ~250Hz for PRCL and ~120Hz for MICH, respectively.
The OLTF was modelled by the servo and violin filters TF from foton, estimated TF of the AA/AI filters, and the constant time delay.

Displacement spectra measurement

SELF NOTE: DON'T FORGET TO TURN ON the whitening of the unused signals! (USE MC DOF or manual switch)

- PRCL

The PRCL displacement was measured with REFL I signals. In the attachment 3, the in-loop and free-run equivalent displacements are shown (red and blue).
Other out-of-loop sensors (33/55/165) were also plotted together.

FIrst of all, the uncompensated displacement noise level of PRCL is around 1e-7 m/rtHz. This is a good indication that the calibration was not crazy.

The sensing noise of REFL11 seems to be 1e-15~1e-16 m/rtHz at high frequency which is enough for now.
As expected, REFL11I has the best noise level among the REFLs. At low frequency, it seemed that the noise level is limited by something at 1e-12 m/rtHz.
Of course, we can't say this is just the sensing noise of the other REFLs or the noise of the REFL11I. But this noise level is enough small for the locking of
the low finesse (F<100) PRCL cavity.

Remembering we had no trouble locking PRCL with REFL33/55/165, this plot indicates that the PRCL was suppressed too much below 2Hz.
And we want more supression between 5Hz to 30Hz. We have resonant gains in ther PRCL servo but not sure how effective they were.
If we consider the contamination of PRCL in MICH, we should try to optimize the PRCL servo.

- MICH

The MICH displacement was similary calibrated to PRCL. The signal sources were the REFL Qs and AS55Q.
In the attachment 4, the in-loop and free-run equivalent displacements are shown (red and blue).
Other out-of-loop sensors were also plotted together.

The problem here is that the out-of-loop levels (REFL33/55/165 and AS55) show almost the same levels
and thus it is likely that the actual (out-of-loop) stability of MICH is this kind of level. If we believe it, we only have
~1/100 supression between 1-10Hz and ~1/10Hz below 0.5Hz. The strong servo control does nothing to stablize
MICH. From the out-of-loop noise level of MICH, this comes for the contamination from leakage PRCL.
We really need to improve the signal quality of MICH.

The MICH servo filter has quite complicated shape, but is not necessary according to the estimated free-runing MICH.

The MICH free-running motion is quieter than the PRCL one between 1Hz to 30Hz. The reasonable explanation is
that it comes from poor vibration isolation of the tip-tilts. It means that SRCL also has the similar noise level to PRCL.

I have been playing with the IFO tonight.  Mostly, I wanted to make sure that all of the scripts for the carm_cm_up sequence were working, and they seem to all be fine. 

I also turned on all 4 UGF servos.  My big ah-ha moment for the night is that the excitation is multiplied by the gain multiplier.  This means that if the UGF servo is multiplying by a small number (less than 1), the excitation will get smaller, and could get small enough that it is lost in the noise.  Now the error signal for the UGF servo is very noisy, and can dip to zero.  Since we can't take the log of zero, there are limiters in the model, but they end up giving -80dB to the error point of the UGF servo.  This makes it all freak out, and often lose lock, although sometimes you just get a weird step in the UGF servo output. 

Anyhow, we need to be mindful of this, and offload the UGF servos regularly.  I think the better thing to do though will be to divide the excitation amplitude by the gain multiplier.  This will undo the fact that it is multiplied by that number, so that the number of counts that we put into the excitation amplitude box is what we expect. 

After some brainstorming with Jenne and Q, both the model and the medm screen have been modified: the entire block "Test1 - injection of the excitation - Test2" has been moved after the servo output. In this way we avoid completely the multiplication problem without having to perform divisions that could lead to division-by-zero problems. Because of how the logic is done now, one UnitDelay block had to be inserted before each one of Test1 and Test2.

Since the UGF Servo has been heavily modified lately, I'll post the current status of the model (as an attachment, as inpage images lose too much quality).

Elog from ~5am last night:

Tonight was just several trials of PRFPMI locking, while trying to pay more attention to the lockloss plots each time.

General notes: 

I tried once to acquire DRMI on 1f while the arms were held off resonance.  I wasn't catching lock, so I went back to PRMI+arms.  I aligned the PMC, which I noted in a separate elog.  

I was able to hold the PRMI on REFL33I&Q, and have ALS CARM and DARM at zero CARM offset.  The arm would "buzz" through the resonance regularly.  I use the word buzz because that's kind of what it sounded like.  This is the noise of the ALS system.

I think we want to add the transmission QPD angular signals to the frames.  Right now, we just keep the sums.  It would have been handy to glance at them, and see if they were wiggling in the same way that some other signal was waggling. 

All the data files are in /opt/rtcds/caltech/c1/scripts/LSC/LocklossData.  Each folder is one lockloss.  It includes text files for each trace, as well as any plots that I've made, and any notes taken.  The text files are several MB each, so I'm not going to bog the elog down with them.  There are a few folders that end in "_notInteresting".  These ones are, as one might guess, not interesting.  2 were MC locklosses (I'm not actuating on MC2, so I declared these independent from my work) and one was when I knew that my ALS was bad - the beatnotes weren't in good places, and so the ALS noise was high.

 Folder:  1100342268_POP22goesLow

Working notes:  Lost lock because POP22 went too low.  PRCL and MICH triggered off.  After this, changed PRCL and MICH "down" thresholds to 0.5, from 10.
 

Plots:

Conclusion:  Easy fix.  Changed the down thresholds for MICH and PRCL to be lower, although still low enough that they will trigger off for a true lockloss.  Why though do we lose so much sideband power when the arm transmission goes high?  POP22 dipped below 10 when TRX went above 29.  Does this happen on both sides of the CARM offset?  Quick simulation needed.

------------------------------------------------------------------------

Folder:  1100330534_maybePRCLangular

Working notes:  PRFPMI, reducing CARM offset to arm powers of 7.  CARM on sqrtInv, DARM on DCtrans. PRMI on REFL33 I&Q. Don't know why I lost lock.  Maybe angular stuff in PRC? I think POP spot was moving in yaw as it started to go bad.
Note, later:  regathered data to also get POP angular stuff. Don't think it's POP angular.  Not sure what it is.

Plots:

Conclusion:  I'm not sure what this lockloss was caused by, although it is not something that I can see in the POP QPD (which was my initial suspicion).  It is, like many of the rest of the cases, one where I see significant bounce and roll mode oscillations (error and control signals oscillating at 16 and 24 Hz).  I don't think those are causing the locklosses though.

--------------------------------------------------------------------

Folder:  1100334680_unknown_highArmPowers

Working notes:  PRFPMI, carm_up script finished, sitting at arm powers of 8.  CARM, DARM on DC trans.  PRMI on REFL33.   Don't know why lost lock.

Plots:

[Don't have any? - I'll make some]

Conclusion:  Again, I see 16 and 24 Hz oscillations, but I don't think those are causing the lockloss.

---------------------------------------------------------------------

Folder: 1100331950_unknown

Working notes: PRFPMI, arms about 8.  CARM, DARM on DC trans.  PRMI on REFL33.  Don't know why I lost lock.

Plots:

Conclusion: Don't have an answer.

--------------------------------------------------------

Folder: 1100345981_unknown

Working notes: Lockloss while going to arm powers of 7ish from 6ish.  Not POP angular, POP22 didn't go low.

Plots:

Conclusions:  This one wasn't from POP22 going too low, but again, I don't see anything other than 16 and 24Hz stuff.

I am still staring at / trying to figure out the latter 4 locklosses posted earlier.  But, I have just included the transmission QPD angular output signals to the frames, so we should be able to look at that with locklosses tonight. 

To get the lockloss plots:  in ..../scripts/LSC/LocklossData/ , first run ./FindLockloss.sh <gps time> .  This just pulls the TRX and TRY data, and doesn't save it, so it is pretty quick.  Adjust the gps time until you capture the lockloss in your plot window.  Then run ./LockLossAutoPlot.sh <gps time> to download and save the data.  Since it has become so many channels, it first makes a plot with all of the error and control signals, and then it makes a plot with the power levels and angular signals.  The data folder is just called <gps time>.  I have started also including a text file called notes inside of the folder, with things that I notice in the moment, when I lose lock.  Don't use .txt for the suffix of the notes file, since the ./PlotLockloss.py <folder name> script that will plot data after the fact tries to plot all .txt files.  I have also been appending the folder name with keywords, particularly _notInteresting or _unknown for either obvious lockloss causes or mysterious lockloss cases.

I had a handful of ~10 minute locks tonight. I intended to work on the 1f PRMI transition, but ended just familiarizing myself with the current scheme. 

Before touching anything, I committed the locking scripts to the svn. Unfortunately, the up script as I found it never worked for me tonight. I had to reintroduce the digitial crossover helper in CM_SLOW to get past the ramping up of the overall REFL11 gain. (With this is in place, there is some bad ringing around 200Hz for a time, but it goes away... or unlocks)

I did phase the PD formally known as REFL55 with an 800Hz PRM excitation while in full lock.42 to 102 degrees, ~30dB ratio between the I and Q peaks. However, come to think of it, how much does the CARM loop interfere with this?

The locklosses I had seemed to be due to a large fluctuation in all cavities' power. Maybe this will be helped by better PRC angular control, but we could maybe be helped by normalizing the digital part of the CARM loop by the arm transmissions once lock is acquired. 

Assuming the carrier mode in PRC is stable and the SB is the one moving, can we just use the POP DC QPD to control PRM?

Can we plot the arm power trend for multiple locks to see if it is associated with any thermal phenomenan in the IFO?
They should be able to fit with an exp + DC.

I'm currently more inclined to believe that the arm power trends have more to do with the arm alignments. Here's a 10 minute lock from last night, where the QPD servos were switched on about halfway through. I couldn't get Den's new servos to turn on without blowing the lock, so I reverted to my previous design, but still only actuated on the ETMs, with their oplevs still on. 

The most obvious feature is the reduction in power that seems to correspond to a ~10urad pitch deflection of ITMX when the lock begins. Is this optical spring action?

Also, it looks like the Y arm Yaw loop was badly tuned, and injecting noise. Ooops.

As of Den's QPD tuning, the QPD servos just actuate on the ETM. This next lock effectively had the QPD servos on the entire time, and we can see a similar drift in ITMX, and how ETMX then follows it to keep the QPD spot stationary. (Here, I'm plotting the QPD servo control signals, unlike above, so we can see X pitch servo output drift with the ITMX deflection)

Again, ITMX is moving in pitch by ~10urad when the interferometer starts resonating. If this is an optical spring, why does this just happen to ITMX? If it is digital shenanigans, how does it correlate with the lock, since there is nothing actuating on ITMX but oplevs and OSEM damping? Is light scattering into the ITMX OSEMs?

[Jenne, Megan, Frank]

We rebooted c1iovme, c1susvme1, and c1susvme2 during lunch.  Frank is going to write a thrilling elog about why c1iovme needed some attention.

C1susvme 1&2 have had their overflow numbers on the DAQ_RFMnetwork screen red at 16384 for the past few days.  While we were booting computers anyway, we booted the suses.  Unfortunately, they're still red.  I'm too hungry right now to deal with it....more to follow.

- I found that the cable for the AS55 LO signal had the shielding 90% broken. It was fixed.

- The Mon5 monitor in the control room was not functional for months. I found a small CRT down the east arm.
It is now set as MON5 showing the picture from cameras. Steve, do we need any safety measure for this CRT?

* Relocked IMC. I guess it was stuck somewhere in the autlocker loop. I disabled autolocker and locked it manually. Autolocker has been reenabled and seems to be running just fine.

* The X arm has been having trouble staying locked. There seemed to be some amount of gain peaking. I reduced the gain from 0.007 to 0.006.

*  I disabled the triggered BounceRG filter : FM8 in the Xarm filter module.  We already have a triggered Bounce filter: FM6 that takes care of the noise at bounce/roll frequencies. FM8 was just adding too much gain at 16.5Hz. Once this filter was disabled the X arm lock has been much more stable. 
Also, the Y arm doesn't use FM8 for locking either.

I changed the suspension library block to acquire the SUS_[optic]_LSC_OUT channels at 16k for sensing matrix investigations. We could save the FB some load by disabling these and oplev channels in the mode cleaner optic suspensions. 

I removed nonexistant PDs from c1cal, to try and speed it up from its constantly overflowing state. It's still pretty bad, but under 60us most of the time. 

I also cleaned out the unused IPCs for simulated plant stuff from c1scx and c1sus, to get rid of red blinkeys. 

 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...