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.
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:
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.
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.
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.
PRMI is locked on sideband, starting ~4 minutes ago, to collect ASC/seismic data for feedforward.
Welcome to your new abode, Donatella!
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:
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:
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.
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:
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.
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://126.96.36.199:8080/40m/11043
EDIT, JCD, 17Feb2015: Updated loop diagram and calculation: http://188.8.131.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://184.108.40.206:8080/40m/11011)
This is the same as saying that we wanted the green trace in http://220.127.116.11: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.
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.
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.
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://18.104.22.168: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.
Things to do for ALSfool:
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).
We tried several times tonight to engage the Fool path with the PRFPMI. No success.
First, we locked the arms on ALS, in CARM/DARM mode, and measured the cancellation ability, to make sure that the filter shape and gain was set correctly. For the PRFPMI, it was okay using the same shape as the single arm case, but the gain was +20.0. There might be a bit more cancellation to be gained if we adjust the shape at the ~1dB level, but we're already able to get 20dB of cancellation, so we decided that would be enough to give things a try. To get this much cancellation, we set the phase tracker loops to both have 2kHz UGFs, almost exactly. We should implement a UGF servo, or the amplitude method version of that as Koji suggested ages ago, so that the phase tracker is always at the same place.
I don't think that REFL 11 is seeing as much CARM as I expect. We ended up switching over to linearized REFL55 for our attempts. When we're close to zero CARM offset, the arms are constantly flashing through resonance, and we get the loud buzzing. REFL11 doesn't seem to see any of this, even though we should be close enough to see some PDH action. REFL55 does change as we get closer to resonance, so I think it's seeing some real CARM stuff.
We tried engaging the Fool, but I don't think it did anything too useful. We need to make an estimate of what we expect our gain of the REFL loop to be - or at least the sign.
The PRMI is still not stable enough. It keeps falling out of lock when we get to high-ish arm powers. Not good. More brain power tomorrow on the modulation cancellation issue.
Perhaps if things are stable at moderate arm powers, we can use an excitation to line up the ALS vs. REFL error signals, and then watch the noises of them change as we move around in CARM offset. This should tell us when the linearized REFL signal is quiet enough that it's worth triggering and trying to transfer over.
The last lockloss tonight, there was something funny going on, that we can't explain. Even though both arms were locked on the CARM/DARM combined ALS signals, beatx doesn't see the giant oscillation that causes carm to lose lock until much later. Fool was trying to do something, but that should affect both als individal signals in the same way. Mystery.
I have used Optickle to model the effect of changing the phase between the 11MHz and 55MHz EOMs. Also, I have looked at what modulation order is most significant (we hope it's -22*11 and -11*22).
First, so that we can compare these numbers more directly to measurements, I have included in the model the fraction of light that gets to each PD. I'm assuming that the Faraday is about 80% transmissive, but I don't know what the true number is. Here's a cartoon showing the attenuation factors.
EDIT, 26March2015, JCD: REFL path updated. See elog 11172.
To model the change in relative phase between the 11MHz and 55MHz modultions, I have held the 11MHz EOM stationary, and moved the 55MHz EOM. Since I needed an actual distance, I used a conversion factor,
The sensing matrix was measured at 143Hz. It has been corrected from mevans-meters to Newtons as the denominator.
The big thing to notice here is that the PRCL magnitude is not changing by a factor of 20. More like a factor of 2. BUT, I have not yet included the fact that Koji also reduced the 55MHz modulation amplitude by a factor of 3.
As for the mysterious degeneracy of all the REFL PDs, I think we need to take a more careful measurement. It's possible that we were seeing the real thing for REFL33, but the others don't seem to change in degeneracy with relative modulation phase.
Why does it even matter for the 3*f1 signal what is going on with the f2 modulation? Well, it appears that we are definitely being dominated by the 44*11 and 55*22 components.
To check this, I restricted Optickle to various orders of modulation (ex. up to second order only includes the [-22, -11, 0, 11, 22] MHz components), and plotted them all. The change in the signal between one trace and another is the contribution from that extra modulation order. The traces are only minutely different between orders, after the 5th order. So, since they're all overlapping with the 5th order trace anyway, I don't plot them.
EDIT: to clarify, when I said "up to X order", I meant up to that order in 11MHz sidebands. Optickle is applying the 11MHz and 55MHz modulations in the same way every time, but then I specify up to what order to include in the summation of different contributions to the field at a given port. So, for the "up to 2nd order", I only include cross terms that come from [-22, -11, 0, 11, 22] MHz. For the next order, I only include terms that come from [-33, -22, -11, 0, 11, 22, 33] MHz, etc. So, there are no 55MHz effects when I'm only including contributions up to 2nd order (since there is a maximum cross beatnote of 44MHz), but starting with 3rd order, I do start to see signals in, for example, REFL55 and AS55, since I get terms from -22*33 and -33*22. The first order in 55MHz (i.e. 55MHz*Carrier) only starts to show up when I calculate "up to 5th order" and above, since that includes [-55, -44, -33, -22, -11, 0, 11, 22, 33, 44, 55] MHz.
What happens if I reduce the 55MHz modulation depth by 10dB? Since we are dominated by 55MHz-related signals, the signal at REFL 33 goes down. The maximum change we could have seen for the REFL33 PRCL signal (difference between max of blue trace and min of orange trace) is a factor of 27.
Where are we on the x-axis of these plots, and where was the maximal cancellation place that Koji found? I need to re-check that part of the code tomorrow, to make sure that I've included all of my contributions from different components of the (field* field) matrix.
But, the moral of the story for tonight is that at least for the REFL33 signal, it's actually plausible that the optical gain went down by a factor of 20, and that the MICH and PRCL signals were degenerate. I suspect that the total cancellation place that Koji found was somewhere around 175 degrees on the x-axis of these plots and that our nominal place is around 0 deg - around there, both the magnitude and the phase situations are possible simultaneously.
About 5-10 minutes ago I just put in the modulation cancellation setup according to the recipe in http://nodus.ligo.caltech.edu:8080/40m/11032
[Jenne, EricQ, Rana]
We spent this evening measuring and thinking about our 3f signals, and the effect of the modulation cancellation.
I reinstalled the delay line box, and reduced the modulation depth of the 55MHz signal, so that we are in the state of modulation cancellation - there should be almost no power at 33MHz injected into the vacuum. I carefully tuned the demod phase of the REFL 11, 33 and 55 MHz PDs, and locked the PRMI on REFL55 I&Q. The signal in REFL 165 was very tiny, so as best as I could tell, the demod phase that Koji found last week was correct.
Here is a little record of what the demodulation phases should be, for the "nominal" and "cancellation" configurations, so that we don't have to continually use the time machine.
Also, here is the locking recipe for REFL55 I&Q in the cancellation configuration:
With this setup, we measured the sensing matrix. MICH had an excitation at 370.123 Hz with 8,000 counts to -ITMX+ITMY (this is about 0.3nm for each ITM), and PRCL had an excitation at 404.123 Hz with 50 counts to PRM. For tonight, here is a PDF of the peaks in DTT. The data is saved in /users/Templates/LSC_error_spectra/SensMat_PRMI_24Feb2015.xml.
Rana has proposed to us an idea for why the REFL 33 signal should be dominated by the 55*22 contribution, rather than -11*22. Eric is in the process of checking this out with a Mist model to see if it makes sense. Here's the gist:
Our Schnupp asymmetry is small (3.9cm, IIRC), so the transmission of the 11MHz signal out the dark port is small. This means that the finesse of the PRC for 11MHz isn't so huge. On the other hand, since 55MHz is a higher frequency, the transmission out the dark port is larger and is a closer match to the PRM transmission, so the finesse of the PRC for 55MHz is higher.
Since the magnitudes of the fields at the reflection port are not changing significantly, our PDH signals are being created by the relative phase of something which is anti-resonant (ex. carrier or 22MHz for sideband lock) vs. something which is resonant (ex. 11MHz or 55MHz). Since the finesse of the 55MHz signal is larger, the accumulated phase change is greater, so we expect a larger slope to our PDH signals that involve 55MHz as compared to those that use 11MHz.
If we are comparing the contributions between -11*22 and 55*22, they both include the anti-resonant 22MHz. So, the difference in the signal strengths comes directly from the difference in phase accumulation due to the variation in the dark port transmission.
EricQ had a thought, and while I have enough awake brain cells to report the thought, we're going to have to revisit it when more of our brains are awake. In either case, the transmission through the dark port is small compared to the transmission of the ITMs, so why don't the ITMs dominate the finesse calculation, and thus are the 11MHz and 55MHz really getting that much of a difference in finesse? To be checked out.
And now I've removed the delay line, and am in the process of reverting the demod phases, etc.
I have measured the sensing matrix for the PRMI at the REFL photodiodes for both the nominal configuration and the 33MHz cancellation configuration. The nominal configuration measurements do not compare well with those from November (http://nodus.ligo.caltech.edu:8080/40m/10701) which makes me unhappy . Both sets of nominal config reported below are from today, after tuning the demod phases and making sure the MICH and PRCL loops looked the same as yesterday (esp. overall gain). The cancellation config data is from last night.
Note that the magnitude for each photodiode is referred to its own "PD counts". Since the electronics are different for each PD, and that is not taken into account here, you cannot directly compare an element from one PD to an element from another PD. What you can do (which is most of what we need right now) is compare all the different measurements for a single photodiode.
So, what I'm apparently seeing is that the magnitudes of the sensing matrix signals that are made using 55MHz (i.e. everything but REFL11) change when we go into the cancellation configuration, but the phases of the sensing elements do not change significantly. Also, I am apparently seeing that REFL11 and REFL33 only have about 3 degrees of separation between the MICH and PRCL signals no matter what configuration is used. This doesn't make a lot of sense, since we know that we can lock robustly on REFL33I&Q (it's been sitting there happily as I write this elog), so it seems crazy that we could actually be so degenerate. Also, at the bottom of the elog that I wrote in November 2014, I show a sensing matrix where both REFL11 and REFL33 have about 45 degrees of separation between the MICH and PRCL signals.
I don't think I'm doing anything too crazy here, particularly with the phase. For a given PD and given DoF, I find the magnitude of the peaks of the I and Q signals, and just do atan2(Q-signal, I-signal)*180/pi, and those are the numbers that go in the phase columns above.
Before taking my measurements, I tuned up the demod phases for the PRMI-only case. I think REFL11 may have previously been tuned for CARM when the arms were held with ALS, but I don't really recall. Anyhow, now all 4 REFL PDs are tuned for PRMI-only.
This was done while the PRMI was locked with REFL 55 I&Q.
EDIT, 26Feb2015: Last night I mixed up the REFL11 and REFL33 new demod phases. Bold are the corrected version. Also, note that REFL33 was formerly tuned for PRCL in PRFPMI, which may be why it changed by ~10 degrees.
15.3 +/- 0.3
Here's the recipe for locking REFL 55 I&Q in the nominal modulation configuration. It's the same as the REFL33 I&Q lock that I was using today, except that for the REFL33 version, the matrix elements are both unity.
I have clarified my elog from last night to indicate that the sensing matrix in the "33MHz cancellation" configuration was measured with the PRMI held on REFL55 I&Q.
Also, I just re-read my control room notes from yesterday, and I typed the wrong demod phases into the table last night. The elog has been edited. Most significantly, the REFL33 demod phase did not change by 70 degrees. It did change by 10 degrees, but that is likely from the fact that it was formerly tuned for PRCL in PRFPMI, and last night I tuned it for PRCL in PRMI-only.
One of the things that I looked at tonight was whether or not I could hold the PRMI on REFL165 at CARM offset of 0, and it turns out that I can. Hooray. The next step was having a look to see if it is actually less noisy than the REFL33 lock.
I calibrated REFL33 and REFL165 to meters (I have the data to do the same for 11 and 55, but haven't done so yet). This way, we can directly compare the signals from each PD.
I scanned between +3 and -3 CARM digital offset (which we think is about 1nm/count while held on ALS), with a ramp time of 10 seconds. I did this several times while the PRMI was locked on both REFL33 and REFL165. Here are the gps times for 8 examples where the PRMI did not lose lock during the sweep:
Here are screen shots from the first REFL33 sweep, and the first REFL165 sweep. DTT can't print 3 plots together, so I'll have to make this nicer later. The top plot is the error signals, calibrated to meters. The middle plot is the control signals, that need to be calibrated to Newtons. The bottom plot is the arm powers, so you can see roughly where we were in the sweep.
We'd like to see a MIST simulation, or perhaps e2e, to see what the predicted disturbance is for each of the error signals during the CARM resonance. We want to make sure that the loops are engaged for all of the degrees of freedom for the simulation.
Recipes for tonight:
REFL165 sometimes has a tough time catching lock by itself, but if you add either REFL33 or REFL55 error signals to the REFL165 signals, it'll catch, and then you can just remove the extra error signals. Also, it doesn't stay locked very robustly unless you include the PRCL FM1 boost.
Here are a bunch of PDFs of time series from last night's CARM sweeps. The y-axes are all calibrated (except for the TRX/TRY, which are just normalized to single arm power, as usual) to real units - meters for the error signals, and Newtons for the control signals. The y-axes for each plot are the same on all PDFs (ex, the control signal plot in the lower left has the same range for all cases) so that it is easy to compare directly.
The most striking thing is that while the PRMI is held on REFL33, the MICH control signal saturates as we go through arm resonance. If the PRMI is held on REFL165, there is no such problem. I think we're going to have a lot more luck keeping the PRMI on REFL 165.
Plots while held on REFL 33:
Plots while held on REFL 165:
This has been edited several times over the last several hours, as I try to change different parameters, to see if they affect the movement of ETMX. So far, I don't know what is causing the motion. If it is there, it is only present when the LSC is engaged, so I don't think it's wobbling constantly on a twisted wire.
FINAL EDIT, 9:10pm: The arm ASC was turning itself on when the arms were locked. Whelp, that was only 3 hours of confusion. Blargh.
For his penance for leaving the arm ASC engaged, Q has made a set of warning lights on the LSC screen, right next to the ASS warning lights.
ETMX might be having one of those days today, which is lame.
So far tonight, I have run the LSC offset script, set the FSS slow value to +0.2, and run the arm ASS scripts. Nothing too crazy I think.
Sometimes when I lock the single arms, the ETMs move around like crazy. Other times, not. What is going on here??? The ETMs don't move at all when they are not being actuated on with the LSC.
In this screenshot you can see the end of a POX/POY lock stretch where everything was nice and good. Then, the arms were unlocked, and they have a bit of a DC offset. After settling from that step, they continue sitting nice and still. Then, I relock the cavities on POX and POY a little before -4 minutes. ETMY takes a moment to pull itself together, but then it's steady. ETMX just wobbles around for several minutes, until I turn off the LSC enable switch (happened after the end of this plot).
I'm not going to be able to lock like this. Eeek!
This is somehow related to light being in the Xarm. This next plot was taken while the arms were held with ALS in CARM/DARM mode.
I closed and re-opened all 3 green shutters. Now (at least the last 8 arm locks in the last 6 mintues) ETMX has never gone wobbly, except for a little bit right after acquisition, to deal with whatever the DC offset it. Why is this changing?
The arms were fine for one long ~30 minute lock while I stepped out for dinner. At some point after returned, the MC lost lock. When the arms came back, ETMX was being fussy again. Then, it decided that it was done.
In this plot, at -1 minute I started the ASS. Other than that, I did not touch any buttons at all, just observed. I have no idea why at about -3 minutes the bad stuff seems to go away.
I was curious if it had to do with the DC pointing of the optics, so I unlocked the arms, put ETMX about where it was during the long good lock stretch, then reaquired lock. I had to undo a little of that so that it would lock on TEM00, but at the beginning of the lock stretch (starting at about -3) the pitch is about the same spot. But, the oscillations persist. This time it was clear that the oscillations were around 80 mHz, and they started getting bigger until they settled to an amplitude they seemed to like.
Seems pretty independent from FSS temp. There are 3 lock stretches in the next plot (easier to see by looking at the Yarm transmission, green trace). The first one, the FSS slow was at 0.35. the middle one, it was around 0.05. The last one, it was around -0.4. Other than the different DC pointings (which I don't know if they are related), I don't see anything qualitatively different in the movement of ETMX.
It's super cold in the control room and EE bench area tonight. I'm wondering if, similar to what happened on Dec 29th (http://nodus.ligo.caltech.edu:8080/40m/10846) the campus steam is off? Or just our heater is broken? The thermostat is cranked up to 80 over by the bathrooms (this is usually ~74F), but we're still cold.
It's 69F in the control room right now (usually mid-high 70s).
EDIT, JCD, 4am: It's 64.3F in the desk area, 67.8F in the control room. It also smells in the control room like some heater has been off for a while, and is turning back on - that burned dust smell that happens after you haven't turned on the heater all summer.
EDIT again: The burn-y smell is getting stronger I think. Security is sending someone over to come check it out.
Better elog tomorrow - notes for now:
REFL165 for PRMI has been "a champ" (quote from Q). We're able to sit on ALS at average arm powers of 30ish. Nice.
Some ALSfool work - measured cancellation almost as good as single arm.
One time transitioned CARM -> normalized REFL55I
Many times did DARM -> normalized AS55Q, see lots of noise at 39ish Hz - may be coupling from MICH??
Arm ASC loops helped improve dark port contrast.
Note to selfs: Need to make sure DTT templates have correct freq ordering - must be small freqs to large freqs.
After some searching, including help from 4 security guys (I think they don't have a lot to do at 4:30am :), we found that Ottavia is super warm, and smelled burn-y. She has been powered down and unplugged. Security guys may call Steve's desk to follow up later today.
A slightly more coherent elog for last night's work.
All night, we've been using REFL165 to hold the PRMI. It's working very nicely. To help it catch lock, I've set the gain in the PRCL filter bank high, and then the *0.6 filter triggers on. The carm_cm_up script now will lock the PRMI on REFL165.
We had to reset the REFL165 phase after we acquired lock - it was -91, but now is -48. I'm not sure why it changed so significantly from the PRMI-only config to the PRFPMI config.
We measured the ALS fool cancellation with the arms held off resonance, at arm powers of a few. Although, they were moving around a lot, but the measurement stayed nice and smooth. Anyhow, we get almost as good of cancellation as we saw with the single arm (after we made sure that both phase trackers had the same UGF):
We were able to partly engage it one time, but we lost lock at some point. Since the frame builder / daqd decided that that would be just the *perfect* time to crash and restart, we don't have any frame data for this time. We can see up to a few seconds before the lockloss, while we were ramping up the RF PD loop gain though, and MICH was hitting the rails. I'm not sure if that's what caused the lockloss, but it probably didn't help.
The ALS fool gain was 22, and we were using FMs 4, 6 (the pendulum and Rana's "comp1"), the same filters that were used for the single arm case. The LSC-MC filter bank gain lost lock when we got to about 5.6 (we were taking +3dB steps).
We were using REFL55I/(TRX + TRY) as our CARM RF error signal. We were using REFL55 rather than REFL11 because we were worried that REFL11 didn't look good - maybe it was saturating or something. To be looked into.
Here's the striptool that was running at the time, since we don't have frame data:
At this point, since we weren't sure what the final gain should be for the RF CARM signal, and we could sit at nice high arm powers (arm powers of 30ish correspond to CARM offsets of about 50pm), we decided to try just a straight jump over to the RF signals.
The first time around, we jumped CARM to (-0.2)*REFL55/(TRX+TRY), but we only stayed lock for 1 or 2 seconds. That was around 1:55am.
We decided that perhaps it would be good to get DARM moved over first, since it has a much wider linewidth, so the rest of the trials for the night were transitioning DARM over to (0.0006)*AS55Q/(TRX + TRY). AS55 was saturating, so we reduced its analog gain from 18dB to 9dB and re-ran the LSC offsets. The MICH noise was pretty high when we were at low CARM offset, although we noticed it more when DARM was on AS55. In particular, there is some peak just below 40Hz that is causing a whole comb of harmonics, and dominating the MICH, PRC and DARM spectra. I will try to get a snapshot of that tonight - I don't think we saved any spectra from last night. Turning off DARM's FM3 boost helped lower the MICH noise, so we think that the problem is significant coupling between the two degrees of freedom.
After the first one or two tries of getting DARM to AS55, we started engaging the arm ASC loops - they helped the dark port contrast considerably. The POP spot still moves around, but the dark port gets much darker, and is more symmetric with the ASC on.
Much of tonight was spent fighting with ETMX. This time, ASC was definitely off, there was nothing coming out of the ASC filter banks except the static output of the ASS. I tried turning off the 1000 count POS offset, but I think that made it a little worse. I ended up putting the offset back.
It's a little confusing, since it sometimes moves when there is no LSC actuation. However, it definitely moves when there is some LSC actuation. I did a test where every time I enabled the IR arm locking and caught lock, I saw a step in the SUSPIT and SUSYAW error signals. Once lock was aquired, it would settle and stay somewhere. If I unlocked the cavity, there was no "undo" step - it just stayed where it was. I wasn't letting it sit long enough to see if it spontaneously moved during this test.
Here's a plot of this test. The only button I'm touching is the LSC enable button. ASC is off, ASS is frozen (DC values exist, but no dither, no feedback). This was done when the 1000 count POS offset was off. The steps are less bad when the offset is on.
In between fighting with the ETM, I was able to do several trials with the PRFPMI.
I was playing with CARM and ALS fool.
First, I used REFL55 normalized by the sum of the transmissions as the error signal for the MC filter bank and saw that REFL11 (as an out of loop signal) got much more smooth, and centered around zero. However, I wasn't able to get the same thing with REFL11. No matter the sign I used for the MC filter bank, the IFO would squeak (some high freq gain peaking I think), and then I'd lose lock. This was true whether I used REFL11 through the common mode board or just directly into the ADC.
Just now, I did one trial of switching DARM over to AS55Q, just to grab a spectra of the MICH noise that Q and I saw yesterday.
I'm a little confused by some delay that seems to exist between the "A" and "B" error signals (right after the LSC input matrix) and the _IN1 point of the servo filters. I didn't save the measurement (bad Jenne), but there's a ~40 degree difference between DARM_A_ERR/DARM_IN2 and DARM_IN1/DARM_IN2. I don't think there should be anything there. Anyhow, it makes the DARM loop measurements look funny. If you just look at, say, DARM_B_ERR/DARM_IN2, you'll think that there's no way that the loop will be stable. However, it will actually be fine.
For tomorrow, we should take the DARM loop measurement with much less actuation. As with last night, I blew the lock by trying to measure the DARM loop.