[EricQ, Jenne]

We started out this evening by locking the PRMI, on different REFL PDs, just to make sure that we could.  We were able to acquire lock (without having to transition) on either REFL55, REFL33 or REFL165 (I&Q phases for each).  By looking at the transfer function between REFL 55 I and REFL 165 I, I determined that the phase of REFL165 needed to be -135.5, not +44.5, so that the gains were the same sign in all REFL PDs (this is in reference to Koji's elog 9777).  The time to acquisition is much shorter with REFL55 than with the other 2 photodiodes.  I'm not sure right now why this is, but it's pretty consistent, and even more so when the arms are held off resonance.  It is also easy to acquire lock with REFL 55 and then transition to either of the 3f diodes.

PRMI settings:

MICH gain = 2.0.  FMs 4, 5 always on.  FMs 2, 3, 6, 7, 9 triggered with 35 up, 2 down.  Trigger servo on POP110I with 100 up, 10 down.

PRCL gain = -0.020.  FMs 4, 5 always on.  FMs 2, 3, 6, 9 triggered with 35 up, 2 down.  Trigger servo on POP110I with 100 up, 10 down.

PRCL ASC triggered with 50 up, 10 down.  Both pitch and yaw servos had FMs 1, 9 always on, and the FM 6 boost turned on by hand after lock acquired.  Pitch gain = -0.023, yaw gain = -0.027.

If using REFL55, PRCL = I = 1 in the input matrix, and MICH = Q = 1 in the input matrix.

If using REFL33, PRCL = I = 3 in the input matrix, and MICH = Q = 3 in the input matrix.

If using REFL165, PRCL = I = 0.15 in the input matrix, and MICH = Q = 0.1 in the input matrix.

We then moved on to trying to do PRMI + 2 arms, but have been plagued a little bit by locklosses, which may be due to the high seismic from the few large and many small Chilean aftershocks. 

Settings:  With the PRM misaligned, we acquired ALS lock in a CARM/DARM fashion.  The Xarm servo was our "darm" proxy, with +1*ALSX and +1*ALSY.  The Yarm servo was our "carm" proxy, with -1*ALSX and +1*ALSY.  The opposite signs from what you might expect is from our having placed the 2 aux laser frequencies on opposite sides of the PSL.  Our DARM (xarm) was actuating +1 on ETMX and -1 on ETMY.  Our CARM (yarm) was actuating +1 on MC2.  Then we put in a CARM offset of ~60 counts.

We then realigned the PRM, and locked the PRMI (settings as above).  It is much easier to acquire lock with REFL55 than it is with REFL33 or REFL165.  Also, when we are locking the PRMI with REFL55, the AS port is dark, and we see bright sideband resonance at the POP port, as we normally expect.  However, as with last night, when we lock the PRMI with either of the 3f PDs, we see a very bright AS port, and a dark POP port.  Tonight, putting in a MICH offset did not seem to make a significant difference.  As with last night, moving the arms farther away from resonance removed this MICH offset.  I am sure that this is not an artifact of the photodiode dark offsets not being set properly, since I rechecked those carefully. 

We have not come to any interesting conclusions about PRMI+2 arms tonight, since we have started losing the MC every few minutes (maybe seismic-related?). 

[EricQ, Jenne]

Much more success later! 

We've had the arms locked on ALS and held off resonance for more than 2 hours now.  That's good.  We've done several trials of locking the PRMI and trying to reduce the ALS CARM offset.  Once we were able to get quite close, but we never achieved zero CARM offset. 

One big finding is that when the TRX and TRY are about 0.1 in the coupled-cavity case, we start to see real length information in the 1/sqrt(trans) signals.  Q will edit this elog, or reply to it, with the data that he has collected.

I played around with the PRMI + 2 arms situation again this evening.  (I'm not ready to call it "PRFPMI" until we're at least partially using IR signals for CARM and DARM control).

I'm still a little bothered by the fact that we lose almost all light in the PRC when we're reducing the CARM offset.  I'm not sure where the light is going, but it's not circulating in the PRC, since I see the POP camera get very dark.  I can bring back light by changing either the PRCL offset, the MICH offset, or to a lesser extent (or maybe I'm not going far enough in offset) the DARM offset.

Tonight, I was using ALS to push on the ETMs in DARM/CARM mode (I didn't push on MC2 today, since it was being finicky and I had a hard time locking CARM with the MC as the actuator today). 

For the PRMI, I was using REFL 33 I&Q.  PRCL gain was -0.04, MICH gain was +0.8.  REFL 33I varied between +2 and +1.2 (smaller gain necessary as CARM offset was reduced, but it's easier to acquire at large CARM offset with larger gain), and REFL 33Q was +1.0.   PRCL has the usual FM 2,3,6,9 triggered, but MICH only had FM 2 triggered.  The others (particularly FM6) make MICH lose lock.  PRCL ASC was engaged, with the PRM oplev off.

Most of what I was trying tonight was to reduce the CARM offset, and then adjust some other offset (MICH, PRCL or DARM) to maximize POP DC.  It's possible that the POP 110 and 22 diodes are changing their optimal demod phases as the optical plant changes, but POPDC is just DC. 

I wasn't able to get the CARM offset below about 40 counts.  At some point I had both CARM and DARM offsets at 50 counts, and had IR resonance in the Xarm, but no resonance in the Yarm.  I guess this is just part of having a simultaneous CARM and DARM offset.

EDIT:  If I leave the CARM offset at 0, and use a large DARM offset (100 counts), I can acquire PRMI lock, but I run into the same problems as I reduce the DARM offset - the POP power decreases, and I lose lock around 45 counts.

Side note: Earlier today I redid the POP 110 and 22 phases.  POP110 was -61 deg, and is not -101 deg.  POP22 was +164 deg, and is now -105 deg.  I'm not sure why they needed such radical changes.  When sideband locked on REFL33, POP110 had an average DC level of 580 cts, while POP22 had a value of 290 cts.

Koji was right, and I was using much too large of a CARM offset.  Tonight, I set either my CARM or DARM offset to 3 counts, and was able to easily acquire PRMI lock using REFL33. 

For either CARM or DARM offset reduction (the other one was kept at zero offset), I was able to get to about 0.5 counts, but I lose lock when I try to go to 0.4 or 0.3 counts.  One time, I tried "jumping over" the resonance, by going from minus 1 to plus 1 in CARM offset.  Plots of this below.

Locking notes

ALS locked with "Xarm" servo as proxy for DARM, and "Yarm" servo as proxy for DARM.  Pushing only on ETMs today, not the MC. 

MICH / PRCL:

Input matrix:  1's in REFL 33 I&Q, if not using power normalization.  200's in REFL 33 I&Q if power normalization used (either POPDC or POP22).  200 used because that's about the average value of POPDC or POP22 when PRMI sideband-only resonant.

Trigger:  POP22, up 100, down 10.

Power normalization:  1's for both MICH and PRCL in POP22I for one trial.  1's for both MICH and PRCL in POPDC for another trial.  Both seemed to work equally well, although that may change when I'm actually getting IR resonance in the cavity.

FM triggers:  MICH = FM2.  PRCL = FMs 2, 3, 6, 9.  Trigger up = 35, down 10.  PRCL delayed by 0.5 sec, MICH delayed by 5 seconds.

Servo gains:  MICH = 0.4, PRCL = -0.01

Observations:

When I approach the situation of both arms resonating, it pretty consistently looks like the PRM is getting pushed in pitch (and not in yaw).  I don't know why this could be, but it seems like this is the big symptom before lockloss - if the POP spot starts moving (and the PRM suspit signal starts moving), PRMI lock is going to be lost.

I don't know if it's imperfect alignment, imperfect mode matching, or something else, but I see lots of high-order higher order modes on both the POP and AS cameras when the CARM or DARM offset is less than 1 count.  I tried to take a video, but the brightness and contrast aren't set as high as on monitors 3 and 5, so it's hard to see the dim stuff.  Youtube.  At the midpoint of the video, you see a lockloss.

Even though I have overridden the transmission triggers so that I only use the QPDs for the transmission signals, I'm only seeing arm transmission values up to about 50 from each arm.  If we had ideal PRC gain, we expect something like 650 or 700. 

A few plots

All of the raw data for these plots, and several other channels, is in /users/jenne/PRFPMI/PRMI_2arms_8Apr2014/m1_to_p1_carmOffset_1081065069.  As mentioned above, "XARM" is CARM, and "YARM" is DARM.  So, the XARM_IN1 tells us about the CARM offset that I was applying.  The start time is 1081065069, and the plots are all 8 seconds long.

First, the transmitted power and the CARM offset.

The REFL_I error signals and the CARM offset.

The RF signals that we will eventually chose from for CARM and DARM control. Note that I'm not sure about the AS55 phase, so I plot both I and Q.

The PRM suspit and sus yaw angular signals and the CARM offset.  I don't see a huge change in the suspit signal, but it does seem to change character once we approach arm resonances.

I have taken EricQ's simulation results for the CARM plant change vs. CARM offset, and put that together with the CM and CARM digital control loops, to see what we have. 

The overall gains here aren't meaningful yet (I haven't set a UGF), but we can certainly look at the phases, and how the magnitude of the signals change with CARM offset.

First, the analog CM servo.  I use the servo shape from Den's elog from December, but only what he calls "BOOST", the regular servo shape, not any of the super boosts, "BOOST 1-3".   No normalization.

Next, the digital LSC CARM servo (same filters as XARM and YARM).  I have used FM4 and FM5, which are the 2 filters that we use to acquire regular LSC arm lock.  For the actuator, I just use a 1Hz pendulum as if I'm pushing only on the ETMs.

I also used the exact same setups as above, but normalized the transfer functions by a DC photodiode output.  The analog CM loops change the least (around a few kHz) if I use POPDC.  The digital CARM loops change the least (around 100Hz) if I use TRX (or, equivalently, TRX + TRY).

Here are the normalized plots:

Either way, with or without normalization, the digital CARM loop will go unstable between 0-10pm, for both the REFL RF photodiodes.  We need to figure out how to get a realistic transfer function out for the 1/sqrt(TRANS) signals, and see what happens with those.  If those also look unstable, then maybe we should consider a DC signal for the analog CM servo to start, since that could have a wider linear range.

[Jenne, EricQ]

This evening we took things a little bit farther than last night (elog 9791) and transitioned CARM to fully IR signals, no ALS at all for CARM error signals!  We were unsuccessful at doing the same for DARM. 

As we discussed at 40m Meeting this afternoon, the big key was to remove the PRCL ASC from the situation.  I don't know specifically yet if it's QPD saturation, or what, that was causing PRM to be pushed in pitch last night, but removing the ASC loops and reengaging the PRM optical lever worked like a dream. 

Since we can now, using ALS-only, get arbitrarily close to the PRMI+2 arm full resonance point, we decided to transition CARM over to the 1/sqrt(transmission) signals.  We have now done this transition 5 or 10 times.  It feels very procedural and robust now, which is awesome!

To make this transition easier, we made a proto-CESAR for the CARM signals in the LSC.  There's nothing automatic about it, it's just (for now) a different matrix. 

ALS lock conventions:

We have (finally listening to the suggestion that Koji has been making for years now....) set a convention for which side of the PSL the X and Y beatnotes should be, so that we don't have to guess-and-check the gain signs anymore.

For the X beatnote, when you increase the value on the slow slider, the beatnote should increase in frequency.  For the Y beatnote, when you increase the value on the slow slider, the beatnote should decrease in frequency. 

The input matrix (the aux input part) should then have +1 from ALSX->carm, and +1 from ALSY->carm.  It should also have -1 from ALSX->darm and +1 from ALSY->darm. 

The output matrix should be carm -> +1's for both ETMs.  darm should be -1 to ETMX and +1 to ETMY.

With these conventions, both carm and darm should have negative signs for their gains. 

Since we don't have (although should whip up) Watch scripts for the CARM and DARM servo filters, we were using the Xarm filterbank for carm, and the Yarm filterbank for darm again.

Transitioning CARM to 1/sqrt(trans) signals:

As with last night, we were able to easily acquire PRMI lock with a CARM offset of 3 counts.  We then moved down to 2 counts, and saw transmission values of 0.1-0.2.  We set the offsets in the TR_SQRTINV filter banks so that the difference between the outputs was zero, and the mean of the outputs was 2 (the same as the CARM offset we had). 

We looked at the relative gain and sign between the ALS and 1/sqrt() signals, and found that we needed a minus sign, and half the gain.  So, we stepped the 1/sqrt() matrix elements from 0 to -0.5 in steps of 0.1, and at the same time were stepping the ALS matrix elements to CARM from +1 to 0, in steps of 0.2.  This was, excitingly, very easy!

The first time we did this successfully, was a few seconds before 1081143556 gps.

Here is a set of spectra from the first time we locked on the 1/sqrt(trans) signals. 

Failure to transition CARM to RF signals, or reduce CARM offset to zero:

While locked on the 1/sqrt(trans) signals, we looked at several RF signals as options for CARM.  The most promising seems to be REFL55, normalized by (TRX+TRY).  The next most promising looks like REFL11 normalized by POPDC.  Note that these are entirely empirical, and we aren't yet at the resonant point, so these may not be truly the best.  Anyhow, we need to reconfigure the LSC input of the normalized error signals, so that they can go into the CESAR matrices.  This was more than we were prepared to do during the nighttime.  However, it seems like we should be about ready to do the transition, once we have the software in place.  Right now, we either normalize both ALS and the RF signal, or we normalize neither.  We want to be able to apply normalization to only the RF signal. 

Just sitting on the tail of the CARM resonance, there were some random times when we seem to have swung through total resonance, and spoiled our 1/sqrt(trans) signals, which aren't valid at resonance, and so we lost lock.  This implies that auto-transitioning, as CESAR should do, will be helpful. 

Attempt at transitioning DARM to AS55:

Next up, we tried to transition DARM to AS55, after we had CARM on the 1/sqrt signals.  This was unsuccessful.  Part of the reason is that it's unclear what the relative gain should be between the ALS darm signals and AS55, since the transfer function is not flat.  Also, we didn't have much coherence between the ALS signals and AS55Q at low frequencies, below about 100 Hz, which is concerning.  Anyhow, more to investigate and think on here. 

Transitioning CARM to 1/sqrt signals, with a DARM offset:

As a last test, Q put in a DARM offset in the ALS control, rather than a CARM offset, and then was still able to transition CARM control to the 1/sqrt signals.  As we expect, when we're sitting on opposite sides of the arm resonances, the 1/sqrt signals have opposite signs, to make a CARM signal. 

Conclusions / path(s) forward:

We need to redo the LSC RF signal normalization, so that the normalized signals can be inputs to CESAR. 

We need to make sure we set the AS55 phase in a sane way.

We need to think about the non-flat transfer function (the shape was 1/f^n, where n was some number other than 0) between the ALS darm signal and AS55.  The shape was the same for AS55 I&Q, and didn't change when we changed the AS55 phase, so it's not just a phasing problem. 

What DC signals can we use for auto-transitioning between error signals for the big CARM CESAR?

[EricQ, Jenne]

We're still working, but I'm really excited, so here's our news:  We are currently holding the IFO on all IR signals.  No green, no ALS is being used at all!!!!  

PRCL and MICH in REFL33, CARM on 1/sqrt(trans), DARM on AS55 Q.

CARM actuating on MC2, DARM actuating +ETMY, -ETMX. 

CARM offset is 1.9 counts, TRX averages about .1 counts. At this offset, we are able to transition CARM from ALS to DC Transmission signals and DARM from ALS to AS55Q. 

[EricQ, Jenne]

A few more details on our work for the evening, of switching the PRFPMI completely to IR signals (although still with a pretty big CARM offset).

We did the same transition for CARM to 1/sqrt(trans) signals, as last night (elog 9793).  The only difference is that for CARM actuation, we were using a -1*MC in the output matrix, rather than +1's for both ETMs. 

We then had a look at the relative sign and gain between the ALS DARM signals, and AS55Q, using a calibration line in DARM.  Before doing so, we used the DARM line (521.3 Hz, 50 counts) to rotate the AS 55 phase from -60.7 degrees to -97.7 degrees, which gave us about 20dB separation between the I and Q signals.  This informed us that we needed a factor of about 400 less gain for AS55Q than for the ALS darm signal, as well as a minus sign, so I put -400 in the DC normalization place in the LSC for AS55, so that my input matrix would go from ALSY-ALSX (1's) to +1 in AS55Q. 

This transition to AS55 was very easy, and once we did it, we held lock for 5 or 10 minutes, until a large earthquake from Papa New Guinea hit us.  Note however, that we still had a large CARM offset, and our TRX and TRY signals were about 0.1 counts, when we expect several hundred at perfect resonance. 

After that, we relocked, made both CARM and DARM transitions again, and tried to look at a CARM calibration line to see if we see CARM information in any of the REFL RF signals.  We lost lock after a few minutes (so, not related to our calibration line), so we didn't finish, but it looks like REFL55I, normalized by TRX+TRY is the most promising.  Also, REFL55's phase was already very good, while REFL11's phase was not. 

There were some moderate changes to the LSC model that happened, and matching screen changes.  I put in a switch just before the input triggering place of the CARM servo.  This allows us to switch from the "regular" input matrix, and a CESAR signal.  The inputs to the CESAR block are sqrtinv(TRX), sqrtinv(TRY), ALSX, ALSY and the output of the CARM row of the input matrix (so that we can have dynamic normalization of the RF signals).  I have exposed all of these changes in the input matrix screens.

I also modified slightly the ALS watch scripts, to include CARM and DARM servo filter watching, so now we can use the actual CARM and DARM servos.  We should make restore configure scripts for these!

The 2 gps times for when we made the transition from ALS DARM to AS55 DARM were 1081238160 and 1081240217.  We want to go back tomorrow, and extract some nice time series.

Here's a spectrum though, of the difference in noise between DARM on ALS, and DARM on AS55.  The CARM was always on 1/sqrt(Trans) signals during these spectra.  We have an enormous gain in high frequency noise performance once we switch to the RF signal, which is great.

 A few time series from last night's data. 

300 seconds, starting from 1081240100, showing that as we move from ALSY-ALSX to AS55Q, the DARM error signal gets smaller.

The same 300 seconds, showing that the CARM error signal, and the arm transmissions, are not perturbed during this transition.

DARM in and out, for 300 seconds, showing that the control output also gets smaller.

A slightly longer time series, ending at about the same time, but starting a few minutes earlier, showing us (1) adding a 3 count CARM offset, (2) locking the PRMI (3) transitioning CARM to sqrtinv signals, and then (4) transitioning DARM to AS55Q.

CARM and DARM in and outs, for the 500 second time chunk showing all the transitions.  Unfortunately, it looks like CARM_OUT is more noisy when it's on the sqrtinv signals, than it was on the ALS signals.  Part of this may be that we have not yet swapped the resistor in the TRY QPD, to improve the SNR in the same way that we have already done for the TRX QPD.  [EDIT, JCD:  Also, we had hard-triggered the Trans switching, so we were only looking at the QPD sum for the TRX and TRY, and the QPDs only have a few ADC counts at low transmissions, so we had poor SNR for that reason too.]

I'm not sure why, but the WFS were turned off when I came in this morning.  The MC was not staying locked, and even during brief locks, the FSS FAST out was railed at 10. 

Aligning the MC mirrors to maximize the transmission, and then engaging the WFS seems to have made things better.

I have compressed the IFO Configure screen.  All PRMI things (sideband lock and carrier lock) are in the PRMI button, all arm things (both RF and ALS) are in the respective arm buttons.

I have also made a new set of scripts for CARM and DARM lock acquisition with ALS. 

I hope that each button's purpose is clear, but take a second to look at them before you next use the IFO Configure screen.

As payment for borrowing 2 of our seismometers, Zach has made us a new Trillium cable, to go from the granite station to the readout box, which we can put into 1X7, where the PEM ADC is.  To put the T-240 in side the can, and seal it, we need a little jumper cable from the seismometer to the granite, but for now, we can just pass this cable underneath the can.

This afternoon, I was toying around with reducing either the CARM or DARM offsets (so, put in a CARM offset, leave DARM zero, lock the PRMI, then reduce CARM offset to zero.  Or, put in a DARM offset, leaving CARM offset zero, lock the PRMI, then reduce the DARM offset to zero).

When looking at the data, I see that the MICH error signal gets fuzzier when the arms get close to resonance. (Note here that because I forgot to zero the carm offset before finding the resonances, -3 is my zero point for this plot and the next.)

Here is a zoom of the last piece of this time series, but with both TRX and TRY plotted (along with POPDC, CARM_ERR and DARM_ERR), where you can see that I had a momentary power buildup of > 100 transmission counts, which is about 20% of our final expected power.

Here is a different time series, showing a reduction of the DARM offset, and you can see that as the offset approaches zero, the MICH error signal gets noticeably more fuzzy.  Somewhere near the 240 second mark, I lose PRMI lock.

[Jenne, EricQ]

I told Koji that I wanted to play with the common mode servo this evening, and he pointed out that we only get the signals after the digital demod phase angle in the digital system (obviously).  So, if I want to use either REFL11 or REFL55 for my CARM signal, I want to do something in analog-land so that my digital demod phase is close to 0 or 90. 

While we had the PRFPMI locked (with CARM offset of 2 or 3 nm), we set the demod phases of REFL11 and REFL55 to minimize a CARM line in the Q-phase.  This gave us -34 degrees for REFL11, and -75 degrees for REFL55. 

We calculated that about 1 degree of phase shift is about 1/(2 * pi * freq), or about 1.4e-8 seconds of delay for 11MHz.  We took the speed of light in the cables to be about 2/3*c, so 1.4e-8 * 2e8 = 2.9 meters per degree for 11MHz.  Since REFL11 was 34 degrees from 0, we estimate that we need to add about 98 meters of cable to the REFL11 signal path.  The same calculation for 55 MHz, but with a 15 degree shift required, gives 8.8 meters of cable to be added to the REFL55 signal path. 

I connected up some long BNC cables, and inserted them between the heliax breakout board on the LSC rack, and the respective PD inputs of the REFL11 and REFL55 demod boards.  I used (45 meters + 45 meters + a little bit) for REFL11, and used about 9 meters for REFL55. 

When we relocked the PRFPMI, and redid the phasing, we were very close to zero for both REFL11 and REFL55!  REFL11's digital demod phase is now +1 degree, and REFL55's digital demod phase is -5 degrees.

We changed the input of the CM servo board from POY (which Den and Koji had been using in December - see elog 9500) to REFL11 I MON. 

Q locked the FPMI (separate reply elog), and then we tried engaging the CM analog servo.  We were not successful. 

These settings were mostly copied from elog 9500, so they are almost surely not correct. 

CM servo screen:  In1 gain = 31dB, switch on, offset = -2.7V, boost off, super boosts off, option=disable, 79:1.6k switch disabled, polarity minus, option disable, AO gain=8dB, limiter enable.

For the slow path, CM_SLOW -> MC LSC servo had a +1 in the input matrix. 

CM filters in the AUX_ERR screen:  FM1 (unwhite) on, all others off, gain = 2.6. 

MC servo filters:  FM7, FM10 on, all others off (no triggered filter modules).  Gain = 0 initially.

MC servo board AO path disabled initially, G=-32dB initially.

Once Q had the FPMI locked, I tried increasing just the CM analog gain (by enabling the AO path on the MC board, and increasing the gain).  Doing this, I lost lock at -3 dB. 

I then tried again, this time alternating increasing the analog gain, and increasing the MC LSC servo gain.  I got up to 3e-3 for the MC digital gain, and -7 dB for the analog gain before we lost lock again.

We have determined that we should probably try just locking one of the arms with POX or POY, as Den and Koji did, to get a feel for how the system works.

[Jenne, EricQ]

This evening, as part of locking activities, we threw together some handy scripts.

The first one, "Lock_ALS_CARM_and_DARM.py" (no judging of my naming style!!), lives in .../scripts/ALS/ . 

It acquires ALS lock in CARM and DARM mode, so we don't have to do it by hand anymore.

The first thing that it does is ask you to acknowledge that your beatnotes are in place, and they follow our new (newer than the last elog about conventions) beatnote convention.  You are reminded in the terminal window what that convention is:  When the temperature sliders for either arm is INCREASED, the beatnote frequency should INCREASE. 

After you acknowledge that the beatnotes are good, it sets the CARM and DARM servo gains to zero, enables the outputs, sets the input matrix elements, clears the phase tracker histories, and starts ramping up the gains (with +1,+1 for DARM, the darm servo gain is +positive.  with -1*ALSX,+1*ALSY for CARM, the carm servo gain is -negative).  At a gain of 3, it engages the integrators and the resonant gains.  At the final gain of 6, it engages the boosts.

We have used this script ~10 times tonight, and it's been great every time.

The next two scripts are for making the transition from ALS to IR signals.  They both live in ..../scripts/PRFPMI/

"Transition_CARM_ALS_to_TransSqrtInv.py" (again - no judging!) slowly blends the input matrix elements to swap CARM control from the ALS signals to the 1/sqrt(trans) signals.  It takes a few steps, and asks for a keyboard input between steps.  This is because if our 1/sqrt(trans) offsets aren't perfect, we can start to lose transmission power.  To mitigate this, we decrease the offset in the CARM servo filter bank to get more power back.  This script requires an input, which is what you want the final sqrtinv matrix elements to be.  It will fail without this.  For a CARM offset, both of the final sqrtinv matrix elements will have the same sign.

"Transition_DARM_ALS_to_AS55.py" (I can telepathically hear you judging me right now.)  does the same blending, except to swap DARM control from ALS signals to AS55Q.  For the same reason of imperfect offset-setting, it takes several steps, to allow you to adjust the CARM offset if needed. Although, after typing this, I realized that perhaps we should have been tweaking the DARM offset.  Either way, this transition required much less tweaking of offsets than the CARM transition did.  Again, the script requires an input, which is your final desired AS55Q->DARM matrix element value.

*  Both of these scripts should be run at a digital CARM offset of about 2 counts, although with the offset tweaking during the CARM transition, I usually end at about 1.5 counts. 

*  To determine the final gain value for the CARM sqrtinv matrix elements, we have been using a spare filter bank (ex. XARM), and having the input to that be the sum of the sqrtinv channels.  We then put in a CARM line, and look at the transfer function between the temporary filter bank's input, and the CARM_IN1. 

*  To determine the final gain value for the DARM AS55 matrix element, we have been doing a similar thing, looking at the transfer function between DARM_IN1 and AS55Q with a DARM line on.  We have been putting this DC gain into the static PD normalization (4th block from the left on the big LSC screen), although with the new script, it will be easier to just put that value into the matrix element.

[Jenne, EricQ]

Tonight, we transitioned CARM and DARM to IR signals, took loop transfer functions, and determined that we could engage the LSC boosts (FM4 in the CARM and DARM servos, which are the same as the XARM and YARM servos). 

Q is preparing spectra to post, and I will dig out time series.  Look for these tomorrow, if they aren't posted tonight.

For the time series data fetching, I have taken notes on what we were doing when, so that I can actually find the data.

11:09pm:  CARM's LSC boost on for the first time

11:14pm:  DARM transferred to AS55Q

11:21pm:  DARM's LSC boost on for the first time

(lockloss)

11:53pm:  CARM transition

12:02am:  DARM transition done, both LSC boosts on

12:04am:  lockloss after reducing CARM digital offset to 0.4

12:45am: PRMI + 2 arms flashing, with no CARM or DARM offsets (arms still on ALS) because we forgot to put in the CARM offset before restoring PRM alignment.  PRMI may have been actually locked, or we may just have been flashing....need to look through the data to see what our recycling looked like.

(lockloss)

1:05am:  pretty smooth transition completed (both CARM and DARM), but we lost lock while reducing the CARM offset.

1:19am: lockloss - why?? We were just sitting at a CARM offset of about 1.3nm (1.3 counts), holding on IR signals.  We were not touching any IFO things while looking at some plots, and just lost lock.  Want to see if we can understand why.

1:27am:  another nice smooth transition for both CARM and DARM to IR signals, but almost immediate lockloss when reducing the CARM offset.

Using the new ALS lock acquisition scripts (elog 9816) and our transition scripts, getting back to PRFPMI lock is pretty smooth and procedural.

* Align arms using ASS (ifo configure screen, restore xarm and yarm, run both arms' ass scripts).

* Align PRMI, no arms (ifo configure screen, restore prmi sideband)

* Find ALS beatnotes, with arm lasers on opposite sides of the PSL.  For both, when increasing the value of the temperature slider, the beatnote should increase in frequency.  (ifo configure screen, restore CARM and DARM als)

* Run ...../scripts/ALS/Lock_ALS_CARM_and_DARM.py

* Run "Find resonance" scripts from ALS screen for each arm.

* Put in a 3 count offset to CARM loop.

* Restore PRM alignment.  (PRMI should acquire lock immediately, although PRM may need some small alignment tweaking).  Enable PRCL and MICH outputs, PRM and BS actuation outputs.

* Reduce CARM offset to 2 counts. 

* Set offsets of 1/sqrt(TRX) and 1/sqrt(TRY) filter banks in the AUXERR section of the LSC screen.  The outputs of both should equal 2 counts (to match the 2 count offset in the CARM loop). 

* Run .../scripts/PRFPMI/Transition_CARM_ALS_to_TransSqrtInv.py , making sure to reduce the CARM digital offset if needed, to keep the arm transmissions at about 0.1 counts.

* Engage FM4 of the CARM filter bank, which is the LSC boost.

* Run .../scripts/PRFPMI/Transition_DARM_ALS_to_AS55.py , making sure to reduce the CARM (or should be DARM?) digital offset if needed, to keep the arm transmissions at about 0.1 counts.

* Engage FM4 of the DARM filter bank, which is the LSC boost.

Notes for going forward:

When we have small-ish digital CARM offsets, such that both of our arm transmitted powers are about 0.1 or higher, we see clear coherence between our CARM_IN1 (the 1/sqrt(trans) signals) and a normalized REFL11_I (again using a spare filter bank like XARM to get REFL11 normalized by (TRX+TRY) ).  We have not yet tried transitioning the CARM digital error signal to this normalized REFL11.

Even though we see that the IFO is much less noisy (as measured by significantly reduced RIN in TRX and TRY as visible by eye on Dataveiwer), we are still losing lock when we reduce the CARM offset.  I have noted above several times, for when we had locklosses, so that I can see if I see anything elucidating in the time series data.

I looked at 2 of the locklosses from last night, (1:19am and 1:27am), and saw that for both, the DARM loop started to oscillate just before we lost lock.  In the trials tonight, we were more watchful of gain peaking.

Here is the 1:19am lockloss

And here is the 1:27am lockloss

 So you can see what we were doing, and what the effect was, here is a few minutes of data just before the 1:27am lockloss. The times I note below are rough, but should give you an idea of what happened at which time.

0 sec:  Arms are held on resonance with ALS.

10 sec:  CARM offset of 3nm added.

20 sec:  PRM restored, one flash, then PRMI acquires lock.

30 sec:  CARM offset reduced to 2nm, transmitted powers are about 0.1

50 sec:  Transition CARM to 1/sqrt(trans) signals.  Note that we are using the high gain Thorlabs PD here, so the noise is better than last Thursday.

60-110 sec:  CARM offset reduction to about 1nm.

110 sec:  CARM's LSC low frequency boost engaged.

120 sec:  DARM transitioned to AS55Q.

170 sec:  DARM's LSC low frequency boost engaged.

Last night, EricQ and I were concerned that we might need some CARM UGF servoing, so I added a UGF servo block, copied from the aLIGO LSC model, to our LSC model.  The block is inline with the CARM servo, after the output triggering, just before the output matrix.  Q put together some screens, which are accessible from the main LSC screen. 

The model is compiled and running.  We didn't get very far in testing it though before Koji pointed out that it is a slow solution, and not a fast one like we were searching for.  We were hoping to deal with the momentary power buildup, and thus optical gain change, as the arms flash close to resonance.  The UGF servo will not work nearly that fast though.  We may want it for slow UGF servo-ing, but it's not the solution to what Q and I were thinking about yesterday.  Regular ol' dynamic normalization is closer to the right answer for this.

In tonight's activities, Koji and I found that we probably want a CESAR block for DARM as well as CARM, so that we can independently normalize AS55Q. 

To solve the DARM oscillation issue from last night (that I discovered this evening when I finally looked at the time series data), we may want to implement a DARM UGF servo.  For tonight, as we reduced the CARM offset and started seeing gain peaking in the DARM spectra, I hand-reduced the DARM gain.

[Jenne, Koji]

This evening, Koji and I followed the procedure from last night (elog 9817), with the exceptions that as we saw gain peaking in the DARM spectrum, we lowered the DARM servo gain.  We also left the DARM FM4 boost off, and added (TRX+TRY) power normalization to AS55 (although we still had to hand-reduce the gain).    These changes enabled us to reduce the CARM offset much further.  We were able to get the transmitted powers to hold steady at about 1 count while on the IR signals, which is a new record for us.  (We had in the past held the arms with ALS at several counts, but the power fluctuations were huge, and now they are nice and small).

After that, we started looking at whether we could transition CARM over to REFL11I.  We tried a few times, but never made it all the way.

Here are some times for data-foraging tomorrow:

8:27pm, nice transition, CARM offset reduction to 0.6 before lockloss.

9:19pm, turned on power normalization for AS55Q, then reduced CARM offset to 0.5

9:40pm, Lockloss after reducing CARM offset to -0.24, arm transmitted powers around 0.9.

gps 1081748419: First trial trying to transition CARM to REFL11I normalized by (TRX+TRY).

gps 1081749965:  Tried to transition CARM to (REFL11 + REFL33)/(TRX+TRY).  Got about 1/3 of the way through the transition (in terms of matrix element value steps) before lockloss.

11:56pm, Tried to add in REFL11I to CARM error signal (without reducing 1/sqrt(trans) matrix elements).  We increased the REFL11 matrix element until we saw gain peaking, and then tried reducing the 1/sqrt(trans) contribution, and lost lock.  We were only at an offset of 0.3, so we probably weren't close enough to the resonance yet.  We were able to add in REFL11 information, but this was probably not too hard, since there wasn't much actual information in it.

Thoughts:

* It's a little weird that once we are on IR signals, the 0 CARM offset point that we find with ALS is not the true CARM offset point.  Although, this may be because we're just going to an averaged no CARM offset place with ALS, but since ALS is noisy, we won't ever really be holding on the zero offset point.  Anyhow, when we were using the 1/sqrt(trans) signals for CARM, and the CARM digital offset was -0.24, the ALSX and ALSY outputs were both about 0.5 in magnitude.

* We're getting there! 

 I have made the same modification to the Yarm trans PD whitening board as was done for the xend, to increase our SNR.  I put in a 2.1kOhm thin film resistor in the Rgain place.

When I was pulling the board, the ribbon cable that goes to the ADC had its connector break.  I redid the ribbon connector before putting the board back. 

I see signals coming into the digital system for both the high gain and low gain Y transmission PDs, so I think we're back.  I will re-do the normalization after Jamie is finished working on the computers for the day.

Jamie tells me that the 2 big consequences of this are (a) we are not archiving any data that is collected on the ioo machine, and (b) that we will not have access to test points on the IOO or ALS models.

To make sure that this is not a show-stopper for locking, I have locked the arms using ALS.  The signals seem to still be getting from the ALS model to the LSC model, and I'm able to acquire ALS lock, so we should be able to work tonight.  All of the data that I have been looking at lately has been coming off of the LSC machine, so we should even be okay in terms of look-back for lockloss studies, etc.

Some time series data from Wednesday night. 

Here is the first time we've gotten the arm transmissions to about 1 count, while holding CARM and DARM on IR signals, so the transmission, as well as POPDC, were relatively quiet.

As we were attempting to transition CARM to REFL11I, at least 2 of the times, we were hitting a CARM oscillation:

Last night, as well as tonight, the ALS seems not quite as robust as it was earlier in the week.

I have just taken noise spectra, and ALS is definitely more noisy than usual. 

These plots are with the arms held in CARM and DARM mode, with servo gains of 8. I was seeing the beginnings of gain peaking at a gain of 10, so I turned it back to 8.  Our ALS in-loop RMS is usually something like a few hundred Hz, but I'm seeing over 1kHz, so I have a factor of 4 or 5 too much noise.  Why?!?!?

This evening, I was not able to successfully transition CARM from ALS to 1/sqrt(trans) signals.  The TRY time series looked odd, so I took a spectra, and we have huge 60Hz noise in TRY. 

I found a lock stretch from around 6:30pm that did not show the 60Hz noise, and then there was a lock stretch around 8pm that did have the noise.  So, something happened at the Yend between 6:30 and 8pm tonight.

Asking around, this was the time frame in which Manasa was down at the Yend to realign the green beam, and to check cabling for the PZT_OUT and ERR_MON signals to the ADC.

Looking at the spectra, Rana noted that we have even as well as odd harmonics of the 60Hz line, which is unusual.

To try to diagnose the problem, Rana and I tried to make sure no cables' connectors were touching, and that no equipment was plugged in that shouldn't be.  We noticed that none of: the shutter, the Thorlabs TRY PD, or the QPD TRY are isolated from the table.  To see if perhaps the shutter was the problem, I turned off the power to the Yend green shutter, and unplugged the cable.  The cable is laying on the table, with the connector sitting on a piece of plastic to isolate it.  Removing the shutter from the system did not change anything. 

We don't see the 60Hz noise in the Xarm, so it's not on the laser light itself.  Also, we don't see the 60Hz lines in the Yarm feedback signal, so we're not putting the lines onto the mirror, and thus onto the Yarm's light. 

Manasa, can you please take a look, and see if you can figure out what is going on?  We need TRY so that we can transition to 1/sqrt(trans) signals for CARM.  Thanks!!

[Jenne, Q]

The frame builder (or something) is unhappy again.  I know that we've seen this before, but I can't find the elog entry that relates to this particular problem.

Every few minutes, the fb status lights on the CDS_STATUS screen go white, and then come back green.  It's annoying when it happens every hour or so (which is unfortunately typical), but it's pretty debilitating when it stops dataviewer and dtt every few minutes.  Just from the way the lights change, it looks like perhaps the daqd process is restarting itself periodically? 

 I re-plugged in the Yend shutter, and turned it on.

I tried some locking anyway tonight, even though we don't have TRY. 

The biggest conclusion is that I miss the auto-resonance-finding.  I've been roughly scanning the Y-ALS offset to find the POY zero crossing when I see the resonance on the test mass face cameras. 

The next-biggest conclusion, is that I can hold the PRFPMI close to resonance, using ALS for CARM and DARM.  I was trying to transition DARM to AS55, but I couldn't get the last bit of the way.  That is, I couldn't turn off the ALS control.  So, I think that AS55 wasn't actually holding DARM, until maybe the last moment or so.

Anyhow, here are some time series.  My average TRX value is around 40 counts, and POPDC is maybe 250 counts (just PRMI, POPDC is about 75 counts).  Obviously this is noisy as hell, but I'm not using any IR signals for the arms.  Near the end of this first time series, I am trying to switch to AS55 for DARM.

Zooming in, my real lockloss is due to PRCL oscillating at ~350 Hz:

However, I also saw ~25Hz peaks in CARM and DARM on the spectra starting to show up, and I see a ~25 Hz oscillation in DARM a few moments after the PRCL lockloss.  (Plot #2 is a zoom of the ~1.1 second mark on Plot #3.)

The locking parameters:

CARM:

Input:  Using the new CESAR matrix, -1*ALSX, +1*ALSY.  Beatnotes both move up in freq if temp sliders move up.

Servo: gain = 6, FMs 1, 2, 3, 5, 6, 7, 9 on.  Offset = 0 counts. 

Output = -1*MC2

DARM:

Input:  +1*ALSX, +1*ALSY

Servo:  gain = 4.  FMs 1, 2, 3, 5, 6, 7, 9 on.  Offset = 0 counts.

Output = -1*ETMX, +1*ETMY

PRCL:

Input:  +1*REFL33_I, Norm = +0.01*POPDC, sqrt engaged.

Servo:  acquisition easier with -0.04 or -0.06, less gain peaking at -0.02   FMs 4, 5 on; 2, 3, 6, 9 triggered with 0.5 sec delay.  Servo trigger = POPDC, up 100, down 10.  FM trigger = POPDC, up 300, down 20.

Output = +1*PRM

PRCL ASC off, PRM oplev on.

MICH:

Input:  +1*REFL33_Q, Norm = +0.01*POPDC, sqrt engaged.

Servo:  gain = 2, FMs 4, 5 on; 2, 3 triggered with 0.2 sec delay.  Servo trigger = POPDC, up 100, down 10.  FM trigger = POPDC, up 300, down 20.

Output = +0.5*BS, -0.2625*PRM

PDs:

REFL33 analog gain set to 30 dB for both I&Q.

AS55 set to 0 dB for both I&Q.  AS55 had DC normalization of 80 counts (which was the measured number for PRFPMI when TRX was about 0.1 count this evening)

Here is 1 second of data, with REFLDC, POPDC and TRX:

Here is a zoom of the first 3 big peaks in TRX.  The weird jumps at the beginning of each TRX peak are due to the triggered switching between the Thorlabs trans PD and the QPD trans PD.  Clearly we need to work on their relative normalizations.  There are also little jumps after each peak as the triggering sends the signal back to the Thorlabs PD.

Here is a zoom of the single big peak about halfway through the 1 second of data:

And here is a zoom of the tail of that peak.  It looks to me like we want to start thinking about using REFL DC when our transmitted powers are around 2 counts.  We could do as soon as 1 count, but 2 is a little farther into the dip.

 I was unhappy with the discontinuities between the Thorlabs and QPD versions of our transmitted light powers.  I realized that in the olden days, we just used the Thorlabs PD, and we set the no-light offset in the LSC version of the TR[x,y] filter banks.  However, now that we have brought the QPDs back, we are setting the dark offsets in the end suspension models, so that the signal chosen by the trigger already has its offset taken care of before we send it to the LSC model. 

Anyhow, having the offsets script try to put a value in the C1:LSC-TR[x,y]_OFFSET was giving us an extra offset and then when we did the normalizations, the numbers came out all wrong.  So.  I have removed the C1:LSC-TR[x,y] filter banks from the offset list, since they were made redundant. 

I have redone the normalizations for both arms (after running the ASS scripts).  I checked by watching the _OUT16 versions of the Thorlabs and QPD diodes before the triggering happens, and as I put offsets into the LSC servos to change the transmitted power, the diodes both change in the same way.  So, we'll have to see if this holds true for more than just values 0-1 the next time we lock, but hopefully it won't need changing for a while.

[Jenne, Koji]

The IFO is being uncooperative tonight, and I have an early morning meeting, so I'm calling it a night. 

Koji's filter module changes have been propagated from the Xarm to the Yarm, to CARM and to DARM.  (Actually, Q overwrote the changes to Xarm on Sunday accidentally, so first he reverted those for us, and then we propagated the changes). 

Today, with careful measuring, we find that for X and Y arms individually locked with the ALS, we want the gains to be +17 for the Yarm, and -17 for the Xarm (with the beatnote up-is-up convention).  This puts the UGFs at 150 Hz. 

We then switched over to CARM and DARM locking.  We guessed that the gains should be a factor of 2 lower since we're pushing on both ETMs for DARM, and the MC2 actuator is roughly the same strength as the sum of the ETMs.  In the end, after measuring the CARM and DARM loops, we find that the gains should be +7.5 for CARM, and +8.0 for DARM to set the UGFs at 150 Hz.  The servo is a little bit delicate, so having too low of gain is not okay. 

For some reason, we seem to be utilizing more actuator range with the new setup, so the limiters in the filter banks have been set to 11,000 (previously were 8,000), and the ALS watch script (ALSdown.py) threshold has been increased to 10,000 (previously 7,000). 

When finding the IR resonances with the new scheme, we are having trouble holding lock throughout the scan.  I have set the tramp for the coarse part of the scan to be 0.05 seconds (previously 0.01 seconds), which is an increase of a factor of 5 in the ramp time.  This helps, but may still not be enough, since we don't always hold lock until both IR resonances are found.

Probably the most annoying thing from tonight is the fact that ETMY keeps drifting off, particularly in yaw, when locked.  I don't have an explanation of why this is happening, but you can watch it happen sometimes, and the lock will be lost shortly thereafter.  Definitely when we lose lock and the ETM gets kicked, it is far enough away in yaw alignment that I have to completely redo the Yarm alignment.  This happens whether or not the ETMY oplevs are on.

To summarize, 3 scripts have been modified:

(1) ALSdown - threshold increased  (Modification from last week - turns off the slow temp servos for the end lasers, clears histories)

(2) ALSfindIRresonance - increase ramp time

(3) Lock_ALS_CARMandDARM - final gain values set to 7.5 for CARM and 8 for DARM, no filters come on until gains all the way up, turns on new set of Koji filters. (Modification from last week - turns on the slow temperature servos for the end lasers)

[Rana, EricQ, Jenne]

We locked the Yarm by using the CM board this evening. 

POY is going from its demod board to the CM board, and then the slow output of that is going to the POY channel of the whitening, and then on to the ADC.  So, with no AO path engaged, this is basically like regular Yarm locking. 

First of all, Den and Koji back in December were concerned that they were seeing some EOM saturation in the fast path, but we don't think that's an issue.  We looked at the FSS PCDRIVE while we increased the AO gain.  In fact, it looks like the offset is coming from the MC board's IN2 slider.  Even with no input on that slider, increasing its value puts an offset into the MC.  To fix this, I am going to put a 6.8uF cap in series with R30 in the MC board, which is part of the crossbar switch where the IN1 and IN2 get summed.  This should AC-couple the output of the IN2 slider before the summing node.

We aren't sure which sign to use for the AO path of the CM board...Eric is doing some modelling to see if he can figure it out.  He's going to try to see which spectra (below) his model matches.

For the spectra, we have a reference trace with no AO path, a trace with "Plus" polarity on the CM board which started to show a peak when the value of the MC IN2 slider was at about -6 dB, and a trace with "Minus" polarity, which started to show a peak when the value of the MC IN2 slider was at about -16 dB. 

We took loop measurements for each of the Plus and Minus cases. Something that seems a little weird is how shallow of a slope we have in both cases near our UGF.

 MC board is out, so don't be surprised that the MC isn't locking.

 MC board is back in place, MC is locked.

If I disable all of the AO path bits of the CM servo (disable switch, and also gain slider to -32dB), and then move the MC IN2 slider around, the MC does not get an offset anymore (as seen by reduced transmission and increased reflected power), so I think the DC coupling is working.  I do lose lock of the MC if the slider goes above ~22 dB in this situation, but I don't see any effect before then, whereas we were able to see a steady increase in the reflected power as we moved the slider around last night.  So, it seems like things are good with the DC coupling of the IN2 slider.

Here are some photos from before I modified the board (front, back, and zoom of the area I was working in):

And here is my modification, putting the 6.8uF cap in series with (a new) 2k thin film resistor, in the spot for R30:

The board is https://dcc.ligo.org/DocDB/0004/D040180/001/D040180-C.pdf

[Edit, 20140721: It looks like this is actually D040180 rev B, not rev C. —Evan]

I touched up the alignment of the Ygreen on the PSL table.

I have taken out of loop spectra for both arms, by looking at POX/POY while the arms were controlled with ALS.

To do this, I put the POY11 Q signal directly to the whitening board, which meant that I removed the cable coming from the common mode board.  (Now that we're doing CM stuff again, I have put it back, so POY is still in the slightly weird "going through the CM slow path" situation). 

For the locking, both arms had FMs 1, 2, 3, 5, 6 engaged.  Yarm had a gain of +17, Xarm had a gain of -17. 

Y beatnote was 98.6MHz with a peak height of -22 dBm.  X beatnote was 45.0MHz with a peak height -11 dBm.

I drove ITMY at 503.1 Hz with 100 counts.  I drove ITMX at 521.1 Hz with 25 cnt. 

Koji helped me match up the peak heights between the FINE_PHASE_OUT_HZ calibrated signals and the PDH signals. 

The out of loop noise is definitely below 1kHz rms now, which is better than it was!  Hooray!

 Today I finally implemented a feature in the whitening triggering that I should have a long time ago:  an override button.

Now, on each RFPD's phase rotation screen, there is a button to either allow triggering for that PD (both quads) or to be in manual mode.  

If you are allowing triggering, they will behave as they have for the last ~year.....if any degree of freedom is using either quadrant of that PD, and that degree of freedom is triggered, then engage analog whitening and digital de-whitening.

If you chose manual mode, then you can engage or disengage the whitening as you please.  (The analog whitening and digital de-whitening are still tied together).

[Rana, Jenne]

This evening, we were able to lock the Yarm through the common mode board, using AS55 as our error signal.  Our final UGF is about 5kHz, with 60 degrees of phase margin.

Before dinner, Rana switched the input of the CM board's REFL1 input to be AS55I rather than POY11Q, in the hopes that it would have better SNR.  Demod phase of AS55 was measured to be 14 deg for optimum Yarm->I-phase and has been set to 0 degrees.  Since the POY demod phase had been 90 degrees, which puts in a minus sign, and now we're using 0 deg which doesn't have a minus sign, we're using the plus (instead of minus) polarity of the CM board.

We re-allocated gains to help lower the overall noise by moving 15dB from the CM board AO gain slider to the MC IN2 gain slider, so we weren't attenuating signals.

We see, by taking loop measurements even before engaging the AO path (so, just the digital loop portion) that we've gained something like 20 degrees of phase margin!  We think that about 5 degrees is some LSC loop re-shaping of the boost filter.  We weren't sure why there was a hump of extra gain in the boost filter, so we've created a new (FM8) boost filter which is just a usual resonant gain:  resgain(16.5,7,50)

The cm_down and cm_step scripts in ..../scripts/PRFPMI/ were modified to reflect the settings below, and their current states are included in the tarball attached.

Also, throughout our endeavors this evening, the PC fast rms has stayed nice and low, so we don't suspect any EOM saturation issues.

Now our Yarm digital servo has a gain of -0.0013, with FMs 2, 4, 5, 7, 8 engaged (2, 7, 8 are triggered). 

Our final CM board settings are: 

REFL1 gain = +22dB

offset = -2.898V

Boost = enable

Super Boost = 0

option = disable

1.6k:79 coupled cavity compensator = enabled

polarity = plus

option = disable

AO gain = 15dB

limiter = enable

MC board:  IN1 gain = 18dB, IN2 gain = 0dB.

Here is a measurement of the Common Mode MCL/AO crossover.  The purple/orange trace here is after/before the boost was engaged.

We also have a measurement of the total loop gain, measured with the SR785.  The parameter file, as well as the python script to get the data, are in the tarball attached.  Noteably, the excitation amplitude was 500mV, whereas Q and Rana yesterday were using 5 or 8 mV.  We aren't sure why the big change was necessary to get a reasonable measurement out.  This measurement is with the boost enabled.

Finally, here is a measurement of the MC error point spectra, with the CM boost on, after we reallocated the gains.  There's a giant bump at several tens of kHz.  We need to actually go out with the fast analyzer and tune up the MC loop.

To get ready for the PRFPMI CM trials tonight, I put AS55's cables back to their nominal state, and now have REFL11 I going to IN1 of the CM board.  The OUT1 of the CM board goes to the REFL11I whitening channel.

REFLDC was not disconnected in the last few days, so it is still set up for IN2 of the CM board, with an external offset adjust.

I was thinking about POP today, and wanted to know if there was something to be done to allow us to use the PRCL ASC for at least a little bit farther into arm power buildup.

Anyhow, I checked, and while PRMI is locked on sidebands (ETMs misaligned), POP DC is about 80 counts, and the power measured by the Ophir power meter is 24 microWatts. 

We were on the 3rd gain setting for the QPD's power amplifier.  I turned it down to the "2" option.  (When at 4, the front panel light indicates saturation).

It's not clear to me what the gain settings mean exactly.  I think that "1" means 4*10^3 V/A, and "6" means 4*10^6 V/A (On-Trak OT301 info site), but I don't know for sure how the gain changes for the settings 2-5.  Anyhow, I have changed the digital gain for the ASC to be -0.063 from -0.023 for both pitch and yaw.

As part of checking the common mode board before we get too carried away with using it, I looked at the time series of the AO servo output when I turned on various boosts, or changed gain values.  As it turns out, basically anything that I did caused glitches.  Oooops.

I plugged a function generator to the IN1 port of the CM board, with a freq of 400Hz, and a voltage of 10mVpp (which is the smallest value that it would allow).  I plugged the BNC version of the servo output into a 300MHz 'scope.

First I looked at "boost" and "super boost", and then I looked at various steps of the AO gain slider.  For all of the button presses that gave me glitches, I saved .png's of the 'scope screen (on a floppy, so I'll have to fetch the data tomorrow...).

Both enabling, and disabling the "Boost" button gave me glitches.

For "Super Boost", I saw glitches for all of the steps, 0->1, 1->2, 2->3. 

For the AO path, I only started at 0dB, and only captured screenshots of glitches when I increased the gain, since presumably that's when we'll care the most during acquisition.  I found that going down in gain caused glitches at every step!  For increasing the gain, steps from an odd number of dBs to an even number consistently caused glitches.  Steps from an even number to an odd number occasionally caused glitches, but they weren't very common.  For the steps that did cause glitches, some were worse than others (7dB to 8dB, 15 dB to 16 dB, and 23 dB to 24 dB seemed the worst.)

After my work, I put all of the cables back, so that we should be ready to utilize the CM board for locking this evening.

For posterity, here are the notes that I took while I was working - I'll make them more coherent when I fold them in with my images tomorrow.  The "first .png, next, etc." are because the 'scope numbers them in order as a default.

1st png = boost enable, then disable
2nd png = super boost, start at 0, then 1, then 2, then 3
3rd png = AO gain from 1 to 0
4th is AO gain from 0 to 1 (happens less often than 1->0, which is every time I get a glitch)
Next is AO gain 1->2, got 2 glitches!
3->2 glitch often, 2->3 much less often
next is 2->3
next png is 3->4, 2 glitches with weird dip
4->5, rare
next png is 5->6
6->7 is rare
next png is 7->8, which is nasty!!
8->9 is rare
png 9->10
10->11 is rare
png 11-> 12, 3 glitches
 12->13 rare
png 13->14, 2 glitches
14->15, rare
png 15->16, kind of nasty
png 17->18, 2 glitches
png 19->20, 3 glitches
png 21->22, 2 glitches
png 23->24, kind of nasty
png 25->26, 2 glitches
png 27->28, 3 glitches, at least
png 29->30, 2 glitches

Somehow, the images got put into a whole new entry, even though I thought I was editing this one.  Anyhow, please see elog 9938.

Note:  I thought I was editing elog 9935, but somehow this became a whole new entry.  Either way, all the info is in here.

As part of checking the common mode board before we get too carried away with using it, I looked at the time series of the AO servo output when I turned on various boosts, or changed gain values.  As it turns out, basically anything that I did caused glitches.  Oooops.

I plugged a function generator to the IN1 port of the CM board, with a freq of 400Hz, and a voltage of 10mVpp (which is the smallest value that it would allow).  I plugged the BNC version of the servo output into a 300MHz 'scope.

First I looked at "boost" and "super boost", and then I looked at various steps of the AO gain slider.  For all of the button presses that gave me glitches, I saved .png's of the 'scope screen (on a floppy, so I'll have to fetch the data tomorrow...).

Both enabling, and disabling the "Boost" button gave me glitches.

For "Super Boost", I saw glitches for all of the steps, 0->1, 1->2, 2->3. 

For the AO path, I only started at 0dB, and only captured screenshots of glitches when I increased the gain, since presumably that's when we'll care the most during acquisition.  I found that going down in gain caused glitches at every step!  For increasing the gain, steps from an odd number of dBs to an even number consistently caused glitches.  Steps from an even number to an odd number occasionally caused glitches, but they weren't very common.  For the steps that did cause glitches, some were worse than others (7dB to 8dB, 15 dB to 16 dB, and 23 dB to 24 dB seemed the worst.)

After my work, I put all of the cables back, so that we should be ready to utilize the CM board for locking this evening.

For posterity, here are the notes that I took while I was working - I'll make them more coherent when I fold them in with my images tomorrow.  The "first .png, next, etc." are because the 'scope numbers them in order as a default.

1st png = boost enable, then disable
2nd png = super boost, start at 0, then 1, then 2, then 3
3rd png = AO gain from 1 to 0
4th is AO gain from 0 to 1 (happens less often than 1->0, which is every time I get a glitch)
Next is AO gain 1->2, got 2 glitches!
3->2 glitch often, 2->3 much less often
next is 2->3
next png is 3->4, 2 glitches with weird dip
4->5, rare
next png is 5->6
6->7 is rare
next png is 7->8, which is nasty!!
8->9 is rare
png 9->10
10->11 is rare
png 11-> 12, 3 glitches
 12->13 rare
png 13->14, 2 glitches
14->15, rare
png 15->16, kind of nasty
png 17->18, 2 glitches
png 19->20, 3 glitches
png 21->22, 2 glitches
png 23->24, kind of nasty
png 25->26, 2 glitches
png 27->28, 3 glitches, at least
png 29->30, 2 glitches

The screenshot of the Boost enable / disable I'll have to re-take.  Apparently I instead caught a screenshot of the list of files on the floppy...ooops.

This is a shot of enabling the Super Boosts.  At the beginning, it's at "0", so no superboosts (also, regular boost was off).  Then, I switch to "1", and the trace gets a little fuzzy.  Then I switch to "2", and it gets very fuzzy.  Then I switch to "3", and a lot of the fuzz goes away.  There's a glitch at each transition.

The following screenshots are all of various steps of the AO gain slider.  For all of these, both the "boost" and "super boosts" were off.  Each screenshot is a single gain step, even if there are several glitches captured.

First, 0dB to 1dB:

Next, 1dB to 2dB:

2dB to 3dB:

3dB to 4dB:

While increasing the gain, I didn't find any more steps from an even to an odd number where I got a glitch.  They would glitch when I undid that step (decreased the gain), but over ~5 trials for each increase, I didn't ever catch a glitch.  The odd to even steps still had glitches while increasing the gain though.

5dB to 6dB:

7dB to 8dB:

9dB to 10dB:

11dB to 12dB:

13dB to 14dB:

15dB to 16dB:

17dB to 18dB:

19dB to 20dB:

21dB to 22dB:

23dB to 24dB:

25dB to 26dB:

27dB to 28dB:

29dB to 30dB:

We need to go back and have a look at all of our optical lever control filters, and make sure they make sense. 

In particular, we should have a look at the ITMs, since they have a huge amount of motion around 10Hz. 

Notes:  ETMX shouldn't have that lower notch.  The bounce mode Qs should be lowered.

[Jenne, Rana, EricQ]

We tried a few times to engage the AO path while holding CARM on sqrtTrans and DARM on ALS, but failed every time.  Since we cannot stably hold lock at arm powers of 1, even though we were able to do so early last week, we think that we have a problem (obviously).  One noticeable thing is that while held with ALS, the Xarm transmission fluctuates almost full power.

As we were seeing late last week, the Xarm IR transmission while held with ALS was fluctuating wildly, whether we were locked on individual arms or on CARM/DARM. 

Tonight we took some out of loop spectra, with different HEPA settings, to see how that affected things.  It looks like HEPA at the nominal ~20% is okay, but anything higher than that starts to affect the Xarm beatnote sensing, while it mostly leaves the Yarm beatnote sensing okay.  Perhaps this is something that isn't tightened enough in the Xarm path, or something on a skinny floppy mount that needs to be more secure.

I am still a little confused though, why we don't see large power fluctuations in *both* arms while using ALS to control CARM/DARM.  Why are we not seeing this Xarm noise being fed back into the Yarm, through either the ETM via DARM, or common stuff via CARM actuating on MC2.

Note that the change at high frequency is because I switched from using non-DQ channels to DQ channels, so that's not anything to pay attention to.  The noise reduction we see is below about 20Hz.

Rana pointed out that our POPDC level was very small.  We don't have screens for them, but the DC PDs have the same analog whitening as the RF PD signals do.  I changed C1:LSC-POPDC_WhiteGain.VAL from 0 to 11.  Now our POPDC while locked on sidebands is about 8,000 counts.

We also swapped the cables between the SR785 and the CM board around.  Now channel 2 of the 785 goes to TP2A, channel 1 goes to TP2B, and the source goes to EXCB.  This is so that we can break the AO loop with the disable switch just after the slow/fast split, and look at the transfer function before we close the loop. 

I took loop measurements of ETMX pit and yaw, and set the upper UGF to be ~6Hz for both.  This required a pitch gain of 25, and a yaw gain of 16.

The spectra look similar to what they were before Steve did the swap.

I believe that the Xend aux laser was turned off earlier today, for Steve's work swapping out the oplev.  When I went down there, the red "off" LED was illuminated, and the LCD screen was showing something.  I pushed the green "on" button, and I immediately got green.

Also, I saw that the 24Hz roll mode was very rung up on ETMX.  I looked at the FM5 "bounce roll" filter, and it had some old values, 12Hz and 18Hz for the resonant gains.  All other optics have the proper 16Hz and 24Hz frequencies.  I copied the BS oplev bounce roll filter over to ETMX pit and yaw (both were wrong), and loaded them in.  The mode is starting to ring down.

Tonight was mostly cleaning up some scripts, including the re-writing the restore and align scripts for the optics. 

The new script is in the same folder as the old one (/opt/rtcds/caltech/c1/medm/MISC/ifoalign/NewAlignSoft.py), but is not yet called from the align screen.  However, I'm using it in the carm up and down scripts, and it works nicely for the PRM.  I need to check that the offset value is okay for all the other optics (i.e. are they getting misaligned enough?), but then I'll have the new script called from the screen.  The new script, per Rana's suggestion, does not touch the bias sliders.  Rather, it puts an offset in the pitch filter banks in the coil driver output matrix-of-filter-banks.  Then the misalign routine turns the offset on, and the restore routine turns the offset off.  This way we have a nice ramp time, but don't have to do the weird calculation of number of steps to take as is done in the current script.  Also, the "save" functionality will be obsolete, since we're never touching the bias sliders except for actual alignment needs.

I'm not sure what changed, other than the HEPA being on lower, but the Xarm ALS was much better behaved tonight.  I was able to hang out around arm powers of ~1 for as long as I wanted. 

I didn't try to hand over to digital REFLDC, but I was trying a few times to engage the AO path.  With the CM board set to Plus, I hear hooting when MC IN2 is about 4dB.  With the CM board set to Minus, I didn't hear hooting, but I lost lock when I went from 13dB to 14dB. 

Also, I put the cables for the SR785 back to the "A" set of test points and excitation, so that I could take a closed loop transfer function.  However, I don't know where the latest working scripts to make a remote measurement are, so maybe we can take some loop measurements tomorrow.

The carm_cm_up script is good (for tonight) up to the prompt "Press enter to indicate that it is okay to turn on MC2 LSC FM8".  There are "read"s every step of the way, so it goes nice and slow, but it'll do everything for you except any last tweaks of the PRM alignment after the PRMI is locked.

It's starting to get a little crowded, but I modified the IFO_ALIGN screen to have new buttons to show the aligned / misaligned state of each optic.  Koji made a good point, and I left the old restore script functional so that if the slider is moved significantly, we can always go back gently to the burt restored value.  I have removed the old misalign function though, since we shouldn't ever be using that again.

I tried many times this evening to engage the AO path, with limited success.

Q's new scripts worked really well, and so I have some transfer functions!  To take these measurements, in ...../scripts/general/netgpib, I am running ./TFSR785 TFSR785_CARMloop_May2014.yml, where the file name is the name of my parameter file.  The data, and the saved pdfs, are in /users/jenne/PRFPMI/CARM_loop_measurements/2014May14/ .  For these measurements, the SR785 is hooked up to the "A" set of excitation and test points on the CM board.

All of these traces were taken while the IFO was PRFPMI, with PRCL and MICH on REFL33, DARM on ALS diff, and CARM on InvSqrtTrans.  carm_cm_up.sh is up to date, through the echo "REFL_I should now be zero" (~line 111 in the script).  All you need to do is set the beatnotes, and then run the script.  Follow instructions in the prompt (such as "press enter to confirm PRMI is locked"). 

Here are my notes for the various times:

23:01:44 - MC IN2 = 0dB, CARM gain = 5.0

23:13:45 - MC IN2 = 10dB, CARM gain = 5

23:26:10 - MC IN2 = 6dB, CARM gain = 10 (after Q suggested increasing overall gain, rather than just AO path)

00:13:07 - MC IN2 = 6dB?, CARM = 6ish?  don't remember exactly.

00:45:00ish, Realigned IFO using IR with arms.

01:03:17 - MC In2 = 0dB, CARM gain = 5

01:07:42 - MC IN2 = 8dB, CARM gain = 6.295  (AO went up to 6dB, then +1dB steps to both simultaneously using  ezcastep C1:LSC-CARM_GAIN 1dB C1:IOO-MC_AO_GAIN 1)

01:08:57 - MC IN2 = 10dB, CARM gain = 7.92447

01:10:08 - MC IN2 = 12dB, CARM gain = 9.97631

lockloss when trying to add 1 more dB to both.

01:41:36 - MC IN2 = 12dB, CARM gain = 9.97

lockloss when just MC IN2 up by 1dB, left CARM gain alone.

Other notes:

The 60Hz noise in TRY is back.  Since I thought I remembered someone suggesting that it was leakage light from the exit sign, Koji went in and wrapped the end table in foil, however the lines are still present.

 In addition to a transparent legend, we need the corresponding CM crossover measurements from DTT to compare with the Q-Mist-Loop model results. The xover tells us when the AO gain is high enough so that they can be ramped up together.

Also, I wonder how much power fluctuation we get from the large ALS DIFF noise and if that demands we get the TR signals normalized by POPDC.

[Rana, Jenne]

We have looked at a few things that do and don't affect the out of loop noise of the ALS X beat, and found that cavity alignment and beatnote RF frequency had the strongest effects.

Possible causes of noise:

1.  Air currents from A/C or flowbench.  No effect. 

        * When table lid is on, turning on and off the flow bench air did not qualitatively change the out of loop beatnote time series signal.

2.  Scattered light from other beams hitting green PDH PD.  No effect.

        * There are a few spots of green light that are hitting the case of the PDH photodiode, but when I put an iris in place to block those spots, there was no change in the beatnote spectra.  This makes sense to me since none of those spots were close to hitting the diode itself. 

        * Rana did notice that the beam was not well centered on the PD, so he steered the beam onto the center of the diode.  Also, the PD is now tilted a little bit so that the reflection from the diode doesn't go back into the beam path.  Neither of these things had an effect that we noticed in the beatnote noise.

3.  Oplev laser light getting to PDH PD.  Not tested.

       * We don't see any red light over by the PDH PD, so we did not try turning off the oplev's laser to see if that had an effect, but we suspect that it is not the cause of our noise.

4.  Clipping of main IR / green beam on Xend table.  Not tested.

      * We should still go have a look at this, but we no longer think that this is the main cause of the elevated noise.

5.  Scattered light all over Xend table.  Not tested.

     * We should still work on dumping extraneous beams on the table, but we do not think that this is the main cause of the elevated noise.

     * Rana took some photos so that we can see how truely bad the situation is.

6.  Amplitude modulation dip in NPRO.  Not tested.

    * It is probably still a good idea to check this, in case the dip in the amplitude modulation has changed over the year or two since it was last measured, but we also don't think that this is the main problem.

7.  Check PDH servo.  Not done.

     * I think this is still on Q's long-term todo list, but we should give the PDH servos a once-over.

8.  Arm cavity longitudinal motion.  No effect.

     * While the Xarm was locked with IR, we put a line at 1.7 Hz with 325 counts into the ITMX position.  To keep lock, the ETM had to move as well.  When we turned on this line (and increased its amplitude up to the final value of 325 cts), we did not see any qualitative change in the beatnote time series noise.

9.  Arm cavity alignment.  Significant DC effect.

    * When the alignment of one of the arm cavity mirrors is changed, the DC value of the beatnote signal changes. 

           * ITMX moved in yaw, we see a 7kHz/15urad DC shift in the BEATX_FINE_PHASE_OUT_HZ time series.

          * ETMX moved in yaw, we see an 8kHz/5.5urad DC shift in the time series.  We aren't sure why this is about a factor of 3 times larger effect (same shift for smaller misalignment) than the ITM.

    * We want to do a Yuta-style analysis to see what the angle to length coupling looks like, so that we can measure the angular motion of our cavity mirrors and put the expected noise into our ALS noise budget.  Perhaps this will help us understand the low frequency difference between our in-loop beatnote error signal and our in-loop PDH error signals (red vs. maroon on the ALS noise budget posted above Pianosa). 

    * I've asked Manasa to take some transfer functions in the morning, so that we can start to have an idea of what is going on with this.

10.  Beatnote RF frequency.  Significant broadband effect.

     * We have found that when the Xarm beatnote is at low RF frequencies, the noise is high, and when the beatnote is at high RF frequencies, the noise is low! 

     * Low RF freqs are below about 40 MHz, while high RF freqs are above about 90 MHz.  This has not been tested for the Yarm.  Also, these are for the case of "temp slider up, beatnote up".  I have not checked if the same is true for the other side of the PSL frequency, although I don't have reason to believe that it would be.

     * Maybe we are saturating some amplifiers?  We need to check this out.  One thought that Den mentioned was the harmonics, and that perhaps they are causing trouble in the electronics.

     * Den is going to think about implementing a frequency divider so that we can directly digitize the beatnote signal. 

    * Here are spectra for different cases:

        * And here is a spectrogram showing us going back and forth between the high and low noise states:

                     *  A:  First noticing that noise is good when RF frequency is high.

                     * B:  Not locked on TEM00 mode, so extra noisy.  Disregard.

                     * C:  Bad noise time.  Xbeat was 21 MHz (dark purple on DTT spectrum above), Ybeat was 118 MHz (sea green on DTT spectrum above).

                    * D:  Good noise time. Xbeat was 89 MHz (light purple on DTT plot), Ybeat was still 118MHz (turquoise on DTT plot).

                     * E:  Bad noise time.  Xbeat was 37.5 MHz, Ybeat was still 118 MHz.

                     * F:  Good noise time.  Xbeat was 113 MHz, Ybeat was still 118 MHz.