[ Yuki, Gautam, Steve ]
To align the green beam in Y-end these hardware were installed:
I made sure that DAC CH9~16 and cable to AI-board worked correctly.
When we applied +100V to PZT driver and connected DAC, AI-board and PZT drive, the output voltage of the driver was not correct. I'll check it tomorrow.
I connected DAC - AIboard - PZTdriver - PZT mirrors and made sure the PZT mirrors were moving when changing the signal from DAC. Tomorrow I will prepare alignment servo with green beam for Y-arm.
I had some success today. I hope that the tweaks I made will allow working with the DRMI during the day as well, though it looks like the main limiting factor in lock duty cycle is angular stability of the PRC.
[Attachment #1]: Repeatable and reliable DRMI locks tonight, stability is mainly limited by angular glitches - I'm not sure yet if these are due to a suspect Oplev servo on the PRM, or if they're because of the tip-tilt PR2/PR3/SR2/SR3.
[Attachment #2]: A pass at measuring the TF from SRCL error point to MICH error point via control noise re-injection. I was trying to measure down to 40 Hz, but lost the lock, and am calling it for the night.
[Attachment #3]: Coherence between PRM oplev error point and beam spot motion on POP QPD.
Note that the MICH actuation is not necessarily optimally de-coupled by actuating on the PRM and SRM yet (i.e. the latter two elements of the LSC output matrix are not precisely tuned yet).
What is the correct way to make feedforward filters for this application? Swept-sine transfer function measurement? Or drive broadband noise at the SRCL error point and then do time-domain Wiener filter construction using SRCL error as the witness and MICH error as the target? Or some other technique? Does this even count as "feedforward" since the sensor is not truly "outside" the loop?
With the DRMI locked, I drove a line in MICH using the sensing matrix infrastructure. Then I looked at the error points of MICH, PRCL and SRCL. Initially, the sensing line oscillator output matrix for MICH was set to drive only the BS. Subsequently, I changed the --> PRM and --> SRM matrix elements until the line height in the PRCL and SRCL error signals was minimized (i.e. the change to PRCL and SRCL due to the BS moving, which is a geometric effect, is cancelled by applying the opposite actuation to the PRM/SRM respectively. Then I transferred these to the LSC output matrix (old numbers in brackets).
MICH--> PRM = -0.335 (-0.2655)
MICH--> SRM = -0.35 (+0.25)
I then measured the loop TFs - all 3 loops had UGFs around 100 Hz, coinciding with the peaks of the phase bubbles. I also ran some sensing lines and did a sensing matrix measurement, Attachment #1 - looks similar to what I have obtained in the past, although the relative angles between the DoFs makes no sense to me. I guess the AS55 demod phase can be tuned up a bit.
The demodulation was done offline - I mixed the time series of the actuator and sensor signals with a "local oscillator" cosine wave - but instead of using the entire 5 minute time series and low-passing the mixer output, I divvied up the data into 5 second chunks, windowed with a Tukey window, and have plotted the mean value of the resulting mixer output.
Unrelated to this work: I re-aligned the PMC on the PSL table, mostly in Pitch.
I've been looking into the cross-coupling from the SRCL loop control point to the Michelson error point.
[Attachment #1] - Swept sine measurement of transfer function from SRCL_OUT_DQ to MICH_IN1_DQ. Details below.
[Attachment #2] - Attempt to measure time variation of coupling from SRCL control point to MICH error point. Details below.
[Attachment #3] - Histogram of the data in Attachment #2.
[Attachment #4] - Spectrogram of the duration in which data in #2 and #3 were collected, to investigate the occurrance of fast glitches.
Hypothesis: (so that people can correct me where I'm wrong - 40m tests are on DRMI so "MICH" in this discussion would be "DARM" when considering the sites)
Measurement details and next steps:
Attachments #2 and #3
Prep for this work:
I was trying to get some pics of the optics as a zeroth-level reference for the pre-vent loss with the single arms locked, but since our SL7 upgrade, the sensoray won't work anymore . I'll try fixing this during the daytime.
Attachment #1 is a block diagram depicting the pathway by which the vertex DOF control signals can couple into DARM (adapted from a similar diagram in Gabriele's Virgo note on the subject). I've also indicated some points where noise can couple into either loop. In general, there are sensing noises that couple in at the error point of the loop, and actuation noises that couple in at the control point. In this linear picture, each block represents a (possibly time varying) transfer function. So we can write out the node-to-node transfer functions and evaluate the various couplings.
The motivation is to see if we can first simulate with some realistic noise and time-varying couplings (and then possibly test on the realtime system) the effectiveness of the filter denoted by "FF" in canceling out the shot noise from the auxiliary loop being re-injected into the DARM loop via the DARM sensor. Does this look correct?
I wanted to set up an RTCDS model to understand this problem better. Attachment #1 is the simulink diagram of the signal flow. The idea will be to put in the appropriate filter shapes into the various filter blocks denoting the DARM and auxiliary DoF plants, controllers and actuators, and then use awggui / diaggui to inject some noises and see if in this idealized model I can achieve good subtraction. Then we can build up to applying a time varying cross coupling between DARM and the vertex DoF, and see how good the adaptive FF works. Still need to setup some MEDM screens to make working with the test system easier.
I figured c1omc would be the least invasive model to set this upon without risking losing any of our IR/green alignment references. Compile and install went smooth, see Attachment #2. The c1omc model was clocking 4us before, now it's using 7us.
Attachment #3 shows the top level of the OMC model, while Attachment #4 shows the MEDM screen.
* Note to self: when closing a loop inside the realtime model, there has to be a delay block somewhere in the loop, else a compilation error is thrown.
Disclaimer: This is almost certainly some user error on my part.
I've been trying to get this running for a couple of days, but am struggling to understand some behavior I've been seeing with DTT.
I wanted to measure some transfer functions in the simulated model I set up.
To see if this is just a feature in the simulated model, I tried measuring the "plant" filter in the C1:LSC-PRCL filter bank (which is also just a pendulum TF), and run into the same error. I also tried running the DTT template on donatella (Ubuntu12) and pianosa (SL7), and get the same error, so this must be something I'm doing wrong with the way the measurement is being run / setup. I couldn't find any mention of similar problems in the SimPlant elogs I looked through, does anyone have an idea as to what's going on here?
* I can't get the "import" feature of DTT to work - I go through the GUI prompts to import an ASCII txt file exported from FOTON but nothing selectable shows up in DTT once the import dialog closes (which I presume means that the import was successful). Are we using an outdated version of DTT (GDS-2.15.1)? But Attachment #1 shows the measured part of the pendulum TF, and is consistent with what is expected until the measurement terminates with a synchronization error.
the import problem is fixed - when importing, you have to give names to the two channels that define the TF you're importing (these can be arbitrary since the ASCII file doesn't have any channel name information). once i did that, the import works. you can see that while the measurement ran, the foton TF matches the DTT measured counterpart.
11 Dec 2pm: After discussing with Jamie and Gabriele, I also tried changing the # of points, start frequency etc, but run into the same error (though admittedly I only tried 4 combinations of these, so not exhaustive).
Several housekeeping tasks were carried out today in preparation for the Y-arm loss measurement.
Rich came by the 40m to photocopy some pages from Hobbs, and saw me working on the 60 Hz hunting. As I suspected, the problem was being generated in the D040060. This board receives the photodiode signal single-ended, but has a different power ground than the photodiode (even though the PD is plugged into a power strip that claims to come from 1Y4). The mechanism is not entirely clear - the presence of these 60 Hz features seemed to be dependent on the light level on the TRY photodiode (i.e. they were absent when the PSL shutter is closed, and were more prominent when TRY was 0.9 rather than 0.5) but the PD certainly wasn't saturated - the DC signal was only ~100 mV when viewed on a scope. In any case, Rich suggested the simplest test would be to ground the BNC shield bringing TRY to the rack, to the local ground on the board, which I did using a crocodile clip. This did the trick, the TRY signal RMS is now dominated by the ~1 Hz seismic-driven variation.
On a more pessimistic note - it looks like the elliptical reflector moving did not work, and the clipping in the Y arm persists . I am able to recover TRY~1 with the yaw offset on the ETM (which is still lower than the 1.06-1.07 Koji reported in Aug 2018, but I can believe that being down to the MC transmission being a few % lower at 15000cts rather than 15500), while the maximum I see without it is ~0.9. This is puzzling, because when the chamber was open, we saw that there was ~1.5" clearance between the edge of the reflector and the beam on an IR card. I suppose the input pointing could have been off by a small amount. So one of the primary vent objectives wasn't acheieved... But I will push ahead with the loss measurement.
Since we changed the HeNe, I updated the calibration factors, and accepted the changes in the SDF.
A more permanent fix than a crocodile clip was implemented. Should probably look to do this for the X end unit as well.
Now that the IMC is remaining locked for extended periods of time, the next problem to attack is the ASS dither alignment system. For a start, I decided to try and get the POX and POY locking working again, as we have not fully recovered the interferometer alignment after the most recent pumpdown. I spent a couple of hours tweaking the alignment of the arm cavity mirrors, BS, and TTs to try and recover the maximum possible TRX and TRY - however, my best efforts only yielded TRX~0.8, TRY~0.75. Moreover, the beam axis is such that the spot is significantly off in YAW on both ETMs, as evidenced by the camera views (also true but less obvious on the ITMs). However, trying to bring the beam back to the center of the optics yields TRY and TRX values lower than the above reported maxima. The EX green beam is currently unavailable to verify the arm cavity alignment because of my hijacking the EX NPROs PZT control for PLL investigations, but with the Y arm, I'm able to lock a TEM00 mode. Probably just needs more careful systematic alignment, but I'm not pursuing this tonight.
After a more systematic alignment effort, I was able to get the spots better centered on the optics (judged by eye from the analog camera views). TRY ~0.7, TRX~1.15. The X-arm dither alignment system seems to work out-of-the-box with the existing settings, I was able to run it and maximize the X-arm transmission.
Other work: I also cleaned up the area around MC2 a litte - laptop from on top of the vacuum chamber was removed and a rogue ethernet cable was also removed. The resulted in some misalignment of the IMC, which I corrected by manual alignment. Now the IMC is locked again with nominal transmission levels.
On the PSL table, I re-routed the RF output from the BeatMouth to the regular IR-ALS electronics chain (it was hijacked for PLL investigations). At EX, I disconnected the cable running from the LB1005 to the EX NPRO laser PZT (again was being used for PLL locking), and re-connected the output from the Green uPDH box to allow for some ALS tests to be done. I could then lock the EX green beam to the X-arm, and achieved GTRY ~ 0.35 using the ASX system. More to follow on ALS tests later today.
In preparation for the ASS debugging, I decided to check out the beam path on the EY table. In order to be able to do this, I had to setup the POY locking to trigger on AS110 instead of TRY (as is usual for this kind of debugging). Then I could poke an IR card in the beam path without destroying the lock.
There are two irides in the beam path immediately between the vacuum window and the harmonic separator that splits off the IR and green beams. I found that the beam was in fact getting clipped on both of them. It was also somewhat off center on a 2" beamsplitter that sends half of the light to the QPD (currently decommissioned). The purpose of these irides are (I think) to eliminate some ghost reflections of the green beam and also the Oplev beam. I opened up the irides until I felt that there wasn't any more clipping of the IR beam, but the appropriate ghost beams were still getting caught.
I also re-aligned the beam onto the TRY Thorlabs PD so as to better center it on the active area. In summary, the result of this work was that the TRY level went from ~0.6 to ~0.93. There may still be some scope for optimizing this - I tried running the Y-arm ASS scripts, and already, the loops don't run away any more. I'll do the systematic analysis of the servo anyways. But given that the IMC Trans lev el used to be ~15,500 counts and is now ~14,500 counts, I think ~7% drop in TRY level is in line with what we "expect" (assuming the pre-power-degradation TRY level was 1.000).
Note that these irides were installed (I think) by Yuki, and so cannot explain the ASS anomalies of July 2018 (i.e. it does not exonerate in-vacuum clipping of the beam, as Koji had already verified that the in-air path was clean back then).
The Y-arm ASS was tuned to be in a workable state. Basically, I followed Koji's recipe.
The SNR of the dither lines in the TRY and YARM control signals were checked - Attachment #1. The dither frequencies are marked with vertical dashed lines (can't figure out how to add 4 cursors in DTT so there's two in each row for a total of 4). A couple of days ago, when I was doing some preliminary checks, I found that the oscillator at 24.91 Hz caused a broadband increase in the TRY noise between DC and ~100 Hz. But today I saw no evidence of such behaviour. So I decided against changing the frequency.
The linearity of the demodulated error signals around the quadratic maxima of the TRY level was checked. I did not, however, investigate in detail the frequency-dependent offset Koji has reported in his elog.
After this work, the TRY level is at 0.95. This is commensurate with the MC trans level being lower by ~7% relative to July 2018. Furthermore, the ASS servo is able to return to TRY~0.95 with a time-constant of ~5 seconds in response to misalignment of the cavity optics. After I investigate the X-arm ASS, I will reset the normalization for TRX and TRY.
Update 645pm: In the spirit of general IFO recovery, I re-centered the ITM and ETM oplev spots, and also the IR beam on the IPPOS QPD to mark the new input pointing alignment (the spot is slightly lower on the AS camera than what I remember). I then tweaked the XARM transmission to maximize it, and re-set the TransMon normalization. I edited the normalization script to comment out the normalizing of the TransMon QPD gains as the QPDs are in some kind of indeterminate state now. Attachment #2 shows the current status, you can also see the normalization being reset. LSC mode disabled for overnight.
Once the XARM ASS is also checked out, I propose moving back to locking the DRMI / PRFPMI configs.
I tried to lock the Y arm cavity length to the PSL frequency using POY11_I as an error signal. Even though I think the cavity alignment is good (I see TRY flashes ~0.8), I am unable to achieve a lock. I checked the signal conditioning, and as far as I can tell, all the settings are correct, but there may be some settings that have not been re-assigned correct values. The other possibility is that something is not quite right with the new c1iscaux. The PDH error signal and arm cavity flashes all seem good though (see Attachment #1), so I'm not sure what obvious thing I'm missing.
To be continued...
There is no visible PDH error signal on the POX11 channels. As a result, I am unable to lock the XARM length to the laser frequency. See Attachment #1 - the Y arm length is locked to the PSL frequency, and control is disabled for the XARM servo.
Now that several of the c1iscaux functionality tests have been completed, I wanted to push ahead with some locking. However, I was foiled at this early stage, for reasons as yet unknown. One possibility is that the
I confirmed that there is light incident on the POX photodiode. So the problem must lie downstream in the demod / whitening / AA electronics. With the PRM aligned (i.e. PRFPMI config with all DoFs uncontrolled), I could see the flashing beam on an IR card. I could also see the spikes in DC power incident on the photodiode using the "DC Monitor" port on the photodiode head and an oscilloscope.
Update 245 pm: I confirmed that I could see a 11 MHz sine wave by connecting the POX11 RFPD output cable at the 1Y2 end to an oscilloscope. The amplitude of this signal was also changing, corresponding to the cavity fringing in and out of resonance. I couldn't, however, see any signal on the RFPDmon port, or the I/Q demodulated output ports. So as of now, the culprit seems to be something on the Demod board. Further investigations underway...
Update 315pm: I did the following checks:
Look for the POX beam with an IR viewer.
The PRMI was locked with the carrier field resonant in the PRC 🙌. The lock is pretty stable (I only let it stay locked for ~10mins and then deliberately unlocked to see if I could readily re-lock, but it has stayed locked for the last ~20mins while I typed this up). See Attachment #1 for the DC power monitor StripTool for a short section of lock.
Next (for LSC activities):
I'm leaving the LSC mode off for tonight, but with the PRMI optics aligned and ETMs misaligned.
I measured the OLTF of both the PRM Oplev loops. Nothing odd sticks out as odd to me in this measurement - there seems to be ~40 degrees of phase margin and >10 dB gain margin for both loops, see Attachment #1. I didn't measure down to the second UGF at ~0.2 Hz (the Oplev loops are AC coupled), so there could be something funky going on there. The problem still persists - if I misalign and realign the PRM using the ifoalign scripts, the automatic engagement of Oplev loops causes the loop to oscillate. Could be that the script doesn't wait for long enough for the alignment transient to die out.
Update 1230pm: Indeed, this was due to the integrator transient. It dies away after a couple of seconds.
The PRMI Oplev servo needs some tuning, it is currently susceptible to oscillations in Pitch.
I was able to lock the FPMI. The lock was quite stable. However, the fluctuations in the ASDC power suggest that it will be difficult to make a DC measurement of the contrast defect in this configuration. This problem can be circumvented in part by some electronics tuning. However, the alignment jitter couples some HOM light which is an independent effect. Can this be a good testbed for the proposed AS WFS system?
I didn't do any serious budgeting yet - need to think about / do some modeling on how this configuration can be made useful.
wonder if its possible to do variable finesse locking
Gabriele mentioned that Virgo used arm trans PDH for this, but I guess we could possibly use POX/POY to start and bring in the PRM with 50% MICH trans
There is an imbalance between the POX and POY detector outputs reported in the CDS system. Possibilities are (i) the POX PD has a uncoated glass window whereas POY does not or (ii) there is some problem in the elctronics.
So increasingly, it looks like the electronics are the source of the problem.
In preparation for some locking work tonight, I did the following at the POP in air table with the PRMI locked on carrier:
After making sure the beams were hitting the 3f photodiodes on the "AP" table, I was able to lock the PRMI with the sidebands resonant inside the RC using 3f error signals. This would be the config we run in when trying to lock some more complicated configuration, such as the PRFPMI (i.e. start with the arms controlled by ALS, held off resonance). Tonight, I will try this (even though obviously I am not ready for the CARM transition step). The 3f lock is pretty robust, I was able to stay locked for minutes at a time and re-acquisition was also pretty quick. See Attachment #1. Not sure how significant it is, but I set the offsets to the 3f paths by averaging the REFL33_I and REFL33_Q signals when the PRMI was locked with the 1f error signals.
As usual, there's a lot of angular motion of the POP spot on the CCD monitor, but the lock seems to be able to ride it out.
Lock-settings (I modified the .snap file accordingly):
REFL33_I --> PRCL, loop gain = -0.019, Trigger on POP22, ON @ 20cts, OFF@0.5cts.
REFL33_Q --> MICH, loop gain = +1.4, Trigger on POP22, ON @ 20cts, OFF@0.5 cts.
This problem has re-surfaced. Is this indicative of some problem with the on-board VGA? Even with 0dB of whitening gain, I see PDH horns that are 10,000 ADC counts in amplitude, whereas the nominal whitening gain for this channel is +18dB. I'll look at it in the daytime, not planning to use REFL55 for any locking tonight.
Hardware issues that need addressing:
There is poor separation of the PRCL and MICH length error signals as sensed in the 3f photodiodes. I don't know why this is so - one possibility is that the MICH-->PRM matrix element in the LSC output matrix needs to be tuned to minimize the MICH -->PRCL coupling.
Over the last few days, I've been trying to make the 3f locking of the PRMI more reliable. Turns out that while I was able to lock the PRMI on 3f error signals, it was just a fluke. So I set about trying to be more systematic. Here are the steps I followed:
Attachment #1 is the result. I don't know what is the reason for such poor separation of the MICH and PRCL error signals in REFL165. The situation seems very different from when I had the DRMI locked in Nov last year.
After this exercise, I tried for some hours to get the 3f PRMI locking going with the arm cavities held off resonance under ALS control, but had no success. The angular motion of the PRC isn't helping, but I feel this shouldn't be a show stopper.
This is as far as I got last night. The first step is to see how reliable the settings determined last night are, today. I don't understand how changing the output matrix element can have brought about such a significant change in the MICH/PRCL separation in all the RF photodiodes.
I ran some sensing measurements at various CARM offsets to check if the PRCL-->REFL33 and MICH-->REFL165 signals were being rotated out of the sensing quadrature as I lowered the CARM offset - there was no evidence of this happening. See Attachment #2. Other possibilities:
The IMC went into some crazy state so I'm calling it for the night, need to think about what could be happening and take a closer look at more signals during the CARM offset reduction period for some clues...
I looked at some signals for a 10 second period when the PRMI was locked with at some CARM offset, just before the PRMI lost lock, to see if there are any clues. I don't see any obvious signatures in this set of signals - if anything, the PRM is picking up some pitch offset, this is seen both at the Oplev error point and also in the POP QPD spot position. But why should this be happening as I reduce the CARM offset? The arm transmission is only ~5, so it's hard to imagine that the radiation pressure is somehow torquing the PRM. There are no angular feedback loops actuating on the PRM in this state except the local damping and Oplev loops.
The 1f signals are also changing their mean DC offset values, which may be a signature of a changing offset in the 3f MICH and PRCL error points? The MICH error signal is pretty noisy (maybe I can turn on some LPF to clean this up a bit), but I don't see any DC drift in the PRCL control signal.
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: