while I was not doing anything on the machine.

After lots of trial and error, and a little inspiration from Koji, I have written a new script that will run when you select "update snapshot" in the yellow ! button on any MEDM screen. 

Right now, it's only live for the OAF_OVERVIEW screen.  View snapshot and view prev snapshot also work. 

Next on the list is to make a script that will create the yellow buttons for each screen, so I don't have to type millions of things in by hand.

The script lives in:  /cvs/cds/rtcds/caltech/c1/scripts/MEDMsnapshots, and it's called....wait for it....... "updatesnap".

 Currently the update snapshot script looks at the 3 letters after "C1" to determine what folder to put the snapshots in.  (It can also handle the case when there is no C1, ex. OAF_OVERVIEW.adl still goes to the c1oaf folder).  If the 3 letters after C1 are SYS, then it puts the snapshot into /opt/rtcds/caltech/c1/medm/c1sys/snap/MEDM_SCREEN_NAME.adl

Mostly this is totally okay, but a few subsystems seem to have incongruous names.  For example, there are screens called "C1ALS...." in the c1gcv folder.  Is it okay if these snapshots go into a /c1als/snap folder, or do I need to figure out how to put them in the exact same folder they currently exist in?  Or, perhaps, why aren't they just in a c1als folder to begin with? It seems like we just weren't careful when organizing these screens.

Another problem one is the C1_FE_STATUS.adl screen.  Can I create a c1gds folder, and rename that screen to C1GDS_FE_STATUS.adl?  Objections?

It turned out that the signal was too small with PDA10A to detect the 22 and 110 MHz RF sidebands.

The DC output coming out from it was about half mV or so (corresponding to few uW in laser power) when the PRCL was locked to the carrier.

This is because PDA10A is a silicon detector which is more sensitive to visible light than IR.

The reason we chose PDA10A was that it has relatively a large diode size of 1 mm in diameter.

However according to the data sheet the responsibility at 1064 nm is about 0.05 A/W which is sad.

I will replace it by PDA10CF, which is made from InGaAs and supposed to have 10 times bigger responsibility.

Though the diode size will be half mm in diameter, which may require another strong lens in front of it.

How to run/use CSS/BOY

(PREPARATION)

0) Everything runs on pianosa for now.

1) type css to launch CSS IDE.

2) You may want to create your own project folder as generally everything happens below this folder.

=== How to make a new project ===
- Right-click on tree view of Navigator pane
- You are asked to select a wizard. Select "General -> Project". Click "Next".
- Type in an appropriate project name (like KOJI). Click "Finish"
- The actual location of the project is /home/controls/CSS-Workspaces/Default/KOJI/ in the above example

(PLAY WITH "Data Browser", THE STRIPTOOL ALTERNATIVE)

1) Select the menu "CSS -> Trends -> Data Browser". A new data browser window appears.

2) Right-click on the data browser window. Select the menu "Add PV". Type in the channel name (e.g. "C1:LSC-ASDC_OUT16")

3) Once the plot configuration is completed, it can be saved as a template. Select the menu "File -> Save" and put it in your project folder.

4) Everything else is relatively straightforward. You can add multiple channels. Log scaling is also available.
I still don't find how to split the vertical axis to make a stacked charts, but I don't surprise even if it is not available.

(HOW TO MAKE A NEW "BOY" SCREEN)

0) Simply to say BOY is the alternative of MEDM. The screen file of BOY is named as  "*.opi" similar to "*.adl" for MEDM.

1) To create a new opi file, right-click on the navigator tree and select the menu "New -> Other".

2) You are asked to select a wizard. Select "BOY -> OPI file" and click "Next".

3) Type in the name of the opi file. Also select the location of the file in the project tree. Click "Finish".

4) Now you are in OPI EDITOR. Place your widgets as you like.

5) To test the OPI screen, push the green round button at the top right. The short cut key is  "CTRL-G".

(HOW TO EDIT AN EXISTING OPI FILE)

1) Right click an OPI file in the navigator tree. Select the menu "Open WIth -> OPI Editor". That's it.

(HOW TO CONVERT AN EXISTING ADL FILE INTO OPI FILE)

1) You need to copy your ADL file into your project folder. In this example, it is /home/controls/CSS-Workspaces/Default/KOJI/

2) Once the ADL file is in the project folder, it should appear in the navigator tree. If not, right-click the navigator pane and select "Refresh".

3) Make sure "ADL Parser" button at the left top part is selected, although this has no essential function.
This button just changes the window layout and does nothing. But the ADL Tree View pane would be interesting to see.

3) If you select the ADL file by clicking it,the tree structure of the ADL file is automatically interpreted and appears in the ADL Tree View pane.
But it is just a display and does nothing.

4) Right-click the ADL file in the navigator pane. Now you can see the new menu "BOY". Select "BOY -> Convert ADL File to OPI".

5) Now you get the opi version of that file.
The conversion is not perfect as we can imagine. It works fine for the simple screens. (e.g. matrix screens)
But the filter module screens get wierd. And the new LSC screen did not work properly (maybe too heavy?)

(HOW TO RUN OUR SHELL/PERL/PYTHON SCRIPTS FROM BOY)

CSS has javascript/python scripting capability.
I suspect that we can make a wrapper to run external commands from python script although it is not obvious yet.

The POP22/110 RFPD has been replaced by PDA10CF. As a result the 22 and 110 MHz signals became detectable.

However the signal level maybe too low according to a quick look with an RF spectrum analyzer.

The level at 22 and 110 MHz were both approximately -70 dBm although these values were measured when the central part was freely swinging.

Perhaps we need to amplify the signals depending on the actual SNR.

 Also I have updated the optical tables' wiki page :

http://blue.ligo-wa.caltech.edu:8000/40m/Optical_Tables

Plugging in the thermal feedback BNC cable to the laser reduced the DC voltage of the green PDH photo diode from 3.12 V to 1.5V off resonance.

The power emitted by the laser was the same as in the case without that cable. Note LT, i.e. measured crystal temperature, of the laser show a

different value when the BNC is connected, but the manual clearly states that this display does not work properly if a cable is connected to the

slow BNC plug, an offset is added.

The power of the 532nm light behind the SHG oven has been reduced from 1mW to 0.4mW. I changed the crystal temperature such that the power

of the green light is 1mW. With this new temperature setting the laser can be locked again.

Changing the crystal temperature changes the laser frequency. This will causes the beat note missing at the vertex.

In other words, you will find the beat note at the vertex when the actual temperature of the crystal is reproduced as before,
no matter how the dial setting/temp voltage input is.

Several activities in the past week (elog1, Mirko's rough realignment of MC and adjustment of the PSL zig-zag on Monday and elog2 ), had led to an MC state where the spots were not centered on the actuation nodes.

The change in the C1IOO model part dealing with MC_ASS led to the disappearance of all MC_ASS filter definitions in the lockins.  I have fixed all that, remade the screens and scripts for making the MC Decenter measurements.

I have just completed the re-centering of the spots on the MC and this of course will lead to some change in the input pointing. 

The MC_REFL beam also was recented on the WFS and the MC2_TRANS QPD.

Will add the mc-decenter measurement in a few mins

I must confess that I changed the temperature of the laser via the dial yesterday. I believe the initial (displayed) temperature was ~19^o, whereas it is now probably in the high 20s. Sorry.

I pulled out the POX11 demod board and found the power splitter on the board hadn't been modified yet.

I am going to replace the splitter which had been made with a hand-wounded coil because it can work only at a specific tailored frequency.

The modification on the POX11 demod board has been successfully done.

I followed the procedure which had been posted in a past entry (#4554).

The home-made splitter was replaced by PSCQ-2-51W, which has a relatively wide band of 5 - 50 MHz.

The usual orthogonality adjustment will be done in the daytime.

 The attached snapshot was taken when an sinusoidal RF signal with a slight frequency offset from LO was injected to the RF input.

It is clear that the I and Q output show healthy signals (i.e. almost the same amplitude and 90 deg phase difference.)

 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.

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.

• 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...

[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 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.

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.

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?

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:

[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.

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.

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 (?!)

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.

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

[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.

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

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

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 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.

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

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.

 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. 

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.

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

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.

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

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.

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 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.

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

 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.

 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.

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.

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 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

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 ?

 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.

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.