While meditating on other things, I have noticed / found the following today:
YARM ASS works okay. Yesterday I measured the sensing matrix for the ASS for both arms (although I forgot to copy one of the matrix elements to my text file for Xarm - needs remeasuring). I put the Yarm matrix in (after appropriate inversion, only non-zero pitch-to-pitch, yaw-to-yaw elements). I turned on the Yarm ASS, and the yaw converged pretty quickly (couple of minutes), with gains of -1 in the servos, overall gain of anywhere between 0.005 and 0.010. The pitch took much longer, and I had to 'pause' several times by turning off the overall gain for the yarm ass when the MC lost lock (which has happened several times tonight - unknown cause). Eventually, the pitch settled out, and quit changing, but the lockin outputs weren't zero, even though the error signal for the servos were almost zero (gains for the pitch servos were -0.5, overall gain ~0.005 was better than 0.01 - higher gain caused oscillations in the lockin outputs). I think this means that I need to remeasure the yarm pitch ass matrix. It's still much, much faster to just turn on the dithers, watch the striptool of the lockin outputs, and align the cavity by hand.
I think the ETMX Trans camera view is clipped a little bit. I went down there, and it doesn't seem to be on the last optic before the camera, and moving the spot on the camera doesn't change the shape of the image, so I don't think it's on the camera. We should look into this, since it's either clipping on the BS that separates some camera beam from the TRX beam, or TRX is getting a clipped beam too. If the clipping is any earlier in the Trans path, the Trans QPD could also have some clipping. This requires investigation. The xarm trigger needs to be reset/disabled so we don't lose lock every time we block the TRX beam (as was happening to me).
XARM really doesn't like to relock unless the POX whitening is turned off. Good flashes, doesn't really catch (10+ min waiting (while working on Yarm stuff) ). After turning off the whitening, it catches almost immediately. Even though it's on the to-do list to rethink the tuning of our whitening, we should probably implement the whitening triggering now anyway. It'll make things easier.
The double integrator that Rana implemented in the X and Y arm servo filters last week take 8 seconds to turn off (due to Foton settings), so even though they are triggered to turn off immediately upon lockloss, they sit around and integrate for 8 seconds, so have huge signals. If the cavity flashes and the locking trigger engages during that 8 seconds, we send a huge kick to the ETMs. I'm modeling the response of the filters to an impulse and noise, particularly in the case of ramping on the double integrators. The problem is that a flat filter has 0deg phase, but the double integrator has 180deg phase at low frequencies, so there's some weird sign flipping that can happen as we ramp - this is part of what I'm modeling.
MC is losing lock unusually often tonight. Everything on the servo board screen looks normal (which is good since that's all set by the autolocker). I just disabled the test exc in, but that's been left enabled for a while now, and it hasn't (I think?) been a problem since there shouldn't be anything connected to the board there. PMC transmission is a little low, 0.816, and FSS is starting to get near -1 on the slow actuator adjust, but we've seen locking of the PMC problems around -1.5 or -2 of the FSS, and the adjust value was at -0.8 earlier tonight and we still had MC locking problems. I have had the seismic channels open on Dataviewer for the last several hours, and I'm not seeing any spikes in any of the Guralp channels which correspond to the times that the MC loses lock. BLRMS don't seem particularly high, so MC lockloss cause is still a mystery for today.
The ETMX monitor selector on the VIDEO screen seems not to be switching the actual camera that's shown on the monitor. Using the script command itself works, so my screen is wrong.
I'd like to get a concrete list of measurements written down, so that it's clear what needs to be done before I graduate.
Are there things that I'm missing? I've never had an IFO to characterize before.
Here are some tests we should script.
Checking the Acromag DAC calibration is more complicated I think. There are measurements of the actuator calibration in units of nm/ct for the fast DACs. But these are only valid above the pendulum resonance frequency and I'm not sure we can synchronously drive a 10 Hz sine wave using the EPICs channels. The current test which drives the PIT/YAW DoFs with a DC misalingment and measures the response in the PDmon channels is a bit ad hoc in the way we set the "expected" response which is the PASS/FAIL criterion for the test. Moreover, the cross-coupling between the PDmon channels may be quite high. Needs some thought...
Never mind. This is just the low pass filter that Den put in to try to deal with the moving cavity pole.
Before I realized this, just in case it was a computer quirk, Koji and I rebooted the end station front end machines. This had no effect other than to keep me searching and measuring until I figured it out. If I turn off the low pass, the phase pops back up to very close to the reference. The low pass currently comes on automatically as part of the carm_cm_up script.
I need to figure this out before it's worth trying any acrobatic AO path turn-on scenarios.
Also this evening, I went to the Yend and did another tweak-up of the green beam alignment.
We opened up the little Thorlabs battery operated PD to see what was inside. Rana took some pictures, and I drew a schematic (attached). It's just a diode, biased with a battery (albeit a crazy 22.5V battery).
Comment by KA: PD is Hamamatsu S1223-01 Si PIN diode.
What a crazy battery. The main point is that it looks like this can be used for reasonable purposes: uses a load resistor on the BNC connector and you can use some pre-amp (e.g. Busby box or SR560) to have a low noise PD readout. You can also use the SR560 in its A-B mode as an 'opamp'. Ground the A input and the use a pole at 1 Hz and make the Output go into the B input through some large series resistor. The BNC from the PD gets Teed into the B input as well.
Then this becomes a transimpedance circuit readout of the diode, using the current noise of the SR560 as the limit.
I tried to figure out why offline LMS filter subtract seismic noise much better from MC_F then the Wiener filter. I did the calculations twice - with my codes and with Matlab in-build functions, the results are the same. So this is not a code error.
The coherence between GUR 1, 2 and MC_F is still poor. Wiener filter is linear and its performance is confined to the frequency ranges where we see coherence. Lms filter is non-linear and it may be possible to subtract the noise even if non-linear effects are present in the system.
I've checked seismometer readout box again. I've soldered 50 Ohms to plus and minus inputs to VERT 1,2 N/S 1,2, E/W 1,2 - GUR 1 and 2 use these channels. Then I put the box back and connected it to the ADC.
The plot shows that the readout box noise is below the ADC noise. It is possible that amplifiers introduce non-linear effects. To check this I plotted the coherence between OSEM sensors and GUR1X signal:
The coherence between OSEM sensors and GUR1X is pretty good, so may be witness path is not responsible for low coherence at 0.1 - 0.5 Hz between MC_F and GUR 1,2. IT seems that MC_F is bad at low frequencies. I terminated the input to the Channel 1 of the Pentek Generic board, where MC_F is plugged in.
ADC is also good. Something else is wrong.
Larry and Nicolas
Larry's transfer function measurements suddenly started returning 0dB 0degrees when before there was some fake filter in the C1:ALS-OFFSETTER2 filter bank.
We looked in the filter bank and his filter was gone. So I created a new filter called LARRYP in FM2. We also disabled the output so he could drive the filter bank and test his TF code.
I'll bring a file binder "40m wiring diagram" to home at the next chance.
There is another one on the shelf in the control room.
(I thought I put it in my bag, but it looks like that I left it somewhere around the fax area)
Koji has provided a 2TB USB3 external hard drive that will get daily backups of chiara:/home/cds, the idea being that if the internal HD at /dev/sdb1 fails, we can physically open the external up, and swap the hard drive into chiara.
We're running an rsync job on it right now, which should be done in a few hours. (USB3 is fast!)
I've also written a backup script at scripts/backup/rsync_chiara.backup which keeps its books in scripts/backup/rsync_chiara.backup.log
I'm adding a entry to the root crontab on chiara to execute the script every day at 7am.
I had some syntax errors in the script that prevented the script from doing the right thing. The backup is now up to date, and the cronjob should work.
We found that the caput commands were taking much longer to execute on megatron than on pianosa (for example). Suspecting that this had something to do with the fact that megatron was using EPICS binaries from the shared NFS drive which were compiled for a much older OS, I installed the latest stable release of EPICS on megatron. The new caput commands execute much faster. I also added the local EPICS directory to the head of the $PATH variable used by the MC autolocker and FSS Slow scripts, so that they use the new caput command. But mcup is still slow - maybe my new path definition isn't picked up and it is still using the NFS binaries? To be looked into...
There were a bunch of medm processes stalled on megatron (connected with screenshot taking). To see if they were interfering with the other scripts, I killed all of the medm processes, and commented out the line in the crontab that runs the screenshots every 10 mins. Let's see if this improves stability.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "en_US.ISO8859-1",
LC_MONETARY = "en_US.ISO8859-1",
LC_CTYPE = "en_US.ISO8859-1",
LC_COLLATE = "en_US.ISO8859-1",
LC_MESSAGES = "C",
LC_NUMERIC = "en_US.ISO8859-1",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Between the 40m meeting, and chatting with Gabriele, there was lots of talking yesterday about our 40m Lock Acquisition game plan.
From those talks, here is my current understanding of the plan, in a Ward-style cartoon:
(This is a 2 page document - description of steps is on 2nd page)
If you look closely, you will notice that there are several places that I have used "?" rather than numbers, to indicate what RFPD signal we should be using. To fill these in, I need to look at some more simulations, and think more carefully about what signals exist at what ports, and what SNR we have at each of those ports.
Also, while the overall scale of the arm power plot is correct, the power level at each step is totally arbitrary right now, and should just be taken to mean places (in time) where the CARM offset is reduced a little more.
There are several things at this point that we know we need to look into:
* POP 22/110 PD and filtering electronics should be switched to a broadband PD, rather than the Thorlabs PD + Miniciruits filters. (Hardware)
* Whitening for the transmission QPDs needs to be thought about more carefully. (Calculation, then hardware)
* Chose a good SNR REFL DC signal, which may or may not be from the PD we are currently using (I think it's the DC of REFL11, but I'll have to check). (Calculation)
* For DRMI locking, what is the size of the SRCL error signal at AS55, AS165, and the REFL ports? Do we need to lock with AS port, and then switch over to a REFL 3f port, to make acquisition easier? (Simulation)
* Similarly, I want to make the equivalent of Figure 3 of T1000294, with our 40m parameters. (Simulation)
* To set the phase of AS110, simulate the demod phase of AS110 in both DRMI and SRMI cases. If no (significant) change, maybe we can set the phase in the real system by misaligning the PRM, and watching the SRMI flash. (Simulation)
* Simulate an arm sweep, up to many orders of the sidebands, to see how close to the carrier resonance any sideband resonances might be. If something like the 4th order sideband resonates, and then beats with a 1st order sideband, is that signal big enough to disturb our 3f locking of the PRMI / DRMI? We want to be holding the arms off resonance with ALS closer to the carrier than any "important" sideband resonances (where the definition of "important" is still undetermined). (Simulation)
* Check if we can hand DARM from the DC transmission signals to the final RF signal while we still have a large CARM offset. Is there a point where the CARM offset is too large, and we must be still using the DC signals? (Simulation)
* At what arm power level can we transition from ALS to IR DC transmission signals for the individual arms? (Simulation)
* Still need to finish calculating what could be causing our big arm power fluctuations (Test mass angular motion? PRM angular motion? ALS noise?) (Calculation)
Replys, and comments are welcome, particularly to help me understand where I may have (likely did) go wrong in drawing my cartoon.
Here is a lock loss from around 11 PM tonight. Might be due to poor PRC signals.
This is with arm powers of ~6-10. You can see that with such a large MICH offset, POP22 signal has gone done to zero. Perhaps this is why the optical gain for PRCL has also dropped by a factor of 30 .
This seems untenable . We must try this whole thing with less MICH offset so that we can have a reasonable PRCL signal.
Provided the IMC is cooperative, the input pointing isn't drifting, and the RF offsets aren't jumping around too much, the locking sequence is now pretty robust.
Most of the analysis uses data between the GPS times 1274418176 and 1274419654 that are recorded to frames.
Here, I provide some details of the sequence. Obviously, I am presenting one of the quickest transitions to the fully locked state, I don't claim that every attempt is so smooth. But it is pretty cool that the whole thing can be done in ~3 minutes.
See Attachment #1 for the labels.
This particular lock held for ~20 minutes so I could run some loop characterization measurements etc.
I am struggling to explain:
I see. At the 40m, we have the direct transition from ALS to RF. But it's hard to compare them as the storage time is very different.
Which 1f signals are you going to use? PRCL has sign flipping at the carrier critical coupling. So if the IFO is close to that condition, 1f PRCL suffers from the sign flipping or large gain variation.
For these initial attempts, I was just trying to transition MICH to REFL55Q. I agree, the PRCL situation may be more complicated.
Thursday morning I found the control room emergency exit not locked.
Please check the doors when leaving the lab , specially when you are the last one out.
I finally managed to get long stretches of PRMI lock, up to many minutes. The lock is not yest very stable, it seems to me that we are limited by some yaw oscillation that I could not trace down. The oscillation is very well visible on POP.
Presently, PRCL is controlled with REFL55_I, while MICH is controlled with AS55_Q. This configuration is maybe not optimal from the point of view of phase noise couplings, but at least it works quite well. I believe that the limit on the length of locks is given by the angular oscillation. I attach to this entry few plots showing some of the lock stretches. The alignment is not optimal, as visible from a quite large TEM01 mode at the dark port.
Here are the parameters I used:
MICH gain -10 PRCL gain -0.1
Normalization of both error signal on POP22_I with factor 0.004
Triggering on POP22: in at 100, out at 20 for both MICH and PRCL.
POP55 demodulation phase -9
MICH and PRCL control signal limits at 2000 counts
There is a high frequency (628 Hz) oscillation going on when locked (very annoying on the speakers...), but reducing the gain made the lock less stable. I could go down to MICH=-1.5 and PRCL=-0.02, still being able to acquire the lock. But the oscillation was still there. I suspect that it is not due to the loops, but maybe some resonance of the suspension or payload (violin mode?). There is still some room for fine tuning...
Lock is acquired without problems and maintained for minutes.
Have a nice week-end!
Our first move has to be fixing the whitening switching for REFL55. That's the configuration we need to start and then move onto REFL165 to get to FPPRMI.
I put a notch in FM10 for both MICH and PRCL at 628Hz, to try to prevent us from exciting the mode that Gabriele saw on Friday. Since those filter banks were all full, I have removed an ELP50 (ellip("LowPass",4,1,40,50)). I write it down here, so we can put it back if so desired.
I was going to try some locking, but things are a little too noisy.
Just so Kiwamu knows what I did today, in case he comes back....
I ran LSCoffsets, and aligned both X and Y arms and saved their positions, and aligned MICH, and saved the BS position.
I'll play with it more later, when there aren't trucks driving around outside that I can hear / feel in the control room.
After giving up on locking, the MC is getting unlocked every now and again (2 times so far in the last few minutes) from transient seismic stuff.
Each morning now, I am going to try to align both arms and lock. Along with that, sometime at towards the end of each week, we should align the OpLevs. This is a good habit that should be practiced more often, not only by me. As for the Y Arm, Yehonathan and I had to adjust the gain to 0.15 in order to stabilize the lock.
Could not load filters into the C1:SUS-ETMX_LOCKIN1_SIG filter bank.
Apparently the filter bank name was too long. I'm not sure why this isn't caught by the real time code generator, I'm planning on asking Alex and Rolf about it today.
Reduce the name of the components. Basically LOCKIN1 needs to become something like LOCK1 or LIN1.
In related news, it looks like the initial filters are hard coded to be 2048 Hz. Given that they start out empty they won't cause things to break immediately, and if you're editing the file you can update the rate as you add the filter. I'll also bring this up with Alex and Rolf and see if the RCG can't be more intelligent about its filter generation.
we decided to give the PRFPMI lock a go early-ish. Summary of findings today eve:
The ALS--> IR CARM handoff is the problematic step. In the past, getting over this hump has just required some systematic loop TF measurements / gain slider readjustments. We will do this in the next few days. I don't think the ALS noise is any higher than it used to be, and I could do the direct handoff as recently as March, so probably something minor has changed.
Main goals tonight were:
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:
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:
TL;DR: Got the x-arm aux laser locked again and took more data - my fit on my transfer functions need improvement and my new method for finding coherence doesn't work so I went back to the first way! See attached file for an example of data runs with poor fits. First one has the questionable coherence data, second one has more logical coherence. (ignore the dashed lines.)
We were able to lock the Y-arm using Megatron and the RCG generated code, with nothing connected to c1iscey.
All relevant cables were disconnected from c1iscey and plugged into the approriate I/O ports, including the digital output. Turns out the logic for the digital output is opposite what I expected and added XOR bitwise operators in the tst.mdl model just before it went out to DO board. Once that was added, the Y arm locked within 10 seconds or so. (Compared to the previous 30 minutes trying to figure out why it wouldn't lock).
[Jenne, Rana, EricQ]
We tried a few times to engage the AO path while holding CARM on sqrtTrans and DARM on ALS, but failed every time. Since we cannot stably hold lock at arm powers of 1, even though we were able to do so early last week, we think that we have a problem (obviously). One noticeable thing is that while held with ALS, the Xarm transmission fluctuates almost full power.
As we were seeing late last week, the Xarm IR transmission while held with ALS was fluctuating wildly, whether we were locked on individual arms or on CARM/DARM.
Tonight we took some out of loop spectra, with different HEPA settings, to see how that affected things. It looks like HEPA at the nominal ~20% is okay, but anything higher than that starts to affect the Xarm beatnote sensing, while it mostly leaves the Yarm beatnote sensing okay. Perhaps this is something that isn't tightened enough in the Xarm path, or something on a skinny floppy mount that needs to be more secure.
I am still a little confused though, why we don't see large power fluctuations in *both* arms while using ALS to control CARM/DARM. Why are we not seeing this Xarm noise being fed back into the Yarm, through either the ETM via DARM, or common stuff via CARM actuating on MC2.
Note that the change at high frequency is because I switched from using non-DQ channels to DQ channels, so that's not anything to pay attention to. The noise reduction we see is below about 20Hz.
Rana pointed out that our POPDC level was very small. We don't have screens for them, but the DC PDs have the same analog whitening as the RF PD signals do. I changed C1:LSC-POPDC_WhiteGain.VAL from 0 to 11. Now our POPDC while locked on sidebands is about 8,000 counts.
We also swapped the cables between the SR785 and the CM board around. Now channel 2 of the 785 goes to TP2A, channel 1 goes to TP2B, and the source goes to EXCB. This is so that we can break the AO loop with the disable switch just after the slow/fast split, and look at the transfer function before we close the loop.
No major progress today.
I fixed a bug in my lockloss script that was asking it to start gathering data just after the lockloss, rather than some seconds beforehand. Ooops. Anyhow, with this handy-dandy plotting, I still don't know why we are losing lock when we have PRMI on REFL33, CARM on sqrtInvTrans, and DARM on AS55. I don't see any oscillations, just the arm power drops off, and a moment later the POP power drops.
For example, here is one of the best states we got to tonight. Data for this is in ..../scripts/LSC/LocklossData/1094369700 . You can re-create the plot by going to ..../scripts/LSC/LocklossData/ and doing ./PlotLockloss.py 1094369700 . We had set the triggers for the trans PD/QPD such that we were using the QPD transmission signals the whole time (above trans of 0.2). We saw that the noise at high frequency during low transmission powers for sqrtInvTrans as an error signal was higher using the QPDs than with the Thorlabs PDs, but that both cases are below the noise for ALS. The arm powers were pretty steady above 3 for the last bit of this lock stretch. I lost lock while trying to transition DARM over to AS55Q. CARM was on sqrtInvTrans(QPDs), PRMI on REFL33 I&Q as usual.
./PlotLockloss.py 1094369700 .
Other things from this evening:
* When I was starting, I saw that when I locked the PRMI, the PRM was oscillating in pitch. Oscillation only happened when PRM pitch oplev was on. I'm not sure what could have changed to make the oplev loop unstable, but the gain was 7.0, and now I have left it at 5.0.
* I recentered the PRM and ITMY oplevs.
* Plugged in the Yend PDH error monitor and pzt output monitors, since I forgot them last week. Hopefully this will allow the Yend SLOW servo to work, and keep us away from the limits of the PZT range.
Some small things I did tonight which did little to nothing to help:
My main concern with tonights situation was the huge low frequency fluctuations of TRY while CARM/DARM locked on ALS. We saw this being very smooth very recently, but when one arm is fluctuating by multiple line widths, it isn't surprising that locks aren't stable. I want to know why the out of loop stability is so unpredictable.
Kiwamu and Koji
The target is to realize DRMI or PRMI + one arm with ALS.
The focus of the night is to achive stable lock of the PRMI (SB resonant) with 3f signals.
Particularly, REFL165 is back now, we are aiming to see if any of the 165 signals is useful.
We made a comparison between REFL33Q/REFL165Q/AS55Q to find any good source of MICH.
However, none of them showed a reasonable shape of the spectra. They don't have reasonable coherence between them.
Nonetheless, we have tried to lock the IFO with those REFL signals. But any of them were useful to keep the PRMI (SB resonant).
The only kind of stable signal for MICH was AS55Q as we could keep the PRMI locked.
- Adjutsed the IMC WFS operating point. The IMC refl is 0.42-0.43.
- The arms are aligned with ASS
- The X arm green was aligned with ASX. PZT offsets slides were adjusted to offload the servo outputs.
- I tried the locking once and the transition was successfull. I even tried the 3f-1f transition but the lock was lost. I wasn't sure what was the real cause.
I need to go now. I leave the IFO at the state that it is waiting for the arms locked with IR for the full locking trial.
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.
Last night I worked on the several locking configurations:
General preparations / AS table inspection
- The AS beam looked clipped. I went to the AP table and confirmed this is a clipping in the chamber.
This may be fixed by the invacuum PZTs.
Modulation frequency tuning
RFPD Mon of the MC demodulator was check with the RF analyzer. Minimized the 25.8MHz (=55.3-29.5MHz) peak by changing the marconi freq.
This changed the modulation freq from 11.066147MHz to 11.066134MHz. This corresponds to the change of the MC round-trip length from
27.090952m to 27.090984m (32um longer).
- I wonder why I could not see good Michelson signal at REFL ports.
- I roughly aligned the Michelson. On the AP table, the RF analyzer was connected to the REFL11 RF output.
By using "MAX HOLD" function of the analyzer, I determined that the maximum output of the 11.07MHz peak
- I went to the demodboard rack. I injected -61dBm from DS345 into the RFEL11 demodboard. This produced
clean sinusoidal wave with the amplitude of 4 count. The whitening gain was 0dB.
- The output from the PD cable was -64.0dBm. So there is ~2.5dB loss in the cable. Despite this noise, the demodulation
system should be sufficiently low noise. i.e. the issue is optical
- The Michelson was locked with AS55Q. And the REFL11 error signals were checked.Fringe like feature was there.
This suggested the scattering from the misaligned PRM. The PRM was further misaligned. Then some reasonable
(yet still noisy) Michelson signal appeared. (Usual misaligned PRM is not at the right place)
Q. How much scattering noise (spurious cavity between PRM and the input optics) do we have when the PRM is aligned?
Q. Where should we put the glass beam dumps in the input optics?
Q. Can we prepare "safe" misaligned place for the PRM with the beam dump?
- The Michelson was locked with REFL11Q. From the transfer function measurement, the gain difference between AS55Q (whitening gain 24dB)
and REFL11Q was 32dB. The whitening gain was 0dB. In fact I could not lock the Michelson with the whitening gain 33dB (saturation???)
The element in the Input matrix was 1, The gain of the servo was +100. BS was actuated.
Coupled cavity tests
- At least REFL11 is producing reasonable signals. So what about the other REFL ports? The Michelson signals in the other frequencies
were invisible. So I decided to use three-mirror coupled cavity with the loss PRC.
- Aligned X arm, Misaligned ETMX, ITMY. Aligned PRM.
- Locked the PRM-ITMX cavity with REFL11 and REFL33.
- Aligned ETMX. If I use REFL11I for the PRC locking, I could not lock the coupled cavity. But I could with REFL33I.
This is somewhat familiar to me as this is the usual feature of the 3f signal.
- The coupled cavity could be locked "forever". To realize this I needed to tweak the normalization factor from 1.0 to 1.6.
Q. How does the coupled cavity change the response of the cavity? Can we compensate it by something?
Q. Measure open loop transfer functions to check if there is any issue in the servo shapes.
- Transmission during the lock is 3.2 while the nominal TRX with PRM misaligned was 0.93.
This corresponds to power recycling gain of 0.17.
- X arm:
- Source: POX11I, phase 79.5 deg, whitening gain 36dB
- Input matrix: POX11I->1.0->XARM, Normalization TRX*1.60
- XARM servo gain +0.8, actuation ETMX
- XARM trigger 0.25 up, 0.05 down. XARM Filter trigger untouched.
- PRC: (sideband locking)
- Source: REFL33I, phase -34.05 deg, whitening gain 30dB
- Input matrix: REFL33I->1.0->PRCL, Normalization None
- PRCL servo gain +4.0, actuation PRM
- PRCL trigger None
- Same test for the Y arm. At the moment ETMY did not have the OPLEV.
Same level of transmission (~3.3)
- Y arm:
- Source: POY11I, phase -61.00 deg, whitening gain 36dB
- Input matrix: POY11I->1.0->YARM, Normalization TRX*2.1
- YARM servo gain +0.25, actuation ETMX
- YARM trigger 0.25 up, 0.05 down. YARM Filter trigger untouched.
- PRC: (sideband locking)
- same as above
Sideband PRMI attempt
- Now I got some kind of confidence on the REFL33 signal.
- So I tried to get any stable setup for sb PRMI, then to find any reasonable MICH signals anywhere else than AS55Q.
- With REFL33I(PRCL) & AS55Q(MICH), I got maximum ~10sec lock. It regularly locked. It was enough long to check
the spectrum on DTT. But it was not enough long to find anything about the MICH signals at the REFL ports.
- I tried REFL33Q for MICH. The lock was even shorter but could lock for 1~2 sec.
Q. What is the cause of the lock loss? I did not see too much angluar fluctuation. The actuation was also quiet (below 10000).
- PRCL: (sideband locking)
- Same as above except for
- the PRCL servo gain +0.05, No limitter at the servo output.
- Trigger POP22I (low pass filtered by LP10) 20 up, 3 down
- AS55Q -24.125 24dB -> x1.0 -> MICH -0.7, No limitter -> ITMX/Y differential
- REFL33Q -34.05dB -> x2.0 -> MICH same as above
- For both case, trigger POP22I (low pass filtered by LP10) 20 up, 3 down
At this point Jenne came back from dinner. Explained what I did and handed over the IFO.
When I talked with Den via phone, he recommended to use the trigger and normalization with POP110I.
So I decided to try this approach. Also I investigated how the REFL33 signals are useful.
I could find the state where the PRMI(sb) locks regularly, although the lock is ~1min at most.
whitening gain 30dB, -14.0deg (finely tuned in lock)
-> x1.0 -> Triggered by POP110I (20up, 1down)
-> Normalized by POP110I x0.04
-> Gain 0.2~0.12 FM3, 4, 5, 6 always on, no triggered FMs
whitening gain 30dB, -14.0deg (finely tuned in lock)
-> x1.0 -> Triggered by POP110I (20up, 1down)
-> Normalized by POP110I x0.04
-> Gain -20 FM4, 5 always on, no triggered FM
-> ITMX (-1.0) and ITMY (+1.0)
I needed to tune the phase very precisely to reach this state. Also the alignment of the michelson and PRM
was very crtiical to acquire the lock.
Later in the same night I was plagued by PRM alignment drift. It seems that the PRM alignment is bistable or
slightly drifting in pitch. I had to align PRM continuously. When the PRMI is locked, the alignment fluctuation
was mainly in yaw. This was as people commented before.