40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 139 of 341  Not logged in ELOG logo
ID Date Author Type Categorydown Subject
  10901   Wed Jan 14 19:27:09 2015 ericqUpdateLSCUGF servo now linear again

The UGF servos have been moved to the control point, are are once again totally linear!

  10902   Thu Jan 15 03:18:11 2015 diegoUpdateLSCUGF servo now linear again

The UGF servos were recommissioned today:

  • suitable values of frequency, excitation, phases and gain were found;
  • the phases were chosen in order to maximize the I signal and suppress the Q one;
  • the servos seemed sufficiently stable when in a quiet state, but they didn't performed well in other cases;
  • I also found out that DARM & CARM and MICH & PRCL are maybe too much coupled, but that could be actually due to the main loops rather than the UGF ones;
  • however, after some weird rampings with no apparent reasons, and after some quite bad and glitchy step responses, I found out that the effect of the chosen phases vanished: the I and Q signals were of the same order of magnitude again, probably causing the bad performance;
  • Jenne and I tried to increase che SINGAINs and COSGAINs (but keeping them equal to each other): this has the good effect of separating more the I and Q signals, but it's just a zoom effect: there still are mixing effects and, more important, some zero-crossings into negative values that cause the signal going into the servo to go crazy.

Our idea is that we need with some thinking about these servos and most of all try to figure out all this phase thing before we can start to trust the servos to be used for locking.

  10903   Thu Jan 15 04:41:01 2015 JenneUpdateLSCThoughts on going forward with variable finesse

[Jenne, Diego]

Life would be easier with the UGF servos working.  As Diego already elogged, we aren't sure why the demod phases are changing, but that is certainly causing the I-signals to dip below zero, which the log function can't handle (there is a limiter before the log, so that the signal can't go below 1e-3).  Anyhow, this is causing the UGF servos to freak out, so we have not been using them for tonight's locking.

Our goal tonight was to see if we could introduce a nice big MICH offset, and then lower the CARM offset while keeping the arms locked on ALS.  We hope to see some kind of sign of a PDH signal in some RF PD. 

In the end, the highest we got to was -460 MICH offset counts, which we think is about 29nm (if our rough calibration is accurate). The MICH half fringe should be 188nm. With this offset, we got down to 0.3 CARM offset counts while locked on ALS.  We think that this is around 300pm, plus or minus a lot.  Note that while yesterday I had a pretty easy time getting to -660 counts of MICH offset, tonight I struggled to get past -200.  The only way we ended up getting farther was by lowering the CARM offset.  Although, as I type this, I realized that last night's work already had a lower CARM offset, so maybe that's key to being able to increase the MICH offset. 

We watched REFL11I and REFL11I/(TRX+TRY) on striptool, but we didn't see any evidence of a PDH signal.  We lost lock when I tried to transition CARM over to REFLDC, but I wasn't careful about my offset-setting, so I am not convinced that REFLDC is hopeless.

So.  Tonight, we didn't make any major locking progress (the MC started being fussy for about an hour, right after I ran the LSC offsets script, just before we started locking in earnest).  However, we have some ideas from talking with Rana about directions to go:

* Can we transition CARM over to REFL11I, and then engage the AO path?

* Then, while the MICH offset is still large, can we transition DARM over to POX or POY, actuating on a single arm?  If CARM is totally suppressed, this is DARM-y.  If CARM doesn't have the AO path yet, this is halfsy-halfsy, but maybe we don't care.

* Then, can we lower the MICH offset and transition back to a REFLQ signal?

* Separately, it seemed like we kept losing PRC lock due to PRC motion.  If the MICH offset is very large, are we sideband-limited at the POP port, such that we can use the POP DC QPD?  Is it even worth it?

 

MICH calibration:

A single mirror (ITM) moving by lambda/2, in the MICH-only situation is the full range, from bright to dark fringe.  So, half fringe should be lambda/4, or about 133nm.  If we are thinking about pushing on the BS, there's an extra factor of sqrt(2), so I think the half fringe should be at 188nm of BS motion.

When we had MICH locked on ASDC/POPDC, we put in a line at 143.125Hz, at 20 counts to (0.5*BS-0.2625*PRM), so a total of 10 counts to the BS at 143Hz.  Given the BS calibration in http://nodus.ligo.caltech.edu:8080/40m/8242, this is 10.1pm of actuation.  We saw a line in the error signal of 0.1 counts, so we infer that the MICH error signal of ASDC/POPDC has a calibration of 94pm/count. This number was invariant over a few different MICH offsets, although the ones I measured at were all below about 100 counts of MICH offset, so maybe this number changes as we start to get farther from the MICH dark fringe.

 

IFO left flashing (all mirrors aligned except SRM) in case anyone wants fresh data for that.

  10904   Thu Jan 15 14:28:14 2015 JenneUpdateLSCLSC model change idea

Something that kind of drives me crazy with our current LSC model setup is that I can't make "finished" error signals before blending them.  The blending happens before the normalization matrix, and there is no place to put an offset to help match a new error signal to the current offset.  So.  While I'm sure this is not going to be immediately popular, here's a cartoon of a proposed model change to the LSC. 

The most important difference between this and the ramping matrix that is used at the sites is that you can put in offsets before the blend.  Also useful is the fact that the normalization can happen before the blend.  This proposal would make the LSC input matrix  and the normalization matrix have twice as many rows, and add an extra "selector matrix" just before the triggering at the error point of the loops. 

I've only drawn one degree of freedom in my cartoon, but assume that they all have the same capability (maybe we don't have to do XARM, YARM and MC this way).  One row is currently being used for the error signal, while the other row is just used to prep a new singal.  For a first transition (say, ALS to DC transmission), maybe the ALS signals are on row 1, and the DC trans is on row 2.  Once the transition is complete, row 1 is available to prep for the next transition (such as AS55Q).

 

Thoughts?  Is there a better way to achieve what I'm going for here?

  10910   Fri Jan 16 03:31:35 2015 JenneUpdateLSCLSC model change implemented

Okay, it has taken me almost exactly 12 hours (with a dinner break), but I have implemented this change.

Everything was svn-ed before I did things, and then again afterward.

Here is the "before" screenshot of the LSC model:

And here is afterward:

If you look extra carefully, you will see that it matches my proposal from http://nodus.ligo.caltech.edu:8080/40m/10904 .  I have made the change for DARM, MICH, PRCL, SRCL and CARM.  I did not alter XARM, YARM or MC.  Also, the CESAR stuff was taken out of the CARM area, since this is now a more generalized version of the same thing.


I have also checked and modified all of the scripts that I could think of, as well as all of the ifoconfig burt .req and .snap files that I could think of.  I also ran the carm_cm_up.sh script once, and it seems to work fine.  All of the transition scripts that are listed below (which are the only ones used currently in the sequence) now use the new error signal blending scheme.

Scripts:

  • Lock_ALS_CARMandDARM.py
  • ALSfindIRresonance.py
  • ALSwatch.py
  • carm_cm_down.sh
  • carm_cm_up.sh
  • CheckPRMIlock.py
  • Transition_MICH_REFL33Q_to_ASDC.py
  • Transition_CARM_ALS_to_TransInvSqrt.py
  • Transition_DARM_ALS_to_DCtrans.py
  • UGFup.py
  • UGFdown.py

Burts (listed are the .req files, but I also checked the .snap files, hand-editing the matrix element numbers where needed if I wasn't in the right config to do a save):

  • C1configure_Yarm.req
  • C1configure_YarmALS.req
  • C1configure_Xarm.req
  • C1configure_XarmALS.req
  • C1configure_CARM.req
  • C1configure_DARM.req
  • C1configure_PRM_forCARMdarm.req
  • C1configure_PRM_SBres.req
  • C1configure_PRM_Carr.req
  • C1configure_PRY.req
  • C1configure_DRM.req
  • C1configure_SRM.req

I also modified the screens for the input matrix and for the normalization matrix.  I created a new screen for the final blending matrices (which are all 2x1's), and I also modified the LSC_OVERVIEW screen. 

The input matrix and normalization matrix screens have colored bars that tell you whether a row is in use or not.  If the background to the row is the blue of the whole screen, that row is not being used.

The LSC screen has new hand-modified Kissel Buttons.  I wanted to show the total PD error signal that is being used, regardless of what row (A or B) it is on at that time.  So, I have collapsed the rows so that DARM_A and DARM_B are overlapped, even though they are actually rows 1 and 2 of the matrix.  The PD should only show up green on the LSC screen if that row is in use (so, if you are prepping a row, but aren't using it yet, you won't see those elements in the matrix).  Anyhow, the point is that the LSC overview part of things shouldn't look any different than before.


Brain not working anymore now that it's ~4am, but I need to rethink and recheck to make sure that the PD whitening triggering is still okay and working.  Or maybe we can remove it, and just include that in the scripts, as Rana has been suggesting for ages.  Thoughts for tomorrow.

  10911   Fri Jan 16 04:14:05 2015 diegoUpdateLSCUGF servo now linear again

UGF Servos' commissioning still going on, updates of today:

  • on Rana's suggestion, we don't use anymore the Q-signal rejection at the level of Phase 1 and Phase 2; instead, a proper complex division is made between those two signals (with a check in case of zero); then the resulting signal is demodulated with a new Phase 3, which is the one used to select the I signal while zeroing the Q one; changes to the model and the screens have been made;
  • a new evaluation of all the parameters for the four servos has been made; aside for the new phase, and the zeroing of the other phases (because they are not used anymore for the selection), the parameters are not dissimilar from the prevoius ones
  • the PRCL and MICH servos seem sufficiently stable;
  • CARM and DARM are stable only for a short amount of time; what usually happens is that one of the two starts drifting in one random direction, and usually the other one follows shortly after; it is not clear if there is a relation or if they stop being stable after a similar amount of time; I still noticed a few lowest limits appearing in the input signal, which should be avoided; I'll check the model again tomorrow;
  • the weird thing about CARM and DARM is that at the same time when one of them starts drifting, its I and Q signals begin to be comparable; when the servo is shut off, they resume their normal state;
  • an increase in the excitation gain improves the separation of I and Q and also reduces their variations, but a high peak in the loop due to this might not be a good idea.

 

  10914   Fri Jan 16 18:46:15 2015 KojiUpdateLSCLSC model change implemented

Was the screen modified directly on LSC_OVERVIEW.adl?
Even if so, that's OK. I'll incorporate the change to the screen making script once I'm back.

  10915   Fri Jan 16 20:01:32 2015 JenneUpdateLSCLSC model change implemented

Nope, I used the script.

Yesterday's changes were mostly to the generateLSCscreen/C1LSC_OVERVIEW_INPUT_MATRIX.adl sub-screen.  The UGF servos were added earlier in the week to the LSC screen in the generateLSCscreen/C1LSC_OVERVIEW_SERVOS.adl sub-screen.

  10916   Fri Jan 16 20:37:52 2015 diegoUpdateLSCUGF servo now linear again

I found an error in the model of the UGF servos, I have now corrected it; for future reference, now the division between TEST2 and TEST1 is properly done with complex math: given

TEST1 = a + i b\hspace{.5cm},\hspace{.5cm}}TEST2 = c + id

we have that TEST3:

 

TEST3 = \frac{TEST2}{TEST1} = \left(\frac{ac+bd}{a^2+b^2}\right) + \left(\frac{ad-bc}{a^2+b^2} \right)i

 

TEST3 is the actual signal that is now phase rotated to select only the I signal while rejecting the Q one.

 

All the updates to the model, the screens and the script have been SVNed.

  10917   Sat Jan 17 01:10:36 2015 JenneUpdateLSCSome locking, may need to modify UGF part again

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

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

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

  10923   Tue Jan 20 15:09:01 2015 JenneUpdateLSCLSC model change implemented

 

Quote:

Brain not working anymore now that it's ~4am, but I need to rethink and recheck to make sure that the PD whitening triggering is still okay and working.  Or maybe we can remove it, and just include that in the scripts, as Rana has been suggesting for ages.  Thoughts for tomorrow.

LSC whitening triggering was not working, because of the implementation of the double-rows for the input matrix.  I have modified the c-code that looks at the input matrix and triggers, and decides when to turn on the PD whitening, so that it now works.

  10925   Tue Jan 20 20:03:17 2015 JenneUpdateLSCALS lock not staying?

The Xarm ALS has been a little funky today. 

First, the green and the arm-axis would not stay co-aligned.  I'm not sure which was moving (although neither ITMX nor ETMX seemed to be moving very much according to their oplevs and OSEMs).  I went to the Xend table and jiggled the mounts for the steering optics, in case one was loose or something.  None were.  However, the transmission quit jumping around by a factor of 2 after that.   The beatnote alignment on the PSL table was also bad, so I tweaked that alignment up for the Xarm.  There were some not connected cables and fibers blocking the access to the X beatnote area, so those are up on top of the PSL table.

Anyhow, I haven't locked the individual arms, but I cannot hold the lock with CARM/DARM.  The CARM output keeps hitting the threshold for the locking watchdog, which turns off the lock.  Obviously I could just increase this threshold, but the right thing to do is figure out why the Xarm ALS is so noisy today, and why it wants to output such a large control signal to maintain the lock.

  10926   Tue Jan 20 21:58:04 2015 diegoUpdateLSCSome locking, may need to modify UGF part again

 

Quote:

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

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

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

 

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

 

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

 

  10927   Wed Jan 21 15:27:47 2015 JenneUpdateLSCFixed LSC model bug

This problem with the CARM loop last night was the fault of a bug that I had put into the LSC model last week.  When I gave the input matrix and normalization matrix double rows, I had put the goto tags for the CARM normalization matrix rows backwards.  So, even though I thought I was not normalizing CARM, in fact I was normalizing by POPDC, which was near zero since the PRM was misaligned.

Anyhow, found, fixed, currently locking, and all seems well.

  10929   Thu Jan 22 03:21:24 2015 JenneUpdateLSCLocks with large MICH offsets

[Jenne, Diego, EricQ]

Tonight we worked on the acquisition sequence (including re-re-re-commissioning the UGF servos, hopefully for the last time...) for the PRFPMI with large MICH offsets. 

The procedure is all in the carm_up script, as far as things work.

We had some locklosses, but they were mostly due to non-carefulness on my part during the transitions between error signals, or the UGF servos getting upset because the oscillator peaks had gotten lost in the noise.  The one that I show here is our very last one of the night, where we are hitting the rails for the MICH signal, which is then causing the other loops to have to do weird things to try to compensate, and they lose lock.

Here also is a StripTool shot during that lock stretch.  I was in the middle of increasing the MICH offset to 75% of the fringe.  The yellow trace (called MICH_B_MON) is ASDC/POPDC normalized so that it always goes 0-1.  I was pleased to see that perhaps REFL11I and AS55Q are turning over, although as Q will tell us in a more detailed elog tomorrow, having a large MICH offset does weird things and moves the DARM zero-point.  So, maybe we aren't actually anywhere awesome yet. 

After some MICH offset, the maximum arm power is always going to be about 50, so arm powers of 8 or 10 equates to 100 pm.  We didn't get there tonight while on IR signals.


The locking sequence is now something like this:

  • Lock carm and darm on ALS, find resonances, move to 3 counts (roughly 3nm) offset.
  • Set PRMI up to acquire on REFL33I and ASDC/POPDC at 25% MICH fringe.  (After a while, I assume perhaps because the alignment is no longer tip-top, I have been by-hand reducing the MICH offset from -700counts which is 25% to -200counts, and then immediately putting it back to -700 after the PRMI acquires.)
  • Engage all 4 UGF servos
  • Reduce the CARM offset a bit, to 1.0 count, which gives arm powers of about 0.4 (with 50 being the max possible)
  • Transition CARM from ALS to sqrtInvTrans
  • Transition DARM from ALS to DC trans:  (TRY-TRX)/(TRX+TRY)
  • Reduce the oscillator amplitudes of the UGF servos
  • Reduce the CARM offset to powers of about 1
  • Ramp to 50% MICH fringe

After this, we tried a few times to lower the CARM offset, but kept losing lock, I think because the UGF servos went crazy.  The final lock, shown above, we lost because the MICH output was hitting the rails.

The problem with the MICH servo right now is the low SNR of the POPDC being used to normalize ASDC.  The control output is enormous, even if we have the 400Hz lowpass on.  We need to rethink our MICH servo, starting with a lower UGF, so that we're not injecting all this sensing noise all over the place. 


For tomorrow:

  • Re-look at MICH loop, to prevent sensing noise injection.
  • How does the large MICH offset affect our zero points for CARM and DARM?  Can we stay on DC transmission signals through 30 or 100 pm?
  • What to do next?  One or two of the locklosses were because the CARM detuned double cavity pole wasn't de-Q-ed enough, so still hit 0dB and created an unstable unity gain point.  Can we go to higher MICH offset, maybe 75%? 
  • Still need to figure out where our missing phase is for our LSC loops.  CARM and DARM are short on phase, and we could definitely use some more.  So, I will work on trying to give us filters that don't eat too much phase, but we still need to find that missing ~14 deg. 
  10933   Fri Jan 23 02:11:40 2015 JenneUpdateLSCCARM filters modified slightly

[Jenne, Diego]

One of tonight's goals was to tweak the CARM filters, so that we could engage the lowpass filter, to avoid the detuned double cavity pole resonance disturbing the CARM loop.

I increased the Q of the zeros in the FM3 boost so that it eats fewer than the original 18 degrees of phase at 100 Hz.  We kept losing lock though, so for each lock I backed off on the Q a little bit.  In the end, the filter eats 9 degrees of phase at 100 Hz.  I also moved the lowpass from 700 Hz to 1kHz, although that doesn't change the phase at 100 Hz very much.

We modified the carm_up script re: PRMI locking a little bit.  The PRMI is not so enthusiastic about locking immediately at 25% MICH fringe, so I backed that off.  It now acquires lock at a few percent, and then ramps up the offset.  Also, the MICH FM6 bounce roll filter is now turned on after lock is acquired, effectively giving it an extra second or two of delay beyond the rest of the filters.

We were able several times to get to some MICH offset and turn on the lowpass filter, but starting to reduce the CARM offset makes us lose lock.  I think the problem is that the UGF servo demod phase is changing as we are changing offsets, filters and error signals.  We see that the I-phase is servoed successfully to 0dB, but that the Q-phase is starting to move around by 30 degrees or more.  We either need to monitor this much more closely, and add the changing demod phases to the carm_up script, or we need to go back to the sum-of-squares situation that we had last week.  Note that we saw failures with that method for a completely separate reason:  we were getting too close to the limiters, which cause the UGF servos to glitch and the outputs jump by a significant amount.  So, the issues that we were seeing last week when we had the sum-of-squares were a different thing, that we noticed and understood later.

Anyhow, nothing too exciting and glorious tonight, but progress has been made.

Also, from some Mist simulations that Q did, Diego made a sweet plot that is now posted in the control room, so we can translate arm power to CARM offset, at various MICH offsets. 

We also took some CARM loop measurements with the new filters.  We have a little more phase than we used to, which is nice.  These traces don't have the lowpass engaged, since I was trying to see how far we could get without it.  We lost lock right after the second measurement, but I think that was to do with the UGF servos.

  10938   Fri Jan 23 19:38:02 2015 JenneUpdateLSCcarm_cm_up supports both signs of CARM offset

A small change, but now the carm_up script supports both sides of the CARM offset.  After the arms are locked with ALS it asks for a "+" or a "-", which indicates which sign of digital CARM offset will be added.  In the past, we have been primarily using the "+" sign.
 

  10942   Tue Jan 27 04:11:21 2015 JenneUpdateLSCSmall tweaks to the locking

[Jenne, Diego, EricQ]

We did a series of small things that may have helped with the locking, although we didn't actually get anywhere closer in CARM offset.

  • Removed the demodulation phase from the UGF servos.
    • We don't care about the phase value, just the magnitude.
    • Since we are using these through transitions between error signals, as well as with different filters coming on and off, the demodulation phase isn't constant, so the UGF servo is getting the wrong answer, and was throwing us out of lock.
    • The problems that Rana and I saw last time we had the sum of the sqrt were later discovered to be attributable to losing the peak in the noise, and hitting saturation limiters in the model, so not the fault of the sum of the squares.
    • I don't actually take the square root.  As Koji pointed out, the very next thing that happens to the signal is mag2dB, which is usually 20*log10(mag).  To compensate for the fact that I'm not taking the square root, I just use 10*log10(mag).  This removes one element of non-linearity, and leaves it at about the same number of square-ings as the complex division.
    • The excitation and measurement still happen after the multiplication.
    • The UGF screens will be updated tomorrow to reflect the change.
  • Added the new error signal rows to the LSC model's DAQ list.  So, now DARM_A_ERR and DARM_B_ERR are both acquired (and the same for CARM, MICH and PRCL).  This is to allow us to look at _DQ channels with dataviewer and DTT without having to clear the testpoints all the time.
    • We were running into too many channels being recorded, so we are not keeping the SRCL A & B signals right now.  Also, the CESAR signals that are no longer in use have been removed from the DAQ list.
  • Added a comb to the ASDC and POPDC signals, to remove the 60Hz harmonics from the MICH error signal.
    • The harmonics of the 60Hz line were dominating by more than an order of magnitude the RMS for the MICH control signal.  We couldn't afford too much phase at a few tens of Hz, so we do not notch out the original 60Hz line, although it isn't as big as, say, the 180Hz line.  So, I think that the notches are for the 2nd, 3rd, 4th and 5th order harmonics of 60Hz.  This significantly improved the RMS of the MICH output signal.
  • Lowered the MICH UGF slightly, from 48Hz to 41Hz. 
    • We wanted to go lower, to maybe 30Hz-ish, but we don't have the phase margin.  The roll mode notch is in the way, so we compromised at 41Hz.  With the comb mentioned above, the MICH control signal looks much more reasonable, and we're not injecting oodles of sensing noise into the BS.
    • Together with the comb, this ensures that we are not constantly railing the MICH output limiter, which lost us lock several times.
  • Increased the POPDC analog whitening gain from 0dB to 18dB.  We will certainly saturate POPDC when the carrier is resonant, but we were hoping to improve our SNR in our MICH error signal.  It helped noticeably, although we'll have to think about the fact that if it saturates while we're trying to acquire, the AS/POP composite signal won't be any good, and we'll kick the optics.  Also, we may have to lower the gain again as the carrier comes in to resonance.  Anyhow, something to think about.  Right now the gain is left at 18dB, and the dark offsets are set to match.
  • We may have been using the wrong side of the MICH offset, according to Q's plots.  We determined tonight that we want a (-) in the MICH gain, although the offset values can stay the same.  Even though we tried this, we didn't really get any farther in CARM offset reduction.
  • We took 2 sets of CARM and DARM loops.  They are both at 50% MICH offset, although I don't remember which sign the first one had.  The second one, at arm powers of 1.4, definitely had the new negative MICH gain. 
    • The first loop was taken at 50% MICH offset (don't remember which sign), and arm powers of about 1.15.
    • The second loop was taken at 50% MICH offset with negative gain, and arm powers of about 1.4.
    • While these numbers are not so different, maybe the first one was at roughly 300pm, and the second was at roughly 200pm, the loop shapes change dramatically.
    • The phase goes flat and we lose some of the phase margin.  Also, the magnitude is starting to get wiggly at lower frequencies.
    • See the transfer functions attached below.
  • While we were sitting at about arm powers of 1.4, with the 50% MICH offset with the negative sign in the gain, we set the REFL 11 demod phase.  It was 18.9deg (I don't remember from when), but we set it to 2.9deg to minimize the PRCL actuation in the Q-phase.  Oscillator was at 443Hz, about 10 counts. 
    • The coherence between the sqrtInvTrans signal and REFL11I looked pretty good from a few Hz to a few tens of Hz. 
    • It was late, so we decided to try transitioning over to REFL11I, and failed at the first very baby step.  So.  Ooops.
    • We should look more carefully at the TF between our current CARM signal and REFL11I.
    • We should also seriously consider using a normalized RF signal.  The SNR in the transmission PDs is just fine, although POPDC isn't a perfect choice at such high MICH offsets.
  10944   Tue Jan 27 15:45:26 2015 diegoUpdateLSCSmall tweaks to the locking

The UGF Servo medm page has been updated to reflect the last changes, namely the return of the sum of squares and the disappearance of Test3.

 

  10947   Wed Jan 28 03:01:24 2015 JenneUpdateLSCTransitioned DARM to AS55Q

[Jenne, Diego]

Tonight we were able to transition DARM from DC transmission signals to AS55Q/(TRX+TRY).  That's about as far as we've gotten though.

Here are the details:

  • Set the ASDC->MICH matrix element such that the MICH fringes were 0-1.  For some reason this number seems to change by ~10% or so each night.
  • Followed main carm_cm_up script, although stopped at MICH offset of 25% (mostly because I forgot to let it go to 50% - no fundamental reason)
  • So, MICH was at 25% (with a + for the gain accidentally, even though we decided yesterday that - was better), arm powers were about 1.1 or so.
  • Took transfer functions driving DARM and looking at normalized AS55Q, and driving CARM looking at normalized REFL11I.
    • There is still not a lot of coherence in the CARM->REFL11I case, so we decided to stick with DARM for starters.
    • The TF between DARM and AS55Q looked really nice!
  • Prepared the unused DARM error signal row, including an offset before the blend matrix.
  • Transitioned over to normalized AS55Q.
    • This left the DARM servo filterbank with a zero digital offset.
    • But, the error signal had an offset before it got to the DARM filter bank.
      • This offset does not have any ramping (I don't know how to do that when building a model), so it's not as nice for reducing an offset.
      • Maybe we can, after transitioning to the new signal, move the offset to the DARM servo filterbank?
  • Was reducing the DARM offset so that we were at the true AS55Q zero crossing.
  • Saw that the UGF servo lines were starting to get a bit lost in the noise, so I increased the DARM's amplitude.
    • I don't know if the UGF servo was already too far gone and increasing the SNR couldn't recover it, or if I was driving too hard and directly kicked myself out of lock.  Either way, we lost lock.

The carm_cm_up script now should get all the way to this point by itself, although occasionally the PRMI part will lose lock (but not the arms), so you have to go back to the 3nm CARM offset and relock the central part.  I have written a little "relockPRMI.sh" script that lives in ..../scripts/PRFPMI/ that will take care of this for you.  

We were able to transition DARM to AS55Q a total of 3 or so times tonight.  The first time was with the + MICH gain, and the rest of the times were with - MICH gain.  The carm_up script now asks for a sign for the MICH gain just after asking for a CARM offset sign. 

I think that we understand all of our locklosses from these states.  Twice (including the time described above) the UGF lines got lost in the noise, and the UGF servos went crazy.  Once the PRCL loop rang up, because a filter that wasn't supposed to be on was on.  This was a terrible filter that I had made a long time ago, and was never supposed to be part of the locking sequence, but it was getting turned on by a restore script, and kept eating our phase.  Anyhow, I have deleted this terrible boost filter so it won't happen again (it was called "boost test", which may give you an idea of how non-confident I was in its readiness for prime-time).  The last time of the night I must not have been quite close enough in CARM offset, so we should probably check with a TF before making this last jump.

Diego wrote a nifty burt restoring script that will clear out all the elements of the input matrix and the normalization matrix for a row that you tell it (i.e. DARM_A will clear out all the elements in the first row of those 2 matrices).  This is useful for the switches back and forth between the _A and _B signals, to make sure that everything is in order.  So, I now run those clear scripts, then put in the elements that I want for the next step.  For example, DARM initially locks with ALS using the A row.  Then, DARM transitions to the B row for DC transmission.  Then, I prepare the A row for AS55Q locking, and I don't want any elements accidentally left from the ALS signal.  It lives in ..../scripts/LSC/InputMatrix/

 

Thoughts for tomorrow:

Daytime re-commission the Xarm ASS.

Nighttime try to get back to DARM on AS55Q and push farther forward. 

 

  10949   Wed Jan 28 14:19:02 2015 ranaUpdateLSCTransitioned DARM to AS55Q

Why AS55/(TRX + TRY) instead of just TRX? Isn't (TRX+TRY) controlled by CARM?cool

(question is secretly from Kiwamu)

  10953   Thu Jan 29 04:27:35 2015 ericqUpdateLSCCARM on REFL11

[ericq, Diego]

Tonight, we transitioned CARM from ALS directly to REFL11 I at 25% Mich Offset. yes

We attempted the transition twice, the first time worked, but we lost lock ~5 seconds after full transition due to a sudden ~400Hz ringup (see attached lockloss plot). The second barfed halfway, I think because I forgot to remove the CARM B offset from the first time frown

The key to getting to zero CARM offset with CARM and DARM on ALS is ekeing out every bit of PRMI phase margin that you can. Neither MICH nor PRCL had their RG filters on and I tweaked the MICH LP to attenuate less and give back more phase (the HF still isn't the dominant RMS source.) PRCL had ~60 degrees phase margin at 100Hz UGF, MICH had ~50 deg at 47Hz UGF. The error signals were comparitively very noisy, but we only cared that they held on. Also important was approaching zero slooooooooowly, and having the CARM and DARM UGF servo excitations off, because they made everything go nuts. Diego stewarded the MICH and PRCL excitation amplitudes admirably. 

Oddly, and worringly, the arm powers at zero CARM offset were only around 10-12. Our previous estimations already include the high Xarm loss, so I'm not sure what's going on with this. Maybe we need to measure our recycling gain?

I hooked up the SR785 by the LSC rack to the CM board after the first success. For the second trial, I also took TFs with respect to CM slow, but they looked nowhere near as clean as the normal REFL11 I channel; I didn't really check all the connections. I will be revisiting the whole AO situation soon. 

In any case, I think we're getting close...

  10960   Fri Jan 30 03:12:15 2015 diegoUpdateLSCCARM on REFL11I

[Jenne, Diego]

Tonight we continued following the plan of last night: perform the transition of CARM to REFL11_I while on MICH offset at -25%:

  • we managed to do the transition several times, keeping the UGF servos on for MICH and PRCL but turning off the DARM and CARM ones, because their contribution was rather unimportant and we feared that their excitations could affect negatively the other loops (as loops tend to see each other's excitation lines);
  • we had to tweak the MICH and PRCL UGF servos:
    • the excitation frequency for MICH was lowered to ~41 Hz, while PRCL's one was lowered to ~50 Hz;
    • PRCL's amplitude was lowered to 75 because it was probably too high and it affected the CARM loop, while MICH's one was increased to 300 because during the reduction of the CARM offset it was sinking into the noise; after a few tries we can say they don't need to be tweaked on the fly during the procedure but can be kept fixed from the beginning;
    • after the transition to REFL11_I for CARM, we engaged also its UGF servo, still at the highest frequency of the lot (~115 Hz) and with relatively low amplitude (2), to help keeping the loop stable;
    • as DARM was still on ALS, we didn't engage its UGF servo during or after the transition, but we just hold its output from the initial part of the locking sequence (after we lowered its frequency to 100 Hz;
  • however, at CARM offset 0 our arm power was less that what we had yesterday: we managed to get higher than ~8, but after Koji tweaked the MC alignment we reached ~10; we still don't understand the reason of the big difference with respect to what the simulations show for MICH offset at 25% (arm power ~50);
  • after the CARM transition to REFL11_I we felt things were pretty stable, so we tried to reduce the MICH offset to get us in the ~ -10% range, however we never managed to get past ~ -15% before losing lock, at arm power around 20;
  • we lost lock several times, but for several different reasons (IMC lost lock a couple of times, PRCL noise increased/showed some ringing, MICH railed) but our main concern is with the PRCL loop:
    • we took several measurements of the PRCL loop: the first one seemed pretty good, and it had a bigger phase bubble than usual; however, the subsequent measurements showed some weird shapes we struggle to find a reason for; these measurements were taken at different UGF frequencies, so maybe it is worth looking for some kind of correlation; morever, in the two weird measurements the UGFs are not where they are supposed to be, even if the servo was correctly following the input (or so it seemed); the last measurement was interrupted just before we lost lock because of PRCL itself;
    • we noticed a few times during the night that the PRCL loop noise in the 300-500 Hz range increased suddenly and we saw some ringing; at least a couple of times it was PRCL who threw us out of lock; this frequency range is similar to the 'weird' range we found in our measurements, so we definitely need to keep an eye on PRCL on those frequencies;
  • in conclusion, the farthest we got tonight was CARM on REFL11_I at 0 offset, DARM at 0 offset still on ALS and MICH at ~ 15% offset, arm power ~20.

 

  10962   Sat Jan 31 01:34:12 2015 JenneUpdateLSCNot able to engage AO path

Nothing earth-shattering today.

A few things of note:

  • I checked the coherence (no lock present, just noise) between REFL11_I_IN1 and CM_SLOW_OUT, which are meant to be the same thing when only the REFL1 path is allowed through the CM board.
    • However, at first, there was very little coherence - small band, and only about 0.7 or so.
    • I went inside and jiggled the cables, and also toggled the whitening switches for REFL11 and the CM_SLOW, and after that I had excellent coherence. 
      • I didn't take a coherence spectrum in between those activities, but since the cable connections were all solid, I believe that it may have been a sticky slider -esque problem, and the CM whitening wasn't matched between the analog and digital.
    • I tried two or three times to engage the AO path, but I always lost lock before I was getting any meaningful gain through.
      • I took some TFs remotely with the SR785, but they're totally noise.  I don't even know which sign of the CM board is correct, so no real knkowledge added there, from today.
  • The ~400Hz ringing that we have been seeing, we have been blaming on the PRCL loop.  However, just before my last lockloss I saw gain peaking around 400Hz in the CARM input spectrum. I didn't see if it was also there in the PRCL spectrum.  So, either it is coupling from PRCL to CARM, or CARM itself.  But I think we need to see if we can eek out a little more phase at higher frequencies for both of those loops.  I  just looked, and about 16 seconds before the last lockloss, I see the PRCL loop coupling into the CARM loop.
    • Since yesterday, we have been lowering the PRCL UGF using the servos to be about 70Hz, to give us more gain margin at the high end of the phase bubble, but we still see this ringing. 
  • Two or three times my arm power buildup at 0 CARM offset, 25% MICH offset was at 20 or 21.  Then, a few other times I was only getting about 10 (which is what we have been seeing the last few days.)
    • I'm running the ASS between each lock, although I'm not running it for a full ~2 minutes or so usually. 
    • I think that the reason I was able to get to such high arm powers was excellent alignment, so maybe it's worth sitting and waiting for the ASS to have a full 2 or 3 minutes between locks, even if the ASS error signals look zero-ed out.
    • This is still a factor of 2 lower than we expect for 25% MICH offset, but the whole factor of 5 isn't explained by some mysterious loss.  At least half of it is alignment.
  • The PRCL ASC feedforward still isn't working, but I'd like to try Q's trans qpd ASC soon, with the full lock.  I think the system is ready, but scripts are not, so Q has to be here to run it.

See first plot below for the PRCL->CARM coupling just before lockloss.  The second plot is the corresponding lockloss, where the PRCL loop is starting to see that oscillation again, and it's just barely starting to get into CARM. 

  10965   Mon Feb 2 22:59:49 2015 diegoUpdateLSCCM board input switched to AS55

[Diego, Jenne]

We just changed the input to the CM board from REFL11 to AS55.

 

  10966   Tue Feb 3 04:01:55 2015 diegoUpdateLSCCM servo & AO path status

[Diego, Jenne]

Tonight we worked on the CM board and AO path:

  • at first we changed the REFL1 input to the CM board from REFL11 to AS55, as written in my previous elog; we tried following Koji's procedures from http://nodus.ligo.caltech.edu:8080/40m/9500 but we didn't get any result: we could lock using the regular digital path but no luck at all for the analog path;
  • then we decided to follow the procedure to the letter, using POY11Q as input to the CM board;
    • we still couldn't lock following the Path #2, even after adjusting the gains to match the current configuration for the Yarm filter bank;
    • we had some more success using Path #1, but we had to lower the REFL1 Gain to ~3-4 (from the original 31) because of the different configuration of the Yarm filter bank, in order to have the same sensing in both of them; we managed to acquire lock a few times, it's not super stable but it can keep lock for a while;
    • when we tried to increase the gain of the MC filter bank and the AO Gain, however, we immediately had some gain peaking, and we couldn't go further then 0.15 and 9db respectively. We currently don't have an answer for that.
    • anyhow, we took a few measurements with the SR785:

 

The BLUE plot is at MC Gain = 0.10 and REFL1 Gain = 4dB; the GREEN plot is for MC Gain = 0.10 and REFL1 Gain = 3dB, which seemed a more stable configuration; after this last configuration, we increased the MC Gain to 0.15 and the AO Gain from 8dB to 9dB and took another measurement, the RED plot; this is as far as we got as of now. We also couldn't increase the REFL11 Gain because it made things unstable and more prone to unlock.

So, some little progress on the AO path procedure, but we are very low on our UGF and we have to find a way to increase our gains without breaking the lock and avoiding the gain peaking we have witnessed tonight.

 

Notes:

  • is the REFL1 Gain dB slider supposed to go to negative dBs? During the night we also tried to use negative dBs, but it seemed it wasn't doing anything instead;
  • when we plugged POY11Q to the CM board, we noticed that it wasn't connected to anything at the moment; since we phase rotate POY11, we were assuming that we were using that signal somewhere. We are confused by this...
  • we remind that REFL11 is no more connected to the CM board input, as POY11 is.
  10969   Tue Feb 3 16:36:33 2015 ericqUpdateLSCCM servo & AO path status

I have removed REFLDC and the SR560 offsetter from the CM board IN2. Now, analog AS55 I lives there, for our single arm testing. (Analog I has more of the single arm Y PDH signal in it). REFL11 has been reconnected to IN1. 


With ITMX super misaligned, Diego and I locked the Y-arm with the AO path on AS55, ultimately at 4kHz bandwidth, but with plenty of gain margin. We didn't allocate the gains too intelligently, and had the CM board input gain slider maxed out, but plenty of headroom in the digital and AO sliders, making it inconvenient to up the UGF even more, to engage the super boosts. However, since this is just a test case to make sure we still can AO lock, I'm not too worried about this. 

Since LSC FMs and such had changed around, old recipies didn't neccesarily work 1:1. Diego is writing a script for the current recipe, and will post an elog with the steps. 

Gains and signs are able to be tracked by loop TFs, the real sticking point is a stable crossover. We used the 1.6k:80 hardware filter in the CM board to give the AO Path a 1/f shape in the crossover region, and undid it digitally in the CM_SLOW input FM. However, we do use a 300:80 in the MC2 sus FM to make the digital loop like 1/f^2 around the crossover, once a little bit of AO has come in to pull up the digital loop's phase. We used the CARM filter bank to do this, so I think we should be able to use a similar technique to do it in the PRFPMI case, as long as the coupled cavity pole is around ~100Hz. 

Attached are a few OLTFs from the progression.

  10971   Wed Feb 4 04:51:14 2015 diegoUpdateLSCCARM Transition to REFL11 using CM_SLOW Path

[Diego, Jenne, Eric]

Tonight we kept on following our current strategy for locking the PRFPMI:

  • the first few tries were pretty unsuccessful: the PRMI lock wasn't much stable, and we never managed to reduce CARM offset to zero before losing lock;
  • then we did some usual manteinance: we fixed the X arm green beatnote, fixed the phase tracker and given much attention to ASS alignment, since the X arm wasn't doing great;
  • the last few locks were consintently better: we managed to get to CARM offset zero "easily", but the arm power was not very high (~8);
  • then we tried to transition CARM to REFL11, both with the usual configuration and using CM_SLOW, using REFL11 as input for the Common Mode Board;
    • with the usual configuration, we lost lock right after the transition, because of MICH hitting the rail;
    • we did a very smooth CARM transition directly to REFL11 on the CM_SLOW path; we managed to take a spectrum with the SR785, but we couldn't take any more measurements before losing lock because of some weird glitch, as we can see from the lockloss plot;
  • another thing that helped tonight was changing the ELP of the MICH filter bank: it went from 4th order to 6th order, and from 40 dB suppression to 60 dB suppression;

both of the last two locks, the most stable ones (one transition to usual REFL11 and one transition to "CM_SLOW" REFL11) were acquired actuating on MC2;

 


EDITs by JCD:  At least one of the times that we lost PRMI lock (although kept CARM and DARM lock on ALS), was due to MICH hitting the rail, even after we increased the limiter to 15,000 counts.


 Here is the transfer function between CARM ALS (CARM_IN1) and REFL11 coming through the CM board (CARM_B), just before we transitioned over.  Coherence was taken simultaneously as usual, I just printed it to another sheet.

CARM_3Feb2015_CarmBwasCMslow_CarmAwasLiveALS.pdf

CARM_3Feb2015_CarmBwasCMslow_CarmAwasLiveALS_Coh.pdf


Here is the lockloss plot for the very last lockloss.  This is the time that we were sitting on REFL11 coming through the CM_SLOW path.  A DTT transfer function measurement was in progress (you can see the sine wave in the CARM input and output data), but I think we actually lost lock due to whatever this glitch was near the right side of the plots.  This isn't something that I've seen in our lockloss plots before.  I'm not sure if it's coming from REFL11, or the CM board, or something else.  We know that the CM board gives glitches when we are changing gain settings, but that was not happening at this time.


Q: Here's the SR785 TF of CARM locked through CM board, but still only digital control; nothing exciting. Excitation amplitude was only 1mV, which explains the noisy profile. 

  10972   Wed Feb 4 14:30:05 2015 ericqUpdateLSCASDC Whitening Gain

At the lunch meeting, we were thinking about the exess high frequency content of the MICH control signal, which leads to railing against the FM output limiter and lock loss. I propsed that POPDC sensor/ADC noise was the culprit. 

In short, I was wrong. Just now, I locked the PRMI with a MICH offset as we normally do, and then froze the POPDC output. The MICH spectrum did not change in any noticible way. 

However, increasing the analog ASDC whitening gain showed a direct improvement of the error signal noise floor, and thus a reduction in the control signal spectrum. I.e. we have been suffereing from ASDC ADC noise.

We had previously set the ASDC whitening gain so that half fringe of the PRMI would be well within the ADC range, but since we're actually only ever going to 25%, I feel fine upping this gain. Interestingly, when increasing the whitening gain by 12dB,  the control signal spectrum has fallen by more like 20 dB in the 400Hz-1kHz region, which is great. 

The only potential hurdle I can think of is that when we start reducing the MICH offset at zero CARM offset, we may approach ADC saturation in ASDC before we can hand off to RF signals, in which case we would have to dynamically lower the whitening gain, which introduces offsets, which could get hairy. But, since MICH railing has been directly seen to lead to lock-loss, I'd rather solve that problem first. 

  10973   Wed Feb 4 18:16:44 2015 KojiUpdateLSCData transfer rate of c1lsc reduced from ~4MB/s to ~3MB/s

c1lsc had 60 full-rate (16kS/s) channels to record. This yielded the LSC to FB connection to handle 4MB/s (mega-byte) data rate.
This was almost at the data rate limit of the CDS and we had frequent halt of the diagnostic systems (i.e. DTT and/or dataviewer)

Jenne and I reviewed DAQ channel list and decided to remove some channels.  We also reviewed the recording rate of them
and reduced the rate of some channels. c1lsc model was rebuilt, re-installed, and restarted. FB was also restarted. These are running as they were.
The data rate is now reduyced to ~3MB nominal.


The following is the list of the channels removed from the DQ channels:

AS11_I_ERR
AS11_Q_ERR
AS165_I_ERR
AS165_Q_ERR
POP55_I_ERR
POP55_Q_ERR

The following is the list of the channels with the new recording rate:

TRX_SQRTINV_OUT 2048
TRY_SQRTINV_OUT 2048
DARM_A_ERR 2048
DARM_B_ERR 2048
MICH_A_ERR 2048
MICH_B_ERR 2048
PRCL_A_ERR 2048
PRCL_B_ERR 2048
CARM_A_ERR 2048
CARM_B_ERR 2048

  10979   Thu Feb 5 04:35:14 2015 diegoUpdateLSCCARM Transition to REFL11 using CM_SLOW Path

[Diego, Eric]

Tonight was a sad night... We continued to pursue our strategy, but with very poor results:

  • before doing anything, we made sure we had a good initial configuration: we renormalized the arm powers, retuned the X arm green beatnote, did extensive ASS alignment;
  • since the beginning of the night we faced a very uncooperative PRMI, which caused a huge number of locklosses, often just by itself, without even managing to reduce the MICH offset before reducing the CARM one;
  • we had to reduce the PRCL gain to -0.002 in order to acquire PRMI lock, but keeping it such or restoring it to -0.004 once lock was acquired either didn't improve the PRMI stability at all;
  • we also tweaked a bit the PRCL and MICH UGF servos (namely, their frequencies to ~80 Hz and ~40 Hz respectively) and that seemed to help earlier during the night, but not much longer;
  • we only managed to transition CARM to REFL11 via CM SLOW twice;
    • the first time we lost lock almost immediately, probably because of a non-optimal offset between CARM A and B;
    • the second time we managed to stay there a little longer, but then some spike in the PRCL loop and/or the MICH loop hitting the rails threw us out of lock (see the lockloss plot);
    • both times we transitioned at arm power ~18;
  • during the night we used an increased analog ASDC whitening gain, as from Eric's elog here http://nodus.ligo.caltech.edu:8080/40m/10972 ; even with this fix, though, MICH is still often hitting the rails and causing the lock losses;
  • the conclusion for tonight is that we need to figure what is going on with the PRMI...

 

  10982   Fri Feb 6 03:21:17 2015 diegoUpdateLSCCARM Transition to REFL11 using CM_SLOW Path

[Diego, Jenne]

We kept struggling with the PRMI, although it was a little better than yesterday:

  • we retuned the X Green beatnote;
  • we managed to reach lower CARM offsets than yesterday night, but we still can't keep lock long enough to perform a smooth transition to CM SLOW/REFL11;
  • we tweaked MICH a bit:
    • the ELP in FM8 now is always on, because it seems to help;
    • we tried using a new FM1 1,1:0,0 instead of FM2 1:0 because we felt we needed a little more gain at low frequencies, but unfortunately this didn't change much MICH's behaviour;
    • now, after catching PRMI lock, the MICH limiter is raised to 30k (in the script), as a possible solution for the railing problem; the down/relock scripts take care of resetting it to 10k while not locked/locking;

So, still no exciting news, but PRMI lock seems to be improving a little.

  10987   Sat Feb 7 21:30:45 2015 JenneUpdateLSCPRC aligned

I'm leaving the PRC aligned and locked.  Feel free to unlock it, or do whatever with the IFO.

  10991   Mon Feb 9 17:47:17 2015 diegoUpdateLSCCM servo & AO path status

I wrote the script with the recipe we used, using the Yarm and AS55 on the IN2 of the CM board; however, the steps where the offset should be reduced are not completely deterministic, as we saw that the initial offset (and, therefore, the following ones) could change because of different states we were in. In the script I tried to "servo" the offset using C1:LSC-POY11_I_MON as the reference, but in the comments I wrote the actual values we used during our best test; the main points of the recipe are:

  • misalign the Xarm and the recycling mirrors;
  • setting up CARM_B for POY11 locking and enabling it;
  • setting up CARM_A for CM_SLOW;
  • setting up the CM_SLOW filter bank, with only FM1 and FM4 enabled;
  • setting up the CARM filter bank: FM1 FM2 FM6 triggered, only FM3 and FM5 on; usual CARM gain = 0.006;
  • setting up CARM actuating on MC2;
  • turn off the violin filter FM6 for MC2;
  • setting up the default configuration for the Common Mode Servo and the Mode Cleaner Servo; along with all the initial parameters, here is where the initial offset is set;
  • turn on the CARM output and, then, enable LSC mode;
  • wait until usual POY11 lock is acquired and, a bit later, transition from CARM_B to CARM_A;
  • then, the actual CM_SLOW recipe:
    • CM_AO_GAIN = 6 dB;
    • SUS-MC2_LSC FM6 on (the 300:80 filter);
    • CM_REFL2_GAIN = 18 dB;
    • servo CM_REFL_OFFSET;
    • CM_AO_GAIN = 9 dB;
    • CM_REFL2_GAIN = 21 dB;
    • servo CM_REFL_OFFSET;
    • CM_REFL2_GAIN = 24 dB;
    • servo CM_REFL_OFFSET;
    • CM_REFL2_GAIN = 27 dB;
    • servo CM_REFL_OFFSET;
    • CM_REFL2_GAIN = 31 dB;
    • servo CM_REFL_OFFSET;
    • CM_AO_GAIN = 6 dB;
    • SUS-MC2_LSC FM7 on (the :300 compensating filter);

I tried the procedure and it seems fine, as it did during the tries Q and I made; however, since it touches many things in many places, one should be careful about which state the IFO is into, before trying it.

The script is in scripts/CM/CM_Servo_OneArm_CARM_ON.py and in the SVN.

 

  10992   Tue Feb 10 02:40:54 2015 JenneUpdateLSCSome locking thoughts on PRMI

[EricQ, Jenne]

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

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

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

  10994   Tue Feb 10 03:09:02 2015 ericqUpdateLSCSome locking thoughts on PRMI

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

Things that were a pain:

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

Other stuff:

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

I found the PSL enclosure open (about a feet wide) on the north side this morning. I am assuming that whoever did the X beatnote alignment last night forgot to close the door to the enclosure before locking attempts frown

Quote:

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

Things that were a pain:

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

Other stuff:

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

 

  10998   Wed Feb 11 00:07:54 2015 ranaUpdateLSCLock Loss plot

Here is a lock loss from around 11 PM tonight. Might be due to poor PRC signals.  \oint {\frac{\partial PRCL}{\partial x}}

This is with arm powers of ~6-10. You can see that with such a large MICH offset, POP22 signal has gone done to zero. Perhaps this is why the optical gain for PRCL has also dropped by a factor of 30 crying.

This seems untenable no. We must try this whole thing with less MICH offset so that we can have a reasonable PRCL signal.cool

  10999   Wed Feb 11 02:42:05 2015 JenneUpdateLSCPRC error signal RF spectra

Since we're having trouble keeping the PRC locked as we reduce the CARM offset, and we saw that the POP22 power is significantly lower in the 25% MICH offset case than without a MICH offset, Rana suggested having a look at the RF spectra of the REFL33 photodiode, to see what's going on. 

The Agilent is hooked up to the RF monitor on the REFL33 demod board.  The REFL33 PD has a notch at 11MHz and another at 55MHz, and a peak at 33MHz. 

We took a set of spectra with MICH at 25% offset, and another set with MICH at 15% offset.  Each of these sets has 4 traces, each at a different CARM offset.  Out at high CARM offset, the arm power vs. CARM offset is pretty much independent of MICH offset, so the CARM offsets are roughly the same between the 2 MICH offset plots. 

What we see is that for MICH offset of 25%, the REFL33 signal is getting smaller with smaller CARM offset!!  This means, as Rana mentioned earlier this evening, that there's no way we can hold the PRC locked if we reduce the CARM offset any more. 

However, for the MICH offset 15% case, the REFL 33 signal is getting bigger, which indicates that we should be able to hold the PRC.  We are still losing PRC lock, but perhaps it's back to mundane things like actuator saturation, etc. 

The moral of the story is that the 3f locking seems to not be as good with large MICH offsets.  We need a quick Mist simulation to reproduce the plots below, to make sure this all jives with what we expect from simulation.

For the plots, the blue trace has the true frequency, and each successive trace is offset in frequency by a factor of 1MHz from the last, just so that it's easier to see the individual peak heights.

Here is the plot with MICH at 25% offset:

And here is the plot with MICH at 15% offset:

Note that the analyzer was in "spectrum" mode, so the peak heights are the true rms values.  These spectra are from the monitor point, which is 1/10th the value that is actually used.  So, these peak heights (mVrms level) times 10 is what we're sending into the mixer.  These are pretty reasonable levels, and it's likely that we aren't saturating things in the PD head with these levels. 

The peaks at 100MHz, 130MHz and 170MHz that do not change height with CARM offset or MICH offset, we assume are some electronics noise, and not a true optical signal.

Also, a note to Q, the new netgpib scripts didn't write data in a format that was back-compatible with the old netgpib stuff, so Rana reverted a bunch of things in that directory back to the most recent version that was working with his plotting scripts.  sorry.

 

  11000   Wed Feb 11 03:41:12 2015 KojiUpdateLSCPRC error signal RF spectra

As the measurements have been done under feedback control, the lower RF peak height does not necessary mean
the lower optical gain although it may be the case this time.

These non-33MHz signals are embarassingly high!
We also need to check how these non-primary RF signals may cause spourious contributions in the error signals,
including the other PDs.

  11001   Wed Feb 11 04:08:53 2015 JenneUpdateLSCNew Locking Paradigm?

[Rana, Jenne]

While meditating over what to do about the fact that we can't seem to hold PRMI lock while reducing the CARM offset, we have started to nucleate a different idea for locking

We aren't sure if perhaps there is some obvious flaw (other than it may be tricky to implement) that we're not thinking about, so we invite comments.  I'll make a cartoon and post it tomorrow, but the idea goes like this.....

Can we use ALS to hold both CARM and DARM by actuating on the ETMs, and sit at (nominally) zero offset for all degrees of freedom?  PRMI would need to be stably held with 3f signals throughout this process. 

1) Once we're close to zero offset, we should see some PDH signal in REFL11.  With appropriate triggering (REFLDC goes low, and REFL11I crosses zero), catch the zero crossing of REFL11I, and feed it back to MC2. We may want to use REFL11 normalized by the sum of the arm transmissions to some power (1, 0.5, or somewhere in between may maximize the linear range even more, according to Kiwamu).  The idea (very similar to the philosophy of CESAR) is that we're using ALS to start the stabilization, so that we can catch the REFL11 zero crossing. 

2) Now, the problem with doing the above is that actuating on the mode cleaner length will change the laser frequency.  But, we know how much we are actuating, so we can feed forward the control signal from the REFL11 carm loop to the ALS carm loop.  The goal is to change the laser frequency to lock it to the arms, without affecting the ALS lock.  This is the part where we assume we might be sleepy, and missing out on some obvious reason why this won't work.

3) Once we have CARM doubly locked (ALS pushing on ETMs, REFL11 pushing on MC/laser frequency), we can turn off the ALS system. Once we have the linear REFL11 error signal, we know that we have enough digital gain and bandwidth to hold CARM locked, and we should be able to eek out a slightly higher UGF since there won't be as many digital hops for the error signal to transverse. 

4) The next step is to turn on the high bandwidth common mode servo.  If ALS is still on at this point, it will get drowned out by the high gain CM servo, so it will be effectively off. 

5) Somewhere in here we need to transition DARM to AS55Q.  Probably that can happen after we've turned on the digital REFL11 path, but it can also probably wait until after the CM board is on.

The potential show-stoppers:

Are we double counting frequency cancellation or something somewhere?  Is it actually possible to change the laser frequency without affecting the ALS system?

Can we hold PRMI lock on 3f even at zero CARM offset?  Anecdotally from a few trials in the last hour or so, it seems like coming in from negative carm offset is more successful - we get to slightly higher arm powers before the PRMI loses lock.  We should check if we think this will work in principle and we're just saturating something somewhere, or if 3f can't hold us to zero carm offset no matter what.

A note on technique:  We should be able to get the transfer function between MC2 actuation and ALS frequency by either a direct measurement, or Wiener filtering.  We need this in order to get the frequency subtraction to work in the correct units.

  11003   Wed Feb 11 17:31:11 2015 ericqUpdateLSCRFPD spectra

For future reference, I've taken spectra of our various RFPDs while the PRMI was sideband locked on REFL33, using a 20dB RF coupler at the RF input of the demodulator boards. The 20dB coupling loss has been added back in on the plots. Data files are attached in a zip.

Exceptions: 

  • The REFL165 trace was taken at the input of the amplifier that immediately preceeds the demod board. 
  • The 'POPBB' trace was taken with the coupler at the input of the bias tee, that leads to an amplifier, then splitter, then the 110 and 22 demod boards. 

I also completely removed the cabling for REFLDC -> CM board, since it doesn't look like we plan on using it anytime in the immediate future. 

  11004   Wed Feb 11 18:07:42 2015 ericqUpdateLSCRFPD spectra

After some discussion with Koji, I've asked Steve to order some SBP-30+ bandpass filters as a quick and cheap way to help out REFL33. (Also some SBP-60+ for 55MHz, since we only have 1*fmod and 2*fmod bandpasses here in the lab). 

  11005   Wed Feb 11 18:11:46 2015 KojiSummaryLSC3f modulation cancellation

33MHz sidebands can be elliminated by careful choice of the modulation depths and the relative phase between the modulation signals.
If this condition is realized, the REFL33 signals will have even more immunity to the arm cavity signals because the carrier signal will lose
its counterpart to produce the signal at 33MHz.

Formulation of double phase modulation

m1: modulation depth of the f1 modulation
m2: modulation depth of the f2 (=5xf1) modulation

The electric field of the beam after the EOM

E=E_0 \exp \left[ {\rm i} \Omega t + m_1 \cos \omega t +m_2 \cos 5 \omega t \right ]
\flushleft = {\it E}_0 e^{{\rm i} \Omega t} \\ \times \left[ J_0(m_1) + J_1(m_1) e^{{\rm i} \omega t}- J_1(m_1) e^{-{\rm i} \omega t} + J_2(m_1) e^{{\rm i} 2\omega t}+ J_2(m_1) e^{-{\rm i} 2\omega t} + J_3(m_1) e^{{\rm i} 3\omega t}- J_3(m_1) e^{-{\rm i} 3\omega t} + \cdots \right] \\ \times \left[ J_0(m_2) + J_1(m_2) e^{{\rm i} 5 \omega t}- J_1(m_2) e^{-{\rm i} 5 \omega t} + \cdots \right]
\flushleft = {\it E}_0 e^{{\rm i} \Omega t} \\ \times \left\{ \cdots + \left[ J_3(m_1) J_0(m_2) + J_2(m_1) J_1(m_2) \right] e^{{\rm i} 3 \omega t} - \left[ J_3(m_1) J_0(m_2) + J_2 (m_1) J_1(m_2) \right] e^{-{\rm i} 3 \omega t} + \cdots \right\}

Therefore what we want to realize is the following "extinction" condition
J_3(m_1) J_0(m_2) + J_2(m_1) J_1(m_2) = 0

We are in the small modulation regime. i.e. J0(m) = 1, J1(m) = m/2, J2(m) = m2/8, J3(m) = m3/48
Therefore we can simplify the above exitinction condition as

m_1 + 3 m_2 = 0

m2 < 0 means the start phase of the m2 modulation needs to be 180deg off from the phase of the m1 modulation.

E = E_0 \exp\left\{ {\rm i} [\Omega t + m_1 \cos \omega t + \frac{m_1}{3} \cos (5 \omega t + \pi)] \right \}

Field amplitude m1=0.3, m2=-0.1 m1=0.2, m2=0.2
Carrier 0.975 0.980
1st order sidebands 0.148 9.9e-2
2nd 1.1e-3 4.9e-3
3rd 3.5e-7 6.6e-4
4th 7.4e-3 9.9e-3
5th 4.9e-2 9.9e-2
6th 7.4e-3 9.9e-3
7th 5.6e-4 4.9e-4
8th 1.4e-5 4.1e-5
9th 1.9e-4 5.0e-4
10th 1.2e-3 4.9e-3
11th 1.9e-4 5.0e-4
12th 1.4e-5 2.5e-5
13th 4.7e-7 1.7e-6
14th 3.1e-6 1.7e-5
15th 2.0e-5 1.6e-4

 

  11007   Wed Feb 11 22:13:44 2015 JenneUpdateLSCNew Locking Paradigm - LSC model changes

In order to try out the new locking scheme tonight, I have modified the LSC model.  Screens have not yet been made.

It's a bit of a special case, so you must use the appropriate filter banks:

CARM filter bank should be used for ALS lock.  MC filter bank should be used for the REFL1f signal. 

The output of the MC filter bank is fed to a new filter bank (C1:LSC-MC_CTRL_FF).  The output of this new filter bank is summed with the error point of the CARM filter bank (after the CARM triggered switch).

The MC triggering situation is now a little more sophisticated than it was.  The old trigger is still there (which will be used for something like indicating when the REFL DC has dipped).  That trigger is now AND-ed with a new zero crossing trigger, to make the final trigger decision.  For the zero crossing triggering, there is a small matrix (C1:LSC-ZERO_CROSS_MTRX) to choose what REFL 1f signal you'd like to use (in order, REFL11I, REFL11Q, REFL55I, REFL55Q).  The absolute value of this is compared to a threshold, which is set with the epics value C1:LSC-ZERO_CROSS_THRESH.  So, if the absolute value of your chosen RF signal is lower than the threshold, this outputs a 1, which is AND-ed by the usual schmidt trigger. 

At this moment, the input and output switches of the new filter bank are off, and the gain is set to zero.  Also, the zero crossing selection matrix is all zeros, and the threshold is set to 1e9, so it is always triggered, which means that effectively MC filter bank just has it's usual, old triggering situation.

  11008   Thu Feb 12 01:00:18 2015 ranaUpdateLSCRFPD spectra

The nonlinearity in the LSC detection chain (cf T050268) comes from the photodetector and not the demod board. The demod board has low pass or band pass filters which Suresh installed a long time ago (we should check out what's in REFL33 demod board). 

Inside the photodetector the nonlinearity comes about because of photodiode bias modulation (aka the Grote effect) and slew rate limited distortion in the MAX4107 preamp.

  11009   Thu Feb 12 01:43:09 2015 ranaUpdateLSCNew Locking Paradigm - LSC model changes

With the Y Arm locked, we checked that we indeed can get loop decoupling using this technique.

The guess filter that we plugged in is a complex pole pair at 1 Hz. We guessed that the DC gain should be ~4.5 nm count. We then converted this number into Hz and then into deg(?) using some of Jenne's secret numbers. Then after measuring, we had to increase this number by 14.3 dB to an overall filter module gain of +9.3.

The RED trace is the usual 'open loop gain' measurement we make, but this time just on the LSC-MC path (which is the POY11_I -> ETMY path).

The BLUE trace is the TF between the ALS-Y phase tracker output and the FF cancellation signal. We want this to be equal ideally.

The GREEN trace is after the summing point of the ALS and the FF. So this would go to zero when the cancellation is perfect.

So, not bad for a first try. Looks like its good at DC and worse near the red loop UGF. It doesn't change much if I turn off the ALS loop (which I was running with ~10-15x lower than nominal gain just to keep it out of the picture). We need Jenne to think about the loop algebra a little more and give us our next filter shape iteration and then we should be good.

  11010   Thu Feb 12 03:43:54 2015 ericqUpdateLSC3F PRMI at zero ALS CARM

I have been able to recover the ability to sit at zero CARM offset while the PRMI is locked on RELF33 and CARM/DARM are on ALS, effectively indefinitely. However, I feel like the transmon QPDs are not behaving ideally, because the reported arm powers freqently go negative as the interferometer is "buzzing" through resonance, so I'm not sure how useful they'll be as normalizing signals for REFL11. I tried tweaking the DARM offset to help the buildup, since ALS is only roughly centered on zero for both CARM and DARM, but didn't have much luck.

Example:

Turning off the whitening on the QPD segments seems to make everything saturate, so some thinking with daytime brain is in order.


How I got there:

It turns out triggering is more important than the phase margin story I had been telling myself. Also, I lost a lot of time to needing demod angle change in REFL33. Maybe I somehow caused this when I was all up on the LSC rack today?

We have previously put TRX and TRY triggering elements into the PRCL and MICH rows, to guard against temporary POP22 dips, because if arm powers are greater than 1, power recylcing is happening, so we should keep the loops engaged. However, since TRX and TRY are going negative when we buzz back and forth through the resonsnace, the trigger row sums to a negative value, and the PRMI loops give up. 

Instead, we can used the fortuitously unwhitened POPDC, which can serve the same function, and does not have the tendancy to go negative. Once I enabled this, I was able to just sit there as the IFO angrily buzzed at me. 

Here are my PRMI settings

REFL33 - Rotation 140.2 Degrees, -89.794 measured diff

PRCL = 1 x REFL33 I; G = -0.03; Acquire FMs 4,5; Trigger FMs 2, 9; Limit: 15k ; Acutate 1 x PRM

MICH = 1 x REFL33 Q, G= 3.0, Acquire FMs 4,5,8; Trigger FM 2, 3; Limit: 30k; Actuate -0.2625 x PRM + 0.5 x BS

Triggers = 1 x POP22 I + 0.1 * POPDC, 50 up 5 down


Just for kicks, here's a video of the buzzing as experienced in the control room

  11011   Thu Feb 12 11:14:29 2015 JenneUpdateLSCNew Locking Paradigm - Loop-gebra

I have calculated the response of this new 2.5 loop system.

The first attachment is my block diagram of the system.  In the bottom left corner are the one-hop responses from each green-colored point to the next.  I use the same matrix formalism that we use for Optickle, which Rana described in the loop-ology context in http://nodus.ligo.caltech.edu:8080/40m/10899

In the bottom right corner is the closed loop response of the whole system.

 

Also attached is a zipped version of the mathematica notebook used to do the calculation.

EDIT, JCD, 17Feb2015:  Updated loop diagram and calculation:  http://131.215.115.52:8080/40m/11043

  11012   Thu Feb 12 11:59:58 2015 KojiUpdateLSCNew Locking Paradigm - Loop-gebra

The goals are:

- When the REFL path is dead (e.g. S_REFL = 0), the system goes back to the ordinary ALS loop. => True (Good)

- When the REFL path is working, the system becomes insensityve to the ALS loop
(i.e. The ALS loop is inactivated without turning off the loop.) => True when (...) = 0

Are they correct?

 

Then I just repeat the same question as yesterday:

S is a constant, and Ps are cavity poles. So,  approximately to say, (...) = 0 is realized by making D = 1/G_REFL.
In fact, if we tap the D-path before the G_REFL, we remove this G_REFL from (...). (=simpler)
But then, this means that the method is rather cancellation between the error signals than
cancellation between the actuation. Is this intuitively reasonable? Or my goal above is wrong?

ELOG V3.1.3-