40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 168 of 341  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  5877   Fri Nov 11 21:09:30 2011 SureshUpdateSUSMC2 is being a little wild...WFS to blame

Quote:

Mirko and  Den are measuring MC_F, which they will report about later, but I noticed that MC2 is totally crazy right now.  It shouldn't matter that they are doing things (like unplugging the feedback to the PSL's PZT), because we actuate on the laser, not on the MC.  I disabled the MC autolocker before they started working. 

Anyhow, somehow MC2 got kicked up (whatever, that happens), but it won't re-damp.  I think it's the WFS.  The yaw output from the WFS is truely crazy. 

I have disabled the WFS output / ASC input on the MC SUS screens, and MC2 was then able to damp.  My disabling only the MC2 WFS input at first kicked up MC1 and 3, so I disabled all of the WFS stuff, and all 3 MC mirrors are again happy. 

SURESH: FIX ME!  (signed, The WFS)

WFSscreenshot.png

 

The Problem

Turning off the WFS servo loops usually should be done using the 'mcwfsoff' script.  The script takes care of switching off the integrators and Clears the History.  

'mcdown' and 'mcup' scripts run the 'mcwfsoff' and 'mcwfson' scripts so when the MC unlocks the WFS servos are shutdown and restarted properly.  However if the MC autolocker script is suspended by pressing the Enable/Disable switch in the LOCKMC screen and then the MC unlocks, it results in the WFS servo integrators accumulating large values.  If these values are passed through the ASC filter banks the optic will get a pretty huge kick.

The Solution

I have added some indicators which will let us know if the WFS Servo Filter outputs are larger than +/-1000.  When engaging the WFS loops the user has to take care to Clear History in the servo filter banks if these indicators are steadily Red.   before engaging the WFS Servo loops ensure that the servo filter outputs are zeroes. 

Koji and I discussed whether it would be useful to run the 'mcwfsoff' script when the Disable button is pressed in the autolocker.  His recommendation is that we should keep  the autolocker script simple and that user has to be cautious when switching on the WFS servos and when directing the ASC outputs to the suspensions.

LOCKMC_screen.png

 

  5878   Fri Nov 11 22:07:43 2011 SureshUpdateIOOTried to recover the MC alignment of 4th Nov: partial success, PSL beam clipping

I have recovered the yaw values pretty much .  As the PZT1 rails in this direction perhaps this is the more relevant of the two alignments.  The beam is translated in the vertical direction, but this can be easily corrected by changing the pitch of MC2

However note that if the WFS are switched on .. MC is going to follow the PSL beam. 

 

 

 Date  #### MC1P MC2P MC3P MC1Y MC2Y MC3Y
03Nov2011   0.1354 -0.2522 -0.1383 -1.0893 0.7122 -1.5587
04Nov2011   4.0411 4.4994 3.5564 -1.4170 -0.2606 -1.7109
08Nov2011   4.7341 4.8794  4.3907 1.3542 -3.0508 -1.7167
10Nov2011    1   3.9944 3.7676 6.1001 -1.3058 -3.8087 -1.6418
11Nov2011    1  3.8542 3.6831 3.0418 -0.8383 0.1550 -2.3841
11Nov2011    2    3.6876 2.7429 2.7830 -1.6250 -0.0386 -1.6346

 

 

  5880   Sat Nov 12 02:27:00 2011 SureshUpdateComputersC1IOO front end suddenly froze. Was restarted remotely

[Koji Suresh]

No one was messing with the c1ioo or any other machine.   The medm screens for WFS and MC alignment froze while I was working on Rossa.

There were number of red lights pertaining to c1ioo machine on the CDS_FR_STATUS screen.  So we logged into c1ioo   from Rossa and restarted it with 'sudo shutdown -r now'.  It came back up but the C1IOO_MC_TRANS_SUM, P and Y signals were not available on the C1IOO LOCKMC screen.

I saw several messages similar to the one here


Sat Nov 12 02:09:14 PST 2011

  medmCAExceptionHandlerCb: Channel Access Exception:
  Channel Name: Unavailable
  Native Type: Unavailable
  Native Count: 0
  Access: Unavailable
  IOC: Unavailable
  Message: Virtual circuit disconnect
  Context: c1ioo.martian:43553
  Requested Type: TYPENOTCONN
  Requested Count: 0
  Source File: ../cac.cpp
  Line number: 1126

 

The MC autolocker script wasnt running.  The heartbeat bit was not blinking on the MC_LOCKMC screen.  So we manually restarted the script.  Hopefully it will return to normal operation.

I restarted the fb at Sat Nov 12 02:12:19 PST 2011  in an attempt to see this resolves the problem.

It didnt.

 

  5881   Sat Nov 12 02:44:18 2011 SureshUpdateComputersC1IOO front end suddenly froze. Was restarted remotely

Quote:

[Koji Suresh]

No one was messing with the c1ioo or any other machine.   The medm screens for WFS and MC alignment froze while I was working on Rossa.

There were number of red lights pertaining to c1ioo machine on the CDS_FR_STATUS screen.  So we logged into c1ioo   from Rossa and restarted it with 'sudo shutdown -r now'.  It came back up but the C1IOO_MC_TRANS_SUM, P and Y signals were not available on the C1IOO LOCKMC screen.

I saw several messages similar to the one here


Sat Nov 12 02:09:14 PST 2011

  medmCAExceptionHandlerCb: Channel Access Exception:
  Channel Name: Unavailable
  Native Type: Unavailable
  Native Count: 0
  Access: Unavailable
  IOC: Unavailable
  Message: Virtual circuit disconnect
  Context: c1ioo.martian:43553
  Requested Type: TYPENOTCONN
  Requested Count: 0
  Source File: ../cac.cpp
  Line number: 1126

 

The MC autolocker script wasnt running.  The heartbeat bit was not blinking on the MC_LOCKMC screen.  So we manually restarted the script.  Hopefully it will return to normal operation.

I restarted the fb at Sat Nov 12 02:12:19 PST 2011  in an attempt to see this resolves the problem.

It didnt.

 

 The problem was resolved after I burtrestored (c1mcs c1ioo and c1rfm) epics snapshots.

 

  5883   Sat Nov 12 03:46:55 2011 SureshUpdateIOOMC WFS Servo: Open loop gain

[Mirko, Suresh]

I closed the WFS loops and measured the transfer function from IN2 to IN1 testpoints on the WFS1_PIT filterbank. 

We looked at the filter shape consisting of

1) Integrator: zpk([0.8],[0],0.8,"n")

2) zpk([0.8],[100,100],1,"n")

3) zpk([1:10],[3,30],1,"n")

The combined filter shape (along with an added pendulum filter, zpk([ ],0.8,1,"n")  ) is given below

WFS1_PIT_servo_filtershape_20111111_1.png

 

The OL Transfer function measured for WFS1_PIT loop is

WFS1_PIT_servo_OLG_20111111_1.png

 The blue reference is a measurement  without the third "45 deg" filter in the list above.  Without it the UGF is around 1.5Hz and increasing the gain results in additional noise from the servo bump seen in the earlier elog .  With it the UGF is around 3Hz.

The supression of the error signal is shown here

 Error_signal_WFS1_PIT_20111111_1.png

The other WFS loops are expected to have a similar behaviour with the exception of the MC2 QPD channels.  I will measure their OLTF shortly and then proceed with the inclusion of the QPD sensors into the WFS system.

 

 

  5891   Tue Nov 15 00:00:15 2011 SureshUpdateIOOMC was realigned to remove beam clipping and to accommodate PZT1 range

[Kiwamu, Suresh]

The MC was realigned to readjust the input beam direction in pitch such that the clipping of the beam at the PSL table reduced and the railing of the PZT1 is avoided.

The current spot positions are given below on the last row:

 

 Date  #### MC1P MC2P MC3P MC1Y MC2Y MC3Y
03Nov2011   0.1354 -0.2522 -0.1383 -1.0893 0.7122 -1.5587
04Nov2011   4.0411 4.4994 3.5564 -1.4170 -0.2606 -1.7109
08Nov2011   4.7341 4.8794  4.3907 1.3542 -3.0508 -1.7167
10Nov2011    1   3.9944 3.7676 6.1001 -1.3058 -3.8087 -1.6418
11Nov2011    1  3.8542 3.6831 3.0418 -0.8383 0.1550 -2.3841
11Nov2011    2    3.6876 2.7429 2.7830 -1.6250 -0.0386 -1.6346
14Nov2011    1 5.9412 2.7658 5.4806 -4.7676 0.7778 2.2053

 

We have quite a lot of decentering in the MC which we must try to remove by parallel transporting the beam in Pitch and Yaw..

At the current settings we might be clipping on the Faraday Isolator as we had estimated that we can allow atmost a 2mm offset in spot positions due to this constraint.

 

 

 

  5892   Tue Nov 15 01:44:36 2011 SureshUpdateIOOMC WFS Servo: Open loop gain

Quote:

Somehow, I generically don't like the idea of lead filters for the WFS loops. We don't really need so much bandwidth. I think you should include with the servo measurements, a servo model ( on the same plot ) that matches the loop shape.

For example, this means including the 28 Hz ELP in the MC1/3 hardware and MC2 ASCPIT/YAW digital filter banks. BY comparing the model v. measurement we can determine if the cross-coupling due to imperfect output matrix is very serious or not.

In the measurements, the loop with the most low frequency gain looks the most promising.

WFS1_PIT servo replotted with foton data overlaid:

I included the following filters in foton:

1) Integrator: zpk([0.8],[0],0.8,"n")

2) zpk([0.8],[100,100],1,"n")

3) zpk([1:10],[3,30],1,"n")

4) ELP28

I have unwound the phase by adding or subtracting 180 to portions of the phase data.

And here is the plot for WFS1_PIT.  I will repeat this process for the other three WFS loops tomorrow.

WFS1PIT_OL_gain.png

 

  5899   Tue Nov 15 19:59:41 2011 SureshUpdateIOOWFS output matrix measured (open loop)

Quote:

Quote:

 The scripts used to make the WFS outmatrix measurement live in /cvs/cds/rtcds/caltech/c1/scripts/MC/WFS

 I assume you mean /opt/rtcds/caltech/c1/scripts/MC/WFS.

As I've tried to reitterate many times: we do not use /cvs/cds anymore.  Please put all new scripts into the proper location under /opt/rtcds.

 Yes the files are in /opt/rtcds/caltech/c1/scripts/MC/WFS.

I just went to wherever the 'scripts' alias takes me, found the 'pwd' and did a cp+paste of the path.   I checked to be sure that 'scripts' takes me to /opt/rtcds/caltech/c1/scripts/.

So why does the pwd show /cvs/cds.... instead of /opt/rtcds  ?

 

  5904   Wed Nov 16 08:57:08 2011 SureshUpdateIOOMC WFS Servo OLG data and fits

I measured the Transfer Functions between from IN2 to IN1 on the WFS1PIT, WFS2PIT, WFS1YAW and WFS2YAW servo loops. 

Then I used the foton filter profiles of the servo filters in the loop and added another one to simulate the pendulum to generate a reasonable fit to the data.  Only the pendulum filter was hand tweaked since the PIT and YAW pendula have different resonant frequencies.

The filter modules included are:

1) Integrator: zpk([0.8],[0],0.8,"n")

2) Phase lead: zpk([0.8],[100,100],1,"n")

3) 45 deg filter: zpk([1:10],[3,30],1,"n")

4) ELP28: ellip("LowPass",5,1,50,28)

5)Pendulum: zpk([ ],0.03+i*0.82;0.03+i*0.82;],1,"n"  (for YAW)

5)Pendulum: zpk([ ],0.05+i*0.68;0.05+i*0.68;],1,"n"  (for PIT)

The data and fits are below.   The UGF is around 2 to 3 Hz and there is no servo bump at this gain setting.  The fits are poor at and below the resonance because the coherence was poor at these frequencies.  I will have to do a swept sine measurement for these low frequencies.

WFS1PITservo.png  WFS2PITservo.pngWFS1YAWservo.png  WFS2YAWservo.png

  5905   Wed Nov 16 09:21:56 2011 SureshUpdateIOOMC2 Shifted in Pitch, corrected by adjusting the pitch bias

[Steve, Suresh]

    Steve went over to the MC2 walkway and stepped over the barrier to pick up some stuff there.  MC2 stack shifted and MC2 pitch as off.  MC unlocked and could not relock till the MC2 pitch bias was readjusted

previous MC2PIT reading: 3.6235           current MC2PIT reading:  3.9565

Without the WFS the MC to PSL alignment is poor, but it is largely due to a shift in the MC and not a shift in the PSL beam.  We know this 'coz the shift in the DC spot positions on WFS (when the MC is unlocked) is not significant nor is the shift on the C1:IOO-QPD.  When WFS loops are engaged the MC optics are turned to optimise the PSL to MC alignment, but the shift is large at the moment.

(Sorry Mirko your measurement could not be completed.  The MC unlocked in the middle)

Please Note:  If you need to access the blocked off area near MC2 stack, do not step over the barrier.  The disturbance is too great and the MC2 stack will shift.  Instead please move the barrier aside and walk as gently as possible near it, taking care not to touch the MC2 Chamber.

  5906   Wed Nov 16 10:08:17 2011 SureshUpdateIOOEffect of turning on the MC2_TRANS_PIT and YAW loops in ASC

I turned on the two remaining loops in the ASC system to see if we can lock.   I put in some ones into the WFS_OUTPUT matrix

WFS_OUTMATRIX.png

and locked the MC2_TRANS_PIT and MC2_TRANS_YAW loops.

The effect of doing so is visible in the error signals.  The black loops are with all ASC loops off, Blue traces are with the WFS1 and 2 loops locked and Red traces are with all loops locked.  I took the red traces to a lower frequency to see if the suppression of the error signals at low frequencies is disturbed by the switching on of the MC2_TRANS loops.  They seem to be working fine without adding any perturbation above the UGF.

WFS_servo_err_20111115.png

I measured the  Transfer Function coefs (at 10Hz using the WFS Lockins)  with MC2_TRANS loops locked in this rudimentary fashion

  WFS1P WFS2P MC2TP WFS1Y WFS2Y MC2TY
MC1P -23.8541 15.2501 -24.3470 -3.3166 -2.0473 -0.1202
MC2P 29.7402 54.7689 29.5102  -0.2922 -17.4226 0.0310
MC3P 34.3612 10.7279 33.9650 6.6582 -4.0892 0.2333
MC1Y 0.9510 -6.3929 0.8722 -98.2414 -82.9129 -4.2802
MC2Y 12.0673 6.1708 11.9502 237.1172 20.7970 14.6480
MC3Y -0.8498 2.8712 -1.4195 -20.6031 111.2531 -1.5234

 

The green and blue bits are the only relevant parts since we ignore the off diagonal parts.  And most of these off diagonal coefs are indeed quite small (<5% of the max).  I have marked the not-so-small ones in yellow.

I then calculated the output matrix elements in two different ways.

a) Using a null vector in the place of MC_DoF --> MC2_TRANS transfer coefs.  The output matrix we get is

 

  WFS1P WFS2P Null Vector
MC1P -1.0000 0.8271  -0.8880
MC2P 0.0962 1.0000  0.4431
MC3P 0.9306 -0.2913  -1.0000

 

  WFS1Y WFS2Y Null Vector
MC1Y -0.2340 -0.5840 1.0000
MC2Y 1.000o -0.1551  0.4714
MC3Y -0.3613 1.0000 0.6571

 

b) Without using the null vector.  i.e. using the MC_DoF --> MC2_TRANS transfer coefs and inverting the full matrix.  The output matrix we get is

 

   WFS1P WFS2P  MC2TP
 MC1P  0.1471  -0.8880  0.8655
 MC2P  1.0000  0.4431  -0.4369
 MC3P  -0.7634  -1.0000  1.0000

 

  WFS1Y WFS2Y MC2TP
MC1Y 0.1401 1.0000 -1.0000
MC2Y 0.1449 0.4714 -0.3627
MC3Y 1.0000 0.6571 -0.6775

 

I plan to try out these two output matrices and measure the OL TFs of the MC2_TRANS and see if we can include these into ASC in a useful fashion.

  5910   Wed Nov 16 10:53:35 2011 SureshUpdateIOOMC2 Shifted in Pitch, corrected by adjusting the pitch bias

Quote:

[Steve, Suresh]

    Steve went over to the MC2 walkway and stepped over the barrier to pick up some stuff there.  MC2 stack shifted and MC2 pitch as off.  MC unlocked and could not relock till the MC2 pitch bias was readjusted

previous MC2PIT reading: 3.6235           current MC2PIT reading:  3.9565

Without the WFS the MC to PSL alignment is poor, but it is largely due to a shift in the MC and not a shift in the PSL beam.  We know this 'coz the shift in the DC spot positions on WFS (when the MC is unlocked) is not significant nor is the shift on the C1:IOO-QPD.  When WFS loops are engaged the MC optics are turned to optimise the PSL to MC alignment, but the shift is large at the moment.

(Sorry Mirko your measurement could not be completed.  The MC unlocked in the middle)

Please Note:  If you need to access the blocked off area near MC2 stack, do not step over the barrier.  The disturbance is too great and the MC2 stack will shift.  Instead please move the barrier aside and walk as gently as possible near it, taking care not to touch the MC2 Chamber.

 

Apparently the MC2 stack had not finished shifting.   The MC unlocked while Steve was working on the PSL table installing the mirror for IOO_QPD and then it could not relock.  So I moved the MC2 once again in Pitch.  The current status of the sliders is here

C1IOO_MC_ALIGN.png

 

Yesterday I fixed the yellow buttons on the MC_ALIGN and MCLOCK screens.  They use the new updatesnap script  .  Could we also add a couple of lines to this script so that eveytime we save a snap shot the various values are written(appended) to a text file?  That way we do not need to depend solely on the conlog, which is quite slow.

 

  5925   Thu Nov 17 13:58:12 2011 SureshUpdateIOOMC unlocked and misaligned.

Quote:

Quote:

Actually, do we need to reset the filter history at every lock loss of the MC?

Those DC offsets were necessary to keep the alignment good just until the MC is unlocked.
So if we keep the history, we can maintain the good alignment.

 I suspect the integrators get fed a huge wrong signal on lockloss. Clearing the history on the trans DOFs when the MC was badly aligned gets it nicely aligned again. I switched off the alignment transmission DOFs for now.

I have modified the 'mcwfson' and 'mcwfsoff' scripts to include the Clear History step for the MC2_TRANS_PIT and _YAW filters.  

These scripts can be run, by hand, from LOCKMC screen or from the WFS_MASTER screen.  Use the 'Turn WFS ON/OFF' button. 

The mcautolockmain script will now clear history on all ASC filter banks when the MC unlocks.

I have turned on ASC loops on the MC2_TRANS (= alignment transmission DOFs of the above elog) paths.

 

 

  5938   Fri Nov 18 01:12:14 2011 SureshUpdateCDSMC1 LR dead for > 1 month; now revived temporarily

[Den, Mirko, Suresh]

    We were investigating why there is no correlation between MC1 osem signals and seismic motion.   During this we noticed a recurrence of this old problem of MC1_LR sensor being dead.  I went and pressed down the chip holders where the AA filters used to sit and which now hold the jumper wire.  The board is large and flexible it is quite likely some solder joint is broken on the MC1_LR path on this board.

   The signal came back to life and is okay now. But it can break off again any time.

 

 

Quote:

 Since the MC1 LRSEN channel is not wasn't working, my input matrix diagonalization hasn't worked today wasn't working. So I decided to fix it somehow.

I went to the rack and traced the signal: first at the LEMO monitor on the whitening card, secondly at the 4-pin LEMO cable which goes into the AA chassis.

The signal existed at the input to the AA chassis but not in the screen. So I pressed the jumper wire (used to be AA filter) down for the channel corresponding to the MC1 LRSEN channel.

It now has come back and looks like the other sensors. As you can see from this plot and Joe's entry from a couple weeks ago, this channel has been dead since May 17th.

The ELOG reveals that Kiwamu caught Steve doing some (un-elogged) fooling around there. Burnt Toast -> Steve.

bt.jpg

993190663   =      free swinging ringdown restarted again

 

  5943   Fri Nov 18 08:29:35 2011 SureshUpdateIOOHEPA air-flow effect on WFS.

[Koji, Suresh]

    We investigated the effect of airflow from the HEPA filters on the PSL beam fluctuation and the resultant noise injected into the WFS loops.   The hint that the WFS are injecting PSL beam jitter into MC mirror motion lies in the MC2_TRANS_PIT and YAW signal's power spectrum shown here.  First, in the blue trace, which shows the spectrum when the WFS loops are off, we see that the WFS1 and WFS2 error signals have a different shape from that of MC2_TRANS.  Since WFS are affected by the PSL beam jitter while the MC2_TRANS_QPD is not, the WFS spectrum contain excess noise, while the MC2_TRANS signals show only the mirror motion.  Next, upon switching on the WFS1 and WFS2 loops, we notice that the MC2_TRANS  spectra acquire the same shape as the WFS spectra.  This shows that the excess noise from the beam jitter has been injected into the MC2 motion, and shows up in the MC2_TRANS spectra.

   To confirm these conclusions we repeated the above measurement with the HEPA fans at 0% (Blue trace), 20% (Red), 30% (Brown) and  100% (Green).   The plots are shown below.  We can see that there is no difference between 0 and 20% levels but beam jitter is visible at 30% HEPA level.  The WFS loops were ON during this time and we can can see the PSL noise injected in to MC2 motion (Green).

WFS_err_HEPA.png

 

The HEPA filter fans are now at 20%.  How can we be sure that they are really working at 20%, since we cannot see any difference between 0 and 20%?

Now that we have this quiet situation, we also investigated the effect (or lack thereof) of switching on the MC2_TRANS loops.  The figure below shows the spectra with all the loops turned off (Blue), with the WFS1 and WFS2  loops turned on (Green)  and with everything turned on (Red).   With the current output matrix, which is the same simple one as the one in this elog, we see some low frequency suppression.  But it also seems to add some noise into the other WFS loops.  I am not sure of this result, due the long duration of this measurement, the seimic noise level may have changed over the course of this measurement.

WFS_err_mc2t_effect.png

As they are not doing any good just now.  I have turned them off by setting the gain in MC2_TRANS PIT and YAW to zero.

 

  5958   Sat Nov 19 06:04:43 2011 SureshUpdateIOOMC_WFS Servo: The MC2_TRANS_PIT and YAW loops switched ON

Without adding significant amounts of noise to other WFS loops I have engaged the MC2_TRANS_PIT and YAW loops. 

After several attempts to measure the system response and computing the output matrix, none of which gave any useful results, I gave up on that and decided to find three orthogonal actuation vectors which enable us to close the loops.  So using the last good output matrix (below left side)  as a template, I rounded it off to the nearest set of orthogonal vectors and arrived at the following matrix (right side):

WFS_OUTMx_Lastgood.png        WFS_OUTMATRIX_20111118.png

 

I also decided that WFS1 and 2 need not drive MC2.  This is just to decouple the loops and minimise cross-talk.   This (albeit heuristic)  matrix seems to work pretty well and the real matrix is probably quite close to it.

I show below the suppressed error signals after tweaking the gains a bit.   The blue line is with no WFS, the green one with only WFS1 and 2 loops on, while the red is with all loops turned on.  The WFS1Yaw and MC2_Trans_pit loops might benefit from a more careful study to determine a better output matrix.

WFS_err_MC2T_on_OMx5_20111118.png

  5989   Wed Nov 23 16:48:39 2011 SureshUpdateGeneralcable cleanup

[Koji Suresh]

As part of the general lab clean up we removed many unused BNC cables (long and short) from around the SP table.  We removed one very long BNC cable which was connected on one side to an PEM input and not connected on the other side near the 1X2 rack..   There were several cables from an old SURF phase camera project which were still attached to a couple of RF amps on the SP tables and running towards the 1X6 rack. 

We also removed some unused power cables  plugged into a power distribution strip near Megatron.

 

  5990   Wed Nov 23 16:55:57 2011 SureshUpdateIOOMC realigned

The PSL alignment into the MC was too poor for the autolocker to engage.  So retaining the last coil slider settings on the MC_Align screen that Kiwamu wanted, I have realigned the PSL beam and recentered the beam on the WFS.

When the WFS_MASTER was burtrestored after the recent power shutdown, the values loaded into the output matrix were not optimal.  When we switch on the WFS loops now, the MC_TRANS loops seem to push the WFS into away from the best possible coupling to PSL.  So I have switched them off for now.   Will load a new optimised output matrix and measure the transfer functions to see what is going on.

 

 

  6015   Sat Nov 26 07:18:11 2011 SureshUpdateIOOMC WFS related changes to c1ioo model

What I did:

    I have changed the c1ioo model such that the signals which are demodulated in the WFS lockin (the SIG inputs) are now picked up just after the input matrix.  This permits us to put a notch filter at the excitation frequency into the WFS servo filterbanks and thus prevent the excitation of all the actuators when we wish to excite just one of them. 

 

The Problem:

    I had followed the procedure of determining the TF coefs between actuators (MC1,2,3 P and Y ) and sensors (WFS1, 2 and MC2Trans P and Y)  and found the output matrix by inverting this TF coef matrix. However these matrices, once substituted for the heuristically determined matrices were always unsuccessful in keeping the WFS servo lock.  The reason appeared to be that when the loops are closed the exitation of one actuator led to the excitation of all actuators through the cross couplings in the output matrix.    In order to prevent this we need a notch filter in the servo filter banks.   But then we will not be able to see the sensor response after the servo filters since the response at 10Hz would be blocked from reaching the lockins.  So I shifted the point at which we sample the sensor response to a point before the WFS servo filters. 

The solution:

a) shift the point where the lockin input signals are picked up in the c1ioo model.

b) retune the lockin servo phases to minimise Q phase

c) edit the WFS lockin scripts to ensure that the 10Hz notch is turned on

d) measure the TF coefs and compute the -1*inverse

e) plug it into the output matrix and tweak the gains to ensure a stable lock

f) examine cross talk by comparing the expected TF in each loop with the expected loop TF.

 

Current state:

  I have completed steps a to e above.  The loops are stable and the error signal is suppressed (see attached pdf files)

To be done:

  The open loop transfer function has to be compared with expected OLTF to be sure we have minimised cross talk.

 

  6290   Thu Feb 16 21:13:07 2012 SureshUpdateElectronicsREFL165 repair: PD replaced, DC response checked with a torch light

[Koji, Suresh]

Kiwamu mentioned that REFL165 is not responding and its DC out seems saturated at 9V.  Koji and I checked to see if changing the power supply to the PD changed its behaviour. It did not.  

I then look a close look at the PD and found that the front window of the PD was not clear and transparent.  There was a liquid condensation inside the window, indicating an over heating of the PD at some point.  It could have arisen due to excessive incident power.  The pic below shows this condensation:

PC_30641_old.jpg

 

I also checked the current flowing through the reverse bias voltage line.  There was a voltage drop of 3V across R22 (DCC D980454-01-C)   indicating a 150mA of current through the PD.  This is way too much above the operating current of about 20mA.   The diode must have over heated.

I pulled out the old PD out and installed a new one from stock.  The pic below shows the clear window of a new PD.

PD_30641_new.jpg

After changing the PD I checked the DC output voltage while shining a torch light on to the PD.  It showed an output of about 30 to 40 mV.  This seemed okay because the larger 2mm photodiodes showed ~100mA DC output with the same torch.Below is the current state of the ckt board.

IMG_0548.JPG

 

I will tune the PD to 165 MHz tomorrow and measure its transimpedance.

  6333   Tue Feb 28 16:31:08 2012 SureshUpdateElectronicsREFL165 repair: Characterization

The transfer function and current noise were measured.  The location of the peak shifts with the amount of incident light power (RF or DC).  The TF was measured at an incident 1064nm light power of 0.4 mW which produced a DC output voltage of 14 mV => DC photocurrent of 0.28 mA. 

Many of the effects that Koji noted in the previous characterization are still present.

In addition I observed a shift of the peak towards lower frequencies as the RF power supplied to the AM Laser (Jenne Laser) is increased.  This could create a dependance of the demodulation phase on incident RF power.

The plots are attached below.

  6337   Wed Feb 29 00:22:35 2012 SureshUpdateElectronicsREFL165 repair: Installed on the AS table

1) The REFL165 has been replaced onto the AS table.

2) When the PD interface cable is attached the PD shows a DC out put of 6mV and does not respond to a flash light.  I changed the PD interface port in the LSC rack by swapping the other end of the cable with an unused (Unidentified PD) interface cable,  The PD is working fine after that.   There could be a problem with some binary switch state on the PD interface where the REFL165 cable was plugged in earlier.

 

  6339   Wed Feb 29 01:14:40 2012 SureshUpdateElectronicsREFL165 repair: Characterization

Quote:

The transfer function and current noise were measured.  The location of the peak shifts with the amount of incident light power (RF or DC).  The TF was measured at an incident 1064nm light power of 0.4 mW which produced a DC output voltage of 14 mV => DC photocurrent of 0.28 mA. 

Many of the effects that Koji noted in the previous characterization are still present.

In addition I observed a shift of the peak towards lower frequencies as the RF power supplied to the AM Laser (Jenne Laser) is increased.  This could create a dependance of the demodulation phase on incident RF power.

The plots are attached below.

 [Koji, Suresh]

To determine the amount of RF power in the AM laser beam at various RF drive levels I measured the RF power out of the Newfocus 1611 PD while driving the AM laser with a Marconi.  During this measurement the DC output was 2.2V.  With the DC transimpedance of 10^4 and a sensitivity of 0.8 A/W we have carrier power as 0.275 mW (-5.6 dBm).  [Incidentally the measured carrier power with a power meter is about 0.55 mW. Why this discrepancy?]

  1 2 3 4 5 6
Marconi Output (dBm) 0 -5 -10 -15 -20 -25
AG 4395 measurement (dBm) -8.1 -13.0 -18.0 -23 -28 -33
RF/DC ratio dB -2.5 -7.4 -12.4 -17.6 -22.6 -27.6

 

Estimation of the signal strength at the REFL165 PD:

   From the 40m Sensing Matrix for DRFPMI we see that the signal strength at REFL165 in CARM is about 5x10^4 W/m.  Since we expect about 0.1nm of linear range in CARM length we expect about 0.05 mW of RF power.  If the (DC) carrier power is about 10 mW at the photodiode (18mW is about the max we can have since the max power dissipation is 100 mW in the diode)  then the RF : DC power ratio is 5x10^-3 => -23 dB

As this is lower than the power levels at which the PD transfer function was determined and where we noted the distorsion and shift of the resonance peak, it is likely that these effects may not be seen during the normal operation of the interferometer.

The shift due to the carrier power level (DC) change may still however pose a problem through a changing demodulation phase. 

 

  6402   Mon Mar 12 22:14:56 2012 SureshUpdateRF SystemCalibration of Demod Board Efficiency.

I have completed the calibration of the demod board efficiencies.  Here is the schematic of the set-up.

 Calibration_Schematic.png

The data is given below and the data-file is attached in several different formats.

 Demod_calib.png

 

  6418   Wed Mar 14 16:39:02 2012 SureshUpdateGeneralREFL165 signal was not reaching demod board : Fixed

Quote:

The following tasks need to be done in the daytime tomorrow.

  • Hook up the DC output of the Y green BBPD on the PSL table to an ADC channel (Jamie / Steve)
  • Install fancy suspension matrices on PRM and ITMX [#6365] (Jenne)
  • Check if the REFL165 RFPD is healthy or not (Suresh / Koji)
    • According to a simulation the REFL165 demod signal should show similar amount of the signal to that of REFL33.
    • But right now it is showing super tiny signals [#6403]

 The REFL165 RF output was not reaching the Demod board.  The RF cable was disconnected.  I fixed that and then I put in a RF signal at 165MHz , 1.66 mVrms at the test input  (100Hz off set from the 165MHz LO) and saw that the 100 Hz demodulated signal was visible in the dataviewer. 

Test_CDS_Calibration.png

 

Will complete the Optical RF power -> CDS counts calibration tomorrow morning. 

  6423   Fri Mar 16 06:17:56 2012 SureshUpdateElectronicsREFL165 calibration : measurements

 

These are the measurements for estimating the amplitude of the signal recorded in the CDS when a known amount of modulated light is incident on the photodiode. 

I mounted the PD characterisation setup onto a small breadboard which could then be placed close AP table.  I then placed position markers for REFL165 on the AP table before moving it onto my small breadboard.  The AM laser was driven by an RF function generator (Fluke 6061A) at a frequency of 165.98866 MHz, which is 102 Hz offset from the 165MHz LO.  The power level was set at -45dBm.  This power level was chosen since anything higher would have saturated the AntiAliasing  Whitening Filters.  The counts in the CDS were converted to voltage using the ADC resolution = 20V per 2^16 counts.

  

  RF source RF power to AM laser 1611 PD 1611 PD REFL165 REFL165 CDS CDS
  power set (dBm) Actual power out (dBm) DC (V) RF out (dBm) DC (mV) RF out (dBm) Amplitude (V)   102 Hz Amplitude (V) 102 Hz
                 
1  -45  -50.6  -2.5 -58.9  10  -37.4  0.171 0.172
2  -48  -53.5  -2.5 -62.1  10  -40.3  0.122  0.121
3  -51  -56.5  -2.5 -65.0  10  -43.1  0.085  0.085

    

 When the 166MHz power is decreased by a factor of 2 the amplitude of 102Hz wave recorded in CDS goes down by sqrt(2) as expected.   The RF AM power incident on the REFL165 was estimated to be 0.011mW(rms)  (case #1 in the above table)  using the DC power ratio and using the transimpedance of the 1611 BBPD to be 700 Ohms.  This produces a 171 mV amplitude wave at 102 Hz.  I then stepped down the power by factor of 2 and repeated the measurement. 

(These numbers however are not agreeing with the power incident on REFL165 if we assume its transimpedance to be 12500.  It will take a bit more effort to make all the numbers agree.  Will try again tomorrow)

Here is a picture of the small black breadboard on which I have put together the PD characterisation setup.  It would be great if we can retain this portable set up as it is, since we keep reusing it every couple of weeks.  It would be convenient if we can fiber couple the path to the PD under test with a 2m long fiber.  Then we will not have to remove the PD from the optical table while testing it.

IMG_0552.JPG

 

  6428   Mon Mar 19 21:25:31 2012 SureshUpdateElectronicsREFL165 calibration : measurements

Quote:

 To characterize the RF V to counts we need to know the state of the whitening filter board. Was the filter on or off ? What was the value of the whitening gain slider?

 The filter was ON and the whiterning filter gain was 45dB

 

  6431   Tue Mar 20 17:50:44 2012 SureshUpdateComputersBeam Scan machine fixed

There was something wrong with the Beam Scan PC.  The  mouse and screen were not responding and the PC was asking for drivers for any new hardware that we plugged in.  We called in the services of Junaid and co. since we do not have a Win98 Second Edition installation disk in the lab.   Junaid came with the disk, we changed the screen and the mouse and installed everything. 

We tried to get the network going on the PC so that we could update stuff easily over the net.  This didnt succeed. For now, we still have to depend on a Win98se CD to get drivers if any new hardware is connected to this machine. 

For future reference, some notes:

1)  We will get a copy of Win98SE for the lab from Junaid

2) We have to use a USB mouse from Dell. We have several spares of this. The drivers for these are present in the machine. 

 

 

The Beam Scan is working okay now.  We will proceed with the beam profile measurements.  

  6441   Fri Mar 23 05:10:46 2012 SureshUpdateIOOBeam Profile measurements: Errors too large to yield good fits.

[Kiwamu, Suresh]

   Today we attempted to measure the beam profile of the REFL beam under two conditions:

              (a) with PRM aligned and ITMs misaligned 

              (b) with PRM misaligned and ITMs aligned

 

The raw data is shown below.  In each of the above conditions we measured in both the vertical (v) and horizontal (h) directions.   The measurements in the vertical direction were better than the ones in the horizontal direction because the optics had a horizontal oscillation which gave larger errors in measurement.

rawdataplot.png

 

Looking at the general trend of these lines it is clear that modes are not matched since the beam reflected by the PRM has a different divergence than that reflected from ITMs.  The beam is also astigmatic as the vertical and horizontal directions have different divergences.

I could find beam parameters only for the Blue line above (Profile in the vertical direction while PRM was aligned).   The fit is quite sensitive to the data points close to the waist, so we need to make better (lower St.Dev.) measurements near the AP table closer to the beam waist.  The intensity with only one ITM aligned is too low and also contributes to the errors.   The beam size is close to 6mm in the horizontal direction, this coupled with yaw oscillations give large errors in this measurement.

Here is the only reliable fit that could be obtained, which is for the prompt reflection from the PRM in the vertical direction

PRM-to-REFL-profile.pdf

The fit function I used is  Beam Dia = Waist { Sqrt [ 1+  ((z + z0)/zr)^2). The fit parameters we get for this data are

z0 = 7.7 m 

Waist = 2.4 mm

zr = 6.9 m

 

Will make another attempt later today...

 

 

 

 

  6447   Mon Mar 26 23:47:54 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam

[Keiko, Suresh]

   Keiko and I measured the IPPOS beam profile.  The fit parameters  are :

  Vertical Horizontal
Waist (mm) 2.77 2.48
Rayleigh length (m) 23.5m 15.87
Waist location (m) 0.81 m 1.85

BeamProfile_IPPOS.png

 

The data files are attached. 

  6448   Tue Mar 27 02:05:40 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam

Quote:

[Keiko, Suresh]

  Vertical Horizontal
Waist (mm) 2.77 2.48
Rayleigh length (m) 23.5m 15.87
Waist location (m) 0.81 m 1.85

BeamProfile_IPPOS.png

 

 

If we assume the nominal wavelength of the IR light to be 1064nm and constrain the Rayleigh length to be zr = (pi w0^2)/lambda we obtain the following fit parameters: (these are compared with the beam profile measurements of June/18/2010 available in the wiki )

  Vertical

Vertical 

06/18/2010

Horizontal

Horizontal

06/18/2010

waist (radius) (mm) 2.77 2.81 2.47 2.91
Rayleigh length (m) (computed) 22.62   18.14  
Waist location w.r.t. to MM2 * 3.37 5.36 4.15 1.96

* I updated the waist waist location coz because I missed-out the distance in air from the vacuum port to the optic on the IPPOS table.

 

BeamProfile_IPPOS.png

 

 

  6459   Tue Mar 27 23:37:35 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam

Quote:

Quote:

The moral of the story that I'm getting from this plot:  something funny is going on.

 Yup, something funny was going on.  Nic's MM code that I used, "a la mode", calls for the focal length of the optics, whereas the code that I wrote and used for ages called for the radius of curvature.  f = R/2.  Fixing that factor of 2 I get something more like:

.....

So, what does it all mean?  That I'm not sure of yet.

 In an attempt to estimate the errors on the fit parameters I upgraded my Mathematica code to use the function 'NonlinearModelFit', which allows us to define weights and also reports the errors on the fit parameters.   The plots have been upgraded to show the error bars and residuals.

Beam-Profile_IPPOS_wError.png

 

The parameters determined are given below and compared to the earlier measurements of 06/18/2010

Vertical Profile:

Parameter Estimate Standard Error 95% Confidence interval 06/18/2010 measurement
Waist (mm) 2.768 0.005 2.757 -- 2.779 2.81
Waist location from MMT2 (m) 5.85 0.12 5.625-- 6.093 5.36

 

 

Horizontal Profile:

Parameter Estimate Standard Error 95% Confidence Interval 06/18.2010 measurement
Waist (mm) 2.476 0.009 2.455 -- 2.496 2.91
Waist Location from MMT2 (m) 4.935 0.145 4.645 -- 5.225 1.96

 

There is a significant change in the beam waist location (as compared to previous report) because I corrected a mistake in the sign convention that I was using in measuring the distances to the waist from the zero-reference.
 

  6477   Mon Apr 2 23:06:38 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam: Mystery deepens

Quote:

I fitzed by hand with the numbers for the incident angles on MMT1 and MMT2, and then let the code optimize the position of MMT1 and MMT2.

Here I have set the incident angle for MMT1 = 25deg, and MMT2 = 12deg (should be 3.5deg, 1deg by design).  The length of the telescope doesn't want to change by more than 7mm, but the position of the telescope wants to change by 1.3meters.     Is it possible that the distances on the Monday IPPOS measurements aren't actually correct?

 

I am trying to track down possible errors in our measurements. 

So as a first step I am recomputing the IPPOS waist location with respect to the MC waist, using the same optical layout diagram as the one used by Jenne in her calculations.  Pic of Jenne's lab notebook showing location of optics is attached.  

IPPOS: measurement elog 6459: Vertical Std.Error Horizontal Std.Error
Waist  2.768 mm 5 microns 2.476 mm 10 microns
Waist location from MC waist  12.411 m  17 mm  9.572 m 54 mm

Std Dev of residuals from fit function

  37 microns   54 microns

 Let us compare it with the old measurement of the IPPOS beam from June/18/2010.

IPPOS: measurement June 18th 2010 Vertical Std.Error Horizontal Std.Error
Waist  2. 812mm 8 microns 2.909 mm 20 microns
Waist location from MC waist  9.265 m  224 mm  5.869 m 415 mm

Std Dev of residuals from fit function

  ~ 25 microns   ~25 microns

Note that there is a discrepancy of about 3.2 m in the waist location for the vertical profile and about 3.5 m for the horizontal profile between these two measurements. 

Let us compare these measurements with what is expected from calculations.  Jenne uses the known parameters of MC waist and the locations of the MMT optics to compute the parameters for the IPPOS beam:

IPPOS: Jenne's Calculations elog 6476:

Vertical Std.Error Horizontal Std.Error
Waist  2.844 mm   2.894 mm  
Waist location from MC waist  11.019 m   8.072 m  

 As the 2010 measurements are reported wrt to MMT2 and calculations are wrt MCwaist, I have used the distance between the MCwaist to MMT2 = 3.910 m to shift the reference from MMT2 to MC waist. Refer to the attached diagram from Jenne's notes for this MMT2 <--> MC waist distance.

There is a discrepancy of 1.5 meters between the calculations and recently measured waist location.  The discrepancy with the 18Jun2010 measurement is much larger, about 3 meters in both v and h.

Are such variations to be expected between two successive measurements?  I looked at another case where we have two measurements of a beam to see what to expect.

I looked at the REFL (Reflection from PRM) case, where we repeated a measurement, to see how much variation could happen in w0 and zr, between repeated measurements. This was a particularly bad case as our first attempt had problems due to OL servo loop oscillations in the PRM suspension damping.  We fixed that later and measurement 2 has smaller residuals. And I think we are doing okay in IPPOS case as seen by the reduced scatter of the residuals.

 These are the fits from the REFL beam measurement 1

REFL: Reflection from PRM: measurement 1 Vertical Error Horizontal Error
Waist 1.662 mm 4 microns 2.185 mm 4 microns
Waist location from MMT2 after reflection at PRM 1.781 m 17 mm 4.620 m 53 mm
Std.Dev. of residuals from fit function   61 microns   98 microns

 I have also recomputed the fits to the data from REFL beam measurement 2.  They match the earlier fits reported by kiwamu in his elog 6446

REFL: Reflection from PRM: measurement 2 Vertical Error Horizontal Error
Waist 1.511 mm 3 microns 2.128 mm 3 microns
Waist location from MMT2 after reflection at PRM 1.281 m 9 mm 3.211 m 37 mm
Std. Dev of residuals from fit function   58 microns   61 microns

 

Note that between these two measurements the beam waist location has shifted by 0.5 m for the vertical and about 1.3 m for the horizontal cases.  So variations of 1.5 m in the waist locations are possible if we are not careful.  But this is a particularly extreme example, I think we are doing better now and the measurement is unlikely to change significantly if we repeat it.

Some notes:

Fits for IPPOS and both REFL measurements 1 and 2 are attached. 

The zero reference for the z axis of the IPPOS beam plot is at a distance of 6.719 m from MC waist for a beam propagating towards the IPPOS QPD.

The zero reference for the z axis of the REFL beam plots is at a distance of 5.741 m from the MMT2 in the direction of a beam reflected by PRM and propagating towards the REFL port.

 

  6526   Thu Apr 12 01:17:56 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam: Possible Clipping

[Suresh, Jenne]

  The input beam is most probably being clipped at the Faraday Isolator.  

Evidence: 

a)  The beam scan of the IPPOS beam showed a nongaussian beam in the horizontal direction.  This was visible in the beam scan since it overlays a gaussian-fit over the data.

b)  I was able to remove this departure from gaussian profile by introducing an offset of 5 into the C1:IOO-WFS2_YAW_OFFSET.  

c)   We made a few measurements of the beam diameter as a function of distance at an offset of 7.  At a distance of beyond 3 m the deviation from gaussian profile was once again apparent. 

d)  We increased the offset to 14 to remove this deviation. 

e)  When we measured the beam diameter again with this new offset the horizontal diameter and vertical diameters dropped by 2.sigma.  Indicating there the beam was clipped till then.

f)   We increased the offset to 16 and the beam diameter did not change further (within 1.sigma). Implying no more clipping, hopefully. 

And then the earthquake stopped us from proceeding further. 

We plan to investigate this further to be sure..  Data attached.

 

Subsidiary effects to keep track of:

1) Introducing an offset into the WFS loops decreases the coupling from PSL into MC. 

2) If the beam is being clipped at the Faraday Isolator then the REFL beam would also show lesser clipping with WFS offsets.

  6528   Thu Apr 12 14:48:44 2012 SureshUpdateSUSlocal damping and WFS

    WFS servo is moving the MC mirror angles to minimise TEM01 and TEM10 modes within the MC cavity.    This means it will compensate not only for angular noise in the mirrors but also for the PSL beam pointing fluctuations.  So the extra "noise" we see when WFS loops are on is because they are active below the WFS UGF of about 2 Hz.  Also if the HEPA airflow is above 20% (of its max), the PSL beam jitter (caused by the airflow) will add broadband noise into the WFS servo loops and this will show up in the OSEM signals.  See elog 5943 for details.

 

 

Quote

    ......            

Then I compared MC1, MC2, MC3 suspos, suspit, susyaw and susside positions with WFS on (black curve) and off (red curve). WFS add noise to MC1 and MC3 measured by osems (MC2 is fine though). WFS should change osem readings but is it a correct way to do this below 0.5 Hz (?) It looks like just a flat noise. Need to think about the conclusion.

 

 wfsmc1.png                      

 

 

 

  6531   Thu Apr 12 23:12:16 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam: Possible Clipping

WiQuote:

[Suresh, Jenne]

  The input beam is most probably being clipped at the Faraday Isolator.  

Evidence: 

.....

We plan to investigate this further to be sure.. 

.....

 

I tried to determine an optimal WFS2YAW offset to be used so that we may avoid clipping.

Initially, I just measured the beam diameter as a function of offset.  If the beam diameter would become independent of offset if it is not clipped.  However a systematic effect became apparent when I shifted the beam on the detector to a slightly different location.  So I repeated the measurements while recentering the beam to the same location everytime  (centered at -1650+/- 50 for both H and V directions).

I have attached plots of the scans for both cases, with recentering and without.    I have not been able to figure out what is going on since the beam diameter does not become independent of the offset.  While the beam profile becomes more gaussian beyond offsets of about 7 or so, the beam diameter does not seem to follow a clear pattern.  The measurements are repeatable (within one sigma) so the experimental errors are smaller than 1 sigma.

The photographs below show the improvement of Horizontal beam profile with WFS2Yaw offset.  These seem to indicate a good gaussian beam for offsets beyond 7 or so.  At offsets more than 12 the MC unlocks.

 

Hor_OSet-2.png Hor_OSet0.png Hor_OSet2.png Hor_OSet8.png
 Offset = -2   Offset = 0   Offset = 2   Offset = 8

 

 

HorizontalNoRecenter.png  HorizontalRecentered.png
  This seems to indicate that the beam diameter does not vary for WFS2Yaw offset > 8  But if we recenter the beam for each measurement this effect seems to vanish

        

 Will continue tomorrow.   Jenne wants to do some IFO locking now.

 

  6534   Fri Apr 13 16:09:43 2012 SureshUpdateComputer Scripts / ProgramsACAD 2002 installed on C21530

I have installed ACAD 2002 on one of the Windows machines in the Control Room.    It is on the machine which has Solid Works (called C21530). 

The installation files are in MyDocuments under Acad2002.  This a shared LIGO license which Christian Cepada had with him.

I hope we will be able to open our optical layout diagrams with this and update them even though it is an old version.

 

 

  6535   Sat Apr 14 00:19:35 2012 SureshOmnistructureLSCOptical Fibers for insitu RFPD characterisation

   I have worked out the fibers we need to get for the following distribution scheme:

1) We have a laser placed at the 1Y1 rack.  A part of the power is split off for monitoring the laser output and sent to a broadband PD also placed in the same rack.  The RF excitation applied to the laser is split and sent to LSC rack (1Y2) and used to calibrate the full PD+Demod board system for each RFPD.

2) A single fiber goes from the laser to a 11+ way switch located in the OMC electronics cabinet next to the AP table.  From here the fibers branch out to three different tables.

Table / Rack   RF PDs on the table Number of PDs Fiber Length from OMC
The AP table AS11,AS55,AS165,REFL11,REFL33,REFL55,REFL165 7 6 m
The ITMY table POY11 1 12 m
The ITMX table POX11, POP22/110 and POP55 3 20 m

 

Cable for the laser source to the OMC table:

The 1Y1 Rack to OMC rack AM Laser Source to Switch 25 m

We also require a cable going from PSL table to the ETMY table:   This is not a part of the RFPD characterisation.  It is a part of the PSL to Y-end Aux laser lock  which is a part of the green locking scheme.  But it is  fiber we need and might as well order it now along with the rest.

PSL Table to ETMY Table PSL to ETMY Aux laser 75m

 

If you would like to add anything to this layout / scheme, please comment.  On Monday Eric is going to take a look at this and place orders for the fibers.

(I have included the lengths required for routing the fibers and added another 20% to that ) 

 

  6549   Thu Apr 19 09:45:43 2012 SureshUpdateGeneralMC2 Oplev signals redirected for use in WFS servo

Quote:

 
Quote:
  • there are no oplev signals in MC1, MC2, and MC3

 None of the 3 MC optics have oplevs, so there shouldn't be any oplev signals. Although MC2 has the trans QPD, which was once (still is??) going through the MC2 oplev signal path.

.......

 

The MC2 Oplev signal path has been modified in the c1mcs model.  The ADC channels have been sent over the rfm into c1ioo model and are currently used in the WFS servo loops.  Please see this elog 5397.

 

  6575   Thu Apr 26 18:17:56 2012 SureshUpdateIOOMC WFS: Tweaked the WFS offsets

[Jamie, Suresh]

Yesterday Den and Koji reported that the WFS loops were causing the MC to become unlocked.  They had aligned the PMC.   The input beam into the MC seems to be well aligned.  MCREFL DC close to minimum it gets while MC is locked (~0.45 V).

I checked and saw that the WFS heads and the MC2_TRANS_QPD had picked up DC offsets.  To reset them I turned off the MC_autolocker and closed the PSL shutter.

The ADC offsets were set using this script /cvs/cds/rtcds/caltech/c1/scripts/MC/WFS/WFS_QPD_offsets.  (Jamie fixed the paths to ezcaservo to get this script to work)

The WFS sensor head offsets were manually set to adjust the Q and I signals from the sensor head to zero.  (This operation is supposed to be done by a script which is available, but I will check it out before I direct people to it).

Then we noticed that the ASC outputs were turned off.  (Presumably Koji turned them off yesterday, when the MC was repeatedly unlocking due to the WFS loops).

We turned on the ASC outputs and the MC stayed locked with reasonable outputs on the WFS output channels.  (+/-100)

However, engaging the WFS servo increases the MCREFL DC signal to 0.7 V from the 0.45 V value when the servo is not engaged.  This could be because of DC offsets in the WFS servo filters.   I will adjust these offsets to maintain good MC transmission when the WFS servo is engaged.

 

 

 

  6582   Mon Apr 30 13:00:50 2012 SureshUpdateCDSFrame Builder is down

Frame builder is down.  PRM has tripped its watch dogs.  I have reset the watch dog on PRM and turned on the OPLEV. It has damped down.  Unable to check what happened since FB is not responding.

There was an minor earthquake yesterday morning which people could feel a few blocks away.  It could have caused the the PRM to unlock.

Jamie,Rolf,  is it okay or us to restart the FB?  

  6584   Mon Apr 30 16:56:05 2012 SureshUpdateCDSFrame Builder is down

Quote:

Quote:

Frame builder is down.  PRM has tripped its watch dogs.  I have reset the watch dog on PRM and turned on the OPLEV. It has damped down.  Unable to check what happened since FB is not responding.

There was an minor earthquake yesterday morning which people could feel a few blocks away.  It could have caused the the PRM to unlock.

Jamie,Rolf,  is it okay or us to restart the FB?  

 If it's down it's alway ok to restart it.  If it doesn't respond or immediately crashes again after restart then it might require some investigation, but it should always be ok to restart it.

I tried restarting the fb in two different ways.  Neither of them re-established the connection to dtt or epics.

1) I restarted the fb from the control room console with the 'shutdown' command.  No change.

2) I halted the machine with 'shutdown -h now' and restarted it with the hardware reset button on its front-panel. No change.

The console connected to the fb showed that the network file systems did not load.  Could this have resulted in failure to start several services since it could not find the files which are stored on the network file system?

The fb is otherwise healthy since I am able to ssh into it and browse the directory structure.

  6586   Mon Apr 30 20:43:33 2012 SureshUpdateCDSFrame Builder is down

Quote:

Quote:

Quote:

Frame builder is down.  PRM has tripped its watch dogs.  I have reset the watch dog on PRM and turned on the OPLEV. It has damped down.  Unable to check what happened since FB is not responding.

There was an minor earthquake yesterday morning which people could feel a few blocks away.  It could have caused the the PRM to unlock.

Jamie,Rolf,  is it okay or us to restart the FB?  

 If it's down it's alway ok to restart it.  If it doesn't respond or immediately crashes again after restart then it might require some investigation, but it should always be ok to restart it.

I tried restarting the fb in two different ways.  Neither of them re-established the connection to dtt or epics.

1) I restarted the fb from the control room console with the 'shutdown' command.  No change.

2) I halted the machine with 'shutdown -h now' and restarted it with the hardware reset button on its front-panel. No change.

The console connected to the fb showed that the network file systems did not load.  Could this have resulted in failure to start several services since it could not find the files which are stored on the network file system?

The fb is otherwise healthy since I am able to ssh into it and browse the directory structure.

[Mike, Rana]

The fb is okay.  Rana found that it works on Pianosa, but not on Allegra or Rossa.  It also works on Rosalba, on which Jamie recently installed Ubuntu.

The white fields on the medm  'Status' screen for fb are an unrelated problem.

 

 

  6668   Wed May 23 20:41:37 2012 SureshBureaucracyGeneral40m Meeting Action Items: Tip-tilts : cabling and electronics

Quote:
..........
  • Tip Tilts
    • Prepare electronics for TTs (coil drivers) - JAMIE
    • In-air TT testing to confirm we can control / move TTs before we vent - SURESH
    • Connect TTs to digital system and controls, lay cables if needed - JAMIE with SURESH
  • .....

 

 [Koji, Suresh]

  We tried to locate the sixteen analog output channels we need to control the four tip-tilts (four coils on each).  We have only 8 available channels on the C1SUS machine. 

  So we will have to plug-in a new DAC output card on one of the machines and it would be logical to do that on the C1IOO machine as the active tip-tilts are conceptually part of the IOO sub-system.   We have to procure this card if we do not already have it.  We have to make an interface between this card output and a front panel on the 1X2 rack.  We may have to move some of the sub-racks on the 1X2 rack to accommodate this front panel.

  We checked out the availability of cards (De-whitening, Anti-imaging, SOS coil drivers)  yesterday.  In summary: we have all the cards we need (and some spares too).  As the De-whitening and Anti-imaging cards each have 8 channels, we need only two of each to address the sixteen channels.  And we need four of the SOS coil drivers, one for each tip-tilt.  There are 9 slots available on the C1IOO satellite expansion chassis (1X1 rack), where these eight cards could be accommodated.

  There are two 25 pin feed-thoughs, where the PZT drive signals currently enter the BS chamber.  We will have to route the SOS coil driver outputs to these two feed-throughs. 

   Inside the BS chamber, there are cables which carry the PZT signals from the chamber wall to the the table top, where they are anchored to a post (L- bracket).  We need a 25-pin-to-25-pin cable (~2m length) to go from the post to the tip-tilt (one for each tip-tilt).  And then, of course, we need quadrapus cables (requested from Rich) which fit inside each tip-tilt to go to the BOSEMs.

   I am summarising it all here to give an overview of the work involved.

 

 

  6669   Wed May 23 21:32:15 2012 SureshUpdateIOOWFS didn't turn off automatically

Quote:

I just sat down in the control room, and discovered the PMC (and everything else) unlocked.  I relocked the PMC, but the MC wasn't coming back.  After a moment of looking around, I discovered that the WFS were on, and railing.  I ran the "turn WFS off" script, and the MC came back right away, and the WFS came on as they should.

We need to relook at the WFS script, or the MC down script, to make sure that any time the MC is unlocked, no matter why it unlocked, the WFS output is off and the filter histories are cleared.

    The only script that can currently take this action is the MC autolocker.  If that is disabled first and the PMC unlocks later, the WFS will not be turned off.  During the last round of discussions we had about the autolocker script, sometime last Nov, we decided that too much automation is not desirable and that the autolocker should be kept as simple as possible.

 

  6676   Thu May 24 15:10:43 2012 SureshSummaryGeneralIOO (MC) health check webpage layout

   Here is the suggested layout of the MC health check web page layout. I will update the Omnigraffle file as people comment and suggest changes.  If you want the file let me know.

 

MC_Health_Check.pdf

  6679   Thu May 24 19:39:18 2012 SureshUpdateIOOMC and WFS alignment adjusted

[Yuta, Suresh]

We found that the MC was not locking and that the alignment between PSL and MC was too poor to obtain a TEM00 mode in the MC.   To correct the situation we went through the following steps:

1) We burt restored the MC alignment slider values to their values at 3:07 AM of today

2) We turned off the MC-autolocker and the ASC signal to the coils.   Then aligned the PSL beam into the MC (with the MC servo loop off) to obtain the TEM00 mode.  We had to adjust the zig-zag at the PSL output by quite a bit to maximise MC transmission.

3) We then centered the spot on the MC2 face and centered the transmitted beam on the MC2_TRANS_QPD

4) Next, we centered the beams on the MC_WFS sensors.

5) Turning on the WFS loops after this showed that everything works fine and WFS loops do not accumulate large offsets.

 

 

  6688   Fri May 25 23:11:50 2012 SureshUpdateIOOMC spot positions measured

[Koji, Yuta, Suresh]

We measured the MC spot positions after re-aligning the MC.  The spot positions are listed below:

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
    3.9073    6.6754    2.8591   -7.6985   -0.9492    7.0423

 

Procedure:

1) In the directory /opt/rtcds/caltech/c1/scripts/ASS/MC  we have the following scripts

      a) mcassUp:    This sets up the MCASS lockins to excite each of the MC mirrors at a different frequency

      b) mcassOn:    This sets the MCASS output matrix to actually send the excitation signals to the mirrors

      c) senseMCdecenter:  This sequentially introduces a 10% offset into the coil gains of each mirror degree of freedom.   It also sends the lockin output data to the screen. 

      d) sensemcass.m :  This is a matlab file which digests the data gathered by the senseMCdecenter script to print a couple of plots and compute the spot positions.

      e) MCASS_StripTool.stp:  This is a set-up file for the StripTool which allows us to see the MCASS-lockin_outputs.  It is nice to see the action of senseMCdecenter  script  at work.

 

2) So the series of commands to use are

      a) ./StripTool  <-- MCASS_StripTool.stp

      b) ./mcassUp

      c) ./mcassOn

      d) ./senseMCdecenter | tee Output_file

       e) ./mcassOff

      f) ./mcassDown

       g) matlab <-- sensemcass.m  <---- Output_file

 

  6733   Thu May 31 17:47:25 2012 SureshOmnistructureGeneral40m Wireless Network

Mike Pedraza came by today to install a new wireless network router configured for the 40m lab network.  It has a 'secret' SSID i.e. not meant for public use outside the lab.  You can look up the password and network name on the rack.  Pictures below show the location of the labels.

40m_Wifi.png

  6756   Tue Jun 5 20:42:59 2012 SureshSummaryIOOTip-Tilt Cabling

I have made a preliminary sketch of the cabling involved in connecting the Tip-tilt coil drivers.   This is a preliminary document. 

40m_Tip-tilt_cabling.png

 

 

  Required parts Quantity Solution
1) DAC Card inserted into C1IOO machine 1 buy or borrow from Cymacs
2) SCSI cable from DAC to D080303 box 1 buy or find at the 40m
3) D080303 box (SCSI to IDC breakout box) 1 Jay may have had spare, if not we have to make one
4) 40 pin IDC cables from D080303 to AntiImaging filter 2 Jay may have kept some stock if not make them
5) 10 pin IDC cables from Anti Imaging filters to Whitening filters 2 make
6) sma to lemo cables from Whitening to coil drivers 4x4=16 buy
7) 15pin IDC to 25pin DSub cables from drivers to feedthroughs on the chambers 4  (length?) make
8) 25pin DSub feedthrough on OMC chamber 1 check in 40m stock else buy
9) 25pin DSub  Kapton strip cable from OMC wall to table top 1 check if any spare are available in aLIGO stock
10) 25pin DSub Kapton strip cable from post to tip-tilt 4 aLIGO team said they have a few to spare if not buy
10) Quadrapus cables on the tip-tilts 4 Jamie is negotiating with aLIGO cable team

 

ELOG V3.1.3-