40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 121 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  6511   Mon Apr 9 17:03:38 2012 DenUpdateEnvironmentLms vs Wiener

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.

  10543   Fri Sep 26 11:44:55 2014 nicolasFrogsComputer Scripts / ProgramsLoaded larry's fake filter into C1:ALS-OFFSETTER2

 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.

  15633   Mon Oct 19 15:38:42 2020 KojiUpdateElectronicsLoan: A file binder "40m wiring diagram"

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)

  10122   Wed Jul 2 15:35:34 2014 ericqUpdateComputer Scripts / ProgramsLocal Chiara backups

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. 


  10236   Fri Jul 18 15:21:12 2014 ericqUpdateComputer Scripts / ProgramsLocal Chiara backups


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. 

  15167   Tue Jan 28 17:36:45 2020 gautamConfigurationComputersLocal EPICS7.0 installed on megatron

[Jon, gautam]

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.

  390   Fri Mar 21 17:01:21 2008 ranaConfigurationDMFLocale change on Mafalda & seisBLRMS restart
Ever since we moved the accelerometers to be around the MC and changed their names, the seisBLRMS
has not been working. I tried to restart it today after fixing the channel names in the par file
but I ran into a PERL / UBUNTU bug.
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").

I don't know how this crept up or when it started. There were a bunch of fixes on the Ubuntu
forums which didn't work.

In the end I just set the 'unset' environment variables via our cshrc.40m file and this seemed
to make ligotools/perl happy. Lets hope this lasts...I love Linux.
  9360   Thu Nov 7 14:39:49 2013 JenneUpdateLSCLock Acquisition Game Plan

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:

 LockAcquisition_7Nov2013.pdf(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. 

  10998   Wed Feb 11 00:07:54 2015 ranaUpdateLSCLock Loss plot

Here is a lock loss from around 11 PM tonight. Might be due to poor PRC signals.  \oint {\frac{\partial PRCL}{\partial x}}

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 crying.

This seems untenable no. We must try this whole thing with less MICH offset so that we can have a reasonable PRCL signal.cool

  17321   Tue Nov 29 11:38:37 2022 JCHowToLSCLock Single Arm After MICH lock

I tried locking single arm this morning, but I was unable to because the triggers were set to lock strictly to MICH. Anchal explained this to me and helped me out. I figured this information would be useful and should be logged somewhere. In red, this is accessed through the IFO --> Configure. Choosing X Arm and Y Arm will change the triggers on the C1LSC page for the single arm locking (In the Black Box.) 

  15348   Tue May 26 02:15:36 2020 gautamUpdateLSCLock acquisition portal entry


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.

  15349   Tue May 26 02:31:00 2020 gautamUpdateLSCLock acquisition sequence

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.

  • A --- Arms are locked on POX/POY, and EX/EY lasers are also locked to their respective arms. The phase tracker outputs are averaged in preparation for transitioning control from POX/POY to ALS. 
  • B --- Aforementioned transition has been realized. CARM offset of -4 is applied. Based on this calibration, this is ~ 4 nm.
  • C --- PRM is aligned in preparation for 3f vertex locking. Between C and D, the long pause is because I also use this time to DC couple the ITM Oplev servos, which requires some averaging. 
  • D --- PRMI is locked. CARM offset reduction begins. Between D and E, I scan CARM through a resonance, and look at the necessary offset requried in the CARM_B (=RF) path. It is a mystery to me why this is required.
  • E --- Ramp CARM offset completely to 0. Twiddle CARM_A and DARM_A offsets (=ALS path) to maximize the arm transmitted powers. Between E and F, you can see that the arm powers stabilize somewhat before any RF control is engaged (more on this later), which means we are approximately in the linear regime of the CARM PDH signal, and the switchover can be effected. As I write this, I wonder if there is any benefit to normalizing the REFL_11 error signal (=CM_SLOW) by the arm transmission for a broader capture range?
  • F --- CARM_B and DARM_B (=RF) paths engaged. I ramp off the ALS servos between F and G using a 10 second ramptime.
  • G --- IFO is now under RF control, ALS control has been turned off completely.
  • H --- Rudimentary ASC is enabled. The ITMs are already running with DC coupled Oplev servos, and for the ETMs, I use the Transmon QPDs. The loop shapes/gains for this part haven't been finalized yet, but some improvement in the stability is seen.

This particular lock held for ~20 minutes so I could run some loop characterization measurements etc.

I am struggling to explain:

  1. Why POP22 goes to 0 when we zero the CARM offset? The arm length is such that the 2f fields don't experience any abrupt changes in reflectivity from the arm cavity for a wide range of offsets. This signal is the trigger signal for the PRMI LSC control - right now, I get around this problem by mixing in some amount of POP DC once the PRMI is locked. But if the lock is lost, this requires some EPICS button gynmastics to try and salvage the lock... I guess the 1f field components experience a different phase on reflection at various offsets, so maybe I should be looking at sqrt(POP22_I^2 + POP22_Q^2) instead of just POP22_I.
  2. Why is an error point offset required in the CARM RF path?
  15360   Wed May 27 20:14:51 2020 KojiUpdateLSCLock acquisition sequence

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.

  15364   Wed Jun 3 01:34:53 2020 gautamUpdateLSCLock acquisition update portal


  • With better ASC servos implemented, I think the lock stability has been improved. 
  • Arm transmission of ~350 was stably maintained (PRG~20, overcoupled). It went as high as 410, so this is now very close to the highest (~425) I've ever managed to get.
  • I was trying to get the vertex transitioned to 1f control but it remains out of reach for now.  The noise at ~100 Hz is dominated by MICH-->DARM coupling (as judged by coherence, I haven't yet done the broadband noise injection characterization). I figured I'd try the 1f transition before thinking about feedforward.
  • The biggest problems remain flaky electronics (poor IMC duty cycle, jumping RF offsets, newly glitchy seismometer, ...)


  15369   Wed Jun 3 03:29:26 2020 KojiUpdateLSCLock acquisition update portal

Woo hoo!

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.

  15371   Wed Jun 3 11:40:56 2020 gautamUpdateLSCLock acquisition update portal

For these initial attempts, I was just trying to transition MICH to REFL55Q. I agree, the PRCL situation may be more complicated.

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.

  11443   Fri Jul 24 13:49:09 2015 SteveUpdatesafetyLock doors please !

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.

  8376   Fri Mar 29 19:56:02 2013 GabrieleMetaphysicsLSCLock of PRMI on sidebands

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!

  8378   Sun Mar 31 17:26:32 2013 ranaUpdateLSCLock of PRMI on sidebands


 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.

  8380   Mon Apr 1 09:25:35 2013 JenneMetaphysicsLSCLock of PRMI on sidebands

[Gabriele, Jenne]

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.

  6509   Mon Apr 9 15:02:30 2012 JenneUpdateLSCLocked MICH

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.

  6510   Mon Apr 9 15:09:34 2012 JenneUpdateLSCLocked MICH


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.

  58   Fri Nov 2 12:18:47 2007 waldmanSummaryOMCLocked OMC with DCPD
[Rich, Sam]

We locked the OMC and look at the signal on the DCPD. Plots included.
  17126   Thu Sep 1 09:00:02 2022 JCConfigurationDaily ProgressLocked both arms and aligned Op Levs

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.

  4313   Thu Feb 17 11:51:14 2011 josephbUpdateCDSLockin filter names too long - broke loading


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.


  1316   Tue Feb 17 05:20:11 2009 YoichiUpdateLSCLocking
Since we excluded *.snap and *.req files from the svn control in the medm directory and these were not restored by the svn co, the burt part of the align/mis-align scripts were not working correctly this evening. So I recreated .req files and cooked up some mis-aligned .snap files.
After some cut-and-try work, I was able to run the dither alignment scripts fine.

Due to the above mentioned delay, the locking work started around midnight.

Tonight, the DD hand-off was not robust. I spent sometime to optimize this.
After the optimization, the locking proceeded to the DC CARM/DARM control state stably.
The CARM->MCL hand-off failed because the LSC-MC offset button was off.
I added a line to turn on the button in the ontoMCL script.
Today, the offloadMCF script worked fine.

Next, the cm_step script stumbled on the "ENGAGERIZING" of the AO path.
I got a hunch that the AO path might not be connected to the MC board.
Indeed, OMC_OSC_FM was connected to the IN2 of the MC board. Looks like it was used for the optimization of the modulation frequencies.
Probably I had the hunch because I did it Smile

I was able to increase the arm power up to 3.9.
The script failed when it tried to switch the CARM signal from TR_DC to SPOB_DC.
I haven't tackled on this issue yet.
  16247   Wed Jul 14 20:42:04 2021 gautamUpdateLSCLocking

[paco, gautam]

we decided to give the PRFPMI lock a go early-ish. Summary of findings today eve:

  1. Arms under ALS control display normal noise and loop UGFs.
  2. PRMI took longer than usual to lock (when arms are held off resonance) - could be elevated sesimic, but warrants measuring PRMI loop TFs to rule out any funkiness. MICH loop also displayed some saturation on acquisition, but after the boosts and other filters were turned on, the lock seemed robust and the in-loop noise was at the usual levels.
  3. We are gonna do the high bandwidth single arm locking experiments during daytime to rule out any issues with the CM board.

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.

  1317   Wed Feb 18 03:17:40 2009 YoichiUpdateLSCLocking
Yoichi, Kakeru,

Last night, the cm_step script failed at the hand-off of CARM error signal from TR_DC to PO_DC.
This was fixed by reducing the PO_DC gain by a factor of 2.
Currently the script fails when changing C1:LSC-DEMOD_GAIN to zero.
To be honest, I don't fully understand the purpose of this step.
  15471   Sun Jul 12 02:42:01 2020 gautamUpdateLSCLocking (on rossa)

Main goals tonight were:

  1. Check if I can lock the interferometer by working on rossa - indeed, I could! It is much snappier than the ageing pianosa. The viewing angle of the CRT monitors from this corner isn't so good though.
  2. Measure step responses for the arm ASC loops to see if any insight can be gained into these loops. Analysis forthcoming...
  1334   Tue Feb 24 02:23:40 2009 YoichiUpdateLockingLocking - MC board bad
Rob, Yoichi, Alberto, Kiwamu, Kakeru

We found that the OMC alignment feedback was on for the POS X loop even though the OMC was not locked.
This caused the PZT mirror to be tilted in yaw a lot. This was probably the reason for the mysterious shift in the AS beam last week, because the AS RF beam is picked up after this PZT mirror.
Rob aligned the OMC and we re-centered the AS PDs and the CCD.
This changed the DARM RF gain, so we changed it from 3 to 1. This gain used to be -1. It is still not understood why the polarity was changed.
The MC length was changed ? We should check the sideband transmission.

After this, we reached to the arm power 4. But the IFO loses lock immediately after the moving zero is turned off.
At this stage, the CARM loop bandwidth is supposed to be high enough that the moving zero is no longer necessary.
However, when we measured the MCL loop gain with several different AO path gains, the loop shape did not change at all.
This led us to suspect the AO path may not be connected. The cabling from the common mode board to the MC board seemed ok.
We tested the signal flow in the MC board using a signal generator and an oscilloscope.
Then we found that a signal injected to the IN2 (AO path) does not reach to the TP1A (right after the boost stages), though the signal is visible in the OUT2 (monitor BNC right after the initial amplifier (B-amp) for the AO path). The signal from IN1 (MC REFL) can be observed at TP1A. This means something is broken between the B-amp and the sum-amp in the AO path.
We will check the MC board tomorrow.
  15037   Wed Nov 20 01:07:18 2019 gautamUpdateLSCLocking - progress


  1. CARM offset was reduced to 0 with the PRMI locked.
  2. TRY levels touched ~200 (Recycling gain ~10, IFO is still undercoupled).
  3. TRX level never went so high - I suspect QPD issues or clipping in the beampath.


  • Attachment #1 is a StripTool summary of the lock - encouragingly, the PRMI stayed locked for several 10s of minutes even when the CARM offset was brought to 0.
  • The MICH signal was pretty glitchy - we increased the gain of the MICH and PRCL loops and thought we saw some improvement, but needs more quantitative investigation.
  • Main differences in locking procedure today were:
    • Added some POPDC to the MICH/PRCL trigger elements in addition to POP22
    • Tried adding a DARM offset before doing the final steps of CARM offset reduction, and then zerod the DARM offset too.
  • The TRX level never went as high as TRY - even though on the CRT monitors, both arms seemed to saturate somewhat more evenly. Potentially the EX QPD needs a checkout, or there is some clipping in the in-air TRX path. Although, puzzilingly, the POXDC level never goes as high as POYDC either. So maybe the buildup is really lower in the XARM? For the daytime tomorrow.

Next steps:

  1. Check the EX QPD / TRX situation.
  2. Figure out how to make the PRMI lock more stable as I reduce the CARM offset.
  3. Start figuring out the CM board, as we'd want to do the handoff to RF at some point.
  15038   Wed Nov 20 12:14:17 2019 gautamUpdateLSCLocking - progress

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:

  1. The noise performance of the two QPDs at each end isn't identical - is there some transimpedance gain difference?
  2. The lower plot shows the angular motion reported by each QPD when the arm cavity is locked. The EX QPD seems much more sensitive than the EY QPD.
  3. I estimate that in this condition, each photodiode is receiving ~20uW of power, corresponding to a shot noise limited RIN of ~10^-7. None of the photodiodes saturate this bound.
  4. There are some ND filters placed in front of the QPDs at both ends. Do we really need these ND filters? I estimate that for the highest buildups, we will have ~10kW * 15ppm * 0.5 ~75mW of power incident on the QPD, so ~20mW per segment. Assuming silicon responsivity of 0.2 A/W, a transimpedance of 1kohm would give us 4V of signal. But the schematic shows higher transimpedance. Do we still have the switching capability for this QPD?

Next steps:

  1. Check the EX QPD / TRX situation.
  15034   Mon Nov 18 21:04:38 2019 gautamUpdateLSCLocking - some ideas

Some ideas Koji suggested:

  1. Try approaching the CARM offset zero point "from the other side" - i.e. start with a CARM offset of the opposite sign (I typically use negative CARM offset).
  2. With the PRMI locked, try bringing one arm onto resonance while the other arm is held off resonance. 

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:

  1. The frequency actuator (ETM) is weaker in this case than in the CARM/DARM basis (where MC2 is the frequency actuator) due to the longer length of the arm cavity (and for ETMX, the higher coil driver series resistance). I had to twiddle the limits of the servo banks to accommodate this. 
  2. The ALS error signal is significantly noisier than POX/POY. Hence, the control signal RMS is often in danger of saturating the DAC range. I implemented a partial fix by adding a 1st order Butterworth LPF with 1kHz corner frequency. According to the model, this eats <5 degrees of phase at the desired UGF of ~150 Hz.
  17277   Thu Nov 17 11:24:39 2022 JCHowToLSCLocking MICH

[Yuta, JC]

Here is the Yuta's Alignment Scheme from elog 17056  with these slight adjustments:

Current alignment scheme:
Current alignment scheme I figured out is the following.
 - Check Y green. If it is transmitted at good spot on GTRY camera, Yarm is OK. If not, tweak ITMY/ETMY. alignment.
 - Mis-align AS4, align TT1, TT2, LO1 to have BHDC_A_OUT of ~115 and BHDC_B_OUT of ~95.
 - Align PR3, PR2 to maximize TRY_OUT to ~1.0
 - Tweak ITMY/ETMY if the beam spot on them are not good.
 - Align BS, ITMX to have good MICH fringe and TRX_OUT to ~1.0.
 - Tweak ITMX/ETMX if the beam spot on them are not good.
 - Misalign ETMY, ETMX, ITMY to have LO-ITMX fringe in BHD DCPDs. From Sitemap --> BHD --> Homodyne Phase Ctrl --> LO_PHASE --> Turn ON LO Phase Servo (This will lock LO and ITMX fringe) --> align AS beam with SR2 and AS4 differentially, with ratio of AS4/SR2=3.6 for YAW, with ratio of AS4/SR2= 4.5 for PITCH to have BHDC_A_OUT ~ 50.
 - Restore ITMY alignment, and lock MICH.

  1329   Fri Feb 20 03:52:23 2009 YoichiUpdateLockingLocking Tonight
Yoichi, Peter

Tonight, we had a problem with the DD hand off.
It failed when the RG filters of MICH for the bounce-roll modes are engaged.
The reason for the failure was that the MICH UGF was too low (~10Hz).
As in the Peter's elog entry, we found that the AS PDs are mis-centered.
Even after we fixed the centering, the MICH UGF was still too low. So we increased the MICH feedback gain by a factor of 10.
The reason for the gain decrease is unknown. It seems almost like the BS coils get weaker.
I checked the UGF of the BS OL loops. These are around 4Hz, so fine. We should check the HWP on the AP table tomorrow.

After the DD hand-off goes ok, the switching of DARM signal from DC to RF failed.
I found that the gain and the polarity of the RF signal were wrong.
AS166 is one of the PDs we found mis-centered (and re-centered). But how can you flip the sign of the signal ?

After this, the cm_step script goes until the activation of the moving zero, but fails when the arm power is increased to 0.7.
Also the ontoMCL script succeeds only 50% of the time.
  17087   Wed Aug 17 10:27:49 2022 CiciUpdateGeneralLocking X-arm AUX laser

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.)


  • The aux laser on the x-arm was still off after the power shutdown, so Paco and I turned it back on, and realigned the oplev of the ETMX - initial position was P = -0.0420, Y = -5.5391.
  • Locked the x-arm and took another few runs - was calculating coherence by I/Q demodulation of the buffers and then recombining the I/Q factors and then taking scipy.signal.coherence(), but for some reason this was giving me coherence values exclusively above 0.99, which seemed suspicious. When I calculated it the way I had before, by just taking s.s.coherence() of the buffers, I got a coherence around 1 except for in noisy areas of the data where it dropped more significantly, and seemed to be more correlated to the data. So I'll go back to using that way.
  • I also think my fits are not great - my standard error of the fits (calculated using the coherence as weight, see Table 9.6 of Random Data by Piersol and Bendat for the formula I'm using) are enormous. Now that I have a good idea that the UGF is between 1 - 15 kHz, I'm going to restrict my frequency band and try to fit just around where the UGF would be. 


To do:

  • Reduce frequency band and take more data
  • Get fit with better standard error, use that error to calculate the uncertainty in the UGF!
  2583   Tue Feb 9 17:18:45 2010 josephbSummaryComputersLocking Y arm successful with fully replaced front-end for ITMY

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).

  9945   Tue May 13 03:30:10 2014 JenneUpdateLSCLocking activities - no progress

[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. 

  10485   Wed Sep 10 02:53:32 2014 JenneUpdateLSCLocking activities - nothing new :(

[Jenne, EricQ]

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.



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.

  10486   Wed Sep 10 02:59:42 2014 ericqUpdateLSCLocking activities - nothing new :(

Some small things I did tonight which did little to nothing to help:

  • I reset the offsets in the SQRTINV FMs to try and match the DC level of the ALS CARM error signal as best as possible, to avoid moving away from the set-point too much, as I was worried we were wandering into regions of too low optical gain. 
  • I turned off the WFS, and hand tweaked the MC alignment. The WFS loops / matrices definitely have some room for improvement, and I was worried that excess angular motion of the MC was coupling into CARM. MC refl is much calmer in the last ~1.5 hrs since I turned off the WFS. 

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. 

  6420   Wed Mar 14 23:02:09 2012 KojiUpdateLSCLocking activity

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.

  11180   Fri Mar 27 20:32:17 2015 KojiSummaryLSCLocking activity

- 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.

  14974   Thu Oct 17 11:19:28 2019 gautamUpdateLSCLocking activity last night
  1. Tuning the MICH-->PRM output matrix element
    • Locked the PRMI with the carrier field resonant in the PRC.
    • REFL11 used to control PRCL, AS55 for MICH.
    • Turned on the sensing notches in the control filter bank. Drove a line in MICH at 311.10 Hz.
    • Tweaked the MICH-->PRM matrix element to minimize the coupling witnessed.
    • As shown in Attachment #1, the minimum coupling was found to be at the value -0.34 (the old value was -0.2655).
    • The minimum was very sharp. A 1% change from the optimum value increased the peak height by > x2. Is this reasonable?
  2. Some sensing matrix measurements: After tuning the output matrix element, I locked the PRMI (ETMs misaligned) in four configurations:
    • PRMI locked with carrier resonant. REFL11_I used for PRCL control, AS55_Q used for MICH control.
    • PRMI locked with sidebands resonant. REFL11_I used for PRCL control, AS55_Q used for MICH control.
    • PRMI locked with sidebands resonant. REFL11_I used for PRCL control, REFL165_I used for MICH control (based on sensing matrix measurement and offsets from previous config).
    • PRMI locked with sidebands resonant. REFL33_I used for PRCL control, AS55_Q used for MICH control.
    • The attached GIF shows the evolution of the demodulated sensing lines as we move through configurations.
    • The actual PDFs are attached as a zip, Attachment #2.
  3. PRMI locking with arms under ALS control
    • The arm cavity lengths were controlled as usual with ALS. This system needs some noise budgeting.
    • I set the CARM offset to -8 (arbitrarily chosen, approximately equal to 20nm, but anyways well above the cavity linewidth).
    • Then I re-aligned the PRM, and attemped to lock the PRMI using the 3f settings determined with no arm cavities --> no success.
    • Tried locking using the 1f error signals instead - in this config, the lock could be established.
    • However, I saw that there was significant light on the AS camera, and I had to put in an offset into the MICH loop to make ASDC go as low as possible.
    • I guess it is possible that the ALS control wasn't precise enough and the leaked light to the dark port was because of differential reflectivity of the arm cavities?
    • Anyways, I ran a sensing matrix measurement with the interferometer in this configuration, and I found that the MICH signal in REFL165 had rotated significantly.
    • I also found that the 3f DC offsets in this configuration were ~5x greater than what was the case for the lock with no arm cavities.

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.

  8491   Thu Apr 25 10:19:10 2013 KojiSummaryLSCLocking activity on Apr 24th

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).

Michelson tests

- 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
  was -61.5dBm.

- 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.

  8500   Sat Apr 27 00:21:06 2013 KojiUpdateLSCLocking activity on Apr 26th

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
-> PRM

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.

  1364   Fri Mar 6 05:44:14 2009 YoichiUpdateLockingLocking distracted by the QPD whitenning problem again
Tonight, I was able to ramp up the arm power to around 20. Then the DARM loop started to oscillate and the IFO lost lock in a few seconds.
I repeated this several times, then realized that the transmission QPDs were not working properly again due to the well known sticky slider problem.
I should have run slider_twiddle script. Since the DARM RF signal is normalized by the sqrt(TRX+TRY), it is reasonable that the DARM loop got unstable.

The fact that I was able to go up to arm power = 20 means there is nothing saturating below this power level.
  1365   Fri Mar 6 15:23:39 2009 YoichiUpdateLockingLocking distracted by the QPD whitenning problem again
By looking at the time series of DARM signal at the time of a lock loss, the oscillation frequency was about 3.5kHz (see the attm1 and its zoomed version attm2).
I will measure the DARM loop gain around this frequency next.

Tonight, I was able to ramp up the arm power to around 20. Then the DARM loop started to oscillate and the IFO lost lock in a few seconds.
I repeated this several times, then realized that the transmission QPDs were not working properly again due to the well known sticky slider problem.
I should have run slider_twiddle script. Since the DARM RF signal is normalized by the sqrt(TRX+TRY), it is reasonable that the DARM loop got unstable.

The fact that I was able to go up to arm power = 20 means there is nothing saturating below this power level.
  1296   Thu Feb 12 11:21:54 2009 YoichiUpdateLSCLocking effort resumed
Last night, I restarted the locking work.
Quite some time was wasted by the disconnected REFL199 by Alberto for the cavity length measurement.
From now on, please put the interferometer back to the original state every day.
If possible, please refrain from changing the IFO settings (cabling, optics, etc).
It is also very important to always restore the full IFO alignment after you are done with your work.

While I was working on the optimization of the DD hand-off, the DRMI alignment got into a strange state.
Even when I did the whole dither alignment procedure from the beginning (from x-arm), the AS166Q did not go above 1000.
PRMI looks ok (SPOB goes above 1100). I could lock the DRMI but the lock position hops to other modes easily.
Manual tweaks of SRM did not help.
After running the whole alignment procedure several times in vain, I was too tired and went home.
I noticed that the single arm lock shows power drops again. There are some offsets in the arm lock loops.
This may have prevented the Michelson alignment from being optimal. I will check this today.
  557   Tue Jun 24 15:15:09 2008 JohnSummaryLSCLocking efforts
Rob, Rana, John

In the past week or so we've been working on reducing the CARM offset using a DC signal (SPOB DC).
We were able to get up to arm powers of around 30 (where a single arm cavity lock is a power of 1)
before instability set in and we would lose lock for, as yet, unknown reasons.

In recent nights locking efforts have taken a few backward steps.

Since last Thursday engaging the AO path has proved troublesome, i.e. engaging it would instantly
cause loss of lock. This seems to be related to problems with the mode cleaner servo. For the past
few nights it has been behaving strangely and could not be operated with the usual super boost stages.
Last night the situation was improved. MC boost stages could be used and the AO path engaged. The
cause of this problem and its spontaneous resolution are not understood.

Last night we were unable to switch CARM to SPOB DC. I've attached a spectrum of the MC2 length signal.
This path is being used for CARM and so gives an indication of the frequency noise after the mode
cleaner. At the moment the plot is calibrated in units of Rana's gut feeling. We already tested to see if
any of the excess noise was introduced by the WFS. No evidence was found. We'll try to make a useful
calibration soon and see if our problems are related to excess frequency noise.

Another realisation from last night was the effect of arm detuning on the analogue CARM path. When CARM is detuned
the coupled cavity pole removes an extra 90 degrees of phase. The digital path has the `moving zero' to compensate
for this. The analogue path has no such compensation and can therefore become unstable at moderate detunings.
We propose trying to reduce the CARM offset further before engaging the analogue path. This will give higher
gain and move the UGF to a region of increased phase margin.
  11126   Tue Mar 10 03:37:03 2015 ericqUpdateLSCLocking efforts

[Q, J]

Not much luck locking tonight; we made the RF transition to CARM numerous times, but it never lasted more than a minute or so. We were able to take a couple of loop and spectrum measurements as we transistioned. 

Here are some spectra showing the noise evolution of CARM_IN1 and DARM_IN1 as we start to transition CARM to RF. We did not manage to grab spectra while CARM was RF only; we can go back in the DQ to find some data. 

As we transition, our phase bubble is shrinking, which may explain our poor stability. On the following plot, I actually mistyped the legend. The cyan trace is ALL RF. I'm not sure why we have a 1/f^2 shape from 100->200Hz. 


We adjusted the pole compensation frequency by looking at REFL11/ALS during a CARM swept sine measurement, the -3db/-45degree point looked more like 80Hz. Strangely, the compensated REFL11 signal appears to lag the ALS signal around the UGF. Maybe this is a loop effect? 

In terms of practical improvements, I've written a script that reliably transitions from POX/POY IR lock to ALS CARM/DARM lock already on resonance. This is saving us a bunch of time. I've svn'd the new ALS script and the new carm_cm_up that uses it. 

We looked into the odd oplev behavior as well. We had earlier seen what looked like railed values on the FM output medm screen (which seemed unexpected for an AC coupled loop), but dataviewer showed it was actually ringing/railing at some 10+Hz as the oplev beam fell off the QPD. The ringing continues even after the quadrant values stop crossing zero, so I think it may be the filters themselves misbehaving. Why there is new behavior here is still beyond me. 

We lost a fair bit of time to a fussy mode cleaner tonight; there was a good 45 minute stretch where it refused to lock for more than a minute or so, the PC drive angriliy never falling below 5. The thing I changed when it started working was using the fast C1:IOO-MC_F channel instead of the slow C1:IOO-MC_FAST_MON as a readback for the FSS input offset; oddly there is a DC difference between the two. This has resulted in a FSS offset of ~4.2, whereas it was previously ~1.8. After this change, the PC drive fell to ~1.0 levels, and the IMC has been mostly ok. 

Given our problems stabilizing the RF lock, we attempted to give the FOOL path a shot, since we now had a better idea of the neccesary REFL11 gain. In short, no luck. Every attempt to use some RF signal just disturbed the lock further. We didn't really pursue it too much after a couple of attempts showed little promise. 

ELOG V3.1.3-