40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 212 of 344  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  9906   Fri May 2 19:03:13 2014 JenneUpdateLSCALS out of loop spectra

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!

ALS_OutOfLoop2_2May2014.pdf

  9908   Sun May 4 22:28:54 2014 ericqUpdateLSCfarther into CM

 [Rana, ericq]

Today, we got a ~2kHz bandwidth lock of the YARM with the AO path. We weren't able to turn any boosts on, due to POY noise. 

Rana and Koji have written scripts (/scripts/PRFPMI/cm_step and cm_down) that work very reliably. 

Here is an OLTF. (Violin filter was off, the crap around 600Hz goes away with them on)

 OLTF.png

My MATLAB modeling was useful is predicting the features of the loop shape, and the dependence on AO gain/crossover. Still, I need to check it out, because there is nonzero discrepancy between reality and my model (this may be hiding in the non flat MC AO response, i.e. the bump at ~35kHz. Alternatively, the crossover frequency is a free parameter...)

In any case, we have confidence that the CM board is mostly working predictably. We presume that our current obstacle is the very noisy nature of POY, and thus it's not worth spending more time in this configuration. 

Upcoming plans:

  • Use the CM board to control the Y arm coupled with the PRM. ("PRY"?)
  • Determine the game plane for high BW control of CARM. 

Next steps:

  • Check CM board boosts turn on politely (Transients, TFs)
  • Use fast spectrum analyzer to check MC loop gain out to a few MHz. (The bump in the tens of kHz should be fixed / moved higher)
  • Think about noise performance of, say, REFLDC, ASDC, RF AS signals, etc. in the PRY case, figure out which one to use first. 
  • We may want to first focus on directly locking the arm on an RF signal, figure out gains etc. and then figure out how to do DC->RF handoff nicely, or if high bandwidth DC signal control is even feasible. 

RXA: we should also use AS45 instead of POY11. It has better SNR and I think our whole problem is too little light on POY.

  9909   Mon May 5 19:26:43 2014 JenneUpdateLSCOverride ability for whitening triggering

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

  9912   Tue May 6 02:48:50 2014 JenneUpdateLSCAO path engaged with AS55 as error signal for Yarm locking

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

out.pdf

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.

TF3_5May2014_BoostON_UGF5kHz.png

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.

CM_TP2A_140506_boostON_realloc.png

Attachment 2: zipped.tgz
  9913   Tue May 6 03:17:15 2014 ranaUpdateLSCfarther into CM

Yes, we still need to do these things, day team. Please tune up the MC loop first, before anything else.

Quote:

Next steps:

  • Check CM board boosts turn on politely (Transients, TFs)
  • Use fast spectrum analyzer to check MC loop gain out to a few MHz. (The bump in the tens of kHz should be fixed / moved higher)
  • Think about noise performance of, say, REFLDC, ASDC, RF AS signals, etc. in the PRY case, figure out which one to use first. 
  • We may want to first focus on directly locking the arm on an RF signal, figure out gains etc. and then figure out how to do DC->RF handoff nicely, or if high bandwidth DC signal control is even feasible.  

  9917   Tue May 6 17:58:44 2014 ericqUpdateLSCfarther into CM

 I took a look at the MC OLTF and AO path TFs with the fast agilent analyzer. 

I played with the relative gain of the EOM and PZT, but couldn't really change the MC OLTF shape much without making the PC Drive RMS angry. 

However, it turns out we have plenty of phase headroom to up the MC UGF from ~100kHz to ~180, with about 40 degrees of phase margin and ~7dB of gain margin. As I write this, PC drive RMS is around 1.1, and FSS Fast at 5.6, so I think the extra gain is fine for now. 

This pushes up and smoothens out the gain peaking in the AO path; see this figure:

AOTFs.pdf

(why does ELOG hate my python plots?! argggg)

Rana's rule of thumb was "We need at least +3dB MC loop gain at our CM servo UGF," so it looks like high tens of kHz bandwidth may be doable from the AO standpoint.

RXA: No, no, no, no, no, noooo. Rana said we need a gain of 3-10 at the CM UGF, not +3 dB.

  9918   Tue May 6 18:32:14 2014 steveUpdateLSCTRY 60Hz noise hunt

This is an effort to get rid of our ground loops  by isolating the electronic components from the optical table.

Aluminum mounting base plates of Thorlabs BA2 and Newport B-2 were replaced by plates or post made out of delrin material.

This is an insulator. DELRIN base plates were installed 6 places. The oplev-qpd has Nylon base plate.

The NPRO and HE/NE lasers are not isolated from the table. S8 and S9

I'm not sure about the doubling oven S10 

The optical table is grounded at G11  through  ~1 Mohms to the ETMY chamber.

Alignment touch up needed   at all D-marked component!

 

Attachment 1: ETMY-ISCT_EISOL.jpg
ETMY-ISCT_EISOL.jpg
  9919   Tue May 6 19:38:13 2014 JenneUpdateLSCSet up for PRFPMI CM locking

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.

  9920   Wed May 7 04:01:44 2014 rana, jenneUpdateLSCPRFPMI: Common Mode servo using REFL_DC ON, CARM offset still non-zero
  1. With REFL_DC coupled into the CM board through an SR560 (with an offset subtractor), we were able to transition to use it as the CARM error signal.
  2. We reduced the CARM offset until the arm powers went up to ~13.
  3. We had the AO path turned on and the MCL/AO crossover was ~150 Hz.
  4. We saw the double cavity pole come in from HF down to ~1-2 kHz. The lock stayed stable like this.
  5. We've set the IMC overall gain higher by +4dB in the mcup script. That's -4 dB from Eric's max gain earlier today.
  6. We have some scripts now for this scripts/PRFPMI/ :   camr_cm_down.sh and carm_cm_up.sh
  7. The sequence was ALS -> SqrtInv while digital with CARM -> MC2. Then we digital transition to REFL_DC using the CM board switch to put REFL_DC into the REFL11_I socket.
  8. REFL_DC is noisy, so we upped the SR560 gain by 10 and compensated.

Also, we found the PRM OL off and turned it back on. The ETMY was swinging a lot after lock loss, so we set its SUSPOS damping gain to match the ETMX and it stopped swinging so much.

Next up: more of the same, make this sequence more stable, turn on CARM OSC and watch the LOCKI outputs while we slowly ramp between signals.

Also, what should be the sign of the CARM offset ???

  9921   Wed May 7 14:01:36 2014 steveUpdateLSCTRY 60Hz noise hunt

Quote:

This is an effort to get rid of our ground loops  by isolating the electronic components from the optical table.

Aluminum mounting base plates of Thorlabs BA2 and Newport B-2 were replaced by plates or post made out of delrin material.

This is an insulator. DELRIN base plates were installed 6 places. The oplev-qpd has Nylon base plate.

The NPRO and HE/NE lasers are not isolated from the table. S8 and S9

I'm not sure about the doubling oven S10 

The optical table is grounded at G11  through  ~1 Mohms to the ETMY chamber.

Alignment touch up needed   at all D-marked component!

 

 Attachment appendix:

 

D: component delrin isolated

N: component nylon isolated ( or Delrin )

S: component shell is shorting to optical table (except oven)

G:  optical table ground

 

I failed to maximize TRY the pds.

  9927   Thu May 8 00:40:39 2014 ericqUpdateLSCBNC vs. 2pin LEMO for AO

 I've checked that the 2pin lemo connector that was run some time ago from the LSC rack to the MC board does indeed transmit signals. To try and evaluate its suitability I did the following:

  • Generated a 5mVpp 1.3kHz signal with an SR785 and fed that into CM board In1, all boosts off, 0dB AO gain. 
  • Both BNC and LEMO connected to CM servo out
  • One of BNC or LEMO connected to IN2 of MC servo, input gain of 30dB but disabled, OUT2 switched to AO and fed to Agilent spectrum analyzer. 
  • Terminated MC IN2 for comparison. 

No real difference was seen between the two cases. The signal peak was the same height, width. 60Hz and harmonics were of the same amplitude. Here are the spectra out to 200k, they are very similar. 

AOcablesWide.pdf

Mode cleaner was locked during this whole thing. This may interfere with the measurement, but is similar to the use case for the AO path. If ground loop / spurious noise issues keep occurring, it will be worthwhile to examine the noise of the CM and MC servo paths, inputs and outputs more carefully. 

  9932   Thu May 8 17:00:56 2014 rana, QSummaryLSCREFL_DC handoff didn't work last night

Last night after checking cabling and turning on ISS, we tried several times to handoff to REFL_DC but it didn't work at all.

Some issues:

  1. The ISS was injecting a lot of very low frequency power fluctuations because of bad AC coupling.
  2. The SR560 @ LSC rack was saturating a lot with the x10 gain that Jenne and Rana put in; we turned it back to G = 1.
  3. The ISS was also saturating a lot. We turned it off around 4 AM, but still no success.
  4. The ALS sequence for finding the Red Resonance takes too long (~2 minutes), so we're trying a faster scheme tonight.
  9933   Thu May 8 17:25:17 2014 steveUpdateLSCTRY 60Hz noise hunt

 I worked at the ETMY-ISCT this morning and late afternoon.  I will continue the 60 Hz noise hunt tomorrow. 

  9935   Fri May 9 04:09:39 2014 JenneUpdateLSCCM board boost turn-on checkout

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.

  9936   Fri May 9 04:51:13 2014 ericqSummaryLSCREFL_DC handoff didn't work last night

Quote:

Last night after checking cabling and turning on ISS, we tried several times to handoff to REFL_DC but it didn't work at all.

Some issues:

  1. The ISS was injecting a lot of very low frequency power fluctuations because of bad AC coupling.
  2. The SR560 @ LSC rack was saturating a lot with the x10 gain that Jenne and Rana put in; we turned it back to G = 1.
  3. The ISS was also saturating a lot. We turned it off around 4 AM, but still no success.
  4. The ALS sequence for finding the Red Resonance takes too long (~2 minutes), so we're trying a faster scheme tonight.

 Still no success tonight

  • We took CARM OLTFs at various CARM offsets and could clearly see the peak in the optical TF (in once case ~2.5kHz), which gave us an indication of our offset (~200pm)
  • REFLDC effectively sees the same plant TF as the transmission signals plus a zero at ~110 Hz, at all offsets under 1nm, from my simulations; this pushes up the optical resonance and causes a loop instability when we try to handoff. 
  • We need to make the CARM OLTF steeper to suppress this instability, but also to make a good crossover with the AO path, which otherwise has too similar of a slope around the UGF, as we saw with our one arm test. 
  • We're thinking of trying to turn the AO path on with REFLDC while keeping the arms on SQRTINV signals. This may be tricky, but if we can get the loop bandwidth above the optical peak, it'll be a lot easier to deal with, and transfer digital control to REFLDC as well. 
  9938   Fri May 9 14:01:24 2014 JenneUpdateLSCCM board boost turn-on checkout

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.

SuperBoosts.PNG

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:

AOgain_0dBto1dB.PNG

Next, 1dB to 2dB:

AOgain_1dBto2dB.PNG

2dB to 3dB:

AOgain_2dBto3dB.PNG

3dB to 4dB:

AOgain_3dBto4dB.PNG

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:

AOgain_5dBto6dB.PNG

7dB to 8dB:

AOgain_7dBto8dB.PNG

9dB to 10dB:

AOgain_9dBto10dB.PNG

11dB to 12dB:

AOgain_11dBto12dB.PNG

13dB to 14dB:

AOgain_13dBto14dB.PNG

15dB to 16dB:

AOgain_15dBto16dB.PNG

17dB to 18dB:

AOgain_17dBto18dB.PNG

19dB to 20dB:

AOgain_19dBto20dB.PNG

21dB to 22dB:

AOgain_21dBto22dB.PNG

23dB to 24dB:

AOgain_23dBto24dB.PNG

25dB to 26dB:

AOgain_25dBto26dB.PNG

27dB to 28dB:

AOgain_27dBto28dB.PNG

29dB to 30dB:

AOgain_29dBto30dB.PNG

  9945   Tue May 13 03:30:10 2014 JenneUpdateLSCLocking activities - no progress

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

ALS_outofloop.pdf


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. 

  9951   Wed May 14 02:37:58 2014 JenneUpdateLSCNo big locking news

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.

  9956   Thu May 15 02:32:01 2014 JenneUpdateLSCStarted engaging the AO path, not getting all the way yet

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

TFSR785_15-05-2014_011008.pdf

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.

  9957   Thu May 15 02:52:51 2014 JenneUpdateLSCStarted engaging the AO path, not getting all the way yet

 

 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.

  9959   Thu May 15 16:46:35 2014 ericqUpdateLSCPossible Path to AO path

 It's taken a lot of trial and error, but I've found a path through MATLAB loops that seems like it may be stable at all points.

CAVEAT: This doesn't give any indication as to why we weren't able to turn up the AO gain more last night, as far as I can tell, so it's not all good news. 

However, it's still ok to at least have a plan that works in simulation... 

Based on the location of the optical resonance peak in the CARM plant, we estimate our CARM offset to be 200pm. I haven't simulated TFs there exactly, but do have 100pm and 300pm TFs. This procedure works in MATLAB starting at either, though 100pm is a little nicer than 300. MATLAB data and code is attached in a zip. 

The steps below correspond to the attached figures: Bode plots and step response of the Loop at each step. 


0. [Not Plotted] DCTrans sensing, MCL actuation on CARM. FMs1,2,3,5,8; UGF = 120. (DARM not considered at all)

  1. AO path just turned on. Crossover with MCL path ~ 3.5kHz. 
  2. AO gain increased. Crossover ~ 500 Hz. There are now multiple UGFs! Handling all of these in a stable manner is tricky. 
  3. AO gain increased. Crossover = 150Hz. [No simulations with a higher crossover survived the next steps]
  4. Compensation filter applied to MCL path; 1 real Zero at 105Hz and a pole at 1k. From a TF point of view, this is sort of like switching to REFLDC, but the SNR at low frequencies is probably better in TR signals at this point. 
  5. CARM offset reduced to 30pm. (This smoothens out the optical plant resonance.)
  6. Overall gain increased by factor of 3. There is now just one UGF at a few kHz, above the optical resonance. From here, gain can be further increased, boosts can go on, offset can go way down. In reality, we should switch to a single error signal once we're back to one UGF, and go from there. 

AOtransitionBodes.pdfAOtransitionSteps.pdf


#4 Seems like the most sticky part. While both sides of this look stable as far as I can tell. I feel that flipping from the red phase curve to the teal might not actually be ok, since they are on either side of the bad phase of 0 degrees. It isn't immediately evident to me how to easily model the transitions between steps, rather than just the stability of of each step in the steady state. 

Attachment 3: AOCarmLoop.zip
  9962   Fri May 16 10:48:32 2014 SteveUpdateLSCY arm T- qpd is getting light guard extension tube

The qpd was removed from the east end table and threaded adaptor ring epoxied on it's shell.

This tube will cut down the amount of emergency exit light getting into the qpd.

Attachment 1: TRYepox.jpg
TRYepox.jpg
  9963   Fri May 16 10:54:42 2014 ericqUpdateLSCX Arm ALS Noise coming in and out

Den and I spent some time with the interferometer last night with hopes of bringing in the AO path, but were stymied by the (re)occurrence of the anomalously high low frequency motion of the Xarm, as seen by fluctuations of TRX from .9 to .2 while "held" on resonance.

Jenne reported that they weren't seeing it earlier in the evening, and then it started again when I showed up. Holding the arms on IR, we could see a fair amount of excess low frequency noise in the BEATX_FINE_PHASE_OUT_HZ channel, as compared to BEATY, bringing its RMS to 5 times that of the Y arm. From the shape of the excess noise (broad slope from DC to tens of Hz), Rana suspected air currents and/or scattering effects being the culprit.

Den poked around a bit on the PSL table, which didn't really change much. He then went down to the X end table to inspect the table, and while he was there, I noticed the noise go down to being in line with the Yarm. I joined him at the end, and we found the beat phase noise in the frequency region of concern to be hugely sensitive to tapping on the enclosure, air current, etc. There is also a ton of green light everywhere, and multiple spots of green light around the green refl PD.

At that point however, the quiescent noise was acceptable (TRX fluctuations of <.2), so we went back to the control room to try to lock. Unfortunately, after a few attempts, the noise was back. At this point, we went home. The layout of the end table likely needs some attention to try and minimize our susceptibility to excess scatter effects. 

  9964   Fri May 16 11:22:23 2014 SteveUpdateLSCX Arm ALS Noise coming in and out

Quote:

Den and I spent some time with the interferometer last night with hopes of bringing in the AO path, but were stymied by the (re)occurrence of the anomalously high low frequency motion of the Xarm, as seen by fluctuations of TRX from .9 to .2 while "held" on resonance.

Jenne reported that they weren't seeing it earlier in the evening, and then it started again when I showed up. Holding the arms on IR, we could see a fair amount of excess low frequency noise in the BEATX_FINE_PHASE_OUT_HZ channel, as compared to BEATY, bringing its RMS to 5 times that of the Y arm. From the shape of the excess noise (broad slope from DC to tens of Hz), Rana suspected air currents and/or scattering effects being the culprit.

Den poked around a bit on the PSL table, which didn't really change much. He then went down to the X end table to inspect the table, and while he was there, I noticed the noise go down to being in line with the Yarm. I joined him at the end, and we found the beat phase noise in the frequency region of concern to be hugely sensitive to tapping on the enclosure, air current, etc. There is also a ton of green light everywhere, and multiple spots of green light around the green refl PD.

At that point however, the quiescent noise was acceptable (TRX fluctuations of <.2), so we went back to the control room to try to lock. Unfortunately, after a few attempts, the noise was back. At this point, we went home. The layout of the end table likely needs some attention to try and minimize our susceptibility to excess scatter effects. 

 Turn off the AC and flow bench please.

  9965   Fri May 16 16:08:12 2014 steveUpdateLSCIsolating base plates

 Electronic components should be ISOLATED as they are installed on the optical tables.

This is essential to avoid ground loops, 60 Hz and harmonic peaks in the spectrum. We have just got some made.

Please only use it for this reason. Earlier black delrin base plates were used up in not needed places.

 

The anodized Aluminum base plates with magenets certainly will conduct.

 

Attachment 1: ISObaseplates.jpg
ISObaseplates.jpg
  9968   Sun May 18 14:36:04 2014 denUpdateLSCoffsets in 3f and drmi stable lock on 1f

Eric, Den

We noticed that PRMI RIN is high when the cavity is locked on RELF33 I&Q signals. We compared the level of power fluctuations when PRMI was locked using REFL11, REFL55 and REFL 33. Attached plot "prmi_rin" shows the spectra.

Then we excited PRM and measured length to RIN coupling when PRMI was locked on REFL33 I&Q. DC offset of PRCL is only 3%. But MICH offset seems to be ~nm. When we gave offset of -15 cnts to the servo, power fluctuations improved by a factor of few.

Then we looked at DRMI. It seems that SRC macroscopic length is off but we still could lock it stably. To account for macroscopic length detuning we had to rotate REFL55 phase from 25 degrees to 50 degrees. Power at AS port increased by factor of ~2 compared to PRMI configuration. SPOP18 is decreased only by 30%. Attached plot "drmi_power" shows POP18, POP90, POPDC and ASDC in PRMI and DRMI configurations.

Plot "src_ol" shows srcl OL transfer function. UGF is 70 Hz. We have also centered SRM OL and copied the servo filters from PRM, gains are set to keep UGF at ~0.1 Hz and 7 Hz

This is a more detailed procedure:

1. Phase: REFL11: 19 degree, REFL55: 50 degrees (25 degrees for PRMI configuration)

2. Input matrix:

PRCL   0.15 0 0 REFL11I
MICH = 0 0.15 0 REFL55Q
SRCL   -0.09 0 1 REFL55I

3. Servo parameters:

PRCL: gain = -0.02, FM4,5 + trigger FM2,3,6,9

MICH: gain = 0.8, FM4,5 + trigger FM2

SRCL: gain = 0.25, FM4,5 + trigger FM2,3

4. Triggering:

signal is SPOP22 , levels 40:25

Attachment 1: prmi_rin.pdf
prmi_rin.pdf
Attachment 2: drmi_power.png
drmi_power.png
Attachment 3: src_ol.pdf
src_ol.pdf
  9969   Sun May 18 17:57:54 2014 ranaUpdateLSCETMX transients due to unseated bias cable

 The daytime crew had noticed that there were some ETMX angular shifts happening without any control or intention.

I reseated and strain relieved the bias cable coming into the backplane of the coil driver and now it seems OK.

In the 4-hour-long second trend plot below, the era before 2300 is before reseating. Afterwards, we make a couple adjustments, but so far there has been no un-asked for alignment shifts.

AdS has been run on both arms and offsets saved. Its locked on green/red and the beat frequencies are low and the amplitudes high. 

Sun May 18 23:53:37 2014: still OK...I declare it fixed.

 

Attachment 1: ETMXbiasCableSeated.pdf
ETMXbiasCableSeated.pdf
  9970   Mon May 19 09:19:44 2014 SteveUpdateLSChappy IFO

15 hours

Attachment 1: whenthinksareworking.png
whenthinksareworking.png
  9972   Tue May 20 02:12:35 2014 JenneUpdateLSCALS X noise investigation

[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:

          ALS_outofloop_19May2013.pdf

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

          XbeatSaturate.png

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

  9976   Tue May 20 16:48:52 2014 ericqUpdateLSC3f Stability

So, I really should have done this as soon as Manasa measured the arm lengths... I've updated my MIST model with the real arm lengths, but still am using assumed identical losses of 75ppm on each mirror. (I've tried measuring the arm losses for real, but got numbers in the hundreds of ppms, so I need to reexamine things...) 

Here's a simulation of the fields in a perfectly locked PRC when CARM is swept (Normalized to input power = 1). 

CARMsweepPrcFields.pdf

More importantly, here's the latest simulation of MICH vs. PRCL demodulation angle separation in the 3F signals. It seems that we may be getting burned by using REFL33 for the PRC lock. REFL165, on the other hand looks much more robust. We should try this out. 

3fs.pdf

(Some of my previous simulations incorrectly implemented MICH excitations; I only moved the ITMS, not the ETMS along with them, so some other stuff slipped in... )

  9977   Tue May 20 22:42:28 2014 ericqUpdateLSC3f Stability

 Here's the angles of MICH and PRCL from the my earlier plot by themselves; this shows that the individual demod angles in REFL165 aren't changing much either. 

PRCangles.pdf

  9978   Wed May 21 00:18:40 2014 JenneUpdateLSCPRMI locked with REFL33 vs. REFL165

Since Q has found that REFL165 will be better for holding the PRMI while we reduce the CARM offset, I had a look at locking PRMI sideband locking with both 3f PDs.

I checked the REFL165 demod phase, and changed it from -142.5 deg to -138.5 deg. to minimize the Q signal while driving PRM length.

I found that keeping the MICH and PRCL loop gains the same, and using matrix elements +0.1 for both I and Q for REFL165, rather than +1 for both I and Q for REFL 33.

MICH gain is +0.8, PRCL gain is -0.02.  FMs 4,5 on for both, FM 2 triggered for MICH, FMs 2,3,6 triggered for PRCL.

I then locked the PRMI on sideband with REFL 33 and then REFL 165, and measured the other one as an out of loop sensor of the motion.  I find that REFL33 and 165 are both comparable, and so we shouldn't have any trouble using REFL165 for locking.

PRMI_outofloop_20May2014.pdf

  9979   Wed May 21 05:05:39 2014 JenneUpdateLSCREFL 165 vs 33 investigations

[Rana, Jenne]

We spent some time tonight looking at locking the PRMI with REFL165 vs. REFL33, while reducing the CARM offset. 

We were not able to lock the PRMI on REFL165 I&Q at small CARM offsets.  When locking at larger CARM offsets (about 100 counts, which is about 100nm) and then re-adjusting the REFL165 demod phase as I reduced the CARM offset, I saw that I had to significantly rotate the phase.  For PRMI only (no arms), the REFL165 demod phase was -138.5 deg.  When the PRMI was locked with a -100 count CARM offset, the optimal demod phase was -123 deg.  Then at -90 counts the phase was -113 deg.  At -70 counts, the phase was -108 deg, at -50 counts it was -98 deg, and at -40 it was -93 deg.  We want to go back and look at these more carefully, and in a more continuous way, by watching the sensing matrix calibration lines.  It's unclear to me right now why we're seeing this, but it's possible that we're getting some kind of extra 55MHz resonances.

REFL DC looks like it should be good - same slope and gain as sqrtTR, extra 20 or 30 deg of phase margin, so we think that we should be able to transition over to it, and then try engaging the AO path.  Tonight we had Den's new 1kHz lowpass engaged, and with this, everything looks nice and stable.

Game plan:  Bring CARM in until transmissions are at about 10ish, then try keeping CARM on sqrtInvTrans for the DC part, and engage the AC AO part with REFL DC.  We probably just need to try this for a while more to find just the right way to turn it on.

Need to think about demod phase rotation vs CARM offset as well as extra resonances, but this may take a while, and if we can just get the AO path engaged, that would be good.

  9983   Wed May 21 13:20:34 2014 manasaUpdateLSCALS X noise from angular motion of mirrors

Quote:

[Rana, Jenne]

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.

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

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

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

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

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

Attachment 1: ALSX_OLYerrITM.png
ALSX_OLYerrITM.png
  9988   Thu May 22 00:30:40 2014 manasaUpdateLSCALS X noise from angular motion of mirrors

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

The transfer functions are mostly flat.

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

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

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

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

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

Attachment 1: ALSX_OLPerrITM2.png
ALSX_OLPerrITM2.png
Attachment 2: ALSX_OLYerrITM.png
ALSX_OLYerrITM.png
Attachment 3: ALSX_OLPerrETM.png
ALSX_OLPerrETM.png
Attachment 4: ALSX_OLYerrETM2.png
ALSX_OLYerrETM2.png
  9996   Tue May 27 21:48:31 2014 JenneUpdateLSCX green broadband PD not working???!?

Grr.  I am very frustrated.  After lunch I redid alignment for both X and Y green systems (Yarm both at the end and on the PSL table, Xarm just on the PSL table).  After that realignment work, I cannot find a beatnote for the Xarm!!! 

The Ybeat, after aligment, was up to -5.5 dBm when the beat was at 11 MHz. Last week it was something like -20 dBm, so alignment makes a big difference.  After doing IR alignment I had noticed that the green transmitted through the Yarm didn't look very bright on the camera, and the power was around 0.2, so I went to the Yend and gently touched the green input steering mirrors, and got the Ygreen trans PD back to more than 0.9 with the PSL green shutter closed.  Awesome.  Then I touched up the Ygreen PSL alignment, and then saw that the beatnote was nice and large.  Hooray.  I measured the out of loop noise, and it was even better than the best we saw last week:  (greenish was best last week for Yarm, teal blue is new Ygreen):

ALS_outofloop_27May2013_2.pdf

At this point, I still hadn't touched anything on the X path (except the PZT input steering mirrors, remotely from the control room).  The beatnote was about the same size as it was on Friday, around -27dBm.  I went onto the PSL table and did the same alignment procedure that I had just done for the Yarm:  Remove the green trans PD and the accompanying lens so that I get far-field spots on the wall, and then steer the PSL green and the X green spots until they are nicely overlapped at both the camera (near-field) and on the wall.  I looked at the DC output of the beat PD, and centered the beam on the diode.  I put back the thorlabs DC transmission PD and the lens, and centered the beam on that.  However, after this work, I cannot find a beatnote for the X arm!  I still see the nice big Ygreen beatnote, and I have the PSL and Xend temperatures where they usually are (  abs(FSS Slow) < 0.1, and X end Slow around 10,090. )  I scanned -10,000 counts, and +5,000 counts from there, and still don't find a beatnote!

I went back inside, and I don't see an RF signal coming into the beatbox from the Xarm.  It's not the cable's fault though, since I then hooked the RF output of the beat PD to a 'scope, and still didn't see any beatnote.  The DC path of the PD is definitely seeing things, because when I switch the 'scope over to the DC output of the Xbeat PD, and I block/unblock the beam, I see the voltage step up and down as expected. 

I have not pulled out the Xgreen broadband PD, but unless someone else has a good idea of what to check, that might be one of the next things to do. 

Ideas of things I could try:

* Put the X broadband PD on the Y beatnote path to see if I see the same Y beatnote (use the port where the Y green trans PD is, since it has the coaligned beams, and a lens).

* Open the PD and see if anything on the RF path is fried.

* Move the Y PD over to the X path, to see if it sees the beatnote.

* ????

  10000   Wed May 28 17:51:48 2014 manasaUpdateLSCX green broadband PD NOT working

Quote:

Grr.  I am very frustrated.  After lunch I redid alignment for both X and Y green systems (Yarm both at the end and on the PSL table, Xarm just on the PSL table).  After that realignment work, I cannot find a beatnote for the Xarm!!! 

At this point, I still hadn't touched anything on the X path (except the PZT input steering mirrors, remotely from the control room).  The beatnote was about the same size as it was on Friday, around -27dBm.  I went onto the PSL table and did the same alignment procedure that I had just done for the Yarm:  Remove the green trans PD and the accompanying lens so that I get far-field spots on the wall, and then steer the PSL green and the X green spots until they are nicely overlapped at both the camera (near-field) and on the wall.  I looked at the DC output of the beat PD, and centered the beam on the diode.  I put back the thorlabs DC transmission PD and the lens, and centered the beam on that.  However, after this work, I cannot find a beatnote for the X arm!  I still see the nice big Ygreen beatnote, and I have the PSL and Xend temperatures where they usually are (  abs(FSS Slow) < 0.1, and X end Slow around 10,090. )  I scanned -10,000 counts, and +5,000 counts from there, and still don't find a beatnote!

I went back inside, and I don't see an RF signal coming into the beatbox from the Xarm.  It's not the cable's fault though, since I then hooked the RF output of the beat PD to a 'scope, and still didn't see any beatnote.  The DC path of the PD is definitely seeing things, because when I switch the 'scope over to the DC output of the Xbeat PD, and I block/unblock the beam, I see the voltage step up and down as expected. 

I have not pulled out the Xgreen broadband PD, but unless someone else has a good idea of what to check, that might be one of the next things to do. 

Ideas of things I could try:

* Put the X broadband PD on the Y beatnote path to see if I see the same Y beatnote (use the port where the Y green trans PD is, since it has the coaligned beams, and a lens).

* Open the PD and see if anything on the RF path is fried.

* Move the Y PD over to the X path, to see if it sees the beatnote.

* ????

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

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

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

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

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

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

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

  10001   Wed May 28 19:15:38 2014 KojiUpdateLSCX green broadband PD NOT working

If the PD is the suspect, just pull it from the table and bring it to the PD testing setup.

The transimpedance of the PD should be ~2000 Ohm for both of the RF and DC outputs.

The test setup gives you the systematic opportunity for examination of the signal line.
Check the signal level with the active probe.

Once the broken component is found replace it. You are supposed to have the replacement
components on the blue tower.

  10002   Thu May 29 02:16:02 2014 ericqUpdateLSCHigh Bandwidth power recycled Yarm.

I'll put more detail in the morning, but I was able to get the PRM/ITMY/ETMY coupled cavities locked with 32kHz bandwidth using the AO path. (However, this is a pretty low-finesse situation, since the BS is dumping so much power out of the PRC. Full buildup is only 3 or 4 times the single arm power)

Since our ALS is better than it was a month ago when I last played with this, I was able to hop straight from ALS to REFL11 I on resonance, with the PRY locked on 3f.

Here are some quick OLTF plots I took along the way.

 

 

quickOLTFs.pdf

I'm using this configuration to validate my loop modelling for the full double arm case. Right off the bat, this tells me that the "minus" polarity on the CM servo is the correct one. I didn't use REFLDC at all tonight, but I figure I can check it out by doing the transition backwards, so to speak.

  10004   Thu May 29 14:40:17 2014 KojiUpdateLSCHigh Bandwidth power recycled Yarm.

Wait. It is not so clear.

Do you mean that the IFO was locked with REFL11I for the first time?

Why is it still in the "low finesse" situation? Is it because of misalignment or the non-zero CARM offset?

  10005   Thu May 29 15:33:55 2014 ericqUpdateLSCHigh Bandwidth power recycled Yarm.

Quote:

Wait. It is not so clear.

Do you mean that the IFO was locked with REFL11I for the first time?

Why is it still in the "low finesse" situation? Is it because of misalignment or the non-zero CARM offset?

Sorry, the X arm is completely misaligned. This is the configuration I first tried in ELOG 9859, that is: a PRM->ITMY recycling cavity and ITMY->ETMY arm cavity. ITMX is completely misaligned, so the BS is dumping much of the recycling cavity light out, which is why I wrote "low finesse." This is the first time I've used REFL11 to control any of our cavities, though.

  10047   Mon Jun 16 23:15:44 2014 JenneUpdateLSCIFO alignment recovery

I noticed today, and Rana said that he saw Saturday, that the MC refl value when the MC is unlocked is unusually high.  It typically goes to about 4.5 V, but now is going up to 6.5V.  Since the PMC output is the same as usual (max seen has been about 0.82 today), something must have happened between the PMC and the IMC. 

Late last week, EricG and Nichin were looking at things on the AS table.  Was anything touched on the AS table?  Was anything touched on the PSL table?  'Fess up please, so that we can pinpoint what the change was.

 

Also, this afternoon, I touched up the MC alignment a bit, although it still needs work (I've asked Manasa to look at it tomorrow).  Rana centered the WFS to my MC alignment (this will need to be redone after the MC is truely aligned), and we turned the WFS on.  I also locked both arms individually, and locked MICH and PRMI sideband.  The PRMI wasn't especially stable unless I turned on the POP ASC.  I assume (hope) that this is just because I was doing it during the day, and not because there is something actually different about the PRMI since the computer meltdown.

 

Rana and I also took some notes on things that need to be done, starting tomorrow (the first line and the yellow line are scribbles):

Note_061614_230723_0.jpg

  10051   Tue Jun 17 17:14:14 2014 ManasaUpdateLSCIFO alignment recovery

 1. Recovered MC alignment and locked it manually after the ottavia cron failed to help.

2. Measured the MC spots and could not get the MC spots better looking than this.

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
[1.6609930611758554, -1.4655939584833202, 1.3133188677545831, -1.9483764375494121, -1.6539541350121174, -0.8862744551298497]

3. Realigned the beams to the MC WFS and enabled WFS servo.

MC Trans SUM is ~17000 counts and MC REFL is ~0.5 counts.

To-do list

MC spots

MC WFS

IOO QPDS center

BBPD char

Recover REFL 33

MC REFL

MC autolocker cron

  10053   Tue Jun 17 21:49:13 2014 JenneUpdateLSCIFO alignment recovery

PRMI locking with REFL33 is fine.  As it was yesterday, it's a little wobbly without the ASC (just PRM oplev), but I don't know that it's any different than it used to be.  It'll hold for long periods of time, so I feel okay about it. 

When the PRMI is locked, you can push the "up" button on the ASC screen, and it'll turn down the PRM oplev gain by a large factor, and engage the ASC.  When you lose lock, press the "down" button to undo these changes.  (Probably the ifoconfig script should include the ASC down script).  These up and down scripts for the ASC are already included in the carm_up script (the ASC up), and the watch scripts which run a down script (including ASC down) for the whole IFO when ALS loses lock.  If the ASC is engaged, I get bored of watching it before the PRMi loses lock on its own, so I think it's okay.  (Let's say that means I've watched it stay locked for at least a few tens of seconds, but it looks like it always has with the ASC - like it'll stay forever).

The only thing that seems different about the PRMI is that I've increased the PRCL gain from -0.02 to -0.04.  This is a value that it was at some weeks ago, and then we turned it down for loop osc reasons, but now it doesn't want to catch lock with the lower value, and if I turn it down after it's locked, it has trouble holding on.  I have included this change into the PRMI sideband configure script.

I haven't tried anything creative like locking with REFL 165.  I also didn't lock with 11 or 55, since 33 just worked.

  10055   Wed Jun 18 11:57:44 2014 not JenneUpdateLSCIFO alignment recovery

Quote:

I noticed today, and Rana said that he saw Saturday, that the MC refl value when the MC is unlocked is unusually high.  It typically goes to about 4.5 V, but now is going up to 6.5V.  Since the PMC output is the same as usual (max seen has been about 0.82 today), something must have happened between the PMC and the IMC. 

Late last week, EricG and Nichin were looking at things on the AS table.  Was anything touched on the AS table?  Was anything touched on the PSL table?  'Fess up please, so that we can pinpoint what the change was.

 

 Nope, we did not touch any of the PDs other than AS55. I have mentioned in  my elog:10037 what we did exactly.

We just looked at all the other PDs to check if they were being illuminated by the correctly labeled fiber. Nothing other than that.

  10068   Thu Jun 19 00:02:48 2014 JenneUpdateLSCPRMI+2 arms recovery

Arms locked in comm and diff with ALS. PRMI locked with REFL33 I&Q while arms off resonance. Having trouble reducing CARM offset, even to get to arm powers of 1.

After Manasa installed the new Xgreen PD, Koji looked at the PSL table alignment with me.  I saw only a very weak beatnote with the X BBPD, even though I could see the beatnote on the Y PD from the leakage of the X beam to the Y PD  (Yend shutter was closed, so just PSL and X greens were on the table).  I had thought that my near-field and far-field alignments were pretty good (actually, I checked them, but didn't feel that I needed to tweak them since Manasa did the alignment this afternoon).  Anyhow, it was just a matter of tweaking up the alignment a bit, and then the X beatnote got up to about -25dBm at a few tens of MHz.  I am starting to question myself if the other BBPD is broken, or if I just not well enough aligned.  Anyhow, the spare is in, we can still have a look at the previous X BBPD, but it may be okay, and it's just me embarrassing myself by not catching an alignment problem.

Anyhow, after the X beat was found, I was able to (on my first try) lock the arms using ALS comm and diff.  (I already had a nice strong Y beatnote, so that didn't need finding, other than temp adjustment of the end laser).  I ran the carm_cm_up.sh script, and it did everything nicely.  I did a quickie check of the phase tracker loop gains, but that should be redone in the morning.

PRMI was a little reluctant to lock, so I played around with the MICH and PRCL gains, but didn't really find any combination that was any better than the usual (+0.8 for MICH, -0.04 for PRCL as I had last night, although I needed to reduce the PRCL gain back to -0.02 to eliminate loop osc). 

After an arm lockloss, I relocked just the PRMI and used awggui to put a line into C1:LSC-PRM_EXC to check the RF PD phasing.  I changed REFL33 from 133.5 to 138.5, and REFL 165 from -142.5 to -152.5.  I didn't think that REFL11 needed changing, and I didn't check REFL55.  I also checked that I could lock PRMI without arms, using both REFL33 and REFL165 - they seemed about the same to me, both stable.  REFL33 has 1's in the input matrix, and I was using 0.07's for REFL165.  The demod phase adjustment didn't really improve PRMI locking while the arms were held off resonance, even if I moved the arms even farther from resonance (usually we do 3nm, I went out to 5nm to see if that helped - it didn't).  I tried REFL165 locking, but that wasn't any good either.  I tried using REFL165 with the arms held off resonance, but that didn't seem to catch at all (at least with REFL33 I was getting short lock blips). 

Anyhow, of the 3 or 4 times that I caught REFL33 PRMI lock and tried to reduce the CARM offset, only one time did I even get to arm powers of about 1 (CARM digital offset of -0.1, with CARM held on sqrt transmission signals), and then it didn't stay for more than a few tens of seconds.  The other few times, it broke lock on the way up to arm powers of 1. 

So, carm_cm_up.sh works pretty well, although perhaps the arm powers of 1 offset reduction needs to be a little slower.  PRMI doesn't catch and hold lock very easily with REFL33, and even less so with REFL165.  It may be useful to try catching lock with REFL11 or 55, and doing a transition over to 3f.  No real progress forward, but we're pretty much recovered.

 

  10090   Tue Jun 24 01:07:56 2014 JenneUpdateLSCBootfest 2014!

Still no real luck getting the beam back aligned to the IFO.

Koji and I tried a few minutes of wiggling the input pointing tip tilts (TT1 and TT2) around, and then tried doing some thinking.

We note that the beam propagates (modulo a few pickoffs):

IMC -> Faraday -> TT1 -> MMT1 -> MMT2 -> TT2 -> PRM.

Since moving TT1 to the rails does make beam reflections in the BS chamber move (as seen by movement of the general illumination on the PRM face camera), I posit that the beam is getting through the Faraday.  It is certainly getting at least mostly through the Faraday, although since the MC locked so easily, I assume that we didn't have too much movement after the ~2pm Alaskan earthquake & aftershocks, so we're at pretty much the same alignment as usual, in terms of beam pointing coming from the IMC.

The plan is then to see the position of the beam on MMT1, and steer using TT1 to get the beam to roughly the center.  Then, see the beam propagate to MMT2 (if possible) and TT2 (if possible).    From here, we should be able to see the spot on PRM.  We should be able to use TT2 to tweak things up, and get the beam back to about the right place on POP, or REFL, or somewhere farther along.  Hopefully at this point, we'd see some flashes in the Yarm. 

Using a spare Watek camera, I was able to capture a shot of the face of MMT1.  This is when the TTs were restored to their values that were saved last Monday.  I checked, and this is also roughly the center of the actuation range of TT1, for both pitch and yaw.

MMT1_face_23June2014_2315pm.png

I am not able to see the face of MMT2, or TT2.  If I leave TT1, and move TT2, I am not able to see any movement of any beam or reflections seen in the PRM face camera.

Koji and I are checking the MC spot positions, but it may be time to leave this for the morning crew.

EDIT:  The MC spots were actually pretty bad, and the WFS were working really hard.  Koji realigned the MC suspensions, and now the MC spots are slightly better, although quite similar, to what Manasa measured last week.  The restored TT values still don't give us any flashes in the arms.

  10094   Tue Jun 24 18:35:53 2014 JenneUpdateLSCStill no beam going to IFO

[Jenne, EricQ, Manasa]

We are still not able to get the beam to go to the interferometer, which is super frustrating. 

We tried using cameras and viewers to look into several ports, however all we can see is the face of MMT1, which I  posted a still of last night.  I have a camera looking at the back of the PRM, in hopes that we could see the beam on PRM, but no luck.  The thought was that the lever arm between TT2 and PRM is so short that as long as TT2 is reasonably in the center of its range, it doesn't need to be precise.  However, it seems that no matter how much I move TT1, I am not able to get a nice beam spot on PRM.  Part of this is that we have to be close enough to the right alignment to hit MMT1, MMT2 and TT2. 

Anyhow, we're frustrated, and I'm not sure what our next step is.  I would very much prefer it if we didn't have to open any chambers, but I don't currently have any new ideas on how to see the spot on MMT2 or TT2.

  10125   Wed Jul 2 21:30:42 2014 JenneUpdateLSCLittle Bo-Peep has lost her phase
Little Bo-Peep has lost her phase,
And can't tell where to find it;
Leave it alone, and it'll come home,
Bringing its degrees behind it.
 
Seriously.  What?  I was holding CARM on sqrtTrans with arm powers of about 1, DARM was still ALS diff, PRMI on REFL33.  CARM was actuating on +ETMX+ETMX, since I kept kicking the MC out of lock, but other than that, everything was set by the carm_cm_up script, so I don't think there should be any big differences.  I took a CARM transfer function, and it seems like the phase bubble has all but disappeared compared to the reference from mid-May. 

CARM_loop_ArmPowers1_2July2014.pdf

I need to figure this out before it's worth trying any acrobatic AO path turn-on scenarios.

 

Also this evening, I went to the Yend and did another tweak-up of the green beam alignment. 

  10126   Wed Jul 2 22:58:11 2014 JenneUpdateLSCLittle Bo-Peep has found her phase

Never mind.  This is just the low pass filter that Den put in to try to deal with the moving cavity pole. 

Before I realized this, just in case it was a computer quirk, Koji and I rebooted the end station front end machines.  This had no effect other than to keep me searching and measuring until I figured it out.  If I turn off the low pass, the phase pops back up to very close to the reference.  The low pass currently comes on automatically as part of the carm_cm_up script.

ELOG V3.1.3-