40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 261 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  3948   Thu Nov 18 16:32:21 2010 yutaSummaryCDScurrent damping status for all optics c1sus handles

Summary:
   I set Q-values for each ringdown of PRM, BS, ITMX, ITMY, MC1, MC2, MC3 to ~5 using QAdjuster.py.
   Here are the results;
c1susdampings.png

  Red ringdowns indicate the second try after gain setting.

Note:

  - ITMX and ITMY are referred according to MEDM screens in this entry.
  - ITMX(south) OSEM positions are currently so bad(LL and SD are all the way in/out).
        I have to change IFO_ALIGN slider values to check the damping servo. For SIDE, I couldn't do that. I reverted the slider change after the damping checking.
  - ITMY(west) somehow has opposite coil gain sign.
       Usually for the other optics, UL,UR,LR,LL is 1,-1,1,-1. But for ITMY to damp, they are -1,1,-1,1.
  - PRM damps, but ringdown doesn't look nice. There must be something funny going on.
  - SRM doesn't have OSEMs put in now.

  3947   Thu Nov 18 14:19:01 2010 josephbUpdateCDSSwapped c1auxex and c1auxey codes

Problem:

We had not switched the c1aux crates when we renamed the arms, thus the watchdogs labeled ETMX were really watching ETMY and vice-versa.

Solution:

I used telnet to connect to c1auxey, and then c1auxex.

I used the bootChange command to change the IP address of c1auxey to 192.168.113.59 (c1auxex's IP), and its startup script.  Similarly c1auxex was changed to c1auxey and then both were rebooted.

 

c1auxey > bootChange

'.' = clear field;  '-' = go to previous field;  ^D = quit

boot device          : ei
processor number     : 0
host name            : linux1
file name            : /cvs/cds/vw/mv162-262-16M/vxWorks
inet on ethernet (e) : 192.168.113.60:ffffff00 192.168.113.59:ffffff00
inet on backplane (b):
host inet (h)        : 192.168.113.20
gateway inet (g)     :
user (u)             : controls
ftp password (pw) (blank = use rsh):
flags (f)            : 0x0
target name (tn)     : c1auxey c1auxex
startup script (s)   : /cvs/cds/caltech/target/c1auxey/startup.cmd /cvs/cds/caltech/target/c1auxex/startup.cmd
other (o)            :

value = 0 = 0x0

c1auxex > bootChange

'.' = clear field;  '-' = go to previous field;  ^D = quit

boot device          : ei
processor number     : 0
host name            : linux1
file name            : /cvs/cds/vw/mv162-262-16M/vxWorks
inet on ethernet (e) : 192.168.113.59:ffffff00 192.168.113.60:ffffff00
inet on backplane (b):
host inet (h)        : 192.168.113.20
gateway inet (g)     :
user (u)             : controls
ftp password (pw) (blank = use rsh):
flags (f)            : 0x0
target name (tn)     : c1auxex c1auxey
startup script (s)   : /cvs/cds/caltech/target/c1auxex/startup.cmd /cvs/cds/caltech/target/c1auxey/startup.cmd
other (o)            :

value = 0 = 0x0

  3946   Thu Nov 18 14:05:06 2010 josephb, yutaUpdateCDSc1sus is alive!

Problem:

We broke c1sus by moving ADC cards around.

Solution:

We pulled all the cards out, examined all contacts (which looked fine), found 1 poorly connected cable internally, going between an ADC and ADC timing interface card  (that probably happened last night), and one of the two RFM fiber cables pulled out of its RFM card.

We then placed all of the cards back in with a new ordering, tightened down everything, and triple checked all connections were on and well fit.

 

Gotcha!

Joe forgot that slot 1 and slot 2 of the timing interface boards have their last channels reserved for duotone signals.  Thus, they shouldn't be used for any ADCs or DACs that need their last channel (such as MC3_LR sensor input).  We saw a perfect timing signal come in through the MC3_LR sensor input, which prevented damping. 

We moved the ADC timing interface card out of the 1st slot  of the timing interface board and into slot 6 of the timing interface board, which resolved the problem.

Final Configuration:

 

 Timing Interface Board

Timing Interface Slot 1 (Duotone) 2 (Duotone) 3 4 5 6 7 8 9 10 11 12 13
Card None DAC interface (can't use last channel) ADC Interface ADC interface ADC interface

ADC

interface

None None None DAC interface DAC interface None None

 PCIe Chassis

Slot 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
PCIe Number Do Not Use 1 6 5 4 9 8 7 3 2 14 13 12 17 16 15 11 10
Card None ADC DAC ADC ADC ADC BO BO BO BO DAC DAC BIO RFM None None None None

Still having Issues with:

ITM West damps.  ITM South damps, but the coil gains are opposite to the other optics in order to damp properly.

We also need to look into switching the channel names for the watchdogs on ITMX/Y in addition to the front end code changes.

  3945   Thu Nov 18 11:06:20 2010 josephbUpdateCDSc1sus and ADCs

Problem:

ADCs are timing out on c1sus when we have more than 3.

Talked with Rolf:

Alex will be back tomorrow (he took yesterday and today off), so I talked with Rolf.

He said ordering shouldn't make a difference and he's not sure why would be having a problem. However, when he loads the chassis, he tends to put all the ADCs on the same PCI bus (the back plane apparently contains multiples).  Slot 1 is its own bus, Slots 2-9 should be the same bus, and 10-17should be the same bus.

He also mentioned that when you use dmesg and see a line like "ADC TIMEOUT # ##### ######", the first number should be the ADC number, which is useful for determining which one is reporting back slow.

Plan:

Disconnect c1sus IO chassis completely, pull it out, pull out all cards, check connectors, and repopulate with Rolf's suggestions and keeping this elog in mind.

In regards to the RFM, it looks like one of the fibers had been disconnected from  the c1sus chassis RFM card (its plugged in in the middle of the chassis so its hard to see) during all the plugging in and out of the cables and cards last night.

  3944   Thu Nov 18 01:52:58 2010 KevinUpdateElectronicsREFL55 Transfer Functions

I measured the optical and electrical transfer functions for REFL55 and calculated the RF transimpedance. To measure the optical transfer function, I used the light from an AM laser to simultaneously measure the transfer functions of REFL55 and a New Focus 1611 photodiode. I combined these two transfer functions to get the RF transimpedance for REFL55. I also measured the electrical transfer function by putting the RF signal from the network analyzer in the test input of the photodiode.

I put all of the plots on the wiki at http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/REFL55.

  3943   Thu Nov 18 00:40:31 2010 yutaUpdateIOOPRM reflected beam reached AP table

(Kiwamu, Yuta)

Summary:
  Yesterday, we placed the new PRM to BS chamber and the beam reached PR2 at ITMX chamber.
  Today, we lead the PRM reflected beam back to AP table.
  Also, we aligned PRs so that the beam hits ITMX and ITMY.

What we did:
  1. Aligned PR2 at ITMX chamber and PR3 at BS chamber so that the beam hits ITMY.

  2. Aligned ITMX using IFO_ALIGN sliders so that the reflected beam overlaps at BS.

  3. Aligned BS using IFO_ALIGN sliders so that the splitted beam to ITMX overlaps the green beam from the X-end.

  4. Roughly aligned ITMY using IFO_ALIGN sliders so that the reflected green goes to far x-end.

  5. From yesterdays in-vac work, the reflected beam from PRM reached the Faraday.
     Aligned 2 steering mirrors in MC chamber so that the beam reaches AP table.

  6. Found the beam is double-spotted by a steering mirror at just after the Faraday symmetric port.
      The mirror is Y1-2037-45S. The beam is hitting it in ~10deg, so we have to replace it.

Plan:
  - replace the steering mirror right next to the Faraday symmetric port.
  - recyled Michealson

Note:
  We had to use "ITMX" channels to align ITMY. We have to fix and check X-Y confusion.
  Also, damping servo for ITMs does not seem to work. We have to check this.

  3942   Wed Nov 17 23:45:20 2010 JenneUpdateSUSA bad day for suspensions

[Jenne, Suresh]

Today has been a downright miserable day in the world of suspension work. Thumbs down to that: 

Yesterday, we had glued 2 full sets of magnets to dumbbells.  Today, half of those broke.  I think I put too thin of a layer of glue on the magnets when gluing them to the dumbbells.  All magnet/dumbbell assemblies should pass the test of being picked up by the dumbbell while the magnet is stuck to the optical table or a razor blade.  6 of the 12 magnets failed this test. Suresh soaked the dumbbells that had been used in acetone, and scrubbed them, so we can reuse them when we reglue things tomorrow.  By some miracle, we have exactly one full set intact (for each set of 6, we need 4 of one direction and 2 of the other).  This was frustrating, but not yet a deal-breaker.  That part comes next....

I got ETMU05 nicely aligned in the magnet gluing fixture, and then was on my last check of whether the side magnets would be glued in the correct place when I realized that the fixture is all wrong for the ETMs.  This final check was added to the procedure after the drama with the ITMs of having the side magnets glued incorrectly as a result of the fixture being specific to the wedge angle of the optic.  Kiwamu and I had set the fixture to be just right for the ~1deg wedge corner station optics, but the ETMs have a 2.35deg wedge (according to the Coastline spec sheet, which is consistent with our measurements when placing the guiderod and standoffs).  Suresh and I need to reset the height of the optic in the fixture using more teflon sheets, but we don't have a whole lot of options ready in the cleanroom.  We're going to cut some more pieces and ask Bob to clean them tomorrow.  Since the way the fixture holds the teflon is a little hoaky, Suresh suggested just resting the optic on teflon pads, rather than screwing the teflon to the fixture, and then putting the optic on the pads.  We'll try Suresh's method tomorrow, and hopefully it will be pretty easy. 

At least the guiderods and standoffs were successfully glued to the optics....

Here's the updated Status Table.  I don't think we're going to be able to have an ETM ready for the chambers early next week, but we should still be able to have both ready for the Monday after Thanksgiving.  The spring plungers arrived today, and were given immediately to Bob and Daphen for cleaning.

StatusTable.png

  3941   Wed Nov 17 20:44:59 2010 yutaSummaryCDSno QPD channels on c1sus machine today

(Joe, Suresh, Yuta)

Currently, only 2 ADC cards work on c1sus machine.
No QPD inputs(e.g. MC2 trans), and no RFM.


Summary:
  We wanted to have PEM(physical environment montor) channels, so we moved a ADC card in c1sus machine.
  It ended up with destroying one of the 3 ADCs.

What we did:
  1. Moved ADC card at PCIe expansion board slot 0 to other empty slot.
     What we call PCI slot 0 was "DO NOT USE" in LIGO-T10005230-v1, so we moved it.

  2. Connected that ADC card to PEM channel box at 1X7 via SCSI cable.

  3. ADC card order is changed, so we checked ADC number assinging and re-labeled the cable.

  4. Found RFM is not working(c1sus and c1ioo not talking) and fb is in a weird state(Status: 0x4000 in GDS screens)

  5. Swapped the cabling so that ADC card 0 will be connected to timing interface card at slot1, but didn't help.
     More than that, we suffered ADC timeout.

  6. Tried ADC card swapping, slot position changing, taking out some of the ADC cards, etc.
     We found that ADC timeout doesn't happen with 2 ADC cards.
     But if we connect one of the ADC card to the timing interface card at slot 8, c1sus ADC timeouts with 2 ADC cards, too.
     So, I think that timing interface card is bad.

  7. Stopped rebooting c1sus again and again. We decided to investigate the problem tomorrow.
     We only need ADC card 0 and 1 for MC damping.(see this wiki page)
       ADC card 0: all UL/UR/LR/LL SENs
       ADC card 1: all SD SENs     
       ADC card 2: all QPDs

Result:
  We can damp optics and lock MC.
  We can't do A2L because RFM is not working.
  We can't see MC2 trans because we currently don't have ADC card 2.

  3940   Wed Nov 17 16:02:30 2010 josephbUpdateCDSModified feCodeGen.pl to fix filtMuxMatrix name generation

Problem:

Sometime in the last 3 weeks, probably when Alex brought his latest changes from Hanford to the 40m and did an SVN update, the code which generates the names of the filter .adl files links for the overall matrix view broke.

Fix:

I modified FE code gen to use $basename instead of the base name after the top name transform (this changes _ to - after the first 3 letters

@@ -3520,11 +3522,11 @@
 
                  my $tn = top_name_transform($basename);
                  my $basename1 = $usite . ":" . $tn . "_";
-                 my $filtername1 = $usite . $tn;
+                 my $filtername1 = $usite . $basename;

Still having problems:

The filter modules built with the matrix of filter modules run (offests/gains work), but will not load filter coefficients/filter names.  All the other filter modules outside the matrix seem to load fine.  At this point, doing a rebuild of any of the front end machines may cause the A2L filter banks to be unloadable.

 

  3939   Wed Nov 17 15:49:53 2010 ranaUpdateDAQOle Channel Names

The following channels should be named as below to keep in line with their names pre-upgrade rather than use _DAQ in the name.

C1:SUS-{OPT}_{POS,PIT,YAW}

SUS{POS,PIT,YAW}_IN1
C1:SUS-{OPT}_OPLEV_{P,Y}ERROR

OL{PIT,YAW}_IN1

C1:SUS-{OPT}_SENSOR_{UL,UR,LL,LR,SIDE}
{UL,UR,LL,LR,SD}SEN_OUT
C1:SUS-{OPT}_OPLEV_{P,Y}OUT
OL{PIT,YAW}_OUT
C1:IOO-MC_TRANSPD
MC2_OLSUM_IN1

 

  3938   Wed Nov 17 10:39:20 2010 josephbUpdateCDSScreen Time Fix

An improved python code to apply a replacement to all *.adl files in a directory would be:

import re, os
files = os.listdir("./")
  for file in files:
    if ".adl" in str(file):
      data = open(file).read()
      o = open(file,"w")
      o.write( re.sub("C0:TIM-PACIFIC_STRING","C1:FEC-34_TIME_STRING",data)  )
      o.close()

Of course, this entire python script can be replaced with a single sed command:

sed -i 's/C0:TIM-PACIFIC_STRING/C1:FEC-34_TIME_STRING/g' *

A more complicated script could be written which looks for key identifiers either in the file header or inside the file to determine which front end is appropriate, using a dictionary like:

dcuid_dict = {"BS":21,"PRM":37,"SRM":37,"ITMX":21,"ITMY":21,"MC1":36,"MC2":36,"MC3":36,"ETMX":24,"ETMY":26}

and then using for loops and if statements.

 

  3937   Wed Nov 17 02:53:41 2010 yutaUpdateIOOplaced new PRM to BS table

(Kiwamu, Yuta)

Background:
  Yesterday, we aligned the Faraday and the beam reached SM2 at BS table.
  Today, we placed a new PRM tower to BS table.

What we did:

  1. Moved IPPO, IPPOSSM1, IPPOSSM3, IPANGSM1, IPANGSM2 out from the BS chamber.

  2. Moved SRM tower(at PRM's place) to the ITMX chamber.

  3. Placed the new PRM tower at the BS chamber.

  4. Adjusted positions of the OSEMs for PRM and BS so that the sensor output can have roughly half of their maximum.

  5. Checked damping servo for PRM and BS. They were working and helped us when adjusting OSEM positions.

  6. Placed IPPO back and using SM2, made the beam hit PR2 at ITMX table.

  7. Aligned the PRM so that the reflected beam path overlaps the incident beam.
     We checked it by looking at MMT1.
     For the alignment, we used IFO align sliders(C1:SUS-PRM_PIT_COMM, YAW_COMM).
        To use them, we rebooted c1susaux.

Result:
  1. The new PRM tower is placed.

  2. OSEM sensor outputs for PRM and BS are;

(V) PRM BS
max current value max current value
ULSEN 1.72 1.006 1.50 0.757
URSEN 1.66 0.918 1.57 0.821
LRSEN 1.92 1.304 1.57 0.821
LLSEN 2.06 1.031 1.38 0.704
SDSEN 9.21 4.366 1.57 0.821

    We changed PRM aligning slider values, and they changed OSEM sensor outputs. We set the slider values to 0 when adjusting OSEM positions.

  3936   Tue Nov 16 23:36:29 2010 Suresh, JenneUpdateSUSAssembly of ETMs

[Jenne, Suresh]

 

The ETM assembly has moved forward a couple of steps.  We have completed the following:

1) Positioning the guide rod and wire stand-off on both the ETMs (5 and 7)

2) The magnets had to be cleaned with an acetone wash as they had touched the plastic Petri-dish (not cleaned for vacuum).

3) The magnets and the Al dumb-bells have been glued together and left to cure in the gluing fixture.

4) The guide-rod and wire stand-offs have also been glued to the optic and left to cure for 24 hrs.

 

 

JD:  As you can see in my nifty status table, we are nearing the end of the suspension story.  

StatusTable.png

We are going to try (but can't guarantee) to get ETMX to Bob for baking by Friday at lunchtime, that way we can re-suspend it on ~Monday, and place it in the chamber.  Then we could potentially begin Green arm locking next week.  Steve has (hopefully!!) ordered the spring plungers for ETMY.  The receiving and baking of the spring plungers is the only current delay that I can foresee, and that only is relevant for one of the optics. 

We (who is going to be in charge of this?) still need to move the SRM OSEMs & cables & connectors to the ITMY chamber from the BS chamber. 

 

 

  3935   Tue Nov 16 21:42:31 2010 ranaUpdateCDSScreen Time Fix
I learned today that the following python code will do a find/replace to fix the TIME string on any MEDM screen which has a whited out time field.
Previously, this field was sourced from the c1dscepics of c1losepics process. Now we have to get it from the IOO or SUS front ends

Here's the python code:

import re
o = open("output.adl","w")
data = open("test.adl").read()
o.write( re.sub("C0:TIM-PACIFIC_STRING","C1:FEC-34_TIME_STRING",data)  )
o.close()

Where 'output.adl' could be the same name as 'test.adl' if you want to
replace the existing file. Also FEC-34 just refers to which FE you're running.
It could, in principle, be any one of them.
 

The next step is to figure out how to apply this to all the files in a directory.

  3934   Tue Nov 16 16:00:26 2010 AidanUpdateGreen LockingPID loop but no green

Quote:

RA: All MEDM screens must be in the proper MEDM directory!! Also, all perl scripts must have a .pl extension!!! Also, all scripts must be in the scripts directory even if they are in development!!! And all scripts should use 'env' rather than have absolute pathnames for the location of perl, csh, tcsh, python, etc.

 That's not unreasonable. But if we try 

 grep "perl" /cvs/cds/rtcds/caltech/c1/scripts/*/* 

you can see that we've got a fair amount of housekeeping to attend to. We might want to think about tidying up the scripts directory as part of the cds upgrade.

 

 

 

 

  3933   Tue Nov 16 15:32:18 2010 valeraUpdateElectronicsOSEM noise at the output of the satellite box

 I measured the SRM OSEM (no magnets at the moment) noise out of the satellite box with a SRS785 spectrum analyzer. I inserted a break out board into the cable going from the satellite box to the whitening board. The transimpedances of the SRM OSEMs are still 29.2 kOhm. The DC voltages out of the SRM satellite box are about 1.7 V. The signal was AC coupled using SR560 with two poles at 0.03 Hz and a gain of 10.

The noise is consistent with the one measured by the ADC except for the 3 Hz peak which does not show up in the ADC spectrum from Sunday. The peak appears in several channels I looked at. The instrument noise floor was measured by terminating the SR560 with 50 Ohm.

I recommend to change all OSEM transimpedance gains from 29 to 161 kV/A. Beyond this gain one will rail the AA filter module when the magnet is fully out of the OSEM.

The OSEM noise at 1 Hz is about factor of 10 above the shot noise. The damping loops impress this noise on the optics around the pendulum resonance frequency. Also the total contribution to the MC cavity length is sqrt(12) time the single sensor as there are 12 OSEMs contributing to MC length. The ADC noise is currently close but never the less not limiting the OSEM noise below 100 Hz. It can be further reduced by getting an extra factor of 2-3 in whitening gain above ~0.3 Hz. The rms of the ADC input of the modified PRM SD (R64 = 161 kOhm) channel is 10-20 cts during the day with damping loop off and whitening on.

The transimpedance amplifier LT1125CS is also not supposed to be limiting the noise. At 1 Hz the 1/f part of the noise: In<1pA/rtHz and Vn<20nV/rtHz.

  3932   Tue Nov 16 12:47:30 2010 AidanUpdateGreen LockingPID loop but no green

The PID loop is ready to be run on the green beat note but, since the tanks are open, there is no green transmission from the end getting to the PSL table. Nevertheless, here's the screen for the PID loop. The loop script is still in my directory /cvs/cds/caltech/users/abrooks/GRNXSlowServo

The medm screen is attached. It shows the current beat note frequency in MHz ()

In c1auxey/ETMYaux.db I added a couple of channels. These are all displayed on the MEDM screen. I added them to autoBurt.req as well.

  • C1:LSC-EX_GRNLSR_TEMP_NOM: the zero-volt setpoint temperature of the end laser (as set on the front panel of the Mephisto controller). This must be entered manually in EPICS as there is no way to read it remotely. [Sad Face]
  • C1:LSC-EX_GRNLSR_TEMP_CALC: the sum of the zero-volt set point temperature and the offset temperature set by the input voltage from C1:LSC-EX_GREENLASER_TEMP

I rebooted c1auxey to get these to work.

Once we get the green beat back again, the PID loop should servo on the end laser temperature to drive the Beat Frequency to the Frequency Setpoint, C1:LSC-EX_GRN_PID_SETPT, which can be set by the pink slider.

RA: All MEDM screens must be in the proper MEDM directory!! Also, all perl scripts must have a .pl extension!!! Also, all scripts must be in the scripts directory even if they are in development!!! And all scripts should use 'env' rather than have absolute pathnames for the location of perl, csh, tcsh, python, etc.

  3931   Tue Nov 16 10:47:45 2010 AidanUpdateGreen LockingRebooted c1psl - added new GRNBEAT_FREQ channel

I restored C1:PSL-126MOPA_126MON to its original settings (EGUF = -410, EGUL = 410) and added a new calc channel called C1:LSC-EX_GRNBEAT_FREQ that is derived from C1:PSL-126MOPA_126MON. The calibration in the new channel converts the input to MHz.

grecord(calc, "C1:LSC-EX_GRNBEAT_FREQ")
{
        field(DESC,"EX-PSL Green Beat Note Frequency")
        field(SCAN, ".1 second")
        field(INPA,"C1:PSL-126MOPA_126MON")
        field(PREC,"4")
        field(CALC,"0.4878*A")
        }

I rebooted c1psl and burtrestored.

  3930   Tue Nov 16 09:02:54 2010 AidanUpdateGreen LockingPID loop - calibration of SR620 output

 [Aidan, Kiwamu]

Kiwamu and I roughly calibrated the analogue output from the SR620 frequency counter yesterday. The input channel, intuitively named C1:PSL-126MOPA_126MON, now reads the measured frequency in MHz with an error of about 0.1MHz - this is, I think, due to the bit noise on the D/A conversion that Kiwamu discovered earlier. That is, the output range of the SR620 corresponds to around 100MHz and is digitized at 10-bit resolution, and ...

100MHz/(10^2) ~= 0.098MHz. [Sad Face]

Calibration:

We set the EPICS range to [-100, 100] (corresponding to [-5V, 5V]), connected a Marconi to the Freq Counter, input a variety of different frequencies and measured the counts on the EPICS channel.

The linear fit to the calibration data was F = 2.006*EPICScount - 0.2942. From this we worked out the maximum and the minimum for the range settings that give the channel in MHz: EGUF = -200.8942 and EGUL = 200.3058. The previous range was [-410, 410]

 

Calibration of SR620 analogue output
Input Frequency (MHz) Measured EPICS Value
10  5.191
20  9.98
30 15.21
40 20.00
50 25.18
60 29.99
70 35.18
71 35.565
72 35.9894
73 36.3861
74 37.17
75 37.576
76 37.9669
77 38.3575
78 39.166
79 39.5691
80 39.978
   

 

  3929   Tue Nov 16 03:33:22 2010 yutaUpdateIOOaligned Faraday, beam reached SM just before PRM

(Koji, Yuta)

We aligned the Faraday after MC and we are now ready to install PRM.

Background:
  MC was roughly aligned (beam spot ~0.7mm from the actuation center).
  So, we started aligning in-vac optics.
  First thing to align was the Faraday after MC3.

What we did:
  1. Ran A2L.py for confirmation.(Second from the last measurement point on the A2L result plot)

  2. Aligned the Faraday so that MC3 trans can go through it. We moved the Faraday itself, while we didn't touch IM2.
     We turned the pitch nob of the last steering mirror at PSL table in CCW slightly in order to lower the beam at the Faraday by ~1mm.

  3. During the alignment, we found that the polarization of the incident beam was wrong. It should have been S but it was P.
     As there is the HWP right before the EOM, Rana rotated it so as to have the correct polarization of S on the EOM and the MC.
     Note that the PMC and the main interferometer are configured to have P-pol while the MC is to have S-pol.

  4. Setup the video camera to monitor the entrance aperture of the Faraday. It required 4 steering mirrors to convey the image to the CCD.

  5. Moved all of the OSEMs for MC1 and MC3 so that the sensor output can have roughly half of their maxima.

  6. Ran A2L.py. (The last measurement point on the A2L result plot)

  7. Aligned the IO optics so that the beam goes Faraday -> MMT1 -> MMT2 -> SM3.

Result:

  1. OSEM sensor outputs for MC1 and MC3 are;

(V) MC1 MC3
max current value max current value
ULSEN 1.3 0.708 1.37 0.699
URSEN 1.4 0.845 1.71 0.796
LRSEN 1.45 0.743 1.77 0.640
LLSEN 1.56 0.762 1.56 0.650
SDSEN 1.67 0.801 1.59 0.821



  2. A2L result is;
MCalignNov16.png


     The beam position slightly got lower(~0.2mm), because we touched SM at PSL table.
     Alignment slider values changed because we moved MC1 and MC3 OSEMs.

  3. Now, MC_RFPD_DCMON is ~0.39 when MC unlocked and ~0.083 when locked.
     So, the visibility of MC is ~79% (for S-pol).

  4. Now the incident beam to the MC has S polarization, the cavity has higher finesse. This results the increased MC trans power.
     It was ~8e2 when the polarization was P, now it is ~4.2e3 when the MC is locked.

  5. The beam reached SM3 at BS table. The alignment of the SM2, MMT1, MMT2 were confirmed and adjusted.

  6. All pieces of the leftover pizza reached my stomach.

Plan:
  - Install PRM to the BS chamber.
  - Align PRM and get IFO reflection beam out to the AP table
 

  3928   Mon Nov 15 22:24:28 2010 SureshUpdateSUSSelection of Magnets

I have selected a set of 16 magnets which have a B field between 900 to 950 Gauss (5% variation) when measured in the following fashion.

I took a Petri-dish, of the type which we usually use for mixing the glue, and I placed a magnet on its end.  I then brought the tip of the Hall-probe into contact with the Petri-dish from the opposite side and adjusted the location (and orientation) of the probe to maximise the reading on the Gauss meter.

The distribution of magnets observed is listed below

 

Range of B Field (Gauss) # of Magnets
800-849 2
850-899 6
900-950
16

 

 

 

 

 

The set of sixteen has been have been placed inside two test tubes and left on the optical bench (right-side)  in the clean room.

 

 

  3927   Mon Nov 15 17:10:59 2010 kiwamuUpdateGreen LockingPLL with real green signal

 I checked the slow servo and the PLL of 80MHz VCO using the real green beat note signal.

 The end laser is not locked to the cavity, so basically the beat signal represents just the frequency fluctuation of the two freely running lasers.

 The PLL was happily locked to the green beat note although I haven't fedback the VCO signal to ETMX (or the temperature of the end laser).

 It looks like we still need some more efforts for the frequency counter's slow servo because it increases the frequency fluctuation around 20-30mHz.

 


 (slow servo using frequency counter)

   As Yuta did before (see his entry), I plugged the output of the frequency counter to an ADC and fedback the signal to the end laser temperature via ezcaservo.

The peak height of the beat note is bigger than before due to the improvement of the PMC mode matching.

The peak height shown on the spectrum analyzer 8591E is now about -39dBm which is 9dB improvement. 

 

     The figure below is a spectra of the frequency counter's readout taken by the spectrum analyzer SR785.

 FCnoise.png

When the slow temperature servo is locked, the noise around 20-30 mHz increased.

I think this is true, because I was able to see the peak slowly wobbling for a timescale of ~ 1min. when it's locked.

But this servo is still useful because it drifts by ~5MHz in ~10-20min without the servo.

Next time we will work on this slow servo using Aidan's PID control (see this entry) in order to optimize the performance.

In addition to that, I will take the same spectra by using the phase locked VCO, which provides cleaner signal.

 

(acquisition of the PLL)

 In order to extract a frequency information more precisely than the frequency counter, we are going to employ 80MHz VCO box.

 While the beat note was locked at ~ 79MHz by the slow servo, I successfully acquired the PLL to the beat signal.

 However at the beginning, the PLL was easily broken by a sudden frequency step of about 5MHz/s (!!).

I turned off the low noise amplifier which currently drives the NPRO via a high-voltage amplifier, then the sudden frequency steps disappeared.

After this modification the PLL was able to keep tracking the beat signal for more than 5min.

(I was not patient enough, so I couldn't stand watching the signal more than 5min... I will hook this to an ADC)

Quote: #3920

Some more details will be posted later.

 

  3926   Mon Nov 15 16:26:46 2010 josephbUpdateCDSc1iscex is now running and the network hasn't died

Problem:

c1iscex was spamming the network with error messages.

Solution:

Updated the front end codes to current standards (they were on the order of months out of date).  After fixing them up and rebuilding the codes on c1iscex, it no longer had problems connecting to the frame builder.\

Status:

I can look at test points for ETMX.  It is not currently damping however.

To Do:

Move filters for ETMX into the correct files. 

Need to add a Binary output blue and gold box to the end rack, and plug it into the binary output card.  Confirm the binary output logic is correct for the OSEM whitening, coil dewhitening, and QPD whitening boards. 

Get ETMX damped.

Figure out what we're going to do with the aux crate which is currently running y-end code at the new x-end.  Koji suggested simply swapping auxilliary crates - this may be the easiest.  Other option would be to change the IP address, so that when it PXE boots it grabs the x-end code instead of the y-end code.

Current CDS status:

MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Sim.Plant Frame builder TDS
                     
  3925   Mon Nov 15 16:09:44 2010 JenneUpdateVACETMX, ETMY, ITMY chambers opened

[Steve, Jenne, Suresh, Koji]

The remaining test mass chambers have been opened, and have light doors in place.  Now we can do all of the rest of the IFO alignment, and then (hopefully) button up before the New Year.

  3924   Mon Nov 15 15:02:00 2010 KojiSummaryPSLpower measurements around the PMC

[Valera Yuta Kiwamu Koji]

Kiwamu burtrestored c1psl. We measured the power levels around the PMC.

With 2.1A current at the NPRO:

Pincident = 1.56W
Ptrans_main = 1.27W
Ptrans_green_path = .104W

==> Efficiency =88%

----

We limited  the MC incident power to ~50mW. This corresponds to the PMC trans of 0.65V.
(The PMC trans is 1.88V at the full power with the actual power of 132mW)

  3923   Mon Nov 15 15:01:51 2010 kiwamuUpdateIOOrealigned the wideband EOM

Since we are going to lock the MC today, I aligned it back to the default place.

Quote: #3888

For Yuta's business, I intentionally misaligned the wideband EOM slightly to Yaw direction. 

  3922   Mon Nov 15 14:42:01 2010 AidanUpdatePSLC1PSL rebooted?

Yeah. Joe and I rebooted c1psl a couple of times this morning. I didn't realize the burtrestore wasn't automatic.

 

Quote:

Has C1PSL rebooted? Has burtrestore been forgotten? Even without elog?

We found some settings are wrong and the PMC has pretty low gain.

 

  3921   Mon Nov 15 14:36:37 2010 KojiUpdatePSLC1PSL rebooted?

Has C1PSL rebooted? Has burtrestore been forgotten? Even without elog?

We found some settings are wrong and the PMC has pretty low gain.

  3920   Mon Nov 15 11:52:22 2010 kiwamuUpdateGreen LockingPLL with real green signal

 PLL_with_green.png

Stabilizing the beat note frequency using Yuta's temperature servo (see this entry)

I was able to acquire the PLL of 80MHz VCO to the real green signal.

Some more details will be posted later.

  3919   Mon Nov 15 11:13:12 2010 josephbUpdateCDSModified rc.local to not start mx_streams automatically

Problem:

c1iscex floods the network with about 1 gigabyte of error messages in a few seconds, writing to a log file in /opt/rtcds/caltech/c1/target/fb/logs/

Temporary change:

I commented out the following line in the rc.local file on the fb machine in the /diskless/root/etc/ directory:

#nice --20 ./mx_stream -s "$SYSTEMS" -d fb:0 >& logs/$HOSTNAME.log&

This disables the automatic start up of the mx_streams code on all the front ends.  This will prevent the network being brought to its knees by c1iscex while we debug the problem.

It also means on a reboot of the front ends, the mx_stream process needs to be started by hand until this change is reverted.

To do this, log into the front end and then change directory to /opt/rtcds/caltech/c1/target/fb

For c1sus, run:

./mx_stream -s c1x02 c1sus c1mcs c1rms c1rfm  -d fb:0

For c1ioo, run:

./mx_stream -s c1x03 c1ioo -d fb:0

 

  3918   Mon Nov 15 04:57:10 2010 ranaUpdateElectronicsSRM side OSEM noise with no magnet

IF I believe this calibration and IF I believe that the noise is the same with no magnet in there, then its almost 1 nm/rHz @ 1 Hz.

I am guessing that Jenne's calculation will show that this is an unacceptably high level of OSEM sensor noise, OAF-wise.

  3917   Sun Nov 14 16:40:46 2010 JenneUpdateTreasureActivities related to OSEM measurement

[Valera, Jenne]

We pondered the idea of clamping the PRM optic to measure the OSEM noise.  So we opened up the BS tank to give this a try.  We rediscovered that Jenne is too short to reach the other side of the PRM tower, so we couldn't fully clamp the optic (when is Jaime coming again? He's kind of tall...)  If we only did the back 2 EQ stops, the optic would still be able to rock, and thus defeat the purpose of clamping anyway.  So we didn't go for it. 

While we were in there we saw that the SRM OSEMs were just hanging out on the table, and decided to go with them.  See Valera's elog for details on our measurement.  We closed up the tank without making any changes to anything.

In other news, we still need to figure out how to change up the connectors to get those OSEMs over to the ITM table.  This needs to happen pretty soonish. 

  3916   Sun Nov 14 16:26:31 2010 jenne, valeraUpdateElectronicsSRM side OSEM noise with no magnet

We realized that the SRM sensors are connected to the readout but just sitting on the BS in vacuum table with no magnets and therefore no shadows in them. We swapped the inputs to the SRM and PRM satellite boxes to use the higher transimpedance gain of the PRM side sensor. The attached plot shows the current spectrum in this configuration. The PD readback voltage was 9.5 V. Since this is close to the rail we put a slightly higher voltage into the AA of this channel to test that we can read out more ADC counts to make sure we are not saturating. The margin was 15800 vs 15400 counts with p-p of 5 counts on the dataviewer 1 second trend. We returned all cables to nominal configuration.

The calibration from A to m is 59 uA/1 mm.

  3915   Sun Nov 14 11:56:59 2010 valeraUpdateCDSTest of ADC noise

 

We missed a factor of 2 in the ADC calibration: the differential 16 bit ADC with +/-10 V input has 20 V per 32768 counts (1 bit is for the sign). I confirmed this calibration by directly measuring ADC counts per V.

So the ADC input voltage noise with +/-10V range around 100 Hz is 6.5e-3 cts/rtHz x 20V/32768cts =  4.0 uV/rtHz. Bummer. 

The ADC quantization noise limit is 1/sqrt(12 fs/2)=1.6e-3 cts/rtHz. Where the ADC internal sampling frequency is fs=64 kHz. If this would be the limiting digitization noise source then the equivalent ADC input voltage noise would be 1 uV/rtHz with +/-10 V range.

  3914   Sun Nov 14 02:59:31 2010 ranaConfigurationGeneralMEDM snapshots web page

Since Nodus is a Solaris machine it can barely handle doing the ImageMagick commands (such as convert and import). I removed the auto MEDM snapshot routine from it

awhile ago and I think the rate of ELOGD crashes has decreased, although its not definitive.

The snapshots have now been re-actived to run on MAFALDA, after I fixed the absolute pathnames in the scripts and installed (via yum) the packages that mafalda

needed to run this (Xvfb, openmotif, compat, etc.). The snapshots web page is now refreshing by itself and the statScreen/cronjob.sh is running on mafalda 5x per hour.

https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

  3913   Sat Nov 13 16:57:21 2010 valeraConfigurationElectronicsPRM Side OSEM transimpedance change

Now that we have increased the range of the AA to +/- 10 V I have increased the PRM side OSEM transimpedance from 29 kV/A to 161 kV/A by changing the R64 in the satellite box. The first attached plot shows the ADC input spectrum before and after the change with analog whitening turned off. The PD voltage readback went up from 0.75 to 4.2 V. The second attached plot shows the sensor, ADC, and projected shot noise with analog whitening turned on and compensated digitally. The ADC calibration is 20 V/ 32768 cts. The PRM damping loops are currently disabled.

I checked for oscillation by looking at the monitor point at the whitening board. There was no obvious oscillation on a scope - the signal was 20 mV p-p on 1 us scale which was very similar to the LL channel.

  3912   Sat Nov 13 15:53:05 2010 yutaUpdateCDSdiagonalization of MC input matrix

Motivation:
  MC is aligned from the A2L measurement, but to do the beam centering more precisely, we need coils to be balanced.
  There are several ways to balance the coils, like using oplev or WFS QPD RF channels.
  But oplev takes time to setup, especially for MC3. Also, c1ioo WFS channels were newly setup and haven't been checked yet.
  So, I decided to use OSEM sensors.
  An OSEM sensor itself is sensitive to every DOF of an optic motion, but we can diagonalize them using 4 OSEM sensors and proper input matrix.

Method:

  1. Measure transfer functions between
     ULSEN and URSEN (H_UR(f))
     ULSEN and LRSEN (H_LR(f))
     ULSEN and LLSEN (H_LL(f))

  2. Make a matrix A.

    A =  [[ 1           1           1          ]
          [ H_UR(f_pos) H_UR(f_pit) H_UR(f_yaw)]
          [ H_LR(f_pos) H_LR(f_pit) H_LR(f_yaw)]
          [ H_LL(f_pos) H_LL(f_pit) H_LL(f_yaw)]]


    where f_dof are resonant frequencies.

  3. A is

    s = Ad


   where vectors s^T=[ULSEN URSEN LRSEN LLSEN] and d^T=[POS PIT YAW].
   So,

    d = Bs = (A^TA)^(-1)A^Ts

   where A^T is transpose of A.

   B is the input matrix that diagonalizes 3 DOFs.

What I did:

  1. Measured the TFs using diaggui and exported as ASCII.

  2. Made a script that reads that TF file, calculates and sets a new input matrix B.
    /cvs/cds/caltech/users/yuta/scripts/inputmatrixoptimizer.py
   You need to set resonant frequencies to use the script.

   New input matrices for MCs are;

C1:SUS-MC1_INMATRIX
[[ 1.17649712  0.94315611  0.85065054  1.02969624]
 [ 0.55939288  1.28066594 -0.85235358 -1.3075876 ]
 [ 1.23467139 -0.74521928 -1.29394051  0.72616882]]

C1:SUS-MC2_INMATRIX
[[ 1.12630748  1.01451545  0.9013457   0.95783137]
 [ 1.03043025  0.67826036 -1.37270598 -0.91860341]
 [ 0.83546271 -1.26311029 -0.6456881   1.2557389 ]]

C1:SUS-MC3_INMATRIX
[[ 1.18212117  1.26419447  0.77744155  0.77624281]
 [ 0.79344415  0.84959646 -1.10946339 -1.247496  ]
 [ 1.00225331 -0.84807863 -1.21772132  0.93194674]]


  I ignored SIDE this time.

Result:

  Spectra of each SUSDOF_IN1_DAQ before diagonalization (INMATRIX elements all 1 or -1) were
MCspectraNov09.png

  After diagonalization, spectra are
MCspectraNov13.png

  As you can see, each SUSDOF has only single peak (and SIDE peak) after the diagonalization.
  SUSSIDE still has 4 peaks because SIDE is not included this time.

  For MC2, POS to SUSPIT and POS to SUSYAW got worse. I have to look into them.

Effect of resonant frequency drift:

  As you can compare and see from the spectra above, resonant frequencies of MC1 are somehow drifted(~0.5%) from Nov 9 to Nov 13.
  If resonant frequency you expected was wrong, calculated input matrix will be also wrong.
  The effect of 0.5% drift and wrong input matrix can be seen from this spectra. DOFs are not clearly separated.
 MC1spetra_wrongmatrix.png

Plan:

 - learn how to use diaggui from command line and fully automate this process
 - balance the coils using these diagonalized SUSPOS, SUSPIT, SUSYAW

  3911   Fri Nov 12 20:40:51 2010 josephb, yuta, valeraConfigurationElectronicsAA voltage range

We changed the range of the two SUS AA boards in the corner from +/-2 V to +/-10 V by changing the supply voltage from +/-5 V to +/-15 V. The change was made by switching the AA power feed wires on  the cross connect. The max supply according to the spec of DRV134/INA134 is +/-18 V.

We checked the new range by applying the voltage to the input of AA and measuring the output going to the ADCs. The local damping MC1,2,3 appears to work.

  3910   Fri Nov 12 19:24:56 2010 KojiUpdateCDSTest of ADC noise

[Koji Yuta]

We found one of the ADC cables were left unconnected. This left the MC suspensions uncontrollable through the whole afternoon.
Please keep the status updated and don't forget to revert the configuration...

Quote:

Test:

Look at the effects of the ADC voltage range on the ADC noise floor.

ADC input was terminated with 50 ohms.  We then looked at the channel with DTT. This was at +/- 10 V range.  We used C1:SUS-PRM_SDSEN_IN1 as the test channel.

The map.c file (in /opt/rtcds/caltech/c1/core/advLigoRTS/src/fe/ ) then had two lines added at line 766.

//JCB temporary 2.5V test, remove me
  adcPtr[devNum]->BCR &= 0x84240;

This hard coded the 2.5 V range (we default to the 10 V range at the moment).

We then rebuilt the c1x02 model and reran the test.

Finally, we reverted the code change to map.c and rebuilt c1x02.

Results:
I've attached the DTT output of the two tests.

It appears the ADC is limited by 1.6 uV/rtHz.  Hence the increase in noise in counts by a factor of 4 when we drop to +/- 2.5 V from +/- 10 V.

 

  3909   Fri Nov 12 13:12:55 2010 kiwamuUpdatePSLincreased NPRO power

I maximized the laser power by rotating the HWP after the NPRO.

If someone works on the MC locking, one should decrease it again.

 

  3908   Fri Nov 12 12:06:11 2010 AidanConfigurationGreen LockingPID script working - now it needs to be tuned

 I've set up a PID script that senses the EX-PSL Green Beat note (from the frequency counter) and actuates on the temperature of the end laser to drive the beat note to a given setpoint.

  • I've added the necessary EPICS channels to c1iscaux and rebooted it so that the channels are live. They are listed in a new database file slow_grnx_pid.db
  • This database was added to the list of those loaded by startup.cmd.  
  • The PID script, GRNXSlowServo, is just a modified version of FSSSlowServo.
  • The version I've been running is currently in /cvs/cds/caltech/users/abrooks/.
  • There's also an MEDM screen in this directoy, C1LSC_EX_GRN_SLOW.adl, there that shows the PID settings.

Right now the script only passes the initial sanities checks, that is:

  1. It runs.
  2. You can enable/disable it without any errors and it starts actuating.

The settings all need to be tuned up - e.g. maximum_increment, hard_stops, time_step, PID constants.

Additionally, the units in the whole thing are pretty useless - some of the channels are in VOLTS, others in WATTS. I'd like to change all these to be in Hz. 


EPICS channels added:

  • grecord(ao,"C1:LSC-EX_GRN_SLOWKD")
  • grecord(ao,"C1:LSC-EX_GRN_SLOWKP")
  • grecord(ao,"C1:LSC-EX_GRN_SLOWKI")
  • grecord(ao,"C1:LSC-EX_GRN_PID_SETPT")
  • grecord(ao,"C1:LSC-EX_GRN_TIMEOUT")
  • grecord(stringin,"C1:LSC-EX_GRN_SLOWVERSION")
  • grecord(bi,"C1:LSC-EX_GRN_SLOWLOOP")
  • grecord(bi,"C1:LSC-EX_GRN_DEBUG")
  • grecord(bi,"C1:LSC-EX_GRN_SLOWBEAT")
 

 

  3907   Fri Nov 12 11:36:06 2010 AidanConfigurationComputersFixed the PERL PATH errors from the scripts directory change

 I've been trying to get a PID loop running for the green locking and I've discovered that some of the directories in the path for the Perl Modules are now obselete. Specifically, since the scripts directory has been moved from /cvs/cds/caltech/scripts to /cvs/cds/rtcds/caltech/c1/scripts the following locations in the Perl @INC path list need to be changed:

  • /cvs/cds/caltech/scripts/general
  • /cvs/cds/caltech/scripts/general/perlmodules

I've added the above directories to the PERL5LIB path in /cvs/cds/caltech/cshrc.40m.

 

 

setenv PERL5LIB /cvs/cds/caltech/scripts/general:

/cvs/cds/caltech/scripts/general/perlmodules:

/cvs/cds/caltech/libs/solaris9/usr_local_lib/perl5/5.8.0/:

/cvs/cds/rtcds/caltech/c1/scripts/general:

/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules

 This seems to fix the problem .. at least, you no longer get an error if you try nodus:~>perl -e 'user EpicsTools'

 

  3906   Fri Nov 12 10:49:34 2010 josephb, valeraUpdateCDSTest of ADC noise

Test:

Look at the effects of the ADC voltage range on the ADC noise floor.

ADC input was terminated with 50 ohms.  We then looked at the channel with DTT. This was at +/- 10 V range.  We used C1:SUS-PRM_SDSEN_IN1 as the test channel.

The map.c file (in /opt/rtcds/caltech/c1/core/advLigoRTS/src/fe/ ) then had two lines added at line 766.

//JCB temporary 2.5V test, remove me
  adcPtr[devNum]->BCR &= 0x84240;

This hard coded the 2.5 V range (we default to the 10 V range at the moment).

We then rebuilt the c1x02 model and reran the test.

Finally, we reverted the code change to map.c and rebuilt c1x02.

Results:
I've attached the DTT output of the two tests.

It appears the ADC is limited by 1.6 uV/rtHz.  Hence the increase in noise in counts by a factor of 4 when we drop to +/- 2.5 V from +/- 10 V.

  3905   Fri Nov 12 06:10:24 2010 yutaUpdateIOOMC aligned (without coil balancing)

Background:
  Last night, we found that one of DAC channels are poorly connected, so we fixed the connectors.
  Rana and Koji used their incredible eyeballs to roughly align MC.
  Next thing to do is to balance the coils, but it takes some time for the setup.
  So, we decided to do A2L anyway.

What I did:
  Using the last steering mirror at PSL table and IM1, changed the incident beam direction to align MC.

Result:
MCalignCALIB.png
 
  I was amazed by their eyeballs.
  I turned the nobs of SM@PSL and IM1 in small increments, so I never lost TEM00.

Is it enough?:
  The length of the whole faraday is about 20cm and aperture diameter is about 12mm. (I couldn't measure the aperture size of the core)
  The beam is about 9mm diameter at 6w.
  So, if the beam is vertically tilted at more than ~3/200rad, it(6w) cannot go through.
  3/200 rad is about 20% difference in position at MC1 and MC3.
  So, the result meets the requirement.

  Also, assuming that coils have 5% imbalance, the beam position I measured have ~3% error.
  So, to do more precise beam centering, we need to balance the coils.

  3904   Fri Nov 12 02:51:20 2010 KevinUpdateElectronicsPhotodiode Testing

[Jenne and Kevin]

I started testing the REFL55 photodiode. With a light bulb, I saw ~270 mV of DC voltage from the photodiode but still could not see any RF signal. I connected the RF out from the spectrum analyzer to the test input and verified that the circuit was working.

I then set up the AM laser and looked at the laser light with REFL11 and an 1811 photodiode. I was able to see an RF signal and verified that the resonant frequency is 55 MHz.

The current setup is not very reliable because the laser is not mounted rigidly. Next, I will work on making this mounting more reliable and will continue to work on finding an RF signal with a flashlight.

  3903   Fri Nov 12 00:42:11 2010 rana, kojiUpdateIOOMC alignment

We decided to ignore the computer script outputs for the beam positions and use instead the eyeball method to get the beam into the MC:

  1. Adjust PSL launch beam to get the beam centered on IM1.
  2. Eyeball the beam to hit the center of MC1. We can get this pretty good by using the brackets to get the vertical and using the centering of the input/refl beams to center it horizontally.
  3. Use MC3 suspension to hit the center of MC2. We did this by hitting each of the 3 EQ stop screw heads and triangulating the MC3 bias settings.
  4. Use MC2 bias to hit the center of MC1.
  5. Use MC1 to get good flashes.
  6. Use all 3 MC sus biases to maximize the transmitted light and minimize the REFL DC.

With this rough alignment in place, we leave it to Yuta to finish the coil balancing and the A2L. We will have an aligned MC in the morning and will start the BS chamber alignment.

  3902   Fri Nov 12 00:13:34 2010 SureshUpdateSUSETM assembly started

[Jenne, Suresh]

Selection of ETMs

Of the four ETMs (5,6,7 and 8) that are with us Koji gave us two (nos. 5 and 7) for use in the current assembly.  This decision is based on the Radius of Curvature (RoC) measurements from the manufacturer (Advanced Thin Films).   As per their measurements the four ETMs are divided into two pairs such that each pair has nearly equal RoC. In the current case, RoCs are listed below:

   

Radii of Curvature of ETMs
ETM # RoC from Coastline Optics (m) RoC from Advanced Thin Films (m)
5 57.6 60.26
6 57.4 54.58
7 57.1 59.48
8 57.9 54.8

 

The discrepancy between the measurements from these two companies leaves us in some doubt as to the actual radius of curvature.  However we based our current decision on the measurement of Advanced Thin Films. 

 

Assembly of ETMs

We drag wiped both the ETMs (5 and 7) and placed them in the Small Optic Gluing Fixture.  The optics are positioned with the High Reflectace side facing downwards and with the arrow-mark on the Wire Standoff side (big clamp).  We then used the microscope to position the Guide Rod and the Wire Standoff in the tangential direction on the ETMs (step 4 of the procedure specified in E010171-00-D)

We will continue with the rest of the assembly tomorrow.

 

  3901   Thu Nov 11 23:35:23 2010 KojiSummaryCDSfound poor contact of DAC cable, previous A2L results were wrong

[Koji / Yuta]

There were the guys who used the PENTEK 40pin connectors into the IDC 40pin connectors.
Those connectors are not compatible at all.

==> We replaced the connectors on the cables from DAC to IDC adapters to the dewhitening board for the vertex SUSs.

In addition, I found one of the Binary OUT IDC50pin connector has no clamp.

==> We put the IDC50pin clamp on it.

bad-boys.png

PENTEK connectors were inserted. The latches are not working!

IMG_3698.jpg

the vertical pitch is different between PENTEK and IDC!
IMG_3705.jpg

Wow! Where is the clamp???

IMG_3706.jpg

Quote:

The cause is apparent! The connectors on the cables are wrong!
Currently only 50% of the pin length goes into the connector!

Quote:

(Koji, Jenne, Yuta)

We found one of DAC cables had a poor contact.
That probably caused our too much "tilt" of the beam into MC.

  It was because one of the DAC cables(labeled CAB_1Y4_88) had a poor contact.
  If I push it really hard, it is ok. But maybe we'd better replace the cable.

What caused a poor connection?:
  I don't know.
  A month ago, we checked that they are connected, but things change.

 

 

  3900   Thu Nov 11 21:07:49 2010 josephbUpdateCDSPlugged c1iscex into DAQ network - still causes network slowdown

I connected the c1iscex computer to the dedicated DAQ network switch (located in 1X7).

This does not seem to have helped c1iscex stop spewing out "OMX: Failed to find peer index of board 00:00:00:00:00:00 (Peer Not Found in the Table)" at the rate of ~1 Gigabyte per minute.

c1iscex is currently off until a solution can be found.

  3899   Thu Nov 11 18:05:55 2010 valeraUpdatePSLPMC mode matching at full laser power

 The PMC mode matching was initially done at low power ~150 mW. It was expected and found that at full power ~2 W (injection current 2.1 A) the mode matching got much worse:

the visibility degraded from 80% to 50% (1 - refl locked/refl unlocked) . The thermal lensing could be in the laser, EOM, or FI.

The first attached plot shows the scan of the beam after the EOM at low and full laser power. At full power the waist position is 10 mm after the turning mirror after the EOM and the waist size is 310 um.

The second plot shows the ABCD calculation for the mode matching solution.

I removed the MM lens PLCX-25.4-77.3-C and placed the PLCX-25.4-180.3-UV about 20 mm after the first PMC periscope mirror (the second mirror after the EOM).

The PMC visibility improved to 94% and the power through the PMC, as measured by the PMC transmission PD, went up by a factor of 2.

ELOG V3.1.3-