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.
I just realized that the "damprestore" script that can be called from the watchdog screen did not have the new oplev names. I have updated it, and added it to the svn.
I think we've seen this in simulations, but it's a little disheartening to see in real life. AS55Q looks like it flattens out pretty significantly right around the DARM=0 point.
Right now I have the arms held on ALS (CARM=-1*MC2, DARM=2*ETMY, as Q used last night), and the PRFPMI is on REFL165I&Q. I have set CARM to be as close to zero offset as I can (so I get all the usual buzzing), and then I'm sweeping the DARM offset between +3 and -3 counts (roughly +/-3nm) with a 3 second ramp and looking at normalized AS55Q. The channel called "DARM_B_ERR" is 0.006*AS55Q/(TRX + TRY). The arm transmissions, as well as the ASDC are plotted as well - ASDC is scaled to fit on the same axes as the transmissions.
Anyhow, here's the time series of the DARM sweeps. AS55 demod phase of -55 degrees seems to give the cleanest signal (within 5deg steps); this is the same phase that we've been using all week.
We played around tonight with different possible ways of transitioning DARM to normalized AS55Q. Before each try, we would use ezcaservo (or just eyeball it) to make sure that the normalized RF signals had a mean of zero, so that we knew we were pretty close to zero offset in both CARM and DARM.
We tried something that is similar in flavor to Kiwamu's self-locking technique - we summed in some normalized AS55Q to the DARM error point (using the DoF selector matrix that I created a few weeks ago), and then tried to engage a little low frequency boost. We tried several times, but we never successfully made the transition.
In the end, we just did a direct transition over to normalized AS55Q, and lost lock after several seconds. The buzzing that we hear didn't change noticeably after the transition, which indicates that most of the noise is due to CARM (which makes since, since it has a much smaller linewidth). The problem with holding DARM is that occassionally we will have a CARM fluctuation that lets the arm power dip too low, and DARM's error signal isn't valid at low arm powers. So, we need to work on getting CARM stabilized before we will have a hope of holding on to DARM.
Here's the lockloss plot from that last lock:
Also this evening, I scanned back and forth over the CARM zero crossing while locked on ALS, to see what the RF error signals looked like. Normalized REFL55 seems to have much more high frequency noise near the edges of the linear range than does REFL11. Also, the REFL 11 signal is much larger. So, what I think I want to try to do is use ALS fool to lower the CARM noise by a bit, then make the DARM transition. Then, we can come back to CARM and ramp up the gain.
With these CARM sweeps, I think that I know the relative gain and sign between ALScomm and the normalized REFL signals, and the REFL signals versus the normalized versions. I think that 100*REFL11I/(TRX+TRY) gives the same slope at the zero crossing as just plain REFL11I. Same factor of 100 is true for REFL55I. The REFL11 slope is 20,000 times larger than the ALS slope, while the REFL55 slope is -500 times the ALS slope (note that REFL55 has a minus sign). We can probably trigger the Fool on when the arm powers are above 50, and trigger off when they're below 20. For the zero crossings, the REFL55 threshold should be about 20, and the REFL11 threshold should be about 500.
I also need to re-think the triggering logic for ALSfool. We probably don't want the zero crossing logic to be able to un-trigger the lock, just in case we get an extra noise blip. So, we want to trigger on with an AND, but only trigger off if the arm powers go too low. Also, the zero crossing logic should look at the normalized error signals, not the plain signals.
We need to modify the ALSwatch logic so that it doesn't look at EPICS values for the thresholding. There may be an updated filter module that includes a saturation monitor, but otherwise we can use the saturation monitor part that is in the OSC section of CDS_PARTS. We'll set the threshold on this to match the limiter in the filter bank. Then, if the filterbank output is constantly hitting the limiter, we should run the down scripts.
This is work that I did yesterday but didn't have time to elog. Since it seems non-trivial to give ourselves ramping matrices, but we only really needed the ramping in the DoF selector matrices, I've replaced the separate _A and _B parts with full filterbanks. Recall from elog 10910 that I had given each degree of freedom's _A and _B input options an offset, an epics monitor and a test point. Now those are removed, and handled inside of the filter banks. The outputs of the filter banks sum together.
This required some screen modifications, but everything should work the same way that it did before this change. I've also changed the DAQ channels from the _A_ERR and _B_ERRs that I had hand-created to now be the _A_OUT and _B_OUT test points from the filter banks (acquired at 2048Hz).
I have not yet modified the burt snapshots for the ifo configure screen. The arms will work the same as always, since they didn't have any selector matrix stuff ever, but the rest still need tweaking.
More work from yesterday.
Rana and I had discussed on Thursday night that we probably want to be able to use the zero crossing of an error signal to trigger a servo on, but not to un-trigger it. So, now the zero crossing trigger is latched, using the power trigger to reset the latch.
Also, the input to the zero crossing trigger is the input to the MC servo, before the triggered switch. This allows us to look at the normalized error signals rather than just the non-normalized ones, if that's what we're trying to lock on. This signal is taken before the triggered switch, so that it's looking at whatever is coming out of the input matrix (including normalization).
So. If the absolute value of the MC error signal goes below the threshold, it outputs a 1, no matter what the arm power is. If the arm power is high, the power trigger also outputs a 1. These are AND-ed together, so only if both are 1 do you actually trigger the MC filter bank. If the zero crossing trigger has been set to 1, it will stay at 1 until the arm power goes low enough to untrigger the power trigger. So, even if you have a little bit of noise on the error signal and it pops above the threshold momentarily, this won't cause the servo to un-trigger.
This is implemented using a "set-reset latch". The output of the latch is the zero crossing trigger, which is AND-ed with the power trigger. This final AND-ing, in addition to doing what we want, solves the ambiguity that is inherent in SR-latches for one combination of inputs.
The trigger screen has been modified to reflect these model changes.
Here's a screenshot of the model, which includes some notes for anyone who opens the model since it's a bit confusing:
Last report on model change / screen work from yesterday.
The ALSwatch script has always been just looking at the EPICS output of the CARM and DARM filter banks, and if it saw a single saturation, it would run the down script. This was non-ideal because (a) the EPICS channels aren't the real signals, and (b) sometimes we'll hit the rails briefly and that's okay - we want to shut things down only when we're constantly saturating.
It turns out that there was a pre-existing saturation monitor part in CDS_PARTS, which I have used. There is one each looking at the output of the CARM and DARM filter banks. The threshold for what saturation means is set as an epics input. The part outputs a running count (number of saturations since the last time it was not saturated, resets each time it goes non-saturating) and a total number since the last reset (also an epics input).
(To be continued... still writing)
[Jenne, with Matt and Fujimi as witnesses]
It might be about time to throw that champagne in the fridge. Nice. Not quite close enough to talk about popping it open, but we'll want it chilled just in case...
I still haven't logged yesterday's work, and I'm still working now, so no details, but I just handed both CARM and DARM over to non-normalized RF signals, and had the arms stable at powers of about 105. I was workinig on the ETM alignment, and the power was increasing, so I think that's where the extra power will come from. I was lowering the DARM gain as I improved the alignment, because the optical gain was increasing so much. I probably just didn't do that fast enough for the last aligning, which is why I lost lock.
Anyhow, here's a plot, because I'm excited:
I have in my notebook that at 9:49pm CARM was no longer using ALS as an error signal, and at 9:50pm, DARM was no longer using ALS as an error signal. It looks like I was locked for 3+ minutes after getting to RF-only signals.
The increase in power near the end of the lock stretch was me trying to improve the dark port contrast by touching the ETMX alignment. DARM was definitely oscillating as I improved the dark port contrast, so I was trying to hand-lower the gain as I worked on the alignment.
This elog will be about work that happened yesterday. I will write a reply to this with work from this evening's success.
Work started with the plan of trying ALS fool, using the new triggering scheme (elog 11114).
The PRMI was having a bit of trouble holding lock with REFL165, so we checked its demod phase. On Monday (elog 11095) we rotated the REFL165 phase from -91 deg to -48 deg while in PRFPMI configuration (I think the -91 was from PRMI-only phase setting). However, Friday night we saw that MICH was super noisy, especially when the CARM and DARM offsets were near zero. Rana rotated REFL165's phase until the MICH noise seemed to get lower (by at least an order of magnitude in the control signal), while we were at zero offset everywhere. We were not driving and looking at any lines/peaks, just the overall spectra. The final REFL165 demod phase is -80.
We tried engaging the fool path with no success.
First, Rana moved the low frequency boost in the MC filter bank from 20:1 to 0.3:0.03. This gave the whole loop at least 20 or 30 degrees of phase at all frequencies below the design UGF (a few hundred Hz? Don't quite remember). To check this, we put in a "plant" filter, and turned on the locking filter (3:3000^2) and the low freq boost and the plant, and the phase never touched 180 at any low freq. This is so that we can ramp on this filter bank's gain without having an unstable unity gain crossing anywhere. Also, I added two +10dB filters to the first two filter modules, so that we could ramp on the gain at the input rather than the output.
Last night we were actuating CARM on MC2 and DARM on the ETMs, and the MC filter bank was set to actuate on MC2. Even with super duper low gain in the MC filter bank, so that the control signal was much less than one (1) count, it would make CARM unhappy. The CARM filter bank's output was doing +/- a hundred or more counts, so why a few tenths of a count mattered, we couldn't figure out. We were using the power trigger for the MC filter bank, but not the zero-crossing trigger. Since the fool tuning was checked while actuating on the ETMs, we wonder if maybe the tuning isn't valid for MC2 actuation? Maybe there's enough of a difference between them that the fool needs to be re-tuned for MC2 actuation? Fool had the complex pair of poles at 1Hz, the "comp1" filter to give phase lag, and a gain of 22.
I think that at some point we even turned off the fool path, but left the MC path on with a little bit of gain, and the audible noise over the speakers didn't seem to change in character at all. Weird.
We ended up leaving the fool path for another time, and started working on error signal blending at the CARM filter bank input. This is pretty similar to Kiwamu's self-locking principle.
Our goal was to ramp up the gain of the RF error signal at low frequency, while letting ALS keep hold of things at higher frequencies.
CARM and DARM sweeps from earlier seemed to indicate that the RF signals are valid without normalization above transmitted powers of 50 or so, so we thought we'd give those a whirl for this error signal blending.
From doing a CARM sweep through resonance, we guessed roughly that the REFL11 (non-normalized) slope was about a factor of 10,000 larger than the ALS slope. We put a 1e-4 into the input matrix element REFL11I -> CARM_B. For some reason, REFL11 seemed to be centered around -250 counts, so we put an offset of +0.025 ( = 250*1e-4) into the CARM_B filter module to compensate for this.
Since we thought that a gain of 1 in the CARM_B filter bank would make it equal to ALS, we tried some lower gains to start with. 0.3 kicked it out of lock, so we ended up liking and using 0.15. With this low gain on, we tried turning on a low frequency boost, 20:1, but that didn't do very much. We turned that off, and instead turned on an integrator, 20:0, which totally made things better. The transmitted arm power was staying higher more of the time.
From a DARM sweep, we thought that AS55Q (non-normalized) should also have an input matrix element of 1e-4 for DARM. We gave DARM_B a gain of 0.1, which seemed good and not too high. Again, trying the gentle boost didn't do much, so we went with the integrator.
At this point, since both RF signals were being used as error signals with integrators, we declared that at least at DC we were on RF signals. Hooray!!
After this, we started increasing the CARM_B gain a little, and decreasing the CARM_A gain. When Rana finally set the CARM_A element to zero, we lost lock. We realized that this is because we didn't include a zero to compensate for the arm cavity pole, which the IR signal will see, but the ALS won't.
We decided that the plan of attack would be to get back to where we were (DC error signals on RF), and try to start engaging the AO path.
As I (very excitedly) reported in elog 11116, I was able to follow the error signal blending procedure from last night, and get CARM and DARM onto digital non-normalized RF signals. The lock held for about 3 minutes after this transition (elog 11118 has plot of this).
I was then able to script what I did (in the carm_up script), and repeat the transition. Q joined me in the control room, but we have not been able to complete the transition a third time.
Here's the sequence that worked the two times:
After those two attempts, we ran the LSC offset script, since that hadn't been done since early yesterday. We did a quick CARM sweep, and REFL11 seemed to be centered around 0 counts, so we removed the 0.025 count offset from the CARM_B filter bank.
For later attempts, we keep seeing oscillations in the lockloss plots around 50 Hz, as if we're seeing gain peaking at the low side of the phase bubble. We have tried turning off various filters at various levels of RF gain, but none of the combinations seems to be excellent. Turning off the FM6 bounce/roll filter in CARM was particularly bad (immediately lost arm transmitted power), but others weren't good either (eg turning off FM3 boost lost arm powers within a second or so). When we lose arm powers, the RF signals aren't valid, so if you don't turn them off fast enough (and ALS is still on with enough gain), you'll lose the full IFO lock. If you're fast though, you can turn off the CARM and DARM _B outputs and not have to start from scratch.
There seemed to be a very fine line to walk between not enough gain (~50Hz oscillations), and too much gain (200-300Hz oscillations). It has been pretty frustrating later in the evening. We seem to only have about 3dB of gain margin on the low side, when all the boosts are on. Not excellent.
When the RF signals had a moderate amount of gain, but ALS was still holding CARM and DARM, Q checked the phases of REFL11 and AS55 with excitation lines. He rotated AS55 from -55 deg to -30 deg (+25 deg) and REFL11 from 144 deg to 164 deg (+20 deg).
Prior to the all-digital attempts, I tried several times to turn on the AO path, without success. I think that the best that I got was 0dB on the CM board input 1 gain, +14dB on the CM board's AO gain, and -30dB on the MC board's AO gain before the mode cleaner lost lock.
I was hoping that I could get CARM entirely to RF signals, and that would make things more stable and less complicated, and I could try again to turn on the AO path, but we haven't been able to do this tonight.
A few times in the later attempts we tried turning on the UGF servos for CARM or DARM. I'm not sure if the lines kicked things out of lock, or if the UGF servos went a little crazy, or what, but we never survived for more than a few seconds after turning on the excitations.
There is a problem with the optical lever servos. I had thought I'd been seeing it ever since Q re-did the models, and now I'm pretty sure that's what's up. Q is hot on the trail of figuring out what may have changed that shouldn't have. We may want to revert to an old Foton file, and re-copy the old filters into the new filter banks just in case. The watchdog damprestore scripts have been tweaked to clear the oplev filter bank histories before turning on the oplevs, and this seems to solve the symptom of kicking the optic when oplevs are engaged.
Although we haven't been able to make the transition to RF-only a third time, I think we're getting there. Progress has certainly been made in the last 2 days!
Here is a longer stretch of data, from the first RF-only lock on Saturday night. Unfortunately daqd had died about 400 seconds before the lockloss, so I can't show the RF signals coming on.
ALS was on the _A channels for CARM and DARM, so when those go to zero (about -300 seconds for CARM, and about -200 seconds for DARM), we're using RF signals only for the error signals.
CARM noise definitely improves, but holy smokes does DARM start to look good! Although, right at the end it starts to look like REFL11I is getting bigger. Not sure why, but we'll have to watch out for this.
Here's the equivalent plot for the second lock stretch. This is the one that was handled by the carm_up script. It looks like I had about 150 seconds of RF-only lock here.
DARM error is getting bigger with time jnear the end, even though I wasn't working on alignment here. Zooming in, DARM is oscillating at 16.4 Hz, which is the bounce frequency. I thought I had my bounce/roll filters on, but somehow it still got a little rung up. It just rings up to a steady state though, it's not getting huge, so I don't know that it was the cause of the lockloss.
Back on Feb 20th (elog 11056) Q replaced all of our oplev parts with the aLIGO version.
Unfortunately, after this it has seemed like there was something not quite right with the optical lever servos.
Since, when the models were changed which gave us an extra underscore in the oplev names, Q did a find-and-replace in the foton text files, I was worried that this might have broken things. I'm not entirely sure how it would have broken them (I didn't see any difference in a diff), but I've heard enough horror stories about the delicacy of the foton text files.
Anyhow, I opened the last archived foton files from just before Q made the change, and copy-and-pasted the design strings from the old filter banks to the new ones. Hopefully this fixes things.
I have looked at the CARM and DARM RF loops, assuming the loop shapes that we've been using, and it pretty much looks like a miracle that we were ever able to make the transition. The CARM and DARM loops are very marginal.
The ALS CARM loop was already pretty close to marginal, but we lose an extra 12 degrees of phase with the REFL loop:
However, if our cavity pole compensator's zero frequency is too low, we get all of that phase back, at the sacrifice of 2dB of gain margin at both ends of the phase bubble.
I looked at an Optical simulation to check what the cavity pole frequencies are expected to be, with the losses that we've measured. In both cases, I assume the Xarm has about 150ppm of loss. The DARM cavity pole is about 4.5kHz no matter what the Yarm loss is. The CARM cavity pole is about 172 Hz if the Yarm has 500ppm of loss, or 120 Hz if the Yarm has 200ppm of loss.
In the plots below, I use a CARM cavity pole frequency of 150 Hz, to roughly split the difference.
Edit, 13Mar2015, JCD: Rana points out to me that I was using from Foton the analog design strings, without including the fact that these are actually digital filters. This means that I am missing some phase lag. Eeek.
The ALS loop includes:
The REFL loop includes:
The first plot is the case of perfectly matched cavity pole and compensating zero (150Hz, with compensator having 3kHz pole):
This next version is the case where the compensating zero is a little too low, which is the case I think we have now:
The last plot is a DARM loop. Everything is the same, except that the RF plant has a 4.5kHz pole, and no compensation:
No wins tonight.
I've tried playing with the shapes of the loops a little bit (mostly CARM so far), to no avail. I think I made it to CARM RF-only only one time tonight. I was able to turn on the REFL11 whitening, although I lost lock while about halfway through the DARM transition.
I tried making a double integrator instead of a single integrator for CARM_B, since that would allow me to make a complex zero pair which could help win back some phase. I also tried just straight copying FM1 from CARM into CARM_B, so that it could be turned off for the ALS part of the loop, but left on for the REFL part, but that didn't work very well. Like Rana and I saw last Friday, we really need the REFL signal to have a true integrator, to force the PDH signal toward zero, before we can complete the transition.
I moved the cavity pole compensator's zero back up to 120 Hz, since that was what had worked on Saturday night. That helped me get farther before running into gain peaking problems at ~50Hz. This is because, as seen in my simulation earlier tonight, I win back some gain margin by having the pole compensator more closely matched with the pole frequency.
I've been turning off both FM1 and FM2 in CARM and DARM. I think this is helping a lot, when I can get far enough to do so. I don't want to turn off the second boost until after I'm about 50/50 on REFL. (When I have that much REFL, with the true integrator, the PDH signal sticks to zero).
I tried once turning off the bounce/roll filters for CARM and DARM, rather than the FM1 boost, since the bounce roll filters eat lots of phase, but I got pushed off resonance. I think not having that focused boost may have made my overall RMS larger, which caused me to randomly jump too far outside of the good PDH range.
Early on in the evening, I turned off the MC2 violin filters in the ETM LSC-SUS filter banks, since I am actuating on only the ETMs tonight. However, I saw a violin mode ring up at ~642, which showed up in POX but not POY. This was causing up-conversion, beating against the 40-50Hz buzzing from the IR resonance. The MC2vio1,2 filter covers this frequency (because it's an absurdly wide notch), but the EXYvio1 filter does not. There seems to be some confusion on the wiki as to what the ETMX violin mode frequency is - it says 631 (638??). The notch that is in the EXYvio1 filter is for 631 Hz, but this is not correct. DAYTIME self: Make the MC2 violin filter smaller than 40Hz(!) wide, and move the ETMX notch up to the correct frequency. For tonight, I just turned back on the MC2 filter, and the mode has rung down.
Idea: MICH offset, or ETM misalignment, enough to keep the power recycling low-ish, so that the CARM cavity pole doesn't come down too far in frequency? Daytime brain should think about this.
Much more success tonight. I only started my tally after I got the CARM transition to work entirely by script, and I have 6 tally marks, so I probably made the CARM to RF-only transition 7 or maybe 8 times tonight in total. Unfortunately, I only successfully made the DARM transition to AS55 once. From the wall striptool, counting the number of times the transmitted power went high, I had about 40 lock trials total.
The one RF-only lock ended around 1:27am.
I think 2 things were most important in their contributions to tonight's success. I modified the bounceRoll filters in the CARM and DARM filter banks to eat less phase. Also, using Q's recipe as inspiration, I started engaging the AO path partway through the CARM transition which makes it much less delicate.
Bounce roll filter
Koji and I added a ~29Hz resonant gain in the bounce roll filter several months ago, to squish some noise that we were seeing in the CARM and DARM ALS error signals. This does a lot of the phase-eating. I'm assuming / hoping that that peak won't be present in the CARM and DARM RF error signals. But even if it is, we can deal with it later. For now, that peak is not causing so much motion that I require it. So, it's gone.
This allowed me to move the complex zero pair from 30 Hz down to 26 Hz. Overall I think this gained me about 10 degrees of phase at 100Hz, and moved the low end of the phase bubble down by about 10Hz.
Prep for REFL 11 I through the CM board and CM_SLOW
In order to use Q's recipe (elog 11138), I wanted to be able to lock CARM on REFL11 using the CM_SLOW filter bank.
I did a few sweeps through CARM resonance while holding on ALS, and determined that the REFL1 input to the CM board needed a gain of -20dB in order to match the slope of CM_SLOW_OUT to CARM_IN (ALS), leaving all of Q's other settings alone. Q had been using a REFL1 gain of 0dB for the PRY earlier today.
I needed to flip the sign in the input matrix relative to what Q had (he was using +1 in the CM_SLOW -> CARM_B, I used -1 there). To match this in the fast path, I flipped the polarity of the CM board (Q was using minus polarity, I am using positive).
The CM_SLOW filter bank had a gain of 0.000189733. I assume that Q did this so that the input matrix element could be unity. I left this number alone. It is of the same order as the plain REFL11I->CARM input matrix element of 1e-4 from Saturday night, so it seemed fine.
During my sweeps through CARM resonance, I also saw that I needed an offset to make CM_SLOW's average about 0. With the crazy gain number, I needed an offest of -475 in the CM_SLOW filter bank. As I type this though, it occurs to me that I should have put this in the CM board, since the fast path will have an offset that isn't handled. Ooops.
Trying Q's recipe for engaging AO path
I am able to get the MC2 AO gain slider up to -10dB (-7 is also okay). If I increase the digital CARM gain too much, I see gain peaking at about 800Hz, so something good is happening. (That was with a CARM_B gain of 2.0 and CARM_A gain of 0. Don't go to 2.0)
I tried once without engaging his 300:80 1/f^2 filter in the CM_SLOW filter banks to start stepping up the CM REFL1 and MC AO gains together, but I only made it 2 steps of 1dB each before I lost lock.
I tried once or twice turning on that 300:80 filter that Q said over the phone really helped his PRY locking, but it causes loop oscillations in CARM. Also, I forgot to turn it off for ~45 minutes, and it caused several locklosses. Ooops. Anyhow, this isn't the right filter for this situation.
AS55 whitening problem
Twice I tried turning on the AS55 whitening. Once, I was only partly transitioned from ALSdiff to AS55, the other time was the one time I made the full transition. It caused the lockloss from the only RF-only lock I had tonight :(
Unfortunately I don't have the time series before the whitening filters (not _DQ-ed), but you can see a giant jump in the _ERR signals when I turn on the whitening, just before the arm power dies:
The AS55 phase is -30, I has an offset of 28.2 and Q has an offset of 6.4. Both have a gain of 1. This should give us enough info to back out what the _IN1 signals looked like before I turned on the whitening if that's useful.
Other random notes
Ramp times for CARM_A, CARM_B, DARM_A and DARM_B are all 5 seconds. This is set in the carm_cm_up script.
carm_cm_up script freezes the arm ASS before it starts the IR->ALS transition, to make it more convenient to run the ASS each lockloss.
carm_cm_up script no longer has a bunch of stuff at the bottom that we're not using. It's all archived in the svn, but the remnants from things like variable finesse aren't actively useful.
carm_cm_down script turns off the CM_SLOW whitening (which gets set in the up script)
carm_cm_down script clears the history of the ETM oplevs, in case they went bad (from some near divide-by-zero action?), but the watchdog isn't tripped. This clears away all the high freq crap and lets them do their job.
FSS Slow has been larger than 0.55 all night, larger than 0.6 most of the night, and larger than 0.7 for the last bit of the night. MC seems happy.
both carm_cm_up and carm_cm_down are checked into the svn. The up script is rev 45336 and the down script is 45337.
Some offset (maybe the fact that the fast AO path had an un-compensated offset?) is pulling the arm powers down as I make the transitions:
After that, I by-hand made the DARM transition on the 6th successful scripted CARM transition, and tried to script what I did, although I was never able to complete the DARM transition again. So, starting where the recipe left off above,
Since DARM doesn't have an analog fast path, it is stuck in the delicate filter situation. I think that I should probably start using the UGF servo once the arm power is stable so that DARM stays in the middle of its phase bubble.
Rather than typing out the details of the recipe, I am attaching the up script.
[Jenne, Koji, Rana]
Thanks to turning off the AS55 analog whitening as well as the 1k:6k lead filter that Koji put into Darm's FM7, the DARM transition was more stable early in the evening.
The AS55 gain and offset did not change noticeably when we switched the AA on or off (switching happened while *not* using AS for any feedback). Earlier in the evening, we did also check what happened with PRMI and REFL33 AA on vs. off, and REFL33 did have a many tens of counts offset on both the I and Q input channels. I have turned the AA filters back on, but run LSCoffsets before trying to lock.
I'm not sure what was up, but somehow I couldn't lock the PRMI for about half an hour or so. Very frustrating. Eventually after futzing around, I was able to get it to lock with REFL33 in PRMI-only, and after that it worked again in PRFPMI with REFL165.
With FSS slow around 0.5, MC has been a bit fussy the last hour. Also frustrating.
Later on in the evening, I started taking out a bunch of the "sleep" commands from the up script, and many of the "press enter to continue" spots, but I think it might be moving too fast. That, or I'm just not catching where I have too much gain. Anyhow, near the middle/end of the CARM transition I am getting severe gain peaking at several hundred Hz. I think I need to use a lower final gain.
So, progress on DARM, but maybe a little more fine-tuning of CARM needed.
Here's a DARM loop measurement, taken after both CARM and DARM were RF-only:
I have modified the DARM model from elog 11133, to include the fact that these are digital filters.
I have also extracted the data from elog 11143, and it together with the model.
The modeled loop has an arbitrary gain factor, to make it have the same 234Hz UGF as the measured data.
The modeled loop includes:
There is a 1.5 degree phase discrepancy at 100Hz, and an 11 degree phase discrepancy at 900Hz, but other than that, the modeled and measured loops match pretty well.
For the measured frequencies, here are the residuals:
I've done a few things to start waking up the IFO after it's week of conference-vacation.
PMC trans was at 0.679, aligned the input to the PMC, now it's up at 0.786.
MC transmission was very low, mostly from low PMC transmission. Anyhow, MC locked, WFS relieved so that it will re-acquire faster.
Many of the optics had drifted away. AS port had no fringing, and almost every optic was far away from it's driftmon set val. While putting the optics back to their driftmon spots, I noticed that some of the cds.servos had incorrect gain. Previously, I had just been using the ETMX servo, which had the correct gain, but the ITMs needed smaller gain, and some of the optics needed the gain to be negative rather than positive. So, now the script ..../scripts/SUS/DRIFT_MON/MoveOpticToMatchDriftMon.py has individually defined gains for the cds.servo.
Next up (after lunch) will be locking an aligning the arms. I still don't have MICH fringing at the AS port, so I suspect that the ASS will move some of the optics somewhat significantly (perhaps the input tip tilts, which I don't have DRIFT_MON for?)
In addition to (and probably related to) the XARM ASS not working today, the ITMX has been jumping around kind of like ETMX sometimes does. It's very disconcerting.
Earlier today, Q and I tried turning off both the LSC and the oplev damping (leaving the local OSEM damping on), and ITMX still jumped, far enough that it fell off the oplev PD.
I'm not sure what is wrong with ITMX, but probably ASS won't work well until we figure out what's up.
I tried a few lock stretches (after realigning the Xgreen on the PSL table) after hand-aligning the Xarm, but the overall alignment just isn't good enough. Usually POPDC gets to 400 or 450 while the arms are held off resonance, but today (after tweaking BS and PRM alignment), the best I can get POPDC is about 300 counts.
Den and I are looking at the ASS and ITMX now.
The problem with the ASS turned out to be a mode that was rung up at 1326Hz in ETMX. It was rung up when the Xarm's overall gain was too high. So, by turning down the digital gain we were able to prevent it ringing up, and then the ASS worked. To circumvent this, we added a notch to the violin filter bank. It turned out that, upon trying to check if this existed also for the Yarm by turning up the digital gain, the ETMY frequency was almost identical. So, the same single notch is in both ETMs, and it covers the modes for both ETMs.
After that, we got back to locking. We have made at least 9 transitions to all-RF (both CARM and DARM) tonight (I have lost track of how many Den has done while I've been writing this - maybe we're up to 10 or so.). We have changed the order of things a little bit, but they're mostly similar to last week. There are some new notches in the CARM_B filter bank, as well as a 700Hz low pass. We have not been using the lead filter in DARM from last week. Script is checked in, and also zipped and attached. At first CARM was actuating on ETMs, but the last half of the locks we've been using MC2. The script is optimized for MC2 actuation.
While locked all RF, we phased REFL55 in preparation for transitioning PRMI over from REFL165. REFL55 phase was +125, now is +80, give or take 5 deg. We have tried measuring the relative gain and sign between REFL55 and REFL165, but we keep losing lock, perhaps as a result of the TFs Den is taking. He's being gentle though.
Measure CARM loop (why was SRmeasure not working?? is it plugged in??)
Turn on AO boosts, etc.
Overall a "meh" night for locking I think. The script to all-RF worked several times earlier in the evening, although it was delicate and failed at least 50% of the time. Later in the evening, we couldn't get even ~10% of the lock attempts all the way to RF-only.
Den looked into angular things tonight. With the HEPA bench at the Xend on (which it was found to be), the ETMX oplevs were injecting almost a factor of 10 noise (around 10ish Hz?) into the cavity axis motion (as seen by the trans QPD) as compared to oplevs off. Turning off the HEPA removed this noise injection.
Den retuned the QPD trans loops so that they only push on the ETMs, so that we can turn off the ETM oplevs, and leave the ITMs and their oplevs alone.
We are worried again about REFL55. There is much more light on REFL55 than there is on REFL11 (a 90/10 beam splitter divides the light between them), and we see this in the DC output of the PDs, but there seems to be very little actual signal in REFL55. Den drove a line (in PRCL?) while we had the PRMI locked with the arms held off resonance, and REFL55 saw the line a factor of 1,000 less than REFL 11 or REFL165. The analog whitening gain for REFL11 is +18dB, and for REFL55 is +21dB, so it's not that we have significantly less analog gain (that we think). We need to look into this tomorrow. As of now, we don't think there's much hope for transitioning PRMI to REFL55 without a health checkup.
After discussions during the meeting today, I removed the PBS from the REFL path, which gives much more light to REFL11, REFL33 and REFL55. Also, the ND1.5 in front of REFL165 was replaced with ND1.1, so that REFL165 now gets 50mW of light. REFL11 gets about 1.3mW, REFL33 gets about 13mW and REFL55 gets about 12mW.
No locking, and importantly no re-phasing of any PDs has been done yet.
Here is an updated diagram of the REFL branching ratios.
Some more words on yesterday's REFL path work.
The 90/10 BS that splits the light between REFL11 and REFL55 was placed back in August 2013, to compensate for the fact that REFL11 has a much larger RF transimpedance than REFL33. See elog 9043 for details.
We had been operating for a long time with an embarrasingly small amount of light on the REFL PDs. REFL11 used to have 80 uW, REFL33 used to have 400 uW and REFL55 used to have 700 uW. REFL 165 was the only sane one, with about 15 mW of light.
After yesterday's work, the situation is now:
As an aside, I was foiled for a while by S vs. P polarizations of light. The light transmitted through the PBS was P-pol, so the optics directing the beams to REFL11, 33 and 55 were all P-pol. At first I completely removed the PBS and the waveplate, but didn't think through the fact that now my light would all be S-pol. P-pol beam splitters don't work for S-pol (the reflection ratios are different, and it's just a terrible idea), so in the end I used the PBS to set the half waveplate so that all of my light was P-pol, and then removed the PBS but left the waveplate. This means that all of the old optics are fine for the beams going to the 3 gold-box REFL PDs. We don't have many S-pol beamsplitter options, so it was easier to use the waveplate to rotate the polarization.
Before locking for the evening, I wanted to try again implementing the Wiener filters that I had designed back in Jaunary (elog 10959).
The problem then was that the newer version of Quack that I was using was doing weird things to me (elog 10993). But, tonight I used the old quack3andahalf that we used to use for Wiener-related things, and that worked (for up to order 20 filters). Actually, the pitch z-axis Wiener filter, when I copy the command string into Foton, says "Error" in the alternate box (the lower one). I also get this error message if I try to put in filters that were greater than order 20, and have been split into several filters. I'm not sure what's wrong, so for tonight I'm leaving out the pitch z-axis seismometer feed forward, and only using 20th order filters for all the rest.
So, pitch has feed forward signals from the T-240's x and y axes, and yaw has feed forward signals from all 3 seismometer channels.
At first, I just had the calculated Wiener filters, and a 10Hz lowpass, but the POP beam spot on the camera was getting slowly pushed away from the starting location. So, I added a 0.01Hz cheby1 highpass filter, and that seems to have fixed that problem. I need to go back to the simulations though, and see if this is going to cause extra noise to be injected (because of incorrect phase in the feed forward signal) at very low frequencies. All 5 Wiener filter banks have a gain of -1.
I'm getting a factor of 4-5ish between 2Hz and 3Hz in both pitch and yaw. What's interesting is that despite no direct angular suppression (as measured by the QPD) at higher frequencies, both POP22 and POPDC see improvement over a much broader range of frequencies. I'll have to think about how to predict this RIN coupling in my budgets.
The time series data for these filters was collected 2 months ago, on the 29th of January. So, it's nice to see that they work now too (although we have already seen that length feed forward signals are good over a many-month period).
In uncalibrated units (I need to calibrate the QPD to microrad, and should probably quote the PD signals in RIN), here is the plot. Blue trace (taken first) was with the feed forward on. Red trace (taken immediately afterward) was with feed forward off. This data is all PRMI-only, locked on REFL165 using Koji's recipe from elog 11174, including changing REFL165 phase to -14deg (from the -110 I found it at) for the no-arms case.
I got the PRMI transitioned from REFL165 over to REFL55 two times tonight. Also, I had 2 long-ish locks, one 9 minutes, and one 6 minutes. All the other locks were short - less than a minute or two.
I've done some shuffling around of the point in the CARM transition when the anti-boosts (1:20 filters) come on in the CARM A filter bank. I've moved the turn-on of these filters a several gain steps earlier, but I'm not sure that they're in the best place yet. Fiddling with the turn-on of the anti-boosts makes the big CARM oscillations last for longer or shorter - if they last too long, they blow the lock, so we don't want them to get too big.
The PRMI angular feedforward has helped a lot tonight, I think. I've added a line to the up script to enable the output of the OAF after the PRMI is locked, and the down script turns it off again. It's not so great when the PRM isn't aligned, since it's designed to work when the oplev is on, so it should be off unless the PRM is aligned. I tried to get a comparison of off vs. on PRC powers with the arms resonating, but I can't hold the lock for long enough when the OAF is not on to get even one average on my 0.01Hz bandwidth spectrum.
I've turned the arm ASC on a few times, but not every lock. Around 12:34am, I set the offsets when CARM and DARM were on RF signals, and I had hand-aligned the ETMs to minimize the power at the AS port. But, this wasn't a good spot for the next lock - the AS port was much darker with the ASC off for that lock. It would be nice to think about trying some dither alignment, and then maybe resetting the setpoints every lock. I'm using Q's original loop shapes, but as he left them yesterday, only actuating on the ETMs (with Yarm Yaw gain 0.7 rather than 0.9).
The CARM crossover might need more tuning. There's some gain peaking around 400 Hz that goes mostly away if I turn the digital CARM gain down by 2dB. (I'm not using any filters in the CM_SLOW filter bank).
I think that the CARM/DARM transition is more likely to be successful if the FSS slow DC is greater than 0.55ish. So far this is pretty anecdotal, but I think I have more success when it's higher. We should pay attention, and see if our trouble locking later in the nights correlates with smaller FSS slow DC values.
I got the PRMI over to 1f two times, at 1:54am and at 2:25am. I did not re-phase "POP"55 (which is the REFL55 signal), but I did check the values for the input matrix. I needed MICH = 0.01*POP55Q and PRCL = 0.008*POP55I. The first time I lost lock because I turned down the CARM digital gain too much. The second time I forgot to turn down the PRCL gain (I was *actually* using 0.01*POP55I for the PRCL input matrix, but needed to lower the gain from -0.08 to -0.07, which is about the same as just using 0.008 in the input matrix). Anyhow, I think PRCL loop oscillations were the cause of the second lockloss.
Here's a strip chart of my first lock of the night, which was the 9 minute lock. Up until about -6 minutes, I was hand-aligning (including the dip around -7.5 minutes, where I was figuring out which direction to move the ETMs). Around -3.5 minutes there is a significant dip down, that corrected itself. By the time I realized that the power had gone down, and was trying to figure out why, it came back. Maybe the same thing happened at the end of the lock, but it kept getting worse? Self, re-look at this time (around 11:50pm) to find out why the power dips.
My tummy feelings (without any data) make me think that this could be something with ITMX, like Q saw earlier today. Or, maybe ETMX, like we've seen for ages. Anyhow, my tummy feeling says this is an optic pointing problem. I certainly think this might be the same thing we see at the end of many locks, the power going low suddenly. So, it might give a big clue to our locklosses. Maybe.
RXA: I've changed the above text into pink Comic Sans to lend it the appropriate level of gravitas, given its scientific justification.
I'd like to get a concrete list of measurements written down, so that it's clear what needs to be done before I graduate.
Are there things that I'm missing? I've never had an IFO to characterize before.
Have you tried a different set of laser temperatures? I don't remember the value for the Xgreen, but whatever the value that matches PSL of 0.62ish and above seems to put the Xgreen laser at a bad temperature. I think this is the mode-hopping region, and we sometimes lock to the wrong mode.
So, FSS values of above 0.5ish are good, but they should be below 0.61ish.
Have you tried a different set of laser temperatures?
Yep, that is how I got back to stable powers.
I have 12 tick marks for times I got all the way to 1f for all 4 degrees of freedom in the PRFPMI. The CARM / DARM transitions now succeed more than they fail, which is nice.
At Q's suggestion, I am turning off all the violin filters in the MC2 path during the CARM transition. This also means that I don't need any of the notches that Den and I put into the CARM_A and CARM_B filter banks last week, which were right at the edges of the violin notches. Anyhow, this seems to make the transition much more likely to succeed. I don't ever use the CM_SLOW FM10 "crossover helper" that Q had to use last night. The violin filters are turned back on after the CARM transition is complete. We don't ever need those other notches.
I checked the REFL165 vs. REFL55 transfer functions for PRCL and MICH, and they are mostly flat. REFL55 seems like it'll give us extra phase for some reason.
I tried setting offsets for PRMI, but they seem to be strongly dependent on arm alignment. I ended up being pretty confused, and since all the REFL signals are pretty close to zero (when CARM/DARM on RF, PRMI on 3f), I have given up on that avenue for tonight.
I think many of my locklosses tonight (lost from the all 1f state) have been fast things, faster than the ADCs can handle. On the lockloss plots that I've looked at, the FSS PC drive is railed at 10V about 200msec before I lose lock. So, something (presumably in the fast CARM path) is making the MC/FSS loop unhappy. I have plugged in the Agilent to the Out2 of the CM board, so that it looks at REFL11. Unfortunately, this is after the input gain slider, so we don't see much until we're locked, but that seems fine. A video camera is pointed at the screen, so that I get real time spectra. It's hard to watch the TV at the same time as everything else, so I haven't witnessed the moment of lockloss in the fast spectrum yet. Be careful when walking down the Yarm. The tripod is partly in the walkway.
Q, I took a few TFs of the total CARM loop, although none of them are particularly good below a few kHz. I can't push hard enough to get coherence, without blowing the lock. TF data is in /users/jenne/PRFPMI/CM_TFs/CM_TFs_2Apr2015/ .
I was worried for a while that, after I transition PRMI to 1f, I hear lots of low frequency rumbling. However, watching the spectra (relative to references taken with CARM and DARM on RF, but PRMI on 3f), the low frequency error and control signals are staying the same for all 4 DoFs, but the high frequency for PRCL and MICH goes down significantly, so it's probably just that the low frequency stuff sounds more obvious, since it's not drowning in high frequency fuzz.
I think that this happens when the beam gets too close to the edge of the QPD. We see this regularly in the ETMs, if they've been kicked a bit, but not enough to trip the watchdogs. I think it might be the step/impulse response of the RES3.3 filter, which rings for almost 20 seconds.
Anyhow, I've just recentered the BS oplev. It was at -21urad in pitch, and had more than 400 counts on the top two quadrants, but only about 100 counts on the bottom two. Now it's around 300 counts on all 4 quadrants.
As a totally unrelated aside, I have installed texlive on Donatella, so that I could run pdflatex.
Q is writing the locking elog for the night, but just to reply to this thread: The IFO worked well tonight, so things are at least not broken.
Unfortunately, this kind of trend plot is not detailed enough to know if something has gone bad in a quantitative way. But at least we can tell that the suspension wire didn't break.
It was only a mediocre locking night. I was foiled for a long time by 2 things, both of which are now taken care of in the scripts, so I don't waste so much time again.
Scripts are checked into the svn.
I used Q's handy-dandy 2D histogram plotter (..../scripts/general/dataHist, which I have taken the liberty of adding to the svn) to set the PRCL offset when I was locked on REFL165. Here is a version of the plot, when I had an offset of +10 in the PRCL filter bank. There was so much noise on the PRCL input that I quit bothering to try and put in an excitation or ramp the offset value. Note that I have since moved this offset to PRCL_A's offset instead, so taking this plot again should have PRCL_IN1 centered around zero.
I had trouble doing something similar for PRCL when I was locked on REFL55. At first, the offset was so poor that POP110 was only about half the value it was when locked on REFL165, and it had a huge amount of RIN. I tried just doing a z avg of the PRCL_B_IN1 (REFL55I) while locked on REFL165, and that said that REFL55I had an offset of +33.8 counts, so I tried an offset of -33.8 counts to get to zero. But, that was still terrible for POP110 power. As I increased the offset, eventually up to +30 counts, POP110 kept getting better and better. I lost lock at that point (while trying to get 10 sec of histogram data), so I'm not sure that +30 is the final value. I want to also get equivalent histograms with POP22 and POPDC (and maybe arm transmissions?) as the X-axis on these plots. There's no excitation, so all of these can be collected at once.
By babysitting the ITM alignment (looking at the rough DC values of the optical lever error siganls), and doing a little adjustment of the ASC differential offset, I was able to keep lock a few times for more than 2 or 3 minutes while all 1f. Not a whole lot longer than that though, even if I wasn't "poking" the interferometer other than maintaining alignment.
Small steps tonight, but all in the forward direction.
On one of my better locks, I saw a kind of weird phenomenon with the PRMI sideband powers versus the carrier powers:
For the last 100 seconds of this plot, I'm all 1f. Alignment is being handled mostly by Q's DC coupled ITM oplevs, and the transmission QPD ASC loops, although I was trying to adjust the offsets in the ASC loops to improve transmission for a bit.
At the very end, the last 10 seconds or so, the POP110 power goes down, and sits at about half it's maximum value. POP22 isn't quite as bad, in that it still touches the max, but the RIN is about 50%. The carrier DC signals (TRX, TRY, POPDC) don't see this huge jump. I don't think I was touching anything the last few tens of seconds. I'm not sure yet how I can so significantly lose sideband power, without losing a similar amount of carrier power.
The ring-ups at about -70sec in the CARM and DARM outs are the bounce mode.
I tried looking at 2D histograms of different combinations of channels, for the time around -30 seconds where things looked pretty clean. It looks like the offsets that Q put in last night (+1 for MICH_B and -3 for PRCL_B) are still about right. The PRCL_IN1 and MICH_IN1 were centered around zero at the maximum power points. CARM and DARM had small offsets, which I put into the DARM_B and CARM_B filter banks (0.0066 for DARM_B, and 0.027 for CARM_B), although these are small enough that I don't know that they really do anything.
As a break from locking for a little while, I tried to see if I could get the TT3 and TT4 DAC channels to work for me. I had hoped it would be a quick and easy task, but I'm not seeing signal out. Since it wasn't working, I decided to go back to locking for the night, and look into the DAC in the daytime. I want to use one channel as the IN2 input of the CM board, and another as the external modulation input to the Marconi for transfer functions, so I need them to work.
As a side note on the input to the Marconi situation, it occurred to me that instead of laying a new cable, I can borrow the POP55 heliax. We don't have a POP55 diode right now, and the other end comes out across the hall from the Marconi, so it would be pretty easy to have a medium-length cable go from ITMX table to the Marconi. Objections to this?
The SUS align/misalign scripts don't work after the new CDS utils upgrade.
I don't know if it's looking for the _SWSTAT channel to confirm that the offset has been turned on/off, or if it is trying to set that channel, to do the switching, but either way, the script is failing. Recall that our version of the RCG still has _SW1R and _SW2R, rather than the newer _SWSTAT for the filter banks.
ezca.ezca.EzcaConnectError: Could not connect to channel (timeout=2s): C1:SUS-PRM_OL_PIT_SWSTAT
Q, can you please (please, please, pretty please) undo this upgrade, and then hold off on any further changes to the system for a few weeks?
The DAC was fine. I realized tonight that the digital filter bank outputs were off, so I wasn't actually sending signals out. Oooops.
Q remotely reverted this change. Scripts seem to work again.
Does anyone know where the Busby or Rai low noise pre-amp boxes are?
I think I need one in order to measure the noise of the Marconi. Right now, I am trying to measure the amplitude noise, but I'm not seeing anything on the SR785 above the analyzer's noise level.
The Rai box was in the Cryo lab, and the Busby box was in the TCS lab. Neither had been signed out. Lame. Anyhow, thanks to Evan and Zach's memories of having seen them recently, they have been returned to the 40m where they belong. (Also, I grabbed a spare Marconi while I was over there, for the phase noise measurement).
Going back to Wiener filtering for a moment, I took a look at what the T-240 noise level looks like in terms of pitch motion on one of our SOS optics (eg. PRM).
The self-noise of the T-240 (PSD, in dB referenced to 1m^2/s^4/Hz) was taken by pulling numbers from the Users Guide. This is the ideal noise floor, if our installation was perfect. I'm not sure where Kissel got the numbers from, but on page 13 of G1200556 he shows higher "measured" noise values for a T-240, although his numbers are already transformed to m/rtHz.
To get the noise numbers to meters, I use: . The top of that fraction is (a) getting to magnitude from power-dB and (b) getting to asd units from psd units. The bottom of the fraction is getting rid of the extra 1/s^2.
Next I propagate this seismometer noise (in units of m/rtHz) to effective pendulum pitch motion, by propagating through the stacks and the transfer function for pos motion at the anchor point of the pendulum to pitch motion of the mirror (see eq 63 of T000134 for the calculation of this TF). This gives me radians/rtHz of mirror motion, caused by the ground motion:
I have not actually calibrated the POP QPD, so I will need to do that in order to compare this seismometer noise to my Wiener filter results.