The UGF servos have been moved to the control point, are are once again totally linear!
The UGF servos were recommissioned today:
Our idea is that we need with some thinking about these servos and most of all try to figure out all this phase thing before we can start to trust the servos to be used for locking.
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?
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?
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.
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):
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.
UGF Servos' commissioning still going on, updates of today:
Was the screen modified directly on LSC_OVERVIEW.adl?
Even if so, that's OK. I'll incorporate the change to the screen making script once I'm back.
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 found an error in the model of the UGF servos, I have now corrected it; for future reference, now the division between TEST2 and TEST1 is properly done with complex math: given
we have that TEST3:
TEST3 is the actual signal that is now phase rotated to select only the I signal while rejecting the Q one.
All the updates to the model, the screens and the script have been SVNed.
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.
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.
After some brainstorming with Jenne and Q, both the model and the medm screen have been modified: the entire block "Test1 - injection of the excitation - Test2" has been moved after the servo output. In this way we avoid completely the multiplication problem without having to perform divisions that could lead to division-by-zero problems. Because of how the logic is done now, one UnitDelay block had to be inserted before each one of Test1 and Test2.
Since the UGF Servo has been heavily modified lately, I'll post the current status of the model (as an attachment, as inpage images lose too much quality).
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.
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.
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.
The UGF Servo medm page has been updated to reflect the last changes, namely the return of the sum of squares and the disappearance of Test3.
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.
Why AS55/(TRX + TRY) instead of just TRX? Isn't (TRX+TRY) controlled by CARM?
(question is secretly from Kiwamu)
Tonight, we transitioned CARM from ALS directly to REFL11 I at 25% Mich Offset.
We attempted the transition twice, the first time worked, but we lost lock ~5 seconds after full transition due to a sudden ~400Hz ringup (see attached lockloss plot). The second barfed halfway, I think because I forgot to remove the CARM B offset from the first time
The key to getting to zero CARM offset with CARM and DARM on ALS is ekeing out every bit of PRMI phase margin that you can. Neither MICH nor PRCL had their RG filters on and I tweaked the MICH LP to attenuate less and give back more phase (the HF still isn't the dominant RMS source.) PRCL had ~60 degrees phase margin at 100Hz UGF, MICH had ~50 deg at 47Hz UGF. The error signals were comparitively very noisy, but we only cared that they held on. Also important was approaching zero slooooooooowly, and having the CARM and DARM UGF servo excitations off, because they made everything go nuts. Diego stewarded the MICH and PRCL excitation amplitudes admirably.
Oddly, and worringly, the arm powers at zero CARM offset were only around 10-12. Our previous estimations already include the high Xarm loss, so I'm not sure what's going on with this. Maybe we need to measure our recycling gain?
I hooked up the SR785 by the LSC rack to the CM board after the first success. For the second trial, I also took TFs with respect to CM slow, but they looked nowhere near as clean as the normal REFL11 I channel; I didn't really check all the connections. I will be revisiting the whole AO situation soon.
In any case, I think we're getting close...
Tonight we continued following the plan of last night: perform the transition of CARM to REFL11_I while on MICH offset at -25%:
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.
We just changed the input to the CM board from REFL11 to AS55.
Tonight we worked on the CM board and AO path:
The BLUE plot is at MC Gain = 0.10 and REFL1 Gain = 4dB; the GREEN plot is for MC Gain = 0.10 and REFL1 Gain = 3dB, which seemed a more stable configuration; after this last configuration, we increased the MC Gain to 0.15 and the AO Gain from 8dB to 9dB and took another measurement, the RED plot; this is as far as we got as of now. We also couldn't increase the REFL11 Gain because it made things unstable and more prone to unlock.
So, some little progress on the AO path procedure, but we are very low on our UGF and we have to find a way to increase our gains without breaking the lock and avoiding the gain peaking we have witnessed tonight.
I have removed REFLDC and the SR560 offsetter from the CM board IN2. Now, analog AS55 I lives there, for our single arm testing. (Analog I has more of the single arm Y PDH signal in it). REFL11 has been reconnected to IN1.
With ITMX super misaligned, Diego and I locked the Y-arm with the AO path on AS55, ultimately at 4kHz bandwidth, but with plenty of gain margin. We didn't allocate the gains too intelligently, and had the CM board input gain slider maxed out, but plenty of headroom in the digital and AO sliders, making it inconvenient to up the UGF even more, to engage the super boosts. However, since this is just a test case to make sure we still can AO lock, I'm not too worried about this.
Since LSC FMs and such had changed around, old recipies didn't neccesarily work 1:1. Diego is writing a script for the current recipe, and will post an elog with the steps.
Gains and signs are able to be tracked by loop TFs, the real sticking point is a stable crossover. We used the 1.6k:80 hardware filter in the CM board to give the AO Path a 1/f shape in the crossover region, and undid it digitally in the CM_SLOW input FM. However, we do use a 300:80 in the MC2 sus FM to make the digital loop like 1/f^2 around the crossover, once a little bit of AO has come in to pull up the digital loop's phase. We used the CARM filter bank to do this, so I think we should be able to use a similar technique to do it in the PRFPMI case, as long as the coupled cavity pole is around ~100Hz.
Attached are a few OLTFs from the progression.
[Diego, Jenne, Eric]
Tonight we kept on following our current strategy for locking the PRFPMI:
both of the last two locks, the most stable ones (one transition to usual REFL11 and one transition to "CM_SLOW" REFL11) were acquired actuating on MC2;
EDITs by JCD: At least one of the times that we lost PRMI lock (although kept CARM and DARM lock on ALS), was due to MICH hitting the rail, even after we increased the limiter to 15,000 counts.
Here is the transfer function between CARM ALS (CARM_IN1) and REFL11 coming through the CM board (CARM_B), just before we transitioned over. Coherence was taken simultaneously as usual, I just printed it to another sheet.
Here is the lockloss plot for the very last lockloss. This is the time that we were sitting on REFL11 coming through the CM_SLOW path. A DTT transfer function measurement was in progress (you can see the sine wave in the CARM input and output data), but I think we actually lost lock due to whatever this glitch was near the right side of the plots. This isn't something that I've seen in our lockloss plots before. I'm not sure if it's coming from REFL11, or the CM board, or something else. We know that the CM board gives glitches when we are changing gain settings, but that was not happening at this time.
Q: Here's the SR785 TF of CARM locked through CM board, but still only digital control; nothing exciting. Excitation amplitude was only 1mV, which explains the noisy profile.
At the lunch meeting, we were thinking about the exess high frequency content of the MICH control signal, which leads to railing against the FM output limiter and lock loss. I propsed that POPDC sensor/ADC noise was the culprit.
In short, I was wrong. Just now, I locked the PRMI with a MICH offset as we normally do, and then froze the POPDC output. The MICH spectrum did not change in any noticible way.
However, increasing the analog ASDC whitening gain showed a direct improvement of the error signal noise floor, and thus a reduction in the control signal spectrum. I.e. we have been suffereing from ASDC ADC noise.
We had previously set the ASDC whitening gain so that half fringe of the PRMI would be well within the ADC range, but since we're actually only ever going to 25%, I feel fine upping this gain. Interestingly, when increasing the whitening gain by 12dB, the control signal spectrum has fallen by more like 20 dB in the 400Hz-1kHz region, which is great.
The only potential hurdle I can think of is that when we start reducing the MICH offset at zero CARM offset, we may approach ADC saturation in ASDC before we can hand off to RF signals, in which case we would have to dynamically lower the whitening gain, which introduces offsets, which could get hairy. But, since MICH railing has been directly seen to lead to lock-loss, I'd rather solve that problem first.
c1lsc had 60 full-rate (16kS/s) channels to record. This yielded the LSC to FB connection to handle 4MB/s (mega-byte) data rate.
This was almost at the data rate limit of the CDS and we had frequent halt of the diagnostic systems (i.e. DTT and/or dataviewer)
Jenne and I reviewed DAQ channel list and decided to remove some channels. We also reviewed the recording rate of them
and reduced the rate of some channels. c1lsc model was rebuilt, re-installed, and restarted. FB was also restarted. These are running as they were.
The data rate is now reduyced to ~3MB nominal.
The following is the list of the channels removed from the DQ channels:
The following is the list of the channels with the new recording rate:
Tonight was a sad night... We continued to pursue our strategy, but with very poor results:
We kept struggling with the PRMI, although it was a little better than yesterday:
So, still no exciting news, but PRMI lock seems to be improving a little.
I'm leaving the PRC aligned and locked. Feel free to unlock it, or do whatever with the IFO.
I wrote the script with the recipe we used, using the Yarm and AS55 on the IN2 of the CM board; however, the steps where the offset should be reduced are not completely deterministic, as we saw that the initial offset (and, therefore, the following ones) could change because of different states we were in. In the script I tried to "servo" the offset using C1:LSC-POY11_I_MON as the reference, but in the comments I wrote the actual values we used during our best test; the main points of the recipe are:
I tried the procedure and it seems fine, as it did during the tries Q and I made; however, since it touches many things in many places, one should be careful about which state the IFO is into, before trying it.
The script is in scripts/CM/CM_Servo_OneArm_CARM_ON.py and in the SVN.
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.
Unfortunately, we only had one good CARM offset reduction to powers of about 25, but then my QPD loop blew it. We spent the vast majority of the night dealing with headaches and annoyances.
Things that were a pain:
I found the PSL enclosure open (about a feet wide) on the north side this morning. I am assuming that whoever did the X beatnote alignment last night forgot to close the door to the enclosure before locking attempts
Here is a lock loss from around 11 PM tonight. Might be due to poor PRC signals.
This is with arm powers of ~6-10. You can see that with such a large MICH offset, POP22 signal has gone done to zero. Perhaps this is why the optical gain for PRCL has also dropped by a factor of 30 .
This seems untenable . We must try this whole thing with less MICH offset so that we can have a reasonable PRCL signal.
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.
As the measurements have been done under feedback control, the lower RF peak height does not necessary mean
the lower optical gain although it may be the case this time.
These non-33MHz signals are embarassingly high!
We also need to check how these non-primary RF signals may cause spourious contributions in the error signals,
including the other PDs.
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.
For future reference, I've taken spectra of our various RFPDs while the PRMI was sideband locked on REFL33, using a 20dB RF coupler at the RF input of the demodulator boards. The 20dB coupling loss has been added back in on the plots. Data files are attached in a zip.
I also completely removed the cabling for REFLDC -> CM board, since it doesn't look like we plan on using it anytime in the immediate future.
After some discussion with Koji, I've asked Steve to order some SBP-30+ bandpass filters as a quick and cheap way to help out REFL33. (Also some SBP-60+ for 55MHz, since we only have 1*fmod and 2*fmod bandpasses here in the lab).
33MHz sidebands can be elliminated by careful choice of the modulation depths and the relative phase between the modulation signals.
If this condition is realized, the REFL33 signals will have even more immunity to the arm cavity signals because the carrier signal will lose
its counterpart to produce the signal at 33MHz.
Formulation of double phase modulation
m1: modulation depth of the f1 modulation
m2: modulation depth of the f2 (=5xf1) modulation
The electric field of the beam after the EOM
Therefore what we want to realize is the following "extinction" condition
We are in the small modulation regime. i.e. J0(m) = 1, J1(m) = m/2, J2(m) = m2/8, J3(m) = m3/48
Therefore we can simplify the above exitinction condition as
m2 < 0 means the start phase of the m2 modulation needs to be 180deg off from the phase of the m1 modulation.
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.
The nonlinearity in the LSC detection chain (cf T050268) comes from the photodetector and not the demod board. The demod board has low pass or band pass filters which Suresh installed a long time ago (we should check out what's in REFL33 demod board).
Inside the photodetector the nonlinearity comes about because of photodiode bias modulation (aka the Grote effect) and slew rate limited distortion in the MAX4107 preamp.
With the Y Arm locked, we checked that we indeed can get loop decoupling using this technique.
The guess filter that we plugged in is a complex pole pair at 1 Hz. We guessed that the DC gain should be ~4.5 nm count. We then converted this number into Hz and then into deg(?) using some of Jenne's secret numbers. Then after measuring, we had to increase this number by 14.3 dB to an overall filter module gain of +9.3.
The RED trace is the usual 'open loop gain' measurement we make, but this time just on the LSC-MC path (which is the POY11_I -> ETMY path).
The BLUE trace is the TF between the ALS-Y phase tracker output and the FF cancellation signal. We want this to be equal ideally.
The GREEN trace is after the summing point of the ALS and the FF. So this would go to zero when the cancellation is perfect.
So, not bad for a first try. Looks like its good at DC and worse near the red loop UGF. It doesn't change much if I turn off the ALS loop (which I was running with ~10-15x lower than nominal gain just to keep it out of the picture). We need Jenne to think about the loop algebra a little more and give us our next filter shape iteration and then we should be good.
I have been able to recover the ability to sit at zero CARM offset while the PRMI is locked on RELF33 and CARM/DARM are on ALS, effectively indefinitely. However, I feel like the transmon QPDs are not behaving ideally, because the reported arm powers freqently go negative as the interferometer is "buzzing" through resonance, so I'm not sure how useful they'll be as normalizing signals for REFL11. I tried tweaking the DARM offset to help the buildup, since ALS is only roughly centered on zero for both CARM and DARM, but didn't have much luck.
Turning off the whitening on the QPD segments seems to make everything saturate, so some thinking with daytime brain is in order.
How I got there:
It turns out triggering is more important than the phase margin story I had been telling myself. Also, I lost a lot of time to needing demod angle change in REFL33. Maybe I somehow caused this when I was all up on the LSC rack today?
We have previously put TRX and TRY triggering elements into the PRCL and MICH rows, to guard against temporary POP22 dips, because if arm powers are greater than 1, power recylcing is happening, so we should keep the loops engaged. However, since TRX and TRY are going negative when we buzz back and forth through the resonsnace, the trigger row sums to a negative value, and the PRMI loops give up.
Instead, we can used the fortuitously unwhitened POPDC, which can serve the same function, and does not have the tendancy to go negative. Once I enabled this, I was able to just sit there as the IFO angrily buzzed at me.
Here are my PRMI settings
REFL33 - Rotation 140.2 Degrees, -89.794 measured diff
PRCL = 1 x REFL33 I; G = -0.03; Acquire FMs 4,5; Trigger FMs 2, 9; Limit: 15k ; Acutate 1 x PRM
MICH = 1 x REFL33 Q, G= 3.0, Acquire FMs 4,5,8; Trigger FM 2, 3; Limit: 30k; Actuate -0.2625 x PRM + 0.5 x BS
Triggers = 1 x POP22 I + 0.1 * POPDC, 50 up 5 down
Just for kicks, here's a video of the buzzing as experienced in the control room
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://22.214.171.124:8080/40m/11043
The goals are:
- When the REFL path is dead (e.g. S_REFL = 0), the system goes back to the ordinary ALS loop. => True (Good)
- When the REFL path is working, the system becomes insensityve to the ALS loop
(i.e. The ALS loop is inactivated without turning off the loop.) => True when (...) = 0
Are they correct?
Then I just repeat the same question as yesterday:
S is a constant, and Ps are cavity poles. So, approximately to say, (...) = 0 is realized by making D = 1/G_REFL.
In fact, if we tap the D-path before the G_REFL, we remove this G_REFL from (...). (=simpler)
But then, this means that the method is rather cancellation between the error signals than
cancellation between the actuation. Is this intuitively reasonable? Or my goal above is wrong?