As EricQ mentioned in last night's elog, the modifications were made to the Yend (SN 17) uPDH board.
R31 became 49.9 Ohms, R30 became 45.3kOhm, R24 became 1.02k, R16 became 1k, a new flying resistor is tombstoned up against R24 and connected by purple wire to C6 and it is 20k. C28 is 183nF and C6 is 100nF. These numbers were used in Q's simulation last night.
[Rana, Jenne, EricQ]
* Too much gain overall on Yend box, needed attenuator on output to get lock. Rethought gain allocation. Resoldered board, installed, Ygreen locks nicely. Error point and control point spectra, box TF and open loop TF data collected, to be plotted.
* Q replaced the Xend box, with a matching TF.
* Locked both arms individually, Yend has lots of low freq fluctuation, Xend has some. Can't do out of loop measurement since we're going well beyond the range of the PDH signals (Yarm RIN is between 1/2 and 1.) Plot TRX and TRY spectra with ALS lock vs. IR lock to get an idea of what frequencies we have a problem with.
* Tried comm/diff locking anyway. Works. Used cm_up script to get CARM to sqrtInvTrans. Went to powers of about 0.5 (hard to say really, because of fluctuations), put sine at 611.1 Hz, 200 cts onto ETMs (-1*x, +1*y), looked at TF between ALS diff and AS55Q. Put that amount into the static power normalization spot for AS55. In steps of 0.1, reduced ALSdiff input matrix elements and increased AS55->DARM element. 2 (3?) times was able to get to AS55Q for DARM. Lost lock once unknown reason, while reducing CARM offset. Lost lock once trying to turn on FM4 LSC boost for DARM.
I locked the arms with IR, and measured the beatnote spectra to get the out of loop noise for the PDH boxes.
Unfortunately, we don't have a reference saved (that I can find), so we're going to have to compare to an elog of Koji's from a month ago. I have created an out of loop ALS reference .xml file in the Templates/ALS folder.
As we can see from Koji's elog 10302, the Xarm seems to have stayed the same, but the Yarm seems to have increased by about an order of magnitude below 100 Hz. :(
These are plots and notes from last week's PDH adventures.
For the PDH servo box re-design, we wanted to think a little bit about what we actually wanted out of the box.
* We want the zero of the main transfer function to be at the same frequency as the cavity pole for green, which is about 18kHz.
* We want the boost to suppress noise at a few hundred Hz. We don't need super-duper low-frequency boost, nor do we want it. We'd like to leave the boost on all the time.
* Wanted to get rid of 10dB attenuator on PD input, so needed to lower the overall gain.
* We acknowledge that the gain of the raw error signal times the PZT response is very high, so no matter what, we will have to have a low-gain servo, even perhaps have the servo shape be less than unity gain.
---> We reduced the gain of the first amplification stage from a gain of 20 to a gain of 3.
---> Made the boost stage have a DC gain of 1. Pole at 75 Hz and Zero at 1.6kHz to give suppression at a few hundred Hz. Boost is *not* a pure integrator, so that we can leave it on. (If we required triggering anyway, we would have made it a pure integrator).
---> In transfer function stage, put zero at 17.7kHz to match cavity pole. Pole of servo was going to be at 20 Hz, but we wanted a little more gain, so we lowered it to 2 Hz.
Here is the final measured servo box transfer function for the Yend box (with an arbitrary gain knob setting):
Once installed, I set the gain knob for the Yend at 4.0, which gave an overall UGF of about 10kHz. Then I measured the loop:
I also measured the error point and the control point, and compared them to Q's measurements in elog 10430.
In order to see what we might expect for a contribution to ALS noise, I looked at the error point spectra and lowpassed it with a pole at 200Hz. I do this because the PDH error is like sensor noise for the ALS, but the ALS UGF is around 200 Hz, so noise at frequencies higher than that will be suppressed like 1/f. So, I lowpass the error signal, then look at the RMS, and see that we should be pretty happy with our result. I include also the Xend error spectrum, as measured and reported by Q in elog 10460.
This afternoon, after Q and Manasa finished recovering from the activities of the morning, I aligned the IFO, and went to the Yend to touch up the alignment of the green to the arm. I don't know if it was the alignment (I didn't do the PSL table), or I happened to have a good combination of laser temperatures, or what, but the Yend ALS noise was super good. After that, the low frequency noise contribution is different lock-to-lock, and I haven't discerned a pattern yet.
One thing that we want to try is to get DARM to AS55 so that we're entirely off of ALS (assuming we've already gotten CARM to sqrtInvTrans). However, according to Q's simulations, we have to get past arm power of a few before we are within the AS55 linewidth. I have a DTT running showing me the phase between AS55 and ALSdiff as I reduce the CARM offset, but I haven't been able to get close enough to see the sign flip when CARM is on sqrtInvTrans. If I just sweep through with both CARM and DARM on ALS, I see the sign flip. I've tried a few different things, but I have not successfully gotten a transition to AS55 while the arm powers were above 1. Empirically, I think I want them at at least 3 or 4.
Koji suggested locking the DRMI rather than PRMI, to widen the AS55 linewidth, but I haven't tried that tonight. Maybe tomorrow night.
I have made a ruidimentary lockloss plotting script, that I have put in ..../scripts/LSC/LockLossData, but I'm not satisfied with it yet. Somehow it's not catching the lockloss, even though it's supposed to run when the ALS watch/down scripts run. I'll need to look into this when I'm not so sleepy.
Q, can you please work on figuring out the phase tracker gain tracker? It will be nice to have that functional so we don't have to fret about the phase tracker gains.
Manasa, can you please estimate what kind of mode matching we have on the PSL table between the arm greens and the PSL green? We *do not* want to touch any optics at this point. Just stick in a power meter to see how much power we're getting from each beam, and then think about the peak height we see, and what that might tell us about our mode overlap. If we determine it is total crap, we can think about measuring the beams that go either toward the camera, or the DC PDs, since neither of those paths require careful alignment, and they are already picked off from the main beatnote path. But first, what is our current efficiency? Yarm is first, then Xarm, since Yarm seems worse (peak height is larger for non-00 modes!)
Q has pointed out that we expect a sign flip in the AS55 signal for DARM as we reduce the CARM offset in the PRFPMI case. Koji also mentioned that the SRC will help broaden the DARM linewidth. I wanted to check and think about these things with my Optickle simulation. Q is working on confirming my results with Mist.
The simulation situation:
* The demod phase for AS55 is set in the MICH-only case so that the MICH signal is maximized in the Q-phase. I do not change the demod phase at all in these simulations.
* Cavity lengths (arms, recycling cavities) are the measured lengths.
* I look at AS55 I and Q as DARM sensors (i.e. I'm doing DARM sweeps) as a function of CARM offset, for both PRFPMI and DRFPMI cases.
Spoiler alert! Conclusions:
* In the PRFPMI case, the DARM signal shows up with approximately equal strength in the I and Q phases, so we suffer only about a factor of 2 if we do not re-optimize the demod angle for AS55.
* In the DRFPMI case, the DARM signal is a factor of 1,000 smaller in the Q-phase than the I-phase, which means that the ideal demod phase angle has moved by about 90 degrees from the MICH-only case. We must either use the I-phase signal or change the demod phase by 90 degrees in order to acquire lock.
* In the PRFPMI case, there is a sign flip for DARM on the AS55 PD around 100pm, so we don't want to use AS55 for DARM until we are well inside 50pm, and aren't going to fluctuate out of that range.
* In the DRFPMI case, there is no such sign flip, at least out to 1nm, so we can use AS55 for DARM as soon as we see a viable signal. This is super awesome. The caveat is that the gain changes significantly as we reduce the CARM offset, so we either need a UGF servo (eventually) or careful watching (for now).
* The AS55 linear(-ish) range is much broader in the dual recycled case, which is yet another reason why getting DARM on AS55 will be easier for DRFPMI.
Why didn't we do it already?
* To put the SRM QPD back, we'd also have to move Steve/EricG's laser. Since I had other things to do, I left the setup for tonight, but I think I will want it for tomorrow night.
* Monday night (and tonight) we can pretty reliably get DARM onto AS55Q for the PRFPMI case, and I don't know what the cause has been for my locklosses, so I thought I'd try to figure that out first.
First up, the current transition we've been trying to handle, PRFPMI DARM to AS55Q. I also plot AS55I, and we see that the signals are roughly the same magnitude (the x axis isn't the same between these plots! sorry), so we aren't screwed if we don't change the demod phase angle. We'll be better off once we can do a re-optimization, but this is assuming we are stuck (at first) with our MICH-only demod phase angle.
Next up, the same plots, but for the DRFPMI case. Note here that there is a factor of about 1000 in the y-axis scales, and also that there is no switch in the sign of the zero-crossing slope for the I-phase.
And here is the same data (DRFPMI case), but zoomed out for the Q-phase, so you can see the craziness of this phase. Again, this is much smaller than the signals in the I-phase, so I'm not too worried.
* Steve leaves the SRM oplev back in its nominal location (we can worry about aligning the mirror, and aligning the beam on the PD, but please put it back approximately where it came from).
* Try DRMI + 2 arm locking, which I don't think we have ever actually done before. Hopefully there won't be any tricks, and we can get to an equivalent place and successfully get DARM to AS55.
* .... Keep going?
I hereby confess to having a secret script. But it is secret no longer!
It's a "goLock" script, and it is now in the path from any terminal. It kills any open medm sessions (to clean up desktops), and then opens a palette of screens that I find useful. It also starts up the CARM and DARM ALS watch scripts, and the toggle shutter scripts. It then leaves the terminal in .../scripts/PRFPMI/ , which is where the carm_cm_up.sh script that we've been using lives.
I also made tonight a "goHome" script, but all that one does so far is set the LSC mode to OFF. The other thing that this could / should do is restore all optics so we don't have hysteresis problems.
Also, also, my "new" misalign / restore scripts had a bug, in that they were always switching oplevs for the PRM, no matter what optic was requested. This sometimes caused the PRM oplev to be engaged while the optic was misaligned, so the PRM would get rung up. This has been fixed.
No major progress today.
I fixed a bug in my lockloss script that was asking it to start gathering data just after the lockloss, rather than some seconds beforehand. Ooops. Anyhow, with this handy-dandy plotting, I still don't know why we are losing lock when we have PRMI on REFL33, CARM on sqrtInvTrans, and DARM on AS55. I don't see any oscillations, just the arm power drops off, and a moment later the POP power drops.
For example, here is one of the best states we got to tonight. Data for this is in ..../scripts/LSC/LocklossData/1094369700 . You can re-create the plot by going to ..../scripts/LSC/LocklossData/ and doing ./PlotLockloss.py 1094369700 . We had set the triggers for the trans PD/QPD such that we were using the QPD transmission signals the whole time (above trans of 0.2). We saw that the noise at high frequency during low transmission powers for sqrtInvTrans as an error signal was higher using the QPDs than with the Thorlabs PDs, but that both cases are below the noise for ALS. The arm powers were pretty steady above 3 for the last bit of this lock stretch. I lost lock while trying to transition DARM over to AS55Q. CARM was on sqrtInvTrans(QPDs), PRMI on REFL33 I&Q as usual.
./PlotLockloss.py 1094369700 .
Other things from this evening:
* When I was starting, I saw that when I locked the PRMI, the PRM was oscillating in pitch. Oscillation only happened when PRM pitch oplev was on. I'm not sure what could have changed to make the oplev loop unstable, but the gain was 7.0, and now I have left it at 5.0.
* I recentered the PRM and ITMY oplevs.
* Plugged in the Yend PDH error monitor and pzt output monitors, since I forgot them last week. Hopefully this will allow the Yend SLOW servo to work, and keep us away from the limits of the PZT range.
Steve and EricG are moving their oplev test for aLIGO over to the SP table, so that we can have the SRM optical lever back.
I have pulled out an Ontrak PSM2-10 position sensor and accompanying driver for the sensor. This, like the POP QPD, has BNC outputs that we can take straight to the ADC.
In the c1pem model I have created 3 new filter modules: C1:PEM-OLTEST_X, C1:PEM-OLTEST_Y, and C1:PEM-OLTEST_SUM. I built, installed and restarted the model, and also restarted the daqd process on the frame builder. On the AA breakout board on the 1X7 rack, these correspond to:
BNC # 29 = OLTEST_X
BNC # 30 = OLTEST_Y
BNC # 31 = OLTEST_SUM
By putting 1Vpp, 0.1Hz into each of these channels one at a time, I see on StripTool that they correspond as I expect.
Everything should be plug-and-play at this point, as soon as Steve is ready with the hardware.
Sitting down to work on the IFO, I couldn't lock the Yarm. I looked at the error signal as well as the transmission on Dataviewer, as usual, and saw that the POY error signal was almost non-existant.
Since there was work on the POY table today (Steve removed the oplev test setup, elog 10489 and Q centered the SRM oplev after doing SRMI alignment, no elog yet), I went out to have a look at the table.
There was nothing occluding the POY beam, which I traced back to the edge of the table. The beam looked nice and round, so I decided that wasn't it. I jiggled the PD cables, and lo and behold, the POY RF out cable almost came off in my hand it was so loose. My suspicion is that whomever was the last to put the POY RF out back didn't tighten the cable and then the work today jiggled the cable loose. I tightened the cable, and by the time I was back to the control room the arm was locked and Koji was already running the alignment scripts.
Koji and Manasa did some work on the PSL green situation today (Koji is still writing that log post up), but I just measured the Yarm out of loop sensitivity, and WOAH.
The beat is -11.5dBm at 42.8 MHz. Koji said the sweet spot is around 30 MHz. The out of loop sensitivity is 400 Hz RMS! Something to note is that the Y beatnote still has a 20dB amplifier before going to the beatbox, but the X does not. We had been worried about saturation issues with the X, so we took out the amplifier. However, I might put it back if we win big like this.
Recall from elog 10462 that I had saved a reference of the out of loop noise for both X and Y, but Y was much noisier than X. The references below are from that elog, and the new Y is in dark blue. (Edit, 9:18pm, updated plot measuring down to 0.01Hz. This is the new reference on the ALS_outOfLoop_Ref.xml template).
EDIT: (Don't worry, I'm going to measure X too, but right now the beam overlap on the camera is not good, as if something drifted after Koji and Manasa closed up the PSL table)
Touched up the alignment for X on the PSL table. Current beatnotes are: [Y, -13.5 dBm, 74.1 MHz], [X, -22 dBm, 13.9 MHz]. Red is the current X out of loop, and I've saved it as the new X reference on the template.
The sum vs. pitch and yaw signals for the SRM QPD weren't making sense to me - centering on the PD lowered the sum, etc. So, I had a look at the SRM oplev setup.
The beam going in to the chamber looked fine, but the beam coming out was weird, like it was being clipped, or diffracted off of a sharp edge. The beam was spread out in yaw over almost 1cm as seen by eye. I looked into the vacuum window, and the beam was sitting on the edge of one of the in-vac steering optics. So, I adjusted the yaw of the beam-launching optic on the out of vac table so that I was roughly centered on both of the in-vac SRM steering mirrors. This required moving the first out of vac mirror for the SRM oplev path on the way to the QPD to move a small amount to one side, since the beam was near-ish the edge of the optic. I then centered the beam on the oplev (I had the SRM roughly aligned already).
Now the SRM oplev makes more sense to me. I have turned on FMs 1, 2, 5, 9 to match ITMY's loop shape. I have set the gains to -10 for pitch and +10 for yaw, to make the upper UGF about 6 Hz.
No breakthroughs tonight.
DRMI didn't want to lock with either the recipe that we used a year ago (elog 9116) or that was used in May (elog 9968). Being lazy and sleepy, I chickened out and went back to PRFPMI locking.
Many attempts, I'll highlight 2 here.
(1) I had done the CARM -> sqrtInvTrans transition, and reduced the CARM offset to arm powers of about 7, and lost lock. I don't remember now if I was trying to transition DARM to AS55, or if I was just prepping (measuring error signal ratio and relative sign).
(2) I stopped the carm_cm_up script just before it wanted to do the CARM -> sqrtInvTrans transition, and stayed with CARM and DARM both on ALS. I got to reasonably high powers, and was measuring the error signal ratios I needed for CARM -> REFL DC and DARM -> AS55. Things were too noisy to get good coherence for the DARM coefficient, but I thought I was in good shape to transition CARM to REFL DC (which looks like REFL11I, since REFLDC goes to the CM board, and the OUT2 of that board is used to monitor the input to the board. ) Anyhow, I set the offset such that it matched my current CARM offset value, and started the transition, but lost lock about halfway through. CARM started ringing up here, and I think that's what caused this lockloss. Could have been the CARM peak, which I wasn't considering / remembering at the time.
Daytime activity for Thurs: Lock DRMI, maybe first on 1f signals, but then also on 3f signals.
Tonight I worked on DRMI locking.
I think the reason the May2014 DRMI recipe wasn't working for me is because I wasn't including the REFL11 -> SRCL element. I had left it out because (a) I didn't think we should need it and (b) REFL11 is going through the CM board.
Tonight, I flipped the switch on the CM screen so that OUT2 was seeing REFL11I, not REFLDC, so I had REFL11 in the usual place. I reset the demod phase, since we had left it at zero for CM stuff.
Setting demod phases for PRMI:
I locked PRMI on sideband, REFL 33 I&Q and drove PRM. REFL55 was at 55deg, and I changed it to 33deg to minimize the peak in the Q-phase. REFL11 was a 0deg, and I set it to 17deg. I also checked the AS55 phase in the MICH-only case, and changed it from 14.75deg to 24.75 deg.
The May 2014 recipe (elog 9968) calls for adding 25 degrees to the REFL55 phase, so I put REFL55 at 58deg for DRMI locking.
After that, using the parameters in the May2014 recipe, the DRMI just locked. Awesome!
I checked the demod phases with DRMI lock. REFL11 stays at 17 degrees. If I actuate the SRM, I get the largest peak in the I-phase of REFL55 with a phase of -143deg, but the acquisition is best with phase around 55deg. [Note, as Q points out, I wonder if SRCL is mostly locked with REFL11I for some magical reason, which is why it didn't matter so much that I put a sign flip into REFL55...I wonder if fixing our macroscopic length offset in SRCL will fix this]. I also changed the REFL165 phase from -155.5deg to +145deg.
By looking at transfer functions at an excitation frequency, I expected that I should be able to hold SRCL and MICH on REFL165, with matrix elements -0.085 for REFL165I->SRCL and -0.23 for REFL165Q->MICH. I was not able to acquire with these values, nor was I able to ramp the matrix elements while keeping lock.
So, I tried moving PRCL to REFL33I, which did work. I used 1.245*REFL33I->PRCL, but left SRCL and MICH on REFL55 I&Q, with the REFL11I->SRCL element also there. This is where I started trying to get rid of the REFL11I element, but couldn't maintain lock most times, and could never acquire lock without it.
Next up, checking the MICH->SRCL coupling due to the output matrix. I did as Koji did in elog 8816 , but first I copied the notches in FM10 of MICH over to PRCL and SRCL (old notch freqs were SRCL=566.1Hz, PRCL=675.1Hz, now they're all 475.1Hz). I drove BS, and checked that the PRM element minimized the peak in REFL33I, the PRCL error signal. I also added an SRM element to reduce the peak in REFL55I, the SRCL error signal. I ended up with 0.5*BS, -0.284*PRM, -1.5*SRM for MICH drive, and unity in the PRM and SRM elements for PRCL and SRCL, respectively.
I measured the SRCL open loop gain, and the UGF was pretty low, so I increased the SRCL gain from 0.2 to 0.5 to make the UGF be around 70Hz. I measured PRCL and MICH also, and they matched their references.
I worked a little bit on trying to remove REFL11 from the SRCL error signal, but didn't get anywhere. I'm leaving the IFO to Q for the rest of the night.
To sum up, here is the set of parameters that worked for DRMI locking. (These are saved as the template on the IFO Config screen.):
REFL11: 17 deg
REFL33: 140.5 deg (not changed tonight)
REFL55: 58 deg (58deg for DRMI, 33deg for PRMI)
REFL165: 145 deg
AS55: 24.75 deg
MICH = 0.15 * REFL55Q
PRCL = 1.245 * REFL33I
SRCL = -0.09 * REFL11I + 1.0 * REFL55I
MICH, PRCL, SRCL all on POP22I, 50:10
MICH = 1.0
PRCL = -0.02
SRCL = 0.5
MICH: 35:2, 2 sec delay, FM 2, 3, 6, 9
PRCL: 35:2, 0.5 sec delay, FM 2, 3, 6, 9
SRCL: 35:2, 5 sec delay, FM 3, 6, 9 (always lose lock trying to engage FM2).
MICH = 0.5 * BS + (-0.284)*PRM + (-1.5)*SRM
PRCL = 1*PRM
SRCL = 1*SRM
During the Sim meeting today, I added parts to the ASS model so that we can also dither the BS and minimize the power at AS.
ASS screen has been updated.
Model changes required a new sender from LSC for ASDC, so both LSC and ASS were compiled, installed and restarted. Also on LSC, I added AS110 I&Q to DQ channels, since we haven't been recording them in the past.
I have done a quick trial in MICH-only lock, and it seems to work. Gain of 10 for both Pit and Yaw servos.
I tried a bunch of times to reduce my CARM offset so I could jump to REFLDC digitally, but I think I'm maybe being a little ambitious with the arm power I'm trying to get to.
I have modified the carm_cm_up script so that it does my new procedure. Everything is the same through locking the PRCL and MICH on 3f. Then it reduces the CARM offset to 1.5 nm. This is where we *used* to transition to sqrtInvTrans. Now I have it going a bit farther to 0.5 nm, and arm powers of about 1 before doing that transition. Also, before it transitions it lowers the CARM gain and engages the 1kHz lowpass in FM9. A gain of about 4 is fine to keep the gain peaking in the CARM loop to only about 10dB, and sets a UGF of 100Hz which is the peak of the phase bubble with the lowpass engaged.
Once I got to this point (several times tonight), I turned on CARM and DARM oscillations and looked at the transfer functions between (CARM and REFLDC) and (DARM and AS55Q). I have 2 DTT templates setup for this, in /users/Templates/PRFPMI. These templates assume that you have your new DARM signal (AS55) going to SRCL_IN1 and your new CARM signal (REFLDC, which is actually REFL11I coming through the CM board) going to MC_IN1.
I'm not sure why I'm losing lock. I don't see anything terribly telling on the time series plots, in particular none of the loops look like they are oscillating. Here is one of the better examples from this evening:
* I realigned the Xgreen on the PSL table (again) to maximize the beatnote amplitude. Y was fine, but X was very poorly overlapped on the camera.
* I put the SR785 back by the LSC rack and plugged it into the CM board for transfer functions. Didn't take any tonight.
* We have a small wishlist for scripting things: (1) DRMI restore script should reset REFL11 to "normal" REFL11. (2) CARM/DARM acquisition restore script should reset REFL11 to REFLDC. (3) CARM/DARM acquisition restore should also set PRMI parameters (as Q noted last week).
Steve asked about calibrating the QPD, so I set up some new epics records so that we can have calibrated versions of the QPD output.
The new channels are called C1:ASC-TESTQPD_Y_Calc and C1:ASC-TESTQPD_X_Calc for pitch and yaw, respectively.
* I modified /cvs/cds/caltech/target/c1iscaux/QPD.db to add 2 new channels. Since we are currently plugged into the IPPOS channels, I didn't want to modify the units of IPPOS, which is why I created new channels. The new channels are just the IPPOS normalized X and Y channels, multiplied by a calibration factor. Steve has already done a rough calibration for his setup, so I used those numbers (0.15 urad/ct for pitch and 0.25 urad/ct for yaw).
* Rebooted c1iscaux. This required adding it to chiara's /etc/hosts file.
* Added the channels to the /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini file so that the channels would appear in dataviewer.
* Restarted the framebuilder daqd process.
How to modify the calibration:
1) On a control room workstation, cd /cvs/cds/caltech/target/c1iscaux to get to the right folder. (Note that this is still in the old cvs/cds place, *not* the new opt/rtcds place)
2) open the epics database file by typing sudo emacs QPD.db. Since this is a protected file, you need to use the "sudo" command, and will have to type in the usual controls password.
sudo emacs QPD.db
3) Find the "records" that have the channel names C1:ASC-TESTQPD_Y_Calc and C1:ASC-TESTQPD_X_Calc by scrolling down. (Right now they are on lines #550 and #561 of the text file).
4) For each of these 2 records, modify the calibration in the line that says something like field(CALC,"(A*0.25)"). In this example, the current calibration is 0.25 urad/oldCount. Change the number to the new value.
5) Save the file. If you followed the procedure in step2 and used the emacs program and you can't use the mouse, do the following: Hold down the "ctrl" key. Keeping ctrl pushed down, push the "x" key. Still keeping ctrl pushed down, push the "s" key.
6) Close the file. If you followed the procedure in step2 and used the emacs program and you can't use the mouse, do the following: Hold down the "ctrl" key. Keeping ctrl pushed down, push the "x" key. Still keeping ctrl pushed down, push the "c" key.
7) Reboot the slow computer called c1iscaux. You should be able to do this remotely by typing telnet c1iscaux, and then typing reboot. If that doesn't work, you may have to go into the IFO room and power cycle the crate by turning the key. This computer is in 1Y3, near the bottom.
8) Check that you can see your channels - you should be finished now!
For steps 3 and 4, here is a screenshot of the lines in the text file:
Tonight was a night of trying to engage the AO path. The idea was to sit at arm powers of a few on sqrtInvTrans for CARM and ALS for DARM, and try to increase the gain for REFLDC->AO path.
No exciting nit-picky details in locking procedure. Mostly it was just a night of trying many times.
The biggest thing that Q and I found tonight was that the 2-pin lemo cable connecting the CM board's SERVO OUT to the MC board's IN2 is shitty. The symptom that led to this investigation was that I could increase the AO path gain arbitrarily, and have no change in the measured analog CM loop transfer function. We checked that the CM board servo out spit out signals that were roughly what we expected based on our ~2kHz excitation. However, if we look at digitized signals from the MC board, the noise level was very high, with loads of 60Hz lines, and a teensy-tiny signal peak. We put a small drive directly into the MC board and could see that, so we determined that the cable is bad. We have unplugged the white 2-pin lemo, and ran a long BNC cable between the 2 boards. Tomorrow we need to make a new 2-pin lemo cable so that we can have the lower noise differential drive signal.
After putting in the temporary cable, we do see an excitation sent to the CM board showing up after the MC board. For this monitoring, the MC_L cable to the ADC has been borrowed, so instead of being the OUT1, the regular length signal, MC_L is currently the OUT2 monitor right after the board inputs.
At some point in the evening, around 1:15am, ETMX started exhibiting the annoying behavior of wandering off sometimes. I went in and pushed on the SUS cables to the satellite box, and I think it has helped, although I still saw the drift at least once after the cable-squishing.
Other than that, it has just been many trials.
The best was one where I was holding the arm powers around 4, and got the CM board's AO gain to -8 dB and the MC board's IN2 AO gain to -4 dB. I lost lock trying to increase the CM board gain to -7 dB.
I took several transfer functions, and used Q's nifty "SRmeasure" script to gather data, and Q made a plot to see the progress.
TF progress plots:
Time series of that lockloss:
I don't know yet if the polarity of the CM board should be plus or minus. This series was taken with "minus". But, since the phase looked opposite of Q's single arm CM board checkout from several months ago, we did a few trials with the polarity switched to "plus". I thought we weren't getting as high of AO path gains, so I switched back to "minus", but the last few trials didn't get even as far as the plus trials did. So, I still don't know which sign we want.
We pulled the old 2-pin lemo cable after I had a look at the connectors. When I unscrewed the connector on the MC side, one of the wires came off. I suspect that it was still hanging on a bit, but my torquing it finally killed it.
We pulled the cable with the idea of resoldering the connectors, but there are at least 2 places where the cable has been squished enough that the shielding or the inner wires are exposed. These places aren't near enough the ends to just cut the cable short.
Downs doesn't have a spool of shielded twisted single-pair cable, so Todd is going to get me the part number for the cable they use, and I've asked Steve to order it tomorrow.
For now, we will continue using the BNC cable that we installed last night - I don't think it's worth resoldering and putting in a crappy 2-pin lemo cable that we'll just throw out in a week.
Discontinuities / glitches could be seen in the CM board fast output when MC board gains were changed, which isn't so nice. Incidentally, I notice now that each lock loss corresponded to a step of AO gain on the CM board.
Back in May I looked at all the glitches that happen when we change the AO gain slider on the CM board - see elog 9938. I wonder if the MC IN2 gain slider has the same issues. I think I'll look at this this afternoon. Maybe we can set the CM board gain someplace, and just use the MC IN2 slider (if it's not as glitchy) for the delicate part where we're just about to cross unity, and then later we can again use the CM board's AO gain.
EDIT: Yes, the glitches on the CM board AO path are *much* bigger, and more frequent. Interestingly, the biggest glitches were every 4 dB. When I went from -29 to -28, again from -25 to -24, -21 to -20, etc. I saw the largest glitches on the MC IN2 slider going -29 to -28 and -17 to -16, but if there were small glitches at other transitions, they didn't hit my trigger levels. I think next time I try engaging the AO path I'll try to do the delicate stuff by upping the MC IN2 gain rather than the CM board AO gain.
[Steve, EricQ, Jenne]
ITMY and BS heavy doors are off, light doors are on. Q is aligning the IFO.
I looked at the CAD layout and it seems like we will clearly be clipping POY if we move SRM by 7.5cm. Since POY is not visible at low power, we cannot be sure about the clipping.
I was bad and forgot to elog this yesterday (bad grad student!), but I setup a laser pointer to show us where the POY beam is.
To do this, I removed the tiny mirror that sends the beam to the POY RF PD (so we do not have POY to lock the Yarm right now. I think Q has successfully been using AS). The laser pointer goes through 2 temporary steering mirrors, then passes through the place that the tiny mirror usually sits, and then travels along the POY path into the vacuum system. The idea here is that we should be able to adjust the laser pointer and the temp steering mirrors, and not touch any of the actual POY mirrors, but still get the green beam to go all the way to ITMY. Yesterday I confirmed that the laser pointer was hitting the in-vac POY pickoff mirror, and today Q and Manasa are doing final adjustment to get the beam all the way to the ITM.
[Zach, Jenne, Steve]
This work happened on Tuesday. Bad Jenne for forgetting to elog it!
Zach brought the 40m's seismometers back (one Guralp and one T-240). We have set the seismometers on their slabs. Also, we ran the T240 cable from 1X5 over to the vertex slab. Also, also, Zach and Steve mounted the T-240 readout box in the 1X5 rack. We have not yet hooked it up to power, although there are fused power blocks available on that rack.
So, the T-240 box needs power, and then we need to connect the seismometers to their respective boxes. Also, we need to run medium-short BNC cables from the T-240 readout box to the PEM AA board over in 1X7.
As per other slow computers, which Chris figured out in elog 10189, I added all the rest of the slow computers to Chiara's /etc/hosts file, so that they would come up when Manasa went and keyed the crates.
Computers that were already there:
Computers that I added today:
Manasa keyed all of these crates *except* for the vac computer, since Steve said that the vacuum system is up and running fine.
No exciting progress today. I did PSL green alignment for the Yarm, although I now think that the Xarm green needs realigning too.
Also, I was foiled for a while by ETMX jumping around. I think it's because the adapter board on the Xend rack didn't have any strain relief. So, I zip tied the heavy cable in a few places so that it's no longer pulling on the connector. Hopefully we won't see ETMX misbehaving as often now, so we won't have to go squish cables as often.
I put a little script into ...../scripts/Admin that will check the fullness of Chiara's disk. We only have the mailx program installed on Nodus, so for now it runs on Nodus and sends and email when the chiara disk that nodus mounts is more than 97% full.
As part of trying to determine whether we require the AO path for lock acquisition, or if we can survive on just digital loops, I looked at the noise suppression that we can get with a digital loop.
I took a spectrum of POX, and calibrated it using a line driving ETMX to match the ALSX_FINE_PHASE_OUT_HZ channel, and then I converted green Hz to meters.
I then undid the LSC loop that was engaged at the time (XARM FMs 1,2,3,4,5,8 and the pendulum plant), to infer the free running arm motion.
I also applied the ALS filters (CARM FMs 1,2,3,5,6) and the pendulum plant to the free running noise to infer what we expect we could do with the current digital CARM filters assuming we were not sensor noise limited.
In the figure, we see that the free running arm displacement is inferred to be about 0.4 micrometers RMS. The in-loop POX signal is 0.4 picometers RMS, which (although it's in-loop, so we're not really that quiet) is already better than 1/10th the coupled cavity linewidth. Also, the CARM filters that we use for the ALS lock, and also the sqrtInvTrans lock are able to get us down to about 1 pm RMS, although that is not including sensor noise issues.
For reference, here are the open loop gains for the LSC filters+pendulum and ALS filters+pendulum that we're currently using. The overall gain of these loops have been set so the UGF is 150Hz.
It seems to me that as long as our sensors are good enough, we should be able to keep the arm motion down to less than 1/10th or 1/20th the coupled cavity linewidth with only the digital system. So, we should think about working on that rather than focusing on engaging the AO path for a while.
Other thoughts from talking with Rana earlier:
Also, Q and I squished on the suspension connectors earlier tonight. MC2 was going wonky, which we feared might be because we were in that area working on Chiara earlier. Then, after squishing the MC connectors, the PRM started misbehaving, so we went and gave all the corner suspension connectors another squish. No suspension glitching problems since then.
After the Great Computer Meltdown of 2014, we forgot about poor c0rga, which is why the RGA hasn't been recording scans for the past several months (as Steve noted in elog 10548).
Q helped me remember how to fix it. We added 3 lines to its /etc/fstab file, so that it knows to mount from Chiara and not Linux1. We changed the resolv.conf file, and Q made some simlinks.
Steve and I ran ..../scripts/RGA/RGAset.py on c0rga to setup the RGA's settings after the power outage, and we're checking to make sure that the RGA will run right now, then we'll set it back to the usual daily 4am run via cron.
EDIT, JCD: Ran ..../scripts/RGA/RGAlogger.py, saw that it works and logs data again. Also, c0rga had a slightly off time, so I ran sudo ntpdate -b -s -u pool.ntp.org, and that fixed it.
sudo ntpdate -b -s -u pool.ntp.org
In all of the fstabs, we're using chiara's IP instead of name, so that if the nameserver part isn't working, we can still get the NFS mounts.
On control room computers, we mount the NFS through /etc/fstab having lines like:
192.168.113.104:/home/cds /cvs/cds nfs rw,bg 0 0
fb:/frames /frames nfs ro,bg 0 0
Then, things like /cvs/cds/foo are locally symlinked to /opt/foo
For the diskless machines, we edited the files in /diskless/root. On FB, /diskless/root/etc/fstab becomes
master:/diskless/root / nfs sync,hard,intr,rw,nolock,rsize=8192,wsize=8192 0 0
master:/usr /usr nfs sync,hard,intr,ro,nolock,rsize=8192,wsize=8192 0 0
master:/home /home nfs sync,hard,intr,rw,nolock,rsize=8192,wsize=8192 0 0
none /proc proc defaults 0 0
none /var/log tmpfs size=100m,rw 0 0
none /var/lib/init.d tmpfs size=100m,rw 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0
none /sys sysfs defaults 0 0
master:/opt /opt nfs async,hard,intr,rw,nolock 0 0
192.168.113.104:/home/cds/rtcds /opt/rtcds nfs nolock 0 0
192.168.113.104:/home/cds/rtapps /opt/rtapps nfs nolock 0 0
("master" is defined in /diskless/root/etc/hosts to be 192.168.113.202, which is fb's IP)
and /diskless/root/etc/resolv.conf becomes:
nameserver 192.168.113.104 #Chiara
IFO vacuum, air condition and PMC HV are still down. PSL out put beam is blocked on the table.
PMC is fine. There are sliders in the Phase Shifter screen (accessible from the PMC screen) that also needed touching.
PSL shutter is still closed until Steve is happy with the vacuum system - I guess we don't want to let high power in, in case we come all the way up to atmosphere and particulates somehow get in and get fried on the mirrors.
Okay, here (finally) is the optickle version.
I have the antispring case, starting at 501pm and going roughly every 10pm down to 1pm. I also have the spring case, starting at -501pm and going down every 10pm to roughly -113pm. Rossa crashed partway through the calculation, which is why it's not all the way.
In the .zip is a .mat file called PDs_vs_CARMoffset_WattsPerNewton.mat, which has (a) a list of the 50 CARM offsets, (b) a frequency vector, and (c) several transfer function arrays. The transfer function arrays are supposed to be intuitively named, eg. REFLDC_antispring.
In the .zip file are also the original .mat files that are a result of the tickle calculations, as well as a .m file for loading them and making the plots, etc. For anyone who is trying to re-create the transfer function variables, I by-hand saved the variable called PD_WperN to the names like REFLDC_antispring. Just kidding. Those original mat files are over 100Mb each, and that's just crazy. Anyhow, I think the .zip has everything needed to use the data from these plots.
Anyhow. Here are plots of what are in the various transfer function arrays:
I have a simulated version of the differences that we expect to see between the 2 different sides of the CARM resonance. The point is that we can try to compare these results with Q's measured results (elog 10594) to see if we know if we are on the spring or antispring side.
I calculated the same transfer functions vs CARM offset again, although tonight I do it in steps of 20pm because I was getting bored of waiting forever. Anyhow, this is important because my previous post (elog 10591) didn't have spring side calculations all the way down to 1pm.
This is similarly true for that elog 10591, but here are some notes on how I am currently getting the W/N units out of Optickle. First of all, I am still using old Optickle1. I don't know if there are significant units ramifications for that, but just in case I'll write it down. Nic tells me that to get [W/N] out of Optickle1, I need to multiply sigAC (units of [W/m]) by my simple pendulum (units of [m/N]). Both of these "meters" in the last sentence are "mevans meters", which are the meters you would get per actuation if radiation pressure didn't exist. So, I guess they're supposed to cancel out? I need to camp out in Nic's office until I figure this out and get it untangled in my head.
Plots of transfer functions for both sides of CARM resonance (same as prev. elog), as well as the ratio between the spring and antispring transfer functions at each CARM offset:
The take-away message from the 3rd column is that other than a sign flip, we don't expect to see very much difference between the 2 sides of the CARM resonance, particularly above a few hundred Hz. (Note that we do not see the sign flip in Q's measurements because he is looking at CARM_IN1, which is after the input matrix, and the input matrix elements have opposite signs between the signs of the CARM offsets. So, the sign flip between spring and antispring around the UGF is implied in the measurements, just not explicit).
Also, something that Rana pointed out to me, and I still don't know why it's true: The antispring transfer functions (at least for the transmission) don't have all the phase features that we expect to see based on their magnitudes. If you look at the TRX antispring plot, blue trace (which is about 500pm from resonance), you'll see that the magnitude starts flat at DC, has some slope in an intermediate region, and then at high frequencies has 1/f^2. However, the phase seems to not know about this intermediate region, and magically waits until the 1kHz resonance to flip the full 180 degrees.
I think the daqd process isn't running on the frame builder.
I tried telnetting' to fb's port 8087 (telnet fb 8087) and typing "shutdown", but so far that is hanging and hasn't returned a prompt to me in the last few minutes. Also, if I do a "ps -ef | grep daqd" in another terminal, it hangs.
I wasn't sure if this was an ntp problem (although that has been indicated in the past by 1 red block, not 2 red blocks and a white one), so I did "sudo /etc/init.d/ntp-client restart", but that didn't make any change. I also did an mxstream restart just in case, but that didn't help either.
I can ssh to the frame builder, but I can't do another telnet (the first one is still hung). I get an error "telnet: Unable to connect to remote host: Invalid argument"
Thoughts and suggestions are welcome!
In order to distinguish between the spring and antispring sides of the CARM resonance, we need to have transfer function measurements down to at least 100 Hz (although lower is better).
We tried to get some transfer functions the same way Q did, but noticed that (a) we couldn't get any low frequency coherence, and (b) that when we increased the amplitude of the white (well, lowpass at 5kHz) noise, the coherence between the AO injection and REFL DC went down. Not clear why this is.
Anyhow, we tried taking good ol' fashioned swept sine transfer functions, although eventually the lightbulb came on that the AO path has a highpass in it. Duh, Jenne. So, we started trying to actuate on MC2 position rather than the AO path laser frequency. We didn't get too far though before El Salvadore decided to have a few 7.4 earthquakes. We're bored of aftershocks knocking us out of lock, so we're going to come back to this tomorrow.
Some measurements. Unclear meaning.
We tried both positive and negative numbers in the CARM offset, and then looked at transfer functions at various arm powers. The hope is to be able to compare these with some simulation to figure out which side of the CARM resonance we are on.
The biggest empirical take-away is that we repeatedly (3 times in a row) lost lock when holding at arm powers of about 5 with negative CARM offsets. However, we were repeatedly (2+ times tonight) able to sit and hold at arm powers of 10+ with positive CARM offsets.
I am not sure that we get enough information out of these plots to tell us which side of the CARM resonance we are really on. Q is working on taking some open loop CARM measurements (actuating and measuring at SUS-MC2_LSC) to see if we can compare those more directly to Rana's plots.
Positive number in the digital CARM offset:
Negative numbers in digital CARM offset:
Here are the same plots, but the legend also includes the arm power that we expect at that CARM offset.
Here is what the arm powers look like as a function of CARM offset according to Optickle. Note that the cyan trace's maximum matches what Q has simulated in Mist with the same high losses. For illustration I've plotted the single arm power, so that you can see it's normalized to 1. Then, the other traces are the full PRFPMI buildup, with various amounts of arm loss. The "no loss" case is with 0ppm loss per ETM. The "150 ppm loss" case is with 150 ppm of loss per ETM. The "high loss" case is representative of what Q has measured, so I have put 500 ppm loss for ETMX and 150 ppm loss for ETMY.
And, the transfer functions (all these, as with all TFs in the last week, use the "high loss" situation with 500ppm for ETMX and 150ppm for ETMY).
I have modified the Dataviewer launcher (which runs when you either click the icon or type "dataviewer" in the terminal).
A semi-old problem was that it would open in the file /users/Templates, but our dataviewer templates start in /users/Templates/Dataviewer_Templates. Now this is the folder that dataviewer opens into. This was not related to the upgrade to Ubuntu 12, but will be overwritten any time someone does a checkout of the /ligo/apps/launchers folder.
A problem that is related to the Ubuntu 12 situation, which we had been seeing on Ottavia and Pianosa for a few weeks, was that the variable NDSSERVER was set to fb:8088, which is required for cdsutils to work. However, dataviewer wants this variable to be set to just fb. So, locally in the dataviewer launcher script, I set NDSSERVER=fb. NB: I do not export this variable, because I don't want to screw up the cdsutils. This may need to be undone if we ever upgrade our Dataviewer.
I have plotted measured data from last night (elog 10607) with a version of the result from Rana's simulink CARM loop model (elog 10593).
The measured data that was taken last night (open circles in plots) is with an injection into MC2 position, and I'm reading out TRX. This is for the negative side of the digital CARM offset, which is the one that we can only get to arm powers of 5ish.
The modeled data (solid lines in plots) is derived from what Rana has been plotting the last few days, but it's not quite identical. I added another excitation point to the simulink model at the same place as the "CARM OUT" measurement point. This is to match the fact that the measured transfer functions were taken by driving MC2. I then asked matlab to give me the transfer function between this new excitation point (CARM CTRL point) and the IN1 point of the loop, which should be equivalent to our TRX_OUT. So, I believe that what I'm plotting is equivalent to TRX/MC2. The difference between the 2 plots is just that one uses the modeled spring-side optical response, and the other uses the modeled antispring-side response.
I have zoomed the X-axis of these plots to be between 30 Hz - 3 kHz, which is the range that we had coherence of better than 0.8ish last night in the measurements. The modeled data is all given the same scale factor (even between plots), and is set so that the lowest arm power traces (pink) line up around 150 Hz.
I conclude from these plots that we still don't know what side of the CARM resonance we are on.
I have not plotted the measurements from the positive side of the digital CARM offset, because those transfer functions were to sqrtInvTRX, not plain TRX, whereas the model only is for plain TRX. There should only be an overall gain difference between them though, no phase difference. If you look at last night's data, you'll see that the positive side of the CARM offset measured phase has similar characteristics to the negative offset, i.e. the phase is not flat, but it is roughly flat in both modeled cases, so even with that data, I still say that we don't know what side of the CARM resonance we are on.
We're summarizing the discussions of the last few days as to the game plan for locking.
The first thing I looked at tonight was locking the PRMI on REFL 165.
I locked the PRMI (no arms), and checked the REFL 165 demod phase. I also found the input matrix configuration that allowed me to acquire PRMI lock directly on REFL165. After locking the arms on ALS, I tried to lock the PRMI with REFL 165 and failed. So, I rechecked the demod phase and the relative transfer functions between REFL 165 and REFL 33. The end of the story is that, even with the re-tuned demod phase for CARM offset of a few nanometers, I cannot acquire PRMI lock on REFL 165, nor can I transition from REFL 33 to REFL 165. We need to revisit this tomorrow.
For the PRMI-only case, I ended up using 0.1's in the input matrix, and I added an FM 1 to the MICH filter bank that is a flat gain of 2.2, and then I had it trigger along with FM2.
I turned this FM1 off (and no triggering) while trying to transition from REFL33 to REFL165 in the PRFPMI case, but that didn't help. I think that maybe I need to remeasure my transfer functions or something, because I could put values into the REFL165 columns of the input matrix while REFL33 was still 1's, but I couldn't remove (even if done slowly) the REFL33 matrix elements without losing lock of the PRMI. So, we need to get the input matrix elements correct.
I also recorded some time series for a quick RAM investigation that I will work on tomorrow.
I left the PRM aligned, but significantly misaligned both ITMs to get data at the REFL port of the RAM that we see. I also aligned the PRMI (no arms) and let it flash so that I can see the pk-pk size of our PDH signals. I need to remember to calibrate these from counts to meters.
Raw data is in /users/jenne/RAM/ .
I have not tried any new DARM signals, since PRMI wasn't working with 3f2.
We should get to that as soon as we fix the PRMI-3f2 situation.
The daqd process on the frame builder looks like it is segfaulting again. It restarts itself every few minutes.
The symptoms remind me of elog 9530, but /frames is only 93% full, so the cause must be different.
Did anyone do anything to the fb today? If you did, please post an elog to help point us in a direction for diagnostics.
Q!!!! Can you please help? I looked at the log files, but they are kind of mysterious to me - I can't really tell the difference between a current (bad) log file and an old (presumably fine) log file. (I looked at 3 or 4 random, old log files, and they're all different in some ways, so I don't know which errors and warnings are real, and which are to be ignored).
We've seen this before, but we need to figure out why POP22 decreases with decreased CARM offset. If it's just a demod phase issue, we can perhaps track this by changing the demod phase as we go, but if we are actually losing control of the PRMI, that is something that we need to look into.
In other news, nice work Q!
Last night I measured our RAM offsets and looked at how those affect the PRMI situation. It seems like the RAM is not creating significant offsets that we need to worry about.
Words here about data gathering, calibration and calculations.
Step 1: Lock PRMI on sideband, drive PRM at 675.13Hz with 100 counts (675Hz notches on in both MICH and PRCL). Find peak heights for I-phases in DTT to get calibration number.
Step 2: Same lock, drive ITMs differentially at 675.13Hz with 2,000 counts. find peak heights for Q-phases in DTT to get calibration number.
Step 3: Look up actuator calibrations. PRM = 19.6e-9/f^2 meters/count and ITMs = 4.68e-9/f^2 meters/count. So, I was driving PRM about 4pm, and the ITMs about 20pm.
Step 4: Unlock PRMI, allow flashes, collect time series data of REFL RF siganls.
Step 5: Significantly misalign ITMs, collect RAM offset time series data.
Step 6: Close PSL shutter, collect dark offset time series data.
Step 7: Apply calibration to each PD time series. For each I-phase of PDs, calibration is (PRM actuator / peak height from step 1). For each Q-phase of PDs, calibration is (ITM actuator / peak height from step 2).
Step 8: Look at DC difference between RAM offset and dark offset of each PD. This is the first 4 rows of data in the summary table below.
Step 9: Look at what peak-to-peak values of signals mean. For PRCL, I used the largest pk-pk values in the plots below. For MICH I used a calculation of what a half of a fringe is - bright to dark. (Whole fringe distance) = (lambda/2), so I estimate that a half fringe is (lambda/4), which is 266nm for IR. This is the next 4 rows of data in the table.
Step 10: Divide. This ratio (RAM offset / pk-pk value) is my estimate of how important the RAM offset is to each length degree of freedom.
Plots (Left side is several PRMI flashes, right side is a zoom to see the RAM offset more clearly):
I realized today that I had been plotting the wrong thing for all of my transfer functions for the last few weeks!
The "CARM offsets" were correct, in that I was moving both ETMs, so all of the calculations were correct (which is good, since those took forever). But, in the plots I was just plotting the transfer function between driving ETMX and the given photodiode. But, since just driving a single ETM is an admixture of CARM and DARM, the plots don't make any sense. Ooops.
In these revised plots (and the .mat file attached to this elog), for each PD I extract from sigAC the transfer function between driving ETMX and the photodiode. I also extract the TF between driving ETMY and the PD. I then sum those two transfer functions and divide by 2. I multiply by the simple pendulum, which is my actuator transfer function to get to W/N, and plot.
The antispring plots don't change in shape, but the spring side plots do. I think that this means that Rana's plots from last week are still true, so we can use the antispring side of TRX to get down to about 100 pm.
Here are the revised plots:
The first half of our evening was spent working on CARM and DARM in PRFPMI, and then we moved on to the PRMI part.
I moved the DARM ALSdiff -> TransDiff transition to be after the CARM ALScomm -> SqrtInvTrans transition in the carm_cm_up script. After I did that, I succeeded every time (at least 10? We did it many times) to get both CARM and DARM off of the ALS signals.
We tried for a little while looking at transitioning to REFL11 normalized by the sum of the transmissions, but we kept losing lock. We also several times lost lock at arm powers of a few, when we thought we weren't touching the IFO for any transitions. Looking at the lockloss time series did not show any obvious oscillations in any of the _IN1 or _OUT channels for the length degrees of freedom, so we don't know why we lost lock, but it doesn't seem to be loop oscillations caused by changing optical gain. Also, one time, I tried engaging Rana's "Lead 350" filter in FM7 of the CARM filter bank when we were on sqrtInvTrans for CARM, and the arm powers were around a few, but that caused the transmission signals to start to oscillate, and after one or two seconds we lost lock. We haven't tried the phase lead filter again, nor have we tried the Boost2 that is in FM8.
We increased the REFL11 analog gain from 0dB to 12dB, and then reset the dark offsets, but still weren't able to move CARM to normalized REFL11. Also, I changed the POP22 demod phase from 159 degrees to 139 degrees. This seems to be where the signal is maximized in the I-phase, while the arms are held off resonance, and also partway up the resonance peak.
We then decided that we should go back to the PRMI situation before trying to reduce the CARM offset further. We can robustly and quickly lock the PRMI on REFL33 while the arms are held off resonance with ALS. So, we have been trying to acquire on REFL33 I&Q, and then look at switching to REFL 165 I&Q. It seems pretty easy to get PRCL over to REFL165 I (while leaving MICH on REFL33 I). For REFL33, both matrix elements are +1. For PRCL on REFL165, the matrix element is -0.08. We have not successfully gotten MICH over to REFL 165 ever this evening.
We went back and set the REFL165 I&Q offsets so that the outputs after the demod phase were both fluctuating around 0. I don't know if they were around +/-100 because our dark offsets were bad or what, but we thought this would help. We were still able to get PRCL transitioned no problem, but even after remeasuring the MICH REFL33 vs. REFL165 relative gains, we still can't transition MICH. It seems like it's failing when the REFL33Q matrix element finally gets zeroed out, so we're not really getting enough signal in REFL165Q, or something like that, and throughout the rest of the transition we were depending entirely on REFL33Q.
Merging of threads.
ChrisW figured out that it looks like the problem with the frame builder is that it's having to wait for disk access. He has tweaked some things, and life has been soooo much better for Q and I this evening! See Chris' elog at elog 10632.
In the last few hours we've had 2 or maybe 3 times that I've had to reconnect Dataviewer to the framebuilder, which is a significant improvement over having to do it every few minutes.
Also, Rossa is having trouble with DTT today, starting sometime around dinnertime. Ottavia and Pianosa can do DTT things, but Rossa keeps getting "test timed out".
I changed the carm_cm_up.sh script so that it requires fewer human interventions. Rather than stopping and asking for things like "Press enter to confirm PRMI is locked", it checks for itself. The sequence that we have in the up script works very reliably, so we don't need to babysit the first several steps anymore.
Another innovation tonight that Q helped put in was servoing the CARM offset to get a certain arm power. A failing of the script had been that depending on what the arm power was during transition over to sqrtInvTrans, the arm power was always different even if the digital offset value was the same. So, now the script will servo (slowly!!) the offset such that the arm power goes to a preset value.
The biggest real IFO progress tonight was that I was able to actually measure the CARM and DARM loops (thanks ChrisW!), and so I discovered that even though we are using (TRX-TRY)/(TRX+TRY) for our IR DARM error signal, we needed to increase the digital gain for DARM as the CARM offset was reduced. For ALS lock and DC trans diff up to arm powers of 3, we use the same ol' gain of 6. However, between 3 - 6, we need a gain of 7. Then, when we go to arm powers above 6 we need a gain of 7.5. I was also measuring the CARM loop at each of these arm powers (4, 6, 7, 8, 9), but the gain of 4 that we use for sqrtInvTrans was still fine.
So, the carm_cm_up script will do everything that it used to without any help (unless it fails to find IR resonance for ALS, or can't lock the PRMI, in which case it will ask for help), and then once it gets to these servo lines to slowly increase the arm power and increase the DARM gain, it will ask you to confirm before each step is taken. The script should get you all the way to arm powers of 9, which is pretty much exactly 100pm according to Q's Mist plot that is posted.
The CARM and DARM loops (around the UGFs) don't seem to be appreciably changing shape as I increase the arm powers up to 9 (as long as I increase the DARM loop gain appropriately). So, we may be able to go a little bit farther, but since we're at about 100pm, it might be time to look at whether we think REFL11 or REFLDC is going to be more promising in terms of loop stability for the rest of the way to resonance.
Here are some plots from this evening.
First, the time I was able to get to and hold at arm powers of 9. I have a striptool to show the long time trends, and then zooms of the lockloss. I do not see any particular oscillations or anything that strikes me as the cause for the lockloss. If anyone sees something, that would be helpful.
This next lockloss was interesting because the DARM started oscillating as soon as the normalization matrix elements were turned on for DARM on DC transmissions. The script should be measuring values and putting in matrix elements that don't change the gain when they are turned on, but perhaps something didn't work as expected. Anyhow, the arm powers were only 1ish at the time of lockloss. There was some kind of glitch in the DARM_OUT (see 2nd plot below, and zoom in 3rd plot), but it doesn't seem to have caused the lockloss.
Not sure why, but Pianosa was frozen. Also couldn't ssh or ping. So, I hard power cycled it.
We spent the afternoon working on the new scan for IR resonance script. It is getting much closer, although we need to work on a plan for the fine scanning at the end - so far, the result from the wavelet thing mis-estimates the true peak phase, and so if we jump to where it recommends, we are only at about half of the arm resonance. So, in progress, but moving forward.
Tonight we repeated the process of reducing the CARM offset and measuring the DARM loop gain as we went. I'm not sure if I just had the wrong numbers yesterday, or if the gains are changing day-by-day. The gains that it wanted at given arm buildups were constant throughout this evening, but they are about a factor of 2 higher than yesterday. If they really do change, we may need to implement a UGF servo for DARM. New gains are in the carm_cm_up script.
We also actually saved our DARM loop measurements as a function of CARM offset (as indicated by arm buildups). The loop stays the same through arm powers of 4. However, once we get to arm powers of 6, the magnitude around 100 Hz starts to flatten out, and we get some weird features in the phase. It's almost like the phase bubble has a peak growing out of it. I saw these yesterday, and they just keep getting more pronounced as we go up to arm powers of 7, 8 and 9 (where we lost lock during the measurement). The very last point in the power=9 trace was just before/during the lockloss, so I don't know if we trust it, or if it is real and telling us something important. But, I think that it's time to see about getting both CARM and DARM onto a different set of error signals now that we're at about 100pm.
I'm not sure why, but c1iscex did not want to do an mxstream restart. It would complain at me that "* ERROR: mx_stream is already stopping."
Koji suggested that I reboot the machine, so I did. I turned off the ETMX watchdog, and then did a remote reboot. Everything came back nicely, and the mx_stream process seems to be running.
* ERROR: mx_stream is already stopping.