40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 43 of 341  Not logged in ELOG logo
ID Date Author Type Categorydown Subject
  7869   Fri Dec 21 16:50:30 2012 RanaUpdateSUSTT in vac DB25 pin swapping

[Koji, Rana, Nic, Steve]

We went to the 25-pin D cable which connects to the TT1 quadropus and succeeded eventually in swapping pins 12/24 into the 13/25 positions.

  1. The D-sub connector is a custom made LIGO part and so it doesn't at all work to use the standard pin extractor tools to move the pins out; we should have investigated this before spending all this time poking at and possibly damaging the existing connector.
  2. To move the pins, we have to partially dis-assemble the connector and fish the pins/wires through the appropriate holes. Unfortunately, the design is such that we nearly lose all of the pins when trying to do this. Pictures describe the story better than words.
  3. After the swap we tried to test the TT, but again wasted some time because the vac feedthrough was incorrectly labeled. The 25-pin feedthrough labeled as "PZT1" does not, in fact, connect to the TT. Instead, its the one slightly above it that is labeled "Pico". I have moved the PZT1 sticker up to match the actual connector. In order to discover this, we beeped through several stages of the coil driver, cable system. WE need to order some in-line D-sub breakouts for 25pin, 37pin, and 9pin which are similar to the ones we have now for 15pin. These are better than the green terminal block breakouts.
  4. After this, we were able to see the TT move, but elected to leave the final piece of the work (determining which microD goes with which coil) to when Jamie gets back.
  5. The TT screen is not good: it needs to be just like the usual sus screen so that we can put in offsets, excitations, etc. Perhaps also the ASC-TT screen can link to the TT:SUS screens. We can just copy the eLIGO TT screens to get going.
  7871   Wed Jan 2 06:52:50 2013 KojiUpdateSUSTT in vac DB25 pin swapping

[Koji, Rana, Nic, Steve]

I recalled that we used an optical lever to check if the TT is moving or not.
We used a laser pointer on a tripod, which was prepared by Steve.

I should also note that we stepped back the eddy current dampers from the magnets
in order to enhance the motion of the suspension. They should be restored in the end.

The mini-D connectors on the OSEMs are loosened so that we can plug the cables in.
This requires a specific metric allen key
that is stored in a clean tool box with an aluminum foil.

  7884   Tue Jan 8 18:10:41 2013 JenneUpdateSUSPRM, SRM, BS oplevs off

I don't know why (I'm just leaving the lab right now....) but BS, PRM, SRM all have no light on their oplev PDs. I have turned off the oplev servos for now, and will get back to them tomorrow, before redoing the BS table oplev layout.

  7900   Tue Jan 15 01:41:40 2013 ranaUpdateSUSTT

 That seems like easily enough range; as long as we can put the TT into the middle of their range to start with we should be OK.

We should consider instrumenting the leakage transmission through all TT with a bare QPD on a stick. We can then use those sensors to monitor the spot positions within the input mirrors as well as the PRC / SRC.

  7903   Wed Jan 16 08:29:45 2013 SteveUpdateSUSPRM damping restored

PRM oplev servo turned off.  OLPIT servo gain 0.15 and OLYAW  -0.3 set to ZERO.  PRM damping restored

  7937   Thu Jan 24 11:31:45 2013 SteveUpdateSUSETMX damping restored

ETMX sus damping restored.  It is still noisy

  7938   Thu Jan 24 11:40:55 2013 JenneUpdateSUSETMX damping restored


ETMX sus damping restored.  It is still noisy

 I should have elogged, but I turned off the watchdog to remind myself that iscex computer is still crashed.  "Turning on" the damping doesn't do anything since there aren't any signals going to the coils from the computer.

  8093   Sat Feb 16 17:27:26 2013 yutaUpdateSUSPRM coil balanced

PRM coil gains and f2a filters are adjusted for PRMI work.
It seems like UR/LL coil gains were ~10 % larger than others, and f2a filters changed by few %.

What I did:
  1. Tried to lock PRMI but when I turn on PRCL lock, PRM reflection looked like it tends to go up and left in REFL camera (last night).

  2. So, I set up PRM oplev back, by steering PRM oplev mirrors on the BS table (last night).

  3. Turned PRM oplev sero on, f2a filters off, and ran

> /opt/rtcds/caltech/c1/scripts/SUS/F2P_LOCKIN.py -o PRM

  I had to fix F2P_LOCKIN.py because it assumed some OUTPUT buttons in LOCKIN1 filters to be ON.
  Also, I had to restore filters in LOCKIN1 (8.5 Hz bandpass filter etc.) because their names were changed. To do this, I copied filters needed from /opt/rtcds/caltech/c1/chans/filter_archive/c1sus/C1SUS_110916_162512.txt, renamed LOCKIN1_(I|Q|SIG) with LOCKIN1_DEMOD_(I|Q|SIG), and pasted to the current filter bank file. I checked that they look OK with foton after editing the file.

  This measurement takes about 30 minutes. I ran several times to check consistency. There was ~ 0.1 % standard deviation for the measurement results.

  4. By putting measured coupling coefficients and PRM pendulum frequency (f0=0.993 Hz) to /opt/rtcds/caltech/c1/scripts/SUS/F2Pcalc.py, I got new f2a filters.

  5. Overwrote f2a filters in C1:SUS-PRM_TO_COIL_(1-4)_1 FM1 with new ones, and turned  new f2a filters on.

  Below is the DC gain adjustment result from F2P_LOCKIN.py;

multiplier factors are :
UL = 1.141525
UR = 0.879997
LR = 1.117484
LL = 0.860995
Set C1:SUS-PRM_ULCOIL_GAIN to 1.04990177238
Set C1:SUS-PRM_URCOIL_GAIN to -0.983396190716
Set C1:SUS-PRM_LRCOIL_GAIN to 0.954304254663
Set C1:SUS-PRM_LLCOIL_GAIN to -0.971356852259

  So, UR/LL coil gains somehow got ~10 % larger than other two since last coil balancing.

  Measured coupling coefficients from F2P_LOCKIN.py were

- measured coupling coefficients are :
P2P(POS=>PIT) = 0.014993
P2Y(POS=>YAW) = 0.001363

  New f2a filters are plotted below. They look fairly different compared with previous ones.


We need better F2P_LOCKIN.py:
  Some one should make F2P_LOCKIN.py better. The main problem is the sudden gain change when starting diagonalization at low frequency. It sometimes trips off the watchdog.

Some elogs related:
  Kiwamu made f2a filters in Sep 2011: elog #5417
  Koji adjusting DC gains in Jan 2013: elog #7969

  8096   Sun Feb 17 19:27:19 2013 ranaUpdateSUSPRM coil balanced

 I will check out the AS55 situation tomorrow. Just put it on my desk.

MC Autolocker was disabled - I enabled it.

For the F2P.py, you should look at how we did this with the script written 8 years ago in csh. There we stored the initial values in a file (so they don't get blow away if someone does CTRL-C). Your python script should have a trap for SIGINT so that it dies gracefully by restoring the initial values. In order to have the smooth value adjustment, you must first set the TRAMP field for all the coil gains to 2 and then switch. Make sure that the lockin ignores the first few seconds of data after making this switch or else it will be hugely biased by this transient.

For the PRM OL use as a F2A reference, you also have to take into account that the OL beam is hitting the PRM surface at non-normal incidence. IF it is a large angle, there will be a systematic error in the setting of the F2Y values.

  8152   Sun Feb 24 00:14:28 2013 ManasaUpdateSUSSUS Summary

I tried to fix the alarms for sensors on the SUS summary screen. I checked earlier elogs and found the setSensors.py script.

I received errors while running the script and pianosa was refused connection to nds. Yuta suspects problems with the lib directory.

Jamie! Can you fix this?

  8154   Sun Feb 24 17:54:34 2013 ranaUpdateSUSSUS Summary


 I asked John Z to talk with Jamie and then install a new NDS2 server software for us. Jamie may know if this happened or was foiled by the linux1 RAID failure.

In any case, our pyNDS stuff ought to be able to talk to NDS2 or our old NDS1 stuff, I hope.

  8159   Mon Feb 25 20:04:22 2013 JamieUpdateSUSsuspension controller model modifications in prep for global damping initiative

[Jamie, Brett, Jenne]

We made some small modifications to the sus_single_control suspension controller library part to get in/out the signals that Brett needs for his "global damping" work.  We brought out the POS signal before the SUSPOS DOF filter, and we added a new GLOBPOS input to accommodate the global damping control signals.  We added a new EPIC input to control a switch between local and global damping.  It's all best seen from this detail from the model:


The POSOUT goto goes to an additional output.  As you can see I did a bunch of cleanup to the spaghetti in this part of the model as well.

As the part has a new input and output now we had to modify c1sus, c1scx, c1scy, and c1mcs models as well.  I did a bunch of cleanup in those models as well.  The models have all been compiled and installed, but a restart is still needed.  I'll do this first thing tomorrow morning.

All changes were committed to the userapps SVN, like they should always be.

We still need to update the SUS MEDM screens to display these new signals, and add switches for the local/global switch.  I'll do this tomorrow.

During the cleanup I found multiple broken links to the sus_single_control library part.  This is not good.  I assume that most of them were accidental, but we need to be careful when modifying things.  If we break those links we could think we're updating controller models when in fact we're not.

The one exception I found was that the MC2 controller link was clearly broken on purpose, as the MC2 controller has additional stuff added to it ("STATE_ESTIMATE"):


I can find no elog that mentions the words "STATE" and "ESTIMATE".  This is obviously very problematic.  I'm assuming Den made these modifications, and I found this report: 7497, which mentions something about "state estimation" and MC2.  I can't find any other record of these changes, or that the MC2 controller was broken from the library.  This is complete mickey mouse bullshit.  Shame shame shame.  Don't ever make changes like this and not log it.

I'm going to let this sit for a day, but tomorrow I'm going to remove replace the MC2 controller with a proper link to the sus_single_control library part.  This work was never logged so it didn't happen as far as I'm concerned.


  8160   Mon Feb 25 20:25:33 2013 BrettUpdateSUSNew Global Damping MEDM Screens

Global damping screens are in progress for the new global damping infrastructure Jamie discussed in log #8159. The main overview screen is /opt/rtcds/caltech/c1/medm/c1sus/master/C1SUS_GLOBAL.adl. The overview screen links to a few sub-screens in the same directory called C1SUS_GLOBAL_DAMPFILTERS.adl, C1SUS_GLOBAL_GLOBALTOLOCAL.adl, and C1SUS_GLOBAL_LOCALTOGLOBAL.adl.

This global damping is in intended to damp the 4 test masses along global interferometer degrees of freedom that are orthogonal to the cavity signals. Ideally the result will be that OSEM sensor noise from the damping loops is invisible to the cavity signals. Mismatches in the suspensions' dynamics and gains will cause some noise to leak through anyway, but we should be able to tune some of this out by carefully scaling the drives to each suspension.

  8161   Mon Feb 25 20:49:07 2013 BrettUpdateSUSMinor Mod made to SUS_GLOBAL block

 I made a minor modification to install some output filters in the new global damping GLOBAL box in c1sus.mdl. These will be needed for tuning the suspension drives to compensate for mismatches in the pendulums.

I recompiled and installed the model, but did not start it. Basically same as Jamie left it in 8159. Interestingly, I did not see the new POSOUT that was put in before the SUSPOS DOF filter. I made sure to reopen the .mdl file fresh before making more mods, but for some reason I do not see that update...

  8168   Tue Feb 26 10:17:44 2013 JamieUpdateSUSremoved global/local switch from sus_single_control

[jamie, brett]

Yesterday we added some new control logic to the sus_single_control part to allow for global damping.  Today we decided that a binary switch between local/global damping was probably a bit extreme since we might want to smoothly ramp between them, instead of just hard switching.  So we removed this switch and are now just summing the control inputs from global and local damping right before the output matrix.

Changes were committed to the SVN, and all suspension models were recompiled/installed/restarted.


  8169   Tue Feb 26 10:20:31 2013 JamieUpdateSUSMC2 suspension controller reverted to library part

I made good on my threat from yesterday to convert the MC2 suspension controller to the library part.  Whatever changes were in MC2 were thrown out, although they are archived in the SVN.  Again, this kind of undocumented breaking is forbidden.

Change was committed to SVN, and c1mcs was recompiled/installed/restarted.

  8172   Tue Feb 26 16:13:18 2013 BrettUpdateSUSITMY and ETMY mysterious loop gain difference of 2.5

While doing initial measurements for the new global damping infrastructure I discovered that the ETMY loop between the OSEM actuation and the OSEM sensors has a gain that is 2.5 times greater than the ITMY.  The result is that to get the same damping on both, the damping gain on the ETMY must be 2.5 times less than the ITMY. I do not know where this is coming from, but I could not find any obvious differences between the MEDM matrices and gains.

I uploaded a screenshot of measured transfer functions of the damped ITMY and ETMY sus's. Notice that the ETMY measurement is 2.5 times higher than the ITMY. The peak also has a lower Q, despite having the same damping filters running because of this mysterious gain difference. Lowering the damping gain of the ETMY loop by this 2.5 factor results in similar Q's.

Attachment 1: Screenshot.png
  8174   Tue Feb 26 17:56:15 2013 BrettUpdateSUSGlobal Damping Update

The global damping input and output matrices were installed to run for the Y-arm. Since we are using just one arm for now, only the DARM and CARM DOFs were entered into the matrices.

The input matrix was set to have elements with magnitudes of 0.5 while the output matrix was set to have elements with magnitudes of 1. The input matrix gets the 0.5 because the sensor signals must be avergaed for each global DOF, to make an 'equivalent sensor' with the same gain. The output matrix gets magnitudes of 1 so that the overall gain of the global loops is the same as the local loops. A transfer function was measured on the CARM loop to check that the overall gain is in fact the same as the measured ITMY and ETMY loops.

Simple damping filters were installed for the ITMY and ETMY as well as the global y arm CARM and DARM loops.

The ETMY output tuning filter ETMY_GLOBPOS was set to have a gain of 0.4 because there is an extra gain of 2.5 relative to ITMY in some mysterious place as discussed in log 8172.

  8182   Wed Feb 27 11:59:43 2013 yutaUpdateSUSPRM/BS coil re-balanced

I re-adjusted coil gains and f2a filters for PRM and BS.
I'm not sure what happened to PRM since I balanced on Feb 16(elog #8093).
Let's see if it helps PRMI locking or not.

========== PRM ==========

- Original DC coil gains

C1:SUS-PRM_ULCOIL_GAIN 1.049901772380000e+00
C1:SUS-PRM_URCOIL_GAIN -9.833961907160000e-01
C1:SUS-PRM_LRCOIL_GAIN 9.543042546630000e-01
C1:SUS-PRM_LLCOIL_GAIN -9.713568522590000e-01

- New DC coil gains

multiplier factors are :
UL = 0.928167
UR = 1.061448
LR = 0.941659
LL = 1.068726
Set C1:SUS-PRM_ULCOIL_GAIN to 0.974482231437
Set C1:SUS-PRM_URCOIL_GAIN to -1.04382410014
Set C1:SUS-PRM_LRCOIL_GAIN to 0.898628670041
Set C1:SUS-PRM_LLCOIL_GAIN to -1.03811466772

- New f2p filters

- measured coupling coefficients are :
P2P(POS=>PIT) = 0.023968
P2Y(POS=>YAW) = 0.007075


========== BS ==========

- Original DC coil gains

C1:SUS-BS_ULCOIL_GAIN 1.037692431800000e+00
C1:SUS-BS_URCOIL_GAIN -1.016268296990000e+00
C1:SUS-BS_LRCOIL_GAIN 9.660800075010000e-01
C1:SUS-BS_LLCOIL_GAIN -9.791833500410000e-01

- New DC coil gains

multiplier factors are :
UL = 1.017855
UR = 1.023207
LR = 0.956184
LL = 1.002755
Set C1:SUS-BS_ULCOIL_GAIN to 1.0562177496
Set C1:SUS-BS_URCOIL_GAIN to -1.03985422464
Set C1:SUS-BS_LRCOIL_GAIN to 0.923750146975
Set C1:SUS-BS_LLCOIL_GAIN to -0.981880297098

- New f2p filters

- measured coupling coefficients are :
P2P(POS=>PIT) = 0.038251
P2Y(POS=>YAW) = -0.014677


  8193   Wed Feb 27 22:28:53 2013 BrettUpdateSUSGlobal Damping Update

 New excitation points were added after the global damping loops for more testing options. The updated c1sus.mdl model was re-committed to the svn. Two interesting simulink 'requirements' were found during this minor modification. First, excitation points must be placed on the top level of the diagram. If they are in a subsystem you will get compiling errors. Second, the excitation name must end in _EXC. It will compile OK if you don't do this, but the excitation points will not put out any excitations.

To do further investigation on the mysterious gain factor of 2.5 between the ETMY and ITMY POS damping loops, I measured TFs in the POS direction to the locked YARM signal for each. This provides an additional sensor, common to both, so we can see if the gain is coming from the actuation side or sensing side of the damping loops. The difference in these TFs is about 


So it seems the majority of the damping gain difference is on the actuation side with some small difference on the sensing side. In order to allow for the later splitting of YARM LSC control between ITMY and ETMY (global damping and the cavity control must be along the same coordinate system), I placed this gain of 2.95 in ITMY_LSC.

To get a first measure of the relative performance of global damping to local damping I measured some TFs between the sensor signal inputs and YARM. So first, while the cavity was still locked with just ETMY, I measured a TF between C1:SUS-ITMY_SUSPOS_EXC and C1:LSC-YARM_IN1. Second, I split the cavity control evenly between the ETMY and ITMY by adjusting C1:LSC-OUTPUT_MTRX. I turned off the local damping and turned on the common DOF global damping (called CARM at this point despite being on just one arm). I then repeated the same TF but driving from C1:SUS-GLOBAL_CARMDAMP_EXC.

The resulting TFs are displayed in the attached figure. The blue curve is then the TF from local damping sensor noise to YARM. The green is global damping sensor noise to YARM. The suppression between local to global is in red. The global damping curve is about 50 to 100 times lower (better) than local damping. This can probably be improved with further tuning to account for remaining differences between the ITMY and ETMY.

Note, the damping loop used in the filter modules for all of these is zpk(0,[15 15],1), with a gain of 30. This purposely has little high frequency filtering so it is easier to see the influence on YARM.

Attachment 1: DampNoise_to_YARM_fig_27Feb2013.png
  8207   Fri Mar 1 16:37:45 2013 BrettUpdateSUSGlobal Damping Update

Brett and Kamal

The global damping testing for the week is now complete. The c1sus.mdl simulink diagram settled on the attached screenshot. The top level of c1sus.mdl is shown on the left zoomed in over the new global damping block. The right shows the inside of that block. Also attached in the second screenshot are two of the modal damping MEDM screens. The left shows the main overview screen, the right shows the global damping filters. The overview screen is called C1SUS_GLOBAL.adl and is found in ...medm/c1sus/master/.

We have measured transfer functions and power spectra that show that global damping, with just a moderate amount of tuning (30 minutes of work) reduces the OSEM damping noise seen by YARM_IN1 by a factor between 50 and 80. Log 8193 highlights the transfer function measurements. The power spectra directly measure the noise in the cavity. I am not putting that data here because I have to catch. I will process the data and post it here later.

Overall the global damping tests appear to have been successful, isolating (not removing) the test mass damping noise from the cavity by almost 2 orders of magnitude. Presumably even more isolation is possible with more tuning.

Attachment 1: GlobalDamp_Simulink.png
Attachment 2: GlobalDampScreens.png
  8220   Mon Mar 4 16:26:45 2013 BrettUpdateSUSGlobal Damping Noise Measurement

Here is an amplitude spectrum plot of y-arm cavity noise with a 50 Hz cutoff damping filter of the form zpk(0,[50;50],1). The low passing of this filter was intentionally extremely poor in order to see the damping noise in the cavity. The blue trace is the noise with no damping, which may be considered the 'best case' scenario from a noise point of view. The green has regular local damping on the ITMY. The ETMY has no damping for this measurement because the cavity control feedback to the ETMY takes care of its control when the cavity is locked. Notice the the large increase in noise from 40 Hz to 250 Hz, up to 1 order of magnitude. This noise is from the OSEM sensors passing through the damping loops. The red curve shows the y-arm noise with the exact same damping, except it is now applied in the global scheme. In this case, the damping noise falls completely below the baseline level of the cavity and becomes indistinguishable from the 'no damping' case.

If the damping injected enough noise I'd expect we would see a drop of 50 to 80 times switching from local to global. That is, the same factor measured in the transfer functions listed in log entry 8193.  However, the damping noise is only at most 1 order of magnitude above the baseline in this measurement. We would have to increase the damping noise by about another order of magnitude before we could expect to see the global damping noise in the cavity measurement.

The units of the cavity displacement in the plot were calculated using the 1.4e12 counts per meter calibration in log 6834. The measured UGF of the LSC loop at the time was 205 Hz. The peak in the plot above 200 Hz appears to be from this unity crossing. Moving the UGF also moves this peak.

Moral of the story: global damping can isolate the damping noise pretty well from the cavity signal.

Attachment 1: YARM_Noise.png
  8221   Mon Mar 4 16:46:31 2013 yutaUpdateSUSoplev calibration for PRM

[Manasa, Sendhil, Yuta]

We calibrated oplev for PRM. Calibration factor for C1:SUS-PRM_OL(PIT|YAW)_IN1 are;
  OLPIT: 15.6 +/- 0.3 counts/mrad
  OLYAW: 17.8 +/- 0.3 counts/mrad

We needed these values for g-factor measurement of PRC using angle dithering method.

What we did:
  1. Adjusted QPD offsets (C1:SUS-PRM_OL[1-4]_OFFSET) by zeroing the output when turned oplev laser was turned off.
  2. Centered PRM oplev beam on QPD using steering mirror.
  3. Mounted PRM oplev QPD on a xy-stage and centered the beam on QPD.
  4. Moved QPD in x and y using micrometers and measured dependance of C1:SUS-PRM_OL(PIT|YAW)_IN1 on QPD displacement.
  5. Measured the path length of PRM oplev returning beam. We get the in-vac path length using optical layout CAD. We measured out of vac path using scale and tape measure.
  6. Dismounted PRM QPD from the stage and put it back to the original position.

  1. Figures below are OLPIT/OLYAW dependance on micrometer displacement moved in x and y. Error bars are measured fluctuation in the signal.

moved in x:PRM_PIT.png       moved in y:PRM_YAW.png

  2. We fitted the result by error function to get slope at zero crossing point. We also linear-fitted the other degree of freedom to get cross coupling between x and y. Slopes we get were;

micrometer    OLPIT          OLYAW
moved in x    4.68 +/- 0.08  0.01 +/- 0.03
moved in y   -5.32 +/- 0.10  0.11 +/- 0.03    (counts/mm)

  3. Measured the path length of PRM oplev returning beam was 3340 +/- 20 mm. This gives you the calibration factors above.

  [Precision] According to Jamie's calculation, expected g-factor for PRC in PR2-flipped PRMI is 0.966/0.939 (elog #8068). We care about the g-factor change in ~0.01. Also, intra-cavity power dependance on mirror angle is proportional to 1/(1-g). So, we need to calibrate mirror angle in ~few 10 % of precision in order to get useful g-factor from angle dithering measurement. Measurement precision here meets this requirement.

  [x/y coupling] Measured x/y coupling was less than 2 %. We assumed gains in 4 QPD quadrants are same, and assumed QPD is mounted well in x/y axes. These assumptions are OK considering precision we need.

  [x/y difference] Calibration factors for OLPIT/OLYAW are different by ~10 %. This is not so crazy considering the incident angle on the QPD (~20 deg) and elliptic beam shape.

  8223   Mon Mar 4 18:11:10 2013 JamieUpdateSUSCleaning up suspension POS inputs

I did a little bit of cleanup of the suspension POS inputs today, both in model and MEDM land.


sus_single_control.mdl was simplified such that now there are just two position inputs:

  • POS: with LSC filter
  • ALTPOS: unfiltered

The regular LSC inputs go into POS, and any optic-specific extra pos inputs go into ALTPOS after being properly filtered and summed.

So for instance, MC2_MCL and MC2_ALS are filtered and summed then go into MC2 ALTPOS.  The ETM ALS inputs go into ALTPOS.

I modified the GLOBAL DAMPING outputs so that they are filtered in the GLOBAL block before being sent to be summed before going into ALTPOS for {I,E}TM{X,Y}.

All suspension models were rebuilt/installed/restarted.


The SUS_SINGLE.adl template screen was modified such that the POS button now points to optic-specific POS filter screens at:


For MC1, MC3, PRM, BS, SRM these are links to SUS_SINGLE_POS.adl.  The rest of the suspensions (MC2, {I,E}TM{X,Y}) now have custom screens that are variations of SUS_SINGLE_POS but with their extra filter screens added in.  For instance, here is the new SUS_ETMX_POS.adl:


This gets rid of all the white screen crap that was in here before.

All of this has been committed to the SVN.  NOTE: symlinks were heavily used when sorting this stuff out, so check for symlinks when modifying in the future.

  8232   Tue Mar 5 17:09:30 2013 yutaUpdateSUSoplev calibration for ITMY

[Manasa, Sendhil, Yuta]

We calibrated oplev for ITMY. Calibration factor for C1:SUS-ITMY_OL(PIT|YAW)_IN1 are;
  OLPIT: 6.29 +/- 0.11 counts/mrad
OLYAW: 5.74 +/- 0.09 counts/mrad

Note that there was ~10% of coupling between pitch and yaw.
This is large considering statistical error, but I think this is from QPD mounted rotated (by ~5 deg).

  Same as in elog #8221.

moved in y: ITMY_PIT.png      moved in x: ITMY_YAW.png

micrometer    OLPIT          OLYAW
moved in y    3.14 +/- 0.05  0.27 +/- 0.03
moved in x   -2.87 +/- 0.04  0.17 +/- 0.03    (counts/mm)

  Measured the path length of ITMY oplev returning beam was 2000 +/- 20 mm. This gives you the calibration factors above.

  ~10 % coupling between OLPIT and OLYAW can be explained by QPD rotation by ~ 5 deg, which seems not unreasonable.

  8236   Tue Mar 5 23:37:11 2013 yutaUpdateSUSPRM angular motion spectra

I measured PRM angular motion spectra (in daytime today).
PRM angular motion is ~ 10 urad in RMS when undamped and ~1 urad in RMS when damped.
If PR2/PR3 angular motions are something like this, and their motion are not enhanced when PRC is locked, measured g-factor of PRC looks OK. But considering the error we have, maybe we are not OK yet. We need calculation.


  8362   Thu Mar 28 00:31:11 2013 JenneUpdateSUSPRMI optics' oplev servos tuned

[Rana, Gabriele, Jenne, Jamie, Lisa, Rana]

We have tuned the oplev servos for PRM, BS, ITMX, ITMY.  For each, we measured the servo transfer function.  Most had a UGF ~ 3Hz.  For those, we increased the gain by a factor of 2, and engaged the 3.3Hz resonant gains. The other case, such as PRM yaw, the gain was already okay, we just needed to engage the resonant gain.  We also checked the new phase margin, and for some of them switched the elliptic lowpass to 50Hz rather than 30 or 35.

Before and afters:









We need to, as a last check, look at the spectra before and after to ensure that no modes (like bounce or roll) are newly excited.

  8389   Tue Apr 2 15:58:40 2013 JenneUpdateSUSoplev calibration for ITMX, BS

[Jenne, Gabriele]

Optical lever calibrations:

ITMX pit calibration = -9.07 cts/mrad

ITMX yaw calibration = -12.33 cts/mrad

ITMX plot:opl_itmx.png

BS pit calibration = -22.86 cts/mrad

BS yaw calibration = -24.14 cts/mrad

BS plot:opl_bs.png


Method:  Similar to Manasa and Yuta's method last month.  We mounted each oplev QPD on a micrometer translation stage, centered the beam using the steering mirror, then used tdsavg to get 10 second averages of the _INMON channel for various settings of the micrometer stage.  For BS, we had to take out the PRM oplev to make room for the translation stage.  All QPDs were remounted in their original positions, within less than 1mm.  Measured the out-of-vac distances with the laser disto-meter, and the invac distances from the optic to the window from the CAD drawing.

Copying from other elog entries,

elog 8232:

We calibrated oplev for ITMY. Calibration factor for C1:SUS-ITMY_OL(PIT|YAW)_IN1 are;
  OLPIT: 6.29 +/- 0.11 counts/mrad
OLYAW: 5.74 +/- 0.09 counts/mrad


elog 8221:

We calibrated oplev for PRM. Calibration factor for C1:SUS-PRM_OL(PIT|YAW)_IN1 are;
  OLPIT: 15.6 +/- 0.3 counts/mrad
  OLYAW: 17.8 +/- 0.3 counts/mrad

  8390   Tue Apr 2 16:13:10 2013 ranaUpdateSUSoplev calibration for ITMX, BS

  Very good - now you need to just put the cal factor into the filter banks so that the PERROR and YERROR signals are in microradians all the time.


EDIT JCD:  In progress.

  8391   Tue Apr 2 16:55:34 2013 JenneUpdateSUSoplev calibration online for ITMs, BS, PRM

[Jenne, Gabriele]

We have put in a new EPICS input into the SUS library part, just before the OL_PIT and OL_YAW filter banks, so that the IN1 point is calibrated to microradians.  I recompiled all SUS-related models.  The OPTLEV_SERVO screen has been changed, so that you can see the calibration, and enter a value.  The gains have been reduced by a factor reciprocal to the calibration, so the loop gain is the same.

ETMs, SRM and MCs all have "calibration" numbers of 1, so the numbers aren't really calibrated, they're just the same as always.

It looks like the PRM and the BS are moving significantly (factor of ~30) more than the ITMs at a few Hz!  (Y-axis of plot is urad/rtHz)


EDIT JCD:  We need to fix up the MEDM QPD indicators, and the OpLev red lights on the watchdog screen, so they match the new numbers.  Also, Rana turned on the output limiters to 2000 for all oplev servos.

  8393   Tue Apr 2 18:19:30 2013 JenneUpdateSUSBS, PRM oplev servos improved


[Gabriele, Jenne]

We have implemented 4Hz resonant gains for both PRM and BS yaw.  The filter was already in place for PRM Yaw, so we just turned it on, but we also copied the filter over to BS Yaw.  We also changed the 3.3Hz res gain and the ELP for the PRM servo to match the BS servo, since after implementing the 4Hz gain, PRM was still much noisier than BS.  Now the 2 servos match, and PRM is a little quieter.  We hope that tonight's locking might be a little more stable after this work.



  8441   Thu Apr 11 03:25:29 2013 JenneHowToSUSIdea for how to properly balance SUS actuators
We have calibrated the overall actuators of each suspension independent of the optical levers. So, we know how much we are 
moving the optic in POS in real units as a result of the dither we inject for the lockin measurement. The amount the oplev beam 
appears to move if there is only POS motion is
where theta is the oplev's angle of incidence and d is the distance the optic has moved in POS.  None of the of the steering mirrors in the 
oplev path matter. 

I propose that I will add an option in the lockin path to subtract away the apparent angle from the oplev output just before the signal 
goes into the lockin module.  Then we will be balancing the actuators based on only the actual angular motion.

The success of this technique depends on how well we know our actuator calibration and the oplev angle of incidence. This also 
assumes that the oplev beam is centered on the optic, so we don't have beam displacement from A2L of the oplev beam, which then 
makes another apparent angular motion.  I suspect that we are close enough that we won't have to worry about this effect.
  8480   Tue Apr 23 22:59:05 2013 ranaConfigurationSUSOptical Lever Gains normalized

Due to the recent addition of cal factors in the OL error points, the OLPIT_GAIN and OLYAW_GAIN have been reduce to tiny numbers (e.g. 0.002).

Since our MEDM only shows 3 digits past the decimal point by default, it makes more sense to have the gains around 1.

So I reduced the gains in all of the FM1 filters from 1000 to 1 and multiplied the GAIN values by 1000 (using ezcastep) to compensate.

All of the active optics seem to be behaving as before. Haven't tested ETMs or SRM yet.

  8481   Wed Apr 24 00:42:07 2013 JenneUpdateSUSPRMI locked, ITMX pitch OpLev ringing up

Koji is working on PRMI locking, and while he was doing that I glanced at the oplevs' spectra for the ITMs and PRM.

I found that when the PRMI was locked (for only 1 second or so max lock time) on the 55MHz sideband, and the error signals show a big peak around 400Hz (definitely audible in the control room), the only OpLev that I see a similar peak in is ITMX pitch. 

In the plot below, I have grabbed a time when the PRMI was flashing as the black reference traces, and then a time when the PRMI was locked as the active traces.  You can see that there is a similar peak in both REFL55I and ITMX_OL_PIT when the cavity is locked. 


  8482   Wed Apr 24 00:44:33 2013 KojiUpdateSUSPRMI locked, ITMX pitch OpLev ringing up

I tried to reproduce the locking situation described in this entry tonight.
The momentary lock was regularly seen but there was no stable lock.

I wonder why the actuators are always saturated. The feedback signals have the dominant component at ~400Hz.

It would also be nice if the servos have some immunity to gain fluctuation.

I didn't check how the situation of the AP table is. I'll look into some details tomorrow.

  8510   Tue Apr 30 10:54:35 2013 JenneUpdateSUSETMX restored

I'm not sure why or when it was tripped, but I have restored the ETMX watchdog.

  8514   Tue Apr 30 22:40:57 2013 JenneUpdateSUSoplev XY-plots reflect new calibration

Back when Gabriele was here, he and I implemented online calibration of the oplevs, into microradians.  A consequence of this is that all of the XY-plots on the medm screens were too small. 

I have gone through all the screens that I could think of (SUS_SINGLE, SUS_SINGLE_OPTLEV_SERVO, OPLEV_MASTER, OPLEV_SUMMARY, OPLEV_SUMMARY_SMALL_SCALE, IFO_OVERVIEW) and made the range of the XY-plots +/- 100, rather than the old scale of +/-1. 

I have also added red boxes behind the numbers on many (but not yet all) of these screens, so that you can see when (a) the oplev sum is too low, or (b) either the pit or yaw value is over 50 microradians. 

While I was putzing around on the IFO overview screen, I also made the oplev sum numbers clickable, with the related display being that optic's oplev servo screen.

  8527   Fri May 3 09:17:41 2013 SteveUpdateSUSETMX needs some help
Attachment 1: ETMX3.2eq.png
  8533   Tue May 7 03:14:06 2013 JenneUpdateSUSPRM SUS_LSC violin (FM5) set to correct frequency

While looking over Koji's shoulder earlier, I noticed the big peak in the PRM yaw spectrum (and I was starting to get annoyed by the hum....the fibox is so useful in motivating tasks that otherwise get looked over!) 

I used DTT's peak find feature (cursor tab, enable both cursors, select Peak X/Y as your 'statistic', set the 2 cursors to be on either side of the desired peak) to find the frequency of the PRM's violin mode.  It is 627.75 Hz. I adjusted FM5 of the C1:SUS-PRM_LSC filter bank (the "violin" filter) to be centered around this frequency, with the start and stop freqs +\- 4Hz.  I plotted the filter linearly in frequency to ensure that my target freq was not too close to either side of the bandstop.  After loading and engaging the new filter, the hum slowly started to go away. 

Note, for posterity:  The bandstop used to be centered around ~645 Hz or so.  I assume this is a copy-and-paste situation, where we hadn't gone through to check the exact frequency for each optic.

  8612   Wed May 22 00:42:13 2013 KojiSummarySUSviolin Q

While looking at the decay of the violin mode of the PRM, I made a simple measurement of the decay rate.

Error signal: REFL33I

The peak @628Hz became 0.372 to 0.303 in 60 sec.

-> Half life of the amplitude T_{1/2} is 203sec.

Q = 4.53 f0 T_{1/2} = 5.8 x10^5

  8617   Wed May 22 15:48:56 2013 JamieUpdateSUSTurn off zero padding in DAC outputs

After the results of the analysis in the #8598 thread, I have added the "no_zero_pad=1" flag to the cdsParameters block of all SUS models:

  • c1mcs
  • c1sus
  • c1scx
  • c1scy

The upsampling to the 64 kHz DAC output will now be done with sample-holds, instead of zero-pads.  This should reduce the 32 kHz lines we were noticing in the analog DAC output.

I note, though, that Brian Lantz points out that this might actually introduce a delay of about a half sample.  We will continue to investigate.

In any event, I have rebuilt and installed all models listed above.  I will restart as soon as opportunity allows.

  8620   Wed May 22 18:24:19 2013 JenneUpdateSUSViolin mode survey


It was too embarassing to see that the actuation frequency was set at the violin mode frequency in order to avoid designing a new filter!?

 Ooops, definitely my bad.  I think I was the one who put in the PRM violin filter, so I should have recognized that frequency.  However, I couldn't think of a reason why violin mode filters should be in the LSC filter banks, since we usually put them in C1:SUS-optic_LSC filter banks. 

Anyhow, so that I don't make a mistake like that again, I was looking through all of the violin mode filters for all the optics, so I could write down the frequencies.  The result: confusion.

Violin filters in C1:SUS-optic_LSC filter banks:

The PRM's violin mode filter is set correctly to 627.75Hz:  elog 8533.

One of BS or SRM has probably been measured (presumably BS), since they have the same filters centered around 645Hz. 

Neither ITM has a violin filter.

The ETMs have violin filters in the 440's, which I assume was correct back in the MOS days, before 2010.

Vio2 filters in C1:SUS-optic_LSC filter banks:

PRM, SRM, BS, ITMX, ITMY:  Centered around 1285 Hz, which matches the violin notch frequencies in the BS and SRM.

ETMY:  Centered around 883.5Hz, which matches the old 440Hz frequency

ETMX:  Centered around 631Hz .  So, this could have been measured, but it was put into the wrong filter module.


Koji tells me that we don't really need to worry about all these violin filters unless they are required (as with the PRM and the obnoxious hum a few weeks ago), so I 'm not going to do any measuring / adjusting of these filters for now.

  8625   Thu May 23 10:20:33 2013 JamieUpdateSUSTurn off zero padding in DAC outputs


After the results of the analysis in the #8598 thread, I have added the "no_zero_pad=1" flag to the cdsParameters block of all SUS models:

  • c1mcs
  • c1sus
  • c1scx
  • c1scy

The upsampling to the 64 kHz DAC output will now be done with sample-holds, instead of zero-pads.  This should reduce the 32 kHz lines we were noticing in the analog DAC output.

I note, though, that Brian Lantz points out that this might actually introduce a delay of about a half sample.  We will continue to investigate.

In any event, I have rebuilt and installed all models listed above.  I will restart as soon as opportunity allows.

I have restarted all the suspension models with the new no_zero_pad flag for the DAC upsampling.  Everything came up fine and all optics are damped as expected (except for concerns about c1scy which I'll note in a followup).

  8668   Tue Jun 4 10:33:09 2013 ranaUpdateSUSETMY oplev path redone

 We also redid the oplev path.

Someone had used the illegal tactic of using aluminum dogs to hold down mounts which already have screw holes in the bases. This is too flimsy to use.

We then adjusted the position of the second lens to get a ~1 mm spot on the QPD. There is a lot of stray red light from extra reflections, but so be it.

Its possible that we are now clipping the IPANG path, but we will need to lock the Y arm and verify the input pointing to be sure. At this point we are ready to measure the ETMY OL loop gain and tune, etc.

  8719   Wed Jun 19 00:46:06 2013 JenneUpdateSUSsave/restore alignment scripts now also work for TTs, fixed a bug

I have done a quick update of the IFO_ALIGN screen's save and restore scripts, so that we can now also save, restore, and view the saved values for the input tip tilts. 

In the past, there was an "if" statement to check if the optic was a PZT, and if so, define the alignment channels accordingly (since all the SOS suspensions have the same format for the name, and the PZTs were the odd ones out).  I have removed the mention of PZTs, and replaced the if statement with an "if TTs" statement, and put in the correct channel names (C1:IOO-TT#_PIT_OFFSET, and the same for YAW). 

Also, I caught a bug in the code, which explains some confusing behavior that I had seen in the past.  When deciding if the restore script should take small steps or just do a big step, it looked at the difference between the saved value and the current value of the slider.  It was *not* looking at the absolute value of the difference.  So, if you had misaligned a slider by hand, and it was in the opposite direction of what the misalign script does, the restore script wouldn't realize that the optic needed to be restored in small steps.  I have now fixed this bug for both pit and yaw cases of the restore script.

  8734   Thu Jun 20 17:47:44 2013 AnnalisaConfigurationSUSETMY oplev servo

[Jenne, Annalisa]

The ETMY Oplev servo didn't work properly, when it was activated the ETMY moved too much.

We measured the oplev TF for Pitch and Yaw and it turned out that the gain was too low by a factor 3, so we increased the gain from -.250 to -.750 on both.

We also locked the Y arm and we could see that the mirror's oscillations are actually suppressed.


  8747   Tue Jun 25 22:50:12 2013 ranaUpdateSUSSUS Screens generation problems?


From the ALS overview screen, opening up the ETMX and ETMY screens gives these white fields. The PV info indicates that the blank fields were made with some macro variable substitution that didn't work well.

Why are these different from the SUS screens I get from the sitemap?

  8749   Tue Jun 25 23:49:04 2013 AnnalisaUpdateSUSETMY Oplev

I had some problem with the Oplev Servo today. I was working at the mode matching fine tuning and I left the Oplev servo enabled while aligning.

When I opened the Yend table lids, the Oplev beam started moving on the QPD and the Oplev servo didn't help in stopping the mirror movement, but it increased it.

So, the mirror was oscillating at a frequency of a few Hz

Koji suggested that maybe the shaking is due to the air conditioning moving the beam, so the servo tries to feed back the signal to the mirror, even if the mirror doesn't actually move.

I also measured the transfer function for the Oplev, but it didn't show any strange behavior.

  8750   Tue Jun 25 23:57:30 2013 ranaUpdateSUSNDS2 Status

I've restarted the NDS2 process on Megatron so that we can use it for getting past data and eventually from outside the 40m.

1) from /home/controls/nds2 (which is not a good place for programs to run) I ran nds2-megatron/start-nds2

2) this is just a script that runs the binary from /usr/bin/ and then leaves a log file in ~/nds2/log/

3) I tested with DTT that I could access megatron:31200 and get data that way.

There is a script in usr/bin called nds2_nightly which seems to be the thing we should run by cron to get the channel list to get updated, but I' m not sure. Let's see if we can get an ELOG entry about how this works.

Then we want Jamie to allow some kind of tunneling so that the 40m data can be accessed from outside, etc.

  8757   Wed Jun 26 15:11:08 2013 John ZweizigUpdateSUSNDS2 Status


I've restarted the NDS2 process on Megatron so that we can use it for getting past data and eventually from outside the 40m.

1) from /home/controls/nds2 (which is not a good place for programs to run) I ran nds2-megatron/start-nds2

2) this is just a script that runs the binary from /usr/bin/ and then leaves a log file in ~/nds2/log/

3) I tested with DTT that I could access megatron:31200 and get data that way.

There is a script in usr/bin called nds2_nightly which seems to be the thing we should run by cron to get the channel list to get updated, but I' m not sure. Let's see if we can get an ELOG entry about how this works.

Then we want Jamie to allow some kind of tunneling so that the 40m data can be accessed from outside, etc.

 I have done the following:

  * installed the nds2-client in /ligo/apps/nds2-client

  * moved the nds2 configuration directories to /ligo/apps/nds2/nds2-megatron

  * set up a cron job to update the channel list every morning at 5 am. The cron line is:

     15 5 * * * /usr/bin/nds2_nightly /ligo/apps/nds2/channel-tracker /ligo/apps/nds2/nds2-megatron

    cron will send an email each time the channel list changes, at which point you will have to restart the server with:

     cd /ligo/apps/nds2/nds2-megatron
     pkill nds2

  * restarted nds2 with updated channel lists.

ELOG V3.1.3-