I don't know why, but as you can see in Steve's plot from earlier this morning, the PMC transmission has been going down significantly all weekend. The PMC refl camera was very bright. I tweaked up the alignment (mostly pitch), and now we're back to normal.
The IMC was having trouble staying locked all morning, and I'm hoping that this PMC adjustment will help - the MC already looks better, although it's only been a few minutes.
As part of our CESAR testing last night, we had a look at the noise of the 1/sqrt(TR) signal.
Looking at the time series data, while we were slowly sweeping through IR resonance (using the ALS), Rana noted that the linear range of the 1/sqrt(TR) signal was not as wide as it should be, and that this is likely because our SNR is really poor.
When a single arm is at a normalized transmission power of 1, we are getting about 300 ADC counts. We want this to be more like 3000 ADC counts, to be taking advantage of the full range of the ADC.
This means that we want to increase our analog gain by a factor of 10 for the low gain Thorlabs PDs.
Looking at the photos from November when I pulled out the Xend transmission whitening board (elog 9367), we want to change "Rgain" of the AD620 on the daughter board. While we're at it, we should also change the noisy black thick film resistors to the green thin film resistors in the signal path.
The daughter board is D04060, S/N 101. The main whitening board for the low gain trans QPD is D990399, RevB, S/N 104.
We should also check whether we're saturating somewhere in the whitening board by putting in a function generator signal via BNC cable into the input of the Thorlabs whitening path, and seeing where (in Dataviewer) we start to see saturation. Is it the full 32,000 counts, or somewhere lower, like 28,000?
Actually the gain was changed. From gain of 2 (Rgain = 49.4kOhm) to 20 (Rgain = 2.10kOhm), Corresponding calibration in CDS was also changed by locking the Xarm, running ASS, then setting the average arm power to be 1. Confirmed Xarm is locking. And now the signal is used for CESAR. We see emperically that the noise has improved by a factor of approximately 10ish.
[Nic, Jenne, EricQ, and Koji]
We have used CESAR successfully to bring the Xarm into resonance. We start with the ALS signal, then as we approach resonance, the error signal is automatically transitioned to 1/sqrt(TRX), and ramped from there to POX, which we use as the PDH signal.
In the first plot, we have several spectra of the CESAR output signal (which is the error signal for the Xarm), at different arm resonance conditions. Dark blue is the signal when we are locked with the ALS beatnote, far from IR resonance. Gold is when we are starting to see IR resonance (arm buildup of about 0.03 or more), and we are using the 1/sqrt(TRX) signal for locking. Cyan is after we have achieved resonance, and are using only the POX PDH signal. Purple is the same condition as cyan, except that we have also engaged the low frequency boosts (FM 2, 3, 4) in the locking servo. FM4 is only usable once you are at IR resonance, and locked using the PDH signal. We see in the plot that our high frequency noise (and total RMS) decreases with each stage of CESAR (ALS, 1/sqrt(TR) and PDH).
To actually achieve the gold noise level of 1/sqrt(TR), we first had to increase the analog gain by swapping out a resistor on the whitening board.
The other plots attached are time series data. For the python plots (last 2), the error signals are calibrated to nanometers, but the dark blue, which is the transmitted power of the cavity, is left in normalized power units (where 1 is full IR resonance).
In the scan from off resonance to on resonance, around the 58 second mark, we see a glitch when we engage FM4, the strong low frequency boosts. Around the 75 second mark we turned off any contribution from 1/sqrt(TR), so the noise decreases once we are on pure PDH signal.
In the scan through the resonance, we see a little more clearly the glitch that happens when we switch from ALS to IR signals, around the 7 and 12 second marks.
We want to make some changes, so that the transition from ALS to IR signals is more smooth, and not a discrete switch.
As Koji suggested in his email this afternoon, we looked at how much actuator range is required for various forms of arm locking: (1) "regular" PDH lock aquisition, (2) ALS lock acquisition, (3) CESAR cooling.
To start, I looked at the spectra and time series data of the control signal (XARM_OUT) for several locking situations. Happily, when the arm is at the half fringe, where we expect the 1/sqrt(TRX) signal to be the most sensitive (versus the same signal at other arm powers), we see that it is in fact more quiet than even the PDH signal. Of course, we can't ever use this signal once the arm is at resonance, so we haven't discovered anything new here.
EricQ then made some violin plots with the time series data from these situations, and we determined that a limit of ~400 counts encompasses most of the steady-state peak-to-peak output from locking on the PDH signal.
[ericq: What's being plotted here are "kernel density estimates" of the time series data of XARM_OUT when locked on these signals. The extent of the line goes to the furthest outlier, while the dashed and dotted lines indicate the median and quartiles, respectively]
I tried acquiring ALS and transitioning to final PDH signals with different limiters set in the Xarm servo. I discovered that it's not too hard to do with a limit of 400 counts, but that below ~350 counts, I can't keep the ALS locked for long enough to find the IR resonance. Here's a plot of acquiring ALS lock, scanning for the resonance, and then using CESAR to transition to PDH, with the limit of 400 counts in place, and then a lockloss at the end. Even though I'm hitting the rails pretty consistently, until I transition to the more quiet signals, I don't ever lose lock (until, at the end, I started pushing other buttons...).
After that, I tried acquiring lock using our "regular" PDH method, and found that it wasn't too hard to capture lock with a limit of 400, but with limits below that I can't hold the lock through the boosts turning on.
Finally, I took spectra of the XARM_OUT control signal while locked using ALS only, but with different limiter values. Interestingly, I see much higher noise between 30-300 Hz with the limiter engaged, but the high frequency noise goes down. Since the high frequency is dominating the RMS, we see that the RMS value is actually decreasing a bit (although not much).
We have not made any changes to the LSC model, so there is still no smoothing between the ALS and IR signals. That is still on the to-do list. I started modifying things to be compatible with CARM rather than a single arm, but that's more of a daytime-y task, so that version of the c1lsc model is saved under a different name, and the model that is currently compiled and running is reverted as the "c1lsc.mdl" file.
I am really, really happy to hear that it was just a sticking situation. Really happy.
Koji locked the MC, arms, and PRMI, with no troubles, after the M8.2 earthquake off the coast of Chile, that happened about 4 hours ago.
Koji and I have the PRMI locked right now, and we hear a very strong violin mode ringing up, at 628Hz. This is, according to Koji's elog 9634, what we expect the PRM's violin mode to be. However, the current PRM violin mode notch is really more of a bandstop filter, between 622-670Hz. At 628Hz, it has a suppression of about -20dB. If I try to increase the width of this notch by making it 612-670Hz, the PRMI won't hold lock.
We're leaving this as a daytime task for tomorrow, since we're in the middle of taking data to show that Koji's new ASC filter design (slightly tuned from his elog 9769) works well.
Edit: I have moved the PRM violin notch frequency over to 612-660 Hz, and after letting it sit for a while (while locked on PRMI), the violin mode has settled down. Interestingly, if I compare the spectrum with and without the 1st order violin mode notch, it looks like the 2nd order mode changes from 1256Hz to 1303Hz. I don't know what is going on here, but we already have notches for both of those frequencies.
I was trying to lock PRMI+2 arms, but I'm losing patience with the MC losing lock. It's mostly well-behaved, but every now and again it'll lose lock, and it always seems to be just when I've gotten to a delicate part. Anyhow. I don't think anything needs fixing.
I am not able today to acquire PRMI lock with REFL 165 I&Q, nor am I able to follow Koji's prescription to transition to 165 from 55. However, I am able to transition to, or just straight-up aquire on, REFL 33 I&Q. The new ASC is awesome.
Before trying to lock with REFL165, I redid it's demod phase, by actuating on the PRM while locked on REFL 55, and minimizing the PRCL signal in the Q-phase. Old 165 phase was -83.5 degrees, new is -79.5 degrees.
I then tried the procedure of misaligning the PRM, acquiring ALS lock of both arms, finding the arm IR resonances, and moving the arms off resonance. Then I restored the PRM, and locked the PRMI on sidebands using REFL33 I&Q.
Something was a little weird and unexpected: If the arms were not far, far off resonance, there was a large MICH offset, so that AS was bright, and POP was pretty dark. If I moved the arms farther from resonance, POP would come back to the "normal" brightness, which was ~460 counts on POP110I. When POP was dark-ish, POP110I was about 150, although this number could be changed by moving the arms around. This number was not dependent on PRM alignment. Also, PRCL was not yet starting to resonate the carrier, because POPDC stayed at its low sideband-lock level of about 90 counts (vs. 2,000+ for a PRMI-only carrier lock), and POP was visually dark on the camera.
While playing with PRMI + 2 ALS arms is entertaining for the evening, I don't yet have a plan for dealing with the changing CARM optical plant for IR signals situation. That's in progress in the daytime.
2 more earthquakes in Chile: a M6.4 and a M7.8.
We got them about 15 minutes ago (according to the BLRMS on the wall), but when I go tin, the MC was already locked, and engaging the LSC immediately got me PRMI lock (since that's the alignment state that the IFO was left in).
We started out this evening by locking the PRMI, on different REFL PDs, just to make sure that we could. We were able to acquire lock (without having to transition) on either REFL55, REFL33 or REFL165 (I&Q phases for each). By looking at the transfer function between REFL 55 I and REFL 165 I, I determined that the phase of REFL165 needed to be -135.5, not +44.5, so that the gains were the same sign in all REFL PDs (this is in reference to Koji's elog 9777). The time to acquisition is much shorter with REFL55 than with the other 2 photodiodes. I'm not sure right now why this is, but it's pretty consistent, and even more so when the arms are held off resonance. It is also easy to acquire lock with REFL 55 and then transition to either of the 3f diodes.
MICH gain = 2.0. FMs 4, 5 always on. FMs 2, 3, 6, 7, 9 triggered with 35 up, 2 down. Trigger servo on POP110I with 100 up, 10 down.
PRCL gain = -0.020. FMs 4, 5 always on. FMs 2, 3, 6, 9 triggered with 35 up, 2 down. Trigger servo on POP110I with 100 up, 10 down.
PRCL ASC triggered with 50 up, 10 down. Both pitch and yaw servos had FMs 1, 9 always on, and the FM 6 boost turned on by hand after lock acquired. Pitch gain = -0.023, yaw gain = -0.027.
If using REFL55, PRCL = I = 1 in the input matrix, and MICH = Q = 1 in the input matrix.
If using REFL33, PRCL = I = 3 in the input matrix, and MICH = Q = 3 in the input matrix.
If using REFL165, PRCL = I = 0.15 in the input matrix, and MICH = Q = 0.1 in the input matrix.
We then moved on to trying to do PRMI + 2 arms, but have been plagued a little bit by locklosses, which may be due to the high seismic from the few large and many small Chilean aftershocks.
Settings: With the PRM misaligned, we acquired ALS lock in a CARM/DARM fashion. The Xarm servo was our "darm" proxy, with +1*ALSX and +1*ALSY. The Yarm servo was our "carm" proxy, with -1*ALSX and +1*ALSY. The opposite signs from what you might expect is from our having placed the 2 aux laser frequencies on opposite sides of the PSL. Our DARM (xarm) was actuating +1 on ETMX and -1 on ETMY. Our CARM (yarm) was actuating +1 on MC2. Then we put in a CARM offset of ~60 counts.
We then realigned the PRM, and locked the PRMI (settings as above). It is much easier to acquire lock with REFL55 than it is with REFL33 or REFL165. Also, when we are locking the PRMI with REFL55, the AS port is dark, and we see bright sideband resonance at the POP port, as we normally expect. However, as with last night, when we lock the PRMI with either of the 3f PDs, we see a very bright AS port, and a dark POP port. Tonight, putting in a MICH offset did not seem to make a significant difference. As with last night, moving the arms farther away from resonance removed this MICH offset. I am sure that this is not an artifact of the photodiode dark offsets not being set properly, since I rechecked those carefully.
We have not come to any interesting conclusions about PRMI+2 arms tonight, since we have started losing the MC every few minutes (maybe seismic-related?).
Much more success later!
We've had the arms locked on ALS and held off resonance for more than 2 hours now. That's good. We've done several trials of locking the PRMI and trying to reduce the ALS CARM offset. Once we were able to get quite close, but we never achieved zero CARM offset.
One big finding is that when the TRX and TRY are about 0.1 in the coupled-cavity case, we start to see real length information in the 1/sqrt(trans) signals. Q will edit this elog, or reply to it, with the data that he has collected.
I played around with the PRMI + 2 arms situation again this evening. (I'm not ready to call it "PRFPMI" until we're at least partially using IR signals for CARM and DARM control).
I'm still a little bothered by the fact that we lose almost all light in the PRC when we're reducing the CARM offset. I'm not sure where the light is going, but it's not circulating in the PRC, since I see the POP camera get very dark. I can bring back light by changing either the PRCL offset, the MICH offset, or to a lesser extent (or maybe I'm not going far enough in offset) the DARM offset.
Tonight, I was using ALS to push on the ETMs in DARM/CARM mode (I didn't push on MC2 today, since it was being finicky and I had a hard time locking CARM with the MC as the actuator today).
For the PRMI, I was using REFL 33 I&Q. PRCL gain was -0.04, MICH gain was +0.8. REFL 33I varied between +2 and +1.2 (smaller gain necessary as CARM offset was reduced, but it's easier to acquire at large CARM offset with larger gain), and REFL 33Q was +1.0. PRCL has the usual FM 2,3,6,9 triggered, but MICH only had FM 2 triggered. The others (particularly FM6) make MICH lose lock. PRCL ASC was engaged, with the PRM oplev off.
Most of what I was trying tonight was to reduce the CARM offset, and then adjust some other offset (MICH, PRCL or DARM) to maximize POP DC. It's possible that the POP 110 and 22 diodes are changing their optimal demod phases as the optical plant changes, but POPDC is just DC.
I wasn't able to get the CARM offset below about 40 counts. At some point I had both CARM and DARM offsets at 50 counts, and had IR resonance in the Xarm, but no resonance in the Yarm. I guess this is just part of having a simultaneous CARM and DARM offset.
EDIT: If I leave the CARM offset at 0, and use a large DARM offset (100 counts), I can acquire PRMI lock, but I run into the same problems as I reduce the DARM offset - the POP power decreases, and I lose lock around 45 counts.
Side note: Earlier today I redid the POP 110 and 22 phases. POP110 was -61 deg, and is not -101 deg. POP22 was +164 deg, and is now -105 deg. I'm not sure why they needed such radical changes. When sideband locked on REFL33, POP110 had an average DC level of 580 cts, while POP22 had a value of 290 cts.
Koji was right, and I was using much too large of a CARM offset. Tonight, I set either my CARM or DARM offset to 3 counts, and was able to easily acquire PRMI lock using REFL33.
For either CARM or DARM offset reduction (the other one was kept at zero offset), I was able to get to about 0.5 counts, but I lose lock when I try to go to 0.4 or 0.3 counts. One time, I tried "jumping over" the resonance, by going from minus 1 to plus 1 in CARM offset. Plots of this below.
ALS locked with "Xarm" servo as proxy for DARM, and "Yarm" servo as proxy for DARM. Pushing only on ETMs today, not the MC.
MICH / PRCL:
Input matrix: 1's in REFL 33 I&Q, if not using power normalization. 200's in REFL 33 I&Q if power normalization used (either POPDC or POP22). 200 used because that's about the average value of POPDC or POP22 when PRMI sideband-only resonant.
Trigger: POP22, up 100, down 10.
Power normalization: 1's for both MICH and PRCL in POP22I for one trial. 1's for both MICH and PRCL in POPDC for another trial. Both seemed to work equally well, although that may change when I'm actually getting IR resonance in the cavity.
FM triggers: MICH = FM2. PRCL = FMs 2, 3, 6, 9. Trigger up = 35, down 10. PRCL delayed by 0.5 sec, MICH delayed by 5 seconds.
Servo gains: MICH = 0.4, PRCL = -0.01
When I approach the situation of both arms resonating, it pretty consistently looks like the PRM is getting pushed in pitch (and not in yaw). I don't know why this could be, but it seems like this is the big symptom before lockloss - if the POP spot starts moving (and the PRM suspit signal starts moving), PRMI lock is going to be lost.
I don't know if it's imperfect alignment, imperfect mode matching, or something else, but I see lots of high-order higher order modes on both the POP and AS cameras when the CARM or DARM offset is less than 1 count. I tried to take a video, but the brightness and contrast aren't set as high as on monitors 3 and 5, so it's hard to see the dim stuff. Youtube. At the midpoint of the video, you see a lockloss.
Even though I have overridden the transmission triggers so that I only use the QPDs for the transmission signals, I'm only seeing arm transmission values up to about 50 from each arm. If we had ideal PRC gain, we expect something like 650 or 700.
A few plots
All of the raw data for these plots, and several other channels, is in /users/jenne/PRFPMI/PRMI_2arms_8Apr2014/m1_to_p1_carmOffset_1081065069. As mentioned above, "XARM" is CARM, and "YARM" is DARM. So, the XARM_IN1 tells us about the CARM offset that I was applying. The start time is 1081065069, and the plots are all 8 seconds long.
First, the transmitted power and the CARM offset.
The REFL_I error signals and the CARM offset.
The RF signals that we will eventually chose from for CARM and DARM control. Note that I'm not sure about the AS55 phase, so I plot both I and Q.
The PRM suspit and sus yaw angular signals and the CARM offset. I don't see a huge change in the suspit signal, but it does seem to change character once we approach arm resonances.
I have taken EricQ's simulation results for the CARM plant change vs. CARM offset, and put that together with the CM and CARM digital control loops, to see what we have.
The overall gains here aren't meaningful yet (I haven't set a UGF), but we can certainly look at the phases, and how the magnitude of the signals change with CARM offset.
First, the analog CM servo. I use the servo shape from Den's elog from December, but only what he calls "BOOST", the regular servo shape, not any of the super boosts, "BOOST 1-3". No normalization.
Next, the digital LSC CARM servo (same filters as XARM and YARM). I have used FM4 and FM5, which are the 2 filters that we use to acquire regular LSC arm lock. For the actuator, I just use a 1Hz pendulum as if I'm pushing only on the ETMs.
I also used the exact same setups as above, but normalized the transfer functions by a DC photodiode output. The analog CM loops change the least (around a few kHz) if I use POPDC. The digital CARM loops change the least (around 100Hz) if I use TRX (or, equivalently, TRX + TRY).
Here are the normalized plots:
Either way, with or without normalization, the digital CARM loop will go unstable between 0-10pm, for both the REFL RF photodiodes. We need to figure out how to get a realistic transfer function out for the 1/sqrt(TRANS) signals, and see what happens with those. If those also look unstable, then maybe we should consider a DC signal for the analog CM servo to start, since that could have a wider linear range.
This evening we took things a little bit farther than last night (elog 9791) and transitioned CARM to fully IR signals, no ALS at all for CARM error signals! We were unsuccessful at doing the same for DARM.
As we discussed at 40m Meeting this afternoon, the big key was to remove the PRCL ASC from the situation. I don't know specifically yet if it's QPD saturation, or what, that was causing PRM to be pushed in pitch last night, but removing the ASC loops and reengaging the PRM optical lever worked like a dream.
Since we can now, using ALS-only, get arbitrarily close to the PRMI+2 arm full resonance point, we decided to transition CARM over to the 1/sqrt(transmission) signals. We have now done this transition 5 or 10 times. It feels very procedural and robust now, which is awesome!
To make this transition easier, we made a proto-CESAR for the CARM signals in the LSC. There's nothing automatic about it, it's just (for now) a different matrix.
ALS lock conventions:
We have (finally listening to the suggestion that Koji has been making for years now....) set a convention for which side of the PSL the X and Y beatnotes should be, so that we don't have to guess-and-check the gain signs anymore.
For the X beatnote, when you increase the value on the slow slider, the beatnote should increase in frequency. For the Y beatnote, when you increase the value on the slow slider, the beatnote should decrease in frequency.
The input matrix (the aux input part) should then have +1 from ALSX->carm, and +1 from ALSY->carm. It should also have -1 from ALSX->darm and +1 from ALSY->darm.
The output matrix should be carm -> +1's for both ETMs. darm should be -1 to ETMX and +1 to ETMY.
With these conventions, both carm and darm should have negative signs for their gains.
Since we don't have (although should whip up) Watch scripts for the CARM and DARM servo filters, we were using the Xarm filterbank for carm, and the Yarm filterbank for darm again.
Transitioning CARM to 1/sqrt(trans) signals:
As with last night, we were able to easily acquire PRMI lock with a CARM offset of 3 counts. We then moved down to 2 counts, and saw transmission values of 0.1-0.2. We set the offsets in the TR_SQRTINV filter banks so that the difference between the outputs was zero, and the mean of the outputs was 2 (the same as the CARM offset we had).
We looked at the relative gain and sign between the ALS and 1/sqrt() signals, and found that we needed a minus sign, and half the gain. So, we stepped the 1/sqrt() matrix elements from 0 to -0.5 in steps of 0.1, and at the same time were stepping the ALS matrix elements to CARM from +1 to 0, in steps of 0.2. This was, excitingly, very easy!
The first time we did this successfully, was a few seconds before 1081143556 gps.
Here is a set of spectra from the first time we locked on the 1/sqrt(trans) signals.
Failure to transition CARM to RF signals, or reduce CARM offset to zero:
While locked on the 1/sqrt(trans) signals, we looked at several RF signals as options for CARM. The most promising seems to be REFL55, normalized by (TRX+TRY). The next most promising looks like REFL11 normalized by POPDC. Note that these are entirely empirical, and we aren't yet at the resonant point, so these may not be truly the best. Anyhow, we need to reconfigure the LSC input of the normalized error signals, so that they can go into the CESAR matrices. This was more than we were prepared to do during the nighttime. However, it seems like we should be about ready to do the transition, once we have the software in place. Right now, we either normalize both ALS and the RF signal, or we normalize neither. We want to be able to apply normalization to only the RF signal.
Just sitting on the tail of the CARM resonance, there were some random times when we seem to have swung through total resonance, and spoiled our 1/sqrt(trans) signals, which aren't valid at resonance, and so we lost lock. This implies that auto-transitioning, as CESAR should do, will be helpful.
Attempt at transitioning DARM to AS55:
Next up, we tried to transition DARM to AS55, after we had CARM on the 1/sqrt signals. This was unsuccessful. Part of the reason is that it's unclear what the relative gain should be between the ALS darm signals and AS55, since the transfer function is not flat. Also, we didn't have much coherence between the ALS signals and AS55Q at low frequencies, below about 100 Hz, which is concerning. Anyhow, more to investigate and think on here.
Transitioning CARM to 1/sqrt signals, with a DARM offset:
As a last test, Q put in a DARM offset in the ALS control, rather than a CARM offset, and then was still able to transition CARM control to the 1/sqrt signals. As we expect, when we're sitting on opposite sides of the arm resonances, the 1/sqrt signals have opposite signs, to make a CARM signal.
Conclusions / path(s) forward:
We need to redo the LSC RF signal normalization, so that the normalized signals can be inputs to CESAR.
We need to make sure we set the AS55 phase in a sane way.
We need to think about the non-flat transfer function (the shape was 1/f^n, where n was some number other than 0) between the ALS darm signal and AS55. The shape was the same for AS55 I&Q, and didn't change when we changed the AS55 phase, so it's not just a phasing problem.
What DC signals can we use for auto-transitioning between error signals for the big CARM CESAR?
We're still working, but I'm really excited, so here's our news: We are currently holding the IFO on all IR signals. No green, no ALS is being used at all!!!!
PRCL and MICH in REFL33, CARM on 1/sqrt(trans), DARM on AS55 Q.
CARM actuating on MC2, DARM actuating +ETMY, -ETMX.
CARM offset is 1.9 counts, TRX averages about .1 counts. At this offset, we are able to transition CARM from ALS to DC Transmission signals and DARM from ALS to AS55Q.
A few more details on our work for the evening, of switching the PRFPMI completely to IR signals (although still with a pretty big CARM offset).
We did the same transition for CARM to 1/sqrt(trans) signals, as last night (elog 9793). The only difference is that for CARM actuation, we were using a -1*MC in the output matrix, rather than +1's for both ETMs.
We then had a look at the relative sign and gain between the ALS DARM signals, and AS55Q, using a calibration line in DARM. Before doing so, we used the DARM line (521.3 Hz, 50 counts) to rotate the AS 55 phase from -60.7 degrees to -97.7 degrees, which gave us about 20dB separation between the I and Q signals. This informed us that we needed a factor of about 400 less gain for AS55Q than for the ALS darm signal, as well as a minus sign, so I put -400 in the DC normalization place in the LSC for AS55, so that my input matrix would go from ALSY-ALSX (1's) to +1 in AS55Q.
This transition to AS55 was very easy, and once we did it, we held lock for 5 or 10 minutes, until a large earthquake from Papa New Guinea hit us. Note however, that we still had a large CARM offset, and our TRX and TRY signals were about 0.1 counts, when we expect several hundred at perfect resonance.
After that, we relocked, made both CARM and DARM transitions again, and tried to look at a CARM calibration line to see if we see CARM information in any of the REFL RF signals. We lost lock after a few minutes (so, not related to our calibration line), so we didn't finish, but it looks like REFL55I, normalized by TRX+TRY is the most promising. Also, REFL55's phase was already very good, while REFL11's phase was not.
There were some moderate changes to the LSC model that happened, and matching screen changes. I put in a switch just before the input triggering place of the CARM servo. This allows us to switch from the "regular" input matrix, and a CESAR signal. The inputs to the CESAR block are sqrtinv(TRX), sqrtinv(TRY), ALSX, ALSY and the output of the CARM row of the input matrix (so that we can have dynamic normalization of the RF signals). I have exposed all of these changes in the input matrix screens.
I also modified slightly the ALS watch scripts, to include CARM and DARM servo filter watching, so now we can use the actual CARM and DARM servos. We should make restore configure scripts for these!
The 2 gps times for when we made the transition from ALS DARM to AS55 DARM were 1081238160 and 1081240217. We want to go back tomorrow, and extract some nice time series.
Here's a spectrum though, of the difference in noise between DARM on ALS, and DARM on AS55. The CARM was always on 1/sqrt(Trans) signals during these spectra. We have an enormous gain in high frequency noise performance once we switch to the RF signal, which is great.
A few time series from last night's data.
300 seconds, starting from 1081240100, showing that as we move from ALSY-ALSX to AS55Q, the DARM error signal gets smaller.
The same 300 seconds, showing that the CARM error signal, and the arm transmissions, are not perturbed during this transition.
DARM in and out, for 300 seconds, showing that the control output also gets smaller.
A slightly longer time series, ending at about the same time, but starting a few minutes earlier, showing us (1) adding a 3 count CARM offset, (2) locking the PRMI (3) transitioning CARM to sqrtinv signals, and then (4) transitioning DARM to AS55Q.
CARM and DARM in and outs, for the 500 second time chunk showing all the transitions. Unfortunately, it looks like CARM_OUT is more noisy when it's on the sqrtinv signals, than it was on the ALS signals. Part of this may be that we have not yet swapped the resistor in the TRY QPD, to improve the SNR in the same way that we have already done for the TRX QPD. [EDIT, JCD: Also, we had hard-triggered the Trans switching, so we were only looking at the QPD sum for the TRX and TRY, and the QPDs only have a few ADC counts at low transmissions, so we had poor SNR for that reason too.]
I'm not sure why, but the WFS were turned off when I came in this morning. The MC was not staying locked, and even during brief locks, the FSS FAST out was railed at 10.
Aligning the MC mirrors to maximize the transmission, and then engaging the WFS seems to have made things better.
I have compressed the IFO Configure screen. All PRMI things (sideband lock and carrier lock) are in the PRMI button, all arm things (both RF and ALS) are in the respective arm buttons.
I have also made a new set of scripts for CARM and DARM lock acquisition with ALS.
I hope that each button's purpose is clear, but take a second to look at them before you next use the IFO Configure screen.
As payment for borrowing 2 of our seismometers, Zach has made us a new Trillium cable, to go from the granite station to the readout box, which we can put into 1X7, where the PEM ADC is. To put the T-240 in side the can, and seal it, we need a little jumper cable from the seismometer to the granite, but for now, we can just pass this cable underneath the can.
This afternoon, I was toying around with reducing either the CARM or DARM offsets (so, put in a CARM offset, leave DARM zero, lock the PRMI, then reduce CARM offset to zero. Or, put in a DARM offset, leaving CARM offset zero, lock the PRMI, then reduce the DARM offset to zero).
When looking at the data, I see that the MICH error signal gets fuzzier when the arms get close to resonance. (Note here that because I forgot to zero the carm offset before finding the resonances, -3 is my zero point for this plot and the next.)
Here is a zoom of the last piece of this time series, but with both TRX and TRY plotted (along with POPDC, CARM_ERR and DARM_ERR), where you can see that I had a momentary power buildup of > 100 transmission counts, which is about 20% of our final expected power.
Here is a different time series, showing a reduction of the DARM offset, and you can see that as the offset approaches zero, the MICH error signal gets noticeably more fuzzy. Somewhere near the 240 second mark, I lose PRMI lock.
I told Koji that I wanted to play with the common mode servo this evening, and he pointed out that we only get the signals after the digital demod phase angle in the digital system (obviously). So, if I want to use either REFL11 or REFL55 for my CARM signal, I want to do something in analog-land so that my digital demod phase is close to 0 or 90.
While we had the PRFPMI locked (with CARM offset of 2 or 3 nm), we set the demod phases of REFL11 and REFL55 to minimize a CARM line in the Q-phase. This gave us -34 degrees for REFL11, and -75 degrees for REFL55.
We calculated that about 1 degree of phase shift is about 1/(2 * pi * freq), or about 1.4e-8 seconds of delay for 11MHz. We took the speed of light in the cables to be about 2/3*c, so 1.4e-8 * 2e8 = 2.9 meters per degree for 11MHz. Since REFL11 was 34 degrees from 0, we estimate that we need to add about 98 meters of cable to the REFL11 signal path. The same calculation for 55 MHz, but with a 15 degree shift required, gives 8.8 meters of cable to be added to the REFL55 signal path.
I connected up some long BNC cables, and inserted them between the heliax breakout board on the LSC rack, and the respective PD inputs of the REFL11 and REFL55 demod boards. I used (45 meters + 45 meters + a little bit) for REFL11, and used about 9 meters for REFL55.
When we relocked the PRFPMI, and redid the phasing, we were very close to zero for both REFL11 and REFL55! REFL11's digital demod phase is now +1 degree, and REFL55's digital demod phase is -5 degrees.
We changed the input of the CM servo board from POY (which Den and Koji had been using in December - see elog 9500) to REFL11 I MON.
Q locked the FPMI (separate reply elog), and then we tried engaging the CM analog servo. We were not successful.
These settings were mostly copied from elog 9500, so they are almost surely not correct.
CM servo screen: In1 gain = 31dB, switch on, offset = -2.7V, boost off, super boosts off, option=disable, 79:1.6k switch disabled, polarity minus, option disable, AO gain=8dB, limiter enable.
For the slow path, CM_SLOW -> MC LSC servo had a +1 in the input matrix.
CM filters in the AUX_ERR screen: FM1 (unwhite) on, all others off, gain = 2.6.
MC servo filters: FM7, FM10 on, all others off (no triggered filter modules). Gain = 0 initially.
MC servo board AO path disabled initially, G=-32dB initially.
Once Q had the FPMI locked, I tried increasing just the CM analog gain (by enabling the AO path on the MC board, and increasing the gain). Doing this, I lost lock at -3 dB.
I then tried again, this time alternating increasing the analog gain, and increasing the MC LSC servo gain. I got up to 3e-3 for the MC digital gain, and -7 dB for the analog gain before we lost lock again.
We have determined that we should probably try just locking one of the arms with POX or POY, as Den and Koji did, to get a feel for how the system works.
This evening, as part of locking activities, we threw together some handy scripts.
The first one, "Lock_ALS_CARM_and_DARM.py" (no judging of my naming style!!), lives in .../scripts/ALS/ .
It acquires ALS lock in CARM and DARM mode, so we don't have to do it by hand anymore.
The first thing that it does is ask you to acknowledge that your beatnotes are in place, and they follow our new (newer than the last elog about conventions) beatnote convention. You are reminded in the terminal window what that convention is: When the temperature sliders for either arm is INCREASED, the beatnote frequency should INCREASE.
After you acknowledge that the beatnotes are good, it sets the CARM and DARM servo gains to zero, enables the outputs, sets the input matrix elements, clears the phase tracker histories, and starts ramping up the gains (with +1,+1 for DARM, the darm servo gain is +positive. with -1*ALSX,+1*ALSY for CARM, the carm servo gain is -negative). At a gain of 3, it engages the integrators and the resonant gains. At the final gain of 6, it engages the boosts.
We have used this script ~10 times tonight, and it's been great every time.
The next two scripts are for making the transition from ALS to IR signals. They both live in ..../scripts/PRFPMI/
"Transition_CARM_ALS_to_TransSqrtInv.py" (again - no judging!) slowly blends the input matrix elements to swap CARM control from the ALS signals to the 1/sqrt(trans) signals. It takes a few steps, and asks for a keyboard input between steps. This is because if our 1/sqrt(trans) offsets aren't perfect, we can start to lose transmission power. To mitigate this, we decrease the offset in the CARM servo filter bank to get more power back. This script requires an input, which is what you want the final sqrtinv matrix elements to be. It will fail without this. For a CARM offset, both of the final sqrtinv matrix elements will have the same sign.
"Transition_DARM_ALS_to_AS55.py" (I can telepathically hear you judging me right now.) does the same blending, except to swap DARM control from ALS signals to AS55Q. For the same reason of imperfect offset-setting, it takes several steps, to allow you to adjust the CARM offset if needed. Although, after typing this, I realized that perhaps we should have been tweaking the DARM offset. Either way, this transition required much less tweaking of offsets than the CARM transition did. Again, the script requires an input, which is your final desired AS55Q->DARM matrix element value.
* Both of these scripts should be run at a digital CARM offset of about 2 counts, although with the offset tweaking during the CARM transition, I usually end at about 1.5 counts.
* To determine the final gain value for the CARM sqrtinv matrix elements, we have been using a spare filter bank (ex. XARM), and having the input to that be the sum of the sqrtinv channels. We then put in a CARM line, and look at the transfer function between the temporary filter bank's input, and the CARM_IN1.
* To determine the final gain value for the DARM AS55 matrix element, we have been doing a similar thing, looking at the transfer function between DARM_IN1 and AS55Q with a DARM line on. We have been putting this DC gain into the static PD normalization (4th block from the left on the big LSC screen), although with the new script, it will be easier to just put that value into the matrix element.
Tonight, we transitioned CARM and DARM to IR signals, took loop transfer functions, and determined that we could engage the LSC boosts (FM4 in the CARM and DARM servos, which are the same as the XARM and YARM servos).
Q is preparing spectra to post, and I will dig out time series. Look for these tomorrow, if they aren't posted tonight.
For the time series data fetching, I have taken notes on what we were doing when, so that I can actually find the data.
11:09pm: CARM's LSC boost on for the first time
11:14pm: DARM transferred to AS55Q
11:21pm: DARM's LSC boost on for the first time
11:53pm: CARM transition
12:02am: DARM transition done, both LSC boosts on
12:04am: lockloss after reducing CARM digital offset to 0.4
12:45am: PRMI + 2 arms flashing, with no CARM or DARM offsets (arms still on ALS) because we forgot to put in the CARM offset before restoring PRM alignment. PRMI may have been actually locked, or we may just have been flashing....need to look through the data to see what our recycling looked like.
1:05am: pretty smooth transition completed (both CARM and DARM), but we lost lock while reducing the CARM offset.
1:19am: lockloss - why?? We were just sitting at a CARM offset of about 1.3nm (1.3 counts), holding on IR signals. We were not touching any IFO things while looking at some plots, and just lost lock. Want to see if we can understand why.
1:27am: another nice smooth transition for both CARM and DARM to IR signals, but almost immediate lockloss when reducing the CARM offset.
Using the new ALS lock acquisition scripts (elog 9816) and our transition scripts, getting back to PRFPMI lock is pretty smooth and procedural.
* Align arms using ASS (ifo configure screen, restore xarm and yarm, run both arms' ass scripts).
* Align PRMI, no arms (ifo configure screen, restore prmi sideband)
* Find ALS beatnotes, with arm lasers on opposite sides of the PSL. For both, when increasing the value of the temperature slider, the beatnote should increase in frequency. (ifo configure screen, restore CARM and DARM als)
* Run ...../scripts/ALS/Lock_ALS_CARM_and_DARM.py
* Run "Find resonance" scripts from ALS screen for each arm.
* Put in a 3 count offset to CARM loop.
* Restore PRM alignment. (PRMI should acquire lock immediately, although PRM may need some small alignment tweaking). Enable PRCL and MICH outputs, PRM and BS actuation outputs.
* Reduce CARM offset to 2 counts.
* Set offsets of 1/sqrt(TRX) and 1/sqrt(TRY) filter banks in the AUXERR section of the LSC screen. The outputs of both should equal 2 counts (to match the 2 count offset in the CARM loop).
* Run .../scripts/PRFPMI/Transition_CARM_ALS_to_TransSqrtInv.py , making sure to reduce the CARM digital offset if needed, to keep the arm transmissions at about 0.1 counts.
* Engage FM4 of the CARM filter bank, which is the LSC boost.
* Run .../scripts/PRFPMI/Transition_DARM_ALS_to_AS55.py , making sure to reduce the CARM (or should be DARM?) digital offset if needed, to keep the arm transmissions at about 0.1 counts.
* Engage FM4 of the DARM filter bank, which is the LSC boost.
Notes for going forward:
When we have small-ish digital CARM offsets, such that both of our arm transmitted powers are about 0.1 or higher, we see clear coherence between our CARM_IN1 (the 1/sqrt(trans) signals) and a normalized REFL11_I (again using a spare filter bank like XARM to get REFL11 normalized by (TRX+TRY) ). We have not yet tried transitioning the CARM digital error signal to this normalized REFL11.
Even though we see that the IFO is much less noisy (as measured by significantly reduced RIN in TRX and TRY as visible by eye on Dataveiwer), we are still losing lock when we reduce the CARM offset. I have noted above several times, for when we had locklosses, so that I can see if I see anything elucidating in the time series data.
I looked at 2 of the locklosses from last night, (1:19am and 1:27am), and saw that for both, the DARM loop started to oscillate just before we lost lock. In the trials tonight, we were more watchful of gain peaking.
Here is the 1:19am lockloss
And here is the 1:27am lockloss
So you can see what we were doing, and what the effect was, here is a few minutes of data just before the 1:27am lockloss. The times I note below are rough, but should give you an idea of what happened at which time.
0 sec: Arms are held on resonance with ALS.
10 sec: CARM offset of 3nm added.
20 sec: PRM restored, one flash, then PRMI acquires lock.
30 sec: CARM offset reduced to 2nm, transmitted powers are about 0.1
50 sec: Transition CARM to 1/sqrt(trans) signals. Note that we are using the high gain Thorlabs PD here, so the noise is better than last Thursday.
60-110 sec: CARM offset reduction to about 1nm.
110 sec: CARM's LSC low frequency boost engaged.
120 sec: DARM transitioned to AS55Q.
170 sec: DARM's LSC low frequency boost engaged.
Last night, EricQ and I were concerned that we might need some CARM UGF servoing, so I added a UGF servo block, copied from the aLIGO LSC model, to our LSC model. The block is inline with the CARM servo, after the output triggering, just before the output matrix. Q put together some screens, which are accessible from the main LSC screen.
The model is compiled and running. We didn't get very far in testing it though before Koji pointed out that it is a slow solution, and not a fast one like we were searching for. We were hoping to deal with the momentary power buildup, and thus optical gain change, as the arms flash close to resonance. The UGF servo will not work nearly that fast though. We may want it for slow UGF servo-ing, but it's not the solution to what Q and I were thinking about yesterday. Regular ol' dynamic normalization is closer to the right answer for this.
In tonight's activities, Koji and I found that we probably want a CESAR block for DARM as well as CARM, so that we can independently normalize AS55Q.
To solve the DARM oscillation issue from last night (that I discovered this evening when I finally looked at the time series data), we may want to implement a DARM UGF servo. For tonight, as we reduced the CARM offset and started seeing gain peaking in the DARM spectra, I hand-reduced the DARM gain.
This evening, Koji and I followed the procedure from last night (elog 9817), with the exceptions that as we saw gain peaking in the DARM spectrum, we lowered the DARM servo gain. We also left the DARM FM4 boost off, and added (TRX+TRY) power normalization to AS55 (although we still had to hand-reduce the gain). These changes enabled us to reduce the CARM offset much further. We were able to get the transmitted powers to hold steady at about 1 count while on the IR signals, which is a new record for us. (We had in the past held the arms with ALS at several counts, but the power fluctuations were huge, and now they are nice and small).
After that, we started looking at whether we could transition CARM over to REFL11I. We tried a few times, but never made it all the way.
Here are some times for data-foraging tomorrow:
8:27pm, nice transition, CARM offset reduction to 0.6 before lockloss.
9:19pm, turned on power normalization for AS55Q, then reduced CARM offset to 0.5
9:40pm, Lockloss after reducing CARM offset to -0.24, arm transmitted powers around 0.9.
gps 1081748419: First trial trying to transition CARM to REFL11I normalized by (TRX+TRY).
gps 1081749965: Tried to transition CARM to (REFL11 + REFL33)/(TRX+TRY). Got about 1/3 of the way through the transition (in terms of matrix element value steps) before lockloss.
11:56pm, Tried to add in REFL11I to CARM error signal (without reducing 1/sqrt(trans) matrix elements). We increased the REFL11 matrix element until we saw gain peaking, and then tried reducing the 1/sqrt(trans) contribution, and lost lock. We were only at an offset of 0.3, so we probably weren't close enough to the resonance yet. We were able to add in REFL11 information, but this was probably not too hard, since there wasn't much actual information in it.
* It's a little weird that once we are on IR signals, the 0 CARM offset point that we find with ALS is not the true CARM offset point. Although, this may be because we're just going to an averaged no CARM offset place with ALS, but since ALS is noisy, we won't ever really be holding on the zero offset point. Anyhow, when we were using the 1/sqrt(trans) signals for CARM, and the CARM digital offset was -0.24, the ALSX and ALSY outputs were both about 0.5 in magnitude.
* We're getting there!
I have made the same modification to the Yarm trans PD whitening board as was done for the xend, to increase our SNR. I put in a 2.1kOhm thin film resistor in the Rgain place.
When I was pulling the board, the ribbon cable that goes to the ADC had its connector break. I redid the ribbon connector before putting the board back.
I see signals coming into the digital system for both the high gain and low gain Y transmission PDs, so I think we're back. I will re-do the normalization after Jamie is finished working on the computers for the day.
Jamie tells me that the 2 big consequences of this are (a) we are not archiving any data that is collected on the ioo machine, and (b) that we will not have access to test points on the IOO or ALS models.
To make sure that this is not a show-stopper for locking, I have locked the arms using ALS. The signals seem to still be getting from the ALS model to the LSC model, and I'm able to acquire ALS lock, so we should be able to work tonight. All of the data that I have been looking at lately has been coming off of the LSC machine, so we should even be okay in terms of look-back for lockloss studies, etc.
Some time series data from Wednesday night.
Here is the first time we've gotten the arm transmissions to about 1 count, while holding CARM and DARM on IR signals, so the transmission, as well as POPDC, were relatively quiet.
As we were attempting to transition CARM to REFL11I, at least 2 of the times, we were hitting a CARM oscillation:
Last night, as well as tonight, the ALS seems not quite as robust as it was earlier in the week.
I have just taken noise spectra, and ALS is definitely more noisy than usual.
These plots are with the arms held in CARM and DARM mode, with servo gains of 8. I was seeing the beginnings of gain peaking at a gain of 10, so I turned it back to 8. Our ALS in-loop RMS is usually something like a few hundred Hz, but I'm seeing over 1kHz, so I have a factor of 4 or 5 too much noise. Why?!?!?
P.S. I realigned the Y green to the arm and brought GTRY to 0.93
This evening, I was not able to successfully transition CARM from ALS to 1/sqrt(trans) signals. The TRY time series looked odd, so I took a spectra, and we have huge 60Hz noise in TRY.
I found a lock stretch from around 6:30pm that did not show the 60Hz noise, and then there was a lock stretch around 8pm that did have the noise. So, something happened at the Yend between 6:30 and 8pm tonight.
Asking around, this was the time frame in which Manasa was down at the Yend to realign the green beam, and to check cabling for the PZT_OUT and ERR_MON signals to the ADC.
Looking at the spectra, Rana noted that we have even as well as odd harmonics of the 60Hz line, which is unusual.
To try to diagnose the problem, Rana and I tried to make sure no cables' connectors were touching, and that no equipment was plugged in that shouldn't be. We noticed that none of: the shutter, the Thorlabs TRY PD, or the QPD TRY are isolated from the table. To see if perhaps the shutter was the problem, I turned off the power to the Yend green shutter, and unplugged the cable. The cable is laying on the table, with the connector sitting on a piece of plastic to isolate it. Removing the shutter from the system did not change anything.
We don't see the 60Hz noise in the Xarm, so it's not on the laser light itself. Also, we don't see the 60Hz lines in the Yarm feedback signal, so we're not putting the lines onto the mirror, and thus onto the Yarm's light.
Manasa, can you please take a look, and see if you can figure out what is going on? We need TRY so that we can transition to 1/sqrt(trans) signals for CARM. Thanks!!
The frame builder (or something) is unhappy again. I know that we've seen this before, but I can't find the elog entry that relates to this particular problem.
Every few minutes, the fb status lights on the CDS_STATUS screen go white, and then come back green. It's annoying when it happens every hour or so (which is unfortunately typical), but it's pretty debilitating when it stops dataviewer and dtt every few minutes. Just from the way the lights change, it looks like perhaps the daqd process is restarting itself periodically?
To see if perhaps the shutter was the problem, I turned off the power to the Yend green shutter, and unplugged the cable. The cable is laying on the table, with the connector sitting on a piece of plastic to isolate it. Removing the shutter from the system did not change anything.
I re-plugged in the Yend shutter, and turned it on.
I tried some locking anyway tonight, even though we don't have TRY.
The biggest conclusion is that I miss the auto-resonance-finding. I've been roughly scanning the Y-ALS offset to find the POY zero crossing when I see the resonance on the test mass face cameras.
The next-biggest conclusion, is that I can hold the PRFPMI close to resonance, using ALS for CARM and DARM. I was trying to transition DARM to AS55, but I couldn't get the last bit of the way. That is, I couldn't turn off the ALS control. So, I think that AS55 wasn't actually holding DARM, until maybe the last moment or so.
Anyhow, here are some time series. My average TRX value is around 40 counts, and POPDC is maybe 250 counts (just PRMI, POPDC is about 75 counts). Obviously this is noisy as hell, but I'm not using any IR signals for the arms. Near the end of this first time series, I am trying to switch to AS55 for DARM.
Zooming in, my real lockloss is due to PRCL oscillating at ~350 Hz:
However, I also saw ~25Hz peaks in CARM and DARM on the spectra starting to show up, and I see a ~25 Hz oscillation in DARM a few moments after the PRCL lockloss. (Plot #2 is a zoom of the ~1.1 second mark on Plot #3.)
The locking parameters:
Input: Using the new CESAR matrix, -1*ALSX, +1*ALSY. Beatnotes both move up in freq if temp sliders move up.
Servo: gain = 6, FMs 1, 2, 3, 5, 6, 7, 9 on. Offset = 0 counts.
Output = -1*MC2
Input: +1*ALSX, +1*ALSY
Servo: gain = 4. FMs 1, 2, 3, 5, 6, 7, 9 on. Offset = 0 counts.
Output = -1*ETMX, +1*ETMY
Input: +1*REFL33_I, Norm = +0.01*POPDC, sqrt engaged.
Servo: acquisition easier with -0.04 or -0.06, less gain peaking at -0.02 FMs 4, 5 on; 2, 3, 6, 9 triggered with 0.5 sec delay. Servo trigger = POPDC, up 100, down 10. FM trigger = POPDC, up 300, down 20.
Output = +1*PRM
PRCL ASC off, PRM oplev on.
Input: +1*REFL33_Q, Norm = +0.01*POPDC, sqrt engaged.
Servo: gain = 2, FMs 4, 5 on; 2, 3 triggered with 0.2 sec delay. Servo trigger = POPDC, up 100, down 10. FM trigger = POPDC, up 300, down 20.
Output = +0.5*BS, -0.2625*PRM
REFL33 analog gain set to 30 dB for both I&Q.
AS55 set to 0 dB for both I&Q. AS55 had DC normalization of 80 counts (which was the measured number for PRFPMI when TRX was about 0.1 count this evening)
Here is 1 second of data, with REFLDC, POPDC and TRX:
Here is a zoom of the first 3 big peaks in TRX. The weird jumps at the beginning of each TRX peak are due to the triggered switching between the Thorlabs trans PD and the QPD trans PD. Clearly we need to work on their relative normalizations. There are also little jumps after each peak as the triggering sends the signal back to the Thorlabs PD.
Here is a zoom of the single big peak about halfway through the 1 second of data:
And here is a zoom of the tail of that peak. It looks to me like we want to start thinking about using REFL DC when our transmitted powers are around 2 counts. We could do as soon as 1 count, but 2 is a little farther into the dip.
The weird jumps at the beginning of each TRX peak are due to the triggered switching between the Thorlabs trans PD and the QPD trans PD. Clearly we need to work on their relative normalizations. There are also little jumps after each peak as the triggering sends the signal back to the Thorlabs PD.
I was unhappy with the discontinuities between the Thorlabs and QPD versions of our transmitted light powers. I realized that in the olden days, we just used the Thorlabs PD, and we set the no-light offset in the LSC version of the TR[x,y] filter banks. However, now that we have brought the QPDs back, we are setting the dark offsets in the end suspension models, so that the signal chosen by the trigger already has its offset taken care of before we send it to the LSC model.
Anyhow, having the offsets script try to put a value in the C1:LSC-TR[x,y]_OFFSET was giving us an extra offset and then when we did the normalizations, the numbers came out all wrong. So. I have removed the C1:LSC-TR[x,y] filter banks from the offset list, since they were made redundant.
I have redone the normalizations for both arms (after running the ASS scripts). I checked by watching the _OUT16 versions of the Thorlabs and QPD diodes before the triggering happens, and as I put offsets into the LSC servos to change the transmitted power, the diodes both change in the same way. So, we'll have to see if this holds true for more than just values 0-1 the next time we lock, but hopefully it won't need changing for a while.
The IFO is being uncooperative tonight, and I have an early morning meeting, so I'm calling it a night.
Koji's filter module changes have been propagated from the Xarm to the Yarm, to CARM and to DARM. (Actually, Q overwrote the changes to Xarm on Sunday accidentally, so first he reverted those for us, and then we propagated the changes).
Today, with careful measuring, we find that for X and Y arms individually locked with the ALS, we want the gains to be +17 for the Yarm, and -17 for the Xarm (with the beatnote up-is-up convention). This puts the UGFs at 150 Hz.
We then switched over to CARM and DARM locking. We guessed that the gains should be a factor of 2 lower since we're pushing on both ETMs for DARM, and the MC2 actuator is roughly the same strength as the sum of the ETMs. In the end, after measuring the CARM and DARM loops, we find that the gains should be +7.5 for CARM, and +8.0 for DARM to set the UGFs at 150 Hz. The servo is a little bit delicate, so having too low of gain is not okay.
For some reason, we seem to be utilizing more actuator range with the new setup, so the limiters in the filter banks have been set to 11,000 (previously were 8,000), and the ALS watch script (ALSdown.py) threshold has been increased to 10,000 (previously 7,000).
When finding the IR resonances with the new scheme, we are having trouble holding lock throughout the scan. I have set the tramp for the coarse part of the scan to be 0.05 seconds (previously 0.01 seconds), which is an increase of a factor of 5 in the ramp time. This helps, but may still not be enough, since we don't always hold lock until both IR resonances are found.
Probably the most annoying thing from tonight is the fact that ETMY keeps drifting off, particularly in yaw, when locked. I don't have an explanation of why this is happening, but you can watch it happen sometimes, and the lock will be lost shortly thereafter. Definitely when we lose lock and the ETM gets kicked, it is far enough away in yaw alignment that I have to completely redo the Yarm alignment. This happens whether or not the ETMY oplevs are on.
To summarize, 3 scripts have been modified:
(1) ALSdown - threshold increased (Modification from last week - turns off the slow temp servos for the end lasers, clears histories)
(2) ALSfindIRresonance - increase ramp time
(3) Lock_ALS_CARMandDARM - final gain values set to 7.5 for CARM and 8 for DARM, no filters come on until gains all the way up, turns on new set of Koji filters. (Modification from last week - turns on the slow temperature servos for the end lasers)
[Rana, EricQ, Jenne]
We locked the Yarm by using the CM board this evening.
POY is going from its demod board to the CM board, and then the slow output of that is going to the POY channel of the whitening, and then on to the ADC. So, with no AO path engaged, this is basically like regular Yarm locking.
First of all, Den and Koji back in December were concerned that they were seeing some EOM saturation in the fast path, but we don't think that's an issue. We looked at the FSS PCDRIVE while we increased the AO gain. In fact, it looks like the offset is coming from the MC board's IN2 slider. Even with no input on that slider, increasing its value puts an offset into the MC. To fix this, I am going to put a 6.8uF cap in series with R30 in the MC board, which is part of the crossbar switch where the IN1 and IN2 get summed. This should AC-couple the output of the IN2 slider before the summing node.
We aren't sure which sign to use for the AO path of the CM board...Eric is doing some modelling to see if he can figure it out. He's going to try to see which spectra (below) his model matches.
For the spectra, we have a reference trace with no AO path, a trace with "Plus" polarity on the CM board which started to show a peak when the value of the MC IN2 slider was at about -6 dB, and a trace with "Minus" polarity, which started to show a peak when the value of the MC IN2 slider was at about -16 dB.
We took loop measurements for each of the Plus and Minus cases. Something that seems a little weird is how shallow of a slope we have in both cases near our UGF.
To fix this, I am going to put a 6.8uF cap in series with R30 in the MC board, which is part of the crossbar switch where the IN1 and IN2 get summed. This should AC-couple the output of the IN2 slider before the summing node.
MC board is out, so don't be surprised that the MC isn't locking.
MC board is back in place, MC is locked.
If I disable all of the AO path bits of the CM servo (disable switch, and also gain slider to -32dB), and then move the MC IN2 slider around, the MC does not get an offset anymore (as seen by reduced transmission and increased reflected power), so I think the DC coupling is working. I do lose lock of the MC if the slider goes above ~22 dB in this situation, but I don't see any effect before then, whereas we were able to see a steady increase in the reflected power as we moved the slider around last night. So, it seems like things are good with the DC coupling of the IN2 slider.
Here are some photos from before I modified the board (front, back, and zoom of the area I was working in):
And here is my modification, putting the 6.8uF cap in series with (a new) 2k thin film resistor, in the spot for R30:
The board is https://dcc.ligo.org/DocDB/0004/D040180/001/D040180-C.pdf
[Edit, 20140721: It looks like this is actually D040180 rev B, not rev C. —Evan]
I touched up the alignment of the Ygreen on the PSL table.
I have taken out of loop spectra for both arms, by looking at POX/POY while the arms were controlled with ALS.
To do this, I put the POY11 Q signal directly to the whitening board, which meant that I removed the cable coming from the common mode board. (Now that we're doing CM stuff again, I have put it back, so POY is still in the slightly weird "going through the CM slow path" situation).
For the locking, both arms had FMs 1, 2, 3, 5, 6 engaged. Yarm had a gain of +17, Xarm had a gain of -17.
Y beatnote was 98.6MHz with a peak height of -22 dBm. X beatnote was 45.0MHz with a peak height -11 dBm.
I drove ITMY at 503.1 Hz with 100 counts. I drove ITMX at 521.1 Hz with 25 cnt.
Koji helped me match up the peak heights between the FINE_PHASE_OUT_HZ calibrated signals and the PDH signals.
The out of loop noise is definitely below 1kHz rms now, which is better than it was! Hooray!
Today I finally implemented a feature in the whitening triggering that I should have a long time ago: an override button.
Now, on each RFPD's phase rotation screen, there is a button to either allow triggering for that PD (both quads) or to be in manual mode.
If you are allowing triggering, they will behave as they have for the last ~year.....if any degree of freedom is using either quadrant of that PD, and that degree of freedom is triggered, then engage analog whitening and digital de-whitening.
If you chose manual mode, then you can engage or disengage the whitening as you please. (The analog whitening and digital de-whitening are still tied together).
This evening, we were able to lock the Yarm through the common mode board, using AS55 as our error signal. Our final UGF is about 5kHz, with 60 degrees of phase margin.
Before dinner, Rana switched the input of the CM board's REFL1 input to be AS55I rather than POY11Q, in the hopes that it would have better SNR. Demod phase of AS55 was measured to be 14 deg for optimum Yarm->I-phase and has been set to 0 degrees. Since the POY demod phase had been 90 degrees, which puts in a minus sign, and now we're using 0 deg which doesn't have a minus sign, we're using the plus (instead of minus) polarity of the CM board.
We re-allocated gains to help lower the overall noise by moving 15dB from the CM board AO gain slider to the MC IN2 gain slider, so we weren't attenuating signals.
We see, by taking loop measurements even before engaging the AO path (so, just the digital loop portion) that we've gained something like 20 degrees of phase margin! We think that about 5 degrees is some LSC loop re-shaping of the boost filter. We weren't sure why there was a hump of extra gain in the boost filter, so we've created a new (FM8) boost filter which is just a usual resonant gain: resgain(16.5,7,50)
The cm_down and cm_step scripts in ..../scripts/PRFPMI/ were modified to reflect the settings below, and their current states are included in the tarball attached.
Also, throughout our endeavors this evening, the PC fast rms has stayed nice and low, so we don't suspect any EOM saturation issues.
Now our Yarm digital servo has a gain of -0.0013, with FMs 2, 4, 5, 7, 8 engaged (2, 7, 8 are triggered).
Our final CM board settings are:
REFL1 gain = +22dB
offset = -2.898V
Boost = enable
Super Boost = 0
option = disable
1.6k:79 coupled cavity compensator = enabled
polarity = plus
AO gain = 15dB
limiter = enable
MC board: IN1 gain = 18dB, IN2 gain = 0dB.
Here is a measurement of the Common Mode MCL/AO crossover. The purple/orange trace here is after/before the boost was engaged.
We also have a measurement of the total loop gain, measured with the SR785. The parameter file, as well as the python script to get the data, are in the tarball attached. Noteably, the excitation amplitude was 500mV, whereas Q and Rana yesterday were using 5 or 8 mV. We aren't sure why the big change was necessary to get a reasonable measurement out. This measurement is with the boost enabled.
Finally, here is a measurement of the MC error point spectra, with the CM boost on, after we reallocated the gains. There's a giant bump at several tens of kHz. We need to actually go out with the fast analyzer and tune up the MC loop.
To get ready for the PRFPMI CM trials tonight, I put AS55's cables back to their nominal state, and now have REFL11 I going to IN1 of the CM board. The OUT1 of the CM board goes to the REFL11I whitening channel.
REFLDC was not disconnected in the last few days, so it is still set up for IN2 of the CM board, with an external offset adjust.
I was thinking about POP today, and wanted to know if there was something to be done to allow us to use the PRCL ASC for at least a little bit farther into arm power buildup.
Anyhow, I checked, and while PRMI is locked on sidebands (ETMs misaligned), POP DC is about 80 counts, and the power measured by the Ophir power meter is 24 microWatts.
We were on the 3rd gain setting for the QPD's power amplifier. I turned it down to the "2" option. (When at 4, the front panel light indicates saturation).
It's not clear to me what the gain settings mean exactly. I think that "1" means 4*10^3 V/A, and "6" means 4*10^6 V/A (On-Trak OT301 info site), but I don't know for sure how the gain changes for the settings 2-5. Anyhow, I have changed the digital gain for the ASC to be -0.063 from -0.023 for both pitch and yaw.
As part of checking the common mode board before we get too carried away with using it, I looked at the time series of the AO servo output when I turned on various boosts, or changed gain values. As it turns out, basically anything that I did caused glitches. Oooops.
I plugged a function generator to the IN1 port of the CM board, with a freq of 400Hz, and a voltage of 10mVpp (which is the smallest value that it would allow). I plugged the BNC version of the servo output into a 300MHz 'scope.
First I looked at "boost" and "super boost", and then I looked at various steps of the AO gain slider. For all of the button presses that gave me glitches, I saved .png's of the 'scope screen (on a floppy, so I'll have to fetch the data tomorrow...).
Both enabling, and disabling the "Boost" button gave me glitches.
For "Super Boost", I saw glitches for all of the steps, 0->1, 1->2, 2->3.
For the AO path, I only started at 0dB, and only captured screenshots of glitches when I increased the gain, since presumably that's when we'll care the most during acquisition. I found that going down in gain caused glitches at every step! For increasing the gain, steps from an odd number of dBs to an even number consistently caused glitches. Steps from an even number to an odd number occasionally caused glitches, but they weren't very common. For the steps that did cause glitches, some were worse than others (7dB to 8dB, 15 dB to 16 dB, and 23 dB to 24 dB seemed the worst.)
After my work, I put all of the cables back, so that we should be ready to utilize the CM board for locking this evening.
For posterity, here are the notes that I took while I was working - I'll make them more coherent when I fold them in with my images tomorrow. The "first .png, next, etc." are because the 'scope numbers them in order as a default.
1st png = boost enable, then disable
2nd png = super boost, start at 0, then 1, then 2, then 3
3rd png = AO gain from 1 to 0
4th is AO gain from 0 to 1 (happens less often than 1->0, which is every time I get a glitch)
Next is AO gain 1->2, got 2 glitches!
3->2 glitch often, 2->3 much less often
next is 2->3
next png is 3->4, 2 glitches with weird dip
next png is 5->6
6->7 is rare
next png is 7->8, which is nasty!!
8->9 is rare
10->11 is rare
png 11-> 12, 3 glitches
png 13->14, 2 glitches
png 15->16, kind of nasty
png 17->18, 2 glitches
png 19->20, 3 glitches
png 21->22, 2 glitches
png 23->24, kind of nasty
png 25->26, 2 glitches
png 27->28, 3 glitches, at least
png 29->30, 2 glitches
Somehow, the images got put into a whole new entry, even though I thought I was editing this one. Anyhow, please see elog 9938.
Note: I thought I was editing elog 9935, but somehow this became a whole new entry. Either way, all the info is in here.
The screenshot of the Boost enable / disable I'll have to re-take. Apparently I instead caught a screenshot of the list of files on the floppy...ooops.
This is a shot of enabling the Super Boosts. At the beginning, it's at "0", so no superboosts (also, regular boost was off). Then, I switch to "1", and the trace gets a little fuzzy. Then I switch to "2", and it gets very fuzzy. Then I switch to "3", and a lot of the fuzz goes away. There's a glitch at each transition.
The following screenshots are all of various steps of the AO gain slider. For all of these, both the "boost" and "super boosts" were off. Each screenshot is a single gain step, even if there are several glitches captured.
First, 0dB to 1dB:
Next, 1dB to 2dB:
2dB to 3dB:
3dB to 4dB:
While increasing the gain, I didn't find any more steps from an even to an odd number where I got a glitch. They would glitch when I undid that step (decreased the gain), but over ~5 trials for each increase, I didn't ever catch a glitch. The odd to even steps still had glitches while increasing the gain though.
5dB to 6dB:
7dB to 8dB:
9dB to 10dB:
11dB to 12dB:
13dB to 14dB:
15dB to 16dB:
17dB to 18dB:
19dB to 20dB:
21dB to 22dB:
23dB to 24dB:
25dB to 26dB:
27dB to 28dB:
29dB to 30dB: