I took over the IFO, after Jenne's locking efforts, which included manual alignment, since the ASS was doing bad things. 

For whatever reason, the Yarm ASS TT gains needed to be flipped back to go in the right direction. I've restored the old BURT snap file, and the ASS seems to work for now.  

Furthermore, I added some FMs to the Yarm ASS to be able to ramp down gains, to be done as new offsets are ramped in, so that a smooth offset transition is possible. The new version of the script works reasonably, but could be smoother still... Once I iron this out, I'll do the same change to the Xarm, and update the buttons. 

In any case, I was able to run ASS on both arms; single arm lock maxed out at around 0.85, maybe because we're only getting 0.78 from the PMC and 16k from the MC? I then aligned and locked the PRM, then reentered the oplevs on all of the PRMI optics. Oddly, the ETMs were at single uRads on their oplevs.

With this arm alignment, I was able to get the green TRX to ~0.55, and thus the beatnote to around -25dBm, which is still lower than we'd like. I didn't touch the Y green alignment, though it is pretty bad, at transmission of below 0.2 when "locked" on the 00 mode. 

When I try to lock things, the initial ALS CARM and DARM locking seems to go fine, actuating on the ETMs for both DoFs, but ETMX is getting kicked during the resonance search every time. Maybe improving green alignment / increasing beatnote amplitudes will hopefully help some.

I'm leaving the interferometer with the PRM aligned, so that all optics (except SRM) are near the center of their oplev range. I'm curious as to what their variance will be over the next day; this can inform whether we need to improve the ETMY oplev's angular range or not. 

 There was still some residual permissions issue. This is now bypassed and so the ACL is ON and all seems to be back the way it was. I've tested that I can login and edit the wiki.

Some useless knowledge follows here. Please ignore.

After some hours of reading unhelpful DokuWiki blogs, I just put the backup wiki into the local disk on NODUS and then made a soft link to point to that from /users/public_html/wiki/. So this implies that the new NFS setup on chiara is different enough that it doesn't allow read/write access to the apache user on the NODUS/Solaris machine.

Here's the magnitude plot of the board TF. As mentioned above, this was done with Marconi+Scope, so we were not able to get the phase of this transfer function. 

Oddly enough, the bump that I saw is not included in Minicircuit's data on the SCLF-5.

SCLF-5!? It's surprising as the cut off of the OLTF is just above 1Hz. cf this entry

This means that not the demod board but MC or FSS boards seem to have large attenuation above 1MHz.

In this situation, does SCLF-10/10.7 really help us?

We measured the TF of the MC Demod board today.

We set the Marconi to +3dBm and drove the PD IN port of the demod board, starting at 29.5 MHz. Then we looked at the beat signal amplitude in the output of the demod board. So this is a transfer function but with mag only. Plots from Q below.

Rana took the demod board out and took pictures of it. Inside, the post mixer low pass is a SCLF-5 from mini-circuits. This has a lot of cutoff down low. Since the purpose of this filter is only to cutoff the 2f-1f and the 3f-2f products, we need to have a lot of attenuation at 29.5 MHz. One day, we may want to re-instate that notch for the (3*f1- f_MC) beat frequency, but for now we want stability.

So, I recommend that we (Steve) get 3 each of the SCLF-10 and SCLF-10.7 from Mini-Circuits Tuesday morning. Maybe we can put them into a spare board?

Also, we should probably remove the 140kHz:70kHz lead filter which is in the MC servo board. Its out of date. I think it would be fine for us to get a 7-15 kHz UGF for the CM servo and the MC can basically do that already. Mainly we want to fix the high frequency shape to get more stability.

After the measurements and photos, we had to reset the MCWFS offsets to get the WFS to not break the lock. Seems very sensitive to offsets. Hopefully Andres will give us a new Gouy phase telescope.

      May  13, 2014             ETMX,  .............laser in place 90 d

      May  22, 2012             ETMY, 

     Oct.  7,  2013             ETMY,  LT  503 d  or  1.4 y............bad beam quality ?

     Aug. 8,  2014              ETMY,  .............laser in place   425 days  or  1.2 y

The Y End laser dumped SHG light has been coupled into the yellow fiber that terminates at the PSL table.

It's not super stably coupled, and only at 5mW. I'll be interested to see what it is on monday.

Eric's OLTF turned out consistent with the AO path TF that has been measured by me on Jul 31 (entry 10322).

Attachment 1:
Updated empirical fit of the open loop TF by LISO.
In this fit, I gave some of the poles/zeros associated with the boost manually set so that I can use them for the servo design.
LISO itself can make better fitting if all of the variables are moved.

Atatchment 2:
The OLTF data and LISO source for the fitting.

Attachment 3:
Comparison of the AO path TFs. The red one was measured directly on Jul 31. The TF is normalized at the low frequency.
The blue was estimated from the OLTF model given above. They are well consistent now.

Attachment 4:
Now some servo design was tried. In the new design (blue), zeros of the super boost frequency was moved from 20kHz to 30kHz
with the hope of having flatter AO response. The improvement is very little while costing costing above 100kHz. Note that the vertical
axis is intentionally in a linear scale. In fact, the AO response is much improved compared to the one before the MC UGF was increased
(shown in magenta). We have a flatter response both in magnitude and phase.
Therefore I think there is no need to tweak the boost frequency for the AO path.
I'd rather recommend to inspect the high frequency LPFs to earn more gain margin at 1MHz as explained in entry 10322.

Attachment 5:
This figure shows the comparison of the TFs for the current and new design trial, just in case someone is interested in to see.

 The guy from physical plant came, and turned off the water to the kitchen sink.  He is putting in a work order to have the plumbers come look at it on Monday morning.  It looks like something is wrong with the water heater, and we're getting water out of the safety overpressure valve / pipe.

The wet things from under the sink are stacked (a little haphazardly) next to the cupboards.

 When I got back to the lab, there was enough water that it was seeping under the wall, and visible outside. Physical plant says it will take an hour before they can come, so I'm getting dinner, then will let them in.

The closed gain I meant is the AO path: Use IN2 to excite the MC loop and measure IN1 using MON2(?).
In order to obtain the open loop gain from this meausrement, the gain mismatching needs to be compensated, though.

This measurement is to correctly predict the AO path response from the open loop transfer function.

Anyway, the openloop gain seems nicely measured. I'll try to predict AO path response from this.

 The PDFR system has been documented in the 40m wiki and all the relevant information about making changes and keeping it updated have been mentioned.

https://wiki-40m.ligo.caltech.edu/Electronics/PDFR_system

This pretty much wraps up my SURF 2014 project at the 40m lab. 

 I did some further measurements, to try and see what corresponds to what. In the end I performed four measurements:

1. Closed loop gain measurement on SR785: Source to MC exc, T'd to channel one. Test 2 to channel two.
2. Open loop gain measurement on SR785: Source to MCexc, Test 2 to channel one, Test 1 to channel two.
3. Closed loop gain measurement on AG4395: RF Source to MC exc, T'd to R input. Test 2 to A input.
4. Open loop gain measurement on AG4395: RF Source to MC exc, Test 2 to R input. Test 1 to A input.

I then converted OLGs to CLG and vice-versa with CLG = 1/(1-OLG)

Here are two plots showing the measured and inferred loop TFs for both closed and open. 

The best agreement seems to be between the directly measured OLGs. Maybe I did something weird with the CLG measurements, or input impedances are distorting things ... 

All data is attached, along with code used to generate the plots. 

 The attached in a zip file are the Simulink feedback loop models for the FOL for both X and Y ends. The controller PID values are estimated by setting a temperature count reference point to 5344, which corresponds to 100 MHz frequency.  The plant transfer function is as calculated in my previous elogs.

 We were not  able to test the PID loop , with the green laser by PZT actuation because of the misalignment of the arms and non-existence of the beat note since last few days. However, we have a complete idea of the design and PID parameters that will be used for the FOL with infrared laser. So we decided that it would be better to test the loop by temperature actuation after the fiber optics is installed and the coupling of infrared laser into the fiber is complete. As of now, we have planned to place the FOL box inside so that it can be used to obtain the green laser beat note on the StripTool graphs. 

 The scripts written for interfacing the FC with R Pi, building EPICS database, piping data into EPICS channels,PID loop for FOL are contained in :

 /opt/rtcds/caltech/c1/scripts/FOL 

The instructions to run these codes on R Pi( controls@domenica) will be available on FOL 40m wiki page.

Also instructions regarding EPICS installation on R Pi and building an EPICS SoftIoc to streamline data from hardware devices into channels will be updated shortly.

I have measured the current boosted MC CLG below 100kHz with an SR785. Swept sine only could get me down to 10kHz, but I was able to get down to 5kHz with a noise-injection measurement. 

I am attaching the SR785 outputs, which are in dB and Degrees. Additionally I pruned the areas of bad coherence out of these, and merged them to provide data files for the CLG and OLG in Real,Imaginary format.

                  2005              ALL oplev servos use Coherent DIODE LASERS # 31-0425-000, 670 nm, 1 mW

    Sep. 28, 2006              optical lever noise budget with DC readout in 40m,  LIGO- T060234-00-R, Reinecke & Rana

    May  22, 2007              BS, SRM & PRM  He Ne 1103P takes over from diode

    May  29, 2007              low RIN He Ne JDSU 1103P selected, 5 purchased sn: T8078254, T8078256, T8078257, T8078258 & T8077178 in Sep. 2007

    Nov  30, 2007               Uniphase 1103P divergence measured

    Nov. 30, 2007               ETMX old Uniphase 1103P  from 2002 dies: .............., running time not known......~3-5 years?

    May 19, 2008               ETMY old Uniphase 1103P from 1999 dies;.....................running time not known.....~    ?

    Oct.  2, 2008                ITMX & ITMY are still diodes, meaning others are converted to 1103P earlier

                     JDSU 1103P were replaced as follows:

   May 11, 2011                ETMX replaced, life time 1,258 days  or 3.4 years

   May 13, 2014               ETMX , LT 1,098 days or 3 y

   May 22, 2012               ETMY,  LT 1,464 days or  4 y

   Oct.  5, 2011                BS & PRM, LT 4 years,  laser in place at 1,037 days or 2.8 y

   Sep. 13, 2011               ITMY  old 1103P &    SRM    diode laser replaced by 1125P  ..........old He life time is not known, 1125P in place 1,059 days or 2.9 y

   June 26, 2013              ITMX 622 days or 1.7 y    note: we changed because of beam quality.........................laser in place 420 days or 1.2 y

  Sep. 27, 2013               purchased 3 JDSU 1103P lasers, sn: P893516, P893518, P893519 ......2 spares ( also 2 spares of 1125P of 5 mW & larger body )

 I'm currently in the process of coupling dumped SHG light from the Y arm end table into fibers for FOL.

The main point is that the NPRO at that end in shuttered, because I wasn't sure whether or not leaving it open would've set anything on fire.

 I noticed some weird behavior on the ETMY oplev that led me to check them all out. 

The short of it is that the ETMY oplev has a pretty small angular range, compared to the displays and other oplevs. I measured how much angular motion each oplev can sense before the beam no longer hits all four quadrants (thus losing the ability to sense).  This could account for some of the additional angular motion of the mirrors... maybe. 

Also, some of the QPD quadrants had offsets as big as 400 counts, thus distorting the zero point. Anyways, here are the angular ranges of each QPD, assuming the current urad/cnt calibrations are valid. 

EMTY

• P: +- 25urad
• Y +- 30urad

ITMY

• P:+-160urad
• Y:+-172urad

BS

• P:+-43urad
• Y:+-40urad

ITMX

(Note: ITMX's oplev pitch and yaw is almost 30 degrees off of the alignment sliders' pitch/yaw coordinates. Steve tells me this is due to the tight nature of getting the oplev beam to the mirror without clipping.)

• P:+-110urad
• Y:+-80urad

ETMX

• P:+-45urad
• Y:+-85urad

PRM

• P:+-50urad
• Y:+-45urad

SRM

• P:+-80urad
• Y:+-80urad

I wrote a script to zero all of the QPD quadrants' offsets (it lives in /scripts/OL) and have used it successfully. The oplev laser must  be off before using it. 

 Purpose

I wanted to do a more robust measurement of PER of PM fibers for FOL, so I thought up this scheme.

Methods

I put together a setup as depicted below in order to take measurements of PER.

The first thing to do was to calibrate the whole setup. In order to do so, I first used the quarter and half wave plates closest to the NPRO to eliminate as much ellipticity from the output beam as possible, and then rotate the newly linearized light to be in alignment with the transmittance of the first polarizing beam splitter (P-Polarization).

I then aligned the fiber's fast axis with the P-Polarization on both the input and output sides. This was important so that no virtual ellipticity would be measured in the final measurement of PER.

I then mode matched and fiber coupled the first PBS output into the fibers, to about 30 mW (~60% coupling).

Photodiode Calibration

I wanted to measure both intensity of P and S simultaneously, so as to minimize the random little time-varying changes that would affect the measurements, so I used a powermeter and a PD, calibrated with the aformentioned powermeter.

In order to be able to compare the photodiode (PDA520) output to the powermeter (Orion) output, I fixed them each in their positions, and varied the laser power to produce the type of linear relationship we expect to see between PD Voltage and Optical Power. In this case, the conversion was P = V*2.719.

PER Measurement

As opposed to the first method, which took only one datum, this method records P and S simultaneously, at different points through rotation of a linearly polarized beam.

Using the second HWP, I rotated the linearly polarized beam before it entered the fiber, at each point, recording the outputs of the PD and the Powermeter.

These data were then converted to be the same units, and fit to a sine wave.

As you can see, the intensities vary nearly identically, at a half wavelength phase difference, which is what one expects in this case. The PER of each polarization can be calculated by dividing the maximum value of one by the minimum of the other, and vice versa. The fact that these oscillate as we expect shows that the beam is relatively well linearized, and essentially that everything is working as it is assumed to be.

By looking at these fits, however, it is visible that they do not overlap with the actual extrema of the data. So, in order to produce more realistic values of extrema, those particular regions were fit to second order polynomials.

The values of these extrema yield the following measurements:

(SMin / PMax) = 0.007 +/- .004  --->  -21.54 +/- 2.48 dB

(PMin / SMax) = 0.022 +/- .009  --->  -16.58 +/- 1.78 dB

Conclusion

The problem I find with these measurements is that they're hard to reproduce.

Plus they seem high, since non-PM fibers advertise extinction ratios around -30 dB., plus I measured it at roughly -24 dB the first time I tried.

Moving Forward

The next thing to do in terms of fiber characterization is to measure the frequency noise they introduce.

With respect to FOL, I just need some time to work on the PSL table, and at the Y end to couple the dumped SHG light, and then we can start using 1064nm beat notes to test//implement the feedback control system.

1)The PDFR scripts have all been migrated into /scripts/PDFR/

2) The MEDM screen to run PDFR is /medm/MISC/PDFR.adl

3) A new button has been added on sitemap to open the above medm window.

4) All data and plots generated will sit in /scripts/PDFR/"PD Name"/

5) All features are working after the migration and absolute file paths are being used.

Work Remaining : Manual for others to make changes and keep using my system.

Yesterday, Q helped me look at the DACs for some of the suspensions, since Gabriele pointed out that the DACs may have trouble with zero crossings.  

First, I looked at the oplevs of all the test masses with the oplev servos off, as well as the coil drive outputs from the suspension screen which should go straight out to the DACs.  I put some biases on the suspensions in either pitch or yaw so that one or two of the coil outputs was crossing zero regularly.  I didn't see any kicks. 

Next, we turned off the inputs of the coil driver filter banks, unplugged the cable from the coil driver board to the satellite box, and put in sinusoidal excitations to each of the coils using awggui.  We then looked with a 'scope at the monitor point of the coil driver boards, but didn't see any glitches or abnormalities.  (We then put everything back to normal)

Finally, I locked and aligned the 2 arms, and just left them sitting.  The oplev servos were engaged, but I didn't ever see any big kicks. 

I am suspicious that there was something funny going on with the computers and RFM over the weekend, when we were not getting RFM connections between the vertex and the end stations, and that somehow weird signals were also getting sent to some of the optics.  Q's nuclear reboot (all the front ends simultaneously) fixed the RFM situation, and I don't know that I've seen any kicks since then, although Eric thinks that he has, at least once.  Anyhow, I think they might be gone for now.

 Dang it, I completely forgot.  Well, anyhow, it pulled itself back down to less than 1V, and the MC stayed happy for several hours.  I'm not totally sure what changing the offset did, but the MC seems happy for right now.  I should take a quick look at the error point to make sure that I didn't mess up your tuning.

LISO Fit for the IMC open loop TF. The data and liso source for the fitting were attached in the ZIP file.

I noticed now that the open loop TF I measured has too less phase delay.
I used the closed loop TF to estimate the openloop TF.

Looking at this comparison, I'm afraid that the superboost was not on during the measurement.
I need a new measurement to design MC loop modification to give the AO path for broader bandwidth.

The fast feedback should be around zero now!

The MC has been unstable and unhappy for the last several hours.  When I looked, I saw that the FSS_FAST monitor has been hovering around 1 V, when it is supposed to be closer to 5ish. 

I changed the C1:PSL-FSS_INOFFSET from -0.08 to -0.8537, and will see if the MC sticks around for longer this time around.

I've checked out cdsutils-274 to /opt/rtcds/cdsutils, and updated the /ligo/apps/ligoapps-user-env.sh to have the newer machines use it by default. This was to gain access to the cdsutils.Step methods for use in the smooth ASS handoffs script. 

This is nice. Can we test this idea with POP22 + a razor blade?

Just to take transfer functions in PRMIsb between the PRM angle to POP QPD/POP22+razor blade
as well as the noise spectrum measurement are already useful.

We want to figure out the requirement for the 2f QPD.
(Transimpedance / Noise level / Beam size / etc)

Depending on the requirement we'll see if we need demodulation or just a power detector.

 In addition to the simulation described in my previous elog, I simulated the signal on a quadrant photodetector demodulated at 2F. The input laser beam is modulated at 11MHz up to the fifth order. There is no additional 55 MHz modulation.

The QPD demodulated at 2F shows good signals for PRC control for all CARM offsets, as expected from the previous simulation.

Last Week

Took first round of PER measurements after a long setup.

Started setting up to take measurement of the other polarization--ran into issues with mounts again. (Spinning of their own free will again.)

Devised a new scheme for taking more robust measurements of PER--still in progress.

Next Week

Finish data analysis of these latest PER measurements

Hopefully finally move on to frequency noise characterization

Materials Needed

None for PER

Unknown for frequency noise

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.

 Today I and EricQ went inside the lab and set up the cables running from the a DAC channel into  PZT input so that we can use the PID controller to tune in the PZT offset to maintain the beat note within a detectable range (This is plan B as the main plan of actuating on the laser temperature can be achieved only after the fiber setup with the PSL is ready). I obtained all the poles and zeroes of plant and started designing a PID loop to test it with the existing system.

I will put in my PID values into the already existing PERL controller code (that is used for controller design in the 40m) and run tests with the PID loop while actuating on the PZT offset. 

 Finally,  the efforts put in the Frequency Counter paid off . I tested the working of both the FC and EPICS channels that I created by displaying the beat note on MEDM screens. EricQ helped me locking the X arm ( Y arm free) thus acquiring only the X arm beat note from the frequency counter. We plotted the beat note on MEDM and clearly could see a stable beat note when the arm was locked. Now it can be said that the FC(two of course) can replace the spectrum analyzer outside and also get the beat-note frequencies  into EPICS channels. The channel names of these two beat note frequencies are:

X Arm:          C1:ALS-XBEAT_FREQ_MHZ

Y Arm:          C1:ALS-YBEAT_FREQ_MHZ

(Note: There are many problems in alignment of the arms and we could have beat note only for some time after putting a lot of effort).

The PDFR system now has the capability to automatically run vectfit3.mat using a wrapper script named vectorfitzpk.m

This is done via a shell script being called from inside python that inturn runs the matlab script.

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.

Q is working on fixing the "save offsets" script for the ASS, because that has lost me my alignment two more times in the last few hours.  But, right now I have both arms locked with transmitted powers of about 0.9!  To get this, I ran the ASS scripts, and hand-tweaked the bias sliders of some of the optics to relieve the ASS outputs.  Then I turned the ASS gain to zero, and by-hand turned off the oscillators.  So, the ASS outputs are just frozen. 

I haven't seen IMTX suspension kicks, I think since Q did the front end reboot earlier. There has been ITMY activity, however. I think I'm going to be bold, and try locking ALS.

TRX and TRY communication were recovered by doing a simultaneous reboot of all of the frontends.

Working with the interferometer has been extremely frustrating today. Having transmission values let us lock and ASS, but that has been less helpful than you would hope.

Saving the ASS offsets has repeatedly resulted in an overall bad change in alignment, moving the TTs and other things off randomly.

ITMX continues to be kicked. ITMY intermittently wanders away. It has not been possible to maintain IFO alignment for a reasonable length of time.

Also, the wall IOO striptool shows the MC2 Trans QPD Yaw having large step-function features. The MC is having an ok duty cycle, but this just may mean that the WFS are able to absorb what is happening to the MC suspensions.

The suspensions are really misbehaving. We need to get to the bottom of this, or else we are going to keep losing time to alignment.

 ITMX is kicked up periodically.  ITMX_PD_MAX_VAR is lowered to 500 from 1350

It started at Friday morning 8-1

It's great that you guys found the beam.
Yes, ITMX kick and lost communication for TRY were the motivation of my CDS rebooting.

[ericq, Jenne]

We both happened to come by today to fix things up.

When I arrived, the PMC was locked to a 01 mode, which I fixed. The PMC transmission is still worryingly low. MC locked happily. 

ETMX was getting odd kicks, the kind where a DC shift would occur suddenly, and then go away a few moments later. I turned off all dynamic coil outputs, and looked at the MON output of the SOS driver with a scope to try and see if the DAC or dewhitening was glitching, but didn't see anything... Meanwhile, Jenne fiddled with the TTs until we got beams on POP and REFL. (EDIT, JCD:  Useful strategies were to put an excitation onto TT2, and move TT1 until the scattered beam in the chamber was moving at the excitation frequency,  Find the edges of TT2 by finding where the scattered light stops seeing the excitation, and center the beam on TT2.  By then, I think I saw the beam on the PRM face camera.  Then, put a temporary camera looking at the face of PR2.  Using TT2 to center here got us the beam on the POP camera.)

We then walked PRM and the TTs around to keep those two camera beams and get the PRM oplev beam back on its QPD. At this point, ITMX was misaligned (by us), and ITMY aligned to get some recycled flashes into the Y-arm. Y-arm was locked to green, and we poked TTs to get better IR flashes. Misaligning PRM, we had Y-Arm flashes of ~0.7. From there, the michelson and then X-arm were roughly aligned. Both arms were seeing flashes of about 0.7, and the MICH fringes on the AS port look nice.

Frustratingly, the SUS->LSC communication for TRY and TRX isn't working, and could not be fixed by any combination of model or front-end restarting... Thus we haven't been able to actually lock the arms and run ASS. THIS IS VERY FRUSTRATING. 

Additionally, at the point where we were getting light back into the Yarm, the ITMX that were seen on Friday were happening again, tripping the watchdog. Also, something in the Yarm cavity is getting intermittently pushed around, as can be seen by the green lock suddenly wandering off. All of these suspension shenanigans seem to be independent of oplev damping. 

It troubles me that this whole situation is fairly similar to the last time we lost the input pointing (ELOG 10088)

In any case, we feel that we have gotten the IFO alignment to a lockable state.

I was investigating several issues on the IFO. As many of you noticed and not elogged, ITMX had frequent kicking without its oplev servo.
Also I had C1:LSC-TRY_OUT flatted out to zero even though I could see some fringes C1:SUS-ETMY_TRY_OUT.

Restarted all of the realtime models (no machine reboot).

Now I don't find any beam on REFL/AS/POP cameras.

If I look at BS-PRM camera, I can see big scattering, the beam is in the BS chamber.
I jiggled TT1 but cannot find neither a Michelson fringe nor POP beam.

So far I can't figure out what has happened but I'm leaving the lab now.

IMC is locked fine.
I can see some higher order mode of the Yarm green, so the Y arm alignment is no so far from the correct one.

 The PZT actuation on the laser frequency in MHz/V ( assuming the previous calibration here of the PZT count/V) is :

X- arm: 33.7 MHz/V

Y- arm: 14.59 MHz/V

This number seems to be wrong by a factor of 10. 

So we[I and EricQ] decided to trace the cables that run into the ADC from the PZT Out. We found a black LEMO box in the path to ADC,which is  an anti-aliasing filter for each input channel. However,in theory the response of this filter should be flat up until a few kHz i.e. for  the DC gain it should be 1. But we will manually test it and look at the DC gain of the LEMO box.

Koji and Evan have both brought up a good point that we may not be backing up the svn and ELOG properly.

I have modified the rsync.backup script that nodus' cron runs every night that backs up /cvs/cds to what I presume are the tape backups at ldas-cit.ligo.caltech.edu.

Specifically, I added two rsync commands that grab the svn and elog directories from /export/home and copy them to their old locations in /cvs/cds/caltech. This way, the old locations are updated, and the tape backups stay current.

Reasoning to choose the current parameters:

FSS Common: 18dB
FSS Fast: 20dB

Attachment 1:
Openloop transfer function of the IMC loop with the nominal gain setting. The UGF is 176kHz and the phase margin is 48 deg.
This is about 3 time more bandwidth than the previous setting. (Good)

It is visible that the TF has sharp roll off around 1MHz. I wonder if this comes from the demodboard LPF and/or the PMC cav pole.
In fact, according to Manasa, the PMC has the ringdown of 164.6ns which corresponds to the cavity pole of 967kHz. So this must
be there in the OLTF.

From the plot, the order of the low pass is about 5. Subtracting the slope by the cavity pole, the order is four. If I look at the TF of the minicircuits
LPFs (this entry), the phase delay of the filter at 1/10 of the cut off freq is ~30deg. And the order of the filters are maybe 6th elliptic?
So it's not yet clear if the LPF is causing a significant phase delay at 180kHz.

More significantly, the gain margin at ~1MHz is way too small. This is causing a big servo bump at that frequency as seen in Attachment 2.

In total, my recommendation is to move the LPF freq up by x2 or x3, and give a mild LPF above 500kHz.
This requires some modeling as well as try and error.

Attachment 2:

This figure is to explain how the common FSS gain was set. By increasing the gain, the UGF is increased and we can enjoy more supression (from red to purple).
The more gain, however, the more servo bump we observe above the UGF. The gain was chosen so that the total PC feedback does not exceed 3V.

Attachment 3/4:

This figure explains how the fast FSS gain (namely crossover frequency between fast and PC) was set. When the fast is low (red) the phase margin between two loops
are plenty and therefore the openloop TF is smooth. But the PC's frequency domain is large and has to work more (in rms). As the fast gain is increased, the actuation
by the PC is offloaded to the fast PZT (that's good). But eventually the phase margin is not enough and the dip start to show up (purple). This dip cause worse closed loop TF,
as seen in Attachment 4, or even an instability of the loop eventually. So the fast gain was set somewhere in between (green).

The comparison between the new and old MC servo (FSS part) was attached.

- The new servo has the same DC range as before.
  Even though there is 1/2 gain in the chain now, the previous range of the FSS box was 0 to 10V.
  Now it is +/-10V. So we did not lose the range.

- The new servo has x3.2 larger range above 100Hz.

- x1.6 enhancement of the FSS Box output noise above 10Hz.

- The noise of the HV amp (and the summing amp) is x300 and x2600 more filtered at 10kHz and 100kHz respectively.

The summing amp is prepared to allow up to use bipolar full range of the FSS box output

This means that the FSS fast PZT output is now nominally 0V and can range +/-10V.

- FSS Box has the output range of +/-10V

- Thorlabs HV amp MDT694 accepts 0V ~ +10V

- This circuit add an offset of +5V while the main signal is attenuated by a factor of 2. The offset voltage is produced from the voltage reference IC AD586.

- In addition, a summing node and voltage monitors before and after the summing node are provided. They are useful to test the crossover frequency of the fast/PC loops.

- The output noise level at 10kHz was ~60 nV/rtHz. The transfer function of the circuit was measured and flat up to 100kHz. The phase delay is negligible at 10kHz and less than 3deg at 100kHz

- Although the schematic was drawn in Altium, the board is a universal 1U eurocard and all wires were hand soldered.

It seems that the MC auto locker and the FSSSlow PID servo survived a night.

PC Drive is still angry occasionally. We want to know what this is.

- Put the circuit diagram of the sum amp on/in the circuit enclosure and associate it with an elog [done].
- Update the circuit diagram of the pomona box [done]
ALL DONE

To make MC auto locker running correctly, mcdown and mcup were revised

I tried it by unlocking MC several times. It seems OK. Let's see how it works.

Nominal gains for locking (to be taken care by mcdown)

C1:IOO-MC_REFL_GAIN
was 16 and is 19 now.

C1:IOO-MC_VCO_GAIN
was 9 and is 9 now too.

C1:PSL-FSS_MGAIN
was missing and now +13

C1:PSL-FSS_FASTGAIN
was +23.5 and is now +20.0

Nominal gains for operation ( to be taken care by mcup.

C1:IOO-MC_REFL_GAIN
was 19 and is 19 now too.

C1:IOO-MC_VCO_GAIN
was 25 and now uses ezcastep (ezcastep C1:IOO-MC_VCO_GAIN=9 +1,16 -s 0.1)

C1:PSL-FSS_MGAIN
C1:PSL-FSS_FASTGAIN

ezcawrite C1:PSL-FSS_MGAIN `ezcaread -n C1:PSL-STAT_FSS_NOM_C_GAIN`
ezcawrite C1:PSL-FSS_FASTGAIN `ezcaread -n C1:PSL-STAT_FSS_NOM_F_GAIN`

C1:PSL-STAT_FSS_NOM_C_GAIN`  is +18
C1:PSL-STAT_FSS_NOM_F_GAIN`   is +20