40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 171 of 344  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  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.



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


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



The data files are attached. 

Attachment 2: BeamProfile_IPPOS.pdf
Attachment 3: BeamProfileData_IPPOS.xlsx
  6448   Tue Mar 27 02:05:40 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam


[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




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 )







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.





Attachment 1: BeamProfile_IPPOS.png
  6459   Tue Mar 27 23:37:35 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam



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.



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


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.


Attachment 1: 40mOpticsLocations.pdf
Attachment 2: Beam-Profile_IPPOS_wError.pdf
Attachment 3: Beam-Profile_PRM_1_wError.pdf
  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.  


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.

Attachment 1: BeamProfileData_IPPOS_2.xlsx
  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.





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.






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


[Suresh, Jenne]

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



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


  • 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



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




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

  • 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


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.



  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



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.


  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. 




  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


  6762   Wed Jun 6 01:23:32 2012 SureshSummaryIOOTip-Tilt Cabling


2 questions (so far) regarding your diagram / doc:

We are using 3 of the feed-throughs on the BS chamber, and 1 on the OMC chamber, even though we have 2 TTs on the BS table, 1 on the OMC table, and 1 on the IMC table? Just wanted to check.

Does your list / table at the bottom include all of the cables we already have, as well as the ones we need?  (Or maybe we just have nothing so far, so this is a moot question).

 The scheme currently is to run a 25pin Kapton strip cable from BS to IMC table inside the chamber.  However we cannot do the same for the OMC table since it will cross the bellows which we often remove.  So we need to supply the one tip-tilt on the OMC table from outside.  I could not spot a spare unused feedthough on the OMC chamber.  We will have to swap one of the blank flanges for one with a few feed throughs.

We do not have any of the cables.   So everything listed has to be arranged for.   The pics are from the existing coil driver system on the SUS machine.


  6770   Wed Jun 6 19:46:46 2012 SureshSummaryIOOTip-tilt assembly: current status and work remaining


Recent History

The lower blades which I had given to the Physics Workshop for making a vacuum relief hole (using a sinker-EDM process) came back about ten days ago.   Merih Eken <meken@caltech.edu>,  the supervisor at the Physics Dept workshop, handled this matter for us.  The blades were sent to a local EDM machineshop and returned in about three working days ( a weekend intervened). 

IMG_0685.JPG  IMG_0687.JPG

Bob cleaned and handed them over to me yesterday evening.  

Current status

Today I have reassembled the four tip-tilts.  I have repacked them in clean bags (double bagged) shifted them to Clean Optics Cabinet (near the ETMX chamber).  The four tip-tilts are in the bottom-most shelf in the cabinet.  There are also some tip-tilt spares in a separate envelope.

Note:  The mirror holder is now held tightly by the eddy current dampers.  This was done for safety of the wires during transportation from LHO.  The eddy current damper in the front of the mirror has to be retracted to allow the mirror holder to swing free.  It has be to about 1mm away from the suspended mirror holder

Work Remaining

1) We need to install the quadrapus cables.  The connector placement on the BOSEM side will have some issues.  It is best to loosen the BOSEM seating as well as the connector seating screws and then push the cable connector into place.  Caution:  when the connector seating screws on the BOSEM are loosened the flexible ckt could be damaged by the loose connector.

2) Insert the mirrors into the mirror holders and balance the suspension such that the mirror's hang vertical and do not have a large yaw offset.

3) Adjust the wire suspension point height so that the flags are in the center of the BOSEM aperture.  Else they will strike against the

4) We need to adjust the position of the BOSEMs such that the shadow sensor signals are at 50%.  This ensures that all the magnets hang at an appropriate distance from their respective coils.

5) To do (3) we need to set up a shadow sensor read-out set-up for one tip-tilt (four sensors)


Attachment 2: IMG_0687.JPG
  4414   Fri Mar 18 16:31:11 2011 Suresh UpdateGreen LockingRe: Y arm plan for today

The reason for using Alberto's laser is that some amount of work has already gone into characterising its phase noise.  Ref elog entry 2788

  3746   Wed Oct 20 18:17:35 2010 Suresh, JenneUpdateSUSPRM assembly

We have positioned the guide rod and the wire-stand-off on the optic in the axial direction. 

We have selected six magnets whose magnetic strength is +/-5% of their mean strength (180 Gauss).  The measurement was made as follows:

1) each magnet was placed on its  end, on the top of a beaker held upside down. 

2) The Hall probe was placed directly under the magnet touching the glass from the other side (the inside of the beaker). 

This ensures that the relative position of the magnet and the probe remains fixed during a measurement.  And ensures that their separation is the same for each of the magnets tested. 

With this procedure the variation in the measured B field is less than +/- 10% in the sample of magnets tested.

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

[Jenne, Suresh]


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

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

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

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

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



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


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

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



  4297   Tue Feb 15 06:59:57 2011 Suresh, JenneOmnistructureGeneralX end enclosure left open

[Jenne, Suresh]

 Jenne found the X-end table enclosure had been left open.  She replaced the lid on it.


  5244   Tue Aug 16 04:25:34 2011 Suresh, KiwamuUpdateSUSalignment of MC output to Y-arm using PZTs

We did several things today+night.  The final goal was to lock the PRC so that we could obtain the POX, POY and POP beams.  However there were large number of steps to get there.

1) We moved the ITMY into its place and balanced the table

2) We then aligned the Y-arm cavity to the green beam which was set up as a reference before we moved the ETMY and ITMY to adjust the OSEMS.  We had the green flashing in Y-arm

3) We checked the beam position on PR2. It was okay. This confirmed that we were ready to send the beam onto the Y arm.

4) We then roughly aligned the IR beam on ETMY where Jamie had placed an Al foil with a hole.  We got the arm flashing in both IR and green. 

5) We used the PZTs to make the green and IR beams co-incident and flashing in the Y arm.  This completed the alignment of the IR beam into the Y-arm.

6) The IPPO (pick-off) window had to be repositioned to avoid clipping.  The IPANG beam was aligned such that it exits the ETMY chamber onto the ETMY table.  It can now be easily sent to the IPANG QPD.

7) Then BS was aligned to direct the IR beam into the X-arm and had the X-arm flashing.  It had already been aligned to its green.

8) It was now the turn of the SRC.  The beam spots on all the SRC related optics were off centered.  We aligned all the optics in the AS path to get the AS beam on to the AP table.

9) The AS beam was very faint so we repositioned the AS camera to the place intended for AS11 PD, since there was a brighter beam available there. 

10) We could then obtain reflections from ITMY, ITMX and PRM at the AS camera. 

11) Problems:

      a) ITMY osems need to be readjusted to make sure that they are in mid-range.  Several are out of range and so the damping is not effective.

      b) When we tried to align SRC the yaw OSEM had to be pushed to its full range.  We therefore have to turn the SRM tower to get it back into range.

 12)  We stopped here since moving the SRM is not something to be attempted at the end of a rather long day. Kiwamu is posting a plan for the rest of the day.

  16624   Tue Jan 25 18:37:12 2022 TYehonathanUpdateBHDPR2 Suspension

PR2's side magnet height was adjusted and its roll was balanced (attachment 1,2). I verified that the OpLev beam is still aligned. The pitch was balanced: First, using an iris for rough adjustment. Then, with the QPD. I locked the counterweight setscrew.

I turned off the HEPAs, damped PR2, and measured the QPD spectra (attachment 3). Major peaks are at 690mHz, 953mHz, and 1.05Hz. I screwed back the lower OSEM plate. The wires were clamped to the suspension block and were cut. Winch adapter plate removed. I wanted to push OSEMs into the OSEM plates but the wiki is down so I can't tell what was the plan. This will have to wait for tomorrow. Also here like with AS1 we need to apply glue to the counterweights.

Attachment 1: PR2_magnet_height.png
Attachment 2: PR2_roll_balance.png
Attachment 3: FreeSwingingSpectra_div_50mV.pdf
  7911   Thu Jan 17 01:27:54 2013 Tara(?)SummaryIOONoise budget for MC


I missed the point.
Do you mean that we can measure the coating thermal noise of the ref cav at the 40m as the IMC is quiet enough?

 Yes, it should be. However, what I did was calculating thermal noise of MC. I'm not sure about the 40m IMC's actual noise level. The plot in the entry was taken from LLO's MC in 2003.

  16314   Fri Sep 3 02:03:15 2021 TegaSummaryComputersStrip down large error files

Also deleted the ~50GB error files from ldas to prevent rsync from copying them to nodus again. With the new update to GWsumm, there are new error messages that initially didn't seem to affect the summary pages functionality, but in the extreme case can populated the error files the repeated warnings on the form "Loading: FrSerData", "Loading: FrSerData::n4294967295", "Loading: FrSummary","Loading: FrSerDataLoading: FrSerData" and many more combinations until we get file sizes of the order of ~50GB. So I have updated the checkstatus script to parse the error files and strip out the majority of these error messages. Work is ongoing to get them all.

In light of these large files generation, I decided to look in the summary pages folder to see if there are other large files that we need to keep track of and it turns there are indeed a collection of files in the archive folder that bloats the summary pages on ldas to ~1TB. Luckily these are not synced to nodus so no problem here. However, since the beginning of the year, the archive folders that hold data used for each day's computation have not been cleared. We have a script for doing this but it has not been run for a while now and it only delete archive files for a specific month which is hardcoded to two months from the date the file is run. I have modified the code to allow archive deletion for a range of months so we can clear data from Jan to July. 


[tega, paco]

We found the files that took excess space in the chiara filesystem (see Attachment 1). They were error files from the summary pages that were ~ 50 GB in size or so located under /home/cds/caltech/users/public_html/detcharsummary/logs/. We manually removed them and then copied the rest of the summary page contents into the main file system drive (this is to preserve the information backup before it gets deleted by the cron job at the end of today) and checked carefully to identify the actual issue for why these files were as large in the first place.

We then copied the /detcharsummary directory from /media/40mBackup into /home/cds to match the two disks.


  16315   Tue Sep 7 18:00:54 2021 TegaSummaryCalibrationSystem Identification via line injection


This morning, I spent some time restoring the jupyter notebook server running in allegra. This server was first set up by Anchal to be able to use the latest nds python API tools which is handy for the calibration stuff. The process to restore the environment was to run "source ~/bashrc.d/*" to restore some of the aliases, variables, paths, etc... that made the nds server work. I then ran ssh -N -f -L localhost:8888:localhost:8888 controls@allegra from pianosa and carry on with the experiment.

[paco, hang, tega]

We started a notebook under /users/paco/20210906_XARM_Cal/XARM_Cal.ipynb on which the first part was doing the following;

  • Set up list of excitations for C1:LSC-XARM_EXC (for example three sine waveforms) using awg.py
  • Make sure the arm is locked
  • Read a reference time trace of the C1:LSC-XARM_IN2 channel for some duration
  • Start excitations (one by one at the moment, ramptime ~ 3 seconds, same duration as above)
  • Get data for C1:LSC-XARM_IN2 for an equal duration (raw data in Attachment #1)
  • Generate the excitation sine and cosine waveforms using numpy and demodulate the raw timeseries using a 4th order lowpass filter with fc ~ 10 Hz
  • Estimate the correct demod phase by computing arctan(Q / I) and rerunning the demodulation to dump the information into the I quadrature (Attachment #2).
  • Plot the estimated ASD of all the quadratures (Attachment #3)

[paco, hang, tega]

Estimation of open loop gain:

  • Grab data from the C1:LSC-XARM_IN1 and C1:LSC-XARM_IN2 test points
  • Infer excitation from their differnce, i.e. C1:LSC-XARM_EXC = C1:LSC-XARM_IN2 - C1:LSC-XARM_IN1
  • Compute the open loop gain as follows : G(f) = csd(EXC,IN1)/csd(EXC,IN2), where csd computes the cross spectra density of the input arguments
  • For the uncertainty in G, dG, we repeat steps (1) to (3) with & without signal injection in the C1:LSC-XARM_EXC channel. In the absence of signal injection, the signal in C1:LSC-XARM_IN2 is of the form: Y_ref = Noise/(1-G), whereas with nonzero signal injection, the signal in C1:LSC-XARM_IN2 has the form: Y_cal = EXC/(1-G) + Noise/(1-G), so their ratio, Y_cal/Y_ref = EXC/Noise, gives the SNR, which we can then invert to give the uncertainty in our estimation of G, i.e dG = Y_ref/Y_cal.
  • For the excitation at 53 Hz, our measurtement for the open loop gain comes out to about 5 dB whiich is consistent with previous measurement.
  • We seem to have an SNR in excess of 100 at measurement time of 35 seconds and 1 count of amplitude which gives a relative uncertainty of G of 0.1%
  • The analysis details are ongoing. Feedback is welcome.
Attachment 1: raw_timeseries.pdf
Attachment 2: demod_signals.pdf
Attachment 3: cal_noise_asd.pdf
  16319   Mon Sep 13 04:12:01 2021 TegaUpdateGeneralAdded temperature sensors at Yend and Vertex too

I finally got the modbus part working on chiara, so we can now view the temperature data on any machine on the martian network, see Attachment 1. 

I also updated the entries on /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini, as suggested by Koji, to include the SensorGatway temperature channels, but I still don't see their EPICs channels on https://ldvw.ligo.caltech.edu/ldvw/view. This means the channels are not available via nds so I think the temperature data is not being to be written to frame files on framebuilder but I am not sure what this entails, since I assumed C0EDCU.ini is the framebuilder daq channel list.

When the EPICs channels are available via nds, we should be able to display the temperature data on the summary pages.


I've added the other two temperature sensor modules on Y end (on 1Y4, IP: and in the vertex on (1X2, IP: I've updated the martian host table accordingly. From inside martian network, one can go to the browser and go to the IP address to see the temperature sensor status . These sensors can be set to trigger alarm and send emails/sms etc if temperature goes out of a defined range.

I feel something is off though. The vertex sensor shows temperature of ~28 degrees C, Xend says 20 degrees C and Yend says 26 degrees C. I believe these sensors might need calibration.

Remaining tasks are following:

  • Modbus TCP solution:
    • If we get it right, this will be easiest solution.
    • We just need to add these sensors as streaming devices in some slow EPICS machine in there .cmd file and add the temperature sensing channels in a corresponding database file.
  • Python workaround:
    • Might be faster but dirty.
    • We run a python script on megatron which requests temperature values every second or so from the IP addresses and write them on a soft EPICs channel.
    • We still would need to create a soft EPICs channel fro this and add it to framebuilder data acquisition list.
    • Even shorted workaround for near future could be to just write temperature every 30 min to a log file in some location.

[anchal, paco]

We made a script under scripts/PEM/temp_logger.py and ran it on megatron. The script uses the requests package to query the latest sensor data from the three sensors every 10 minutes as a json file and outputs accordingly. This is not a permanent solution.


Attachment 1: Screen_Shot_2021-09-13_at_4.16.22_AM.png
  16323   Mon Sep 13 17:05:04 2021 TegaSummaryPEMInfrasensing temperature sensor modbus configuration

Anchal mentioned it would be good to put more details about how I arrived at the values needed to configure the modbus drive for the temperature sensor, since this information is not in the manual and is hard to find on the internet, so here is a breakdown.

So the generic format is:


which in our case become:


As can be seen, the parameters of the first two functions "drvAsynIPPortConfigure" and "modbusInterposeConfig" are straight forward, so we restrict our discussion to the case of third function "drvModbusAsynConfigure". Well, after hours of trolling the internet, I was able to piece together a coherent picture of what needs doing and I have summarised them in the table below.



Once the asyn IP or serial port driver has been created, and the modbusInterpose driver has been configured, a modbus port driver is created with the following command:

drvModbusAsynConfigure(portName,                # used by channel definitions in .db file to reference this unit)
                       tcpPortName,             # reference to portName created with drvAsynIPPortConfigure command
                       slaveAddress,            # 
                       modbusFunction,          # 
                       modbusStartAddress,      # 
                       modbusLength,            # length in dataType units
                       dataType,                # 
                       pollMsec,                # how frequently to request a value in [ms]
                       plcType);                #

drvModbusAsynConfigure command
Parameter Data type Description
portName string Name of the modbus port to be created.
tcpPortName string Name of the asyn IP or serial port previously created.

tcpPortName = { }
slaveAddress int The address of the Modbus slave. This must match the configuration of the Modbus slave (PLC) for RTU and ASCII. For TCP the slave address is used for the "unit identifier", the last field in the MBAP header. The "unit identifier" is ignored by most PLCs, but may be required by some.

ServersCheck API ignores this value, as confirmed with pymodbus query, so set to default value: 
slaveAddress = 0
modbusFunction int

modbus supports the following 8 Modbus function codes:

Modbus Function Codes
Access Function description Function code
Bit access Read Coils 1
Bit access Read Discrete Inputs 2
Bit access Write Single Coil 5
Bit access Write Multiple Coils 15
16-bit word access Read Input Registers 4
16-bit word access Read Holding Registers 3
16-bit word access Write Single Register 6
16-bit word access Write Multiple Registers 16
modbusStartAddress int Start address for the Modbus data segment to be accessed.
(0-65535 decimal, 0-0177777 octal).

Modbus addresses are specified by a 16-bit integer address. The location of inputs and outputs within the 16-bit address space is not defined by the Modbus protocol, it is vendor-specific. Note that 16-bit Modbus addresses are commonly specified with an offset of 400001 (or 300001). This offset is not used by the modbus driver, it uses only the 16-bit address, not the offset.

For ServersCheck, the offset is "30001", so that

modbusStartAddress = 30200 - 30001 = 199

modbusLength int The length of the Modbus data segment to be accessed.
This is specified in bits for Modbus functions 1, 2, 5 and 15.
It is specified in 16-bit words for Modbus functions 3, 4, 6 and 16.
Length limit is 2000 for functions 1 and 2, 1968 for functions 5 and 15,
125 for functions 3 and 4, and 123 for functions 6 and 16.

ServersCheck uses two's complement 32-bits word (with big-endian byte order & little-endian word order) format to store floating-point data, as confirmed with pymodbus query, so that:

modbusLength = 2
modbusDataType int The modbusDataType is used to tell the driver the format of the Modbus data. The driver uses this information to convert the number between EPICS and Modbus. Data is transferred to and from EPICS as epicsUInt32, epicsInt32, and epicsFloat64 numbers.

Modbus data type:
0 = binary, twos-complement format
1 = binary, sign and magnitude format
2 = BCD, unsigned
3 = BCD, signed

Some Modbus devices (including ServersCheck) use floating point numbers, typically by storing a 32-bit float in two consecutive 16-bit registers. This is not supported by the Modbus specification, which only supports 16-bit registers and single-bit data. The modbus driver does not directly support reading such values, because the word order and floating point format is not specified.

Note that if it is desired to transmit BCD numbers untranslated to EPICS over the asynInt32 interface, then data type 0 should be used, because no translation is done in this case. 

For ServersCheck, we wish to transmit the untranslated data, so:

modbusDataType = 0
pollMsec int Polling delay time in msec for the polling thread for read functions.
For write functions, a non-zero value means that the Modbus data should
be read once when the port driver is first created.

ServersCheck recommends setting sensor polling interval between 1-5 seconds, so we can try:

pollMsec = 1000
plcType string Type of PLC (e.g. Koyo, Modicon, etc.).
This parameter is currently used only to print information in asynReport.
In the future it could be used to modify the driver behavior for a specific PLC.

plcType = "ServersCheck"


Useful links

















  16324   Mon Sep 13 18:19:25 2021 TegaUpdateComputer Scripts / ProgramsMoved modbus service from chiara to c1susaux

[Tega, Anchal, Paco]

After talking to Anchal, it was made clear that chiara is not the place to host the modbus service for the temperature sensors. The obvious machine is c1pem, but the startup cmd script loads c object files and it is not clear how easy it would integrate the modbus functionality since we can only login via telnet, so we decided to instead host the service on c1susaux. We also modified the /etc/motd file on c1susaucx which displays the welcome message during login to inform the user that this machine hosts the modbus service for the temperature sensor. Anchal plans to also document this information on the temperature sensor wiki at some point in the future when the page is updated to include what has been learnt so far.

We might also consider updating the database file to a more modern way of reading the temperature sensor data using FLOAT32_LE which is available on EPICs version 3.14 and above, instead of the current method which works but leaves the reader bemused by the bitwise operations that convert the two 16 bits words (A and B) to IEEE-754 32-bit float, via 

field(CALC, "(A&D?(A&C?-1:1):0)*((G|A&E)*J+B)*2^((A&D)/G-F)")


   field(INPA, "$HiWord")
   field(INPB, "$LoWord")
   field(INPC, "0x8000")   # Hi word, sign bit
   field(INPD, "0x7F80")   # Hi word, exponent mask
   field(INPE, "0x00FF")   # Hi word, mantissa mask (incl hidden bit)
   field(INPF, "150")      # Exponent offset plus 23-bit mantissa shift
   field(INPG, "0x0080")   # Mantissa hidden bit
   field(INPJ, "65536")    # Hi/Lo mantissa ratio
   field(CALC, "(A&D?(A&C?-1:1):0)*((G|A&E)*J+B)*2^((A&D)/G-F)")
   field(PREC, "4")

as opposed to the more modern form

field(INP,"@asyn($(PORT) $(OFFSET))FLOAT32_LE")
  16338   Thu Sep 16 12:06:17 2021 TegaUpdateComputer Scripts / ProgramsTemperature sensors added to the summary pages

We can now view the minute trend of the temperature sensors under the PEM tab of the summary pages. See attachment 1 for an example of today's temperature readings. 

Attachment 1: TempPlot_2021-09-16_12.04.19PM.png
  16349   Mon Sep 20 20:43:38 2021 TegaUpdateElectronicsSat Amp modifications

Running update of Sat Amp modification work, which involves the following procedure (x8) per unit:

  1. Replace R20 & R24 with 4.99K ohms, R23 with 499 ohms, and remove C16.
  2. (Testing) Connect LEDDrive output to GND and check that
    • TP4 is ~ 5V
    •  TP5-8 ~ 0V. 
  3. Install 40m Satellite to Flange Adapter (D2100148-v1)


Unit Serial Number Issues Status
S1200740 NONE DONE
S1200742 NONE DONE
S1200743 NONE DONE

TP4 @ LED1,2 on PCB S2100568 is 13V instead of 5V

TP4 @ LED4 on PCB S2100559 is 13V instead of 5V

S1200752 NONE DONE




Attachment 1: IMG_20210920_203456226.jpg
  16356   Wed Sep 22 17:22:59 2021 TegaUpdateElectronicsSat Amp modifications

[Koji, Tega]


Decided to do a quick check of the remaining Sat Amp units before component replacement to identify any unit with defective LED circuits. Managed to examine 5 out of 10 units, so still have 5 units remaining. Also installed the photodiode bias voltage jumper (JP1) on all the units processed so far.

Unit Serial Number Issues Debugging Status

TP4 @ LED3 on chan 1-4 PCB was ~0.7 V instead of 5V

Koji checked the solder connections of the various components, then swapped out the IC OPAMP. Removed DB9 connections to the front panel to get access to the bottom of the board. Upon close inspection, it looked like an issue of a short connection between the Emitter & Base legs of the Q1 transistor.

Solution - Remove the short connection between the Emitter & Base legs of the Q1 transistor legs.

S1200748 TP4 @ LED2 on chan 1-4 PCB was ~0.7 V instead of 5V

This issue was caused by a short connection between the Emitter & Base legs of the Q1 transistor.

Solution - Remove the short connection between the Emitter & Base legs of the Q1 transistor legs.

S1200749 NONE N/A DONE
S1200750 NONE N/A DONE
S1200751 NONE N/A DONE


Defective unit with updated resistors and capacitors in the previous elog

Unit Serial Number Issues Debugging Status

TP4 @ LED1,2 on PCB S2100568 is 13V instead of 5V

TP4 @ LED4 on PCB S2100559 is 13V instead of 5V

This issue was caused by a short between the Collector & Base legs of the Q1 transistor.

Solution - Remove the short connection between the Collector & Base legs of the Q1 transistor legs


Complications - During the process of flipping the board to get access to the bottom of the board, a connector holding the two middle black wires, on P1, came loose. I resecured the wires to the connector and checked all TP4s on the board afterwards to make sure things are as expected.






Running update of Sat Amp modification work, which involves the following procedure (x8) per unit:

  1. Replace R20 & R24 with 4.99K ohms, R23 with 499 ohms, and remove C16.
  2. (Testing) Connect LEDDrive output to GND and check that
    • TP4 is ~ 5V
    •  TP5-8 ~ 0V. 
  3. Install 40m Satellite to Flange Adapter (D2100148-v1)


Unit Serial Number Issues Status
S1200740 NONE DONE
S1200742 NONE DONE
S1200743 NONE DONE

TP4 @ LED1,2 on PCB S2100568 is 13V instead of 5V

TP4 @ LED4 on PCB S2100559 is 13V instead of 5V

S1200752 NONE DONE





  16357   Thu Sep 23 14:17:44 2021 TegaUpdateElectronicsSat Amp modifications debugging update

Debugging complete.

All units now have the correct TP4 voltage reading needed to drive a nominal current of 35 mA through to OSEM LED. The next step is to go ahead and replace the components and test afterward that everything is OK.


Unit Serial Number Issues Debugging Status
S1200736 TP4 @ LED4 on chan 1-4 PCB reads 13V instead of 5V

This issue was caused by a short between the Collector & Base legs of the Q1 transistor.

Solution - Remove the short connection between the Collector & Base legs of the Q1 transistor legs

S1200737 NONE N/A DONE
S1200739 NONE N/A DONE
S1200746 TP4 @ LED3 on chan 5-8 PCB reads 0.765 V instead of 5V

This issue was caused by a short between the Emitter & Base legs of the Q1 transistor.

Solution - Remove the short connection between the Emitter & Base legs of the Q1 transistor legs


Complications - I was extra careful this time because of the problem of loose cable from the last flip-over of the right PCB containing chan 5-8. Anyways, after I was done I noticed one of the pink wires (it carries the +14V to the left PCB) had come off on P1. At least this time I could also see that the corresponding front panel green LED turn off as a result. So I resecured the wire to the connector (using solder as my last attempt yesterday to reattach the via crimping didn't work after a long time trying. I hope this is not a problem.) and checked the front panel LED turns on when the unit is powered before closing the unit. These connectors are quite flimsy.

S1200747 TP4 @ LED2 on chan 1-4 PCB reads 13V instead of 5V

This issue was caused by a short between the Collector & Base legs of the Q1 transistor.

Solution - Remove the short connection between the Collector & Base legs of the Q1 transistor legs





  16379   Mon Oct 4 21:58:17 2021 TegaUpdateElectronicsSat Amp modifications

Trying to finish 2 more Sat Amp units so that we have the 7 units needed for the X-arm install. 

S2100736 - All good

S2100737 - This unit presented with an issue on the PD1 circuit of channel 1-4 PCB where the voltage reading on TP6, TP7 and TP8 are -15.1V,  -14.2V, and +14.7V respectively, instead of ~0V.  The unit also has an issue on the PD2 circuit of channel 1-4 PCB because the voltage reading on TP7 and TP8 are  -14.2V, and +14.25V respectively, instead of ~0V.


  16386   Wed Oct 6 16:31:02 2021 TegaUpdateElectronicsSat Amp modifications

[Tega, Koji]

(S2100737) - Debugging showed that the opamp, AD822ARZ, for PD2 circuit was not working as expected so we replaced with a spare and this fixed the problem. Somehow, the PD1 circuit no longer presents any issues, so everything is now fine with the unit.

(S2100741) - All good.


Trying to finish 2 more Sat Amp units so that we have the 7 units needed for the X-arm install. 

S2100736 - All good

S2100737 - This unit presented with an issue on the PD1 circuit of channel 1-4 PCB where the voltage reading on TP6, TP7 and TP8 are -15.1V,  -14.2V, and +14.7V respectively, instead of ~0V.  The unit also has an issue on the PD2 circuit of channel 1-4 PCB because the voltage reading on TP7 and TP8 are  -14.2V, and +14.25V respectively, instead of ~0V.



  16411   Mon Oct 18 16:48:32 2021 TegaUpdateElectronicsSat Amp modifications

[S2100738, S2100745, S2100751] Completed three more Sat Amp units modification with seven remaining.


Attachment 1: IMG_20211018_162918574.jpg
  16427   Tue Oct 26 13:27:07 2021 TegaSummaryElectronicsSat Amp modification Summary

Modifications and testing of SatAmp units COMPLETE. Attachments 1 & 2 show all 19 units, one installed unit and the remaining 18 units are stacked and ready for install. Detailed notes of the modification for each unit are presented in the summary document in the dcc.



Attachment 1: SapAmpModStack.jpg
Attachment 2: SatAmpInstalled.jpg
  16449   Thu Nov 4 18:29:51 2021 TegaUpdateSUSSetting up suspension test model


Today we continued working on setting up the 6 degrees of freedom model for testing the suspension which we copied over from  "/cvs/cds/rtcds/userapps/release/sus/c1/models/c1sup.mdl" to c1sp2.mdl in the same folder. We then changed the host from c1lsc to c1sus2, changed cpu # from 7 to 3 bcos c1sus2 has 6 cores. Then ran the following commands to build and install the model on c1sus2:

$ ssh c1sus2

$ rtcds make c1sp2

$ rtcds install c1sp2

where we encountered the following installation error:

ERROR: This node 62 is already installed as:



The new entry you are trying to write is as follows:



This script will not overwrite existing entries in testpoint.par

If this is an attempt to move an existing system from one host to another,

please remove conflicting entry from testpoint.par file

It seems that changing the model name and host did not change the node allocation, so will remove the previous entries in testpoint.par to see if that helps. After deleting the following lines


from the file "/opt/rtcds/caltech/c1/target/gds/param/testpoint.par", the installation went fine and the above entries were replaced by 


BTW, I now believe the reason we had the node conflict earlier was bcos both models still had the same value of  dcuid=62, so I think changing this value in our model file would be a better solution. Work is ongoing.


  16478   Mon Nov 22 16:38:26 2021 TegaSummaryComputer Scripts / ProgramsSUS Plant Plan for New Optics

[Tega, Ian]


1. Investigate cross-coupling btw the various degrees of freedom (dof) - turn on noise for each dof in the plant model and measure the transfer function of the other dofs.

2. Get a closed-loop transfer function using noise injection and give a detailed outline of the procedure in elog - IN1/IN2 for each TM_RESP filter while the others are turned off.

3. Derive analytic model of the closed-loop transfer functions for comparison.

4. Adapt control filters to fit optimized analytical solutions.

  16495   Thu Dec 9 00:32:56 2021 TegaUpdateCDSNew SUS medm screen update

The new SUS screen can be reached via sitemap -> IFO SUS button -> NEW ETMX dropdown menu link. Please use and provide feedback. Not sure exactly if we need/want the display screens after the IOP model on the right of the medm screen. I have not been able to locate the corresponding channels but did not want to remove them until I was sure that we don't plan to add these features to our screens. When all bugs have been ironed out, we can use appropriate macro substitution for the other optics.

The next feature to add is the BLRMS to the coil and PD channels. I plan to combine the PEM BLRMS medm implementation with the sus_single_BLRMS model block (located in  /opt/rtcds/userapps/release/cds/c1/models). This way we use the latest BLRMS block in "/opt/rtcds/userapps/release/cds/common/models/BLRMS.mdl" whilst also leveraging the previous work done on the sus_single_BLRMS model, which neatly fits into our current SUS model.

Attachment 1: Screen_Shot_2021-12-09_at_12.29.30_AM.png
Attachment 2: Screen_Shot_2021-12-09_at_12.42.35_AM.png
  16496   Thu Dec 9 18:22:36 2021 TegaUpdateCDSNew SUS medm screen update

Work on the medm screen for SUS RMS monitor is ongoing. The next step would be to incorporate this into the SUS medm screen, add the BLRMS model to the SUS controller model, recompile, check that the channels are being correctly addressed, then load the appropriate bandpass and lowpass filters.  

Attachment 1: Screen_Shot_2021-12-09_at_6.21.09_PM.png
  16500   Fri Dec 10 18:55:58 2021 TegaUpdateCDSNew SUS medm screen update

Turns out the BLRMS monitoring channels for MC1, MC2, MC3, ITMY and SRM already exist in c1pem. So I modified the new SUS screen to display the BLRMS info for the aforementioned optics. Next step is to add the BLRMS monitor for PRM, ITMX, ETMX and ETMY. This would require extending the number of inputs for the "SUS" block in c1pem to accomodate the additional inputs from the remaining optics.

Attachment 1: BLRMS_ITMY_screenshot.png
  16503   Mon Dec 13 15:05:47 2021 TegaUpdatePEMgit repo for temp sensor and sus medm

[temperature sensor]

git repo: https://git.ligo.org/40m/tempsensor.git


Update the temp sensor channels to fit with cds format, ie. "C1:PEM-TEMP_EX", "C1:PEM-TEMP_EY", "C1:PEM-TEMP_BS"

- Use FLOAT32_LE data format for the database file (/cvs/cds/caltech/target/c1pem1/tempsensor/C1PEMaux.db) to create the new channels.

- Keep the old datadase code and channels so we can compare with new temp channels afterwards. Also we need a 1-month overlap b4 deleting the old channels.


[sus medm screen]

git repo: https://git.ligo.org/40m/susmedmscreen.git

todo (from talk with Koji)

- Link stateword display to open "C1CDS_FE_STATUS.adl"

- Damp filter and Lock filter buttons should open a 3x1 filter screen so that the 6 filters are opened by 2 buttons compared to the old screen that has 3 buttons connected to 2X1 filter screen

- Make the LOCKIN signla modulation flow diagramlook more like the old 40m screen since that is a better layout

- Move load coefficient button to top of sus medm screen (beside stateword)

- The rectangular red outline around the oplev display is confusing and needs to be modified for clarity

- COMM tag block should not be 3D as this suggests it is a button. Make it flat and change tag name to indicate individual watchdog control as this better reflect its functionality. Rename current watchdog switch to watchdog master is it does what the 5 COMM switches do at once.

- Macro pass need to be better documented so that when we call the sus screens from locations other than sitemap, we should know what macro variables to pass in, like DCU_ID etc.

- Edit sitemap.adl to point only to the new screens. Then create a button on the new screen that points to the old screen. This way, we can still access the old screen without clogging sitemap.

- Move the new screen location to a subfolder of where the current sus screens reside, /opt/rtcds/userapps/trunk/sus/c1/medm/templates

- Rename the overview screen (SUS_CUST_HSSS_OVERVIEW.adl) to use the SUS_SINGLE nomenclature, i.e. SUS_SINGLE_OVERVIEW.adl

- Keep an eye of the cpu usage of c1pem as we add BLRMS block for other optics. 



ELOG V3.1.3-