Indeed it is strange. I took a quick look at it.

In order to recover the same condition (e.g. the same amount of the reflected DC light and the same temperature readout),

it needed to have +8.9V in the slow input from the DAC through EPICS.

Obviously applying an offset in the slow input to maintain the same condition is not good.

It needs another solution to maintain the sweet frequency where the frequency of the PSL and the Y end laser is close in a range of 200 MHz.

Difficult to understand.

The mode matching does not change the recycling gain. It changes the coupling of the incident light into the cavity.
It changes the reflected and accumulated power, but the recycling gain is not affected.

The recycling gain is determined by the optical configuration and the optical loss in the cavity.

In the actual measurement, of course, we should take both of the loss and the mode matching into account.
But this is the issue of the measurement method.

The essential questions are:
How much is the actual recycling gain? And how does it affect the signal extraction?

Goal of this week :  ALS on the Y arm

Minimum success : Detection of the green beatnote between the freq-doubled PSL and the Y arm transmitted light

EDIT by KI:

  The definition of the recycling gain is wrong here.

See the latest entry (#5875)

Here is a summary about the Power Recycled Michelson (PRMI).

It seems the mode matching is also one of the greatest contributor on the low recycling gain.

 (Estimated parameters)

     +  Loss = 5.3% (or effective reflectivity of  93.28% in Michleson) => Under coupling !!

     +  Mode matching efficiency = 47.4 %  => Really bad !!

   With these values we end up with a recycling gain of 7 and a normalized REFLDC of  0.5 as observed (#5773).

Also according the incident beam scan measurement (#5773) the loss is NOT a local effect like a clipping, it is more like uniformly distributed thing.

As for the mode matching, the number indicates that approximately the half of the incident light is coming back to the REFL port without interacting with PRMI.

This is bad because the non-mode-matched light, which is just a junk light, is entering into the photo detectors unnecessarily.

In the worst scenario, those junk light may create a funny signal, for example a signal sensitive to the alignment of PRM.

(Estimation method)

The method to estimate the loss and the MM (Mode-Matching efficiency) is essentially the same as before (#5541).

One difference from the previous estimation is that the I used more realistic parameters on the transmissivity of ITMs and PRM :

     PRM : T = 5.637 %  (see the 40m wiki)

     ITM : T = 1.384 %  (see the 40m wiki)

 In addition to the basic calculations I also made plots which are handy for figuring out where we are.

Quantities we can measure are the reflected light from PRMI and the recycling gain using the REFL PD and the POY PD respectively.

So I wanted to see how the loss and MM can be estimated from the measured REFL DC and recycling gain.

The plots below are the ones.

[Loss map]

 The first figure shows a contour map of the loss as a function of the measured REFL DC and recycling gain.

The white area is a place where no proper solutions can be found (for example MM can get to more than 100 or loss becomes negative).

The star mark in the plot corresponds to the place where we are now. Obviously the loss is about 5%.

If we somehow decrease the amount of the loss the star mark will mostly go up in the plot.

[MM map]
 The second figure shows a contour map of the MM as a function of the measured REFL DC and recycling gain. 

The X and Y axis are exactly the same as that of the first plot. Again the star mark represents the place where we are.

We are currently at MM=47%

(Solutions)

Here are some solutions to bring the recycling gain higher.

We don't work on these things immediately since it requires opening of the chambers again and it will take some times.

But we should think about those options and prepare some stuff for a coming vent.

  + Refinement of the position of the mode matching telescopes.  => The Recycling gain can go up to 15.

     => Assuming the loss in the cavity doesn't change, the star mark in the first plot will go to the left hand side along the "0.05" black solid line.

     => However PRMI will be still under coupled.

     => Needs an estimation about which way we move the telescopes.

 + Locate the place of the dominant loss source and reduce it somehow.

    => The recycling gain will be more than 18 if the loss reduces by a factor of more than 5.

    => Needs a clever way to find it otherwise we have to do it in the classical way (i.e. white light and trying to find dirty surfaces)

As described in elog 2063 and the mevans document, we need to measure the TF of the OAF's plant, to find the delay.

At DC, the phase is 2.5deg, and at 32Hz, the delay is -4.6Hz (extrapolated from the points at ~30deg and ~38deg).  The DTT file is in /users/Templates/OAF/OAF-MCL-Delay-9Nov2011.xml . 

This gives a phase lag of 7.1deg at the Nyquist freq.

7.1 / 180 * 32 = 1.26, so ~1 cycle delay.  Not so much.  The new ADCs are waaaay faster than the old 110Bs.  Yay!

The Matlab NDS1 access seems to only work for some channels. With other channels it just hangs 'Busy' and does nothing.
Below you can see some channels that make matlab hang. Everyting happened on allegra. I tried compiling the NDS1 sources (from https://www.gravity.phy.syr.edu/dokuwiki/doku.php?id=ligodv:nds1_ligodv_install ) into mex files myself. Same result. I
 

a=NDS_GetChannels('fb:8088'); %/cvs/cds/caltech/apps/linux64/share/matlab/NDS_GetChannels.m
%data=NDS_GetData({'C1:IOO-MC_F_DQ'},1004826500,100,'fb:8088',a)     %Works
%data=NDS_GetData({'C1:IOO-WFS1_PIT_IN1_DQ'},1004826500,100,'fb:8088',a)     %Works
data=NDS_GetData({'C1:LSC-AS11_I_OUT'},1004826500,100,'fb:8088',a)         %Doesn't work, hangs
%%%which NDS_GetData.m: /cvs/cds/caltech/apps/linux64/share/matlab/NDS_GetData.m

error signal = signal measured behind the low-pass filter

feedback signal = output of the gain servo, going to the PZT

First of all both signals in V/sqrt(Hz) just in case I mess up the next calibration step.

The 60 Hz line (and its multiple) are a new feature. They show up as soon as the feedback loop is closed. So far, I couldn't find their origin.

For the next calibration step:

• width of a typical error signal, i.e. the frequency band width of the carrier slope, ~1.4 kHz
• height of a typical error signal 182 mV

 As reported a couple days ago, the ETMX IO chassis has no timing signal.  This is why we there is no QPD signal and why we turned off the ETMX watchdog.  In fact, I believe that there is probably nothing coming out of the ETMX suspension controller at all.

I'm working on getting the timing board replaced.  Hopefully today.

The ETMX oplev returning beam is well centered on the qpd. We lost this signal 2 days ago. I will check on the qpd.

ETMX sus damping restored.       c1iscex computer is down

With fancy analysis tools approaching usability I looked some more into noise projections from PIT,YAW motion of the MC mirrors to MC length.

Injection channels are: C1:IOO-MC1-PIT_EXC. Actual injection signal is recorded in C1:IOO-MC1-PIT_OUT and similar.
Source channels for the projection are C1:IOO-WFS1_I_PIT_OUT_DQ and similar.
Response channel is C1:OAF-MCL_IN_IN1 or C1:IOO-MC_F_DQ.
MC auto-alignment was off.

1. Fixed sine injection @ 0.5Hz

Every injection lasted 4mins.

2. Filtered white noise injection

Generated white noise from 0.5Hz-20Hz, then filtered that in the C1:IOO-MC1-PIT and similar filters by the following TF, (Notch 1Hz, Q=3, 40dB &  2 zeros @ 1.1Hz)

All injections lasted 4mins. I left the filters in the first filter bank but disabled them. 

Had since yesterday evening some trouble with getting a channel from rfm on c1sus to oaf on c1lsc via dolphin. Several restarts of c1lsc and c1sus didn't help. At some point this morning a restart of c1lsc helped. Everything ok again.
At the bad time the dolphin TF looked like this:

Should be flat at gain 1 and no phase change obviously.

I switched on the WFS servos with the output matrix (open loop) determined last Friday.  Only the WFS1Pit, WFS2Pit, WFS1Yaw and WFS2Yaw servo filters are now on.   I then adjusted the gains to obtain maximum suppresson of error signals without oscillations in the loops

I now proceed to determine the output matrix again.

 The MC alignment was bad and I wondered if it is because MC shifted or because the input PSL beam shifted.   So I remeasured the spot positions and find that MC2 Yaw has shifted a lot.   Todays measurements are in Cyan boxes above. The shift in MC3P is probably an associated shift due to some pit--yaw coupling.  So I am going to move MC2 and try to align the MC to the PSL.

A nice plot !

Can you put another y-axis on the right hand side of the same plot  in terms of the cavity displacements ?

And can you also measure a more important spectrum, namely the suppressed error signal ?

I measured the power spectrum of channel C1:GCY_SLOW_SERVO1_IN1, which is the PZT driving voltage.

I converted the output to a PSD. Next, I converted counts/sqrt(Hz) to volts/sqrt(Hz) by multiplying with 40 V / 2^16 counts.

Finally, I multiplied it with 5MHz/V for the PZT to end up with Hz/sqrt(Hz).

This corresponds to a cavity length fluctuation of

with lambda = 532nm and a YARM cavity length of 37.757m (elog # 5626).

All in one plot

It appears that the timing slave in the c1iscex IO chassis is dead.  It's front "link" lights are dark, although there appears to be power to the board (other on-board leds are lit).  These front lights should either be on and blinking steadily if the board is talking to the timing system, or blinking fast if there is no connection to the timing distribution box.  This likely indicates that the board has had some sort of internal failure.

Unfortunately Downs has no spare timing slave boards lying around at the moment; they're all stuffed in IO chassis awaiting shipping.  I'm going to email Rolf about stealing one, and if he agrees we'll work with Todd Etzel to pull one out for a transplant

I copied Mirko's PEM BLRMS block, and made it a library part.  I don't know where such things should live, so I just left it in isc/c1/models.  Probably it should move to cds/common/models.  To make the oaf compile, you have to put a link in /opt/rtcds/caltech/c1/core/branches/branch-2.1/src/epics/simLink , and point to wherever the model is living. 

I then put BLRMSs on the control signals coming into the OAF, and after the Correction filter bank in the Adapt blocks, so we can check out what we're sending to the optics.

 I assume you mean /opt/rtcds/caltech/c1/scripts/MC/WFS.

As I've tried to reitterate many times: we do not use /cvs/cds anymore.  Please put all new scripts into the proper location under /opt/rtcds.

 This was totally my fault.  I'm very sorry.  I modified the lockin part to output the Q phase, and forgot to modify the models that use that part appropriately.  BAD JAMIE!  I'll check to make sure this won't bite us again.

 After Rana pointed out the errors of our ways, we reverted all of these changes.

 I installed 4 remote AC power on/off strip at

1Y1   for the Vertex area 4 chamber illuminating lights ( CIL )

1Y3   for HV ps for PZT steering mirrors that should be interlocked with P1 pressure gauge. Power off above 3 mTorr

1Y4   for  ETMY CILs,

1X9   for ETMX CILs

I need one volunteer to help me to make MEDM screen and connect the network to the switches.

I clicked on the FE status screen, just to check on things, and everything on the c1iscex section was red (the IOP and c1scx).  Upon deciding that was probably a bad thing, I did a soft reboot from the control room.  Now the IOP says "NO SYNC", and the c1scx status thing is totally frozen. 

I have sent Jamie a whiny email. He promises to be here soon to fix it.

I've noticed that it always takes running the script twice for it to actually work. I think there's something wrong with how it's doing it. I'll mess with it sometime the elog isn't getting much use.

Elog restart script killed the elog, but didn't restart it.  Restarted by hand.

The Nov.19 interruption was rescheduled to be on Nov.20,2011

          CALIFORNIA INSTITUTE OF TECHNOLOGY

                 FACILITIES MANAGEMENT

            UTILITY & SERVICE INTERRUPTION

**PLEASE POST**

Building:         CENTRAL ENGINEERING SERVICES, STEELE HOUSE, KECK LAB,

                  LIGO GRAVITATION PHYSICS BLDG, SAFETY STORAGE (BY CES)

Date:             Sunday, Nov. 20,2011

Time:             10:00 AM TO 11:00 AM

Interruption:     ELECTRICITY

Contact:          MIKE ANCHONDO X-4999 OR TOM BRENNAN X-4984

*THIS INTERRUPTION IS REQUIRED FOR MAINTENANCE OF HIGH VOLTAGE SWITCHGEAR

IN CAMPUS SUB-STATION.

The PMC acted like it was sleeping. The HV slider was dead. The MC locked instantly as the PMC had transmission.

The 'helping' trick is a good one: we should use our best guess for the stackTF and the pendulumTF and put it into the IIR filter bank to pre-filter the seismometer signals before they get to the MC mirrors. Also should remember that the signal we send to suppress the seismic motion is applied to the pendulum as a force, not a displacement.

The 3 Hz fast cutoff in the MC_F signal is a good clue. It means that at low frequencies, perhaps the noise source is going through a digital 3 Hz elliptic or Chebychev filter.

 Dr. SUS failed while trying to get the sensor data. Specifically, it couldn't get ETMY data. This is odd, because in my tribulations last week I ended up having to add the ETMY_SENSOR channels manually into the NDS2 channel files. After doing this, I was able to get ETMY data just fine (though I admitted that we would have problems again as soon as we wanted to update the channel files). I even ran the diagAllSUS code in a sandbox and it pulled data---and generated input matrices---just fine.

The error persists even if I try to get the data manually:

>> d = NDS2_GetData({'C1:SUS-ETMY_SENSOR_UL'},t0,10,'mafalda.martian:31200');

Connecting.... authenticate done

Warning: daq_recv_next failed

??? Error using ==> NDS2_GetData

Fatal Error getting channel data.

I think Jamie is still waiting for J.Z.'s help with this, but it is probably pointless to keep trying to run this code before NDS2 is working again. Another option is to just use NDS, but I think certain people are opposed to this. 

Ok, here's the deal:

• For the time being, I have written a "doirun" bit into runDrSUS (i.e. it runs if doirun is 1 and doesn't if it's 0). This is a bad way of doing this, so in the end I think we should put a switch on the IFO MEDM and have the script read the value when the cron job is run. If you want it to be an opt-in rather than a toggle, we can have the script write it back to 0 every time. I don't know how to do this yet because I am an MEDM n00b, but I will do it soon.
• Since we have decided to keep a human in the loop on the writing to the frontend, I have kept the elog results push.
• I have also edited diagAllSUS.m so that it archives all computed matrices (hierarchy: .../scripts/SUS/peakFit/inMats/(gps_time_of_kick)/inMat(optic_name).mat). There is a 'writematrices' bit in the M-file, currently set to 0.
• I have written the script 'writeAllInMats' and the accompanying M-file 'writeAllInMats.m'. This allows the user to write whichever set of input matrices he or she desires (syntax: writeAllInMats (gps_time_of_kick)). If no argument is given, then it reads the most recent kick time from 'kickAll.time' and writes the corresponding matrices.

So, here is an example of how this works:

1. Someone decides to do a diagonalization on a particular weekend, (eventually) clicking a switch in MEDM
2. Cron runs runDrSUS at 8am that Sunday. This:
   1. Kicks all the optics, lets them swing for 5 hours, then reengages the watchdogs. The kick time is saved in kickAll.time, and an alert is posted to the elog
   2. Runs diagAllSUS, which computes and saves all matrix data. A report of the results is posted to the elog.
3. On Monday morning---or whenever---someone looks at the entry and decides whether or not to write the files
   1. If the results are good, he or she runs writeAllInMats and the latest matrices are written
   2. If the results are bad, he or she does nothing. The matrices are still archived and can be written at any time in the future.

The code is set to run tomorrow morning. Everything but the writing will be done.

In any case, the daily backup of the scripts are found in /cvs/cds/caltech/scripts_archive. 

I think you also should check the PZT's capacitance of the 700mW LightWave because 2.36 nF is the one for the 1W Innolight laser.

The scripts and screens needed to make the MC WFS ouput matrix are once again functional. 

I corrected the WFS lockins' phases to ensure that the Q outputs are minimised.  Since all the lockins have the same relative phase with respect to the oscillator I found that the same phase works for all of them.  About 90 deg in this case.

The scripts used to make the WFS outmatrix measurement live in /cvs/cds/rtcds/caltech/c1/scripts/MC/WFS

1) setupWFSlockins:   This script makes sure that all the ASC, WFS_ LKIN and WFS_servo filter banks used in this measurement are set up properly.  It also sets the WFS_lockin oscillator to 10 Hz.  There are filter modules in the SIG filter bank of the WFS demodulators. 

2) senseWFSoutMATRX:  This script cycles through the various MC actuators ( MC 1 2 3 : PIT and YAW ) and measures the response of the various ASC sensors (WFS and MC2_TRANS QPD).

3) The data collected by the sensWFSoutMATRX can be analysed with a matlab file called " wfsmatrix3.m " located in a subdirectory under WFS called 'matlab'.   I have added some comments in this file to make it easier to follow.   The output of this file, at the moment, gives only the " Actuation Vectors " for WFS1P, WFS2P, WFS1Y and WFS2Y.  It ignores the MC2TransQPD for now. 

4)  The lockin outputs are given below ( the 'reduceddata' )

             wfs1p      wfs2p      mc2tp      wfs1y      wfs2y     mc2ty

mc1p    0.2926   -0.4086    0.2926    0.0340    0.0064    0.0001
mc2p   -0.2830   -1.3060   -0.2833    0.0628    0.1171   -0.0003
mc3p   -0.3283   -0.3455   -0.3288   -0.0456    0.0275    0.0000
mc1y    0.0440    0.0261    0.0429    0.7204    0.9351   -0.0008
mc2y   -0.1006    0.0850   -0.1036   -1.5509   -0.3882    0.0165
mc3y     0.0150   -0.0832    0.0144    0.1114   -1.0573    0.0006

5) The actuation vectors are given below

6) This measurement was performed with the WFS servo loops open. I will try to close the loops with this matrix and run the script again to measure the output matrix in closed loop.

7) This a.vectors obtained above are significantly different from that obtained a while ago (elog 5668) before the lockin demod phases (relative to each other) were fixed.  This could also be because both are open loop measurements and we might have wandered into the nonlinear regime of the WFS sensors.

 I have moved all the MC_ASS scripts to a directory called MC under ASS

Did somebody delete all the scripts in /opt/rtcds/caltech/c1/scripts/ASS ?

[Mirko, Den]

We still think about the coherence between seismic noise and mode cleaner length. We beleive that

1. Below ~0.1 Hz tilt affects on the seismometers as was simulated http://nodus.ligo.caltech.edu:8080/40m/5777

2. From 0.1 to 1 Hz is an interesting region. We try to figure out why we do not see any coherence here. Tilt does not seem to dominate.

At 1 Hz coherence might be lost because of the sharp resonance. For example, if the mirror is suspended to the platform by wires with f = 1 Hz and Q = 1000, then the coherence between platform motion and mirror motion will be lost as shown on the figure below.

For this reason we tried to "help" to the adaptive filter to guess transfer function between the ground motion and mirror motion by multiplying seimometer signal by the platform -> mirror transfer function. As we do not know exactly eigen frequency and Q of the wires, we did a parametric simulation as shown on the figure below

The maximum coherence that we could achieve with treak was 0.074 compared to 0.056 without. This was achieved at f=1.0011 Hz but with surprisingly high Q = 330. And though this did not help, we should keep in mind the tecnique of "helping" the adaptive filter to guess the transfer function if we partly know it.

Another unexpected thing is that we see come coherence between gur1_x and mode cleaner WFS pitch signal at frequencies 0.1 - 1 Hz

 From this we can suggest that either mode MC_F channel does not completely reflect the mc length at low frequencies or WFS2 shows weard signal.

63% coupling efficiency into the new fiber collimator (Thorlabs XXXX) and the blue fiber.This should be sufficient for a beat measurement with the PSL laser.

I think the coupling efficiency is not too bad with having no mode matching lenses and no adjustable collimator lens.

252mW in front of the fiber

159 mW fiber output

My inclination is to not do the writing of the matrices automatically nor to do the weekly kicks. Its nice to have long locks of the MC, etc.

I suggest just making the kick on Sundays when someone intentionally asks for it (e.g. by pressing a button on Friday). The free-swinging ringdown ought to be a opt-in kind of feature, not opt-out.

After Kiwamu adjusted the MC2 PIT to accommodate the limited range of the PZT1 ( elog ),  I remeasured the spot positions today.  

As expected there is a translation of the beam axis to one side (Up? Down?) .  

I wonder how a beam translation by 5mm solved the PZT1 angular range limitation problem (?!)

I moved the place where we take the OAF Degree of Freedom signals from - now it's the error point rather than the feedback for DARM, CARM, MICH, PRCL, SRCL, XARM and YARM.  I didn't do anything to MCL.

While trying to compile, there was something wrong with the lockins that were there...it complained about the Q OUTs being unconnected.  I even reverted to the before-I-touched-it-today version of c1lsc from the SVN, and it had the same problem.  So, that means that whomever put those in the LSC model did so, and then didn't check to see if the model would compile.  Not so good.

Anyhow, I just terminated them, to make it happy.  If those are actually supposed to go somewhere, whoever is in charge of LSC lockins should take a look at it.

Also, as Mirko mentioned in the previous elog 5811, we wanted to calculate the effect on the MC without actuating, so we put in a new summing point and a filterbank so we have testpoints.

LSC model recompiled.

OAF model recompiled.

FB restarted because of the new channels added to OAF.

[Den, Jenne, Mirko]

Here is the story:

1. High gain
The control loop has a high gain at the interesting frequencies. The error point (EP) before the servo is approx. zero and the information how much the mirror would move is in the feedback point (FB) behind the servo. The mirror doesn’t actually move because of the high gain. This is the case of the grav. wave detectors and medium frequencies (> approx. 50Hz, <<1kHz). Adding feed-forward (FF) to this doesn’t actually keep the mirror quieter. In fact if you look into the FB and subtract the seismic you make the mirror move more. Yes this is the case we have for the mode cleaner, doesn’t make sense.
In a real GW detector FF however isn’t totally useless. The FB tells you how much the mirror moves, due to GWs, seismic etc. When you record the FB and subtract (offline) the seismic you get closer to the real GW signal.

2. Low gain
When you, for technical reasons, can’t have a high gain in your control loop the EP contains information of how the mirror actually moves. You can then feed this into the adaptive filter and add its output to the FB. This will minimize the EP reducing the actual mirror motion. This is the case we will have for most or all other degrees of freedom in the 40m.

The reason we have so much gain in the mode cleaner length control is that we don’t actually move mirrors around. We change the frequency of the incoming laser light. You can do that crazy fast with a big amplitude. This gives us a high UGF and lots of gain in the 1Hz range we are interested in.

We now change the adaptive filter to look at the EP for all DOFs except for the MC. We calculate the effect of the FF on the MC length signal without ever applying the FF to the MC length control.

Looking into the coherence between the seismometers and IMC length (MC_F):

FIrst with the seismometers only AC filtered at around 0.003 Hz and AA30Hz:

Ignore the increase in coherence at very low frequencies. That is an artefact.

Then with an additional filter single complex pole @1Hz Q=1000 (giving 20dB per decade in attenuation above 1Hz) , only for GUR1X:

Okay, my elog entry was not clear I changed the temperature of the SHG which only changes the conversion efficiency. 

Anyhow, since the laser set temperature and thus the laser frequency has been changed by Zach and I couldn't find a note

of the original laser crystal temperature, my plan is to reset the SHG temperature to the old value, set the laser crystal temperature

around 19°C and do fine adjustment of that temperature by optimising the doubling efficiency. Okay?

I also modified the Y-Arm PDH box itself slightly. Previously, there was a flying 10k resistor from the SWEEP input to TP2. I don't see the point of this, so I moved it from TP2 across R19 (to the same point where it is on the gyro PDH boxes) to allow for excitation signals to be injected with the loop closed (i.e., with the SWEEP switch off). This is useful for OLTF measurements.

I spent some time the other day trying to diagnose the problem with the Y Arm universal PDH box (S/N 17), which Katrin has been unable to use for locking the green beam. As far as I can tell, there is nothing wrong with the box itself (though the weird TF behavior that Katrin noticed was not initially reproducible, so its cause may still be there).

I did notice that I was unable to generate a PDH error signal using the universal box. In this configuration, a summing circuit is needed to add the PZT modulation signal (f_mod = 178875 Hz) in along with the feedback signal. To do this, Katrin was using a slightly different version of the passive summing box that Kiwamu built for the X Arm. I read this entry to understand how it is supposed to work and noticed that the "expected transfer functions" were not what the circuit actually does. I have talked to Kiwamu about it and he found that he posted the wrong TFs (he has the right ones on his computer). As you can see from the plot below, there is extra low passing that severely attenuates the modulation path to the PZT. In addition, there is a phase shift of ~-60 degrees, which is bad.

To combat this, I propose we simply change the resistor in the modulation path from 1M to 10k. This leaves the feedback path TF unchanged, and changes the mod path into a sort of bandpass filter for the modulation frequency. The fact that the phase is near zero at f_mod means we don't have to come up with some way to phase shift the signal for demodulation. The attenuation level of ~-36 dB is also convenient: The ZAD-8 mixer wants 7 dBm, so, 10 dBm (FG) - 3 dB (splitter) - 36 dB (sumbox) = -25 dBm ~ 12 mV. This is roughly the desired PZT voltage level.

[Offsets in MC]

 I have introduce an offset in MC2 PIT because the PZT1 again started railing.

Right now the PZT1 EPICS value is within the range happily.

Please keep this MC eigen axis as a nominal configuration.

[IFO-configure script]

 I have modified the IFO configure scripts such that XARM and YARM are locked with POX11 and POY11 respectively.

A big advantage in use of POX and POY is that we don't need to misalign ITMs when we align each arm.

Those scripts are now available from the C1IFO_CONFIGURE screen as usual.

• I have replaced all instances of /cvs/cds/rtcds with /opt/rtcds in the Dr. SUS code. 

• We discussed placing a human in charge of whether or not the input matrices get written to the frontend. I am not sure if we reached a definitive conclusion. Currently, the code is set to write the matrices automatically. What to do?
  
  • If we decide that oversight is necessary, I suggest that we leave the publishing of the results to the elog intact. This way, it will be someone's job to read the weekly Dr. SUS diagnosis on Sunday night (or Monday morning), and run a simple script that writes the matrices. This seems like the most reasonable solution.

I await responses...

XARM lock was achieved by POX11_I

Summary:

- The  whitening gains of POX11_I and Q are 42dB so that POX11_I have the same amplitude as AS55_I

- The demod phase of POX11 was adjusted to eliminate the PDH signal from the Q phase. The phase is  -100.5deg.

- In order to lock the XARM with POX11_I_ERR, I had to increase the trigger threshold from 0.1 to 0.2 as the arm was
kicked with the threshold of 0.1.

Method

- Lock the X arm with AS55_I at the XARM configuration.

- Adjusted POX11 demod phase so that POX11_Q is minimized.

- POX I&Q whitening gains were adjusted. When they are 42dB, POX11_I_ERR and AS55_I_ERR have almost the same signal amplitude.
(In reality, POX11_I_ERR has +1dB larger amplitude.)

- Adjusted POX11 demod phase again with better precision.

- Measured transfer function between AS55_I_ERR and POX11_I_ERR. As the sign was opposite, the demod phase was -180deg flipped.

- Tried to lock the arm with POX11_I_ERR. It did not acquire the lock. The arm looked kicked by the servo.

- Increased the trigger threshold from 0.1 to 0.2. Now the arm is locked with POX11_I_ERR.

 The current MC spot decentering is given below:

spot positions in mm:

MC1P     MC2P     MC3P      MC1Y     MC2Y     MC3Y

0.4089    0.4800   -0.1266   -1.4095    0.3808   -1.7517

The yaw measurement probably has the wrong scale factor in the conversion to mm.  It could be under estimated by a factor 2.65/2.00 since the 10% step in coil gains produces a 2mm offset rather than the expected 2.65mm.  See the figures below.  I will check this during the next iteration when another mode clearner alignment comes up.

As I had to redefine all the MC_ASS lockin filters it is possible that Lockin phase might have changed by a few degrees giving rise to a change in the scale factor.