Following Jamie's table in elog 8654, I have connected up the channels 0, 1 and 2 from ADC0 on the IOO computer to rfm send blocks, which send the signals over to the rfm model, and then I use dolphin send blocks to get over to the ass model on the lsc machine. 

I'm using the 1st 3 channels on the Pentek Generic interface board, which is why I'm using channels 0,1,2. 

I compiled all 3 models (ioo, rfm, ass), and restarted them.  I also restarted the daqd on the fb, since I put in a temporary set of filter banks in the ass model, to use as sinks for the signal (since I haven't done anything else to the ASS model yet).

All 3 models were checked in to the svn.

Measurements:

1. Calibrating offset :

I measured the shift in the beat frequency while scanning through the offset. Offset stepped by 50 resulted in 1MHz shift of the beat frequency.
 

2. Anti-whitening filter for beatbox output:

I made an anti-whitening filter for the beatbox output in the ALS_BEATX_FINE_I module by inverting the whitening filters that Jamie had installed in the beatbox earlier (elog).  I have kept the old anti-whitening filter in the module as well for the time-being because the new anti-whitening filter was not as good as the old one in stabilizing the servo (large error signals and unstable ALS).

3. Beat frequency scan for 3FSR:

With ALS loop enabled, I did an offset sweep corresponding to 3FSR (FSR = c/2L = 3.7MHz). The loop doesn't seem to be stable enough to reduce the arm fluctuation to get a resonance for IR. Time series of scan is shown below:

4. No-loop and in-loop spectrum:

I measured the spectrum of the error signal (C1:ALS-BEATX_FINE_I_IN1) with ALS loop enabled and disabled. To suppress the peaks at 3.2Hz and 16.5Hz, I turned ON the corresponding filters. I have recorded the error signal spectrum with only 16.5Hz res gain filter turned ON. Turning ON res gain 3.2Hz filter kicked ETM. 
Spectrum of error signal shown below:

To resolve:

1. What is wrong with the new anti-whiteing filter?

2. Why would the res gain filters kick ETM and show no noise suppression?

I am proposing a model name change.  Currently, we have an "ASS" model, but we do not have an "ASC" model. 

The ASS is currently using ~17 of 60 available microseconds per cycle.  So, we have some cpu overhead available to put more stuff on that cpu. Like, say, ASC stuff.

So, my proposal is that we change the ASS model name to "ASC", and put all of the ASS-y things in a top_names block, so we retain the current channel names.  The IOO top_names block that is in the current ASS model (which is there to send signals to the LSC DAC for the input tip tilts, even though the names need to be IOO) should obviously stay on the top level, so that things in there retain their names.

Then, I can make a new top_names sub-block for ASC-like things, such as the new POP QPD. 

Inside the ASC block (in the ASC model), I'm currently thinking something simple will do..... QPD inputs, going to a matrix, which outputs to the filter banks in the "length" degree of freedom basis (PRCL, SRCL, etc), then another matrix, going to the ASC suspension paths. 

So, for example, the POP QPD pitch would go to the PRCL_PIT filter bank, and then on to the PRM_ASCPIT path in the SUS screen.

Or, in another example case, IPPOS yaw would go to an input pointing filter bank, then on to TT1's yaw slider.

EDIT:  After a few minutes of thinking, I think I also want triggering, and perhaps filter bank triggering, in the ASC model.  One of the reasons Koji has been pushing for the new automation system is that when the PRC fell out of lock, the ASC path would kick the PRM until Koji ran a down script.  Triggering will fix this issue, and it's the kind of thing that needs to happen quickly, so may not really be appropriate for the Guardian anyway.

I have done a quick update of the IFO_ALIGN screen's save and restore scripts, so that we can now also save, restore, and view the saved values for the input tip tilts. 

In the past, there was an "if" statement to check if the optic was a PZT, and if so, define the alignment channels accordingly (since all the SOS suspensions have the same format for the name, and the PZTs were the odd ones out).  I have removed the mention of PZTs, and replaced the if statement with an "if TTs" statement, and put in the correct channel names (C1:IOO-TT#_PIT_OFFSET, and the same for YAW). 

Also, I caught a bug in the code, which explains some confusing behavior that I had seen in the past.  When deciding if the restore script should take small steps or just do a big step, it looked at the difference between the saved value and the current value of the slider.  It was *not* looking at the absolute value of the difference.  So, if you had misaligned a slider by hand, and it was in the opposite direction of what the misalign script does, the restore script wouldn't realize that the optic needed to be restored in small steps.  I have now fixed this bug for both pit and yaw cases of the restore script.

[Jenne, Jamie, Manasa]

Jamie was working on the MC guardian today (I think he will elog about this soon).

After this, I received the MC locked in TEM00 with MC_REFL at ~2.5 counts from Jamie. Usually the WFS would do their job in this case to bring MC to a good locking condition and since this did not happen, I figured out that something was wrong with the MC_WFS.

What we did:

1. The WFS were turned off. 

2. As a first step, we wanted to run the WFS_OFFSET script (Koji's elog) which requires MC to be locked with MC_REFL<0.5 and spot positions centered. The autolocker was disabled and MC locked manually to MC_REFL<0.5. 

3. While running the WFS_OFFSETS script, Jamie pointed out that the inputs to the WFS servo had been turned off. After the WFS_OFFSET script finished running we turned ON the WFS inputs. 

4. Following this, the MC was relocked manually and MC spot positions were measured (all spot positions were decentered by < 2 mm). 

5. We ran the WFS_OFFSET script again and turned the WFS back ON. But this would still kick the MC out of lock. 
 

Status: MC is locked with WFS turned OFF. Jamie will be looking through what changes he had made earlier today to fix this problem. 

  Red-green laser pointers added to the depleted stock of 2011

The two pointers output measured 4.4 mW green and 2 mW red

Interesting.
What's the reason why the PRMI/MICH ratio gets worse (larger) for 55MHz and 165MHz for the DRMI compared to the PRMI case?

Y arm locked on green carrier in 00 mode!

It locked at almost 280 cts, and the transmitted power on the PSL table is  about 40 uW.

To make it lock on the carrier I had to flip the sign of the error signal in the PDH loop, so I put a phase shifter (a Pomona box with a 23 uF capacitor) right before the LO input of the PDH box (on the model of the X arm).

Tomorrow I will put more details about the power budget and the phase shifter transfer function.

What I did: 

1. Followed the same procedure to enable ALS (http://nodus.ligo.caltech.edu:8080/40m/8703)
2. Enabling ALS servo stabilized the arm fluctuation and the beat frequency.
3. Beat frequency sweep was done (with ALS servo enabled) by changing offset C1:ALS-BEATX_FINE_OFFSET_OFFSET in steps.

Discussion:

The plots, with a log y axis

PRMI:

DRMI:

PRFPMI:

DRFPMI:

Power not on to the POP QPD yet though.  Also, still need to reconnect POPDC.

I have made some plots of the sensing matrix (PRCL / MICH amplitude ratio, and relative angle) versus Schnupp asymmetry for all the configurations that involve the power recycling cavity.  I am still meditating on what they mean for us, in terms of whether or not we should be changing our Schnupp asymmetry.

The Schnupp asymmetry scan starts at 1mm, rather than 0.  Also, recall that our current Schnupp asymmetry is 3.9cm.

PRMI:

DRMI:

PRFPMI:

DRFPMI:

 I have made 3 dongles that go from 2-pin lemo to BNC so that I can connect the 3 QPD signals (X, Y, Sum) to the IOO ADC (Pentek Generic board in 1Y2, which also has the MC channels). 

The interface board with the 2-pin lemo connectors doesn't have anything in the DCC for the document number (D020432), so I asked BAbbott, and he said: "After a bit of searching, I found that on psage 2 of D020006-A-pdf ( https://dcc.ligo.org/LIGO-D020006-x0 ), Pin 1 of each LEMO connector is the + leg, and pin 2 is the - leg.  This means that you should connect the center conductor of the BNC (if you don't have any 2-wire twisted-pair cables around) should be connected to pin 1 of the LEMO, and the outer conductor should be connected to Pin 2.  According to http://il.rsdelivers.com/product/lemo/epg0b302hln/2-way-size-0b-pcb-mount-socket-10a/1305621.aspx Pin one is the top one on the right-angled LEMO."  According to page 50 of the lemo data sheet, pin1 is the one with the mark next to it, when you are looking at the solderable end.

I have edited the daq channels in c1als model.

Added: DQ channels for the error signal (phase tracker output)
Removed: DQ channels that existed for the beat_coarse signals

Installed and restarted the model on c1ioo.
Frame builder restarted.
Changes were committed to the svn. 

It's nice that we are now able to scan the cavity again. We got close to PRMI+one arm one step further.
The calibration of the scan frequency and the evaluation of the in-loop/out-of-loop error signal in terms of (Hz/rtHz) would be necessary.

The beat amplitude looks actually huge aIthough I don't know where you are monitoring.
Talk to Jamie to figure out how much the signal should be at the monitoring point.
If it is more than we are supposed to have, put an attenuator somewhere.

I have placed the lenses and the PDs in their new positions on the POP path.  As Koji had pointed out to me in reply to elog 8663, what really matters to get the beam size I want on the QPD is the distance between the lenses, and not so much the absolute position of the lenses (since the Rayleigh range of the POP beam coming out of the vacuum is so long), so I left the 2" lens in place, and made the distance between the Y1 and the QPD's lens 35 cm. 

I didn't move the camera very much, mostly just enough to get the beam centered on the TV.  I need to check where this is in terms of the beam shape, to see where I should move it to, so that I'm getting useful beam motion information by looking at the camera. 

The steering mirror for the POP110 PD is still between the camera and the steering mirror for the QPD, there's just much less space between those 3 elements than there was previously.  I put the POP110 PD's lens and the PD itself in such a way that the PD is at the focus.

The PD which used to be the ASC razor blade PD has been put back in the cabinet.  The cable that was plugged into it was being used for POPDC.  I will need to switch things back so that POPDC is once again coming from the POP110 PD.  Also, I need to bring over the power supply for the QPD, and lay some cables between the supply/readout box and the IOO chassis (where Jamie has freed up some channels for me).

Also, while I was on the POX table, I was reminded that we need to deal with the ITMX oplev situation, which Gautam detailed in elog 8684.  I will ask Steve to take care of it when he's back from vacation.

 This is nice - how about figuring out how to plot the measurement and model on the same plot? I guess we need to figure out how to go from counts to Watts.

I put in a new version of the modelled plot.  I figured out a different way to keep things generic so the same script can be used for other sites, but writes the names in the same format as the measured matrix, so the correct order is preserved.

The REFL11 measurement is consistent with the one in elog 8648 (data taken a few days earlier), within the error bars.  My goal for tonight is to hopefully get the POP path back in order, so that I can lock the PRMI again, and can measure again if I want.

The error bars for each sensor are only taken once (with no drive, so it's the noise in the "dark" sensor).  I take 6 "dark" measurements for each sensor, and get the stdev.  Then I use that and propagate it through for each measured sensing matrix element.  So, the PRCL and MICH error bars for REFL11 were created from the same standard deviation, and propagated in the same way, but the values plugged into the partial derivative of the function were different for PRCL and MICH. 

(wikipedia - propagation of uncertainties)

Also, to answer an emailed question via the elog, the "0 degree" axis of the plots is the 0 demod phase axis, which corresponds to the I output of the demod boards (the I input to the RFPDs, before the phase rotation).  The "I" axis that I've drawn is the current demodulation phase that we have, which corresponds to the I_ERR output of the RFPDs after the phase rotation, which is the PD_I signal that goes into the LSC input matrix.  I draw this to help us see if our current demod phase is well tuned or not.

Yes, the MICH and PRCL signals are not at all orthogonal in the REFL33 sensor.  I think this is because our modulation frequency was chosen to be good in the case of the full DRFPMI IFO, not the corner IFO cavities.  As I calculated in elog 8538, the ideal frequency for the PRMI is 18kHz larger than our current modulation frequency. 

For the plots below, note that 11.066134 MHz is our current actual modulation frequency, and 11.0843 MHz is my calculated ideal modulation freq. 

Model, using our current modulation frequency, and the designed PRCL cavity length (same as elog earlier today):

Model, using the "ideal" PRMI modulation freq, and the PRCL cavity length used in elog 8538, where I calculated that number (a few cm different than the design PRCL length):

You can see that if we could use a better frequency, we would get much, much better signal separation.  Since our modulation frequency choice is related to our vacuum envelope constraints (we can't make the arms of a length that will have the sidebands exactly antiresonant when the arms are locked on the carrier), I hope that this will not be a significant issue in aLIGO. 

-The reflection is measured when the cavity is unlocked. I measured it with the power meter in front of the PD, so I interrupted the PDH loop.

- From the specs of ETM we have:

T(S1,HR,532nm)=5.0%+/-3% (+/-1% target),  R(S2,AR,532nm)<1000ppm

It means that I should have about 600-550 uW in reflection, but I don't. I can say that there are many losses, and maybe some power is clipping inside the Faraday. Nonetheless, the reflected beam looks less strong than the injected one, so most of the losses should be on the ETM table.

(- The reflected power is 0.090 mW, I just wrote it wrong yesterday, sorry!)

- The last question is actually very interesting. Maybe I was locking on the sideband when I locked to 30 cts, but if it is the case I cannot really explain why today I locked on the carrier (I locked the cavity to about 200-250 cts), and everything I changed was the PD gain and the amplitude on signal generator connected to the PDH box. It seems like there should be some sign flip somewhere, but I need to think about.

Stabilized ALS and beat frequency sweep realized.

Procedure:

1. Enable appropriate filter modules and set appropriate servo gains.

2. Clear history of C1:ALS-BEATX_FINE_PHASE

3. Enable the servo loop. I had set limits on the servo loop and ramp time for gain switching so that I don't kick the ETMY hard.
Gains were decided such that the error signal C1:ALS-BEATX_FINE_PHASE_OUT was minimized.

4. Beat frequency sweep is realized by stepping up on C1:ALS-BEATX_FINE_OFFSET_OFFSET (from 0 to 2100 in this case).

Video1 shows the difference that can be seen at the RF spectrum analyzer when ALS is enabled.

Video2 shows the beat frequency sweep as seen on the spectrum analyzer.

I could not get 'getdata' to work as I wanted. So I have attached the error signal trend before and after the ALS servo loop is enabled.

Thank you Jenne for helping retrieve more sensible data!

More info:
The beat note is very strong and we can clearly see its harmonics as well. Attached is the picture showing the several harmonics.
________________________________
Peak frequency(MHz)    Power(dBm)
________________________________
 47                                    -2.77
 93.5                                -27.56
 139                                 -32.75
 185.4                              -45.64
 231.9                              -57.10
 278.4                              -59.42
________________________________

To do:
1. Obtain IR resonance.
2. Check the digital anti-whitening filter after the beatbox.
3. The effect of the harmonics should be figured out.
4. Write scripts to enable ALS and findIRresonance.

I'd repeat the measurement for REFL11. The PRC arrow has some big error bar on it, and maybe the true error is even bigger.

Also, please make the placement of the plots the same for modeled and measured so it's easy to compare.

Is this reflection measured with the cavity locked or unlocked?

So what's the actual designed reflectivity of the ETM for green? No one seems to be able to give me a straight answer about this.

Looking at the reflected beam when the beam is misaligned makes it look like it's << 0.9. Is that expected given the coating spec?

You say the cavity scan goes as high as 300cts but you can only lock to 30cts, are you locked on the sideband?

Using all of the latest parameters that I can find, I have re-modeled the 40m sensing matrix.  Also, I have it output the data in a format that can be used by the same plotting function as the measured sensing matrix, so they are nice and easy to compare.

The newly modeled 40m sensing matrix:

To compare, here is the measured sensing matrix from elog 8644:

Notice that (a) the units are different, so don't focus too much on the amplitudes of the lines, and (b) all of the measured and modeled matrix elements are pretty similar, except for the REFL11.  REFL11 (top right in model plot, top center in measured plot) looks like it's flipped, as well as rotated.  The new model doesn't match up too well with the Kiwamu/Koji models (which matched eachother okay), but I like that the new model matches the measurements fairly well.  The Koji sensing matrix: on the 40m wiki

EDIT: I have replaced the modelled plot with a new version.  The data and numbers are the same, but I have switched the labels on the individual radar plots, and forced them to be in the same order as they are in the measured plot.

> > Hmmm.  You seem to be saying that more light is reflected than is injected. Is this a units problem? Or was some IR on the power meter during the 'reflected' measurement? 
> > We should look at it with fresh eyes in the morning. 
> 
> Also, if you have been measuring the power of green refl at the rejection port of the green faraday, the polarization of the light entering the green faraday should be checked once again to make sure that you are measuring 
> only the reflected power from the arm cavity.

Sorry Sorrry Sorry!!
It was 0.090 mW, I just forgot a zero!!!
Sorry!

> Hmmm.  You seem to be saying that more light is reflected than is injected. Is this a units problem? Or was some IR on the power meter during the 'reflected' measurement? 
> We should look at it with fresh eyes in the morning. 

Also, if you have been measuring the power of green refl at the rejection port of the green faraday, the polarization of the light entering the green faraday should be checked once again to make sure that you are measuring 
only the reflected power from the arm cavity.

Hmmm.  You seem to be saying that more light is reflected than is injected. Is this a units problem? Or was some IR on the power meter during the 'reflected' measurement? 
We should look at it with fresh eyes in the morning. 

After restoring alignment I could see again strong 00 flashes (about 250-300 counts on ALS-TRY). So I locked the arm with IR and after enabling the PDH servo for the green locking, I also locked the green on the Y arm in 00 mode. Then I moved the two mode matching lenses to maximize the power into the 00 mode, but I didn't reach more than 30-35 counts.

Green power injected into the Y arm                    0.680mW

Green power reflected back                                  0.090mW

Green power transmitted on the PSL                  few uW

I would expect more power on the PSL table (maybe 10x more).

 For the mode matching calculation I was using the ETMY focal length that I found on Kiwamu's plot on the wiki page. 

Taking into account also the substrate, the focal length turns out to be

fl = ((n-1)*(1/R1 - 1/R2 + (n-1)d/(nR1R2)))^(-1) = -125.81 m

with n = 1.46071 (refraction index of fused silica at 532nm)

R1 = 5625 m (radius of curvature of the first surface)

R2 = 57.37 m (radius of curvature of the second surface)

d = 25mm (thickness)

The value of the focal length is sligthly different from the one I was using before in the calculation, but maybe it is enough to change the coupling.

The mode matching solution I found is very sensitive to the lenses position. 

The beam waist position can vary up to 20m varying by 1cm the first lens position, while it is slightly less sensitive to the second lens displacement.

As shown in the picture, along the green beam path there is also a 1m focal length lens. It's position is fixed, because it is along the IR transmetted beam path also. I tried to get a better solution without it, but I found that the waist position was still strongly dependent on one of the two lenses position, so it would not solve the problem to remove this lens.

I think that the main issue of this mode matching is related to the "space contraints", because the two lenses' positions can vary in a very small space, even though the green beam path on the table is quite long.

Eventually, I put the MM lenses found from this last simulation on the table, and it seems to work, since I've seen very strong 00 flashes. Unfortunately, while trying to maximize the alignment I broke it  and I have to do it again, but I feel confident! 

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.

 Also make sure you are taking into account the substrate of the ETM.

Still no good locking!

After making the reflected beam size closer to the injected one, I maximized alignment. I locked again in 00 mode, but I couldn't maximize the power. 

I just realized that maybe I'm not using the correct radius of curvature for the ETMY in the simulation. Tomorrow I will start checking from that.

[Annalisa, Nic]

After connecting the PD with the reflection from the arm  to the PDH box, theY  arm has been locked on the 01 mode.  Maximizing the alignment, we obtained a 00 mode locking, but we couldn't maximize the power.

The size of the reflected beam was different with respect to the size of the incoming beam, so probably a bad mode matching was one of the issues.

Moreover, the reflected beam is very low power. We need to figure out why it is so (bad alignment? related to mode matching?)

After measuring better all the distances, I did a new mode matching calculation. I put the lenses after measuring the beam waist, so the size of the beam on the lenses was the same as expected from the calculation. Nevertheless, the beam size on the beam splitter looks bigger than expected, and also in this case green flashes into the cavity at some HOM (again 01).

I also tried to lock again the cavity and maximize the alignment, but I didn't get any improvement with respect to the previous mode matching.

http://nodus.ligo.caltech.edu:8080/40m/7885

To allow Annalisa to work on the Y-green alignment as I work with the X-green, the part of the PSL green beam that goes to the Y-green beat PD has been blocked with an iris.

 [manasa, gautam]

-the replacement lamp arrived a while back.

-the old lamp has been switched out, it had 3392 lamp hours on it.

-new lamp installed, projector mounted back up, and lamp hours reset to zero. there is a lingering odour of something burning, not sure what it is or if it is in any way connected to the new lamp. old lamp disposed in the hazardous waste bin. the big screen is back online.

 Updated laser inventory and operator list. They are posted in the 40m wiki and entry doors of the 40m IFO room.

Let me know if this list needs correction.

Lightwave  M126N-1064-700 NPRO sn 337 in the PSL enclosure got connected to local emergency shut off switch. This is a LIGO operational safety requirement.

Replaced the batteries successfully in the control room.  We just had to switch the clips from the old batteries to the new one, which we didn't know was possible until now.

 Thin wall connector from McMCarr#55275K25 was tested in 150 mW, 1 mm beam size of 1064 nm  overnight. It did not show any degradation.

 [Jenne, Gautam]

It turned out that the earlier fix was not really a fix, because there was some confusion as to which of the two lenses Jenne moved while working, and while Manasa and I were re-aligning the beam, we may have moved the other lens.

Subsequently, when we checked the quadrant sum, it was low (in the region of 20), even though OPLEV_PERROR and OPLEV_YERROR were reasonably low. We called up a 30 day trend of the quadrant sum and found that it was typically closer to 4000. This warranted a visit to the table once again. Before going to the table, we did a preliminary check from the control room so as to make sure that the beam on the QPD was indeed the right one by exciting ITMx in pitch (we tried offsets of 500 and -500 counts, and the spot responded as it should). ITMx oplev servo was then switched off.

At the table, we traced the beam path from the laser and found, first, that the iris (I have marked it in one of the photos attached) was practically shut. Having rectified this, we found that the beam was getting clipped on the first steering mirror after the laser (also marked in the same photo, and a second photo showing the clipping is attached). The beam isn't very well centred on the first lens after the laser, which was the one disturbed in the first place. Nevertheless, the path of the entering beam seems alright. The proposed fix, then, is as follows;

1. Use the existing iris and a second one to mark the path of the entering beam.
2. Make the necessary adjustments (i.e. move the lens immediately after the laser and the first steering mirror after the laser) such that the direction of the entering beam is unchanged, and the clipping and centering problems are resolved. 

Back in the control room we noticed that the quadrant sum had gone up to ~3500 after opening out the iris. The OPLEV_PERROR and OPLEV_YERROR counts however were rather high (~200 counts in pitch and ~100 counts in yaw). Jenne went back to the table and fixed the alignment such that these counts were sub-10, and the quadrant sum went up to ~3800, close to the trend value. 

At the time of writing, the beam is still not centred on the lens immediately after the laser and is still getting clipped at the first steering mirror. Oplev servo back on.

Photos

 An overview

The clipping

 Wrong: this is not an interface.

• Shipping Estimate Friday June 7, 2013 - Monday June 10, 2013

  Delivery Estimate: Wednesday June 12, 2013 - Monday June 17, 2013 by 8:00pm
• 
  Sold by: Lampedia

Thank you Ben Abbott forwarding this information:

 QPD Amplifier D990272 https://dcc.ligo.org/cgi-bin/private/DocDB/ShowDocument?.submit=Number&docid=D990272&version= at the X-end.  It plugs into a Generic QPD Interface, D990692, https://dcc.ligo.org/cgi-bin/private/DocDB/ShowDocument?.submit=Number&docid=D990692&version= according to my drawings, that should be in 1x4-2-2A.

The rejected beam from the Faraday is steered with a mirror into the PDA32A PD  and a 75mm fl lens is used to focus the beam into it.

The main beam is a few millimeters away from the mirror mount (maybe 2mm), and I think it should be fine as long as the main beam is not supposed to move.

 [Jenne, Annalisa]

DQ channels have been created in the C1ALS model for TRX and TRY. They are called TRX_OUT and TRY_OUT and the sampling rate is 2048 Hz.

Most dependencies are met.  The next issue is that matplotlib.basemap is not installed, because it is not available for our version of python.  We need to update python on megatron to fix this.

The rejected beam from this Faraday comes out at a tiny, tiny angle and so its tough to pick it off without clipping the main beam.

Some care must be taken in setting this up - Steve may have some good ideas on what kind of mount can be placed so close to the beam.

Why did we ever order this terrible Faraday? Let's never get a Faraday with a tiny angle between the beams again.

 There were 4 cables running over the front side of rack 1Y4 such that the front door could not be closed. I re-routed them (one at a time) through the opening on the top of the rack. The concerned channels were

• Green refl mon
• Err mon
• Pzt out (temp) (has been marked "Door Damaged BNC")
• Laser temp ctrl

Before and after pics attached.

Before

.

After

Update: We don't have our BIG screen 

There was no light from the projector when I came in this morning. I suspected it might have to do with the lifetime of the bulb. But turning the projector OFF and ON got the projector working....but only for about 10-15 seconds. The display would go OFF after that. I will wait for some additional help to dismount it and check what the problem really is.

 [Annalisa, Gautam]

 The green beam alignment has been improved, so we see much more 00 bright flashing. We checked the polarization and the Ygreen shutter is back in place.

A mirror is already in place to steer the rejected beam from the green Faraday into a PD, tomorrow morning we'll put a lens and the PD to take the signal for PDH locking.

The FSS SLOW actuator often runs off away from zero and into a region where the mode hopping is bad and makes a lot of frequency noise (e.g. that 8 hour period a few weeks ago when Jamie couldn't lock the MC).

It should not have this behavior. The SLOW loop should only be running when the MC is locked.

Today I found that the threshold was set back to 0.2 V (which is approximately the correct value for the RefCav locking). Its being compared to the MC TRANS, so the correct value should be ~1/2 of the maximum MC TRANS.

To find this out, I read this piece of text:

    # Make sure the loop is supposed to be active
    if (get_value("C1:IOO-MC_TRANS_SUM") < get_value("C1:PSL-FSS_LOCKEDLEVEL")) {
    print("Reference Cavity not locked -- control loop disabled.\n");
    next;
    }

from scripts/PSL/FSS/FSSSlowServo. I set the threshold using the commmand:

caput -c -t C1:PSL-FSS_LOCKEDLEVEL 12000

Then I restarted the code on op340m, by typing:

> nohup FSSSlowServo

and then closing the terminal. Seems to be behaving correctly now. Previously, the value was so low that the SLOW loop was never turning itself off.