I set up a photodiode (PDA10CF) in the IFO REFL beampath and the Agilent NA is sitting on the east side of the PSL enclosure. This was meant to be just a first look, maybe the PDA10CF isn't suitable for this measurement. The measurement condition was - PRM aligned so we have a REFL beam (DC level = 8.4V measured with High-Z). Both ITMs and ETMs were macroscopically misaligned so that there isn't any cavity effects to consider. I collected noise around 11 and 55 MHz, and also a dark measurement, plots to follow. The optics were re-aligned to the nominal config but I left the NA on the east side of the PSL enclosure for now, in anticipation of us maybe wanting to tune something while minimizing a peak.
Attachment #1: Results of a coarse sweep from 5 MHz to 100 MHz. The broadband RIN level is not resolvable above the dark noise of the photodiode, but the peaks at the modulation frequencies (11 MHz, 55 MHz and 29.5 MHz) are clearly visible. Not sure what is the peak at ~44 MHz or 66 MHz. Come to think of it, why is the 29.5 MHz peak so prominent? The IMC cavity pole is ~4kHz so shouldn't the 29.5 MHz be attenuated by 80dB in transmission through the cavity?
Attachment #2: Zoomed in spectra with finer IF bandwidth around the RF modualtion frequencies. From this first measurement, it seems like the RIN/rad level is ~10^5, which I vaguely remember from discussions being the level which is best achieved in practise in the 40m in the past.
Check the RAM due to the EOM? Perhaps the pointing / polarization control into the EOM got degraded.
Tried a bunch of things tonight.
One possibility is that the arm buildup is exerting some torque on the ITMs, which can also change the PRC cavity axis - as the buildup increases, the dominant component of the circulating field in the PRC comes from the leakage from the overcoupled arm cavity. We used to DC couple the ITM Oplev servos when locking the PRMI. The TRX level of 1 corresponds to ~5W of circulating power in the arm cavity, and the static radiation pressure force due to this circulating power is ~30 nN, rising up to 300nN as the TRX level hits 10. So for 1mm offset of the spot position on the ITM, we'd still only exert 300 pN m of torque. I don't see any transient in the Oplev error signals when locking the arm cavity as usual with POX/POY, but on timescales of several seconds, the Oplev error point shows ~3-5 urad of variation.
I changed the shape of the low pass filter to reduce high frequency sensor noise injection into the MICH control signal. The loop stability isn't adversely affected (lost ~5 degrees of phase margin but still have ~50 degrees), while the control signal RMS is reduced by ~x10. This test was done with the PRMI locked on the carrier, need to confirm that this works with the arms controlled on ALS and PRMI lcoked on sideband.
The POP beam coming out of the vacuum chamber is split by a 50/50 BS and half is diverted to the POP22/POP110/POPDC photodiode (Thorlabs PDA10CF) and the other half goes to the POP QPD. This optical layout is still pretty accurate. I looked at the data of the POPDC and POP QPD SUM channels while the dither alignment was running, to see if I could figure out what's up with the weird correlated dip in REFLDC and POPDC. While the POPDC channel shows some degradation as the REFLDC level goes down (=alignment gets better), the QPD sum channel shows the expected light level increase. So it could yet be some weird clipping somewhere in the beampath - perhaps at the 50/50 BS? I will lock the PRMI (no arms) and check...
There are many versions of the POP22 signal path I found on the elog, e.g. this thread. But what I saw at the LSC rack was not quite in agreement with any of those. So here is the latest greatest version.
Since the 2f signals are mainly indicators of power buildups and are used for triggering various PDH loops, I don't know how critical some of these things are, but here are some remarks:
I did some re-alignment of the POP beam on the IX in air table. Here are the details:
Tangentially related to this work - I took the nuclear option and did a hard reboot of the c1susaux Acromag crate on Sunday to fix the EPICS issue - it seems to be gone for now, see Attachment #5.
I am still unable to achieve arm powers greater than TRX/TRY ~10 while keeping the PRMI locked. A couple of times, I was able to get TRY ~50, but TRX stayed at ~10, or even dropped a little, suggestive of a DARM offset? On the positive side, the ALS system seems to work pretty reliably, and I can keep the arms controlled by ALS for several tens of minutes.
There seems to be stronger-than-expected coupling between CARM and the 3f sensors.
Full analysis tomorrow, but I collected sensing matrix measurements with lines driven in PRCL,MICH and CARM at a couple of CARM offsets. I also wanted to calibrate the CARM offset to physical units so I ran some scans of the CARM offset and collected the data so I can use the arm cavity FSR to calibrate CARM. Koji suggested using REFL165_I for PRCL and REFL165_Q for MICH control - this would allow us to see if the problem was with the 1f sideband only. While the lock could be established, we still couldn't push the arm powers above 10 without breaking the PRMI lock. While changing the CARM offset, we saw a significant shift in the DC offset level of the out-of-loop REFL33_I signal. Need to think about what this means...
A coarse calibration of the CARM error point (when on ALS control) is 7.040 +/- 0.030 kHz/ct. This corresponds to approximately 0.95nm/ct. I typically lose the PRMI lock when the CARM offset is ~0.2 cts, which means I am about 1kHz away from the resonance. This is >10 CARM linewidths.
The calibration was done by sweeping the CARM offset (no PRM) and identifying the arm cavity FSRs by looking for peaks in TRX / TRY. Attachment #1 shows the scan, while Attachment #2 shows a linear fit to the FSRs. In Attachment #2, the frequency axis is taken from the phase tracker servo, which was calibrated by injecting a "known" frequency with the Marconi, and there is good agreement to the expected FSR with 37.79 m long arm cavities. There is much more info in the scan (e.g. modulation depths, mode matching to the arm cavities etc) which I will extract later, but if anyone wants the data (pre-downsampled by me to have a managable filesize), it's attached as a .zip file in Attachment #3.
Here is a comparison of the response of various DoFs in our various RFPD sensors for two different CARM offsets. Even in the case of the smaller CARM offset of ~1kHz, we are several linewidths away from the resonance. Need to do some finesse modeling to make any meaningful statement about this - why is the CARM response in REFL11 apparently smaller for the smaller CARM offset?
If you mistrust my signal processing, the GPS times for which I ran the sensing lines are:
CARM offset = ~30kHz (arm transmission <0.02) --- 1257064777+5min
CARM offset = ~1kHz (arm transmission ~5) --- 1257065566+5min
We turned off many excessive violin mode bandstop filters in the LSC.
Due to some feedforward work by Jenne or EQ some years ago, we have had ~10 violin notches on in the LSC between the output matrix and the outputs to the SUS.
They were eating phase, computation time, and making ~3 dB gain peaking in places where we can't afford it. I have turned them off and Gautam SDF safed it.
Offensive BS shown in brown and cooler BS shown in blue.
To rotate the DTT landscape plot to not be sideways, use this command (note that the string is 1east, not least):
pdftk in.pdf cat 1east output out.pdf
The clue was that the loop X arm POX loop looked to have low (<3dB)) gain margin around 600 Hz (and again at 700 Hz). Attachment #1 shows a comparison of the OLTF for this loop (measured using the IN1/IN2 method) before and after our change. We hypothesize that one of the violin filters that were turned off had non-unity DC gain, because I had to lower the loop gain by 20% after these turn-offs to have the same UGF. I updated the snap files called by the arm locking scripts.
I think I caught all the places where the FM settings are saved, but some locking scripts may still try and turn on some of these filters, so let's keep an eye on it.
The DC port of the Bias-Tee is routed to (a modified version of) the iLIGO whitening board. This has the well-known problem of the protection diodes of the LT1125 quad-op-amp lowering the (ideally infinite) input impedance of the first gain stage (+24 dB). To be sure as to how much signal we can put into this port (in anticipation of trying some variable finesse PRFPMI locking but also for general book-keeping), I tested the usable input range by driving a triangle wave at ~3 Hz and changing the amplitude of the signal until we observed saturation. We found that we could drive a 10 Vpp signal at which point there was evidence of some clipping (it was asymmetric, the top end of the signal was getting clipped at +14,000 cts while the bottom end still looked like a triangle wave at -16,000 counts). Anyway we probably don't want to exceed +/- 10,000 counts on this channel. This is consistent with Hartmut's statement of having +/- 4V of usable range (although the counts he mentions are twice what I saw yesterday).
Other discussion points between Rana, Koji and Gautam:
Some ideas Koji suggested:
For the second idea, it is convenient to be able to control the arms in the XARM/YARM basis as opposed to the CARM/DARM basis as we usually do when going through the locking sequence. After some fiddling, I am able to reliably execute this transition, and achieve a state where the FP arm cavities are resonant for the IR with the ALS beat note frequency being the error signal being used. Some important differences:
I took a look at the TRX/TRY RIN reported in the single arm POX/POY lock, and compared the performance of the two available PDs at each of the two ends. Attachment #1 shows the results. Some remarks:
In search of the source of discrepancy between the QPD readings in the X and Y arms, we look into the schematics of the QPD amplifier - DCC #D990272.
We find that there are 4 gain switches with the following gain characteristics (The 40m QPD whitening board has an additional gain of 4.5):
Switch 4 bypasses the amps controlled by switch 2 and 3 when it is set to 1 so they don't matter in this state.
Note that according to elog-13965 the switches are controlled through the QPD whitening board by a XT1111a Acromag whose normal state is 1.
Also, according to the QPD amplifier schematics, the resistor on the transimpedance, controlled by switch 1, is 25kOhm. However, according to the EPICS it is actually 5kOhm. We verify this by shining the QPD with uniform light from a flashlight and switching switch1 on and off while measuring the voltages of the different segments. The schematics should be updated on the DCC.
Surprisingly, QPDX switches where 0,0,0,0 while QPDY switches where 1,0,0,1. This explains the difference in their responses.
We check by shining a laser pointer with a known power on the different segments of QPDX that we get the expected number of counts on the ADC and that the response of the different segments is equal.
Koji and I had noticed that there was some discrepancy between the switchable gain stages of the EX and EY QPDs. Sadly, there was no indication that these switches even exist on the QPD MEDM screen. Yehonathan and I rectified this today. Both EX and EY Transmon QPDs now have some extra info (see Attachment #1). We physically verified the indicated quadrant mapping for the EX QPD (see previous elog in this thread for the details), and I edited the screen accordingly. EY QPD still has to be checked. Note also that there is an ND=0.4 + ND=0.2 filter and some kind of 1064nm light filter installed in series on the EX QPD. The ND filters have a net transmission T~25%.
After making the EX and EY QPDs have the same switchable gain settings (I also reset the trans normalization gains), the angular motion witnessed is much more consistent between the two now - see Attachment #2. The high-frequency noise of the sum channel is somewhat higher for EX than EY - maybe the ND filters are different on the two ends?
Note that there was an extra factor of 40 gain on the EX QPD relative to EY during the lock yesterday. So really, the signals were probably just getting saturated. Now that the gains are consistent between the ends, it'll be interesting to see how balanced the buildup of the two arms is. There still remains the problem that the MICH loop was too unstable, which probably led to to excess arm power fluctuations.
There is a mark on the QPD surface that is probably dirt (since we never have such high power transmitted through the ETM to damage the QPD). I'll try cleaning it up at the next opportunity.
After the QPD fix, both arms report consistent buildup - see Attachment #1. The peak values touch ~250, corresponding to a PRG of ~13. The IFO becomes critically coupled at PRG=15. I am finding that the 3f signal offsets are changing as a function of the CARM offset, and this could be responsible for the lock breaking as I approach 0 CARM offset. I found that I could maintain a more stable and deterministic transition to zero CARM offset by dynamically adjusting the 3f PRCL error signal offset to keep the REFL11 signal approximately at 0. Some shaking seems to have commenced so I am breaking for now.
Note that I find scattered throughout the elog references to a similar problem of the PRMI losing lock as the CARM offset is reduced, e.g. here. But haven't stumbled across what the resolution was, the PRFPMI could be locked pretty easily in 2015 I remember.
In preparation for trying out some high-bandwidth Y arm cavity locking using the CM board, I hooked up the POY11_Q_Mon channel of the POY11 demod board to the IN1 of the CM board (and disconnected the usual REFL11 cable that goes to IN1). The digital phase rotation for usual POY Yarm locking is 106 degrees, so the analog POY11_Q channel contains most of the signal. I then set the IN1 gain of the servo to 0dB, and looked at the CM_Slow signal - I changed the whitening gain of this channel to +18dB (to match that used for POY11_I and POY11_Q), and found that I had to apply a digital gain of 0.5 to get the PDH horns in the usual POY11_I signal and the CM_Slow signal to line up. There was also a sign inversion. Then I was able to use the digital LSC system and lock the Y arm cavity length to the PSL frequency by actuating on ETMY, using CM_Slow as an error signal. A comparison of the in-loop POY11_I ASD when the arm is locked is shown in Attachment #1 - CMslow seems to be dominated by some kind of electroncis noise above ~100 Hz, so possibly needs more whitening (even though the nominal whitening filter is engaged)?
Anyway, now that I have this part of the servo working, the next step is to try and engage the AO path and achieve a higher BW lock of the Y arm cavity to the PSL frequency (= IMC length). Maybe it makes more sense to actuate on MC2 for the slow path.
One of the differences between the direct POY and the CM_SLOW POY is the presence of the CM Servo gain stages. So this might mean that you need to move some of the whitening gain to the CM IN1 gain.
The Y arm cavity length was locked to the PSL frequency with ~26kHz UGF, and 25 degrees phase margin. Slow actuation was done on ETMY using CM_Slow as an error signal, while fast actuation was done on the IMC error point via the IN2 input of the IMC servo board. Attachment #1 shows the comparison of the in-loop error signal spectra with only slow actuation and with the full CM loop engaged.
I hypothesize that the high-frequency noise (>100 Hz) is higher for POY than POX in Attachment #1 because I am using the "MON" port of the demod board - this has a gain of 2, and there could also be some flaky components in this path, hence the high frequency noise is a factor of a few greater in the POY spectrum relative to the POX spectrum (which is using the main demodulated output). For REFL11, we have a low noise preamp generating the input signal so I don't think we need to worry about this too much.
The PC Drive RMS didn't look any stranger than it usually does for the duration of the lock.
Attachment #2 shows the OLTF of the locking servo with the final gains / settings, which are in bold. The loop is maybe a bit marginal, could possibly benefit from backing off one of the super boosts. But the arm has stayed locked for >1 hour.
The purpose of this test was to verify the functionality of the CM board and also the IN2 of the IMC servo board in a low-pressure environment. Once I confirm that the modelled OLTF lines up with the measured, I will call this test a success, and move on to looking at REFL11 in the arms on ALS, PRMI on 3f config. I am returning the REFL11 signal to the input of the CM board, but the SR785 remains hooked up.
Unrelated to this work - PMC alignment was tweaked to improve input power to IMC by ~5%.
There was no shaking (that disturbed the locking) tonight!
The problem is hard to debug because we are feeding back on the ETMs, BS and PRM, and at the low CARM offset (= high PRG), all the DoFs are cross coupled strongly so just by looking at error/control signals, I can't directly determine where the noise is originating. The fact that the ALS CARM spectrum shows a noise increase suggests that the problem has to do with the test masses, PSL, IMC, or end green PDH setups.
My plan is to do a systematic campaign and eliminate some of these possibilities - e.g. install some baffling around the fiber coupler and the end green PDH photodiodes and see if there is any improvement in the situation.
* In attachment #1, the "Ref" traces are when the CARM offset is 0, and the arms are buzzing in and out of resonance. The non-reference traces are for when the CARM offset is ~28kHz (so several linewidths away from resonance).
I re-checked the ALS noise in the following configurations:
The RMS noise sensed by POX/POY is ~20pm, which is somewhat higher than the best I've seen (maybe the arms are moving more at the time of measurement or the AUX PDH loops need a bit of touching up). But the orange traces in the top row of Attachment #1 are already ~x2 better than the equivalent traces from when we were using the green beams to make the beats. So it's hard to explain the 0-300 fluctuations in the arm powers when the CARM offset is reduced to 0 - i.e. the ALS noise is becoming worse as I reduce the CARM offset (= have more circulating power compared to the conditions of this test). I assume the transmission is Lorentzian, in which case even if we have 5x the CARM linewidth worth of ALS noise, we should see the arm power fluctuate between ~10 and 300.
* I notice that a big jump in the RMS sensed by POX/POY comes from the 24 Hz peak, which is presumably the Roll mode coupling to length - maybe a ResG can make the situation better. The high frequency noise can also be probably rolled off better.
Since we are using the POX and POY photodiodes as out-of-loop sensors for measuring the ALS noise, I decided to double-check their calibrations. I determined the following numbers (for the single arm lock):
POX_I [with 30dB whitening gain]: (8 +/- 1)e-13 m/ct
POY_I [with 18dB whitening gain]: (0.9 +/- 0.1)e-13 m/ct
With this calibration, I measured the in-loop spectra of the XARM and YARM error-points when they are locked - they line up well, see Attachment #1. Note that these numbers are close to what we determined some time ago using the same method (I drove the ITMs then, but yesterday I drove the ETMs, so maybe the more accurate measure of uncertainty is the difference between the two measurements).
Attachment #2 shows the out-of-loop spectra sensed by these photodiodes with this calibration applied, when the arms are under control using ALS beat frequencies as the error signals, and controlled in the CARM/DARM basis. Need to think about why there is such a difference between the two signals.
The procedure used was the same as that outlined here.
Summary of DC actuator gains:
The quoted values of the DC gain are for counts seen at the output of the LSC filter bank. I've attempted to show that once we account for the different series resistance and some extra gains between the output of the LSC filter bank and the actual coil, things are fairly consistent.
...maybe the opto-mechanical CARM plant is changing as a function of the CARM offset...
Even assuming 50% error in the calibration factors, it's hard to explain the swing of TRX/TRY when the CARM offset is brought to zero.
The ITMX OSEMs report elevated noise in the 10-100 Hz band when we have high circulating power in the arm cavities, see Attachment #1. Since there is no LSC actuation on the ITMs in this state, this could be a radiation presssure effect, or could be scattered 1064nm light entering the OSEMs. The Oplevs don't report any elevated noise however. ITMY has the OSEM whitening broken for two channels, but the other two channels don't report as significant an increase as ITMX, see Attachment #2. I can't find the status of which OSEMs have the 1064nm blocking filters installed. The local damping loops are rolled off by ~100dB at 30 Hz, so the sensing noise re-injection should be attenuated by this factor, so maybe the OSEM sensor noise isn't the likely culprit. But radiation pressure didn't worsen the length noise in the past, even after our mirror cleaning and the increased PRG.
if the RP don't fit
u must acquit
sweep the laser amplitude
to divine the couplin w certitude
i reconnected the AOM driver to the AOM in the main beam path (it was hijacked for the AOM in the AUX laser path for Anjali's MZ experiment). I also temporarily hooked up the AOM to a CDS channel to facilitate some swept-sine measurements. This was later disconnected. The swept sine will need some hardware to convert the bipolar drive signal from the CDS system to the unipolar input that the AOM driver wants (DTT swept sine wont let me set an offset for the excitation, although awggui can do this).
I tried the following minor changes to the locking procedure to see if there were any differences in the ALS noise performance:
None of these changes had any effect - the ALS noise still goes up with arm buildup.
I think a good way to determine if the problem is to do with the IR part of the new ALS system is to resurrect the green beat setup - I expect this to be less invasive than installing attenuators/beam dumps in front of the fiber couplers at the ends. We should at the very least recover the old ALS noise levels and we were able to lock the PRFPMI with that config. If the excess noise persists, we can rule out the problem being IR scatter into the beat-mouth fibers. Does this sound like a reasonable plan?
was worth a shot i guess.
Trawling through some elogs, I see that this kind of feature showing up in the ALS CARM is not a new problem, see for example here. But I can't find out what the resolution was.
Trawling through some past elogs, I saw that the ALS noise increase as a function of CARM offset reduction is not really a new thing (see e.g. this elog). In the past, when we were able to lock, when the CARM offset is reduced to zero, the arms would "buzz" through resonance. It just wasn't clear to me how much the buzzing was - in all the plots we presented, we were not looking at the fast 16k output, so it looked like the arm powers had stabilized. But today, looking at the frame data at 16k from back in 2016, it is clear to me that the arm transmission was in fact swinging all the way from 0 to some maximum. Once the IR signal (=REFL11) blending is turned on, we were able to stabilize the arm power somewhat. What this means is that we are in a comparable state as to when we were able to lock in the past (since I'm able to sit at 0 CARM offset with the PRMI locked almost indefinitely).
So, I think what I'll try for the next 3 days is to get this blending going, I think I couldn't enable the CM_slow path because when I was experimenting with the high bandwidth Y arm cavity locking, I had increased the whitening gain of this channel, but REFL11 has much more optical gain (=larger signal) than POY11, and so I'll start from 0dB whitening gain and see if I can turn the magic integrator on. Long term, we should try and compensate the optomechanical plant that changes as our CARM offset gets reduced, as this would further reduce the lock acquisition time and simplify the procedure (no need to fiddle with the integrator, offsets etc). A relevant thread from the past.
I made it to 0 CARM offset, PRMI locked a bunch of times today. However, I could not successfully engage the AO path.
Much of the procedure is scripted, here is the rough set of steps:
As I type this out, I realized that I was incorrectly setting offsets to maximize the arm powers by adjusting CARM/DARM offsets as opposed to CARM_A / DARM_A offsets. Tried another round of locking, but this time, I can't even turn the integrator on to get the arms to click into somewhat stable powers.
One thing I noticed is that depending on the offsets I put into the 3f locking loops, the mean value of REFL11 and AS55 when the ALS CARM/DARM offsets are zeroed changes quite significantly. What is the correct condition to set these offsets? They are different when locking the PRC without arm cavities, and also seem to change continuously with CARM offset. I am wondering if I have too much offset in one of the vertex locking loops?
We did the following:
The goal tonight was to go through the locking scripts to see if I could recover the state from November 2019, when I could have the arm lengths controlled by ALS, and sit at zero CARM offset with the PRMI remaining locked and the arm powers fluctuating between 0-300. The IR-->ALS transitions went smoothly tonight, and the PRMI locking was also fairly robust when the CARM offset was large, but was less good when reduced to 0. Nevertheless, it is good to know that the system can be restored to the state it was late last year. Next step is to figure out how to keep the PRMI locked and get the AO path engaged, this was what I was struggling with before the new year.
The CARM-->RF transition remains out of reach. No systematic diagnosis scheme comes to mind.
TBC. Mercifully at least the shaker stayed still tonight.
The goal is to try and identify the source of the excess ALS noise as the CARM offset is reduced. The idea is to look at the MC_F spectrum (or the IMC error point) in a few conditions:
#1 vs #2 is like a control experiment, we expect to see the excess noise imprinted on the MC length and hence in MC_F (provided the sensing noise is low enough). #2 vs #3 will be informative of something like backscatter to the PSL increasing the frequency noise. #2/3 vs #4 will help isolate the problem to an individual arm's AUX PDH loop or some optomechanical effect.
I was looking back at some spectra from the last couple of nights but I don't really have an apple-to-apple comparison in the various actuation schemes (some ALS loops were engaged/disengaged), so I'll do a more systematic test tonight. Already, it looks like MC_F is not a good candidate to look for the excess frequency noise, I don't really see a big difference between conditions #1 and #2. According to this, we are looking for an increase at the level of a few 100Hz/rtHz @ ~40 Hz, wheras MC_F is much noisier.
I did some more detailed tests to see if I could isolate where the excess ALS noise at low CARM offset is coming from, by measuring the spectrum of the IMC error point (in loop). The results, shown in Attachment #1 and #2, are inconclusive.
Since MC_F didn't show any signatures of elevated noise, I decided to hook up an SR785 to the A excitation bank TEST1 input of the IMC servo board to monitor the in-loop error signal. I initially took a few measurements spanning 800 Hz in frequency, and to my surprise, I found that there was elevated noise in the frequency band we see an increase in the ALS noise, even when the CARM feedback goes to the ETMs (so the IMC cavity is in principle isolated from the main interferometer). This is Attachment #1. So I re-took a couple of measurements (this time only for the case of CARM feedback to the ETMs), with a 200 Hz frequency span, and found no significant noise elevation. This is Attachment #2. I am led to conclude that the IMC error point level changes over time for reasons other than the CARM offset - it'd be nice to have a spectrogram of the IMC error point and compare excursions relative to the median level over a few 10s of minutes, but we don't have this data stream digitized by the CDS system - maybe I will hijack the MC_L channel temporarily to record this data stream. It seems a waste that we're not able to take full advantage of the measured <10pm RMS noise of the IR ALS system.
I managed to partially stabilize the arm citculating powers - they stay in a region in which the REFL 11 signal is hopefully approximately linear and so I can now measure some loop TFs and tweak the transition appropriately.
The main change I made tonight was to look at the REFL11 signal as I swept the ALS CARM offset through 0. I found that the maximum arm powers coincided with a non-zero REFL11 signal value (i.e. a small CARM offset was required at the input to the CARM_B filter bank). Not so long ago, I had measured the PM/AM ratio for 11 MHz to be ~10^5 - so it's not entirely clear to me where this offset is coming from. Then, I was able to turn on the integrator (z:p = 20:0) in the CARM_B filter bank while maintaining high POP_DC. At this point, I ramped up the IN2 gain on the IMC servo board (= AO path), and was able to further stabilize the power.
Attachment #1 shows this sequence from earlier in the evening. Note that in this state, both ALS and IR control of CARM is in effect. The circulating power is fluctuating wildly - partly this is probably the noisy ALS control path, but there is also the issue of the (lack of) angular control - although looking at the transmon QPDs and the POP QPD signals, they seem pretty stable.
The next step will be to try and turn off the ALS control path. Eventually, I hope to transition DARM control to AS55 as well. But at this point, I can at least begin to make sense of some of the time series signals, and get some insight into how to improve the lock.
No systematic diagnosis scheme comes to mind.
Plots + interpretation tomorrow.
Getting closer... To facilitate this work, I made some convenience scripts that can be run from the CM MEDM screen.
To study the evilution of the AO path TFs a bit more, I've hooked up POY11_Q Mon to IN1 of the CM board. I will revert the usual setup later in the evening.
Update 1730: I've returned the cabling at 1Y2 to the nominal config, and also reverted all EPICS settings that I modified for this test. Y-arm POY locking works. Attachment #1 shows the summary of the results of this test - note that the AO gain was kept fixed at +5dB throughout the test. I have arbitrarily trimmed the length of the frequency vector for some of these traces so that the noisy measurement doesn't impede visual interpretation of the plots so much. At first glance, the performance is as advertised. I basically followed the settings I had here to get started, and then ramped up various gains to check if the measured OLTF evolved in the way that I expected it to. The phase lead due to the AO path is clearly visible.
Some important differences between this test and the REFL11 blending is (i) in the latter case, there will also be a parallel loop, CARM_A, which is effecting some control, and (ii) the optical gain of CARM-->REFL11_I is much higher than L_Y-->POY. So the initial gain settings will have to be different. But I hope to get some insight into what the correct settings should be from this test. I think IMC servo IN2 gain and AO gain slider on the CM board are degenerate in the effect they have, modulo subtle effects like saturation.
One possibility is that the gain allocation I used yesterday was wrong for the dynamic range of the CARM error signal. In some initial trials today, when I set the CM board IN1 gain to -32dB (as in the case of attempting the CARM RF handoff) and compensated for the reduced POY PDH fringe amplitude by increasing the digital gain for the CM_Slow path, I found that there was no phase advance visible even when I ramped up the IMC IN2 gain to +10dB. So, for the CARM handoff too, I might have to start with a higher CM board IN_1 gain, compensate by reducing the CM_Slow digital gain even more, and then try upping the IMC IN2 gain.
P.S. When the excitation input to the CM board was enabled in order to make TF measurements, I saw significant increase in the RMS of the error signal. Probably some kind of ground loop issue.
This measurement tells you how the gain balance between the SLOW_CM and AO paths should be. Basically, what you need is to adjust the overall gain before the branch of the paths.
Except for the presence of the additional pole-zero in the optical gain because of the power recycling.
You have compensated this with a filter (z=120Hz, p=5kHz) for the CM path. However, AO path still don't know about it. Does this change the behavior of the cross over?
If the servo is not unconditionally stable when the AO gain is set low, can we just turn on the AO path at the nominal gain? This causes some glitch but if the servo is stable, you have a chance to recover the CARM control before everything explodes, maybe?
Over the last couple of days, I've been trying to see if I can measure the phase advance due to the AO path - however, I've been unable to do so for any combination of CM board IN1 gain and MC Servo board IN2 gain I've tried. Yesterday, I tried to understand the loop shapes I was measuring a little more, and already, I think I can't explain some features.
Attachment #1 shows the TF measured (using SR785, and the EXC_A bank of the CM board) when the CM Slow path has been engaged.
Attachment #2 shows error signal spectra for the in-loop PRFPMI DoFs, for a few different conditions.
I believe that a stable crossover is hopeless under these conditions.
I measured the transfer function of the AO path, and think that there are some features indicative of a problem somewhere in the IMC locking loop.
Regardless of the locking scheme used, high bandwidth control of the laser frequency relies on the fact that the laser frequency is slaved to the IMC cavity length with nearly zero error below ~50 kHz (assuming the IMC loop has a UGF > 100 kHz). In my single arm experiments, I didn't know what to make of the ripples that became apparent in the measured OLTF as the AO gain was ramped up.
Tonight, I measured the TF of the "AO path", which modifies the error point of the IMC, thereby changing the laser frequency.
Attachment #1 shows the result of the measurement.
I didn't use POX / POY as a sensor to confirm that this is real frequency noise, I will do so tomorrow. But it may be that realizing a stable crossover is difficult with so many features in the AO path.
Previous thread with a somewhat detailed characterization of the IMC loop electronics.
While my checks of the AO signal path have thrown up some unanswered questions, I don't think there's any evidence in those measurements to suggest the AO crossover can't be realized. Thinking about it today though - I was wondering if it could be that the IN1 gain slider of the CM board is configured optimally. Looking back at some data, when the ALS CARM offset is zeroed, the CM_SLOW digitized data has a peak-to-peak range of ~200 cts. This is paltry. One possibility is that as I am upping the AO path gain, I'm simply injecting the electronics noise of the CM board into the IMC error point. I'd say it is safe to up the IN2 gain by 20dB to -12 dB, in which case the peak-to-peak would be ~2000 cts, still only 10% of the ADC range. It'll be straightforward to re-scale the CARM_B loop gain to account for this. Let's see if this helps.
I'd also like to measure the spectrum of the REFL11_I signal in a few different states. I think I should be able to do this using the OUT2 of the CM servo board. These are the things to try tonight:
It's been a while since I've attempted any locking, so tonight was mostly getting the various subsystems back together.
Finally, some RF only CARM, see Attachment #1. During this time, DARM was also on a blend of IR and ALS control, but I couldn't turn the ALS path off in ~4-5 attempts tonight (mostly me pressing a wrong button). Attachment #2 shows the CARM OLTF, with ~2kHz UGF - for now, I didn't bother turning any boosts on. PRCL and MICH are still on 3f signals.
The recycling gain is ~7-8 (so losses >200ppm), but there may be some offset in some loop. I'll look at REFL DC tomorrow.
Can we please make an effort to keep the IFO in this state for the next week or two
- it really helped tonight I didn't have to spend 2 hours fixing some random stuff and could focus on the task at hand.