I have added another block to the LSC screen (and made the corresponding sub-screen) to expose the analog settings for the DC photodiodes. 

Note that we have 2 open channels there, which are still called something like "PD2" and "PD3" from olden times.

If we ever chose to use those, we will probably want to change their names, in /cvs/cds/caltech/target/c1iscaux2/LSC_aux2.db and /cvs/cds/caltech/target/c1iscaux/LSC_aux.db

[Jenne, EricQ, Rana]

Tonight we started prepping for an attempt at variable finesse locking. 

The idea is to put in a MICH offset and hold the lock with ASDC/POPDC (so that the offset can be larger than if we were just using RF signals).  This reduces the PRC buildup, which reduces / removes the double cavity resonance problems while reducing the CARM offset. 

• So.  Today, I pulled out the POP22 razor blade so that we can use the Thorlabs PD as POPDC, without the yaw coupling.  Our other option is to use the POP QPD SUM, but that would require some model changes and more importantly it's not a particularly low noise readout path.

• We re-set the analog whitening gains for ASDC and POPDC.
  • For ASDC, we want the half-fringe in the PRMI case to be not saturating.  We chose 18dB (it had been the default 0dB).
  • For POPDC, Rana and I saw that it was saturating all the time with the 33dB that it had when the carrier became resonant.  This was never really a problem in the past, but if we use it for normalization, we get glitches that knock us out of lock every time POPDC saturated.  So, now POPDC is at 0dB.  It still occasionally saturates when the PRMI is flashing, but we can't get lower than 0dB without going and putting an ND filter on the PD.
• We turned off the analog whitening filters and digital unwhitening for both ASDC and POPDC.  We can consider turning them back on later after we have acquired lock if we need them, but we need them off for acquisition.
• Locked MICH with ASDC/POPDC.  Good.  Stays locked even if PRM is flashing.
• Locked PRMI with PRCL on REFL33I and MICH on ASDC/POPDC.
• Locked arms, held off resonance with ALS, lock MICH with ASDC/POPDC. 
• Failed to lock PRMI with arms held off resonance, using the new scheme (no transition, trying to directly acquire)
• Locked PRMI on REFL33 I&Q with the arms held off resonance, and tried to transition MICH over to ASDC/POPDC, failed.
• Confusion about the relative phase between REFL33Q and ASDC.  It looks like it is ~45deg at 100 Hz, or ~90 deg at 375 Hz.  Why isn't it 0 or 180?
• Went back to PRMI-only, tried to map out fringe by changing MICH offset (tried while MICH was on both REFL33 and ASDC/POPDC).  Not really sure where we are on the fringe.

MICH locked on ASDC normalized by POPDC, PRM and ETMs (and SRM) all misaligned.

MICH offset of -20

MICH input = -0.04*ASDC normalized by 0.1*POPDC.

MICH gain = +5

MICH always triggered on (no triggering for DoF), but FM8 (CLP400) triggered to come on after lock (didn't write down the values).

PRMI locked with MICH on ASDC normalized by POPDC, PRCL on REFL33I, ETMs and SRM misaligned.

MICH offset of -10

MICH input = -0.04*ASDC normalized by 0.1*POPDC.

PRCL input = 1*REFL33I

MICH gain = +5

PRCL gain = -0.4 (factor ten times the regular value)

MICH always on, PRCL triggered on POP22.  MICH FM8 and PRCL FM1,2,6,9 triggered on.

Gives POPDC of about 20 counts, POP22 of about 12 counts, ASDC of about 500 counts.

Arms held at 3nm, MICH locked on ASDC/POPDC, PRM and SRM misaligned.

MICH offset of -10

MICH input = -0.04*ASDC normalized by 0.1*POPDC.

MICH gain = +5

MICH always on, PRCL triggered on POP22.  MICH FM8 and PRCL FM1,2,6,9 triggered on.

Arms held at 3nm, attempt at PRMI lock with MICH on ASDC/POPDC.

Failed.  Tried mostly same MICH gains as arms+mich, and PRCL at 10* normal gain.

Arms held at 3nm, PRMI locked with REFL 33 I&Q, attempt at transition to MICH on ASDC/POPDC.

Failed.  At first, I was putting in the TF line at ~375Hz, but we looked at the full transfer function between 100Hz and 1kHz, and there was a weird dip near 300Hz from PRCL-MICH loop coupling.  Here we were seeing that the phase between REFL33Q and ASDC was ~90 degrees.  What?

Tried putting the TF line at ~100 Hz (since MICH UGF is in the few tens of Hz anyway, so 100 is still above that), but still get weird relative phase.  Here it seems to be about 45 degrees when I inject a single line, although it didn't seem like a weird phase when we did the full swept sine earlier.  Maybe I was just not doing something right at that point??

Anyhow, no matter what values I tried to put into the input matrix (starting with REFL33I&Q, trying to get MICH to ASDC/POPDC), I kept losing lock.  This included trying to ramp up the MICH offset simultaneously with the matrix changing, which was meant to help with the PRCL gain change.  Q has since given us MICH and PRCL UGF servos.

Tomorrow:

• Why is there some weirdo phase between REFL33Q and ASDC at 100Hz?  Was I just being a spaz?
• With PRMI-only, figure out how to transition from REFL33 I&Q over to MICH on ASDC/POPDC.
• Then hold the arms off resonance, and do the same transition.  (First make sure we're at a good place on the fringe)
• Lower the CARM and DARM offsets, transition them to RF, engage CARM AO path.
• Reduce MICH offset, transition to RF.
• Celebrate (maybe).

A few hours ago I tweaked up the alignment to the PMC.  It was really bad in pitch, and the transmission was down to about 0.711.

In order to know where we should try to make the transition from REFL##Q to ASDC for MICH, I did a quick Optickle simulation to see what the error signals will look like.

The idea is to try to lock the PRMI on a single REFL diode (ex. REFL33 I&Q) with some MICH offset, and then transition over to ASDC.  As soon as we have completed the transition, we can engage the normalization matrix to normalize ASDC by POPDC, and also increase the MICH offset if we want.  Unfortunately, we do not as yet have the ability in our model to independently normalize different error signals, and then blend them, so we have to turn on the normalization after we've transitioned.

Here is the situation for PRMI-only:

You can see that REFL33Q has a slightly wider range than REFL165Q.  It seems like we can perhaps try to make the transition around -15nm or so.  Note that the error signals are not quite symmetric about 0nm, so we can use that to help determine what + and - mean.  We expect that we need to add about 1nm offset to REFL33Q to get a true minimum in ASDC, so the sign of the digital offset that we need will tell us if there is a sign flip or not between the digital offset and this x-axis. 

After we get this to work (hopefully in the next hour or so....), we will want to try the same thing with the arms held off resonance. 

Usually we lock the PRMI at an offset of about 3nm:

However we could do it lower, perhaps around 1nm (which is where we currently are doing our CARM/DARM ALS->IR signals transitions):

At some point, we will arrive at 0nm CARM offset, when we'll want to transition back to RF signals (although probably we could jump straight to a 1f signal, not plotted):

The moral of the story here is that I'm not sure how we were ever successfully locking MICH on REFL165Q, unless my phase-setting in Optickle is way off.  Certainly it looks like we should be sticking with REFL33 for PRFPMI.  Also, since we have an offset in REFL33Q anyway (which we have seen and have commented on before), at 3nm CARM offset it looks like we could try to just do the jump without any extra digital offset.  Here's a zoom of the 3nm situation:

[Jenne, Diego, EricQ]

Hopefully there will be more later, but Chiara just went down (network? other?  Q is in there right now looking at it), so this is a so-far-tonight elog.

We have successfully transitioned MICH over from REFL33Q to ASDC in both the PRMI and PRFPMI configurations.  Next up is to start reducing the CARM offset.

Resetting the REFL demod phases

I have been unable to lock the PRMI for more than teeny blips since Thursday.  So, tonight I finally got it to lock with MICH on AS55Q and PRCL on REFL33I, and used that to set the demod phases. 

Setting the demod phases, I used an oscillation of 100 cts to PRM, at 400.123 Hz.

REFL 33 demod phase started at 148deg, now 133.2deg.

REFL165 phase started at -105.53, now -172.

No signal in REFL55????  Time series and spectra both look just like noise.  Need to check alignment of beam on PD, or if cables unplugged!!

REFL11 phase started at 16.75, now 18.9deg.

Was then able to lock on REFL 33 I&Q, like normal.

Transitioning PRMI from REFL33Q to ASDC

With the PRMI locked on REFL33 I&Q, I found that a MICH offset of -5 counts gives a minimum in ASDC.  From my earlier elog this evening (http://nodus.ligo.caltech.edu:8080/40m/10887), I expect the minimum to be at +1.4nm.  This is only one point though, so I don't know the calibration of the MICH offset yet (we should get this calib during the day by looking at MICH-only).  Anyhow, this informed which side was positive and negative relative to my Optickle plots, so I know that I wanted positive offset in the MICH servo.

I was able to comfortably hold lock at +20 counts.  Looking at a calibration line at 143.125 Hz, I determined that I wanted the matrix element for ASDC to be -0.05.  After I made that transition using ezcastep, I put the POPDC normalization in.  At the time, POPDC was about 151counts, so I put 1/151 in the POPDC->Mich matrix element.

So, here were the final lock parameters.  Note that in PRMI-only, you can acquire lock like this, and with a variety of MICH offsets:

Locking PRMI part of PRFPMI

Since the PRMI has been fussy, I'm including a brief note on the PRMI settings when the arms are held with ALS off by roughly 3nm.  To get to this point, we just ran the usual carm_cm_up script, and didn't let it run anymore when it asked for confirmation that PRMI was locked.

With MICH offset of -30 counts, AS port is pretty bright.  ASDC dark offset is set to -475.4 by the LSCoffsets script. with MICH offset = 0, ASDC_OUT is around 300counts.  But, with MICH offset = -30, ASDC_OUT is about 525 counts.  So, I put that 525 counts into the ASDC filterbank offset (so it is now the dark offset + this extra offset), so the ASDC offset is currently around -1,000.  This makes the ASDC signal roughly zero when I am ready to transition MICH over to it.  In principle I should probably set it so the average is the same as the MICH offset, but the noise is so high relative to that offset, that it doesn't matter.

After this, we engaged the CARM and DARM UGF servos.  MICH was gain peaking, so I think we might want to turn that one on too, rather than my by-hand turning down the gain.

The transition has been successful 4 or 5 times with the arms held off resonance at 3nm.  Once, we reduced the CARM offset as low as 1.7 (and had to lower the MICH gain to 1.5), but we were still hearing a woomp-woomp sound.  Not sure what that was from.  At this point, Chiara died, so we lost lock.  After that, we re-acquired lock a few more times, but MC keeps losing it.  We are still able to make the MICH to ASDC transition though, which is good.

The transition won't work if the PRCL UGF servo is not on.  The gain multiplier goes from about 1.1 up to 2.4, so the PRCL gain is certainly changing through the transition.

Diego has written up scripts for the individual UGF servos (look for an elog from him separately), so now the carm_cm_up script goes as far as locking the PRMI on REFL33 I&Q, and then it starts to transition.  PRCL UGF is engaged, MICH offset is set to -30 counts, MICH is transitioned to ASDC, POP normalization engaged, CARM UGF servo turned on, and DARM UGF servo turned on.  There are "read"s in the script before each step, so you can stop whenever you like.

Here's the final configuration for the PRFPMI while the arms are held at 3nm, with MICH on ASDC (so after the transition):

The transition for MICH to ASDC has been successful with the arms held off resonance several times tonight. It's all part of the carm_cm_up script now. I think that if we hadn't lost about an hour of time and our momentum, we would have gotten farther.  I have high hopes for tomorrow night!

I'm super excited about this new frequency readback, but I'm not sure that it's reliable yet.  Without touching any settings, the readback is currently saying 78.6MHz, and is changing slightly (as is the FSS Slow Temp), so something is working.  However, the beatnote as measured on the spectrum analyzer is 158.2MHz.  So, either the calibration or the tracking or something isn't quite finished being tuned yet.

It's going to be super awesome when we have this though!!

[Jenne, Rana]

We tried locking with the variable finesse MICH offset technique again today. 

A daytime task tomorrow will be to figure out where we are in MICH and CARM offset spaces.  This will require some thinking, and perhaps some modelling.

We were using the UGF servos and checking out their step resonses, and had the realization that we don't want the gain multiplication to happen before the offsets are applied, in the case of MICH and CARM.  Otherwise, as the UGF servo adjusts the gain, the offset is changed.  I think this is what ChrisW and I saw earlier on in the evening, when it seemed like the CARM offset spontaneously zoomed toward zero even though I didn't think I was touching any buttons or parameters.  Anyhow, we no longer used the MICH and CARM UGF servos for the rest of the night.  We need to think about where we want the offset to happen, and where we want the UGF servo multiplication to happen (maybe at the control point, with a very low bandwidth?) such that this is not an issue.

Also, I'm no longer sure that the sqrt(I^2 + Q^2) instead of the usual demodulation is going to work for the UGF servos (Q made this change the other day, after we had talked about it).  When the numbers going into the I and Q servo banks are small (around 1e-5), the total UGF servo gets the answer wrong by a factor of 10 or so.  If I made the "sin gain" and "cos gain" 1000 instead of the usual 1, the numbers were of the order 1e-2, and the servo worked like normal.  So, I think we were perhaps running into some kind of numerical error somehow.  We first noticed this when we lowered the DARM excitation by a factor of 10, and the servo no longer functioned.  We should take out this non-linear math and go back to linear math tomorrow.

During the evening tomorrow, we should try locking the PRMI with a large MICH offset, and then leaving CARM and DARM on ALS, and seeing how far we can get.  Is it possible to just jump over to RF signals, since we won't have to worry about the detuned cavity pole?

Tonight, the locking procedure was the same as usual, but stopping the carm_up script before it starts to lower the CARM offset at all.  Only difference was that MICH triggered FMs were 2,3,7 rather than the usual 2,6,8. 

So, assuming you have the IFO with CARM and DARM on ALS held at +3 CARM offset counts (which we think is about 3nm), and the PRMI is locked on REFL33I&Q with no offsets, here's what we did:

• PRCL UGF servo on
• MICH offset goes to -20
• MICH transitions to ASDC (0.27*ASDC, then normalize by POPDC)
• DARM UGF servo on
• CARM offset to 1 (arms about 0.25)
• CARM transition to SqrtInvTrans
• Lower CARM gain to 4
• CARM offset to 0.6 (arms about 1)
• DARM transition to DC transmission
• Increase MICH offset to about -650 or -670
• Lower CARM offset, see what happens

Something else to think about:  Should we normalize our DC transmission signals by POPDC, so that the arm powers will change when we change the MICH offset (for a constant CARM offset)?

The best we got was holding for a few minutes at arm powers of 7.5, but since the MICH offset was large and the power recycling was low, this was perhaps pretty far.  This is why we need some calibration action.

Also, earlier today I copied the CARM and DARM "slide" filter module screens so that we have the same thing for MICH.  Now all 3 of these degrees of freedom have slider versions of the filter module screens, which are called from the ctrl_compact screen.

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

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?

I have installed kerberos on Rossa, so that I don't have to type my name and password every time I do an svn checkin, since I'm making some modifications and want to be sure that everything is checked in before and afterwards. 

I ran sudo apt-get install krb5-user.  I didn't put in a default_realm when it prompted me to during install, so I went into the /etc/krb5.conf file and changed the default_realm line to read default_realm = LIGO.ORG. 

Now we can use kinit, but we must (as usual) remember to kdestroy our credentials when we're done.

As a reminder, to use:

> kinit albert.einstein

Password for albert.einstein@LIGO.ORG: (type your pw here)

When you're finished, run

> kdestroy

The end.

Good call.  I added a line ticket_lifetime = 3600, which should make it destroy the credentials after an hour.

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.

Have we been running the PMC autolocker lately?  I can't remember, and I also can't find where it might be running.  It's not on megatron, either in the crontab or Q's new /etc/init place.  It's also not on op340m. 

Anyhow, what prompted this was that the PMC transmission has been incredibly fuzzy today.  On the StripTool it looks like it was fine until about -7 hours ago, when it lost lock.  Then Diego relocked it around -3 hours ago, and it's been fuzzy ever since. It was unlocked again for about 15 minutes about 45 minutes ago, and when I relocked it, it was even more fuzzy.

The FSS slow is almost exactly zero, the PMC's PZT is not at the edge of the range, the FSS PC drive RMS has been both high and low, and the PMC fuzz level has just been consistently high.  I was checking the parameters in the PMC phase shifter screen, and looked up the autolocker to see what the nominial values are supposed to be. 

For the RFADJ value, the autolocker sets it to 2.0, and after it locks increases it up to 4.5.  I found the value at 2.0, and the autolocker isn't running, which made me wonder if the autolocker died sometime after it set the value low, but before it could detect lock and reset the value to high.  (Actually, after lock it sets the value to whatever is in the channel C1:PSL-STAT_PMC_NOM_RF_ADJ, which is 4.5).

Anyhow, I manually set the RFADJ value to 4.5, and the PMC transmission immediately improved. 

EDIT, 8pm, JCD:  Rana reminded me that he attached a screenshot back on 30Dec2014 (http://nodus.ligo.caltech.edu:8080/40m/10849), which I had ignored earlier because the parameters weren't written in text.  My bad.  Anyhow, after the New Year's tune-up, the RFADJ should be 6.0.  I have set it so, and also changed the C1:PSL-STAT_PMC_NOM_RF_ADJ chan to be 6.0.

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.

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. 

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.

I made little scripts to go with the sus driftmon buttons, that will servo the alignment sliders until the susyaw and suspit values match the references on the driftmon screen. 

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.

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.

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

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

So, I neglected to elog this yesterday, but yesterday we had one of those EPICS freezes that only affects slow channels that come from the fast computers.  It lasted for about 5 minutes.

Right now, we're in the middle of another - it's been about 7 minutes so far. 

Why are these happening again?  I thought we had fixed whatever was the issue.

EDIT:  And, it's over after a total of about 8 minutes.

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.
 

I have just put the seismometers back into their nominal positions, on the concreted slabs.  The T-240 is in the vertex, and the 2 Guralps are at the end stations.

The vertex location doesn't have a spaghetti pot right now.  There is an aluminum support for cable trays that is welded to the supports under the beam tube that is in the way.  The pot looks like it will fit barely, if it were slid totally horizontally into place.  However we can't do that with the seismometer in place.  I'll chat with Steve this afternoon about our options. 

Since I don't know that we are planning on ever putting a cable tray on the inside of the beamtube, perhaps we can cut ~6 inches of this piece away. 

I had a look at the OAF model today. 

Somehow, the screens that we had weren't matching up with the model.  It was as if the screens were a few versions old.  Anyhow, I found the correct screens in /userapps/oaf/common/medm, and copied them into the proper place for us, /userapps/isc/c1/medm/c1oaf.  Now the screens seem all good.

I also added 2 PCIE links between the OAF and the SUS models.  I want to be able to send signals to the PRM's pitch and yaw.  I compiled and restarted both the oaf model and the sus model.

The OAF model isn't running right now (it's got the NO SYNC error), but since it's not something that we need for tonight, I'll fix it in the morning.

My thought for trying out the OAF is to look at the coherence between seismic motion and the POP DC QPD when the PRMI is locked (no arms).  I assume that the PRM is already handled in terms of angular damping (local and oplev), so the motion will be primarily from the folding mirrors.  Then, if I can feedforward the seismometer signal to the PRM to compensate for the folding mirrors' motion, I can use the DC QPD as a monitor to make sure it's working when we're PRMI-only locked, or at low recycling gain with the arms.  But, since I'm not actually using the QPD signal, this will be independent of the arm power increase, so should just keep working.

Anyhow, that's what my game plan is tomorrow for FF.  Right now the T-240 is settling out from its move today, and the auto-zero after the move.

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

PRMI is locked on sideband, starting ~4 minutes ago, to collect ASC/seismic data for feedforward.

Welcome to your new abode, Donatella!

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

[Aside - How do you rotate plots in the new elog?  It's showing them correctly in the attachments list below the entry, but not in the body of the log :( ]

I tried a round of PRCL ASC Wiener filtering today, but something wasn't right.  I was able to either make the cavity motion worse, or completely throw the cavity out of lock.  Making it less noisy didn't happen.

I took only 9 minutes of data the other day, since the PRMI didn't want to stay locked while it was daytime.  So, this wasn't a whole lot to train on.  But, even so, I designed some Wiener filters.  The plots with the designs show the calculated Wiener filter ("Wiener") and the result from vectfit ("Fit"). Below the bode plot is the coherence between that witness (seismometer direction) and the degree of freedom (QPD channel).  The fits were weighted by the choherence, so you can see that in the areas where the coherence was good, the fit was good.  Elsewhere, it's not so great.

Using these filters, and assuming a Cheby1 2nd order lowpass filter at 30Hz, I predicted the following residuals:

After discovering that these filters didn't work, I went rogue and also put in a high pass filter at 0.1 Hz, but that didn't really change anything.

Here is a plot of what happened in Yaw.  The Wiener filters' gains were all 0.3 here, which made the cavity motion larger, but not so large that it lost lock.  The filters ought to have gains of 1 - the Wiener calculation should figure out the gains appropriately, if I've given it enough information.  Here, as in the prediction plots above, red is the reference with the Wiener off, and black is with the Wiener filters on.  Black is supposed to be below red, if the filters are working.  Blue is the estimate of the angular motion that is being fed forward to the PRM, and you can see that at least the general shape is correct.  I do need to figure out what the resonance in the blue trace is from - it's at the same frequency as a peak in the T-240's spectrum (that I didn't save).  I suspect the cable might be touching the spaghetti pot on the inside, and making a mechanical short to pot vibrations.

Anyhow, more work to be done.  I left the PRMI locked for a while this afternoon, starting at 5:15ish, so I'll see tomorrow how long of a lock stretch I was able to capture for training. 

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. 

After aligning the PRC, I centered the POP QPD.

Today (after centering the POP QPD), I measured the PRM to POP QPD transfer functions.  I am suspicious that this was part of my problem last week.  Since most of the angular noise is coming from the folding mirrors, but I can't actuate on them, I need to know (rather, the Wiener calculator needs to know) how actuating on the PRM will affect the spot at the POP QPD.

For the plots below, I have cut out any data points that have coherence less than 0.95. I may want to go back and fill in a little bit some of the areas (particularly around 3Hz) that I had trouble getting coherence in.

Using these to prefilter my witness data, I am failing to calculate a Wiener filter.  I have tried the Levinson algorithm, as well as brute-forcing it, but I'm too close to singular for either to work.  I am able to calculate a set of Wiener filters without the prefiltering, or with a dummy very simple prefilter, so it's not inherently in the calculators.  Separately, I can plot my vectfit-ed actuator TFs, and I can convert them to a discrete fiilter with the bilinear transform, and then use sosfilt to filter some white noise data, which comes out with the shape I expect.  So.  It's not inherently the filters either.  More work to do, when it's not 4am.

Here are the measured actuator transfer functions.  They were measured as usual with DTT, but since the measurement kept getting interrupted (MC unlock, or I wanted to add more integrations or more cycles), these are several different DTT files stitched together.  In both cases I am acuating PRM's ASC[pit, yaw] EXC point, and looking at the POP QPD.

I opened up the spaghetti pot over the vertex seismometer, and taped the cable to the slab.  The way the cable is coiled, it was touching the underside of the seismometer.  Now the only connection is at the cable connector.  There is a ~few inch bit of cable, then it's taped down. 

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

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

I discovered that somehow my Wiener filters that show up in Foton are not the same as what I have in Matlab-land. 

I have plotted each of my 3 filters that I'm working with right now (T-240 X, Y and Z for PRCL Pitch) at several stages in the filter creation process.  Each plot has:

• Blue trace is the Wiener filter that I want, after the vectfit process.
• Green trace is the frequency response of the SOS filters that are created by autoquack (really, quack_to_rule_them_all, which is called by autoquack).  The only thing that happens in matlab after this is formatting the coefficients into a string for writing to foton.
• Red trace is the exported text file from foton.

It's not just a DC gain issue - there's a frequency dependent difference between these filters.  Why?? 

It's not frequency warping from changing between analog and digital filters.  The sample rate for the OAF model is 2048Hz, so the effect is small down at low frequencies.  Also, the green trace is already discretized, so if it were freq warping, we'd see it in the green as well as red, which clearly we don't.

Has anyone seen this before?  I'm emailing my seismic friends who deal in quack more than I do (BLantz and JKissel, in particular) to see if they have any thoughts.

Also, while I'm asking questions, can autoquack clear filters?  Right now I'm overwriting old filters with zpk([],[],1)'s, which isn't quite the same.  (I need this because the Wiener code needs more than one filter module to fit all of the poles I need, and it decides for itself how many FMs it needs by comparing the length of the poles vector with 20.  If one iteration needs 4 filter modules, but the next iteration only wants 3, I don't want to leave in a bogus 4th filter. 

Here are the plots:

(The giant peak at ~35Hz in the Z-axis fiilter is what tipped me off that something funny was going on)

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.

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

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.

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

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

Okay, Koji and I talked (after he talked to Rana), and I re-looked at the original cartoon from when Rana and I were thinking about this the other day.

The original idea was to be able to actuate on the MC frequency (using REFL as the sensor), without affecting the ALS loop.  Since actuating on the MC will move the PSL frequency around, we need to tell the ALS error signal how much the PSL moved in order to subtract away this effect. (In reality, it doesn't matter if we're actuating on the MC or the ETMs, but it's easier for me to think about this way around).  This means that we want to be able to actuate from point 10 in the diagram, and not feel anything at point 4 in the diagram (diagram from http://131.215.115.52:8080/40m/11011)

This is the same as saying that we wanted the green trace in http://131.215.115.52:8080/40m/11009 to be zero.

So.  What is the total TF from 10 to 4? 

. 

So, to set this equal to zero (ALS is immune to any REFL loop actuation), we need .

Next up, we want to see what this means for the closed loop gain of the whole system.  For simplicity, let's let , where * can be either REFL or ALS. 

Recall that the closed loop gain of the system (from point 1 to point 2)  is

, so if we let   and simplify, we get

This seems a little scary, in that maybe we have to be careful about keeping the system stable.  Hmmmm.  Note to self:  more brain energy here.

Also, this means that I cannot explain why the filter wasn't working last night, with the guess of a complex pole pair at 1Hz for the MC actuator.  The  ALS plant has a cavity pole at ~80kHz, so for our purposes is totally flat.  The only other thing that comes to mind is the delays that exist because the ALS signals have to hop from computer to computer.  But, as Rana points out, this isn't really all that much phase delay below 100Hz where we want the cancellation to be awesome. 

I propose that we just measure and vectfit the transfer function that we need, since that seems less time consuming than iteratively tweaking and checking. 

Also, I just now looked at the wiki, and the MC2 suspension resonance for pos is at 0.97Hz, although I don't suspect that that will have changed anything significantly above a few Hz.  Maybe it makes the cancellation right near 1Hz a little worse, but not well above the resonance.

I have modified the LSC trigger matrix screen, as well as the LSC overview screen, to reflect the modifications to the model from yesterday. 

Also, I decided that we probably won't ever want to trigger the zero crossing on the Q phase signals of REFL.  Instead, we may want to try it out with the single arms, so the zero crossing selection matrix is now REFL11I, REFL55I, POX11I, POY11I, in that order. 

[Jenne, Rana]

We wanted to jump right in and see if we were ready to try the new "ALS fool" loop decoupling scheme, so we spent some time with CARM and DARM at "0" offset, held on ALS, with PRMI locked on REFL33I&Q (no offsets).  Spoiler alert:  we weren't ready for the jump.

The REFL11 and AS55 PDs had 0dB analog whitening, which means that we weren't well-matching our noise levels between the PD noise and the ADC noise.  The photodiodes have something of the order nanovolt level noise, while the ADC has something of the order microvolt level noise.  So, we expect to need an analog gain of 1000 somewhere, to make these match up.  Anyhow, we have set both REFL11 and AS55 to 18dB gain. 

On a related note, it seems not so great for the POX and POY ADC channels to be constantly saturated when we have some recycling gain, so we turned their analog gains down from 45dB to 0dB.  After we finished with full IFO locking, they were returned to their nominal 45dB levels. 

We also checked the REFL33 demod phase at a variety of CARM offsets, and we see that perhaps it changes by one or two degrees for optimal rotation, but it's not changing drastically.  So, we can set the REFL33 demod phase at large CARM offset, and trust it at small CARM offset.

We then had a look at the transmon QPD inputs (before the dewhitening) for each quadrant.  They are super-duper saturating, which is not so excellent. 
QPDsaturation_12Feb2015.pdf

We think that we want to undo the permanently-on whitening situation.  We want to make the second stage of whitening back to being switchable.  This means taking out the little u-shaped wires that are pulling the logic input of the switches to ground.  We think that we should be okay with one always on, and one switchable.  After the modification, we must check to make sure that the switching behaves as expected.  Also, I need to figure out what the current situation is for the end QPDs, and make sure that the DCC document tree matches reality.  In particular, the Yend DCC leaf doesn't include the gain changes, and the Xend leaf which does show those changes has the wrong value for the gain resistor.

After this, we started re-looking at the single arm cancellation, as Rana elogged about separately.

ALSfool_12Feb2015.pdf

I first updated the DCC branches for the Xend and Yend to reflect the as-built situation from December 2014, and then I updated the drawings after Q's modifications today.

The ALS fool scheme is now diagrammed up in OmniGraffle, including its new official icon.  The mathematica notebook has not yet been updated.

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

I have measured very, very carefully the transfer function from pushing on MC2 to the Yarm ALS beatnote.  In the newest loop diagram in http://nodus.ligo.caltech.edu:8080/40m/11030, this is pushing at point 10 and sensing at point 4. 

Since it's a bunch of different transfer functions (to get the high coherence that we need for good cancellation to be possible), I attach my Matlab figure that includes only the useful data points.  I put a coherence cutoff of 0.99, so that (assuming the fit were perfect, which it won't be), we would be able to get a maximum cancellation of a factor of 100. 

This plot also includes the vectfit to the data, which you can see is pretty good, although I need to separately plot the residuals (since the magnitude data is so small, the residuals for the mag don't show up in the auto plot that vectfit gives). 

If you recall from http://nodus.ligo.caltech.edu:8080/40m/11020, we are expecting this transfer function to consist of the suspension actuator (pendulum with complex pole pair around 1Hz), the ALS plant (single pole at 80kHz) and the ALS sensor shape (the phase tracker is an integrator, with a boost consisting of a zero at 666Hz and a pole at 55Hz).  That expected transfer function does not multiply up to give me this wonky shape.  Brain power is needed here.

Just in case you were wondering if this depends on the actuator used (ETM vs MC2), or IFO configuration (single arm vs. PRFPMI), it doesn't.  The only discrepancy between these transfer functions is the expected sign flip between the MC2 and ETMY actuators.  So, they're all pretty consistent. 

Before locking the PRFPMI, I copied the boost filter (666:55) from the YARM ALS over to Xarm ALS, so now both arms have the same boost.

YARM_actTF_compareActuators.pdf

Things to do for ALSfool:

• Put fitted TF into the MC_CTRL_FF filter bank, and try to measure the expected cancellation, a la http://nodus.ligo.caltech.edu:8080/40m/11009
• Quick test with single arm, ALS locked using full loop (high gain, all boosts), since the previous versions were with ALS very loosely locked.
  • Does this measured transfer function actually give us good cancellation? 
• Think.  Why should the transfer function look like this??
• Try it on the full PRFPMI

Dang it, yes. You're right.  I should have caught that. 

Since Dcpl and Srefl are both zero during the measurement (since it was an ALS lock), this is actually

So, I need to remove the effect of the ALS closed loop, to get the actual quantity I was looking for.

I re-did the Mathematica notebook according to the most current diagram (note to daytime self: attach .nb file!!!), and found that the denominator has changed, such that plugging in the new D=-A_refl*P_als*S_als gives the same

full-system closed loop gain of   

where   is the open loop gain, and the * indicates either the REFL or ALS portions of the system. 

I have also plotted some things with Matlab, although I'm a little confused, and my daytime self needs to spend some more time thinking about this.

In the actuators (both for REFL and ALS), I include a pendulum, the digital anti-imaging filters that let us go from the 16kHz model to the 64kHz IOP and the analog anti-imaging filters after the DAC.  Note to self:  still need to include violin filters here.

For the servo gains, I copy the filters that we are using from Foton, and give them the same overall gain multiplier that is in the filter bank.  For the ALS going through the CARM filter bank, this is FMs 1, 2, 3, 5, 6 with a gain of 15.  For the RF (actually, POY here) going through the MC filter bank, this is FMs 4, 5, 7 with a gain of 0.08. 

For the plants of each system, since this is still single arm lock, I just include a cavity pole (80kHz for ALS, 18kHz for REFL). 

In the sensors (both for REFL and ALS), I include the analog anti-aliasing as well as the digital anti-aliasing to allow us to go from the 64kHz IOP to the 16kHz front end system.  For the ALS I also include in the sensor the closed loop response of the phase tracker loop (H/(1-H), where H is the open loop gain of the phase tracker).  For both sensors, I also include a semi-arbitrary number to make the full single-loop open loop gain have a UGF of 200Hz.  In the ALS sensor, I also include a minus sign to make the full open loop gain have the correct phase.

Here I plot the open loop gains of the individual single loops, as well as the open loop gain of the full system (Hals + Hrefl - Hals*Hrefl).  I feel like I must be missing a minus sign in my ALS loop, but I don't know where, and my nighttime brain doesn't want to just throw in minus signs without knowing why.  That will affect how the final ALSfool (blue trace) looks, so maybe it's not really as crazy as it looks right now.

Also, I was trying to explain to myself why we are getting the shape that we are in our measurements of the cancellation (http://nodus.ligo.caltech.edu:8080/40m/11041).  But, I can't.  Below are the plots of the transfer functions from either point 9 or 10 (before or after the G_refl) to point 5, which is the ALS error point.  The measurement in elog 11041 should correspond to the blue trace here.  For these traces, the decoupling is set to just (-A_refl), although there aren't any noticeable changes in the shape if I just set D=0.  If we start with the assumption that D=0, the shape and magnitude are basically identical to this plot, and then as we make D=-A_refl P_als S_als, the transfer functions both go to zero. 

So.  Why is it that with no decoupling, the transfer function from 10 to 5 is tiny?  Why do the shapes plotted below look nothing at all like the measured cancellation shape?  Daytime brain needs to think some more.

Here is an updated cartoon, with the ALS sensor explicitly shown as the beatbox times the closed loop response of the phase tracker servo. 

The most important transfer functions are written on the diagram.  Others can be extracted from the attached Mathematica file (which corresponds to this diagram).