40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 231 of 344  Not logged in ELOG logo
ID Date Author Type Category Subject
  5718   Fri Oct 21 02:57:38 2011 SureshSummarySUSMC2 Misaligned 2:27PM on Wednesday : cause traced

Quote:

Quote:

There looks some activity at around MC2 on Wednesday afternoon.
It caused the misalignment of MC2. Misalignment was not found in MC1/3.

It seems that the incident beam on the MC was aligned in the evening.
This increased the MC transmission but it is vibible that the spot on MC2 is shifted from the center.

We need an action on this issue tomorrow in the daytime.

 

I am working on fixing this.  You might some strange stuff going on in the control room screens.  Pls ignore it till I am done.

 

While chatting with Jenne I learnt that some substantial amount of work had taken place yesterday around the MC2 chamber.  This was associated with the relocating of seismometers.  ref elog

I reiterate what is well known for quite sometime:  MC2 table is not well isolated from the ground.  And we should not approach this chamber unless absolutely necessary. I have blocked off the area around it which we should avoid.  It is a serious waste of time and effort to realign the MC each time the MC2 table decides to settle into a new position.

Steve tells me that the mild-steel frame supporting the chamber+MC2_table sits with two legs on one concrete slab while the other two legs sit on another one.   The frame is also quite weak without sufficient gussets or cross connects.  The next time we have a major shutdown we must replace this frame with a more sturdy one which sits on one slab (preferably the one on which the rest of the MC sits).

Till we improve this mounting, I suggest that we avoid that area as much as possible.

 

  5717   Fri Oct 21 02:36:44 2011 SureshSummarySUSMC2 Misaligned 2:27PM on Wednesday : MC Realigned

Quote:

Quote:

There looks some activity at around MC2 on Wednesday afternoon.
It caused the misalignment of MC2. Misalignment was not found in MC1/3.

It seems that the incident beam on the MC was aligned in the evening.
This increased the MC transmission but it is vibible that the spot on MC2 is shifted from the center.

We need an action on this issue tomorrow in the daytime.

 

I am working on fixing this.  You might some strange stuff going on in the control room screens.  Pls ignore it till I am done.

 

 

  I have realigned the MC by recentering the spots on all the MC optics.  The current spot positions (in mm) are:

MC1P     MC2P     MC3P      MC1Y      MC2Y     MC3Y

0.2245    0.3364   -0.2801   -1.8891    0.1631   -1.744

Initially the lockins 2 and 5 showed very small outputs.  This was traced to the fact that we have recently switched on a 28Hz ELP filter module in the MC2 ASC filter bank which introduces an extra phase of about 75deg..  See this elog.

When the MC ASS lockins were initially setup, the phase was set with this filter module switched off.  Since quite some time has passed since the last calibration of these phases, I readjusted the phases to minimise the  Q_OUTPUT and I also adjusted the GAINs in the SIG filter banks  of all the six lockins so that their I_OUT's drop by the calibration value of -2.65 when an offset of 0.1 is introduced into the MC suspension output matrices.  Two short scripts in the $scripts$/ASS/ directory help in setting and removing these offsets.  They are called MCxoffsetOn and MCxoffsetOff.   They have to be edited appropriately to address each DoF of the MC.

The $scripts$/ASS/mcassUp script., which sets up everything to make the MC spot decentering measurement, has been edited to set these new phases and gains.  The old settings have been commented out.

I then centered the spots on the WFS sensors and the MC_TRANS QPD.  We are now ready to make the MC WFS output matrix transfer coef measurement again, but this time with the WFS loops closed.

 

  5716   Thu Oct 20 18:57:35 2011 SureshSummarySUSMC2 Misaligned 2:27PM on Wednesday

Quote:

There looks some activity at around MC2 on Wednesday afternoon.
It caused the misalignment of MC2. Misalignment was not found in MC1/3.

It seems that the incident beam on the MC was aligned in the evening.
This increased the MC transmission but it is vibible that the spot on MC2 is shifted from the center.

We need an action on this issue tomorrow in the daytime.

 

I am working on fixing this.  You might some strange stuff going on in the control room screens.  Pls ignore it till I am done.

 

  5715   Thu Oct 20 18:42:47 2011 KojiUpdateComputer Scripts / ProgramsWhere should the "Update Snapshots" of screens live?

The following directory exists. We can apply this convention to all of the models.

/cvs/cds/rtcds/caltech/c1/medm/c1lsc/snap

Quote:

While trying to implement the regular yellow shell script button in MEDM for my new OAF screen, I noticed that the update snapshot stuff in all of the buttons that I checked (including IFO Align and LSC Overview) are pointing to folders in the old /cvs/cds/caltech/ area.  Also, I think some of the folders that it's looking for don't exist anymore, even in the old system.  So.  Has anyone thought about where the snapshots should live in the new world order?  Previously they were in ...../medm/c1/subsystem/ .  Maybe we should make a snapshots folder in each subsystem's medm folder, at the same level as the 'master' folder for the custom screens?  This is my current proposal.

Unless someone objects / has a better plan / knows why they're still pointing to the old place, I'll do this in the morning, and work on changing all the buttons to point to the new place.

 

  5714   Thu Oct 20 18:01:17 2011 JenneUpdateComputer Scripts / ProgramsWhere should the "Update Snapshots" of screens live?

While trying to implement the regular yellow shell script button in MEDM for my new OAF screen, I noticed that the update snapshot stuff in all of the buttons that I checked (including IFO Align and LSC Overview) are pointing to folders in the old /cvs/cds/caltech/ area.  Also, I think some of the folders that it's looking for don't exist anymore, even in the old system.  So.  Has anyone thought about where the snapshots should live in the new world order?  Previously they were in ...../medm/c1/subsystem/ .  Maybe we should make a snapshots folder in each subsystem's medm folder, at the same level as the 'master' folder for the custom screens?  This is my current proposal.

Unless someone objects / has a better plan / knows why they're still pointing to the old place, I'll do this in the morning, and work on changing all the buttons to point to the new place.

  5713   Thu Oct 20 16:33:24 2011 KatrinUpdateGreen LockingTransfer function YARM PDH box

Yesterday, I measured the transfer function of the YARM PDH box.

SCRN0000.pdf

 

I tested the electronic board and couldn't find a frequency dependent behaviour. So I measured the TF again and it looked nice.

PDH_box.png

Today's nice measurement could is/was reproducible. I suppose yesterday's measurement is just an artefact.

The electronic board is modified according to Kiwamu's wiki entry http://blue.ligo-wa.caltech.edu:8000/40m/Electronics/PDH_Universal_Box

 

Btw. The light could be locked to the cavity for ~3min.

  5712   Thu Oct 20 12:43:19 2011 steveUpdateSAFETYrefilled first aid kits & their locations

First aid kits are located close vicinity of entry doors and under circuit breaker panels.

 

Attachment 1: P1080299.JPG
P1080299.JPG
Attachment 2: P1080306.JPG
P1080306.JPG
Attachment 3: P1080304.JPG
P1080304.JPG
Attachment 4: P1080305.JPG
P1080305.JPG
Attachment 5: P1080300.JPG
P1080300.JPG
Attachment 6: P1080301.JPG
P1080301.JPG
Attachment 7: P1080303.JPG
P1080303.JPG
Attachment 8: P1080307.JPG
P1080307.JPG
  5711   Thu Oct 20 11:59:21 2011 ZachUpdateComputer Scripts / Programsmodified "dataviewer" on nodus

The "dataviewer" script was still setting the server to fb40m on nodus. I modified it to fb, so that this is the default when you enter "dataviewer" or "dv".

  5710   Thu Oct 20 09:54:53 2011 jamieUpdateComputer Scripts / Programspynds working on pianosa again

Quote:

 

Doesn't work on pianosa either. Has someone changed the python environment?

pianosa:SUS_SUMMARY 0> ./setSensors.py 1000123215 600 0.1 0.25
Traceback (most recent call last):
  File "./setSensors.py", line 2, in <module>
    import nds
ImportError: No module named nds

 So I found that the NDS2 lib directory in (/ligo/apps/nds2/lib) was completely empty.  I reinstalled NDS2 and pynds, and they are now available again by default on pianosa (it should "just work", assuming you don't break your environment).

Why the NDS2 lib directory was completely empty is definitely a concern to me.  The contents of directories don't just disappear.  I can't imagine how this would happen other than someone doing it, either on purpose or accidentally.  If someone actually deleted the contents of this directory on purpose they need to speak up, explain why they did this, and come see me for a beating.

  5709   Thu Oct 20 04:47:37 2011 kiwamuUpdateLSCclipping search round 1

[Koji / Kiwamu]

  We tried finding a possible clipping in the vertex part.

We couldn't find an obvious location of a clipping but found that the recycling gain depended on the horizontal translation of the input beam.

We need more quantitative examination and should be able to find a sweet spot, where the recycling gain is maximized.

 

(what we did)

  + locked the carrier-resonant PRMI.

  + with IR viewers we looked at the inside of ITMX, ITMY and BS chambers to find an obvious clipping.

    => found two suspicious bright places and both were in the ITMY chamber.

      (1) POY pick off mirror : looked like a small portion of a beam was horizontally clipped by the mirror mount but not 100% sure whether if it is the main beam or a stray beam.

      (2) The top of an OSEM cable connectors tower : although this is in the way of the SRC path and nothing to do with PRC.

 + Made a hypothesis that the POY mirror is clipping the main beam.

 + To reject/prove the hypothesis we shifted the translation of the incident beam horizontally such that more beam hits on the suspicious mirror

 + Realigned and relocked PRMI.

    => Indeed the recycling gain went down from 6 to 0.8 or so. This number roughly corresponds to a loss of about 50%.

         However the MICH fringe still showed a very nice contrast (i.e. the dark fringe was still very dark).

         Therefore our conclusion is that the POY mirror is most likely innocent.

  5708   Thu Oct 20 01:40:33 2011 KojiSummarySUSMC2 Misaligned 2:27PM on Wednesday

There looks some activity at around MC2 on Wednesday afternoon.
It caused the misalignment of MC2. Misalignment was not found in MC1/3.

It seems that the incident beam on the MC was aligned in the evening.
This increased the MC transmission but it is vibible that the spot on MC2 is shifted from the center.

We need an action on this issue tomorrow in the daytime.

Attachment 1: MC2_misalign.png
MC2_misalign.png
  5707   Wed Oct 19 19:43:16 2011 JenneUpdatePSLPMC found unlocked

Quote:

I just relocked the PMC.  I don't know why it was unlocked.

 Again....

  5706   Wed Oct 19 18:18:03 2011 SureshUpdateElectronicsStochMon : Filters installed

Quote:

To get to the bottom of the RFAM mystery, we've got to resurrect the StochMon to trend the RFAM after the IMC.

We will put an 1811 on the MC_TRANS or IP_POS beam (the 1811 has an input noise of 2.5 pW/rHz).

Then the Stochmon has an input pre-amp, some crappy filters, and then Wenzel RMS->DC converters. We will replace the hand-made filters with the following ones from Mini-Circuits which happen to match our modulation frequencies perfectly:

11 MHz     SBP-10.7+

55 MHz     SBP-60+

29.5 MHz   SBP-30+

 

The Stochmon had a four-way splitter, four hand-made filters and four mini-circuits ZX47-60-S+ Power Detectors.

Using the filters from our stock I have replaced the hand-made filters with the ones mentioned in Rana's elog.   The power supply solders to the ZX47-60-S+ Power Detectors were weak and came off during reassembly. And some of the handmade short SMA cables broke off at the neck.  So I changed the power supply cables and replaced all the short SMA cables with elbows.  I also removed one of the Power Detectors since there were four in the box and we need only three now.

The power supply connector on the box is illegal.  The current lab standard for  {+15, 0 , -15}  uses that connector.  So we are going to change it as soon as possible.  We need to identify a good {0, 5} lab standard and stock them.

The following were removed from the box:

PA190146.JPG

 

The box now looks like this:

PA190143.JPG

 

Steps remaining in installation of Stochmon:

1) Install the Newfocus 1811 PD at the IPPOS by diverting some of the power in that path

2) Connect the outputs of the Stochmon to ADC inputs in 1X2 rack.

  5705   Wed Oct 19 18:16:53 2011 JenneUpdatePSLPMC found unlocked

I just relocked the PMC.  I don't know why it was unlocked.

  5704   Wed Oct 19 17:33:07 2011 kiwamuUpdateGreen LockingETMY mechanical shutter : fully functional

The mechanical shutter on the Y end is now fully functional.

 

 It is newly named to 'C1AUX_GREEN_Y_Shutter' in the EPICS world.

It uses the same binary output channel which had been served for the POY shutter.

To change the EPICS name I edited a db file called ShutterInterLock.db, which resides in /cvs/cds/caltech/target/c1aux.

After editing the file I rebooted the c1aux machine, by telnet and the reboot command in order to make the change effective.

Also I added this new shutter on the ALS overview screen (see the attachment below)

MechShutter.png

Quote from #5701

The ETMY  shutter can be remotely switched from medm screen POY of mechanical shutters.

The new cable from ETMY controller goes to east vertex EV-ISCT where it is connected to POY shutter hook up BNC cable.

  5703   Wed Oct 19 17:21:16 2011 KojiSummaryLSCModification on the RFPD interface cards

I have modified all of the three RFPD interface cards to be enabled permanently.
This prevents an accidental disabling caused by a stray voltage of the logic input (or whatever),
which was reported in multiple occasions by Anamaria and me.

The logic ICs (74LS04) for buffering of the EPICS switches were removed by 14pin sockets with additional wires soldered.
The modification shorts the inputs to the second logic chips, resulting in the permanent enabling of the PD circuit.

Attachment 1: D990543-B_mod.pdf
D990543-B_mod.pdf
  5702   Wed Oct 19 16:53:38 2011 kiwamuUpdateCDSsome screens need labels

Untitled.png

Some of the sub-suspension screens need labels to describe what those row and column are.

  5701   Wed Oct 19 16:28:35 2011 steveUpdateGreen LockingETMY mechanical shutter is working

Quote:

Uniblitz mechanical shutter installed in the green beam path at ETMY-ISCT  The remote control cable has not been connected.

The ETMY  shutter can be remotely switched from medm screen POY of mechanical shutters.

The new cable from ETMY controller goes to east vertex EV-ISCT where it is connected to POY shutter hook up BNC cable.

  5700   Wed Oct 19 15:48:20 2011 MirkoUpdatePEMMoved the STS1 from x-arm end to vortex

[Jenne, Mirko]

We moved our one STS1 from the x-arm end to the vortex. We record the data as STS1 in c1pem @ 256Hz. x is still north-south.

JD:  This is actually an STS-2.  We just call it C1:PEM-SEIS_STS1.... to differentiate the 3 STSs that we have from one another (assuming we plug in the other two).

19102011061.jpg

  5699   Wed Oct 19 15:46:49 2011 kiwamuUpdateSUStaking care of SRM

Quote from #5691

I am going to check the sensing matrix with the new free swinging spectra (#5690)

 

The SRM input matrix has been readjusted.

However still there is the unwanted coupling from the POS drive to SIDE signal and from the SIDE drive to POS signal.

      BADNESS
  SRM  SRM.png       pit     yaw     pos     side    butt
UL    0.871   0.975   1.115  -0.295   1.096  
UR    1.015  -1.025   1.128  -0.140  -1.053  
LR   -0.985  -0.984   0.885  -0.088   0.831  
LL   -1.129   1.016   0.872  -0.243  -1.020  
SD    0.084   0.061   3.534   1.000  -0.018  
 
 4.24965

 

  5698   Wed Oct 19 14:03:41 2011 kiwamuUpdateGeneralvent prep : dichroic mirrors

Status update on dichroic mirror:

 I got the specification sheet of an aLIGO 2" dichroic mirror from Lisa.

https://dcc.ligo.org/cgi-bin/private/DocDB/ShowDocument?docid=25232

This is the one from ATF. It has low loss, a high R for 1064 nm and high T for 532 nm. So it matches our needs.

Based on this sheet we may reset some of the parameters in the specification (e.g. incident angle and etc.,) and will get a quote from ATF.

We will buy 3 of them, including 1 spare. First I need to review the specification.

  5697   Wed Oct 19 13:45:11 2011 SureshUpdate40m UpgradingActive Tiptilts from LLO moved to clean shelf along X arm

I have moved the active tip tilts that we brought over from LLO to the Clean Bureau along the X arm (closest to the ETMX). There are two tip tilts and a pack of spare parts.  I am sure that the tip tilts are clean, packed in the clean room at LLO.  I am not sure whether the spares are clean.  I have kept them together for now.

We need to open one of the Tip tilt packages to be sure what we have got.

  5696   Wed Oct 19 12:25:58 2011 SureshUpdate40m UpgradingActive Tiptilts from LLO moved to clean shelf along X arm

I have moved the active tip tilts that we brought over from LLO to the Clean Bureau along the X arm (closest to the ETMX). There are two tip tilts and a pack of spare parts.

  5695   Wed Oct 19 12:06:26 2011 MirkoUpdateCDSIncluded the MC servo channel in CDS

[Jamie, Mirko]

Included the 'Servo' output from the D040180 in c1ioo, which I hoped would be a better measure of the MC length fluctuations. It goes into ADC6, labeled CH7 on the physical board.
Servo-output => C1:IOO-MC_SERVO. (Already present is Out1-output => C1:IOO-MC_F).
At low freq. the servo signal is about 4.5dB bigger. Both are recorded at 256Hz now which is the reason for the downward slope at about 100Hz.

MC_F_versus_MC_SERVO.png

Coh_MC_F_MC_SERVO.png

  5694   Wed Oct 19 10:49:35 2011 kiwamuUpdateSUSSRM oscillation removed

Quote:

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. 

 Kiwamu removed the 18.3 Hz ocsillation by turning down the oplev servo gain.

Attachment 1: SRMoplevKWMtune.png
SRMoplevKWMtune.png
  5693   Wed Oct 19 09:44:10 2011 steveUpdateSUSETMX oplev power spectrum

Quote:

 ETMX oplev had 6 mm diameter beam on the qpd.  I relayed the beam path with 2 lenses  to get back  3 mm beam on the qpd

BRC 037  -100 Bi _concave lens and PCX 25  200 VIS do the job. Unfortunately the concave lens has the AR 1064.

 

 

 Coherence at 1 and 2-3 Hz only. He/Ne laser intensity noise is not an issue.

Attachment 1: ETMXoplev2lens.png
ETMXoplev2lens.png
  5692   Wed Oct 19 08:34:16 2011 steveUpdateSUSSRM sus damping restored

Sorry Kiwamu, I realized too late that you were freeswigging. Hopefully 4 hrs was enough.

Attachment 1: SRM.png
SRM.png
  5691   Wed Oct 19 05:15:44 2011 kiwamuUpdateSUStaking care of SRM

I made some efforts to fix the situation of SRM but it is still bad.

The POS motion wasn't well damped. Something is wrong either (maybe both) sensing part or actuation part.

I am going to check the sensing matrix with the new free swinging spectra (#5690)

 

(Symptom)

 When I was trying to lock SRMI I found that the fringes observed at the AS camera didn't show spatial higher order modes, which is good.

So I thought the SRM suspension became quiet, but it actually wasn't. Because the RMS monitor of the SRM OSEMs already went to about 30 counts.

At the same time the opelev error signals were well suppressed. It means some DOFs which were insensitive to the oplev were ringing up, namely POS and SIDE.

According to the LSC error signal and the ASDC signal, I believe that the POS was going wild (although I didn't check the OSEM spectra).
 

(Some efforts)

 + Readjusted the f2a filters (see the attachment).

 + Tried to eliminate a coupling between the POS and SIDE drives by tweaking the output matrix.

    => In order to eliminate the coupling from the POS drive to SIDE sensor, I had to put a comparable factor into an element.

     So it might be possible that the POS sensor was showing the SIDE signal and vice versa.

      In order to check it I left SRM free swinging (#5690).

Quote from #5684

The main reason why I couldn't lock DRMI was that the suspensions were touchy and especially the SRM suspension wasn't good.

Attachment 1: f2pSRM.png
f2pSRM.png
  5690   Wed Oct 19 04:23:58 2011 kiwamuUpdateSUSSRM free swinging test

The following optics were kicked:
SRM
Wed Oct 19 04:22:53 PDT 2011
1003058589
 

  5689   Tue Oct 18 22:47:09 2011 SureshConfigurationIOOMC autolocker script edited to shutdown and restart WFS loops

Quote:

I found that the MC WFS had large offset control signals going to the MC SUS. Even though the input switch was off, the integrators were holding the offset.

I have disabled the ASCPIT outputs in the MC SUS. Suresh is going to fix the MC autolocker script to gracefully handle the OFF and ON and then test the script before resuming the WFS testing.

MCL data for OAF may be suspect from this morning.

 I have edited (uncommented existing commands)  the following scripts to enable WFS locking to come on when the MC is locked.

1) $scripts$/MC/autolockMCmain40m*

2) $scripts$/MC/mcup

3) $scripts$/MC/mcdown

4) $scripts$/MC/WFS/mcwfson

5) $scripts$/MC/WFS/mcwfsoff.

I have checked that the autolocker script switches off the mcwfs when mc loses lock and then switches it on after re-obtaining lock.

 

  5688   Tue Oct 18 21:19:18 2011 ranaConfigurationIOOWFS disabled in SUS

I found that the MC WFS had large offset control signals going to the MC SUS. Even though the input switch was off, the integrators were holding the offset.

I have disabled the ASCPIT outputs in the MC SUS. Suresh is going to fix the MC autolocker script to gracefully handle the OFF and ON and then test the script before resuming the WFS testing.

MCL data for OAF may be suspect from this morning.

  5687   Tue Oct 18 20:50:19 2011 SureshUpdateIOOC1IOO and WFS associated screens

In keeping with the current protocol,  I have started to move all the user-built medm screens associated with C1IOO into the $screens$/c1ioo/master/ directory. 

I then edited the menu button in the sitemap.adl to point to the screens in the ..c1ioo/master/ directory.  All the screens in $screens$/c1ioo/ directory have been backed up into bak/.  I plan to edit the c1ioo model soon and at that time I will delete all the screens in the $screens$/c1ioo directory and let only the automatically regenerated screens  stay there.   If there are broken links to user-built screens associated with c1ioo, please copy the relevant screen to the master/ directory and edit the path in the menus.

 

  5686   Tue Oct 18 15:20:03 2011 kiwamuSummaryIOORFAM plan

[Suresh / Koji / Rana / Kiwamu]

Last night we had a discussion about what we do for the RFAM issue. Here is the plan.

 

(PLAN)

  1. Build and install an RFAM monitor (a.k.a StochMon ) with a combination of a power splitter, band-pass-filters and Wenzel RMS detectors.

       => Some ordering has started (#5682). The Wenzel RMS detectors are already in hands.

  2. Install a temperature sensor on the EOM. And if possible install it with a new EOM resonant box.

      => make a wheatstone bridge circuit, whose voltage is modulated with a local oscillator at 100 Hz or so.

  3. Install a broadband RFPD to monitor the RFAMs and connect it to the StochMon network.

      => Koji's broadband PD or a commercial RFPD (e.g. Newfocus 1811 or similar)

  4. Measure the response of the amount of the RFAM versus the temperature of the EO crystal.

      => to see whether if stabilizing the temperature stabilizes the RFAM or not.

  5.  Measure the long-term behavior of the RFAM.

      => to estimate the worst amount of the RFAM and the time scale of its variation

  6. Decide which physical quantity we will stabilize, the temperature or the amount of the RFAM.

  7. Implement a digital servo to stabilize the RFAMs by feeding signals back to a heater

     => we need to install a heater on the EOM.

  8. In parallel to those actions, figure out how much offsets each LSC error signal will have due to the current amount of the RFAMs.

    => Optickle simulations.

  9. Set some criteria on the allowed amount of the RFAMs

    => With some given offsets in the LSC error signal, we investigate what kind of (bad) effects we will have.

  5685   Tue Oct 18 10:04:41 2011 KojiUpdateLSCREFL165 removed from the table

The original REFL165 had ~50MHz/A dependence on the DC photocurrent.
The resistr R21, which was 2670 Ohm contrary to the original drawing, was replaced to 532 Ohm
to increase the feedforward gain by factor of 5.

The resulting dependence is reduced to ~0.5MHz/A although it has Q reduction of ~20% at 6mA.

Some concerns:

These transfer functions were measured between TEST IN and RF OUT while the diode was illuminated with the white light from a light bulb.

There looks some thermal effect on the resonant freq. If the white light illumination is suddenly removed, the bias compensation
is immediately removed but the resonance takes some time (~min) to come back to the original freq.

I am afraid that the light bulb gave too much heat on the surrounding PCB and lead unnecesarily high level dependence of the resonant freq on the DC current.

Or, if this thermal effect comes from the power consumption on the diode itself, we need to characterize it for aLIGO.

In order to check this, we need a test with the 1064nm illumination on the diode in stead of the light bulb.

Attachment 1: REFL165_original.pdf
REFL165_original.pdf
Attachment 2: REFL165_new.pdf
REFL165_new.pdf
Attachment 3: REFL165_schematic_111017_KA.pdf
REFL165_schematic_111017_KA.pdf
  5684   Tue Oct 18 04:04:27 2011 kiwamuUpdateLSCmeasurement of sensing matrix : touchy SRM

I made some attempts to measure the sensing matrix of the central part.

I could measure the matrix in the PRMI configuration but wasn't able to measure the matrix in the DRMI configuration.

   => I will report the result of the PRMI sensing matrix tomorrow.

The main reason why I couldn't lock DRMI was that the suspensions were touchy and especially the SRM suspension wasn't good.

Some impacts due to the feedback during the lock acquisition completely kicks SRM away. 

The watchdogs' RMS monitor on SRM easily rang up to more than 10 counts once the acquisition started.This is quite bad.

Also the stability of the PRMI lock was strongly depending on the gains of the PRM oplevs.

I guess I have to revisit the vertex suspensions more carefully (i.e. f2a coupling, actuator output matrix, damping gains, input matrices, oplev filters)

otherwise any LSC works in the vertex will be totally in vain.

  5683   Mon Oct 17 23:56:34 2011 SureshUpdateIOOMC WFS Integrators switched on and WFS_MASTER screen updated

[Rana, Suresh]

     To see if the loops will stay locked when the Integrators in the servo are switched on, we stayed with the same simple output matrix (just 1 or -1 elements) and switched on the FM1 on all WFS servo filter banks.  We monitored the time domain error signals to see if engaging the locks made the error signals go to zero.  Most of the error signals did go to zero even when an intentional offset was introduced into the MC pitch of the suspension.

      We need to include TestPoints just before the Input Servo Matrix so that we can monitor the error signals without being affected by the gain changes in the WFS_GAIN slider.   These are currently not present in the C1IOO model and the position of the WFS_GAIN also has to be shifted to the other side of the Input matrix.

      The C1IOO_WFS_MASTER screen has been changed to the new one.  This incorporates filter banks for the MC_TRANS_P and _Y channels.  The screen is not yet fully functional but I am working on it and I it will continue to improve it.

WFS_MASTER_screenshot_20111017.png

  5682   Mon Oct 17 23:28:32 2011 ranaUpdateElectronicsStochMon

To get to the bottom of the RFAM mystery, we've got to resurrect the StochMon to trend the RFAM after the IMC.

We will put an 1811 on the MC_TRANS or IP_POS beam (the 1811 has an input noise of 2.5 pW/rHz).

Then the Stochmon has an input pre-amp, some crappy filters, and then Wenzel RMS->DC converters. We will replace the hand-made filters with the following ones from Mini-Circuits which happen to match our modulation frequencies perfectly:

11 MHz     SBP-10.7+

55 MHz     SBP-60+

29.5 MHz   SBP-30+

  5681   Mon Oct 17 22:20:42 2011 KojiUpdateLSCREFL165 removed from the table

Quote:

REFL165 removed from the table for the C(V) test

The PD was returned on the table.

The C(V) compensation path was modified and the change of the resonant freq was cancelled.
A more precise analysis comes later.

  5680   Mon Oct 17 17:07:30 2011 steveUpdateSUSETMX oplev returning beam od 3 mm

 ETMX oplev had 6 mm diameter beam on the qpd.  I relayed the beam path with 2 lenses  to get back  3 mm beam on the qpd

BRC 037  -100 Bi _concave lens and PCX 25  200 VIS do the job. Unfortunately the concave lens has the AR 1064.

 

 

Attachment 1: ETMX-oplev.jpg
ETMX-oplev.jpg
  5679   Mon Oct 17 14:26:22 2011 MirkoUpdateCDSSeismic BLRMS channels, new RMS calculation

Quote:

[Rana, Koji, Mirko]

We looked into the CDS RMS block c-code as described in Rolfs RCG app guide. Seems the block uses a first order LP filter with a corner freq. / time of 20k execution cycles. There are also some weird thersholds at +-2000counts in there.

I was looking into implementing a hand-made RMS block, by squaring, filtering, rooting. The new RMS (left) seems nicer than the old one (bottom right). Signal was 141counts sinus at 4Hz.

Filters used: Before squaring: 4th order butterworth BP at given freq. & (new) 6th order inverse Chebyshew 20dB at 0.9*lower BP freq. and 1.1*upper BP freq. => about 1dB at BP freq.

                       After squaring: 4th order butterworth LP @ 1Hz.

C1PEM execution time increased from about 20us to about 45us.

Made a new medm screen with the respective filters in place of the empty C1PEM_OVERVIEW. Should go onto the sitemap.

New_RMS_vs_old_RMS.png

Original RMS LP is slower than 0.1Hz, see below for single LP at 0.1Hz in the new RMS. Original RMS is faster than single LP @ 0.01Hz

Original_RMS_LP_slower_than_0.1Hz.png

Some of the channels are recorded as 256Hz DAQ channels now. Need to figure out how to record these as 16Hz EPICS channls.

 Channels are now going into EPICS channels (e.g. C1:PEM-ACC1_RMS_1_3 ). Adapted the PEM_SLOW.ini file. Channels don't yet show up in dataviewer. Probably due to other C1PEM maschine

  5678   Mon Oct 17 11:40:44 2011 KojiUpdateLSCREFL165 removed from the table

REFL165 removed from the table for the C(V) test

  5677   Mon Oct 17 11:06:31 2011 MirkoUpdateCDSPiping data from c1lsc to c1oaf

Changed, recompiled, installed and restarted c1rfm and c1oaf to get the MC1-3 Pitch and Yaw data into the c1oaf model.
Also changed c1oaf to use MCL as a witness channel (as well as an actuator).
Added the changes to svn.

  5676   Mon Oct 17 10:43:14 2011 MirkoUpdateCDSCommited changes to c1rfm

I want to make changes to c1rfm. Found uncommited changes to it from Sept 27. Since we recompiled it since then it should be safe to commit them, so I did. See svn log for details.

  5675   Mon Oct 17 07:57:24 2011 steveUpdateSUSETMX sus damping restored
  5674   Sun Oct 16 05:35:18 2011 ranaUpdateComputer Scripts / ProgramsFailing to set SUS summary screen values

Quote:

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.

 Doesn't work on pianosa either. Has someone changed the python environment?

pianosa:SUS_SUMMARY 0> ./setSensors.py 1000123215 600 0.1 0.25
Traceback (most recent call last):
  File "./setSensors.py", line 2, in <module>
    import nds
ImportError: No module named nds

  5673   Sun Oct 16 02:30:00 2011 ranaUpdateElectronicsTesting REFL165

Unless the bias feedback circuit has been tuned for the 1 mm diode, its possible that you are seeing some C(V) effects. Its easy to check by looking at the phase response at 165 MHz v. the DC photocurrent. Then the feedback or feedforward gain can be tuned.

 

  5672   Sat Oct 15 17:06:20 2011 KojiUpdateLSCInstallation REFL165

REFL165 was installed on the AP table last night.

Meanwhile I found the DC power level at the REFL PDs were 0.8~1.2V if the PRM is aligned and the IFO is not locked.
This corresponds to 16~24mA (20~30mW). This is too big.

The HWP of the REFL path were adjusted so that we have 6~10mA (8~12mW) on each PDs.

  5671   Sat Oct 15 16:42:08 2011 KojiUpdateLSCTesting REFL165

Test results of new REFL165 (the first attachment)

- The resonant freq 166.2MHz, Q=57 (previous Q was ~7)

- If we believe the TF measurement, the transimpedance at the resonance is 7.8k [V/A] and the shotnoise intercept current of ~1mA.
The linearity of the peak was confirmed by changing the modulation level of the beam.

- There is a riddle: the white light test indicates 4.5k [V/A] and 2.8mA for those numbers.
There are big descrepancies from those by the TF measurements.


Further analysis of the descrepancies:

Using the noise measurements with different DC current levels, the transimpedance for each frequency can be reconstructed.

Does this indicate the satiration by the white light???

- The TF measurement shows consistent mag&phase relationship at the resonance (c.f. LISO fit).
So this steep resonance is not an artifact by a noise or glitch but the real structure of the electronics.

- The TF measurement has been done with the photocurrent of ~0.3mA, while the transimpedance measurement
with the white light illumination has the practical effect only when the DC photocurrent is larger than 1mA
because of the circuit noise. Does this higher photo current affected the resonance?

- The off-resonant transimpedance agree with the TF measurement as far as we can see with those measurements.
This may mean that the actual resonant structure has been affected in the white light measurement.
(i.e. not the saturation of the RF opamp which causes the change of the gain at any freq.)
Is the above mentioned higher DC current causing the change of the diode capacitance or other property of the diode or the inductors???

Attachment 1: REFL165_test_111014_KA.pdf
REFL165_test_111014_KA.pdf REFL165_test_111014_KA.pdf REFL165_test_111014_KA.pdf REFL165_test_111014_KA.pdf
Attachment 2: REFL165_transimpedance2.pdf
REFL165_transimpedance2.pdf
  5670   Sat Oct 15 16:01:26 2011 kiwamuUpdateIOOabout LOCKIN module

Quote from #5669

To make things faster, I think we can just make a LOCKIN which has 3 inputs: it would have one oscillator, but 6 mixers. Should be simple to make.

 I think the idea of having multiple inputs in a LOCKIN module is also good for the LSC sensing matrix measurement.

Because right now I am measuring the responses of multiple sensors one by one while exciting a particular DOF by one oscillator.

Moreover in the LSC case the number of sensors, which we have to measure, is enormous (e.g. REFL11I/Q, REFL33I/Q, REFL55I/Q, ... POY11I/Q,...) and indeed it has been a long-time measurement.

  5669   Sat Oct 15 10:58:32 2011 ranaUpdateIOOMC WFS Output Matrix determination

In order to save time and sanity, you should not measure the pitch ->yaw and yaw-> pitch. It makes things too complicated and so far is just not significant. In the past we do not use these for the matrix work.

i.e. there should just be a 3x3 pitch matrix and a 3x3 yaw matrix. Once the loops are working we could investigate these things, but its really a very fine tweak at the end. There are quite a few other, more significant effects to handle before then.

To make things faster, I think we can just make a LOCKIN which has 3 inputs: it would have one oscillator, but 6 mixers. Should be simple to make.

ELOG V3.1.3-