Koji recommended that I can add whitening filters to suppress ADC noise easily. I added a filter before ADC in ALS loop with 4 zeros at 1.5 Hz and 4 poles at 100 Hz and added a reversed filter in the digital filter of ALS. This did not change the performance of the loop but significantly reduced the contribution of ADC noise above 1 Hz. One can see ALS_controls.yaml for the filter description. Please let me know if this does not make sense or there is something that I have overlooked.

Now, the dominant noise source is DFD noise below 100 Hz and green laser frequency noise above that. For DFD noise, I used data dating back to Kiwamu's paper. The noise contribution from DFD in the model is lower than the latest measured ALS noise budget post on elog. I'll look further into design details and noise of DFD.

Code, data, and schematics

Setting the record straight

I found out an error I did in copying some control model values from Kiwamu's matlab code. On fixing those, we get a considerably reduced amount of total noise. However, there was still an unstable region around the unity gain frequency because of a very small phase margin. Attachment 3 shows the noise budget, ALS open-loop transfer function, and AUX PDH open-loop transfer function with ALS disengaged. Attachment 4 is the yaml file containing all required zpk values for the control model used. Note that the noise budget shows out-of-loop residual arm length fluctuations with respect to PSL frequency. The RMS curve on this plot is integrated for the shown frequency region.

Trying to fix the unstable region

Adding two more poles at 100 Hz in the ALS digital filter seems to work in making the ALS loop stable everywhere and additionally provides a steeper roll-off after 100 Hz. Attachment 1 shows the noise budget, ALS open-loop transfer function, and AUX PDH open-loop transfer function with ALS disengaged. Attachment 2 is the yaml file containing all required zpk values for the control model used. Note that the noise budget shows out-of-loop residual arm length fluctuations with respect to PSL frequency. The RMS curve on this plot is integrated for the shown frequency region.

But is it really more stable?

• I tried to think about it from different aspects. One thing is sure that  remains greater than 1 in all of the frequency region plotted for. This is also evident in the common-mode to residual noise transfer function which shows no oscillation peaks and is a clean mirror image of the open-loop transfer function (See Attachment 1, page 2).
• Another way is to look for the phase margin. This is a little controversial way of checking stability. For clarity, the open-loop transfer function I'm plotting does not contain the '-1' feedback in it. So the bad phase value at unity gain frequency is -180 degrees (or 180 degrees) for us. I've taken the difference from the closest side and got 76.2 degrees of phase margin.
• Another way I checked was by plotting a Nyquist plot for the open-loop transfer function. It is said that if the contour does not encircle the point '-1' in the real axis, then the loop would be stable even if the where is the frequency where phase lag becomes -180 degrees at the lowest frequency. For us, is at 1 Hz because of the test mass actuator pole. But I have verified that the Nyquist contour of the open-loop transfer function does not encircle '-1' point. I have not uploaded the Nyquist plot as it is not straight forward to plot. Because of large dc gain, it covers a large region and one needs to zoom in and out to properly follow what the contour is really doing. I didn't get time to make insets for it.

Is this close to reality?

For that, we'll have to take present noise source estimates but Gautum vaguely confirmed that this looked more realistic now 'shape-wise'. If I remember correctly, he mentioned that we currently can achieve 8 pm of residual rms motion in the arm cavity with respect to the PSL frequency. So we might be overestimating our loop's capability or underestimating some noise source. More feedback on this welcome and required.

Additional Info:

The code used to calculate the transfer functions and plot them is in the repo 40m/ALS/noiseBudget

Attachment 5 here shows a block diagram for the control loop model used. Output port 'Res_Disp' is used for referring all the noise sources at the residual arm length fluctuation in the noise budget. The open-loop transfer function for ALS is calculated by -(ALS_DAC->ALS_Out1 / ALS_DAC->ALS_Out2) (removing the -1 negative feedback by putting in the negative sign.) While the AUX PDH open-loop transfer function is calculated by python controls package with simple series cascading of all the loop elements.

I think the digital loop in the ALS budget is too optimistic. You have to include all the digital delays and anti-aliasing filters to get the real response.

aslo, I recommend grabbing some of the actual spectra from the in-lock times with nds and using the calibrated spectra as inputs to this mode. Although we don't have good models of the stack, you can sort of infer it by using the calibrated seismometer data and the calibrated MC_F or MC_L channels (for IMC) or XARM/YARM signals for those.

This is not a reply to comments given to the last post; Still working on incorporating those suggestions.

Trying out a better filter from scratch

Rana suggested looking first at what needs to be suppressed and then create a filter suited for the noise from scratch. So I discarded all earlier poles and zeros and just kept the resonant gains in the digital filter. With that, I found that all we need is three poles at 1 Hz and a gain of 8.1e5 gives the lowest RMS noise value I could get.

Now there can be some practical reasons unknown to me because of which this filter is not possible, but I just wanted to put it here as I'll add the actual noise spectra into this model now.

Few questions:

• What anti-aliasing filters are used in ALS?
• Is the digital delay fixed to a constant upper limit or is it left to change as per filters? I have already used a 470 us delay (modeled with Pade 4th order approximation).
• I could not find a good place where channel names are listed with corresponding meaning. Where can I find them?
• Is there a channel which keeps a record of lock status? In short, how do I find the in-lock times

This ALS loop is not stable. Its one of those traps that comes from using only the Bode plot to estimate the loop stability. You have to also look at the time domain response - you can look at my feedback lecture for the SURF students for some functions.

Yes, that loop was unstable. I started using the time domain response to check for the stability of loops now. I have been able to improve the filter slightly with more suppression below 20 Hz but still poor phase margin as before. This removes the lower frequency region bump due to seismic noise. The RMS noise improved only slightly with the bump near UGF still the main contributor to the noise.

For inclusion of real spectra, time delays and the anti-aliasing filters, I still need some more information.

Few questions:

• What anti-aliasing filters are used in ALS?
• Is the digital delay fixed to a constant upper limit or is it left to change as per filters? I have already used a 470 us delay (modeled with Pade 4th order approximation).
• I could not find a good place where channel names are listed with corresponding meaning. Where can I find them?
• Is there a channel which keeps record of lock status? In short, how do I find the in-lock times

Additional Info:

The code used to calculate the transfer functions and plot them is in the repo 40m/ALS/noiseBudget

Related Elog post with more details: 40m/15587

Before starting to move things around the PSL table, I measured the ALS out of loop noise for reference. The noise spectrum showed excess noise around 30Hz.  The traces in blue were taken before I went in and those in red were taken after my work.

I also looked at the power spectrum of LSC-TRY_OUT to see if the noise is from the IR lock itself and there was nothing suspicious with it. 

Since the green transmission was 50% lower than the usual, I touched the steering mirrors for green at the Y end table to get a better transmission and beat signal. The noise still hasn't disappeared. 

I am not sure if this could be from our neigbors who have been running rock experiments since morning. We should check back to see if this noise disappears once they shut down.

DTT xml files are available in directory /users/manasa/data/150109/

I have noticed that ALS noise has been at 1KHz rms since LSC arm lock servos have been used to lock arms using ALS error signals. May be this has not been given much attention.

But looking more closely at the ALS noise (better dtt resolution for noise power spectrum) , there seems to be too much noise suppression at <1Hz and not much happening at around 10Hz.

Attachment 1 (data files at /users/manasa/data/140421/)

So I made a bunch of transfer function measurements for ALS and phase tracker servo. Koji will be using these and redesigning the servo filters so that we can get more suppression at 10Hz.

Other than this I also found that the Y arm showed more high frequency noise as compared to the X arm. (Edit by manasa: Thinking back now, this could be related to the onset of 60Hz noise at the Y end elog 9838. But still has to be looked at after fixing TRY)

Attachment 2

Tip: Once the arms are ALS locked, enabling the SLOW_SERVO helps hold the lock stably. 

P.S. I realigned the Y green to the arm and brought GTRY to 0.93

To do:

Find out what makes Y arm in-loop noise at high frequency higher than X arm.

 I am working on the basic ALS servo model. The simulink model for the same is attached. The loop is not yet complete (I'm still debugging it) ; but this is just an update of where I am right now.

Attached is the simulink and matlab file. 

Renaming of the c1gcv model earlier (elog 7011) had left white boxes in most of the ALS medm screens.

Channels names were corrected. No more white boxes.

I'm really excited, so I'm posting this, even though I'm still working:

I currently have ALS locked using the LSC system, and have (by hand, coarsely) found IR resonance!  Hooray!

I looked at my error signals, as well as LSC-XARM_IN1 with dataviewer, and noticed that the XARM_IN1 signal was crazy when I was using the ALS signal as the error.  I soon realized that this is because there was a non-zero element in the power normalization matrix, and I'm overriding the trigger.  So, I was trying to divide by zero, and was getting crazy numbers.  After zeroing the power normalization matrix element for the Xarm, the XARM_IN1 signal matched the ALSX_OUT, and I was easily able to acquire lock.

I had already re-transferred over the ALS versions of the filters, so that's what I'm using right now.  Next up (on a 5 minute time-scale) is trying to acquire lock using the regular LSC filters. 

Oh, also, something I hadn't thought of before dinner:  I am setting the offset of the ALSX filter bank such that the output is centered around zero, so that I can lock, since these are not AC coupled servos.

Great. I indeed disabled all of the triggers and the normalization during my trial but in vain.
So I'm curious this is actually because of the filter shape or not.

I am also not able to lock the ALS using the 'regular' LSC filters.  To figure out what filters were doing what, I made several comparison plots from Foton.

The first one is the progression of ALS locking, using the filters from ALS-XARM.  FM5 is always engaged, then FMs 2, 3, 6, 7, and 8, and finally FM 10 (the low frequency boost) is engaged.

The next plot is a comparison between the ALS version of the filters, and the LSC-XARM equivalents. 

Finally, just so I remember which LSC filters do what, I made an equivalent of the first plot, but for the LSC filters.

When I try to lock the Xarm ALS using the regular LSC filters, I'm getting an oscillation somewhere, that grows and eventually knocks me out of lock.  It looks from dataviewer to be in the ~few Hz range, but it's hard to see it in DTT, since I don't stay locked all that long once the oscillation starts.  (If I catch it, I can back off the gain and turn off the servo without losing lock, but if I don't turn off the servo, I inevitably push the ETM too hard and lose green lock to the arm.)  I tried engaging the 3.2 Hz resonant gain filter, and it just makes things oscillate sooner, so that's not a solution with the current filter designs. 

Also, I'm not able to lock the IR using the ALS version of the XARM filters.  I'll have to meditate more on the situation, but the filters seem to be different enough that there's no crossover at this point.

No more progress tonight.  I am still unable to lock the ALS using the regular LSC filters.  I went back to putting the ALS filters into the LSC filter banks, and locked both arms with ALS, and found their IR resonances. I then held them off resonance, and tried to lock PRMI with REFL 55 I&Q, with no success.  Just before locking the arms, I had redone the whole IFO alignment (lock arms in IR, ASS, lock and align MICH, lock and align PRMI), and the PRMI was flashing very nicely.  I'm not sure why I wasn't able to catch lock, except that perhaps 3 or 6 ALS offset counts isn't far enough away from the IR resonance to make the 1f signals happy. The MC lost lock, which I then took as a sign that it's time to go home. (I was hoping to do a quick PRMI + 2arms, and see that we don't lose PRMI lock.  I was going to catch lock with REFL55, then transition to REFL33, although if I had thought about it before the MC lost lock, I would have tried just catching lock with REFL33).

I restored the regular LSC filters for the X and Y arms, and locked the arms in IR just to make sure it's all honkey-dory.  Which, it's not quite.  I don't know why, but right now, neither arm wants its boost (FM9) enabled.  It's part of the restore script that FM9 is triggered along with the rest of the filters, but even if I turn on the filters manually, I can turn on all but FM9, and then when I turn on the boost, the arm falls out of lock. Same behavior for both arms.  Anyhow, they lock, and they seem okay modulo the boost not being able to engage.

[Jenne, Koji, Manasa, EricQ]

Today we successfully locked the ALS using the LSC system, with filters that are good for both the IR PDH and the ALS locking.  We tried PRFPMI, but were unable to hold PRMI lock while the arms were held with ALS.  We combined the ALS signals into common and differential signals, and successfully transitioned over to a combined set of 1/sqrt(TRANS) signals for the common mode part of the lock (differential stayed with ALS). 

Locking the ALS using filters in the LSC system that are also good for IR PDH

The biggest difference between the ALS and LSC filters were the ones used for lock aquisition. At Koji's suggestion, I made FM5 of the LSC servos (for X and Y arms) the filter needed for ALS locking.  Then, I made FM4 into a combination of old LSC FM4 and FM5, as well as an inverse of the new FM5, so that when both FM4 and FM5 are engaged, the servo shape is the same as the old LSC.  I left the other LSC filters where they were.  I replaced the FM1 +6dB with the combined integrators (really, just gentle DC boosts) for the ALS, since we were never using this +6dB filter module.  The LSC resonant gain filter for the bounce mode also included a resgain for 18.5 Hz.  I don't know what that was for, and it was eating into phase that I needed, so I removed it.

The other filter that changed significantly was the Boost filter.  The ALS system had been using more DC gain than the LSC had.  However, the current ALS boost filter (in FM10 of the old ALS servos) was eating too much phase near my UGF.  So, I scooted the whole boost filter to lower frequencies, to give myself some extra phase margin.  The boost was set to "zero history", "zero crossing", with 0.01 tolerance and an 8 second timeout.  Setting it to zero crossing with a low tolerance, rather than just ramping it on, was the key to engaging the boost.

I had to be so careful about phase margin, since I lost ~15 degrees of phase at 200 Hz from the lag of going through the RFM network.  This was pretty frustrating, but I don't have a better plan yet, save moving the c1als model and ADC to the SUS machine, which has Dolphin access to the LSC.  I may back off my safety margin, and give myself some gain in the boost back at 10Hz, since we are now seeing too much noise at 10Hz in the closed-loop spectra.  I also "cheated" and lowered my UGF from the ~150Hz it used to be in the ALS model, to 100Hz, where I was closer to the top of the new phase bubble.

With the new filter situation, I was able to lock the Xarm (the one I was using for design work) with both IR and ALS.  To lock IR, the "restore" script still works. For the ALS, we should put in a separate "restore" script into the IFO_CONFIGURE screen. 

The ALS locking procedure is as follows:

* Prepare ALS and green locking.  Green locked to 00 mode, alignment all nice, etc, etc.  Beatnote within 100MHz on spectrum analyzer.  If doing both arms, try to get beatnotes on opposite sides of PSL, to keep crossbeatnotes at higher frequencies, and out of the way.

* Turn on Watch script.

* Set LSC parameters (this is where a new restore script will come in handy): 

       * Zeros in RFPD columns of input matrix (i.e. POX and POY).

       * Ones in AUX input matrix elements.

       * Zeros in power normalization matrix rows for arms.

       * All FM triggers for arms set to "Man" for manual.

       * Override main trigger, so that signals are always going through to the servo.

       * Only FM5 engaged in arm servo.

       * Gain of servo set to zero, output on, then engage main LSC master switch.  ETM output on.

* Clear history in phase tracker.

* Check sign of gain using + or - 0.1 in the servo.  You'll know if you got it wrong (the ETM will be kicked, and the beatnote will fly around).  If you didn't get it wrong, you probably got it right.

* Increase gain to about 12 (with correct sign).

* Engage FM1 (gentle DC boost), FM6,7,8 (resonant gains for stack, bounce, roll)

* Wait a few seconds for filters to settle, then engage FM9 (boost).

* Run find IR resonance script.

* Move off resonance by ~36 counts (12 times the +3 script).  This number comes from trying to be completely off the IR resonance, even when the PRMI was locked.

* Do whatever locking (ex. PRMI) you set out to do.

 PRFPMI attempt

After locking both arms with ALS using the LSC system, we attempted to lock the PRMI.  We were able to lock PRMI on REFL55 I&Q, REFL33 I&Q, and REFL55 I&AS55Q before the arms were locked, so we were hoping that we wouldn't have too much trouble.

We found the IR resonance for both arms, then moved off resonance.  Then, restored the PRM.  For REFL55, Koji coarsely turned the REFL 55 demod phase from 16 degrees to 87, while we were locked on the carrier.  After this, I stepped farther and farther from the IR resonance, since at first I found that our transmitted powers were something like 4, rather than almost zero, so the demod phase may not be totally correct.  

We were having trouble, so we locked the PRMI on carrier using REFL55 I and AS55 Q, with 1's in both elements in the input matrix.  MICH gain was about -10, PRCL +0.010.  We used this time to tweak up the alignment of the PRMI.  At some point, Koji tweaked the REFL33 demod phase from 124 to 134 degrees.  Then we switched back to sideband locking.  After some trials with REFL55 I&Q, and REFL55/AS55, we went to REFL33 I&Q.  REFL33I->PRCL was 1.556 in the input matrix, and REFL33Q->MICH was -0.487.  No other elements in the input matrix.  MICH gain was reduced to -6, PRCL gain to -0.020.  MICH FMs 3,6,9 triggered, PRCL FMs 2,3,6,8,9 triggered.  We were able to keep short locks on the order of ~10 seconds, but not longer. We played with every parameter we could think of (alignment being good is one of the most important!), but were not able to keep better lock.  The POP spot is moving around a lot, so the PRCL ASC needs to be examined, hopefully tomorrow.

We started losing the Xarm lock fairly regularly, I'm not sure why, but the Yarm was locked for almost 2 hours straight, held off resonance with ALS!

 ALS Common and Differential, transition to IR control

We set PRMI aside for the rest of the night, and looked at using ALS to control the arms in common and differential modes. 

Regular ALS locking procedures were used (see above), with the exception of the AUX input matrix:

 Since the beatnotes were on opposite sides of the PSL frequency, the common and differential modes look opposite of what you'd expect. 

We then used the regular find IR resonance scripts running simultaneously, which worked really well to find both arms' IR resonance points.

I put a 1 count offset in the Xarm servo (which was our proxy for common mode), although in retrospect this should have been +0.5 in ALSX, and -0.5 in ALSY, so that our signals going through the input matrix were at their zero crossings.  Anyhow, this offset put us at about half fringe on both arms (transmissions were about 0.6). 

Koji set the offsets in the 1/sqrt(trans) filter banks before the input matrix so that they would have zero crossings at this point (avg the IN1, put negative of that value into the offset). 

We then stepped the input matrix values until our common mode (Xarm) row was:

We left the differential (YARM) row alone, so that the ALS system would still be controlling the differential degree of freedom.  The values and sign for the 1/sqrt(trans) signals came from a transfer function of dividing the spectra of each error signal and noting the relative gain and sign.

After we swapped the error signals, we realized that we had to remove the offset from the XARM servo, which is why we should have put the offsets elsewhere in the first place.

Then, Koji took a spectrum, which is attached to this entry.  We note that the ALS signals are strongly correlated, and mostly common. 

To Do List

Going forward, we need to figure out what is going on with the PRMI, and why we're having trouble keeping lock.

We need to redo the PRCL ASC servo, with the anti-oplev trick that Rana mentioned a week or two ago.

We need to investigate the degeneracy of REFL165, now that Q's simulation doesn't justify / explain it. 

The Xarm ALS has been a little funky today. 

First, the green and the arm-axis would not stay co-aligned.  I'm not sure which was moving (although neither ITMX nor ETMX seemed to be moving very much according to their oplevs and OSEMs).  I went to the Xend table and jiggled the mounts for the steering optics, in case one was loose or something.  None were.  However, the transmission quit jumping around by a factor of 2 after that.   The beatnote alignment on the PSL table was also bad, so I tweaked that alignment up for the Xarm.  There were some not connected cables and fibers blocking the access to the X beatnote area, so those are up on top of the PSL table.

Anyhow, I haven't locked the individual arms, but I cannot hold the lock with CARM/DARM.  The CARM output keeps hitting the threshold for the locking watchdog, which turns off the lock.  Obviously I could just increase this threshold, but the right thing to do is figure out why the Xarm ALS is so noisy today, and why it wants to output such a large control signal to maintain the lock.

The ALS system is iffy tonight.

After putting the cable back to the RF spectrum analyzer (it had been taken to test the frequency counter setup, and not put back), I had a good Yarm beatnote, but again this evening the Xarm beatnote is small.  I touched up the PSL table alignment (very, very little needed, but it did double my peak height).  I *think* that this is happening because we haven't settled into a good IFO alignment place, so the arm pointing keeps changing very slightly, which means that the PSL ALS alignment needs touching.  Anyhow, even after alignment the Xarm beatnote is only -36 dBm at 81 MHz.  It should be at least -25 dBm or so, although I haven't seen it any larger than about -35 dBm since the IFO beam was lost last Friday.

I am not able to hold ALS lock long enough to scan the arms and find the IR resonances.  The only optics that I am actuating on this evening are the 2 ETMs.  When I lose lock and look at the watchdogs, the ETMs are the only optics that have largeish numbers, which comes from the ALS lockloss.  So, I don't think I am suffering from the ITM suspension kicks tonight.  Rather, I think that it's that the ALS system isn't tuned up nicely.

I think that it is past time we tuned up and checked out the ALS PDH setup.  Q:  Can you please measure the loop TFs for both of the ALS PDH boxes tomorrow?  At the very least we want to know what we're working with. 

Evan:  What is the status with the ISS? 

I am going to try tomorrow to look at the suspensions, and see if I can track anything down.  I feel like I see the kicks more often when the arms are locked, i.e. we are sending an LSC signal to them.  The LSC POS signal is a factor of a few hundred larger than the damping SUSPOS signal is.  Are we saturating something somewhere?  Why is this a new thing?  We certainly do see kicks when the LSC is not engaged, so this may not be the right path, but it is something concrete to look at.

 Not sure why, but Rana and I didn't see the super high Xarm noise with ALS that we reported last night (elog 10382).  

The in-loop ALS noise seems fine.  The out of loop measurement while the ALS is locked is a little tricky, since ALS hold the arms within the POX/POY linear ranges.  

Here is the in-loop noise:

 As I was trying to solve the 2 arm ALS problem, I found the Y arm ALS not so stable AGAIN :( . I measured the in-loop noise of the X arm as ~400Hz/rtHz (60 picometers).

I went ahead and checked the out of loop noise of the ALS and found there is some high frequency noise creeping in above 20Hz for the Y arm ALS (blue curve). I checked the UGFs and phase margins of the phase tracker loops and found they were good (UGF above 1.4KHz and phase margins between 40 and 60 degrees).

So the suspect now is the PDH servo loop of both the arms which has to be checked.

Attached is the out-of loop noise plots of X and Y arm ALS.

I discussed with Yuta about the ALS servo and phase tracker and found that there was a lot of information lying around from last year but there aren't any clear elogs on how to enable ALS and obtain IR resonance.

Guide to enabling the ALS servo and find IR resonance:

The steps will explain in detail how to ressurrect the ALS servo for green X-arm and find IR resonance using ALS. The medm screens are very confusing right now.

(i) Finding the beat note

1. Get the IR to flash in TEM00 for the arm and lock it by enabling LSC (Locking the arm to IR keeps the arm cavity mirrors stable so that you can scan the temperature of the X-end laser to find the beat note).

2. Steer the X-green into the arm cavity such that the arm cavity locks in TEM00 for green as well. At this point you should also have the X-green reaching the PSL table.

3. Align the PSL doubled green (PSL-green) and the X-green in near-field (at the camera) and far-field (letting the beams to propagate beyond the Green-TRX PD).

4. Check cabling of the RF beat PD.

5. Change the X-laser temperature by sweeping the offset (C1: ALS-SLOW_SERVO2_OFFSET) in steps of 10.

6. Find the beat note and tune the alignment at the beat PD to maximize the beatnote amplitude. Disable LSC for X arm.

(ii) The GREEN HORNET explained

'Input signal conditioning' block takes I and Q signals after the delay frequency discriminator (DFD) in the beat box and these signals pass through C1ALS_BEATX_FINE filter banks. The output signal then enters the phase rotation matrix of the phase tracker. The phase tracker gives 'PHASE_OUT' which is the error signal that is fed to the ETM servo filter module (DOF filters)  through the 'Input matrix' in the medm. 

An offset can also be fed to the phase tracker which will scan the beat frequency (used to find IR resonance).

(iii) Scripts

1. easyALS.py - This runs from 'ON plus' or 'ON minus' buttons in the C1ALS_COMPACT. 

The script clears history of 'fine_phase' filter module and increases gain of the servo in steps ('ON plus' for positive gain and 'ON minus' for negative gain).

2. findIRresonance.py - This runs from 'IRres' button in the C1ALS_COMPACT.

It adds offset to the phase tracker in steps which scans the beat frequency to find IR resonance.

P.S. Check the scripts before enabling the servo so that the right filter modules are being turned ON. Using the wrong set of filter modules can kick the ETM.

____________________________________________________________________________________________________________________________________________________

X arm ALS progress:

I found the beat note and got ALS to work reasonably for the Xarm without kicking the ETM. I did this by manually toggling buttons and changing gains. The scripts need editing.

To do:

Modify the scripts to work as we want them to.

The ALS medm is SSSOOOO confusing. It definitely needs to be fixed (remove all unwanted parts of the screen that existed 'pre-phase tracker').

Find IR resonance.

I have measured very, very carefully the transfer function from pushing on MC2 to the Yarm ALS beatnote.  In the newest loop diagram in http://nodus.ligo.caltech.edu:8080/40m/11030, this is pushing at point 10 and sensing at point 4. 

Since it's a bunch of different transfer functions (to get the high coherence that we need for good cancellation to be possible), I attach my Matlab figure that includes only the useful data points.  I put a coherence cutoff of 0.99, so that (assuming the fit were perfect, which it won't be), we would be able to get a maximum cancellation of a factor of 100. 

This plot also includes the vectfit to the data, which you can see is pretty good, although I need to separately plot the residuals (since the magnitude data is so small, the residuals for the mag don't show up in the auto plot that vectfit gives). 

If you recall from http://nodus.ligo.caltech.edu:8080/40m/11020, we are expecting this transfer function to consist of the suspension actuator (pendulum with complex pole pair around 1Hz), the ALS plant (single pole at 80kHz) and the ALS sensor shape (the phase tracker is an integrator, with a boost consisting of a zero at 666Hz and a pole at 55Hz).  That expected transfer function does not multiply up to give me this wonky shape.  Brain power is needed here.

Just in case you were wondering if this depends on the actuator used (ETM vs MC2), or IFO configuration (single arm vs. PRFPMI), it doesn't.  The only discrepancy between these transfer functions is the expected sign flip between the MC2 and ETMY actuators.  So, they're all pretty consistent. 

Before locking the PRFPMI, I copied the boost filter (666:55) from the YARM ALS over to Xarm ALS, so now both arms have the same boost.

YARM_actTF_compareActuators.pdf

Things to do for ALSfool:

• Put fitted TF into the MC_CTRL_FF filter bank, and try to measure the expected cancellation, a la http://nodus.ligo.caltech.edu:8080/40m/11009
• Quick test with single arm, ALS locked using full loop (high gain, all boosts), since the previous versions were with ALS very loosely locked.
  • Does this measured transfer function actually give us good cancellation? 
• Think.  Why should the transfer function look like this??
• Try it on the full PRFPMI

Wonkey shape: Looks like a loop supression. Your http://nodus.ligo.caltech.edu:8080/40m/11016 also suggests it too, doesn't it?

Dang it, yes. You're right.  I should have caught that. 

Since Dcpl and Srefl are both zero during the measurement (since it was an ALS lock), this is actually

So, I need to remove the effect of the ALS closed loop, to get the actual quantity I was looking for.

I re-did the Mathematica notebook according to the most current diagram (note to daytime self: attach .nb file!!!), and found that the denominator has changed, such that plugging in the new D=-A_refl*P_als*S_als gives the same

full-system closed loop gain of   

where   is the open loop gain, and the * indicates either the REFL or ALS portions of the system. 

I have also plotted some things with Matlab, although I'm a little confused, and my daytime self needs to spend some more time thinking about this.

In the actuators (both for REFL and ALS), I include a pendulum, the digital anti-imaging filters that let us go from the 16kHz model to the 64kHz IOP and the analog anti-imaging filters after the DAC.  Note to self:  still need to include violin filters here.

For the servo gains, I copy the filters that we are using from Foton, and give them the same overall gain multiplier that is in the filter bank.  For the ALS going through the CARM filter bank, this is FMs 1, 2, 3, 5, 6 with a gain of 15.  For the RF (actually, POY here) going through the MC filter bank, this is FMs 4, 5, 7 with a gain of 0.08. 

For the plants of each system, since this is still single arm lock, I just include a cavity pole (80kHz for ALS, 18kHz for REFL). 

In the sensors (both for REFL and ALS), I include the analog anti-aliasing as well as the digital anti-aliasing to allow us to go from the 64kHz IOP to the 16kHz front end system.  For the ALS I also include in the sensor the closed loop response of the phase tracker loop (H/(1-H), where H is the open loop gain of the phase tracker).  For both sensors, I also include a semi-arbitrary number to make the full single-loop open loop gain have a UGF of 200Hz.  In the ALS sensor, I also include a minus sign to make the full open loop gain have the correct phase.

Here I plot the open loop gains of the individual single loops, as well as the open loop gain of the full system (Hals + Hrefl - Hals*Hrefl).  I feel like I must be missing a minus sign in my ALS loop, but I don't know where, and my nighttime brain doesn't want to just throw in minus signs without knowing why.  That will affect how the final ALSfool (blue trace) looks, so maybe it's not really as crazy as it looks right now.

Also, I was trying to explain to myself why we are getting the shape that we are in our measurements of the cancellation (http://nodus.ligo.caltech.edu:8080/40m/11041).  But, I can't.  Below are the plots of the transfer functions from either point 9 or 10 (before or after the G_refl) to point 5, which is the ALS error point.  The measurement in elog 11041 should correspond to the blue trace here.  For these traces, the decoupling is set to just (-A_refl), although there aren't any noticeable changes in the shape if I just set D=0.  If we start with the assumption that D=0, the shape and magnitude are basically identical to this plot, and then as we make D=-A_refl P_als S_als, the transfer functions both go to zero. 

So.  Why is it that with no decoupling, the transfer function from 10 to 5 is tiny?  Why do the shapes plotted below look nothing at all like the measured cancellation shape?  Daytime brain needs to think some more.

Here is an updated cartoon, with the ALS sensor explicitly shown as the beatbox times the closed loop response of the phase tracker servo. 

The most important transfer functions are written on the diagram.  Others can be extracted from the attached Mathematica file (which corresponds to this diagram).

The ALS fool scheme is now diagrammed up in OmniGraffle, including its new official icon.  The mathematica notebook has not yet been updated.

EDIT, JCD, 17Feb2015:  Updated cartoon and calculation: http://131.215.115.52:8080/40m/11043

[Jenne, EricQ]

We tried several times tonight to engage the Fool path with the PRFPMI.  No success. 

First, we locked the arms on ALS, in CARM/DARM mode, and measured the cancellation ability, to make sure that the filter shape and gain was set correctly.  For the PRFPMI, it was okay using the same shape as the single arm case, but the gain was +20.0.  There might be a bit more cancellation to be gained if we adjust the shape at the ~1dB level, but we're already able to get 20dB of cancellation, so we decided that would be enough to give things a try.  To get this much cancellation, we set the phase tracker loops to both have 2kHz UGFs, almost exactly.  We should implement a UGF servo, or the amplitude method version of that as Koji suggested ages ago, so that the phase tracker is always at the same place.

I don't think that REFL 11 is seeing as much CARM as I expect.  We ended up switching over to linearized REFL55 for our attempts.  When we're close to zero CARM offset, the arms are constantly flashing through resonance, and we get the loud buzzing.  REFL11 doesn't seem to see any of this, even though we should be close enough to see some PDH action.  REFL55 does change as we get closer to resonance, so I think it's seeing some real CARM stuff.

We tried engaging the Fool, but I don't think it did anything too useful. We need to make an estimate of what we expect our gain of the REFL loop to be - or at least the sign.

The PRMI is still not stable enough.  It keeps falling out of lock when we get to high-ish arm powers.  Not good.  More brain power tomorrow on the modulation cancellation issue. 

Perhaps if things are stable at moderate arm powers, we can use an excitation to line up the ALS vs. REFL error signals, and then watch the noises of them change as we move around in CARM offset.  This should tell us when the linearized REFL signal is quiet enough that it's worth triggering and trying to transfer over.

The last lockloss tonight, there was something funny going on, that we can't explain.  Even though both arms were locked on the CARM/DARM combined ALS signals, beatx doesn't see the giant oscillation that causes carm to lose lock until much later.  Fool was trying to do something, but that should affect both als individal signals in the same way.  Mystery.

Leaving a note on the ALS feedback before I forget:

The MC2 suspension needs to have an input for the ALS feedback in the realtime model like ETMs.

I added an ALS feedback path on the MC2 suspension and this path will enable us to stabilise the MC length using the ALS scheme.

[Koji, gautam]

Summary:

We think we got to the bottom of this issue today. The RF signal level going into the demod board is too high. This electronics chain needs some careful gain reallocation.

Details:

I was demonstrating to Koji a strange feature I had noticed in the ALS control, whereby when applying a CARM offset to detune the arms, the two arms seemed to respond differently (based on the transmission levels). This kind of CARM-->DARM coupling seemed strange to me. Anyway, I also noticed that the EPICS indicators on the ALS MEDM screen suggested ADC saturations were going on. I had never really looked at the fast time series of the inputs to the phase tracker servos, but these showed saturating behavior on ndscope traces. I went to the LSC rack and measured these on a scope, indeed, they were ~20V pp.

The output of the BeatMouth PDs are going to a ZHL-3A amplifier - we should consider replacing these with lower gain amplifiers, e.g. the Teledyne AP1053. This is relegated to a daytime task.

Other findings tonight:

While working on the PSL table, I somehow put the IMC FSS into a bad state, reminiscent of this behavior. Seems like this is linked to some flaky connection on the PSL table. One candidate is the unstable attachment of the Pomona box between the NPRO PZT and the FSS output - we should install a short BNC cable between these to avoid the lever arm situation we have right now.

[steve, gautam]

We installed some rails to mount the 2U chassis containing ~100m of delay line cabling, and the 1U chassis containing the FET demodulators for the ALS signals in the LSC rack. This has made it MUCH easier for a single person to work there and remove/reinstall these chassis. The delay line box has 100m of cable inside it, and so was rather heavy (~8kg) - previously, it was being supported only by a pair of brackets on the front, so the new arrangement is much more robust. Steve is looking into acquiring plastic spacers of the appropriate width, so that we can secure the units to the rack using usual rack mount screws (but the material of the newly installed rails and the screw heads holding them in place necessitate this plastic spacer). 

Delay line box has been re-installed, demodulator chassis has been removed by me for characterization. Steve will put up photos once the units are re-installed.

For this work, I had to disconnect a bunch of cabling, but only those connected to ALS. All cables were labelled, and I will re-connect them once I am done with the demod chassis.

 I modified the ALS down script. When  the value of  C1:ALS-X(Y)ARM_OUT  becomes larger than the threshold, it turn off the output ON/OFF switch immediately. That is because the ALS servo has ramp time. When script changes the gain to 0, it takes some seconds. That is not good for suspensions.

 After changing servo gain to 0 and turning off the filters, the script waits ramp time and turn on the servo output switch.

I wrote the down script for ALS. This script is  (script)/ALS/ALSdown.py When this script is running, it watches the feedback signal of the ALS control loop so as to shut down the servo immediately when  the suspension is kicked. 

When  the value of  C1:ALS-X(Y)ARM_OUT  becomes larger than the threshold (right now it is 4500 counts), it changes the servo gain to 0, turns off all filters except for FM5 (the filter for phase compensation), resets the history of the phase tracker of each arm and prints the time on window when the suspension kicked

I put the switch on the C1ALS screen, and if you push this switch the window will open (like when you turn on the c1ass script) and the script start to run. For stopping this script, you have to close that window or press Ctrl + C on that window. This is little bit inconvenient, but we will make autolocker script for ALS and this downscript will be included that script soon. So I think it is enough to protect the suspensions right now.

Summary:

Last year, I worked on the ALS delay line electronics, thinking that we were in danger of saturation. The analysis was incorrect. I find that for RF signal levels between -10 dBm and +15 dBm, assuming 3dB insertion loss due to components and 5 dB conversion loss in the mixer, there is no danger of saturation in the I/F part of the circuit.

Details:

The key is that the MOSFET mixer used in the demodulation circuit drives an I/F current and not voltage. The I-to-V conversion is done by a transimpedance amplifier and not a voltage amplifier. The confusion arose from interpreting the gain of the first stage of the I/F amplifier as 1 kohm/10 ohm = 100. The real figures of merit we have to look at are the current through, and voltage across, the transimpedance resistor.  So I think we should revert to the old setup. This analysis is consistent with an actual test I did on the board, details of which may be found here.

We may still benefit from some whitening of the signal before digitization between 10-100 Hz, need to check what is an appropriate place in the signal chain to put in some whitening, there are some constraints to the circuit topology because of the MOSFET mixer.

One part of the circuit topology I'm still confused by is the choice of impedance-matching transformer at the RF-input of this demod board - why is a 75 ohm part used instead of a 50 ohm part? Isn't this going to actually result in an impedance mismatch given our RG405 cabling?

Update: Having pulled out the board, it looks like the input transformer is an ADT-1-1, and NOT an ADT1-1WT as labelled on the schematic. The former is indeed a 50ohm part. So it makes sense to me now.

Since we have the NF1611 fiber coupled PDs, I'm going to try reviving the X arm ALS to check out what the noise is after bypassing the suspect Menlo PDs we were using thus far. My re-analysis can be found in the attached zip of my ipynb (in PDF form).

Summary:

The restoration of the delay-line electronics is complete. The chassis has not been re-installed yet, I will put it back in tomorrow. I think the calculations and measurements are in good agreement.

Details:

Apart from restoring the transimpedance of the I/F amplifier, I also had to replace the two differential-sending AD8672s in the RF Log detector circuit for both LO and RF paths in the ALS-X board. I performed the same tests as I did the last time on the electronics bench, results will be uploaded to the DCC page for the 40m version of the board. I think the board is performing as advertised, although there is some variation in the noise of the two pairs of I/Q readouts. Sticking with the notation of the HP Application Note for delay line frequency discriminators, here are some numebrs for our delay line system:

•   - measured by driving the LO/RF inputs with Fluke/Marconi at 7dBm/0dBm (which are the expected signal levels accounting for losses between the BeatMouth and the demodulator) and looking at the Vpp of the resulting I/F beat signal on a scope. This is assuming we use the differential output of the demodulator (divide by 2 if we use the single-ended output instead).
•  [see measurement]
•  (to be confirmed by measurement by driving a known FM signal with the Marconi)
• Assuming 1mW of light on our beat PDs and perfect contrast, the phase noise due to shot noise is which is ~ 5 orders of magnitude lower than the electronics noise in equivalent frequency noise at 100 Hz.
• The noise due to the FET mixer seems quite complicated to calculate - but as a lower bound, the Johnson current noise due to the 182 ohms at each RF input is ~ 10 pA/rtHz. With a transimpedance gain of 1 kohm, this corresponds to ~10 nV/rtHz. 

In conclusion: the ALS noise is very likely limited by ADC noise (~1 Hz/rtHz frequency noise for 5uV/rtHz ADC noise). We need some whitening. Why whiten the demodulated signal instead of directly incorporating the whitening into the I/F amplifier input stage? Because I couldn't find a design that satisfies all the following criteria (this was why my previous design was flawed):

1. The commutating part of the FET mixer must be close to ground potential always.
2. The loading of the FET mixer is mostly capacitive.
3. The DC gain of the I/F amplifier is low, with 20-30dB gain at 100 Hz, and then rolled off again at high frequencies for stability and sum-frequency rejection. In fact, it's not even obvious to me that we want a low DC gain - the quantity  is directly proportional to the DC transimpedance gain, and we want that to be large for more sensitive frequency discriminating.

So Rich suggested separating the transimpedance and whitening operations. The output noise of the differential outputs of the demodulator unit is <100 nV/rtHz at 100 Hz, so we should be able to saturate that noise level with a whitening unit whose input referred noise level is < 100 nV/rtHz. I'm going to see if there are any aLIGO whitening board spares - the existing whitening boards are not a good candidate I think because of the large DC signal level.

This Hanford alog may be of relevance as we are using the aLIGO AA chassis for the IR ALS channels. We aren't expecting any large amplitude high frequency signals for this application, but putting this here in case it's useful someday.

This test was done, and I determine the frequency discriminant to be  (for an RF signal level of ~2 dBm). 

Attachment #1: Measured and predicted value of the DFD discriminant for a few RF signal levels.

• Methodology was to drive an FM (deviation = 25 Hz, fMod = 221 Hz, fCarrier ~ 40 MHz) with the Marconi, and look at the IF spectrum peak height on a SR785
• The "Design" curve is calculated using the circuit parameters, assuming 4dB conversion loss in the mixer itself, and 3dB insertion loss due to various impedance matching transformers and couplers in the RF signal chain. I fudged the insertion/convertion loss numbers to get this curve to line up with the measurements (by eye).
• For the measurement, I assume the value for FM deviation displayed on the Marconi is an RMS value (this is the best I can gather from the manual). I'll double checking by looking at the RFmon spectrum directly on the Agilent NA.
• X axis calibrated by reading off from the RF power monitor using a DMM and using the calibration data from the bench.
• I could never get the ratio of peak heights in Ichan/Qchan (or the other way around) to better than ~ 1/8 (by moving the carrier frequency around). Not sure I can explain that - small non-orthogonality between I and Q channels cannot explain this level of leakage.

Attachment #2: Measured noise spectrum in the 1Y2 (LSC) electronics rack, calibrated to Hz/rtHz using the discriminant from Attachment #1.

• Something funky with the I channel for X, I'll re-take that spectrum.

I'm still waiting on some parts for the new BeatMouth before giving the whole system a whirl. In the meantime, I'll work on the EX and EY green setups, to try and improve the mode-matching and better characterize the expected suppressed frequency noise of the end NPROs - the goal here is to rule out the excess low-frequency noise that was seen in the ALS signals coming from unsuppressed frequency noise.

Bottom lines: 

1. The DFD noise is at the level of ~ 10mHz/rtHz above 10 Hz. This justifies the need for whitening before ADC-ing.
2. The measured signal/noise levels in the DFD chain are in good agreement with the "expected" levels from circuit component values and typical insertion/conversion loss values.
3. Why are there so many 60 Hz harmonics???

Attachment #1 shows the schematic of the test setup. Signal generator (Marconi) was used to supply the RF input. We observed the IF output in the following three test conditions.

1. Observed the spectrum with FM modulation (fcarrier of 40 MHz and fmod of 221 Hz )- a peak at 221 Hz was observed.
2. Observed the noise spectrum without FM modulation.
3. Observed the noise spectrum after disconnecting the delayed output of the delay line. 

• It is observed that the broad band noise level is higher without FM modulation (2) compared to that we observed after disconnecting the delayed output of the delay line (3).
• It is also observed that the noise level is increasing with increase in RF input power. 
• We need to find the reason for increase in broad band noise .

[Paco, Anchal]

One of the crucial and currently limiting calibration errors is in the ALS beat. We think a major driver of calibration uncertainty may be the DFD TF calibration since it depends on the RF beat power.

The RF beat power as monitored by C1:ALS-BEATY_RF_POW shows relative fluctuations of 0.02% at the 16 Hz sampling rate (actually 0.09% rms from Attachment #1) once the single arm and YAUX laser are both locked. This sounds ok, but that's just a statistical estimate. The beat frequency changes every time we break and reacquire the lock, making the BEAT PD frequency response and DFD overall calibration change their nominal TF. This changes can be significantly larger than 0.02% (e.g 4.9% = observed change in the RF power after breaking and reacquiring the YAUX lock this morning). This is far more significant than the contribution from the RIN on the two lasers.

This kind of systematic error could be addressed by either/all:

• Stabilizing the ALS BEAT absolute frequency (offset locking using freq counter and simple integrator or equivalent)
• Rejecting RF beat amplitude fluctuations by mixing a stable DC voltage in the DFD, or using a comparator. 
  • Our plan this afternoon is to quickly measure the RF AM rejection level from a simple mixer and a stable voltage reference and plan ahead.
• ISS on both lasers

Eventually the instability in the Y end PDH servo turned out to be some kind of an alignment issue.

After carefully realigning the green beam to the Y arm, the UGF of the ALS loop became able to be at more than 50 Hz.

With this UGF it became able to suppress the arm motion to the ADC noise level (few 100 pm in rms).

Now I am scanning the arm length to look for a TEM00 resonance.

(the Story)

I have noticed that the spatial fringe pattern of the reflected green light was very sensitive to the pitch motion of ETMY when the green light was locked to the Y arm.

So I realigned the last two launching mirrors to minimize the reflected light. Indeed the misalignment was mainly in the pitch direction.

I basically translated the beam upward by a couple of mm or so.

The amount of the DC reflection is about 2.4 V when it is unlocked and it is now 0.77 mV when the green light is locked.

[Paco]

I took ~ 7 minutes of XALS beatnote data with the XAUX laser locked to the XARM cavity, and the XARM locked to PSL to develop an allan deviation estimator. The resulting timeseries for the channel C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ (decimated timeseries in Attachment #1) was turned into an allan variance using the "overlapped variable tau estimator":

Where  represents the k-th data point in the raw timeseries, and are the variable integration intervals under which two point variances are computed (the allan variance is a special case of M-point variance, where M=2). Then, the allan deviation is just the square root of that. Attachment #2 shows the fractional deviation (normalized by the mean beat frequency ~ 3 MHz for this measurement) for 100 integration times spanning the full duration (~ 7 min = 420 s).

The code used for this lives in Git/40m/labutils/measuremens/ALS/

If this estimate is any good, wherever the fractional beatnote deviation reaches a minimum value can be used as a proxy for the longest averaging time that give a statistical increase in SNR. After this timescale, the frequency comparison is usually taken over by "environmental instabilities" which I don't think I can comment further on. In our particular estimate, the 100 second integration gives a fractional deviation of ~ 0.44 %, or absolute deviation of 12.925 kHz.

what's the reasoning behind using df/f_beat instead of df/f_laser ?

I guess it didn't make sense since f_beat can be arbitrarily moved, but the beat is taken around the PSL freq ~ 281.73 THz. Attachment #1 shows the overlapping tau allan deviation for the exact same dataset but using the python package allantools, where this time I used the PSL freq as the base frequency. This time, I can see the minimum fractional deviation of 1.33e-13 happening at ~ 20 seconds.

Another, more familiar interpretation

The allan variance is related to the beatnote spectral density as a mean-square integral (the deviation is then like the rms) with a sinc window.

[Masayuki, Manasa] 

Flowchart for ALS autolocker. The error signal thresholds will be decided by trial and error.

  I think we can use the IMC autolocker to start with getting this started. Once Jamie fixes the NDSSERVER environment variable bug, we should be able to use his more slick automation code to make it auto lock.

Step by step procedure for stabilizing arms using ALS servo:

The procedure is the same for both the arms. 

0. Check that the ALS arm servos are turned OFF and not sending any signals to the ETM suspensions. 

1. Find the beat note by varying the laser temperature (moving the slider for SLOW_SERVO2_OFFSET).
Tip: It is easier to have the arms locked using IR PDH while searching for the beat note. Also check the stability of the MC. Unstable MC will cause the PSL temperature to drift and thereby affect the beat frequency.

2. Once you have the beat note, check if the beat amplitude is ~ -15 to -20 dBm. If the amplitude is small, then the alignment needs to be fixed (either the green input pointing at the end tables or the PSL green alignment). This is important because the UGF of the phase tracking loop (should be above 1KHz) changes with the amplitude of the beat note.
Also the beat frequency should be < 100 MHz; preferably below 80 MHz.

3. Disable IR PDH locking if you had used it while searching for the beat note. 

4. Press CLEAR HISTORY button for the phase tracker servo. Check if the phase tracking loop is stable (phase tracker servo output counts should not be ramping up). If the phase tracker is not stable, check the servo gain and phase margin of the loop.

5. Turn OFF all filters in the ALS arm servo filter module except for FM5 (phase compensation filter). With ALS arm servo gain set to zero, enable the arm servo and allow ALS control signals to be sent to the ETM suspensions.

5. Open dtt and look at the power spectrum of the ALS error signal (C1:ALS-BEAT?_FINE_PHASE_OUT_HZ). 

6. Set ALS arm servo gain +/- 0.1 to check the sign of the servo gain. Wrong sign of gain will make the loop unstable (beat note moving all over the frequency range on the spectrum analyzer). If this happens, set the gain to zero immediately and clear history of phase tracker servo. If you have set the correct sign for gain, the servo will stabilize the beat note frequency right away. 

7. Once you know the correct sign of the servo gain, increase the gain in steps while simultaneously looking at the power spectrum of error signal on dtt (it is convenient to set dtt measurements to low bandwidth and exponential measurement settings). Increase the gain until you can see a slight bump close to the UGF of the ALS servo (>100Hz). 
There have been times when this servo gain was in a few hundreds; but right now it varies from +/- 10-20 for both the arms. So we are stepping up gain in steps of +/- 2.

8. Enable filters (FM2, FM3, FM6, FM7, FM8). Wait to see the rms noise of the error signal go down (a few seconds).

9. Enable boost filter (FM10). There also exists a weaker boost filter (FM4) which we don't use any more. 

Note:

1. Beat frequency changes affect both the servo gain and sign of gain. So if you lose stability of ALS servo at any point, you should go through all the steps again.

2. At any point if the ALS arm servo becomes unstable (which can happen if the MC loses lock or if the beat frequency was too high ), change the servo gain to zero immediately. Turn OFF all the filters except for FM5 (if they were enabled) and reset phase tracker servo (CLEAR HISTORY button in the phase tracker filter module). Masayuki has written the down script that does all this. The script will detect arm servo loop instability by continuously looking at the feedback signal. Details about the script can be found here. 

Here is a cheat sheet that can give you an idea of the SLOW SERVO2 offset range to scan in order to find the beat note:

PSL temperature  X offset   Y offset
31.58                     5278       -10890
31.52                     5140       (not recorded)
31.45                     4810       (not recorded)
31.33                     4640       -10440
31.28                     4500       -10340
            

After aligning the arms to IR, I aligned the Y green beam to the arm.  Also, the X green beatnote was very small, so I aligned the PSL green for X.

[Koji Annalisa]

We did the same mod of the beatbox for the Y arm too. See
http://nodus.ligo.caltech.edu:8080/40m/8855

[Manasa Koji]

Summary:
The new whitening filters improved the out-of-loop ALS stability of the Y arm down to 300Hz (20pm_rms in displacement).

- After modifying the whitening filters, the out-of-loop stability of the arms were tested with the IR PDH signals.

- The X arm showed non-stationarity and it made the ALS servo frequenctly fell out of lock.

- For now we decided to use the Y arm for the PRMI+one arm trial.

- The performance of the ALS was tested with several measurements. (attachment 1)

Cyan: Stability of the beatnote frequency with the MC and the arm freely running. The RMS of the day was ~6MHz.

Blue: Sensing limit of the beat box was tested by giving a signal from Marconi. The same amplitude as the X arm beat was given as the test signal.
This yielded the DC output of ~1200 counts.

Green: Out-of-loop estimation of the beatbox performance. This beat note stability was measured by controlling the arm with the IR PDH signal.
Assuming the PDH signal has better SNR than the beat signal, this gives us the out-of-loop estimation of the stability below 150Hz, which is the
unity gain frequency of the ALS loop.
Above 150Hz the loop does not force this noise to the suspension. Just the noise is injected via a residual control gain (<1).

Black: In-loop evaluation of the ALS loop. This becomes the left over noise for the true stability of the arm (for the IR beam).

Red: The arm was brought to the IR resonance using the ALS offset. The out-of-loop stability was evaluated by the IR PDH signal.
This indeed agreed with the evaluation with the other out-of-loop evaluation above (Green) below 150Hz.

Attachment 2 shows the time series data to show how the arm is brought to the resonance.
1 count of the offset corresponds to ~20kHz. So the arm started from 200kHz away from the resonance
and brought to the middle of the resonance.

(Manasa downloaded the 2k sampled data so that we can use this for presentations.)

Awesome !