40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 226 of 341  Not logged in ELOG logo
ID Date Author Type Category Subject
  5799   Thu Nov 3 17:19:54 2011 SureshUpdateIOOMC realigned to center the spots on actuation nodes

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

  5798   Thu Nov 3 17:04:23 2011 KojiUpdateGreen LockingSHG temperature (YARM)

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.

  5797   Thu Nov 3 16:43:44 2011 KatrinUpdateGreen LockingSHG temperature (YARM)

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.

 

  w/o BNC cable at slow plug w/ BNC cable at slow plug
T (°C) 29.776 29.776
LT (°C) 39.2 48.4
1064nm power (mW) 440 448
Temp. at TC200 (°C) 35.7 36.4
532nm power in front of Isolator (mW) 1.0 1.0

 

 

 

  5796   Thu Nov 3 16:31:47 2011 kiwamuUpdateLSCPDA10CF as POP22/110 : better

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

Quote from #5794

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

  5795   Thu Nov 3 15:14:22 2011 KojiUpdateCDSCSS/BOY installed on pianosa

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

(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".
OPI_EDITOR.png

(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?)
ADL2OPI1.png ADL2OPI2.png

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

  5794   Thu Nov 3 14:25:52 2011 kiwamuUpdateLSCPDA10A as POP22/110 : too small signal

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.

Quote from #5788
 The POP22/110 RFPD has been installed. It is PDA10A from Thorlabs instead of the usual home-made RFPD.
  + Fine alignment

  5793   Thu Nov 3 13:00:52 2011 JenneUpdatePhotosFormatting of MEDM screen names

Quote:

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?

 

  5792   Wed Nov 2 22:02:39 2011 JenneUpdatePhotosNew screen snapshot script written!

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

 

  5791   Wed Nov 2 21:49:59 2011 KatrinUpdateCDSc1iscey computer died again

while I was not doing anything on the machine.

  5790   Wed Nov 2 21:15:06 2011 KatrinUpdateCDSand again c1scy.mdl compiled

I changed an ADC channel for GCY_ERR and thus recompiled the c1scy model.

  5789   Wed Nov 2 20:56:49 2011 KatrinUpdateCDSdigital zeros at C1:X05-MADC0 (c1scy)

Channels C1:X05-MADC0_TP_XXX with XXX 2-9, 14-19, 21-27, 29-31 showed digital zeros.

Some of these channels are used in c1scy.mdl, e.g. for OSEM stuff. I guess this is not optimal...

  5788   Wed Nov 2 19:32:20 2011 kiwamuUpdateLSCPOP22/110 installed

[Steve / Kiwamu]

 The POP22/110 RFPD has been installed. It is PDA10A from Thorlabs instead of the usual home-made RFPD.
For an RF cable we rerouted one of the spare Heliax cables for it.
The cable is the one which used to be served for the 166MHz ASC wavefront sensors, picking up the RF source signal at 1X2 and sending it to the LSC rack.
 
 - - Remaining tasks - -
  + Fine alignment
  + Connection at the LSC rack
  + Update of the table diagram

Quote from #5783

They were traced and labeled. One goes to 1X2 and the other to AS-ISCT. They are Andrew Heliax 1/4" od. made by CommScone,  model number FSJ1-50A

  5787   Wed Nov 2 17:33:28 2011 KatrinUpdateGreen LockingADC channels for slow control

connector J9B of hardware ADC --> ch1 in software ADC --> GCY_ERR

connector J14 of hardware ADC --> ch11 in software ADC --> GCY_PZT

connector J15 of hardware ADC --> ch13 in software ADC --> GCY_REFL_DC

 

 

  5786   Wed Nov 2 17:29:10 2011 KatrinUpdateCDSc1scy.mdl compiled

Slight modification on that model:

  • terminated Q_out of Lockins to be able to compile the old model
  • assigned other ADC channels to GCY (green YARM)
  5785   Wed Nov 2 14:07:25 2011 ZachUpdateelogrestarted

Elog was hanging, restarted with the script.

  5784   Wed Nov 2 11:29:04 2011 not ZachUpdateSUS"Dr. SUS" progress

Quote:

Now that NDS2 is working, I was able to run all parts of diagAllSUS (except for the matrix writing) without errors. Barring issues with standard commands (freeswing, turnOnWatchDogs.csh, caput, etc.), Dr. SUS should be ready to go.

As requested, I have suppressed the generation of an elog post containing the results of the diagonalization.

Dr. SUS will run on allegra as a cron job at 8:00am on Sundays:

allegra:peakFit>crontab -l

PATH=/bin/:/usr/bin/:/cvs/cds/caltech/apps/linux64/matlab/bin/:/cvs/cds/caltech/apps/linux/gds/bin/:/cvs/cds/caltech/apps/linux/tds/bin/

PWD=/cvs/cds/caltech/apps/linux/gds/lib/

LD_LIBRARY_PATH=/cvs/cds/caltech/apps/linux/gds/lib

01 05 * * 0 cat /cvs/cds/caltech/users/kiwamu/work/20091026_OMC-LSC-diag/src/OMC_LSC_timing.m | matlab -nosplash -nodesktop > /dev/null

 

0 8 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/runDrSUS

Also: should these variable definitions really be here? 

Cron starts with only a very minimal PATH.  However, this shouldn't be an issue if you specify the full path to the commands.

The rest of the env vars should probably not be there.

Also, Zach:  using /cvs/cds is now forbidden.  We need to put this script in the right place.

  5783   Wed Nov 2 10:41:47 2011 steveUpdateGeneral2 spare heliax at the LSC rack

They were traced and labeled. One goes to 1X2 and the other to AS-ISCT. They are Andrew Heliax 1/4" od. made by CommScone,  model number FSJ1-50A

  5782   Wed Nov 2 10:04:05 2011 steveUpdateSUSMC2 chamber anchoring tightened

Quote:

 Thinks to do before the NEXT realignment:

B,  tie 4 ancher bolts on table legs to the floor

C,  tie 4 dog clamps between table and chamber

D,  check the locked position of the 4 x 4 positioning screws

E,  check bellow protecting 4 tubes are not shorting

A,  here is the concrete  slab cut

 

It reminds me to check the  IFO vacuum envelope dog clamps on the chambers to floor  with torque wrench.

 

 

 I locked the PMC and MC resonated in TM00 right on. Than I started checking anchoring screws with the torque wrench.

B,  3/8 foor bolts were tight, They were set  to 50 ft/lbs

C,  dog clamp bolts were tight at 80 ft/lbs

D,  horizontal position locks were lose. They were locked by finger.

E,  below covers were reset not to short

The MC is locking in TM01 mode now 

  5781   Wed Nov 2 01:53:08 2011 ZachUpdateSUS"Dr. SUS" progress

Now that NDS2 is working, I was able to run all parts of diagAllSUS (except for the matrix writing) without errors. Barring issues with standard commands (freeswing, turnOnWatchDogs.csh, caput, etc.), Dr. SUS should be ready to go.

As requested, I have suppressed the generation of an elog post containing the results of the diagonalization.

Dr. SUS will run on allegra as a cron job at 8:00am on Sundays:

 

 

allegra:peakFit>crontab -l

 

PATH=/bin/:/usr/bin/:/cvs/cds/caltech/apps/linux64/matlab/bin/:/cvs/cds/caltech/apps/linux/gds/bin/:/cvs/cds/caltech/apps/linux/tds/bin/

 

PWD=/cvs/cds/caltech/apps/linux/gds/lib/

 

LD_LIBRARY_PATH=/cvs/cds/caltech/apps/linux/gds/lib

 

01 05 * * 0 cat /cvs/cds/caltech/users/kiwamu/work/20091026_OMC-LSC-diag/src/OMC_LSC_timing.m | matlab -nosplash -nodesktop > /dev/null

0 8 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/runDrSUS

Also: should these variable definitions really be here?

 

 

  5780   Tue Nov 1 23:13:28 2011 ZachUpdateComputersNDS2 channel files

I did some messing around with the NDS2 config and channel files and things seem to be working as expected... for now. SENSOR channel data can be acquired for all sensors on all hanging optics.

What I did:

  • NDS2 gets its channel lists from .../users/jzweizig/nds2-mafalda/nds2.conf, which is called in the start-nds2 script. Within this, there are channel.file lines that specify which channels are available for raw and trend data. The four files that were listed were:
    • C-R-raw-channel_list.txt
    • C-M-ChanList.txt
    • C-T-ChanLIst.txt
    • C-R-online-channel_list.txt (this one was listed after a hashed line, which was suspicous---see below)
  • I noticed that a grep for SENSOR only returned lines for non-MC mirrors in both "R" files
  • I also noticed that calling NDS2_GetChannels('mafalda.martian:31200') did not return any non-suffixed (i.e., raw) channel names for MCx_SENSOR channels, while non-MC SENSOR channels each had two non-suffixed listings. I thought this was strange.
  • I manually added the line "C1:SUS-MC1_SENSOR_UL 0 real_4 2048 C-R" to one of the "R" channel files, then restarted the NDS2 server, and that channel was still not served. I figured that the second "R" channel file might have been left in the config file as a mistake, so I commented it out, restarted the NDS2 server, and was able to get MC1_SENSOR_UL data. I have left the comment-out there, with a signed EDIT.
  • Wary of (and too lazy to) manually add lines for all 5 sensors for each MC mirror, I decided to try generating a channel file using the most recent .gwf file in the frames, as indicated in Joe and John's elog post. To do this, while in .../nds2-mafalda/, I ran:
    • /cvs/cds/caltech/users/jzweizig/nds2-server/bin/buildChannelList /frames/full/10042/C-R-1004246528-16.gwf > C-R-raw-channel_list.txt
  • A grep for SENSOR in the new C-R-raw-channel_list.txt now returned lines for all MC mirror sensors... BUT NOT FOR ETMY(?!). I tried some slightly older .gwf files (all from today), but the ETMY files never showed up. I had no choice but to enter them manually. Another odd thing is that the channel file generated this way seems to be fairly jumbled up, in the sense that there is no clear top-town order (e.g. SUS-BS_blah then SUS-ETMX_blah). Instead, some SUS-BS channels are here, some are after SUS-ETMX or SUS-PRM channels, etc. Look at the file to know what I mean.
  • The original raw channel file is there as C-R-raw-channel_list.txt.bak.1004247481.

In any case, as I said, everything appears to be working now, but as soon as we try to generate a new channel file using the prescribed means, there will inevitably be channels omitted. Someone who knows more than me should get to the bottom of this and wiki a strict, detailed procedure for how this is to be done.

  5779   Tue Nov 1 19:26:38 2011 ZachUpdateSUS"Dr. SUS" progress

EDIT: Ran Jamie's NDS2 reset method and it's still not serving up MC data.

I am debugging the SUS input matrix diagonalization code (which I have affectionately termed "Dr. SUS") offline by running everything except the actual writing of the matrices (%writeSUSinmat()) in a sandbox directory. Some notes:

  • nodus doesn't know NDS2, but this isn't a problem given Kiwamu's reply, since we don't want to push results to the elog. I will still have the script push "optics kicked---don't touch" alerts to the elog, but I realized this can be done easily from a remote computer via in-script SSH commands. My next choice was pianosa, but even though she knows NDS2, she spits out MEX errors when I try to get data. Third stop was allegra, and she plays nice 
  • NDS2 is unable to read the MC mirror sensor data. Data from all other optics are retrieved without a problem. I verified that raw data was being written by plotting playback data in dataviewer, and I tried various times and the problem persisted. I suspect the problem is on the NDS2 server side:

The most recent entry in .../users/jzweizig/nds2-mafalda/channel_history shows nothing for MC1 2 or 3

 

mafalda:channel_history>more C-R-999986048-178368.cls | grep SENSOR
C1:SUS-BS_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-BS_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-BS_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-BS_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-BS_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-ETMX_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-ETMX_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-ETMX_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-ETMX_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-ETMX_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-ETMY_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-ETMY_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-ETMY_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-ETMY_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-ETMY_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-ITMX_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-ITMX_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-ITMX_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-ITMX_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-ITMX_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-ITMY_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-ITMY_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-ITMY_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-ITMY_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-ITMY_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-PRM_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-PRM_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-PRM_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-PRM_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-PRM_SENSOR_UR raw 0 real_4 2048 C-R
C1:SUS-SRM_SENSOR_LL raw 0 real_4 2048 C-R
C1:SUS-SRM_SENSOR_LR raw 0 real_4 2048 C-R
C1:SUS-SRM_SENSOR_SIDE raw 0 real_4 2048 C-R
C1:SUS-SRM_SENSOR_UL raw 0 real_4 2048 C-R
C1:SUS-SRM_SENSOR_UR raw 0 real_4 2048 C-R

 

  5778   Tue Nov 1 18:45:48 2011 JenneUpdateComputersAllegra's screens

I was trying to give Allegra a second head, and it didn't quite work.  It's still in progress.  Steve, you might not like how I've 'mounted' the second monitor, so we can talk about something that might work tomorrow.

  5777   Tue Nov 1 18:16:50 2011 DenUpdateAdaptive FilteringAdaptive filter witness and EP SNR

Quote:

 

Coherence of seismometers to MCL:


STS1 is located at the vertex. x-axis along the x arm.
GUR1 is located at the IMC MC2 mirror. Same orientation.
Coherence.png

=> 1. Only the x-direction has good coherence (to be expected)
     2. Only good coherence at 1.5-4Hz (huh?)

So probably other noise sources are dominating. Let's look into noise projections. Remember IMC autoalignment is off.

A quick adaptive filter run with only the GUR1 and STS1 witnesses applied only to MCL didn't really do anything. Some more thought needs to be invested into the AA and shaping filters.

The possible explanation to this effect is the following:

Seismic noise mainly consists of the Love and Rayleigh surface waves. In the simulations we've taken 2 perpendicular Love waves and 2 perpendicular Rayleigh waves that interfere under the test mirrors. This interference produces both translational and tilt movements. Then we can see the coherence between translational motion and cavity length.

translation_length.jpg

1. The coherence at big frequencies is small due to the passive isolation.

2. The coherence at 1 Hz is 0 due to the wire resonance.

3. The coherence between 1 and 10 Hz is reasonable. At the real 40m's measurements we can see only good coherence for gur1_x and sts1_x but this is the matter of adjusting seismic waves amplitude and direction. In the simulation we've assumed that all waves are of the same amplitude. The really interesting thing is that

4. The coherence below 0.8 Hz began to grow. We don't see this in real measurements.

But let's simulate the seismometer measurements. It measures not only translational motion but also tilt and with amplitude proportional to g / omega^2. On the Figure below the spectrum of translation motion, tilt and tilt as seen by seismometer is presented. We can see that at low frequencies tilt begins to dominate over the translational motion. We assumed the speed of waves in the region 30 - 60 m/sec.

trans_tilt.jpg

Let's now plot the coherence between the cavity length and seismometer signal.

seismic_length.jpg

We can see that the coherence between seismic signal from measured by seismometer and cavity length is gone below 1 Hz where tilt becomes important.

Now let's try to filter out the seismic noise from the cavity length using both static Wiener filtering and adaptive Mfxlms algorithm. For both filters we've used AA filter before the filters and also AI filter after adaptive filter. The downsampling ratio was 4, the sample frequency 256. We can see that nothing is really subtracted due to the pollution of the seismometer signal due to tilt motion.

tilt_filtering.jpg

Assume we do the same computational experiment but with the seismometers that measure only ground translational motion and tilt do not affect on them. Then we have a reasonable subraction of seismic noise at low frequencies even with the filters of the length 100 as shown on the figure below.

filtering.jpg

Let's look through an order of magnitude analysis. Assume ground motion consists of only one wave with amplitude A and only vertical movement:  z(t) = A*sin(2 pi 0.1 t). So the frequency of the wave is 0.1 Hz. If A = 10-6 m => the amplitude of the suspended mirror motion is also approximately 10-6 m, as we have no isolation at low frequencies. The tilt angle has the amplitude alpha = 2*pi*A/lambda, where lambda - wavelength of the ground wave, lambda = v/f = 40/0.1 = 400 m, v - speed of the wave, f - frequency. Then alpha = 10-8 rad. If the distance between ground and mirror suspension point is 1 m, then mirror motion amplitude due to tilt is B = 10-8 m << A. 
It turns out that tilt does not effect much on the cavity length compared to the ground translational motion, but it affects a lot on the seismometer signals, that are used as witness signals in the filtering. For that reason we need tiltmeters to filter seismometer signals in order to obtain pure translational ground motion.
  5776   Tue Nov 1 16:02:15 2011 kiwamuUpdateSUSRe: SUS input matrix diagonalizer REMOVED from crontab

Quote:

It turns out that nodus doesn't know how to NDS2, so I can't run diagAllSUS as a cron job on nodus. To further complicate things, no other machines can run the elog utility, so I am going to have to do something shifty...

 Actually in the last 40m meeting we discussed the SUS diagnosis and decided not to post the results on the elog.

Alternatively we will have a summary web page which will contain all the information (sensitivity, UGF monitors, etc.,) and will be updated everyday like GEO.

This will be a place where we should post the SUS results every week.

So we don't need to worry about the cron-elog job, and for running the scripts you can simply use one of the lab machines as a cron host.

Once you get the scripts running on a machine as a cron job, it will be the point where we should quit developing the SUS diagonalizer and pass it to the web summary people.

  5775   Tue Nov 1 13:46:03 2011 ZachUpdateSUSSUS input matrix diagonalizer REMOVED from crontab

It turns out that nodus doesn't know how to NDS2, so I can't run diagAllSUS as a cron job on nodus. To further complicate things, no other machines can run the elog utility, so I am going to have to do something shifty...

  5774   Tue Nov 1 13:41:38 2011 MirkoUpdateLSCAM modulation due to non-optimal SB frequency

Quote:

[Kiwamu, Mirko]

Non-optimal 11MHz SB frequency causes PM to be transformed into AM.
m_AM / m_PM = 4039 * 1kHz / df , with df beeing the amount the SB freq. is off.

Someone might want to double check ths.

 Actually there was an error.

For 11MHz it is:
m_AM / m_PM = 2228 * 1kHz / df

For 55MHz:
m_AM / m_PM = 99.80 * 1kHz / df

see PDF

Attachment 1: IMC.pdf
IMC.pdf
  5773   Mon Oct 31 21:46:32 2011 kiwamuUpdateLSCDependence of Recycling gain on incident beam pointing

I horizontally swept the translation of the incident beam in order to investigate a possible clipping in Power-recycled Michelson (PRMI).

The recycling gain of PRMI depended on the beam pointing but it did't improve the recycling gain.

I guess the amount of the entire shift I introduced was about +/- the beam diameter = +/- 5 mm or so.

Within the range of about +/- 5mm in the horizontal beam translation I didn't find any obvious sign of a clipping.

 

(Measurement)

 This is the procedure which I did:
  (1) Some amount of offsets were introduced on MC2 in both PIT and YAW such that the PZT1 won't rail (#5762).
      => Every time when I introduced the offset I realigned the zig-zag mirrors on the PSL table to maintain the high transmissivity of MC.
  (2) Fine tuning of the MC offsets so that the PZT1_X EPICS value becomes almost zero when the beam is aligned down to the Y arm.
     => 0.523 in C1:ASC_PZT1_X became a point where the coupling of the beam into the Y arm was maximized.
     => Last time the direction which we investigated was the positive side from this zero point (#5709) in PZT1_X.
  (3) Aligned MICH by steering BS.
  (4) Locked PRMI with carrier resonating and aligned PRM to maximized the power recycling gain which was obtained from POYDC.
  (5) Translated the beam pointing
     => First I shifted PZT1_X by a wanted amount.
    => Then I locked the Y arm and realigned PZT2_X by maximizing the Y arm transmission.
          This procedure should give us a pure translation on the incident beam.
  (6) Repeated the same procedure (3) through (5) in each PZT1 position.
 

(Results)

Here shows the measured recycling gain and the power reflectivity of PRMI as a function of the beam pointing.

beam_scan_PRCL.png

 Upper plot : measured recycling gains (Red) observed maximum values (Black) measured values on average.
 Lower plot : measured power reflectivity of PRMI (Blue) observed minimum values (Black) measured values on average.
 
 As shown in the plots the recycling gain could go up to 8 at some points.
As the PZT went away from 0 it decreased and eventually became about 3 in each side.
The reflectivity showed the minimum value of 0.4 when the PZT1 was at -1 in EPICS value.
One hypothesis to explain this plot can be that : we are just seeing the effect of the incident beam misalignment.

 

  5772   Mon Oct 31 19:39:00 2011 JenneUpdateAdaptive FilteringScreens, code, computers

[Mirko, Jenne]

I finished (mostly? maybe?) the OAF screens.  They're pretty awesome. 

While we were playing with the OAF, trying to do some oafing, the output of the code decided to just be zeros.  We did a test, and in the c-code set the output to be a constant value, and that worked.  But when we put it back to normal (being adaptive) and recompiled, it still only outputs zeros.  The code is receiving both witness and error signals, so we don't know what's going on.

In the course of trying to make things work again, we did a complete reboot of c1lsc and c1sus.  Did a burt restore.  Everything (except our weird code problem) should be fine again.  Optics are damping happily.

  5771   Mon Oct 31 15:58:25 2011 steveUpdateSUSthinking of black glass baffles for 40m

Shade 12 black glass-green lines: 1/8" thick,  6" wide  x 7 " high  mounted on angle bracket below.  Aperture 1" diameter. Let me know what do you think.

 

Attachment 1: 03260901.PDF
03260901.PDF
Attachment 2: 03260902.PDF
03260902.PDF
  5770   Mon Oct 31 14:06:16 2011 ZachUpdateSUSSUS input matrix diagonalizer added to crontab

I actually tried to do this last night, but I was getting a terminal error from nodus. Jamie told me to just manually redefine the TERM variable and it would work. So, I have added kickAll and diagAllSUS to controls@nodus's crontab:

 

nodus:~>crontab -l

0 5 * * * /opt/rtcds/caltech/c1/scripts/backup/rsync.backup

0 7 * * * /opt/rtcds/caltech/c1/scripts/backup/check_backup.sh 

0 17 * * 0 /cvs/cds/caltech/users/jenne/LIGOX/LIGOX_Pizza_Reminders.sh

0 8 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/kickAll

0 18 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/diagAllSUS

Again, their functionality should be checked before this is allowed to run on Sunday!

 

  5769   Mon Oct 31 14:01:56 2011 KatrinUpdateGreen LockingYARM locks for 2h

Today, I could lock the YARM laser for 2h to the YARM cavity. After to hours the output of the servo is saturated. I need to work on thermal feedback to the laser.

It is a nice TEM00 mode and the green light enters PSL table.

20111031_OLTF.png

Measured with pin-ball machine spectrum analyzer (I forgot the real name, but it is the one that makes sounds like a pin-ball machine), source power10mVp, Lb1005 gain 2.05.

 

Setup

YARM_setup.png

Input offset of LB1005 is zero

 

Locking history

On Thursday, Oct 27, lock for 3 min

On Friday, Oct 28, lock up to 18 min, improvements done by

  • finding the right adjustment of PI Corner frequency and gain
  • better alignment of the light to the cavity
  • I used a high-pass filter between LO and LB1005, but no improvement of lock. In contrast, it got worse.

On Monday,Oct 31, careful adjustment of summing box (rear of of LB1005), lock up to 2h, limited by saturated feedback signal --> work on slow control

 

Some more plots

feedback.png

 PD_DC1.png

PDH_error1.png

Attachment 1: 20111031_OLTF.png
20111031_OLTF.png
Attachment 2: YARM_setup.png
YARM_setup.png
  5768   Mon Oct 31 09:42:12 2011 steveUpdateIOOPMC locked

The PMC HV drops off more offen lately.

Attachment 1: pmcHV.png
pmcHV.png
  5767   Mon Oct 31 08:55:19 2011 steveUpdateVACpressure plot at day 53

Quote:

I was lucky to notice that the nitrogen supply line to the vacuum valves was leaking. Closed ALL valves. Open supply line to atm. Fixed leak. 

This was done fast so the pumps did not have to be shut down. Pressurized supply line and open valves to

"Vac Normal" condition in the right sequence.

 

Attachment 1: pd71-m-d53.png
pd71-m-d53.png
  5766   Sun Oct 30 23:03:37 2011 SUS_DiagonalizerUpdateSUSSUS input matrix diagonalization complete (EXAMPLE)
New SUS input matrix diagonalization complete. Matrices have been written to the frontend. Summaries for each optic can be viewed below.

(THIS IS AN EXAMPLE---no new matrices have been written.)
Attachment 1: MC1.png
MC1.png
Attachment 2: MC2.png
MC2.png
Attachment 3: MC3.png
MC3.png
Attachment 4: ETMX.png
ETMX.png
Attachment 5: ETMY.png
ETMY.png
Attachment 6: ITMX.png
ITMX.png
Attachment 7: ITMY.png
ITMY.png
Attachment 8: PRM.png
PRM.png
Attachment 9: SRM.png
SRM.png
Attachment 10: BS.png
BS.png
  5765   Sun Oct 30 23:01:51 2011 ZachUpdateSUSdiagAllSUS -- automated input matrix generator

I finally got around to wrapping up the SUS input matrix diagonalizer. The files I have added to ...scripts/SUS/peakFit are:

  • kickAll: Restores all SUS angle biases using /cvs/cds/rtcds/caltech/c1/medm/c1ifo/cmd/C1IFO_OPTICrestore.cmd XXXX &, then runs 'freeswing all'. Finally, writes an elog entry with the time when the optics were kicked and saves the gps time to 'kickAll.time'.
  • diagAllSUS.m: An M-file that calls all the other individual M-files needed for the matrix generation. What it does:
    • Reads kick time from kickAll.time
    • Runs getSensors.m to get time series from all optics' sensors
    • Runs makeSUSSpectra.m to generate spectra from time series
    • Runs findPeaks.m to fit spectra for peak frequencies
    • Loops through all optics and runs, in sequence:
      • inmat = findMatrix(XXXX) to generate the matrix for each optic
      • writeSUSinmat(XXXX,inmat) to write that matrix to the frontend
  • diagAllSUS: A wrapper for diagAllSUS.m. It also writes an elog entry and attaches the pre and post spectra demonstrating the diagonalization. The entry following this one is an example.

The following lines should eventually be added to the controls@nodus crontab:

0 8 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/kickAll

0 18 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/diagAllSUS

(i.e., do the kick at 8am on Sundays and run the diagonalization 10 hrs later at 6pm). They can be done on a different machine but then my elog commands will need to be modified.

Before we add them, we should check that they do, in fact, work. We can do this sometime while I'm at the 40m this week.
 

  5764   Sun Oct 30 14:08:35 2011 ranaUpdateElectronicsRFAM monitor in place. ( Uncalibrated ) EPICS troubles

Quote:

{Suresh, Jamie, Mirko]

We adapted the Stochmon box to include LP filters at 1.8Hz behind the RMS parts.
Then measured the RMS signals for different RF signal levels at 11.0.65, 29.5, 55.325MHz provided by a RF freq. generator.
As you can see in the data below the suppression of the BP filters of neighboring frequencies is only 35-35dB in power (see also manufacturer specs).

We therefor want to substract crosstalk, by calculating it out. We decided to use C-code in CDS. No computer crashing this time :)

 This is neat idea, but it seems like it would be easier to just add another set of rf BP filters inside of the StochMon box. Luckily, Steve was thinking ahead and ordered extra filters.

  5763   Sat Oct 29 22:57:03 2011 MirkoUpdateLSCAM modulation due to non-optimal SB frequency

[Kiwamu, Mirko]

Non-optimal 11MHz SB frequency causes PM to be transformed into AM.
m_AM / m_PM = 4039 * 1kHz / df , with df beeing the amount the SB freq. is off.

Someone might want to double check ths.

Attachment 1: IMC.pdf
IMC.pdf
  5762   Sat Oct 29 05:50:44 2011 kiwamuUpdateLSCMC suspensions misaligned to avid railing for PZTs

I have shifted the alignment of the MC suspensions such that the PZT won't rail.

Since I didn't care of the spot positions on the MC mirrors, currently they are terribly off from the centers.

After the shift, I realigned the Stochmon PD again.

The attachments below shows the alignment of MC and PZTs before shifting the just for a record

 MCalignOct282011.png 

Oct282011.png

Quote from #5754

 Tomorrow night I will intentionally introduce offsets in the MC suspensions to avoid the railing.
The goal will be a scan of the incident beam while measuring the recycling gain.

  5761   Sat Oct 29 02:35:39 2011 SureshUpdateIOOWFS_MASTER screen and lockin screens fixed

I have fixed the WFS_MASTER screen and several of the subscreens such as the MCASS and MC_WFS_LKIN.

Since MC_WFS_LKIN uses six demodulators and single oscillator I could not use the automatically built Lockin screens. 

I built one using the compact filter banks mentioned earlier

The phases in the WFSlockins have yet tp be set.

  5760   Fri Oct 28 20:39:19 2011 MIrkoUpdateLSCRFAM monitor in place. ( Uncalibrated ) EPICS troubles

{Suresh, Jamie, Mirko]

We adapted the Stochmon box to include LP filters at 1.8Hz behind the RMS parts.
Then measured the RMS signals for different RF signal levels at 11.0.65, 29.5, 55.325MHz provided by a RF freq. generator.
As you can see in the data below the suppression of the BP filters of neighboring frequencies is only 35-35dB in power (see also manufacturer specs).

We therefor want to substract crosstalk, by calculating it out. We decided to use C-code in CDS. No computer crashing this time :)

We however ran into the problem that the RMS signal channels are acquired by the slow (EPICS) maschine c1iool0. Channels are (C1:IOO-RFAMPD_33MHZ , -"-133MHZ, -"-166MHZ) and we could not access those in the CDS c1ioo model. Using the EpicsIn block we got an CA.Exception stating that the variable was hosted on multiple servers. We then tried to use the EzcaRead to access the variables. Got an compile error, about the compiler not beeing able to connect all parts. It seems that the EzcaRead left behind a "ghost" part in the model (something with M1:SYS-FOO_BAR which is the default naming of the EzcaRead block) even after we deleted that block. We toyed around with the /opt/rtcds/caltech/c1/chans/daq/C1EDU_IOO.ini  and  /cvs/cds/caltech/target/c1iool0/ioo.db  files. We tried to uncomment the "old" (33,133,166) channels there to get rid of the conflict, but that didn't work.

We want to write the outputs to C1:IOO-RFAMPD_11MHZ , -"-29MHZ, -"-55MHZ EPICS channels.

We had to get the model back from the svn to get it running again.

Attachment 1: MC_DC11MHz.m
Pwr=[-60,-55,-50,-45,-40,-35,-30,-25,-20,-10,-5,0,5,10]';
Voltage11=[2.12,2.10,2.03,1.93,1.83,1.71,1.59,1.47,1.35,1.10,0.97,0.85,0.71,0.61]';

Voltage11=spline(Pwr,Voltage11,linspace(-60,10,15));
PwrSmooth=linspace(-60,10,15);

Voltage29=[2.14,2.14,2.14,2.14,2.14,2.14,2.13,2.12,2.09,1.94,1.84,1.73,1.61,1.49];
Voltage29=spline(Pwr,Voltage29,linspace(-60,10,15));

Voltage55=[2.16,2.16,2.16,2.16,2.16,2.16,2.16,2.15,2.14,2.13,2.10,2.04,1.94,1.83];
... 5 more lines ...
Attachment 2: MC_DC29MHz.m
Pwr=[-60,-55,-50,-45,-40,-35,-30,-25,-20,-15,-10,-5,0,5,10]';
Voltage11=[2.16,2.16,2.16,2.16,2.15,2.16,2.15,2.13,2.10,2.03,1.93,1.81,1.70,1.58,1.46]';

Voltage29=[2.12,2.10,2.03,1.93,1.83,1.70,1.59,1.47,1.34,1.22,1.09,0.97,0.84,0.71,0.61]';

Voltage55=[2.16,2.15,2.16,2.16,2.15,2.15,2.14,2.10,2.0,1.97,1.97,1.77,1.65,1.50,1.37]';

%%  Example 55MHz inj.

Voltage11=[2.00];
... 21 more lines ...
Attachment 3: MC_DC55MHz.m
Pwr=[-60,-55,-50,-45,-40,-35,-30,-25,-20,-15,-10,-5,0,5,10]';
Voltage11=[2.16,2.16,2.16,2.16,2.16,2.15,2.15,2.15,2.15,2.15,2.12,2.09,2.00,1.89,1.78]';

Voltage29=[2.14,2.14,2.14,2.13,2.14,2.13,2.11,2.06,1.98,1.88,1.76,1.64,1.52,1.40,1.27]';

Voltage55=[2.14,2.11,2.05,1.96,1.85,1.73,1.61,1.48,1.36,1.23,1.10,0.98,0.84,0.71,0.61]';

plot(Pwr,Voltage55)

%%
... 17 more lines ...
Attachment 4: RFAMPD.c
double x;
double y;
double z;

double temp1;
double temp2;

double Corrx;
double Corry;
double Corrz;
... 49 more lines ...
  5759   Fri Oct 28 18:33:59 2011 steveUpdateVACleaking nitrogen line fixed

I was lucky to notice that the nitrogen supply line to the vacuum valves was leaking. Closed ALL valves. Open supply line to atm. Fixed leak. 

This was done fast so the pumps did not have to be shut down. Pressurized supply line and open valves to

"Vac Normal" condition in the right sequence.

Attachment 1: allvalvesclosed.png
allvalvesclosed.png
  5758   Fri Oct 28 15:45:52 2011 MirkoUpdateComputersNifty screen generator

Quote:

Suresh showed me a cool script that Mirko made, but didn't elog about.

You tell the script what filter banks you want, and it creates a screen for each with a bunch of different filter module display formats.  Then you can copy the format you like into the actual screen you're modifying. 

Currently PEM, LSC and IOO (and maybe others?) have "fmX" folders inside their medm/c1.../master folders.  For each subsystem, we need to copy this folder, and modify the generic .adl file so that it puts in the correct subsystem letters.  Once this is done, you can just run the generateFMscreens.py after putting in your filter bank names.

 Wasn"t me.

  5757   Fri Oct 28 15:33:06 2011 JenneUpdateComputersNifty screen generator

Suresh showed me a cool script that Mirko made, but didn't elog about.

You tell the script what filter banks you want, and it creates a screen for each with a bunch of different filter module display formats.  Then you can copy the format you like into the actual screen you're modifying. 

Currently PEM, LSC and IOO (and maybe others?) have "fmX" folders inside their medm/c1.../master folders.  For each subsystem, we need to copy this folder, and modify the generic .adl file so that it puts in the correct subsystem letters.  Once this is done, you can just run the generateFMscreens.py after putting in your filter bank names.

  5756   Fri Oct 28 14:56:02 2011 JenneUpdateCDSCSS/BOY installed on pianosa

Quote:

I've installed Control System Studio (CSS) on pianosa, from the version 3.0.2 Red Hat binary zip.  It should be available as "css" from the command line.

CSS is a new MEDM replacement. It's output is .opi files, instead of .adl files.  It's supposed to include some sort of converter, but I didn't play with it enough to figure it out.

Please play around with it and let me know if there are any issues.

links:

 So far I've only given it about half an hour of my time, but it is *really* frustrating so far.  There don't seem to be any instructions on how to tell it what our channels are / how to link CSS to our EPICS databases.  Or, the instructions that are there say "do it!", but they neglect to mention how...  Also, there exists (maybe?) an ADL->BOY converter, but I can't find any buttons to click, or how to import an .adl, or what I'm supposed to do.  Also, it's not clear how to get to the editor to start making screens from scratch. 

It looks like it has lots of nifty indicators and buttons, but I would have felt better if I had been able to do anything.

Another thing that is going to be a problem:  the Shell Command button that we use all over the place in our MEDM screens is not supported by this program.  It's listed in the "limitations" of the ADL2BOY converter.  This may kill the CSS program immediately.  Jamie: did Rolf/anyone mention a game plan for this?  It's super nice to be able to run scripts from the screens.

Moral of the story:  I'm annoyed, and going to continue making my OAF screens in MEDM for now.

  5755   Fri Oct 28 12:47:38 2011 jamieUpdateCDSCSS/BOY installed on pianosa

I've installed Control System Studio (CSS) on pianosa, from the version 3.0.2 Red Hat binary zip.  It should be available as "css" from the command line.

CSS is a new MEDM replacement. It's output is .opi files, instead of .adl files.  It's supposed to include some sort of converter, but I didn't play with it enough to figure it out.

Please play around with it and let me know if there are any issues.

links:

  5754   Fri Oct 28 05:17:13 2011 kiwamuUpdateLSClocking activity : PZT1 is still railing

Status update on the LSC activity:

 To see how good/bad the beam pointing is, I locked the Y arm with POY11.
Then I ran the ASS servo to automatically correct the alignment of the ITMY and ETMY suspensions and also the beam pointing.
The result is that the PZT1_X is still railing to the negative side.
Due to it the transmitted light from the Y arm is about 0.6 or so which is supposed to be 1 if the beam pointing is perfect.
The EPICS value of PZT1_X is at the minimum of -10 and the ASS servo tried to push it more negative side.
 
 Tomorrow night I will intentionally introduce offsets in the MC suspensions to avoid the railing.
The goal will be a scan of the incident beam while measuring the recycling gain.
  5753   Fri Oct 28 04:57:00 2011 kiwamuUpdateLSCPOX11 demod board broken
The POX11 demodulation board is broken. It needs to be fixed in the daytime tomorrow.
It only outputs the Q signal and nothing is coming out from the I output.


(Some stuff checked)
 [OK] ADCs
 [OK] Whitening filters looked fine. Their gains were controllable from EPICS.
 [OK] Connection between the POX11 RFPD and demodulator box
 [OK] The Q signal showed the PDH signal of the X arm with an amplitude of about 200 counts, which almost is the same as that of POY11.
 [NOT GOOD] The I signal from the demod board
 [OK] Outputs cables, which send the I and Q signals from the demod board to WFs are fine.
         
(Test on the POX11 demod board)
 As usual, a test signal whose frequency is shifted by a little bit from that of LO was injected to the RF input of the board to see if the circuit is working.
The I signal didn't show up and there were no signals even in the monitor LEMO output.
Something is wrong in the I signal demodulation path on the circuit board.

Here is an actual time series of the I and Q signals in dataviewer. The I signal outputs just junk while the Q showed a nice sine curve.
Screen_shot_2011-10-28_at_2.26.02.png

  5752   Fri Oct 28 03:42:50 2011 kiwamuUpdateLSCITMX table needs to be refined

(POX)

The POX beam had been 80% clipped at a black glass beam dump of the POX11 RFPD.

I steered the first mirror in the POX path to fix the clipping. Then the beam was realigned onto the RFPD.

However the beam is still very close to the black glass, because the incident angle to the second mirror is not 45 deg .

We need to refine the arrangement of the POX11 optics a bit more so that the beam will never be clipped at the black glass.

 

(POP)

 The POP optics also need to be rearranged to accommodate one more RFPD.

Additionally Rana, Suresh and I discussed the possible solutions of POP22/110 and decided to install a usual PD (PDA10A or similar) instead of a custom-made.

So a plan for the POP detectors will be something like this:

        + design an optical layout.

        + buy a 2 inch lens whose focul length is long enough (#5743)

        + rearrange the optics and install POP22/110

        + lay down a long SMA cable which sends the RF signal from POP22/110 to the LSC rack.

        + install a power splitter just before the demod board so that the signal is split into the 22MHz demoad board and 110MHz demod board.

           => make sure we have a right splitter for it.

        + install a band pass filter after the power splitter in each path.

           => A 22MHz band pass filter is already in hand. Do we have 110MHz band pass filter somewhere in the lab ?

The picture here shows the latest configuration on the ITMX table.

ITMXtable.png

Quote from #5743

RF photo diodes POP55 and POX11 are installed. The beams are aligned to the photo diodes. 

  5751   Fri Oct 28 03:12:37 2011 SureshUpdateIOOMC2 realigned to align MC to PSL

Around 6PM on the 27th, I found that the C1:IOO-MC_RFPD_DCMON had risen to about 2.5V.   I checked the trend of MC2 sensors and found that  between 2PM and 6PM, MC2 had drifted in a strange way.  And also that the alignment had grown worse over several days.   I also noticed that the spot on the MC2F camera had shifted to the left.

I attempted to correct the alignment (decrease the C1:IOO-MC_RFPD_DCMON to ~0.5V ) by just moving the MC2 and succeeded!! So it is quite likely that most of the slow MC drift is arising due to MC2 table drift.

MC2_Drift_20111027.png

 

I decided to try and close the MC2_TRANS QPD to MC2 loops separately to see if MC alignment becomes stable  But several screens needed to be fixed before we could try anything.   So I fixed C1IOO_WFS_MASTER,  C1IOO_WFS_INMATRIX and ...OUTMATRIX screens.  Deleted the older ones to avoid confusion.

In this process I noticed that the directory of $screens$/c1mcs/master contains copies of older C1SUS_MC1 , 2. and 3 screens which look very similar to the new autogenerated screens.  Some of the links in the WFS screens were pointing to the old screens.  I have redirected the links and I will delete these in a couple of days, if no one objects.

 

 

 

  5750   Fri Oct 28 02:41:18 2011 SureshMetaphysicselogelog unresponsive: restarted

Elog did not respond despite running the /cvs/cds/caltech/elog/start-elog.csh  script two times.  

It worked the after the third restart. 
 

ELOG V3.1.3-