Probably things would have worked better if you would have gotten your hair done at the same place as me.

To make the mcwfson/off scripts work from rossa (and not just Jamie's pet machine) I swapped the sh-bang line at the top of the script to use 'env bash' instead of 'env csh' in the case of mcwfsoff and 'env tcsh' in the case of mcwfson.

The script was failing to work due to $OSTYPE being defined for pianosa csh/tcsh, but not on rossa.

During debugging I also bypassed the ezcawrapper for ezcaswitch so that now when ezcaswitch is called, it directly runs the binary and not the script which calls the binary with numerous retries. In the future, all new scripts will be rewritten to use cdsutils, but until then beware of ezcaswitch failures.

WFS scripts checked into the SVN.

This was all in an effort to get Koji to allow me to upgrade pianosa to ubuntu 12 so that I can have ipython notebook on there.

Objections to upgrading pianosa? (chiara and megatron are already running ubuntu 12)

We turned on the MC2_TRANS paths for both PIT/YAW tonight.

I turned off the BLP200 and turned on the RLP7 (RLP always are better than BLP). G_PIT = -0.111, G_YAW = 0.111. On Monday, let's let Steve look at the trends and determine if this centering servo is bad or good.

I should've included this in my Thursday night ELOG... That evening, I aligned the mode cleaner with reasonable MC1/3 spot positions, and the MC2 spots very close to centered, and recentered the WFS and MC2 Trans QPDs. The mode cleaner held up very well over the course of that evening, even when actuating CARM on MC2 with WFS engaged (which previously wasn't very stable when the WFS weren't well aligned).

Inspired by a comment by Koji the other day, I spent some time yesterday and today working on locking a (very lossy) power recycled Y-arm. ITMX was misaligned, to save myself the headache of dealing with ITMY getting a sign flip and ITMX staying the same when the arm resonates. 

My main goal was to achieve high bandwidth control with the analog CARM servo. 

TL,DR: Transisitoned 90% to REFLDC through CM_SLOW at TRY = 2.1 twice. Couldn't make it all the way over. 

PRCL settings:

• Input: REFL165 I.
• Actuate on PRM +1
• Control: G=-.32 (~100Hz UGF); Acq on FM 4,5; Trig 1,2,3,6,9 (I modified the +10dB in FM1 to a 1kHz ELP)
• Trig: POP 110 I: 1.5 up, 0 down (max was around 4 counts, very weak PRC!)

The PRC was very stable in this configuration, which doesn't surprise me due to its simplicity. I was honestly a little surprised there was enough light to lock on 3f. REFL33 didn't work. 

My efforts to bring the Y-arm into lock were very similar to the CARM procedure we've been using recently. (Which is the motivation for this exercise)

At first I was actuating on ETMY, and got to the point where I wanted to start bringing in the CARM servo slow output, then realized that I didn't want to actuate both on the ETM and MC AO. (Maybe this would be doable, but in the end, not what I'm interested in learning about in terms of overlap with CARM locking)

From then on, I only actuated YARM on MC2. (Heads up, my lock-losses will show up in the trends of the MC2 Trans addition to the WFS.)

Transitioning the arm to SqrtInv TRY control was just as straightforward as it has been for CARM. However, engaging the LSCLock FM (FM4), would sometimes work beautifully, and sometimes kick the hell out of MC2. Keeping an eye on the error signal spectrum and UGF gave no indication which outcome would happen. Once FM4 could be engaged, the transmitted power was very stable. Without FM4, reducing the offset didn't get very far without losing lock. 

I tried a few times to bring in CM_slow (set to just IN2, i.e. offset adjusted REFLDC), at arbitrary arm powers, with little success. I didn't know how much arm power to expect at resonance, and thus didn't really know where on the line width I was.

I knew I was mostly outside of the linear regime of the PDH signals, since, even though I had good coherence between, say, REFL11 I and SqrtInvTry, with an ETMY excitation on; when I would turn TRY normalization on/off, I would see the sign of the TF change. 

I then realized that I could actively keep an eye on the trend of POY11, to see when I got to the PDH "hump", which is where REFLDC starts being usable, and SqrtInv is reaching its limit. 

This brought me to a YARM offset of .115, with a steady TRY of about 2.1. I adjusted the analog offset of the REFLDC input to the CARM board, and the digital gain of the CMSLOW input filter to get 1:1 correspondence between CMSLOW and the SQRTINVY channels. Their spectra were neigh identical, with CMSLOW having slightly more high frequency noise. 

I started stepping SQRTINV down by .1, and upping CMSLOW by .1. This shifted the offset around, so I opted for taking away gain before bringing it back, because I didn't want to get so close to resonance that SQRTINV would freak out. I got to .1*SQRTINVY + .9*CMSLOW, and lost lock. TRY was getting noisier as I made the transition. 

I'm not sure what exactly was the reason for failure. I'm going to go back over some of the data to try to get an idea.. Maybe I should've loosened up some of the gain/boosts during the transition. 

So, no great success story yet, but this configuration is a lot simpler than the full PRFPMI, and I feel that I should soon be able to get it fully controlled, and figure out a systematic way to make the digital to analog transition for this PRFP cavity, and thus have a much more informed basis for doing the same for CARM control. 

The measured open loop TF of the ALS Phase Tracker loop for each arm was characterized by an empirical model on LISO.

The model for the open loop TF has pole 1m instead of the one at DC as LISO has a difficulty to model it.
Digital time delay and the sampling effect seem to be well represented by a zero at ~8kHz and delay of  ~60us.
(cf 16kHz sampling => 61us)

The XARM phase tracker has the UGF of 1.5kHz. This is too low because
1) The phase rotation at 100Hz is visible in the plot.
2) We don't much care about the closed loop bump in the phase tracker as long as the phase tracker keeps its continuity.

So I suggest to increase the gain so that we have the UGF of 3kHz. (phase margin: 24deg)

The red curve in the plot is the closed loop response calculated by CLTF =  - OLTF / (1-OLTF).

The model results are used in the ALS servo models.

The measured openloop TF of the ALS servo for each was characterized by a ZPK model.

The openloop TF can be modeled by:

1) Filter TF obtained from foton
2) Actuator response with appropriate assumption
3) Phase tracker closed loop TF
4) Delay caused by the digital control
5) anything else

For 1) ZPK models of the servo filter was obtained from foton. It turned out that the TF of FM5 doesn't match with the ZPK model in foton.
Therefore the TF was exported and fitted with LISO. This seems to be related to the pole frequency (3kHz) which is too close to Nyquist frequency (8kHz).

FM(:,1)  = zero1(f,5).*pole1(f,0.001)*5000;
FM(:,2)  = zero1(f,1).*pole1(f,0.001)*1000;
FM(:,3)  = zero2(f,4.5,1.4619).*pole1(f,0.001).*pole1(f,0.001)*20.2501*1e6;
FM(:,4)  = zero2(f,35,2).*pole2(f,3,3).*zero1(f,3000).*pole1(f,1).*pole2(f,3000,1/sqrt(2)).*pole1(f,700).*zero1(f,10).*zero1(f,350).*136e1;
FM(:,5)  = zero1(f,1).*pole1(f,4.010e3).*pole2(f,17.3211e3,1.242).*zero2(f,18.865e3,100e3);
FM(:,6)  = zero2(f,3.2,0.966775).*pole2(f,3.2,30.572);
FM(:,7)  = zero2(f,16.5,2.48494).*pole2(f,16.5,78.5807).*zero2(f,24.0,2.22483).*pole2(f,24.0,7.03551);
FM(:,8)  = 1;
FM(:,9)  = zero2(f,7.50359,1.07194).*pole2(f,1.43429,0.717146)*27.5653;
FM(:,10) = 1;
dc_gain = 14;

FM1/2/3/5/6/7/9 are used for the control.

For 2), a resonant freq of 0.97 with Q of 5 was assumed.

The model for 3) was obtained by the previous entry.

Now the measured TF was divided by the known part of the model 1) ~ 3) and empirically fitted in LISO.

### XARM ###
pole 392.5021429051 698.1992431753m
zero 42.3128869460k 31.0954443799m
pole 589.2716424428 2.8325268375
factor 8.3430140244
delay 34.7536691023p

### YARM ###
pole 416.2463334253 743.2196174175m
zero 97.9161062704M 114.6703921876m
pole 626.0463515310 2.7671041771

factor 9.0045911761
delay 34.0945727358p

These compensation TF have weird TF. Probably the frequency response of the delay and the analog AA/AI filters without the high frequency data
led the LISO make up this. I'm requesting Masayuki to provide the AA/AI data to make the estimation more reasonable.
For the servo modeling, this is sufficient and we'll go a head.

The results of the OLTF modeling are attached.

As we now have the loop model, we can characterize the error signals.

We have the following data:

1) Free-running ALS error signals (i.e. phase tracker output) calibrated in Hz (for 532nm) (blue)
2) Controlled ALS error signals calibrated in Hz (for 532nm) (red)
3) ALS error signals measured with X and Y arm locked with the IR PDH. (black)
    This is likely to represent the sensing noise of the beatnote detection

from 2) we can derive the similar quantity as 1)
4) Estimated free-running ALS error signals from the controlled signals (green)

Remarks:

- From 1) and 4) we can see that the phase tracker is not perfectly linear. It seems that fast fringing of the phase tracker is causing upconversion.

- From 2) and 3) the servo loops don't have enough gain between 3Hz and 20Hz. On the other hand they have too much gain bekow 3Hz.

Based on the evaluation of the error signals, the new servo was designed.

Concept:
- Don't touch the locking filters. (i.e. FM5)
- Sacrifice some phase at 150Hz to increase the gain between 3-20Hz.
- As resonant gains costs the phase without increasing the LF gains, replace them with a poles for the integrators.

FM(:,1) = zero2(f,.5,.7).*pole2(f,0.001,.7)*(0.5/0.001)^2;
FM(:,2) = zero2(f,5,2).*pole2(f,3,3).*pole1(f,1).*zero1(f,5)*5*(5/3)^2;
FM(:,3) = zero2(f,25,.7).*pole2(f,3.2,10)*(25/3.2)^2; % Zero crossing
FM(:,4) = zero2(f,35,2).*pole2(f,3,3).*zero1(f,3000).*pole1(f,1).*pole2(f,3000,1/sqrt(2)).*pole1(f,700).*zero1(f,10).*zero1(f,350).*136e1;
FM(:,5) = zero1(f,1).*pole1(f,4010).*pole2(f,17.3211e3,1.242).*zero2(f,18.865e3,100e3);
FM(:,6) = zero2(f,5,2).*pole2(f,10,2).*pole2(f,16.5,30).*zero2(f,30,2);
FM(:,7) = 1;
FM(:,8) = 1;
FM(:,9) = 1;
FM(:,10) = 1;
dc_gain = 14;

FM1/2/3/5/6 are expected to be used for the control.

FM1: Boost below 0.5Hz. This does not cost the phase margin.
FM2: Increase the gain below 5Hz. This hardly cost the phase margin.
FM3: Boost below 25Hz. This is the main phase cost at UGF. This has a complex pole pair at 3Hz with Q=10 to supress the stack motion.
FM6: zero-pole-pole-zero combination to boost the gain between 5 to 30Hz. This eats the phase margin a little.

Note that the phase tracker gain for the X arm was increased by factor of 2.5.

Comparison of the new and old servo OLTF
The new servo has the same UGF, slightly less phase margin, and more gain between 1.5 and 25Hz.

The expected error signals derived from the estimated free running error signals of the ALS.

1) Previously estimated free-running noise (blue)
2) Previous in-loop ALS error signal (red)
3) Estimated error signal with the new servo (green)
4) Out-of-loop noise of the ALS with the arm controlled with the IR PDH (black)

Now the error signal (green) is expected to be very white.
The suppressed noise between 3 to 20Hz are below the sensing noise level.
There seems a little excess at 24.5Hz and 28Hz. If it is limiting the RMS, we need to take care of them.

The new ALS/LSC servo was implemented for the X arm.

I'll upload more data later but here I make quick remarks:

- We need to give the gain of 12 to have correct UGF with the ALS.

- With this servo, the Xarm PDH lock oscillates with the gain of 0.02. We need to lower the gain to 0.015.
  Also FM trigger should be changed not to trigger unused FMs (FM7/8)

Here are the MATLAB scripts and LISO codes for all of these servo analyses

 I was unhappy with the discontinuities between the Thorlabs and QPD versions of our transmitted light powers.  I realized that in the olden days, we just used the Thorlabs PD, and we set the no-light offset in the LSC version of the TR[x,y] filter banks.  However, now that we have brought the QPDs back, we are setting the dark offsets in the end suspension models, so that the signal chosen by the trigger already has its offset taken care of before we send it to the LSC model. 

Anyhow, having the offsets script try to put a value in the C1:LSC-TR[x,y]_OFFSET was giving us an extra offset and then when we did the normalizations, the numbers came out all wrong.  So.  I have removed the C1:LSC-TR[x,y] filter banks from the offset list, since they were made redundant. 

I have redone the normalizations for both arms (after running the ASS scripts).  I checked by watching the _OUT16 versions of the Thorlabs and QPD diodes before the triggering happens, and as I put offsets into the LSC servos to change the transmitted power, the diodes both change in the same way.  So, we'll have to see if this holds true for more than just values 0-1 the next time we lock, but hopefully it won't need changing for a while.

The MC was showing slow but periodic alignment drifts and eventually unlocked around noon. I looked up the alignment trend (Attach: 2 day trend)

MC_TRANS_PIT_ERR and MC_TRANS_Y_ERR show that the MC_TRANS servo slowly drifted the IMC alignment causing it to lose lock from time to time (mostly in yaw).

To confirm that the drift was NOT due to off-centering in the MC2_TRANS QPD, I turned off the WFS servo, moved MC2 to recenter the trans beam on the QPD, and re-enabled WFS servo.

MC_TRANS path in WFS is still left enabled.

 Last long extension cord removed from 1Y1 to ITMX-ISCT

The AC power strip at ITMX-ISCT is coming from wall L#26

This is a 4-day trend. I don't see any difference here which is significant. My guess is that the MC_TRANS servo gain is so low that its not really doing anything.

I'll turn it on periodically this week and then on Monday people can look at the trend again to see if they can identify when the servo is ON and when its OFF.

[Jenne, Koji]

The IFO is being uncooperative tonight, and I have an early morning meeting, so I'm calling it a night. 

Koji's filter module changes have been propagated from the Xarm to the Yarm, to CARM and to DARM.  (Actually, Q overwrote the changes to Xarm on Sunday accidentally, so first he reverted those for us, and then we propagated the changes). 

Today, with careful measuring, we find that for X and Y arms individually locked with the ALS, we want the gains to be +17 for the Yarm, and -17 for the Xarm (with the beatnote up-is-up convention).  This puts the UGFs at 150 Hz. 

We then switched over to CARM and DARM locking.  We guessed that the gains should be a factor of 2 lower since we're pushing on both ETMs for DARM, and the MC2 actuator is roughly the same strength as the sum of the ETMs.  In the end, after measuring the CARM and DARM loops, we find that the gains should be +7.5 for CARM, and +8.0 for DARM to set the UGFs at 150 Hz.  The servo is a little bit delicate, so having too low of gain is not okay. 

For some reason, we seem to be utilizing more actuator range with the new setup, so the limiters in the filter banks have been set to 11,000 (previously were 8,000), and the ALS watch script (ALSdown.py) threshold has been increased to 10,000 (previously 7,000). 

When finding the IR resonances with the new scheme, we are having trouble holding lock throughout the scan.  I have set the tramp for the coarse part of the scan to be 0.05 seconds (previously 0.01 seconds), which is an increase of a factor of 5 in the ramp time.  This helps, but may still not be enough, since we don't always hold lock until both IR resonances are found.

Probably the most annoying thing from tonight is the fact that ETMY keeps drifting off, particularly in yaw, when locked.  I don't have an explanation of why this is happening, but you can watch it happen sometimes, and the lock will be lost shortly thereafter.  Definitely when we lose lock and the ETM gets kicked, it is far enough away in yaw alignment that I have to completely redo the Yarm alignment.  This happens whether or not the ETMY oplevs are on.

To summarize, 3 scripts have been modified:

(1) ALSdown - threshold increased  (Modification from last week - turns off the slow temp servos for the end lasers, clears histories)

(2) ALSfindIRresonance - increase ramp time

(3) Lock_ALS_CARMandDARM - final gain values set to 7.5 for CARM and 8 for DARM, no filters come on until gains all the way up, turns on new set of Koji filters. (Modification from last week - turns on the slow temperature servos for the end lasers)

Be aware that this may affect POP QPD and POP RF Thorlabs PD

New ALS servo performance

Attachment 1:

Comparison between the old (orange) and new (red). The new error signal (red) is suppressed like a white noise as expected.

Comparison between the out-of-loop evaluation (black) and the in-loop signal (red). Below 50Hz the out-of-loop is limited by the sensor-noise like something.
This out-of-loop stability was measured with the ALS stayed at the top of the resonance and calibrated the POX11 error signal.

Attachment 2:

New ALS servo with the LSC PDH signal. When the PDH signal is used for the control, FM4 is additionally used.
In this condition, the error signal was measured and calibrated into frequncy noise (Hz/sqrtHz).

By comparing the POX (with the new servo) and POY (with the old servo) signals, one can see that the new servo has better supression below 30Hz with almost no cost at ~100Hz.

I've moved the WB network analyzer to the OMC lab. The 40m network analyzer is not in service for the MC monitoring.
I setup the configuration so that the same command gives us the same spectrum measurement.

 TP2 dry pump replaced at fore pump pressure 1 Torr,  TP2 50K_rpm 0.34A

 Top seal life 6,362 hrs

 New seal performance at 1 hr  36 mTorr, 

 Maglev at 560 Hz, cc1 6e-6 Torr

[Koji, Manasa]

The Y arm locks stably for IR PDH now.  

The reason for ETMY getting kicked during lock acquisition was finally found to be related to the limiter value set in the Y arm servo. We reduced the limiter value unintentionally and found that the lock acquisition stayed smooth. The limiter value was stepped in 1000s from 7000 and eventually found that the ETMY suspension was kicked when we try to acquire lock with the limiter value was set at 11000. 

The limiter for X arm at 11000 is not causing any trouble at the moment.

In the process, we did a bunch of things through the evening to troubleshoot IR locking of the Y arm.

Earlier today running the IFO configure script did not restore the arms to lock and both the ETMs needed to be aligned to lock the arms. The arms stayed locked for 15 minutes and the Y arm lost lock eventually leaving the ETMY in a misaligned state. 

The state of the Y arm was similar to what Jenne has explained in ELOG where the ETMY was kicked during lock acquisition and would move to a misaligned state.

To trouble shoot, there were several things that were done. A few of them might not have any direct correlation to the locking issue but could just be a coincidence.  

1.  The trigger time for the filters in the arm filter modules were set such that they switch on after the SUS violin filters. Arm FM trigger time = 3 s (previously set at 0.1s) and SUS violin trigger time = 1s. This reduced the number of lock loss events.

2. There was some drop in transmission when the bounce filter of Y arm (FM6) turned ON. This was fixed by changing its ramp time (initially set at 1s). The filter has been modified to turn on immediately upon arm lock acquisition before the other triggered filters in the filter module turn on.

3. The QPD and SUS signal cables running to the rack were checked to be intact. Koji found some of them to be loose. But this had no evident correlation with the arm locking problem.

4.The oplev and PD alignment was checked at the Y end. The high gain trans PD for Y arm was checked for good alignment by looking at TRY. It was found that the EXIT light at the Y end is injecting some noise to the transmission PD. 

5. The ETMY was given offsets in PIT, YAW and POS and the OSEM sensor values were checked to see if the suspension is behaving well. It was behaving well.

c1sus and c1iscey were reset. The PMC needed to be locked. MC locked instantly.

The FSS ion pump power supply was turned on.

c1sus and c1isey were not talking to fb. The usual mxstream restart did not help.

Restarted fb

>>ssh fb

>>telnet fb 8087
shutdown

All lights on the FE status screen are green now.

Note that Steve did an mxstreamrestart earlier today because the same machines c1sus and c1isey were not talking to fb.

I. The Y arm stayed stable through last night and I have saved the arm lock settings to IFOconfigure.

II. ALS X arm noise measurements

I looked at the before and after noise of ALSX.

Settings:
Phase tracker gain = 85
Xarm servo gain = -17

The rms in loop noise has dropped from 3KHz to 500 Hz.

Attachment 1: Phase tracker OLTF

Attachment 2: Free running noise and in loop noise

Attachment 3: Out of loop noise (measured with arms locked using PDH for IR)

Attachment 4: ALS arm servo OLTF

xml data files can be found in /users/manasa/data/140430/

The c1ioo host is now fully on the dolphin network!

After the mx stream issue from two weeks ago was resolved and determined to not be due to the introduction of dolphin on c1ioo, I went ahead and re-installed the dolphin host adapter card on c1ioo.  The Dolphin network configurations changes I made during the first attempt (see previous log in thread) were still in place.  Once I rebooted the c1ioo machine, everything came up fine:

We then tested the interface by making a cdsIPCx-PCIE connection between the c1ioo/c1als model and the c1lsc/c1lsc model for the ALS-X beat note fine phase signal.  We then locked both ALS X and Y, and compared the signals against the existing ALS-Y beat note phase connection that passes through c1sus/c1rfm via an RFM IPC:

The signal is perfectly coherent and we've gained ~25 degrees of phase at 1kHz.  EricQ calculates that the delay for this signal has changed from:

122 us -> 61 us 

I then went ahead and made the needed modifications for ALS-Y as well, and removed ALS->LSC stuff in the c1rfm model.

Next up: move the RFM card from the c1sus machine to the c1lsc machine, and eliminate c1sus/c1rfm model entirely.

For reference, here are the new IPC entries that were made for the ALS X/Y phase between c1als and c1lsc:

controls@fb ~ 0$ egrep -A5 'C1:ALS-(X|Y)_PHASE' /opt/rtcds/caltech/c1/chans/ipc/C1.ipc
[C1:ALS-Y_PHASE]
ipcType=PCIE
ipcRate=16384
ipcHost=c1ioo
ipcNum=114
desc=Automatically generated by feCodeGen.pl on 2014_Apr_17_14:27:41
--
[C1:ALS-X_PHASE]
ipcType=PCIE
ipcRate=16384
ipcHost=c1ioo
ipcNum=115
desc=Automatically generated by feCodeGen.pl on 2014_Apr_17_14:28:53
controls@fb ~ 0$ 

After all this IPC cleanup is done we should go through and clean out all the defunct entries from the C1.ipc file.

The POP QPD X/Y/SUM signals, which are acquired in c1ioo, are now being broadcast over dolphin.  c1ass was modified to pick them up there as well:

Here are the new IPC entries:

controls@fb ~ 0$ egrep -A5 'C1:IOO-POP' /opt/rtcds/caltech/c1/chans/ipc/C1.ipc
[C1:IOO-POP_QPD_SUM]
ipcType=PCIE
ipcRate=16384
ipcHost=c1ioo
ipcNum=116
desc=Automatically generated by feCodeGen.pl on 2014_Apr_30_17:33:22
--
[C1:IOO-POP_QPD_X]
ipcType=PCIE
ipcRate=16384
ipcHost=c1ioo
ipcNum=117
desc=Automatically generated by feCodeGen.pl on 2014_Apr_30_17:33:22
--
[C1:IOO-POP_QPD_Y]
ipcType=PCIE
ipcRate=16384
ipcHost=c1ioo
ipcNum=118
desc=Automatically generated by feCodeGen.pl on 2014_Apr_30_17:33:22
controls@fb ~ 0$ 

Both c1ioo and c1ass were rebuild/install/restarted, and everything came up fine.

The corresponding cruft was removed from c1rfm, which was also rebuild/installed/restarted.

I found the YARM LSC feedback going to MC2 and the MC2 violin mode (at 644.69 Hz) rung up. The existing notch was just a second order Twin-T style notch (so not a good idea) and also not turned on, since it was in the FM4 spot of LSC-MC2 and the vio triggers are ganged between all mirrors and don't touch FM4.

I copied the PRM vio bandstop into FM2 of this bank, deleted the old notch, and tuned the bandstop frequencies a little to get the violin peak into one of the zeros of the elliptic bandstop. Attached are the Y-arm / MCF spectrum with the mode rung up as well as the new filter's TF compared with the old notch.

P.S. I installed http://en.wikipedia.org/wiki/Midnight_Commander on pianosa.

Looks like there was some mysterious MC alignment shift around 5:30 PM today, but no elog.....?? Now things are drifting much more than this morning or yesterday. Who did what and why???

I think I'll blame Jamie since he just got back and did some computer fiber voodoo today.

http://www.lawsome.net/no-throwing-rotten-tomatoes-a-repealed-kentucky-law/

During a lull in Koji vs. The Arm, I switched on the MC2_TRANSQPD feedback path to check out its UGF. In the past months, when its been on, it has had a gain of ~0.03 - 0.1.

Today, I found that with the gain turned up to 11, it has a ~1 minute step response time (as you see in the above Strip chart). So its had a UGF of ~2 hours or so during the times when we thought it might be doing bad or good or magic.

I leave it on now to see if it behaves well over the next days. Let's see if Steve thinks its good or not based on his trend monitoring.

** also touched up the PMC pointing (using the PMC REFL image / please never align the beam into the PMC without this camera image)

I saw big misalignment on the GTRX camera, I went to the PSL table and aligned the beat beams.

I disconnected the RF out of the X beat PD and  connect an oscilloscope.
The beat amplitude was 15mVpp at the beginning and is 60mVpp right now.
I checked the alignment on this RF PD and the DC PD as well as the spot on the CCD.

The RF cable was connected again.

Jenne and I ran the ALS and scanned the arm cavity. We had the impression that the noise level of the ALS improved,
but I don't have correctly calibrated measurement. Let's do it tomorrow in the day time.

The Yarm beat alignment look awful. We should align this too.

[Rana, EricQ, Jenne]

We locked the Yarm by using the CM board this evening. 

POY is going from its demod board to the CM board, and then the slow output of that is going to the POY channel of the whitening, and then on to the ADC.  So, with no AO path engaged, this is basically like regular Yarm locking. 

First of all, Den and Koji back in December were concerned that they were seeing some EOM saturation in the fast path, but we don't think that's an issue.  We looked at the FSS PCDRIVE while we increased the AO gain.  In fact, it looks like the offset is coming from the MC board's IN2 slider.  Even with no input on that slider, increasing its value puts an offset into the MC.  To fix this, I am going to put a 6.8uF cap in series with R30 in the MC board, which is part of the crossbar switch where the IN1 and IN2 get summed.  This should AC-couple the output of the IN2 slider before the summing node.

We aren't sure which sign to use for the AO path of the CM board...Eric is doing some modelling to see if he can figure it out.  He's going to try to see which spectra (below) his model matches.

For the spectra, we have a reference trace with no AO path, a trace with "Plus" polarity on the CM board which started to show a peak when the value of the MC IN2 slider was at about -6 dB, and a trace with "Minus" polarity, which started to show a peak when the value of the MC IN2 slider was at about -16 dB. 

We took loop measurements for each of the Plus and Minus cases. Something that seems a little weird is how shallow of a slope we have in both cases near our UGF.

Just to be clear, the normal POY signals are not currently present, so the restore POY script will not result in the arm locking. POY11_I is turned off, POY11_Q is the output of the CM board, which can be used to lock the arm, as we did tonight. 

The POY digital demos angle went -56 -> 90, to get all of POY11_Q_IN1 to POY11_I_ERR

Miscellaneous things:

• Right now, the cable from CM board ->MC board is a BNC. There appeared to be a differential 2-pin lemo hanging around for this purpose, but it didn't seem to be transmitting the signal. However, we will want something better than a BNC to keep this signal clean. 
• I took SR785 TFs of the CM board from IN to the slow and fast outs. They looked reasonable, and will be posted in time. 
• We enabled the 79:1.6k filter in the CM screen (though it is unclear if these are the actual values...), and put in its inverse in the digital path. I.e. we only want this shape in the AO path, to give it 1/f shape in the vicinity of the crossover. This is only necessary in the uncoupled cavity case. 

Steve and I nicely routed the dolphin fiber from c1ioo in the 1X2 rack to the dolphin switch in the 1X4 rack.  I shutdown c1ioo before removing the fiber, but still all the dolphin connected models crashed.  After the fiber was run, I brought back c1ioo and restarted all wedged models.  Everything is green again:

 MC board is out, so don't be surprised that the MC isn't locking.

 MC board is back in place, MC is locked.

If I disable all of the AO path bits of the CM servo (disable switch, and also gain slider to -32dB), and then move the MC IN2 slider around, the MC does not get an offset anymore (as seen by reduced transmission and increased reflected power), so I think the DC coupling is working.  I do lose lock of the MC if the slider goes above ~22 dB in this situation, but I don't see any effect before then, whereas we were able to see a steady increase in the reflected power as we moved the slider around last night.  So, it seems like things are good with the DC coupling of the IN2 slider.

Here are some photos from before I modified the board (front, back, and zoom of the area I was working in):

And here is my modification, putting the 6.8uF cap in series with (a new) 2k thin film resistor, in the spot for R30:

The board is https://dcc.ligo.org/DocDB/0004/D040180/001/D040180-C.pdf

[Edit, 20140721: It looks like this is actually D040180 rev B, not rev C. —Evan]

 (Edited this post; Forgot to account for the FMs other than 4 and 5... it now agrees better!)

I did some quick MATLAB simulation of the relevant loops to try and understand what was going on. I put the digital UGF around 200Hz, and then brought in the AO path with both signs. 

In these plots, blue is digital only, green is AO+digital with the crossover happening at the UGF, and red is the AO gain set to five times of what it was in the green curve. 

Based on the phase curves in the loop measurements, I would be inclined to say the pink -AO case corresponds to the opposite sign plot, and the +AO case to the same sign plot. 

This correspondence also holds for the appearance of the peaks in the noise curves, the Opposite sign case has a dip in loop gain at ~50Hz (pink curve, -AO), same sign around ~30Hz (brown curve, +AO). 

However, both of these look like they become unstable at some point in the transition! This agrees with our experience last night...

I'll fiddle around and try to come up with some compensating digital filter that will make the Opposite sign scenario work. 

The MATLAB code I used to make these plots is attached. 

 I think that's about halfway there. Since this needs to be a precise comparison, we cannot use so many approximations.

We've got to include the digital AA and AI filters as well as the true, measured, time delay in the system. Also the measured/fitted TF of the CM board with the 79:1.6k filter engaged. We want an overall phase accuracy between Jenne's measured TF from last night and this model (i.e. on the same plot with the residual plotted).

Is there a cavity pole in the model? Should be at ~1.6 kHz.

CVI broadband AR coating was measured at the PSL-enclosure table around 9-10am today. The 2W Innolight first PBS  S polarization beam was used with an other 1/2 wave plate and PBS.

W2-PW1-1004-C-633-1064-0   This 0.045" thick window has 0.7- 0.8 % reflected beam on each sides at 5 degrees of incidence, P polarization.

The specification is  R avg <0.5 % per surface at 0 degree

Rana wants The device would be useless with such a high R, but R 0.1% is OK so I will get V coating.

This C1IOO business seems to be wiping out the MC2_TRANS QPD servo settings each day.   What kind of BURT is being done to recover our settings after each of these activities?

(also we had to do mxstream restart on c1sus twice so far tonight -- not unusual, just keeping track)

I wanted to use locate to find some files today, but found that it doesn't index any of our NFS mounted files (i.e. the whole /cvs/cds/ and /opt/rtcds/ ).

So I went into /etc/updatedb.conf and edited it like so, so that it no longer ignores NFS type file systems:

controls@rossa:/etc 0$ diff updatedb.conf updatedb.conf~
4c4
< PRUNEFS="nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf fuse.glusterfs fuse.sshfs ecryptfs fusesmb devtmpfs"
---
> PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf fuse.glusterfs fuse.sshfs ecryptfs fusesmb devtmpfs"

The CRON.daily on ROSSA only should run each morning at 6:25 (under the ionice class 3 protocol as usual). If this seems OK after a week or so, we can do the same for the other CDS workstations (remembering to adjust their cron.daily times so that not every one hammers the NFS at the same time).

We were having unstable MC locking so we did some physical alignment touch up. Use MC suspension bias to have good MC alignment. Unlock MC and align DC beams to center on WFS. Re-lock and things are now stable.

Someone had been feeding bad info to Eric about MC alignments; we do not center the MC WFS beams with the MC locked.

However, in any case, today the MC2-TRANS servo was not being good so I turned it off. We need the real matrix measurement to bring it back.

Rana, Q

After some more matlab loopology (see Qlog), we turned on the AO path successfully. The key was to turn on the 300:80 filter in the MCL path so that it could cross stably with the AO. Then we ramp up the AO gain via the newly AC coupled AO path into the MC servo board.

The POY11 signal looks nice and smooth. For the final smoothness after the overall common gain is ramped up, I turned on a FM7 pole at 300 Hz so that the MC path would keep falling like 1/f^2 and not interfere with the AO path around 1 kHz.

There's not enough gain yet to be able to turn on the Boost. PCDRIVE is ~3 V. Earlier tonight we were seeing the EOM saturation effect maybe, but we re-allocated the gain more to the front end and its all fine now. I think we can get another ~10-15 dB of gain by using the POY whitening gain slider + the CM AO slider. Then we can get the Boost on and take some TFs with the SR785 (as long GPIB allows).

Good Settings:

CM REFL1 = +31 dB, AO = +16 dB, MC IN2 = +16 dB. SUS-MC2_LSC = FM6, FM& ON

** Everything has been pretty stable tonight except some occasional MC/EOM locking oscillations. This means that its been easy to keep trying some different CM steps since the Y-Arm relocks using MCL within seconds.

 Late adition: CHECK all viewport covers.

A, transparent Lexan sheet is protecting glass windows in a horizontal position

B, metal housing protection is required on each viewport except signal ports

C, signal ports should be shielded by optical table enclosure

We have to cover this window-camera with implosion proof cover or just remove it and blank it.

Question number 2: Do our vertically positioned windows with flip able covers require protective lexan ? NO 5-5-2014

 c1sus needed reset.

 CVI V-AR coating at 1064 nm, 0 degree,  catalog item is R< 0.25% on each sides,

 R <0.1 % is custom at much higher prices.

This custom order should go with other  orders that has similar need.

From CVI: 5-6-2014

I checked the trace info on the W2-PW1-1004-C-633-1064-0, BBAR coated window that you received.  It is side 1, 0.42%R & side 2, 0.53%R @ 1064nm.  And with the shift, I’m not too surprised you ended up with 0.7%.  A V coat would start with <0.25% (and more typically coming in at ~0.1%) per surface.  As far as stock options, I have a 1”dia x 4mmT, fused silica window that is recorded as side 1, R=0.09 and Side 2, R=0.08% @ 1064.  Is this too think or will it work for you?

I don't see how the work I did would affect this stuff, but I'll look into it.  I didn't touch the MC2 trans QPD signals.  Also nothing I did has anything to do with BURT.  I didn't change any channels, I only swapped out the IPCs.

I touched up the alignment of the Ygreen on the PSL table.