40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 112 of 341  Not logged in ELOG logo
IDup Date Author Type Category Subject
  5589   Fri Sep 30 18:06:24 2011 kiwamuSummaryIOOPZTs straing guage

beforeOutage110930.png

  5590   Fri Sep 30 18:35:42 2011 steve, kiwamuUpdateVACvacuum set for poweroutage

We did the following:

1, closed V1, VM1,  annuloses: VASE, VASV, VABS, VAEV,  VAEE and VA6

2, stop rotation of Maglev-TP1, waited to decellerate and turned off power to it

3, closed V4,  stoped rotation of TP2, waited to decellerate and turned power off

4, opened VM3 to RGA that is still running

 

I will come in tomorrow 9-10am to restart pumping.

  5591   Fri Sep 30 19:12:56 2011 KojiUpdateGeneralprep for poweroutage

 

 [Koji Jenne]

The lasers were shutdown

The racks were turned off

We could not figure out how to turn off JETSTOR

The control room machines were turned off

FInally we will turn off nodus and linux1 (with this order).

Hope everything comes back with no trouble

(Finger crossing)

  5592   Sat Oct 1 17:47:21 2011 KojiSummaryGeneralRecovery from the power shutdown

[Steve Koji Kiwamu]

- The storage on linux1 and linux1 itself (with this order) were turned on at 10:30am

- Kiwamu restored the vacuum system

   => opened V4, started TP1 (maglev) and opened V1.

      The pressure went downfrom 2.5 mTorr to the normal level in about 20 minutes.

- A regular fsck of linux1 was completed at 5pm

- Nodus was turned on. Mounting /cvs/cds succeeded

- The control room computers were turned on

- The rack power for FB turned on, FB and megatron started.

- Kiwamu and Koji went through all of the rack powers and started the slow and fast machines.
As we found Solensen for -15V at ETMX was current limited. +/-15V were turned off for now.
==> Kiwamu turned on Solensen again for investigation and found it became okay.
It's now ON.
 
- c1sus and c1ioo had many red lamps on the FE status screen.
Ran killc1XXX for all of the FE codes on c1lsc and c1ioo.
Then, made software reboot (sudo shutdown -r now)
All of the FEs shows green (after some randome clicking of DIAGRESETs)

- HVs on 1X1 were turned on. The are not vacuum HV, but used only in the air

- Turned on the RF generation box and the RF distribution box

- burtrestore slow machines (c1psl, c1susaux, c1iool0, c1iscaux, c1iscaux2, c1auxex, c1auxey)

  5593   Sat Oct 1 22:53:49 2011 kiwamuSummaryGeneralRecovery from the power shutdown : lockable

Found the Marconi for the 11 MHz source had been reset to its default.

 => reset the parameters. f = 11.065910 MHz (see #5530) amp = 13 dBm.

Interferometer became lockable. I checked the X/Y arm lock, and MICH lock, they all are fine.

  5594   Sun Oct 2 02:21:27 2011 kiwamuUpdateSUSfree swinging test once more

The following optics were kicked:
MC1 MC2 MC3 ETMX ETMY ITMX ITMY PRM SRM BS
Sun Oct  2 02:13:40 PDT 2011
1001582036

They will automatically get back after 5 hours.

  5595   Sun Oct 2 02:33:32 2011 kiwamuUpdateLSCsomething funny with AS55

Just a quick report.

The AS55 signal contains more noise than the REFL signals.

Why ? Is this the reason of the instability in PRMI ?

outofloop.png

 I locked the Power-Precycled ITMY with REFL33.

As shown in the plot above, I compared the in-loop signal (REFL33) and out-of-loop signals (REFL11 and AS55).

All the signals are calibrated into the displacements of the PR-ITMY cavity by injecting a calibration peak at 283 Hz through the actuator of PRM.

AS55 (blue curve) showed a structure around 3 Hz and higher flat noise below 1 Hz.

Quote from #5582
I am suspecting that something funny (or stupid) is going on with the MICH control rather than the PRCL control.

 

  5596   Sun Oct 2 13:45:13 2011 ranaSummaryGeneralRecovery from the power shutdown: apache / svn

Restarted Apache on nodus using Yoichi's wiki instructions. SVN is back up.

  5597   Sun Oct 2 18:33:36 2011 kiwamuUpdateSUSinversion of the input matrix on ETMX, ITMX and PRM

The input matrices of ETMX, ITMX and PRM have been newly inverted.

Those were the ones having some troubles (see #5444, #5547).

After a coarse adjustment of the damping Q factors, they look damping happily.

 

    optic                    spectra    inverted matrix   BADNESS
ETMX ETMX.png       pit     yaw     pos     side    butt
UL    0.848   0.108   1.578   0.431   1.025 
UR    0.182  -1.892   1.841  -0.128  -1.172 
LR   -1.818  -1.948   0.422  -0.122   0.939 
LL   -1.152   0.052   0.159   0.438  -0.864 
SD    1.756  -3.794  -0.787   1.000  -0.132 
  5.37028
ITMX ITMX.png     pit     yaw     pos     side    butt
UL    0.510   0.584   1.228   0.458   0.203 
UR    0.783  -1.350   0.348  -0.050   0.555 
LR   -1.217   0.065   0.772   0.264   0.312 
LL   -1.490   2.000   1.652   0.772  -2.930 
SD   -0.635   0.853  -1.799   1.000  -1.597  
 7.5125
PRM PRM.png       pit     yaw     pos     side    butt
UL    0.695   1.422   1.774  -0.333   0.954 
UR    1.291  -0.578   0.674  -0.068  -0.939 
LR   -0.709  -1.022   0.226   0.014   0.867 
LL   -1.305   0.978   1.326  -0.251  -1.240 
SD    0.392  -0.437  -0.500   1.000   0.420
 5.09674

 

(some notes)

 Before running the peakFit scripts, I woke up the nds2 sever process on Mafalda because it hasn't been recovered from the power outage.

To start the nds2 process I followed the instruction by Jamie (#5094).

Then I started requesting the data of the last night's free swinging test (#5594)

However the NDS2_GetData command failed everytime when data with long duration were requested.

It maybe because some of the data are missing in sometimes, but I haven't seriously checked the data stored in fb.

So for the reason, I had to use a short duration of 1200 sec (default is 3600 sec). That's why spectra look noisier than usual.

  5598   Mon Oct 3 04:43:03 2011 kiwamuUpdateLSCsideband-resonance PRMI locked

My goal of today was to lock PRMI without using AS55 and it is 50% successful.

The sideband-resonance PRMI (SB-PRMI) was locked with REFL33_I and REFL55_Q for the PRCL and MICH control respectively.

The carrier-resonance PRMI wasn't able to be locked without AS55.

     (it looked no clean MICH signals at the REFL ports.)

 


(Motivation)

 The motivation of not to use AS55 came from the suspicion that AS55 was injecting some noise into MICH (#5595).

So I wanted to try another RFPD to see if it helps the stability or not. 

 

(locking activity)

  The lock of SB-PRMI was quite stable so that it stayed locked more than 30 minutes (it ended because I turned off the servos.)

Then I briefly tried DRMI while PRCL and MICH kept locked by the same control loops, namely REFL33_I and REFL55_Q.

The lock of MICH and PRCL looked reasonably robust against the SRCL fringes, but wasn't able to find a good signal for SRCL.

I think I am going to try locking DRMI tomorrow.

 - - settings

    Demod phase for REFL55 = -45.3 deg

    Demod phase for REFL33 = -14.5 deg

    Whitening gain for REFL55 = 4 (12 dB)

    Whitening gain for REFL33 = 10 (30 dB)

    MICH gain = 100

    PRCL gain = 8

 

(misc.)

 + I removed an iris on the ITMY table because it was in the way of POY. See the picture below.

ITMYtable.png

 

  + I found that burtrestore for the ETMX DC coil forces were not functional.

  => currently ETMX's "restore" and "mislalign" buttons on the C1IFO_ALIGN screen are not working.

  => According to the error messages, something seemed wrong on c1auxex, which is a slow machine controlling the DC force.

  5599   Mon Oct 3 08:38:21 2011 steveSummaryVACRecovery from the power shutdown is completed

 

I failed to start Rana's favorit anciant desktop computer at the vac rack. He has to baby this old beast just a little bit more.

Vacuum status: Vac Normal was reached through Farfalla: Rga was switched back to IFO and and Annuloses are beeing pumped now.

V1 was closed for about a day and the pressure reached  ~2.8 mTorr in the IFO.  This leakrate plus outgassing is normal

The ref cavity 5000V was turned on.

The only thing that has to be done is to restart the RGA. I forgat to turn it off on Friday.

 

  5600   Mon Oct 3 13:04:12 2011 JenneUpdateSUSAUXEX, AUXEY rebooted

Quote:

  + I found that burtrestore for the ETMX DC coil forces were not functional.

  => currently ETMX's "restore" and "mislalign" buttons on the C1IFO_ALIGN screen are not working.

  => According to the error messages, something seemed wrong on c1auxex, which is a slow machine controlling the DC force.

 [Suresh, Jenne]

Suresh pointed out the oddity that all of the EX, EY slow channels were showing white boxes on the medm screens on all of the workstations except Rosalba.  I don't know why Rosalba seemed to be working, but whatever.  I'm not 100% sure that Rosalba was even working properly....I shutdown ETMX and ETMY's watchdogs before we went to boot computers, but when I came back to the control room the 2 optics were rung up anyway.  Turning back on the watchdogs, the optics immediately began to damp happily.

Since Kiwamu had trouble with the slow channels for EX, we decided to key some crates. 

We keyed the c1auxey, and c1auxex crates, waited a few seconds, and then things looked okay in medm-land.  I looked at the "View Backup" for ETMX, and there were no values for the DC sliders, so since the arms are both flashing right now, I did a "save", and then confirmed that I can misalign and restore the optic.  However, since I didn't fully align/lock the cavity, the saved value for right now shouldn't be fully trusted.  We might have to manually align the cavity using the BS.

  5601   Mon Oct 3 14:05:41 2011 JenneUpdateSUSFailing to set SUS summary screen values

I assume it's because the burt restore didn't work for the SUS summary screen, but all of the values for the ifo suspensions (not the MCs...they're okay) are red. 

I am trying to run Rana's setSensors.py script, but am failing.  Any inspiration would be appreciated:

rosalba:SUS_SUMMARY>./setSensors.py 1001708529 500 .1 .25
['./setSensors.py', '1001708529', '500', '.1', '.25']
/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages/nds/__init__.py:28: RuntimeWarning: No protocol specified, attempting protocol nds_v2
  super(daq, self).__init__(host, port)
Connecting NDS2 .... authenticate done
Traceback (most recent call last):
  File "./setSensors.py", line 81, in ?
    mean = acquire(x)
  File "./setSensors.py", line 73, in acquire
    daq.request_channel(chans[x])
Boost.Python.ArgumentError: Python argument types in
    daq.request_channel(daq, str)
did not match C++ signature:
    request_channel(_daq_t {lvalue}, daq_channel_t*)

I'm not exactly sure what the problem is.  Line 73, looks like it should have 2 arguments in the daq.request_channel, but even if I put in the "daq" variable (which is set a few lines above), I get the exact same error.  So...something else is wrong.  Ideas from someone who "speaks" python??

  5602   Mon Oct 3 16:18:05 2011 JenneUpdateAdaptive FilteringMeditations on the OAF

Quote:

[Mirko, Den, Jenne]

We're modifying the c1oaf model, and we got to talking about the "Fx" part of "FxLMS".  In the past, we put in a guess for the filter.  What if we use the static wiener filter as the F, and send the wiener filtered witness channels to the adaptation algorithm? 

Are the wiener filter and the plant compensation filter ("Fx") the same?  Will this work?  Or is there some reason that they must be different?

Also:  Notes to self:  Put in filtered witness channels as well as regular into Adapt block.  Make sure that the order/number of inputs is correct.

 More meditations...

Mirko and I were talking about the tunability required for each DoF.  For right now, we're going to give each DoF its own mu and tau (adaptation gain and adaptation decay), but we're leaving all of the other things (number of taps, number of witnesses, delay, downsample rate) the same for each DoF's adaptation.  This may need to change later, but we'll get there when we get there. 

The one I'm most concerned about is the number of witnesses...  Mirko is suggesting that we give each adaptation algorithm all witnesses, and unused ones should converge to ~0.  I agree in principle, but I'm not sure that it's actually going to work that way.  I think we may need to be able to tell the algorithm which witnesses to look at for which DoF. 

Also, the Delay.... we may need to adjust it for each DoF.  In Matt's OAF "manual" in elog 395, he mentions the need to calculate the delay based on a plant TF.  Presumably since (except for the MC) all the witnesses come in together, and all the DoFs come in together, the delay should be about the same for all?  We'll have to see...

  5603   Mon Oct 3 17:06:27 2011 JenneHowToComputer Scripts / ProgramsKissel Button Generator

Quote:

>pwd
/opt/rtcds/caltech/c1/medm/c1lsc_tst/master/KisselButtonGenerator

 I copied the Kissel button generator scripts folder into scripts:

/opt/rtcds/caltech/c1/scripts/KisselButtonGenerator/

Maybe this isn't the most intuitive place ever, since it's a script that only has to do with medm screens, but at least it's better than hidden in the depths of Koji's LSC medm path.....

  5604   Mon Oct 3 17:27:23 2011 JenneUpdateSUSFailing to set SUS summary screen values

Quote:

I am trying to run Rana's setSensors.py script, but am failing.  Any inspiration would be appreciated:

rosalba:SUS_SUMMARY>./setSensors.py 1001708529 500 .1 .25
['./setSensors.py', '1001708529', '500', '.1', '.25']
/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages/nds/__init__.py:28: RuntimeWarning: No protocol specified, attempting protocol nds_v2
  super(daq, self).__init__(host, port)
Connecting NDS2 .... authenticate done
Traceback (most recent call last):
  File "./setSensors.py", line 81, in ?
    mean = acquire(x)
  File "./setSensors.py", line 73, in acquire
    daq.request_channel(chans[x])
Boost.Python.ArgumentError: Python argument types in
    daq.request_channel(daq, str)
did not match C++ signature:
    request_channel(_daq_t {lvalue}, daq_channel_t*)

I'm not exactly sure what the problem is.  Line 73, looks like it should have 2 arguments in the daq.request_channel, but even if I put in the "daq" variable (which is set a few lines above), I get the exact same error.  So...something else is wrong.  Ideas from someone who "speaks" python??

 My guess is that this has something to do with the NDS client version you're using.  Try running the script on a machine where pynds and nds-client are known to be compatible, like pianosa.

  5605   Mon Oct 3 17:57:12 2011 kiwamuUpdateASCIPPOS fixed

The input matrix of IPPOS were fixed so that the horizaontal motion correctly shows up in X and the vertial is Y.

 

(what I did)

 + The data base file, QPD.db, were edited.

  QPD.db is a part of the c1isxaux slow machine and it determines the input matrix for deriving the X/Y signals from each quadrant element.

 + The previous input matrix was :

      X = (SEG1 + SEG4) - (SEG2 + SEG3)

      Y = (SEG1 + SEG2) - (SEG3 + SEG4)

 + The new matrix which I set is :

     X = (SEG1 + SEG2) - (SEG3 + SEG4)

     Y = (SEG1 + SEG4) - (SEG2 + SEG3)

    The new matrix is a just swap of the previous X and Y.

 + Then c1isxaux was rebooted by :

     telnet  c1iscaux

     reboot          

 + The I did the burt restore it to this morning.

Quote from #5574

The channels for IPPOS had been assigned in a wrong way.

 

  5606   Mon Oct 3 20:02:59 2011 SureshUpdatePSLAM / PM ratio

[Koji, Suresh]

In the previous measurement, the PDA 255 had most probably saturated at DC, since the maximum ouput voltage of PDA255 is 5V when it is driving a 50 Ohm load.  It has a bandwidth of 0 to 50MHz and so can be reliably used to measure only the 11 MHz AM peak.  In this band it has a conversion efficiency of 7000 V per Watt (optical power at 1064nm).  [Conversion efficiency:  From the data sheet we get 0.7 A/W of photo-current at 1064nm and 10^4 V/A of transimpedance]  The transimpedance at 55 MHz is not given in the data sheet.  Even if PDA255 is driving a high impedance load, at high incident power levels the bandwidth will be reduced due to finite gain x bandwidth product of the opamps involved, so the conversion efficiency at 11 MHz would not be equal to that at DC.

So Koji repeated the measurement with a lower incident light level:

**********************************

V_DC = 1.07 V  with 50 Ohm termination on the multimeter.

Peak height at 11 MHz on the spectrum analyzer (50 Ohm input termination) = -48.54 dBm

***********************************

Calculation: 

a) RF_Power at 11 MHz :  -48.45 dBm = 1.4 x 10^(-8) W

b) RF_Power = [(V_rms)^2] / 50_ohm  ==> V_rms = 8.4 x 10^(-4) V

c) Optical Power at 11 MHz: [V_rms / 7000] = 1.2 x 10^(-7) W

d) Optical Power at DC =  [V_DC / 7000] = 1.46 x 10^(-4) W

e) Intensity ratio:  I_AM / I_c = 7.9 x 10^(-4) . AM:Carrier amplitude ratio is half of the intensity ratio = 4.0 x 10^(-4)

f) PM amplitude ratio from Mirko's measurement is 0.2

g) The PM to AM amplitude ratio is 506

_________________________________

As the AM peak is highly dependent upon the drifting EOM position in yaw, it is quite likely that a higher PM/AM ratio could occur.  But this measurement shows how small it could get if the current situation is allowed to continue.

 

Quote:

[Mirko / Kiwamu]

 We have reviewed the AM issue and confirmed the ratio of AM vs. PM had been about 6 x103.

The ratio sounds reasonably big, but in reality we still have some amount of offsets in the LSC demod signals.

Next week, Mirko will estimate the effect from a mismatch in the MC absolute length and the modulation frequency.

 


(Details)

 Please correct us if something is wrong in the calculations.

 According to the measurement done by Keiko (#5502):

        DC = 5.2 V

        AM @ 11 and 55 MHz = - 56 dBm = 0.35 mV (in 50 Ohm system)

Therefore the intensity modulation is 0.35 mV / 5.2 V = 6.7 x 10-5

Since the AM index is half of the intensity modulation index, our AM index is now about 3.4 x 10-5

According to Mirko's OSA measurement, the PM index have been about 0.2.

As a result,  PM/AM = 6 x 103

Quote from #5502

Measured values;

* DC power = 5.2V which is assumed to be 0.74mW according to the PDA255 manual.

*AM_f1 and AM_f2 power = -55.9 dBm = 2.5 * 10^(-9) W.

 

 

  5607   Mon Oct 3 20:47:51 2011 kiwamuUpdateCDSc1lsc and c1sus didn't run

[Mirko / Jenne / Kiwamu]

Just a quick update. All the realtime processes on the c1lsc and c1sus machine didn't run at all.

Somehow the c1xxxfe.ko kernel module, where xxx is x04, x02, lsc, ass, sus, mcs, pem and rfm failed to be insmod.

The timing indicators on the c1lsc and c1sus machine are saying NO SYNC.

 

- According to log files (target/c1lsc/logs/log.txt)

insmod: error inserting '/opt/rtcds/caltech/c1/target/c1lsc/bin/c1lscfe.ko': -1 Unknown symbol in module

- dmesg on c1lsc (c1sus also dumps the same error message):

[   45.831507] DXH Adapter 0 : sci_map_segment - Failed to map segment - error=0x40000d01
[   45.833006] c1x04: DIS segment mapping status 1073745153

DXH dapter is a part of the Dolphine connections.

When a realtime codes is waking up, the code checks the Dolphin connections.

The checking procedure is defined by dolphin.c (/src/fe/doplhin.c).

According to a printk sentence in dolphin.c the second error message listed above will return status "0" if everything is fine.

The first error above is an error vector from a special dolphin's function called sci_map_segment, which is called in dolphin.c.

So something failed in this sci_map_segment function and is preventing the realtime code from waking up.

Note that sci_map_segment is defined in genif.h and genif.c which reside in /opt/srcdis/src/IRM_DSX/drv/src.

  5608   Mon Oct 3 21:20:30 2011 JenneUpdateCDSc1lsc and c1sus didn't run

[Jenne, Mirko, Kiwamu, Koji, and Jamie by phone]

We just got off the phone with Jamie.  In addition to all the stuff that Kiwamu mentioned, Mirko reverted the c1oaf model and C-code to stuff that was working successfully on Friday (using "svn export, rev # 1134) since that's what we were working on when all hell broke loose.

We did a few rounds of "sudo shutdown -h now" on c1lsc and c1sus machines, and pulled the power cords out.  

We also switched the c1ioo and c1lsc 1PPS fibers in the fanout chassis, to see if that would fix the problem.  Nope.  c1ioo is still fine, and c1lsc is still not fine.

Still getting "No Sync".

We're going to call in Alex in the morning, if we can't figure it out soon.

  5609   Mon Oct 3 23:52:49 2011 kiwamuUpdateCDSsome more tests for the Dolphin

[Koji / Kiwamu]

 We did several tests to figure out what could be a source of the computer issue.

The Dolphin switch box looks suspicious, but not 100% sure.

 

(what we did)

 + Removed the pciRfm sentence from the c1x04 model to disable the Dolphin connection in the software.

 + Found no difference in the Makefile, which is supposed to comment out the Dolphin connection sentences.

   ==> So we had to edit the Makefile by ourselves

 + Did a hand-comilpe by editing the Makefile and running a make command.

 + Restarted the c1x04 process and it ran wihtout problems.

   ==> the Dolphin connection was somehow preventing the c1x04 process from runnning.

 +  Unplugged the Dolphin cables on the back side of the Dolphin box and re-plug them to other ports.

   ==> didn't improve the issue.

 + During those tests, c1lsc frequently became frozen. We disabled the automatic-start of c1lsc, c1ass, c1oaf by editting rtsystab.

  ==> after the test we reverted it.

 + We reverted all the things to the previous configuration.

  5610   Tue Oct 4 07:51:36 2011 steveUpdateCDSc1lsc and c1sus are still down

 

 c1lsc and c1sus are still down. Only ETMX and ETMY are damped

  5611   Tue Oct 4 10:35:08 2011 MirkoUpdateCDSc1lsc and c1sus running again

[Alex, Mirko]

Alex fixed the computers this morning. It was in fact a dolphin problem:

Hi Jenne,  figured it out. Even though dxadmin said the Dolphin net was fine, it wasn't. Something happeneed to DIS networkmanager and I had to restart it. It is running on fb: 
controls@fb ~ $ ps -e | grep dis 12280 ?        00:00:00 dis_networkmgr
controls@fb ~ $ sudo /etc/init.d/dis_networkmgr restart
Once the restart was done both c1lsc and c1sus nodes were configured correctly, they printed the usual "node 12 is OK" "node 8 is OK" messages into the dmesg and was able to run /etc/start_fes.sh on lsc and sus to load all the FEs.  Alex

Some lights on c1lsc were still red: C1:DAQ-FBO_C1SYS_SYS and the smaller red light left of it. Restarted the fb. Didn't help. Restarted c1lsc, all green now.
Restored autoburt from Oct 3. 19:07 on c1lsc and c1sus.
  5612   Tue Oct 4 14:41:47 2011 JenneUpdateIOOMC Trans channels are digital 0

I relocked the PMC (why is it unlocking so much lately??), and then noticed that even though the MC is locked, MC Trans Sum, P, Y, are all seeing digital zero.  I'm putting Suresh, as IOO guy, in charge of figuring it out.

  5613   Tue Oct 4 15:43:10 2011 KojiUpdateIOOclosed the shutter before the MC

The shutter before the MC was closed at 3:30 as I started working on the RFAM.

MC REFL (INLOCK): 0.6~0.7
MC REFL (UNLOCK): 6.9
MC TRANS: 50000~52000

  5614   Tue Oct 4 15:57:30 2011 SureshUpdateIOOMC Trans channels are digital 0

I thought this problem might be arising because the MC2_TRANS QPD signals are not being passed from the c1mcs to c1ioo models over the rfm.   But there was no way to check if there is any data being picked up in c1mcs model.  So I copied the MCTRANS block from the c1ioo model into the c1mcs.  This block takes the four segments of the MC2_TRANS QPD and computes the pitch, yaw and sum signals from that.   It also exports these into epics channels.  I then recompiled and started the c1ioo c1mcs and c1rfm models. 

Restared fb at

Tue Oct  4 15:19:10 PDT 2011

Koji then noted that the MC2_TRANS filter banks in c1rfm and in c1ioo were showing nonzero values.   So the signals were infact reaching the c1ioo model.  They were being blocked by the INMATRIX (which the autoburt had not restored) of the MC_TRANS block, because all its elements were zero.  We burtrestored the c1iooepics to about 30hrs ago and then MC_TRANS signals were back in the LOCK_MC screen.

 

  5615   Tue Oct 4 16:10:45 2011 SureshUpdateComputer Scripts / ProgramsMC was not damping

The MC was not damping earlier this morning around 11:45AM.  The reason was that the INMATRIX on all the three MC1, 2 and 3 were zero.   This was seen earlier when autoburt did not restore this.

This got fixed when I Burt-Restored c1mcsepics.snap

In the afternoon we had to restore c1mcs again to restore the MC_TRANS channels because its INMATRIX was also zero.

Can we do something to make sure this gets done in the autoburt properly?

  5616   Tue Oct 4 16:58:45 2011 SureshUpdatePSLAM / PM ratio

Correction: Koji noted that Mirko actually reports a PM modulation index of 0.17 for the 11 MHz sideband (elog: http://nodus.ligo.caltech.edu:8080/40m/5462. This means

f) the amplitude ratio of the PM side-band to carrier is half of that = 0.084

g)  the PM to AM amplitude ratio as 0.084 / [4.0 x 10^(-4)]  = 209.

  5617   Tue Oct 4 19:06:46 2011 KojiUpdateIOOclosed the shutter before the MC

Finished the work at 6:30

MC REFL (INLOCK): 0.50-0.52
MC REFL (UNLOCK): 6.9
MC TRANS: 54400~547000


RFAM level

Before the work: -48.5dBm for 1.07VDC (both 50Ohm terminated)

Right after the work: -80dBm for 0.896VDC (both 50Ohm terminated)
10min after:   -70dBm
1hour after:   -65dBm
3hours after: -62dBm
1day after (Oct 5, 20:00):    -62.5dBm
2days after (Oct 6, 23:20): -72.5dBm
3 days after (Oct 7, 21:00): -57.8dBm

Quote:

The shutter before the MC was closed at 3:30 as I started working on the RFAM.

MC REFL (INLOCK): 0.6~0.7
MC REFL (UNLOCK): 6.9
MC TRANS: 50000~52000

 

  5618   Tue Oct 4 19:31:17 2011 kiwamuUpdateSUSPRM and BS oplev laser died

The He-Ne laser which has been used for the PRM and BS oplevs were found to be dead.

According to the trend data shown below, it became dead during the dolphin issue.

(During the dolphin issue the output from the oplev QPDs are digitally zero)

oplevs.png

  5619   Tue Oct 4 20:34:20 2011 KatrinUpdateGreen Locking7kHz Peak in servo input YARM

[Kiwamu, Katrin]

As reported earlier an oscillation around 7kHz is an the PDH error signal. The lower spectrum show that there is a peak from 6-7kHz.

This peak is somehow dependent on the modulation frequency. This means the peak can be shifted to a higher frequency when the modulation frequency is increased (see for comparsion f_mod=279kHz).

If the power supply for the green PD is switched of the peak vanishes. The same happens if the LO is switched of.

servoinput.png servoinput2.png

  5620   Wed Oct 5 11:33:25 2011 steveUpdateSUSPRM and BS oplev laser replaced

 

JDSU 1103P died after 4 years of service. It was replaced with new identical head of 2.9 mW output. The power supply was also changed.

The return spots of 0.04 mW  2.5 mm diameter on qpds are BS  3,700 counts and PRM 4,250 counts.

 

  5621   Wed Oct 5 14:18:09 2011 kiwamuUpdateCDSsome DAQ channel lost in c1sus : fb, c1sus and c1pem restarted

I found again the ini files had been refreshed.

I ran the activateDQ.py script (link to the script wiki page) and restarted the daqd process on fb.

The activateDQ.py script should be included into the recompile or rebuild scripts so that we don't have to run the script everytime by hands.

I am going to add this topic on the CDS todo list (wiki page).

Quote from #5561

Somehow some DAQ channels for C1SUS have disappeared from the DAQ channel list.

 

  5622   Wed Oct 5 17:08:49 2011 steveUpdateSUSBS oplev spectra

Kiwamu and Steve,

The He/Ne oplev shows no coherece so relative intensity noise is not limiting factor for the oplev servo

  5623   Wed Oct 5 18:31:02 2011 KatrinUpdateGreen LockingExchanged mirror on YARM table

On the Green YARM end table the second mirror behind the laser has been exchanged.

Reason: The light is impinging on the mirror under an angle of  about 10 degrees, but the old mirror was coated for angle of incidence (aoi) of 45°.

Thus it was more like a beam splitter. The new mirror is a 1" Goock & Housego mirror which has a better performance for an aoi of 10 degree.

Realignment through Faraday Isolator and SHG cristall as well as 532nm isolator is almost finished.

  5624   Thu Oct 6 05:18:20 2011 kiwamuUpdateLSCNoise in AS55 was from clipping : fixed

It turned out the noise in AS55 was due to a clipping.  After fixing the clipping the noise successfully went down.

I was going to briefly check the clipping and go ahead locking DRMI, but for some reason I couldn't stop myself from working on this issue.

Here is a plot of the noise spectra taken before and after fixing the clipping.

The configuration of this measurement is exactly the same as that I did before (#5595)

outofloop.png

(what I did)

 + Locked power-recycled ITMY so that the AS beam is bright enough to work with.

 + Shook BS at 1 Hz in the YAW direction

 + Looked around the AP table with an IR viewer and searched for a clipping moving at 1Hz.

 + Found the first lens in the AS beam path has clipped the beam at the upper side. A tiny portion of the beam was clipped.

 + Corrected the beam height to 4 inch by steering the very first mirror.

 + Raised the height of the lens because it was about 3.5 inch or so.

 + Found the lens had a scratch (~1 mm size ) at 1 cm blow the center on the surface.

   => I tried finding a spare 2 inch lens with a long focul length, but I couldn't find it,

        So I left the lens as it is, but we should buy some 2 inch lenses just in case like this.

 + Replaced the 1 inch beam splitter by 2-inch 99% BS so that most of the light goes into the RFPD and a little bit goes into the camera.

Quote from #5595

The AS55 signal contains more noise than the REFL signals.

  5625   Thu Oct 6 15:37:26 2011 JenneUpdateGreen LockingY-green Mech Shutter Button

[Katrin, Jenne]

We were poking around and tried to make a button for the Y-green shutter, just like the X-green already has.  I don't know where the X-green shutter button goes to in model-land, so I can't figure out if there is already a channel set up for the Y end.  Just switching the X for a Y didn't work.  Someone (maybe me) should fix this in the next soon.

  5626   Thu Oct 6 15:40:57 2011 JenneUpdateLSCArm absl length data taken

[Katrin, Jenne]

We took the data for the new absolute length measurement of both arms, after the latest vent and move.  We will analyze soonly.  We had done a round of analysis,  but then Koji pointed out that our data wasn't so clean because the whitening filters were on (and saturated the ADC).  We now have the data (but not the analysis) for the better data with the WF off.

So our dirty-data preliminary number for the X arm is 37.73meters, which is 14cm different from our old length.  We were supposed to move by ~20cm, so....either this measurement is bad because the data sucked (which it did), or we are 6cm off.  Or both.

I'll do another analysis with the clean data for both arms later today/tomorrow.

  5627   Fri Oct 7 04:42:24 2011 kiwamuUpdateLSCDRMI locked and some plans

DRMI has been locked using the same RFPD selection as the old days (i.e. AS55_I, AS55_Q and REFL_I).(#4760)

But remember : this is just a beginning of several measurements and tests to characterize the central part.

 

Here is a list of the measurements and actions :

  - 3f locking related

      + Listing up the necessary RFPDs and their installations.

      + Calibration of the SRM actuator  => this is necessary to convert the sensing matrix into unit of [counts/m] or [W/m].

      + Measurement of the sensing matrix => check the performance of 3f signals. Also diagonalization of the LSC sensing matrix

      + Diagonalization of the output matrix.

      + Noise characterization of 3f PDs => confirm the noise are low enough to keep the lock of the central part

 - Power-recycling gain issue related (#5541)

     + Estimation of the mode matching efficiency => maybe we can use power-recycled ITMs to estimate it (?)

     + Implementation of auto alignment servos and scripts for MICH, PRCL and SRCL. => integrate it to the existing ASS model

     + Search for a possible loss factor

  5628   Fri Oct 7 11:45:24 2011 KojiSummaryLSCPOY11 installed, 55MHz PD at POY removed

POY11 PD was installed last night. The lock of the Y arm was confirmed with the POY11I signal.

- The DC transimpedance was modified to be 1010V/A as the incident power is tiny.

- The demodulation phase of the roughly adjusted (148deg) to have PDH signal at the I-phase.
 
The comparison with AS55I signal exhibits that POY11I have ~150 times weaker signal with 45dB whitening.
 
(In total 25000 times weaker.)

On the way to make POY11 functioning, there were many fixes at the LSC rack...


Details:

- The PD interface cards (power supply for the RFPDs) were checked:
So far the two card at the right hand side were checked. 

Desipite the previous entry reported the issues on those boards, they did not show any problem yesterday.

One hypothetical possibility is the enabling switches that is controlled from the old slow epics targets.

- POY55 was removed

This 55MHz PD is supposed to be installed at POP.
The PD, an RF cable, an RF amp, the power supply of the RF amp were removed.

- POY11 was installed

The PD was placed where the 55MHz was placed.

The beam was aligned on the diode using the IR viewer and the digital multimeter.

The power supply cable and the RF cable for POY on the ITMY table were used.

There were an ND filter on the POY beam path. It was removed.


- On the LSC rack
The PD RF was connected to the patch panel at the top of the rack.

There were loose connectors on the patch panel. Some connectors were tightened on the panel.

I found that POY11 and POX11 had I&Q signal reversely connected to the whitening board.
   ==> These were fixed but
require the orthogonality test again for those channels.



The I phase output of the AS11 demod board had a broken connector. 

The onboard SMA has got disintegrated because of too much twist on the connector.
The board was once removed from the rack and the connector was fixed using a heat gun and soldering.

The DC signals were checked. POYDC was not correctly connected. POYDC were correctly connected to the POYDC channel.

- CDS
c1lsc was found with the RFM frozen.
The c1lsc machine was soft-rebooted after stopping all of the RT processes.

Once the RT processes came back, they were all burtrestored.

- PDH locking
Restored Y-arm. Locked it with AS55Q.
Ran ASS alignment for Y-arm.
100cnt 150Hz sinusoidal signal is applied to ETMY

Measured the PSD of AS55Q, POY11I, and POY11Q.
Adjusted the demod phase so that the excitation could be minimized in POY11Q.


  5629   Fri Oct 7 11:53:47 2011 KojiUpdateLSCDRMI locked and some plans

- REFL165 PD to be fixed (shows constant high voltage at the DC out)

- Make POP22/110 PD

- Install AS11? or use it as POX11?

- Install POP55

  5630   Fri Oct 7 14:04:48 2011 steveUpdateSUSHe/Ne intensity noise effect on oplevs

The SRM bounce peak 18.33 Hz. Suresh helped me to retune filter through Foton, but we failed to remove it.

ITMX_OPLEV_PERROR shows high coherence with oplev laser. This is our lousiest set up. I will work on it next week.

Generally speaking we can say that JDSU-Uniphase 1103P and 1125P laser intensity noise do not limit oplev servo performance.

However, the overall well being of filters, gain settings, beam sizes on qpds are poor.

 

  5631   Fri Oct 7 17:35:26 2011 KatrinUpdateGreen LockingPower on green YARM table

After all realignment is finished, here are the powers at several positions:

 

DSC_3496_power.JPG

  5632   Fri Oct 7 19:06:46 2011 SureshUpdateIOOMC spot positions: checked and corrected.

Koji and Kiwamu had adjusted the MC beam axis slightly such that we can couple the MC output into the Y-arm without exceeding the current range of adjustability on PZT1.  This changed the centering of beam spots on MC mirrors.  I checked the mc-decentering make sure we have not made too big a compromise.  And since we can move MC2 spot position while maintaining the current positions on MC1 and MC3 decentering, we can atleast eliminate the A2L coupling on that mirror.  I used the scripts in $scripts$/MC/moveMC2/ to adjust the MC2 spot position.

Spot positions in mm (MC1,2,3 pit MC1,2,3 yaw) before adjustment:
    1.4674   -0.3548    1.0199   -1.5519    1.9834   -1.5971

After correcting MC2:

    1.4528    0.1431    0.9958   -1.2147    0.3823   -2.0163

After correcting MC1:

    1.3745    0.0669    0.8899   -1.5269    0.0296   -1.7314

 

The spot positions on MC1 and MC3 are very nearly (+/- 0.06 mm) same as before, while the MC2  decentering has been reduced close to zero.

A slight adjustment of the PZTs may be required to reset the beam pointing.

  5633   Fri Oct 7 22:31:53 2011 kiwamuUpdateSUSnoisy ULSEN on ETMY

Yesterday Koji was claiming that the rms monitor of ULSEN on ETMY didn't well go down.

Indeed something bad is happening on ULSEN of ETMY.

I guess it could be a loose connection.

ETMY_OSEMs.png

(The unit of Y axis in the plot is not true. Don't believe it !)

  5634   Fri Oct 7 22:41:05 2011 KojiConfigurationGeneralScript backup fixed

Script backup regularly runs on op340m by crontab,
but the true backup were not taken since Oct 16, 2010
as the backup program was looking at the old script directory.
/cvs/cds/script/backupScripts.pl was modified to look at the new script directory.

OLD COMMAND:

$command = "cd /cvs/cds/caltech; /usr/sbin/tar cfX - $EXCLUDE_LIST scripts | bzip2 > $ARCHIVEDIR/scripts_$curdate.tar.bz2";

NEW COMMAND:

$command = "cd /opt/rtcds/caltech/c1; /usr/sbin/tar cfX - $EXCLUDE_LIST scripts | bzip2 > $ARCHIVEDIR/scripts_$curdate.tar.bz2";

  5635   Fri Oct 7 22:48:26 2011 SureshUpdateIOOMC2 Trans QPD spot size and incident power decreased

After centering the spot on the MC2, I started to adjust the spot position on MC_TRANS_QPD to center the beam on it.  I noticed that the spot size was about 3 to 4mm dia. because the 200mm lens was too close to the QPD.  I moved it back and decreased the spot size to about 1mm and the sensitivity to spot position increased.  However, Koji noted that the QPD sectors were near saturation, so I put in a ND=0.3 filter to reduce the incident power on the QPD.

At optimal alignment the current QPD_SUM is around 25k to 26k counts (factor of 2 down). Eventually the gain of the QPD ckts have to be reduced to prevent saturation, for the moment this is temporary fix.

The MC_TRANS_SUM trigger for MC autolocker is working fine no further change was required.

  5636   Fri Oct 7 23:23:05 2011 kiwamuUpdateSUSSRM oplev was oscillating

The SRM oplevs were found to be oscillating because of a small phase margin.

I reduced the gains to the half of them. The peak which Steve found today maybe due to this oscillation.

Quote from #5630

The SRM bounce peak 18.33 Hz. Suresh helped me to retune filter through Foton, but we failed to remove it. 

  5637   Sat Oct 8 00:44:42 2011 kiwamuUpdateLSCcalibration of SRM actuator

The AC response of the SRM actuator has been calibrated.

 actuators.png
(Summary of the calibration results)
     BS = 2.190e-08 / f2     [m/counts]
     ITMX  = 4.913e-09 / f2   [m/counts]
     ITMY  = 4.832e-09 / f2   [m/counts]
     PRM   = 2.022e-08 / f2  [m/counts]
     SRM   = 2.477e-08 / f2  [m/counts]    ( NEW ! ) 
 
(Measurement)
The same technique as I reported some times ago (#4721) were used.
The Signal-Recycled ITMY was locked for measuring the actuator response.
Since the ITMY actuator had been already calibrated, first the sensor was calibrated into [counts/m] by exciting the ITMY actuator and then calibrated the SRM actuator with swept sine measurement.
 
 - - notes to myself
   SRCL GAIN = 2.2
   Sensor = REFL11_I
   Demod. phase = 40 deg
   Resonant condition = Carrier resonant
   Gain in WF = 0 dB

Quote from #5583
The AC responses of the BS, ITMs and PRM actuators have been calibrated.

 

  5638   Sat Oct 8 04:41:07 2011 kiwamuUpdateLSClength fluctuations in SRCL

For a comparison, the length fluctuation of Signal-Recycled ITMX (SRX) and ITMY (SRY) have been measured.

Roughly speaking the length motion of SRX and SRY are as loud as that of PRCL.

Some details about the measurement and data analysis can be found in the past elog entry (#5582).

In the process of converting the raw spectra to the calibrated displacements the SRM actuator was assumed to have a resonance at 1Hz with Q = 5.

length_noise.png

(Notes on SRX/Y locking)

     Sensor = REFL11_I
     Actuator = SRM
     Demod. phase = 40 deg
     SRCL_GAIN = 20
     UGF = 100 - 200 Hz
     Resonant condition = Carrier resonance
     Whitening gain = 0 dB
     ASDC = 360 counts

Quote from #5582

The MICH and PRCL motions have been measured in some different configurations.

      + PRCL is always noisier than MICH.

ELOG V3.1.3-