40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 3 of 341  Not logged in ELOG logo
IDdown Date Author Type Category Subject
  17070   Wed Aug 10 15:33:59 2022 CiciUpdateGeneralWorking Red Pitaya VNA

TL;DR: I am now able to inject a swept sine and measure a transfer function with python on my Red Pitaya! Attached is a Bode plot for a swept sine from 1 - 30 MHz, going through a band pass filter of 9.5 - 11.5 MHz.


  • Spent too long trying to get pyRPL to work, do not recommend. The code on their website has a lot of problems (like syntax-error level problems), and is ultimately designed to open up and start a GUI, which is not what I want even if it did work.
  • Found some code on the git repository of someone at Delft University of Technology, worked better but still not great (oscilloscope/spectrum analyzer functions were alright, but couldn't successfully run a VNA with it, and overcomplicated). Helped me figure out appropriate decimation factors. Realized it was not using the FPGA to get TF data but instead just collecting a lot of time trace data and then taking an FFT in the code to get the TF, which wasn't ideal.
  • Eventually switched to using the Red Pitaya SCPI server to talk to the Red Pitaya myself, successful! I inject a swept sine with a for loop that just cycles through frequencies and takes the transfer function at each one.
    • Was originally getting the transfer function by using scipy.signal.csd() and scipy.signal.welch() to get Pxy and Pxx and dividing, and then just finding the closest point in the frequency spectrum to the frequency I was inserting.
    • Switched to doing IQ demodulation myself: where x(t) is the measurement before the band pass filter and y(t) is the measurement after, taking the mean of (x(t) * cos(2pi*freq)) = a1, mean(x*sin()) = a2, mean(y*cos()) = b1, mean(y*sin()) = b2, and then TF(freq) = (b1 + i b2)/(a1 + i a2).
    • Unfortunately still taking time trace data and then calculating the TF instead of using the FPGA, but I have not found anything online indicating that people are able to get VNA capabilities on the Red Pitaya without collecting and sending all the time trace data... I'm still not sure if that's actually a Red Pitaya capability yet.


To do:

  • Will go take measurements of the AUX laser loop with the RPi! Have a good diagram of when I did it with the SR785 so it shouldn't be too hard hopefully.
  • Figure out how to get coherence data!!
  • Figure out how to get the RPi on the wifi. Right now I'm just plugging the RPi into my computer. Paco and I were working on this before and had trouble finding old passwords... Hopefully will not be too much of a roadblock.
  17069   Tue Aug 9 19:54:31 2022 yutaSummaryLSCFPMI locking tonight

[Tega, Anchal, Yuta]

We resored FPMI locking settings. Below is the summary of locking configurations tonight.
To ease the lock acquisition, the step to feedback POX11_I to ETMX and POY11_I to MC2 before POX and POY mixing was necessary tonight.

 - 0.5 * POX11_I + 0.5 * POY11_I handed to 0.5 * REFL55_I
 - YARM filter module, FM4,5 for acquisition, FM1,2,3,6,8 triggered, C1:LSC-YARM_GAIN = 0.012
 - Actuation on -0.77 * MC2
 - UGF ~ 250 Hz

 - 0.5 * POX11_I - 0.5 * POY11_I handed to 4.6 * AS55_Q (it was 2.5 in 40m/17012)
 - XARM filter module, FM5 for acquisition (no FM4), FM1,2,3,6,8 triggered, C1:LSC-XARM_GAIN = 0.015
 - Actuation on 0.5 * ETMX - 0.5 * ETMY
 - UGF ~ 120 Hz

 - 1 * REFL55_Q (turned on after XARM and YARM acquisition)
 - MICH filter module, FM4,5,8 for acquisition, FM2,3 triggered, C1:LSC-MICH_GAIN = +40
 - Actuation on 0.5 * BS
 - UGF ~ 100 Hz

Measured sensing matrix:
Sensing Matrix with the following demodulation phases
{'AS55': 200.41785156862835, 'REFL55': 93.7514468401475, 'POX11': 105.08325063571438, 'POY11': -11.343909976281823}
Sensors              DARM                    CARM                   MICH
C1:LSC-AS55_I_ERR_DQ 5.27e-02 (-154.105 deg) 2.83e-01 (132.395 deg) 1.17e-04 (-40.1051 deg)
C1:LSC-AS55_Q_ERR_DQ 3.99e-02 (-151.048 deg) 1.42e-02 (125.504 deg) 1.41e-04 (-2.42846 deg)
C1:LSC-REFL55_I_ERR_DQ 5.59e-02 (77.6871 deg) 1.15e+00 (-44.589 deg) 3.55e-04 (69.2585 deg)
C1:LSC-REFL55_Q_ERR_DQ 1.84e-03 (16.3186 deg) 3.35e-03 (125.67 deg) 4.59e-05 (4.18718 deg)
C1:LSC-POX11_I_ERR_DQ 1.54e-01 (-157.852 deg) 6.07e-01 (-42.1078 deg) 5.55e-05 (73.3963 deg)
C1:LSC-POX11_Q_ERR_DQ 6.83e-05 (-148.591 deg) 6.37e-04 (121.983 deg) 1.35e-06 (43.7201 deg)
C1:LSC-POY11_I_ERR_DQ 1.85e-01 (36.1624 deg) 5.73e-01 (-43.1776 deg) 2.12e-04 (82.16 deg)
C1:LSC-POY11_Q_ERR_DQ 2.16e-05 (130.937 deg) 6.38e-05 (-173.194 deg) 1.40e-06 (47.5416 deg)

FPMI locked periods:
  - 1344129143 - 1344129520
  - 1344131106 - 1344131305
  - 1344133503 - 1344134020

- Restore CM servo for CARM

  17068   Tue Aug 9 15:50:22 2022 KojiUpdateBHDBHD fringe contrast improved from 43% to 74%

For both 40m/17020 and 40m/17024, what does the contrast mean if the numbers are leaking out to ~-100cnt?
Also how much is it if you convert this contrast into the mode matching?

  17067   Tue Aug 9 15:33:12 2022 yutaUpdateBHDBHD fringe contrast improved from 43% to 74%

[Anchal, Yehonathan, Yuta]

We did the constrast measurement with the method same as 40m/17020.
Contrast between ITM single bounce and LO beam increased to 74% (we had 43% before unclipping LO beam in 40m/17056).
From equations in 40m/17041 and measured ITM sigle bounce power (93 or 138 counts @ BHD DCPD) and LO power (130 or 124 counts @ BHD DCPD) from 40m/17056,  expected visibility for perfectly mode-matched case is 99%.
Measured constrast of 74% indicate mode-matching of 56%.

Both arms locked, MICH fringe (20% percentile)
Contrast measured by C1:LSC-ASDC_OUT is 80.66 +/- 0.20 %
Contrast measured by C1:LSC-POPDC_OUT is 92.27 +/- 0.66 %
Contrast measured by C1:LSC-REFLDC_OUT is 89.59 +/- 0.84 %
Contrast measured by all is 87.51 +/- 1.69 %

Both arms misaligned, MICH fringe (20% percentile)
Contrast measured by C1:LSC-ASDC_OUT is 82.50 +/- 0.61 %
Contrast measured by C1:LSC-POPDC_OUT is 94.18 +/- 0.26 %
Contrast measured by C1:LSC-REFLDC_OUT is 92.78 +/- 0.19 %
Contrast measured by all is 89.82 +/- 1.75 %

ITMX-LO fringe (40% percentile)
Contrast measured by C1:HPC-DCPD_A_OUT is 73.93 +/- 1.52 %
Contrast measured by C1:HPC-DCPD_B_OUT is 73.56 +/- 1.22 %
Contrast measured by all is 73.74 +/- 0.98 %

ITMY-LO fringe (40% percentile)
Contrast measured by C1:HPC-DCPD_A_OUT is 73.45 +/- 0.61 %
Contrast measured by C1:HPC-DCPD_B_OUT is 75.27 +/- 0.50 %
Contrast measured by all is 74.36 +/- 0.54 %

  17066   Mon Aug 8 17:16:51 2022 TegaUpdateComputersFront-end machine setup

Added 3 FE machines - c1ioo, c1lsc, c1sus -  to the teststand following the instructions in elog15947. Note that we also updated /etc/hosts on chiara by adding the names and ip of the new FE since we wish to ssh from there given that chiara is where we land when we connect to c1teststand.

Two of the FE machines - c1lsc & c1ioo - have the 6-core X5680 @ 3.3GHz processor and the BIOS were already mostly configured because they came from LLO I believe. The third machine - c1sus - has the 6-core X5650 @ 2.67GHz processor and required a complete BIOS config according to the doc.

Next Step:  I think the next step is to get the latest RTS working on the new fb1 (tower machine), then boot the frontends from there.

KVM switch note:

All current front-ends have the ps/2 keyboard and mouse connectors except for fb1, which only has usb ports. So we may not be able to connect to fb1 using a ps/2 KVM switch that works for all the current front-ends. The new tower machine does have a ps/2 connector so if we decide to use that as the bootserver and framebuilder, then we should be fine.

  17065   Mon Aug 8 14:47:10 2022 ranaUpdatePSLFSSSlow/MCAutolocker issue (docker)

can't we just go back to the old python script that was working for many years, and tested? I imagine that as soon as someone besides you tries to debug the docker setup, this is what will happen.


Added C1:IOO-MC_LOCK to ALConfigMC.yml which solved the isse with FSS Slow. We should tune the FSS Slow Servo PID coefficients for a better performance.

the C1PSL_SLOW.adl screen is not obsolete. It can be used to change the PID coefficients, engage/disengage the PID loop, monitor the PID script blinker, and monitor FAST actuator value C1:PSL-FSS_FAST. the functionality of this screen has not changed from before.

I've also added a wiki page for scripts documentation.


  17064   Fri Aug 5 17:03:31 2022 YehonathanSummaryGeneralTesting 950nm laser found in trash pile

I set out to test the actuation bandwidth of the 950nm laser. I hooked the laser to the output of the bias tee of PD testing setup. I connected the fiber coming out of the laser to the fiber port of 1611 REF PD.

The current source was connected to the DB9 input of the PD testing setup. I turned on the current source and set the current to 20mA. I measured with a fluke ~ 2V at the REF PD DC port.

I connected the AC port of the bias tee to the RF source of the network analyzer and the AC port of the REF PD to the B port of the network analyzer. Attachment 2 shows the setup.

I took a swept sine measurement (attachment) from 100kHz to 500MHz.

It seems like the bandwidth is ~ 1MHz which is weird considering the spec sheet says that the pulse rise time is 0.5ns. To make sure we are not limited by the bandwidth of the cables I looped the source and the input of the network analyzer using the cables used for the previous measurement and observed that the bandwidth is a few 100s of MHz.

  17063   Fri Aug 5 12:42:12 2022 KojiUpdateIOOIMC WFS: Overnight observation

The IMC lock survived overnight and the WFS servo loops kept it aligned. The IMC was unlocked in the morning.
The left 6 plots are the WFS servo outputs and the right most two plot show the transmission and reflection of the IMC.

If the WFS is making the lock unstable under high seismic conditions, please turn the loops off.


  17062   Thu Aug 4 22:32:31 2022 KojiUpdateIOOUpon leaving the lab (WFS investigation)

Upon leaving the lab:

- HEPA is ON at the original speed (i.e. same speed at 5PM today)

- WFS servo is ON, partly because we want to see how stable it is. It is not handled with the autolocker right now.
So there is a possibility that the WFS servo goes wild and make the IMC totally misaligned (and does not come back)
In such a case, go to the WFS servo screen and push "CH" (clear history) of each servo filters.

  17061   Thu Aug 4 22:14:38 2022 KojiUpdateIOOWFS investigation


Attachment 1: HEPA ON

WFS1/2 PIT/YAW Spectra are stabilized below 1Hz (0.1Hz for WFS1P)

MC2 TRANS PIT is largely contaminated by the other WFS loops.
MC2 TRANS YAW is slightly contaminated but not much compared to the one for pitch.

Attachment 2: HEPA OFF

Again, WFS1/2 PIT/YAW Spectra are stabilized below 1Hz (0.1Hz for WFS1P)

MC2 TRANS PIT is still contaminated but better.
MC2 TRANS YAW is not contaminated.


WFS1/2 signals are largely disturbed when PSL HEPA is ON. Probably the amount of HEPA air flow was not optimized.
Above 1Hz, invacuum suspension are quieter than the beam incident on the IMC.

The dirty WFS signals are fedback to the mirrors. Due the large motion of the beam and also the imperfection of the actuator matrix cause the MC2 spot rather moves than stabilized.

This means that the WFS loops should leave the mirrors untouched above 1Hz i.e. The loop bandwidths should be low (~<0.1Hz). (Yes I know)
However, the simple gain reduction (x10) does make the servos unstable. So more adjustment is necessary. (<-Not for today)

  17060   Thu Aug 4 22:14:20 2022 KojiUpdateIOOWFS investigation

Sensing matrix measurement

MCx_ASCyyy_EXC was shaken with the amplitude of 3000 cnt. Measure the transfer functions to each segment of the WFS I&Q demod outputs.

- Pitch excitations consistently indicated WFS1 SEG2&3 / SEG1&4, and WFS2 SEG 1&2 / SEG 3&4 are the pairs.
- Yaw excitations consistently indicated WFS1 SEG1&2 / SEG3&4, and WFS2 SEG 1&4 / SEG 2&3 are the pairs.

---> WFS1P matrix {1,-1,-1,1}, WFS1Y matrix {1,1,-1,-1}, WFS2P matrix {1,1,-1,-1}, WFS2Y matrix {-1,1,1,-1}

Now look at the servo input. The following lists show the important numbers for the actuation to sensor matrices. The numbers were the measured transfer function between 7~10Hz and the unit is 1/f^2 [cnt/cnt].

CHA:, C1:SUS-MC1_ASCPIT_EXC, CHB:, C1:IOO-WFS1_I_PIT_OUT, -77.4602 +/- 18.4495
CHA:, C1:SUS-MC1_ASCPIT_EXC, CHB:, C1:IOO-WFS2_I_PIT_OUT, -22.6042 +/- 5.289
CHA:, C1:SUS-MC1_ASCPIT_EXC, CHB:, C1:IOO-MC_TRANS_PIT_OUT, -0.0007949 +/- 0.00019046
CHA:, C1:SUS-MC1_ASCYAW_EXC, CHB:, C1:IOO-WFS1_I_YAW_OUT, -60.5557 +/- 14.1008
CHA:, C1:SUS-MC1_ASCYAW_EXC, CHB:, C1:IOO-WFS2_I_YAW_OUT, -206.3526 +/- 47.1332
CHA:, C1:SUS-MC1_ASCYAW_EXC, CHB:, C1:IOO-MC_TRANS_YAW_OUT, 0.00027094 +/- 6.6131e-05

CHA:, C1:SUS-MC2_ASCPIT_EXC, CHB:, C1:IOO-WFS1_I_PIT_OUT, 57.8636 +/- 35.3874
CHA:, C1:SUS-MC2_ASCPIT_EXC, CHB:, C1:IOO-WFS2_I_PIT_OUT, -185.079 +/- 104.679
CHA:, C1:SUS-MC2_ASCPIT_EXC, CHB:, C1:IOO-MC_TRANS_PIT_OUT, 0.00089367 +/- 0.00052603
CHA:, C1:SUS-MC2_ASCYAW_EXC, CHB:, C1:IOO-WFS1_I_YAW_OUT, -349.7898 +/- 202.967
CHA:, C1:SUS-MC2_ASCYAW_EXC, CHB:, C1:IOO-WFS2_I_YAW_OUT, -193.7146 +/- 111.2871
CHA:, C1:SUS-MC2_ASCYAW_EXC, CHB:, C1:IOO-MC_TRANS_YAW_OUT, 0.003911 +/- 0.0023028

CHA:, C1:SUS-MC3_ASCPIT_EXC, CHB:, C1:IOO-WFS1_I_PIT_OUT, 65.5405 +/- 14.305
CHA:, C1:SUS-MC3_ASCPIT_EXC, CHB:, C1:IOO-WFS2_I_PIT_OUT, 78.8535 +/- 17.1719
CHA:, C1:SUS-MC3_ASCPIT_EXC, CHB:, C1:IOO-MC_TRANS_PIT_OUT, -0.00087661 +/- 0.00020837
CHA:, C1:SUS-MC3_ASCYAW_EXC, CHB:, C1:IOO-WFS1_I_YAW_OUT, -130.7286 +/- 29.6898
CHA:, C1:SUS-MC3_ASCYAW_EXC, CHB:, C1:IOO-WFS2_I_YAW_OUT, 129.0654 +/- 28.6328
CHA:, C1:SUS-MC3_ASCYAW_EXC, CHB:, C1:IOO-MC_TRANS_YAW_OUT, -0.00024944 +/- 5.9112e-05

Put these numbers in the matrix calculation and take the inverse for pitch and yaw separately.

We obtained

WFS1P    WFS2P    MCTP    
-4.017   -4.783   -7.306e5   MC1P
 3.611   -5.252   -2.025e5   MC2P
 7.323   -1.017   -6.847e5   MC3P

WFS1Y    WFS2Y    MCTY    
-3.457   -4.532   -5.336e5   MC1Y
-0.1249   0.3826   2.635e5   MC2Y
-5.714    1.076   -4.578e5   MC3Y

Basically we can put these numbers into the output matrix. The last column corresponds to the spot position servo and we want to make this slow.
So used x1e-5 values (i.e. removed e5) instead of these huge numbers.


  17059   Thu Aug 4 21:58:18 2022 KojiUpdateIOOWFS investigation

OK... It seems that all the 6 dof of the IMC WFS servo loops were closed with some condition...

- Measured the transfer functions from ASCPIT/YAW_EXC of each suspensions to WFS segs.
- FInd the proper input matrix for PIT and YAW for WFS1 and WFS2
- Closed loops one by one => This was not so successful because the loop shape was quite conditional.
- Closed WFS1/WFS2 loops one by one only with FM4 (0.8Hz Zero / (100Hz pole)^2). Adjust the gains to have the UGF at a few Hz.

- Found that the separation between WFS1P and WFS2P was not good. This caused instability of these loops when the gains were matched. I ended up lowering the gain of WFS1P by a factor of 10. This made the loop OK to work. FM3 (Integrator below 0.8Hz) worked fine.

- FM9 Rolloff filters (RLP12) makes the loops unstable.

- The MC2 spot loops (MC2_TRANS_PIT/YAW) are supposed to be slow loops. From the time series behavior it looks they are working.

MEDM Snapshots (Attchaments 1~4)

  17058   Thu Aug 4 19:01:59 2022 TegaUpdateComputersFront-end machine in supermicro boxes

Koji and JC looked around the lab today and found some supermicro boxes which I was told to look into to see if they have any useful computers.


Boxes next to Y-arm cabinets (3 boxes: one empty)

We were expecting to see a smaller machine in the first box - like top machine in attachement 1 - but it turns out to actually contain the front-end we need, see bottom machine in attachment 1. This is the same machine as c1bhd currently on the teststand. Attachment 2 is an image of the machine in the second box (maybe a new machine for frambuilder?). The third box is empty.


Boxes next to X-arm cabinets (3 boxes)

Attachement 3 shows the 3 boxes each of which contains the same FE machine we saw earlier at the bottom of attachement 1. The middle box contains the note shown in attacment 4.


Box opposite Y-arm cabinets (1 empty box)


In summary, it looks like we have 3 new front-ends, 1 new front-end with networking issue and 1 new tower machine (possibly a frame builder replacement).

  17057   Thu Aug 4 11:28:22 2022 AnchalUpdatePSLFSSSlow/MCAutolocker issue (docker)

Added C1:IOO-MC_LOCK to ALConfigMC.yml which solved the isse with FSS Slow. We should tune the FSS Slow Servo PID coefficients for a better performance.

the C1PSL_SLOW.adl screen is not obsolete. It can be used to change the PID coefficients, engage/disengage the PID loop, monitor the PID script blinker, and monitor FAST actuator value C1:PSL-FSS_FAST. the functionality of this screen has not changed from before.

I've also added a wiki page for scripts documentation.

  17056   Wed Aug 3 16:00:51 2022 yutaUpdateBHDBHD fringe aligned with reduced LO and AS beam clipping

Last week, we could find an alignment which realizes LO beam and AS beam both unclipped, but it was not consistent with an alignment which realize BHD fringe (40m/17046).
Today, we tweaked the alignment of SR2, AS1, AS4 to have BHD fringe with reduced LO and AS beam clipping.
AS beams on AP table and BHD both still look clipped, but much better now.
Ideally, SR2 and AS1 will unclip AS beam, and LO1, LO2, AS4 would make BHD fringe, but it is hard right now since LO beam seem to have little room and LO2 have little actuation range.
BHD optics on ITMY table, including camera, and AS55/ASDC were realigned after the aglinment work (Note that DCPD_A path have a pick-off for camera path, and this pick-off mirror have quite significant incident angle dependence of R/T ratio).

Current alignment scheme:
Current alignment scheme I figured out is the following.
 - Check Y green. If it is transmitted at good spot on GTRY camera, Yarm is OK. If not, tweak ITMY/ETMY. alignment.
 - Mis-align AS4, align TT1, TT2, LO1 to have DCPD_A_OUT of ~130 and DCPD_B_OUT of ~125.
 - Align PR3, PR2 to maximize TRY_OUT to ~1.05.
 - Tweak ITMY/ETMY if the beam spot on them are not good.
 - Align BS, ITMX to have good MICH fringe and TRX_OUT to ~1.1.
 - Tweak ITMX/ETMX if the beam spot on them are not good.
 - Misalign ETMY, ETMX, ITMY to have LO-ITMX fringe in BHD DCPDs, and align AS beam with SR2 and AS4 differentially, with ratio of AS4/SR2=3.6.

DC PD values in various configurations:
Both arms locked with POX/POY, MICH free, PRM/SRM misaligned

                          Mean     Max      Min
C1:IOO-MC_TRANS_SUM :     14088.57 13947.52 14167.04
C1:LSC-ASDC_OUT16 :           0.16    -0.02     0.34
C1:LSC-POPDC_OUT16 :        369.34   -74.88   854.34
C1:LSC-REFLDC_OUT16 :         0.03    -0.00     0.06
C1:LSC-TRY_OUT16 :            1.00     0.95     1.04
C1:LSC-TRX_OUT16 :            1.07     1.04     1.08

Only LO beam to BHD DCPDs
                          Mean     Max      Min
C1:IOO-MC_TRANS_SUM :     14121.32 14057.71 14159.38
C1:HPC-DCPD_A_OUT16 :       129.80   128.37   130.68 (Consistent with, 40m/17046. Power as expected within 20%. Squashed shape)
C1:HPC-DCPD_B_OUT16 :       123.42   121.92   124.48

ITMX single bounce (ITMY, ETMX, ETMY, PRM, SRM, LO misalgined)
                          Mean     Max      Min
C1:IOO-MC_TRANS_SUM :     14105.13 14000.89 14171.91
C1:HPC-DCPD_A_OUT16 :        92.54    91.45    93.30 (Consistent with 40m/17040, Power as expected within 40%. Clipped to the left in camera)
C1:HPC-DCPD_B_OUT16 :       137.70   136.55   138.53 (Note that DCPD_A/B ratio is different from LO, due to BHD BS R/T unbalance; 40m/17044)
C1:LSC-ASDC_OUT16 :           0.10     0.09     0.10 (Power as expected 40m/16952. Clipped to the right in camera)
C1:LSC-POPDC_OUT16 :        309.19   288.93   327.10 (Power as expected within 30% 40m/17042.)
C1:LSC-REFLDC_OUT16 :         0.02     0.01     0.02

ITMY single bounce (ITMX, ETMX, ETMY, PRM, SRM, LO misalgined)
                          Mean     Max      Min
C1:IOO-MC_TRANS_SUM :     14112.09 14025.37 14154.51
C1:HPC-DCPD_A_OUT16 :        92.58    92.01    93.26
C1:HPC-DCPD_B_OUT16 :       137.68   136.81   138.27
C1:LSC-ASDC_OUT16 :           0.10     0.09     0.10
C1:LSC-POPDC_OUT16 :        308.48   290.49   319.73
C1:LSC-REFLDC_OUT16 :         0.02     0.01     0.02

MICH fringe only (ETMX, ETMY, PRM, SRM, LO misalgined)
                          Mean     Max      Min
C1:IOO-MC_TRANS_SUM :     14090.34 13979.15 14143.86
C1:HPC-DCPD_A_OUT16 :       325.60    91.92   714.57
C1:HPC-DCPD_B_OUT16 :       400.27    18.37   762.57
C1:LSC-ASDC_OUT16 :           0.19    -0.05     0.41
C1:LSC-POPDC_OUT16 :        595.66  -119.21  1334.11
C1:LSC-REFLDC_OUT16 :         0.03    -0.01     0.07

LO-ITMX fringe only (ITMY, ETMX, ETMY, PRM, SRM misalgined)
                          Mean     Max      Min
C1:IOO-MC_TRANS_SUM :     14062.58 13968.05 14113.67
C1:HPC-DCPD_A_OUT16 :       224.31    89.57   371.66
C1:HPC-DCPD_B_OUT16 :       259.74    85.37   421.86

 - Measure contrast (40m/17020) and estimate mode-matching of LO-AS again (40m/17041)
 - Now that we have better LO-AS fringe, lock LO phase in MICH (40m/17037)
 - Now that Dolphin issue was fixed, try double-demodulation to lock LO phase

  17055   Wed Aug 3 15:01:13 2022 KojiUpdateGeneralBorrowed Dsub cables

Borrowed DSUB cables for Juan's SURF project

- 2x D25F-M cables (~6ft?)

- 2x D2100103 ReducerCables

  17054   Tue Aug 2 17:25:18 2022 TegaConfigurationBHDc1sus2 dolphin IPC issue solved

[Yuta, Tega, Chris]

We did it!laugh

Following Chris's suggestion, we added "pciRfm=1" to the CDS parameter block in c1x07.mdl - the IOP model for c1sus2. Then restarted the FE machines and this solved the dolphin IPC problem on c1sus2. We no longer see the RT Netstat error for 'C1:HPC-LSC_DCPD_A' and 'C1:HPC-LSC_DCPD_B' on the LSC IPC status page, see attachement 1.

Attachment 2 shows the module dependencies before and after the change was made, which confirms that the IOP model was not using the dolphin driver before the change.

We encountered a burt restore problem with missing snapfiles from yesterday when we tried restoring the EPICS values after restarting the FE machines. Koji helped us debug the problem, but the summary is that restarting the FE models somehow fixed the issue.

Log files:
Request File list:
Snap files location:
Autoburt crontab on megatron:
19 * * * * /opt/rtcds/caltech/c1/scripts/autoburt/autoburt.cron > /opt/rtcds/caltech/c1/burt/burtcron.log 2>&1
  17053   Tue Aug 2 01:10:26 2022 KojiUpdateIOOWFS investigation

Continued to work on the WFS repair

Demod phase adjustment:

- Use the PDH signal to adjust the demodulation phase to have uniform signals between the segments.

- Excited laser frequency at 1234Hz by injecting 10mVpp into IMC Servo Board IN2. The input was enabled on the MC Servo screen and given the input gain of 0dB.

- Looked at the ~real time spectrum in WFS1/2 SEG1/2/3/4 I&Q after the phase rotators. Changed the demod phases 1) to have ~0deg transfer function between C1:IOO-MC_F to C1:IOO-WFSi_Ij 2) to minimize the freq signal in Q phases.
(See Attachment 1)

- Resulting change of the demod phases:

WFS1 SEG1  52.0 -> 38.0deg
WFS1 SEG2  54.0 -> 53.0deg
WFS1 SEG3  16.6 -> 33.2deg
WFS1 SEG4 103.9 ->-37.1deg

WFS2 SEG1  17.0 -> 57.8deg
WFS2 SEG2  26.6 -> 51.5deg
WFS2 SEG3  24.5 -> 44.0deg
WFS2 SEG4 -58.0 ->103.7deg

SEG4 of both WFSs had significant phase rotation. A quick check of the power spectrum indicates that the Q signals have significantly (<x1/10) lower signals (Attachment 2/3/4). So that's good.

Transfer function measurement

Now the ASCPIT/ASCYAW of the MC1/2/3 suspension were excited and the transfer functions to WFS1/2 SEG1/2/3/4 and MC Trans P/Y were measured. The analysis will come later.

Again here the Q signals have significantly lower sensitivity to the mirror motion. So it is consistent with the above observation of the spectra.

However, the quick check of the transfer functions indicated that the conventional input matrices result in the flipped dependence of the combined error signals in pitch and yaw.
This might indicate that some of the cables were not inserted into the demod board properly although the cables at the demod boards show no indication of anomaly. (See the photos in ELOG 17048)

It might be the case that the cable had been inserted with a special unusual arrangement.

In any case, this can be fixed at the input matrix. Native change of the input matrix made WFS1PIT/WFS1YAW/WFS2PIT/WFS2YAW/MC2Trans YAW servos running (after some adjustment of the servo signs).
The MC2TRANS PIT servo didn't seem to settle and run away no matter which sign is used.

It's probably better to look at the sensing matrix and figure out the proper input/output matrix carefully. So at this moment, no WFSs are working.

Note that I left the new demod phases in the system

During the transfer function measurement some filters were turned off to make the shaking smoother:

IMC ASC filters were turned off to make the FResp flat:

60Hz comb OSEM Input filters were also turned off to make the transfer functions simpler:
- MC1 INPUT FM2 OFF (60Hz comb)
- MC2 INPUT FM2 OFF (60Hz comb)
- MC3 INPUT FM2 OFF (60Hz comb)

cf. Past IMCWFS commissioning http://nodus.ligo.caltech.edu:8080/40m/12684

  17052   Mon Aug 1 18:42:39 2022 TegaConfigurationBHDc1sus2 IPC dolphin issue update

[Yuta, Tega]

We decided to give the dolphin debugging another go. Firstly, we noticed that c1sus2 was no longer recogonising the dolphin card, which can be checked using

lspci | grep Stargen

or looking at the status light on the dolphin card of c1sus2, which was orange for both ports A and B.

We decided to do a hard reboot of c1sus2 and turned off the DAQ chassis for a few minutes, then restared c1sus2. This solved the card recognition problem as well as the 'dis_irm' driver loading issue (I think the driver does not get loaded if the system does not recognise a valid card, as I also saw the missing dis_irm driver module on c1testand). 

Next, we confirmed the status of all dolphin cards on fb1, using

controls@fb1$ /opt/DIS/sbin/dxadmin

It looks like the dolphin card on c1sus2 has now been configured and is availabe to all other nodes. We then restated the all FE machines and models to see if we are in the clear. Unfortunately, we are not so lucky since the problem persisted.

Looking at the output of 'dmesg', we could only identity two notable difference between the operational dolphin cards on c1sus/c1ioo/c1lsc and c1sus2, namely: the card number being equal to zero and the memory addresses which are also zero, see image below.

Anyways, at least we can now eliminate driver issues and would move on to debugging the models next.

  17051   Mon Aug 1 17:19:39 2022 CiciSummaryGeneralRPitaya Data on Jupyter Notebook

Have successfully plotted data from the Red Pitaya on Jupyter Notebook! Have lost years of my life fighting with PyQt. Thanks to Deeksha for heavy contribution. Next task is to get actually good data (seeing mostly noise right now and haven't figured out how to change my input settings) and then to go to set up the RPi in the lab.

  17050   Sat Jul 30 12:48:18 2022 KojiUpdatePSLFSSSlow/MCAutolocker issue (docker)

> it only starts working when C1:IOO-MC_LOCK is 1 and C1:PSL-FSS_SLOWLOOP is 1.

- OK. Your new MCAutolocker does not reflect the lock status to C1:IOO-MC_LOCK. This causes FSS Slow to go crazy when the IMC is not locked. Can you fix that?

- So C1PSL_SLOW.adl screen, which spawns by the "SLOW Servo" button on the FSS screen, has no effect on the FSS SLOW servo anymore. It is obsolete. At least the screen (or the link to the screen) should be removed. (Work on it once you are back.)

- Also, please make a wiki page and copy the description on the previous page.

  17049   Sat Jul 30 10:38:12 2022 AnchalUpdatePSLFSSSlow/MCAutolocker issue (docker)

The FSSSlow script was not properly documented and it was not working, so I had to use one that I knew worked from CTN. This scripts lives in


and uses a configuration file


The script runs all the time inside docker container which keeps it running. The heart-beat blinker shows if the script is active or not, but it only starts working when C1:IOO-MC_LOCK is 1 and C1:PSL-FSS_SLOWLOOP is 1. The second channel is a button on C1PSL_SLOW screen to engage autolocker. It has to be turned on for FSS to work.


docker instructions:

The following message is displayed on login in optimus:

This computer runs four services as of Feb 18, 2022 for 40m lab. To check
status of these services, type
> sudo docker ps
For restarting a particular service, type:
> sudo docker restart container_name
where container name can be found from ps command above.
Fimilarly, to check status of a service, type:
> sudo docker logs container_name

In case, you have just rebooted the machine, to start these services do
> cd /opt/rtcds/caltech/c1/Git/40m/softchansmodbus
> sudo docker-compose up -d
> cd /opt/rtcds/caltech/c1/Git/40m/scripts
> sudo docker-compose up -d

To stop the docker services completely, for example before a reboot, do
> cd /opt/rtcds/caltech/c1/Git/40m/scripts
> sudo docker-compose down
> cd /opt/rtcds/caltech/c1/Git/40m/softchansmodbus
> sudo docker-compose down

This should remove all active containers from the computer.

To check IP address of running containers, type:
> sudo docker inspect -f '|| {{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}   ||   {{.Name}} ||' $(sudo docker ps -aq)

The softchansmodbus directory runs modbusEPICS docker image to host some
useful soft EPICS channels. The scripts directory runs pyep docker
image to run MC autolocker, PMC autolocker and FSS PID locker.

For checking log files of autolocker script, on optimus do:

sudo docker logs scritps_AL_MC_1

For checking log files of FSS PID loop, on optimus do:

sudo docker logs scripts_PID_

In the above commands, add < | tail -15> to just see the most recent 15 lines in the log file. change 15 to whatever number of lines you want to see from the end.

At any time, if you want to know how docker is running stuff, check out the /opt/rtcds/caltech/c1/Git/40m/scriptsdocker-compose.yml file for self-explanatory script usage.

I'll add some documentation on the wiki soon. That is indeed required and should have been done already.

Debugging scripts:

All scripts could be debugged by running them on rossa by directly using python command. You can stop the docker container on optimus using:

sudo docker stop container_name

and then run the file on rossa to check it's behavior. After debugging and fixing any issues, please commit the file to gitlab repo and go back to optimus and restart the docker container:

sudo docker restart container_name

I'll add this procedure to a wiki page as well.

Reverting back to systemd on megatron

The setup on megatron was not removed at all. All service files exist in same place and old scripts can be started in the old manner by doing following on megatron:

For FSSSlow:

sudo systemctl enable FSSSlow
sudo systemctl restart FSSSlow

For MC autolocker:

sudo systemctl enable MCautolocker
sudo systemctl restart MCautolocker

For diabling these services again, do:

sudo systemctl stop FSSSlow
sudo systemctl disable FSSSlow
sudo systemctl stop MCautolocker
sudo systemctl disable MCautolocker

Note that one should stop docker containers on optimus before starting these systemd services to avoid conflicting scripts running together.

I have added above instructions on megatron motd. So on loging into megatron, these updated instructions would come.

If someone wants to fix the old scripts and use systemd for managing those scripts, please do so but I won't be able to help in debugging those old scripts. The shell scripts are very complicated and beyond my knowledge and python scripts are lacking documentation.

I'm happy to help debug or extend the functionality of the new scripts that live in the git directory.

  17048   Fri Jul 29 22:37:54 2022 KojiUpdateIOOWFS investigation

I wanted to check what's wrong with the WFS.

I played with MC2 misalignment to check the error signals.
MC2 pitch and yaw misalignment optically produce a vertical translation and horizontal rotation of the cavity axis at the waist, respectively. So it is thought to be a more separated excitation of the cavity axis.
Then I noticed that WFS2 error signals in general has high (~100%) pitch-yaw coupling. So it was suspicious.

I went to the rack and found that WFS2 SEG4 RF input (labeled "8") was not completely inserted. (Attachment 1)
It seemed that the LEMO connector or the receptacle didn't latch properly anymore and could be easily pulled.
I gave some elbow grease to fix this but in vain. I ended up to use LEMO-BNC adapters which somehow offered a robust connection.

Desipite the insightful discovery, this was not the intrinsic solution to the issue. I checked the past signal history, but I don't think this loose connection caused the missing signal.

Next, I needed to go a bit deeper. The WFS sensors are supposed to be adjusted to I phase where the PDH signal maximally shows up. And all the segments are supposed to have the same sign in terms of the PDH signal.

I've unlocked the IMC and turned on MC2 tickling. This swept the cavity over the resonances.
WFS1 SEG1I~3I showed about the same waveform, but SEG4 Q shows the PDH signal rather than SEG 4 I.
Then tried the same test for WFS2. The SEG4 I signal has the sign-flipped PDH signal compared to WFS2 SEG1I-SEG3I.

I quickly adjusted the demod phase of WFS1 SEG4 and WFS2 SEG4 to correct them,

WFS1 SEG4 103.9-> -20
WFS1 SEG4 -58  -> 120

This in fact made the pitch and yaw separated but flipped (Pitch signal shows up in WFS1Y and yaw signal shows up in WFS1P. Same for WFS2)

These modifications were reverted upon my leaving.

Now things are much more subtle now. And I need to do a more careful quantitative analysis of the demodulation phases / input matrix / output matrix.

Note: It seems that I had worked on IMCWFS on Dec 21, 2016

  17047   Fri Jul 29 20:21:11 2022 KojiUpdatePSLFSSSlow/MCAutolocker issue (docker)

MCAutolocker/FSSSlow are not properly documented and not properly working.
Tidy up the script and documentation, or bring it back to megatron

I was aware that the FSSSlow was misbehaving since the shutdown upon the July power outage.
- FSS Slow servo did nothing even though the apparent settings in C1:PSL_SLOW screen looked fine and heart beat blinking
- Wanted to restart FSSSlow at megatron. Despite the login message showing how to do it, the system service does not exist anymore, because it was moved somewhere.
- Searched 40m wiki but found no info how to kill and restart it
- Found an elog. It was moved to docker on optimus ELOG 16480 . The restart procedure can only be found here. Please fix all the documentation inconsistency >> Anchal

According to this elog, the following commands need to be run for starting up MCAutolocker and FSSSlow on optimus:

cd /opt/rtcds/caltech/c1/Git/40m/scripts/MC
sudo docker-compose up -d

- Problem continues. Now FSSSlow is running but only when the IMC is locked. It does not stop even when the IMC lock is lost. How can we debug docker thing?
- This is minor but the MCAutolocker log (/opt/rtcds/caltech/c1/scripts/MC/logs/AutoLocker.log) is no longer updated even though MCAutolocker is running. Was it moved somewhere?


  17046   Fri Jul 29 18:24:53 2022 TegaUpdateBHDLO beam power improved by factor of 6 after LO and AS beam alignment

[Yuta, Tega]

From our previous work (elog 17044) of shaking PR2 and seeing a signal in DCPD_A and the fact that LO beam power is far smaller than the expected nominal value, we decided to use TT1 and TT2 to realign the LO beam. This resulted in LO beam power going up by a factor of 6 and an improvement in the LO beam shape. We are still unable to find LO and AS alignment which realize BHD fringe with no clipping everywhere.

Deformed LO beam issue: Following the TT1 and TT2 alignments, used PR2 and PR3 to recover the transmission of the X and Y arms to 1. We also used LO1 and LO2 offsets to further reduce the beam deformation by eliminating the HOM concentric fringes that surounded the LO beam and to maximize the DCPD outputs. BHD optics in ITMY table was tweaked a lot to keep the LO beam centered on the BHD DCPDs and camera. The improved LO beam is still astigmatic in the yaw direction but at least now looks like a TEM00 mode. We also repositioned the DCPD_A path camera lens to remove the circular diffused fringes due to lens clipping. After the alignment, power was measured to be the following. It also reduced the coherence between DCPD outputs and suspension motions (see attached).

                       LO         ITMX
C1:HPC-DCPD_A_OUT16    +127.50    +96.24 (ITMX single bounce consistent to 40m/17040)
C1:HPC-DCPD_B_OUT16    +120.51    +141.52
Power at viewport A    504 uW (almost as expected 40m/17040)
Power at viewport B    385 uW

AP table AS beam clipping: We also noticed clipping in the AS beam in AP table which we removed by moving SR2 and AS1 in YAW and then used AS4 to keep the BHD AS beam centered in the BHD DCPDs.

BHD fringe: After overlaping the LO and AS beams, we saw diagonal fringes indicating beam tilt of LO wrt AS, so we tried to remove the AS beam tilt using AS1 and AS4 but failed to do so because the AS4 mirror seemed to completely distort the beam, so intead we decided to use SR2 and AS1 to remove the tilt between LO and AS beams, which realized BHD fringe. But the motion of SR2 and AS1 then moved the AS beam that it is no longer seen in AP table. The alignment to realize LO and AP AS beam without clipping, and that to realize BHD fringe are attached.

  17045   Thu Jul 28 20:16:26 2022 AnchalUpdateBHDShaking test for LO beam AS beam to BHD DCPDs

Some insights from the inside vacuum situation:

  • The beam is an incident near normal on PR2 close to the center of the optic. It wasn't hard to align this part, I'm very confident that we aligned it to the center of PR2. So I do not think the LO beam is ghost beam from PR2.
  • The place that is most susceptible to clipping is POP_SM5 mirror in front of LO1. The LO beam has little clearance from the edge of the mirror.
  • Another possibility of clipping in LO beam is through the cage of LO2. LO2 is a 45-degree incidence mirror, so it is possible we are clipping off the cage or seeing a ghost beam mixed in LO beam here.
  • The fact that moving PR2 is affecting LO beam is weird but doesn't necessarily mean it is a ghost from PR2.
  17044   Thu Jul 28 16:51:55 2022 TegaUpdateBHDShaking test for LO beam AS beam to BHD DCPDs

[Yuta, Tega, Yehonathan]

To investigate the BHD power imbalance and clipping issues, we did some shaking test of the mirrors in the LO path and AS paths. The results suggests the following:

  • The clipping is happening after the BHD BS in DCPD_A path, as opposed to our initial guess of BHD BS transmission clipping in elog 17040.
  • The LO beam we are seeing is probably a ghost beam from PR2

We performed both PIT and YAW shaking of all mirrors and looked at the output at DCPD_A and DCPD_B, see table below for details. Since we only see the dithering signal in DCPD_A, it suggests that the clipping is ocurring after the BHD BS and is also confined to the path between BHD BS and DCPD_A. We also swapped the camera location from DCPD_A to DCPD_B on ITMY table and confirmed that the beam was clipped for DCPD_A but not for DCPD_B.

This result discounts the possiblity of clipping being responsible for the power imbalance and therefore suggests that the power imbalance may actually be due to BHD BS not being 50:50. From the measurement in elog 17040, the transmission of BHD BS is 44\pm0.3% and the reflectivity is 56\pm0.3%. Note that DCPD_A is the transmission of BHD BS for AS beam, whereas DCPD_B is the reflection of BHD BS for AS beam, elog 16932.

We expect the shaking of PR2 to give no signal in either DCPD_A or DCPD_B when the LO beam is purely in trasmission, however, we see a signal in DCPD_A sugesting that the LO beam transit path through PR2 may not be as expected, i.e. the beam might be exiting the side of PR2 instead of the AR coated surface.

Finally, we measured the coherence between the dithering dof and DCPD_A/B & POP, see attachment 2, where we noticed that both DCPD_A/B have high coherence in the 1Hz-10Hz frequency band whereas ther was no coherence in POP as expected. This suggests that there may also be some small clipping in DCPD_B path.


LO Beam Shaking (LO1, LO2, PR2):

color OPTIC DOF Freq OSC Amp (cnts) comment
Black       0 Reference
Blue LO1 YAW 304.4 2000

Signal in DCPD_A & No signal in DCPD_B

Orange LO1 PIT 304.4 2000 No signal
Magenta LO2 YAW 312.2 10000 No signal
Purple LO2 PIT 312.2 10000 Signal in DCPD_A & No signal in DCPD_B
Green PR2 YAW 308.8 20000 Signal in DCPD_A & No signal in DCPD_B
Red PR2 PIT 308.8 20000 Signal in DCPD_A & No signal in DCPD_B


AS Beam Shaking (AS1 and AS4)

color OPTIC DOF Freq OSC Amp (cnts) comment
Black       0 Reference
Blue AS1 YAW 305.5 2000

Signal in DCPD_A & No signal in DCPD_B

Orange AS1 PIT 305.5 2000 Signal in DCPD_A & No signal in DCPD_B
Magenta AS4 YAW 313.3 2000 Signal in DCPD_A & No signal in DCPD_B
Purple AS4 PIT 313.3 2000 No signal



  17043   Thu Jul 28 15:11:59 2022 KojiUpdateCDSToo huge script_archive

As a result of the following work, the file volume of /cvs/cds was reduced from 3.2TB to 2.2TB, and /opt/rtcds/caltech/c1/scripts was reduced from 10GB to 1.5GB

/cvs/cds/caltech/scripts_archive was cleaned up. Now the archive files are reduced to have:

  • every month 1st day from 2005 to 2018/12
  • every ten days (1, 11, 21) for 2019 and 2020
  • everyday for 2021 and 2022

(scripts)/MEDMtab/image was deleted. I can be restore back from one of the script_archive files.

(scripts)/MC/logs/AutoLocker.log was just deleted and refreshed. For the past settings, we can refer autoburt snapshots or script_archive files.


  • It turned out that the frequency of the check was reduced to once per 10min on Sep 9th, 2021 (unelogged activity).
  • The volume of the text since then was not much volume. So I deleted the lines before this date. And the file size is <7MB now.

(scripts)/ZI was moved to /cvs/cds/apps


  • 2018, 2019, 2020 snapshots were archived in tar.gz.
  • These snapshots were then deleted


  17042   Thu Jul 28 14:34:40 2022 YehonathanUpdateBHDLO beam power at BHD DCPDs is significantly lower than expected

{Yuta, Yehonathan}

We went to the BS table to check the POP beam power. We first notice that the POP beam has a nice gaussan profile on the viewing card. We traced it the beam to the viewing port and measured the power there. Before measuring the power we misalign ITMY/ITMX to get rid of interferences. We measure the beam to be 205uW in both cases.

The expected power is

950 mW * 0.9 (IMC transmission?) * 5.637%(PRM) * 97.8%(PR2) * 50%(BS) * 98.6%(ITM) * 50%(BS)  * 2.2%(PR2) = 260uW

which is reasonably close to what we measure which confirms that PR2 transmission is around what we think it is.

This strengthen our suspicion that LO beam gets clipped somewhere.


We also improved the clipping on the POP camera by one of the beamsplitters along the beam path and the alignment to the POPDC PD (~100 cts before, ~ 1000 cts after).


  17041   Thu Jul 28 13:09:28 2022 yehonathanUpdateBHDMode matching considerations

The LO beam was found to have a power of 60uW, 10% of the power expected. We are pretty sure about the expectation because the AS beam has a power of 300uW, roughly the expected power. Additionally, the visibility of the MICH fringes in the BHDR is 40%.

If the mode-matching is perfect then we expect the visibility to be \text{VIS}=\frac{I_\text{max}-I_\text{min}}{I_\text{max}+I_\text{min}}=\frac{2\sqrt{I_\text{LO}I_\text{AS}}}{I_\text{LO}+I_\text{AS}}=\frac{2\sqrt{300\cdot 60}}{300+600}

which is roughly 74.5%.

If there is some mode-mismatch one can show that the visibility is \text{VIS}=\frac{2\sqrt{M}\sqrt{I_\text{LO}I_\text{AS}}}{I_\text{LO}+I_\text{AS}}, where M=\left|\frac{\int \left(E_\text{LO}^\star E_\text{AS} \right)\mathrm{d}x \mathrm{d}y}{\sqrt{I_\text{LO}I_\text{AS}}}\right|^2 is the mode-mismatch.

Using Finesse model I calculated \sqrt(M)=0.93 in the MICH configuration so the expected visibility is around 70%, far away from the observed 40%. To explain the observed visibility the mode mismatch would have to be ~ 30% which is very unlikely.

So it could either be a ghost beam or that the LO beam is clipped so badly that it also degrades its phase front (and therefore the mode-matching). The fact that we see fringes on the LO beam might suggest knife edge clipping on one of the auxiliary optics in the BS chamber.

  17040   Wed Jul 27 18:30:50 2022 yutaUpdateBHDLO beam power at BHD DCPDs is significantly lower than expected

[Paco, Yehonathan, Yuta]

We measured power and counts at BHD DCPDs with LO beam only and ITM single bounce.
We found that LO beam power is ~7 times less than the expected.
We also confirmed that AS beam is clipped somewhere inside vacuum and have 20-50% less power compared with the expected.
LO/AS beams going to DCPD A and B also have power imbalance by 30-40%.

What we did:
 - Run LSCoffsets.py to zero the offsets. I modified the old script so that it can handle new BHD PDs. Also, a bug was fixed (it didn't take into account the gains in filer modules, so INMON is now used instead of OUT16 for calculating offsets).
 - Measured powers and counts in BHD DCPDs at ITMY table with LO beam only and ITMX/ITMY single bounce.
 - During the measurement, we found that power into DCPD A and DCPD B are quite different. One of the reason was a lens and an iris right after the viewport for A path. We removed both of them. Also, only A path have a pickoff which picks off ~20% of light to BHD camera (called SRMF; 40m/16880).
 - We also found that LO beam shape is ugly. ITM single bounce beam from X and Y have similar clipping (see Attached photos). We tried to reduce clipping with various suspensions (LO1, LO2, AS1, AS4, SR2, SRM, BS, ITMX, PR2), but was not possible by moving only single suspension.

 - Result of counts and power measurements are as follows. Power was measured right in front of DCPD, and also right after the viewport to estimate the loss in the in-air paths. Note that LSC channels have gain of 1, but HPC channels have gain of -1.9 for DCPD_A and -1 for DCPD_B.

                       Blocked  LO       ITMX      ITMY    
C1:LSC-DCPD_A_OUT16    -0.01    -17.89    -91.62    -86.21    
C1:LSC-DCPD_B_OUT16    +0.06    -17.72   -131.83   -131.98    
C1:HPC-DCPD_A_OUT16    +0.07    +34.12   +174.63   +164.24    
C1:HPC-DCPD_B_OUT16    +0.13    +17.60   +131.31   +131.49    
Power at DCPD_A        19 uW    63 uW    278 uW    290 uW    
Power at DCPD_B        19 uW    65 uW    393 uW    404 uW    
Power at viewport A    -- uW    82 uW    350 uW    337 uW    
Power at viewport B    -- uW    64 uW    436 uW    431 uW

DCPD calibration:
 - From the measurements above, counts/W in IN1 can be calculated as follows. Offset of 19 uW is substracted from the measured power to take into account for background light.

C1:LSC-DCPD_A_IN1     -3.59e+05 counts/W
C1:LSC-DCPD_B_IN1     -3.61e+05 counts/W
C1:HPC-DCPD_A_IN1     -3.60e+05 counts/W
C1:HPC-DCPD_B_IN1     -3.57e+05 counts/W

 - DCPD calibration shows that DCPD to ADC itself is quite balanced within 1%. A factor of 1.8-1.9 seen was from unbalanced light between A path and B path (40m/17037).
 - Power expected for ITM single bounce to one of DCPDs is ~520 uW, but was 350-430 uW as measured right after the viewport. Power at A is significantly less than that for B. Note that power at AS55 was as expected (40m/16952). Also, clipping cannot be reduced by moving suspensions. These could mean that clipping is happening after AS2.

950 mW * 0.9 (IMC transmission?) * 5.637%(PRM) * 97.8%(PR2) * 50%(BS) * 98.6%(ITM) * 50%(BS) * 10%(SRM) * 90%(AS2) * 50%(BHDBS) = 520 uW

 - Power expected for LO beam to one of DCPDs is ~530 uW, but was 60-80 uW as measured right after the viewport. Power at A is significantly more than that for B, which is opposite for ITM single bounce. This could mean that something is happening at BHDBS? We are not sure why the power is so low. Are we seeing some ghost beam? For PR2 transmission, 22000 ppm was used for calculation, from 40m/16541.

950 mW * 0.9 (IMC transmission?) * 5.637%(PRM) * 2.2%(PR2) * 50%(BHDBS) = 530 uW

 - As far as we remember, beam shapes were not as bad when we closed out the chambers...

 - Check if measured power explains the visitivity of LO-ITM single bounce (40m/17020)
 - If not, what is the mode mismatch? Is it possible to explain the mode mismatch with deviations from designed mode-matching telescope?
 - Measure POP power to see if PR2 actually have T=2.2%
 - Play with LO1 and LO2 to invesitate LO beam shape and power
 - Check coherence between LO/AS power fluctuations with suspension motions
 - What is the expected counts/W for these DCPDs?
 - Balance the optical paths in ITMX table for A and B (same lenses, same mirrors)
 - Install better lens in front of camera

  17039   Wed Jul 27 14:39:04 2022 DeekshaUpdateElectronicsNew and improved PZT TF data from the DFD

Paco and I messed around with the attenuation of the scope and bandwidth of the IF. We also replaced the BNC T's in the circuits with RF splitters. We saw some decent improvements to the data. The data is attached and a diagram of the experiment. [We analytically calculated the impedances to avoid any mismatch taking place]. Working on fitting the data.

We also moved around the wires so that the AG4395 is closer to the PZT.


  17038   Tue Jul 26 21:16:41 2022 KojiUpdateComputer Scripts / ProgramsVector fitting

I think the fit fails as the measurement quality is not good enough.


  17037   Tue Jul 26 20:54:08 2022 PacoUpdateBHDBHD MICH test - LO phase control

[Yuta, Paco]

TL;DR Successfully controlled LO phase, and did BHD-MICH readout with various MICH offsets and LO phases.

Today we implemented a DCPD based LO phase control. First, we remeasured the balancing gain at 311.1 Hz (the MICH oscillator freq) and combined C1:HPC-DCPD_A_OUT with C1:HPC-DCPD_B_OUT to produce the balanced homodyne error signal (A-B). We feed this error signal to C1:HPC-LO_PHASE_IN1 and for the main loop filters we simply recycled the LSC-MICH loop filters FM2 through FM5 (we also copied FM8, but didn't end up using it much). Then, we verified the LO phase can be controlled by actuating either on LO1 or LO2. For LO2, we added an oscillator in the HPC LOCKINS at 318.75 Hz (we kept this on at 1000 counts for the measurements below).

The LO phase control was achieved with a loop gain in the range of 10-30 (we used 20), no offset, and FM4, and FM5 engaged. FM2 can be added to boost, but we usually skipped FM3. Then, we went through a set of measurements similar to the ones described in a previous elog. A key difference with respect to the measurements from before is that we locked MICH using AS55Q (as opposed to REFL55Q). This allowed us to reach higher MICH offsets without losing lock. After turning on the MICH oscillator at 3000 counts, we looked at:

  1. LO misaligned + MICH at dark fringe (offset = -21).
    • Here, we don't expect to see any MICH signal and indeed we don't, except for a small residual peak from perhaps a MICH offset or slightly imbalanced PDs.
  2. LO aligned, but uncontrolled + MICH at dark fringe (offset = -21).
    • Here we would naively expect MICH to show up in A-B, but because of the uncontrolled LO phase, we mostly see the noise baseline (mostly from LO RIN? ...see measurement 3) under which this signal is probably buried. Indeed, the LO fringe increased noise in A, B, and A-B but not in A+B. This is nice. yes
  3. LO aligned, but uncontrolled + MICH with dc readout (offset = +50).
    • Here we expected the MICH signal to show up due to the large offset, and we can indeed see it in A, B, and A+B, but not in A-B. Nevertheless we see almost exactly the same noise level even though we allow some AS light into the BHD readout, so maybe the noise observed in the A-B channel from measurements 2 and 3 is mostly from LO RIN. This needs further investigation...
  4. LO aligned, controlled at no offset + MICH with dc readout (offset = +50).
    • In general here we expected to see a noise reduction in the A-B channel since the LO fringe is stable, and a MICH signal should appear. Furthermore, since LO phase is under control, we expect the LO2 Oscillator to appear which it does for this and the following measurements. Because of the relative freedom, we tried this measurement in two cases:
      1. When feeding back to LO1
        • We actually see MICH in the A-B channel, as expected, after the noise level dropped by ~ 5. We also observed small sidebands +- 1 Hz away from the MICH peak, probably due to local damping in either LO or AS paths.
      2. When feeding back to LO2
        • We also see MICH here, with a slightly better drop in noise (relative to feeding back to LO1). Sidebands persisted here, but around at +- 2 Hz.
  5. LO aligned, controlled (offset = 10) + MICH with dc readout (offset = +50). *
    • Here, we expected the A-B MICH content to increase dramatically, and indeed it does after a little tuning of the LO phase heart. The noise level decreased slightly because LO phase noise is decreased around the optimal point.
  6. LO aligned, controlled (offset = 20) + MICH with dc readout (offset = +30). *
    • Here, we naively expected A+B MICH content to decrease, but A-B remain constant. In order to see this we tried to keep the balance between the offsets, but this was hard. We don't really see much of this effect, so this also needs further investigation. As long as we keep controlling the LO phase using the DCPDs because the offsets tend to reduce the error signal we will have a harder time.

* For these measurements we actuated on LO2 to keep the LO phase under control.

Note that the color code above corresponds to the traces shown in Attachment #1.

What's next?

  • Alignment of LO and AS might be far from optimized, so it should be tried more seriously.
  • What's the actual LO power? How does it compare with AS power at whatever MICH offsets?
  • Try audio dither LO phase control.
    • With MICH offset.
    • Without MICH offset, double demod (after dolphin fix crying)
  17036   Tue Jul 26 19:50:25 2022 DeekshaUpdateComputer Scripts / ProgramsVector fitting

Trying to vectfit to the data taken from the DFD previously but failing horribly. I will update this post as soon as I get anything semi-decent. For now here is this fit.

  17035   Mon Jul 25 18:22:30 2022 DeekshaSummaryWikiMeasured the PZT TF Successfully

Measured the PZT beatnote using the setup mentioned in elog post 17031. Attached is the data taken from 10kHz to 1MHz, decadewise data was also taken that I'm not including in this post. A_R refers to the transfer function taken of channel A wrt the voltage reference (the swept sine we are inputting which has an IF of 30kHz). A and B correspond to the I and Q components of the signal taken from the DFD, respectively. I am currently working on plotting the data, and will shortly update this post with plots. Next steps - 

- quantify the uncertainty in the signal (I think)

- vectfit the data to find poles and zeroes

(and possibly find a better way to print/obtain data)

Edit: first pass of data plotted

  17034   Mon Jul 25 18:09:41 2022 TegaConfigurationBHDBHD Homodyne Phase control MEDM screen

[Paco, Tega, Yuta]

Today, we made a custom MEDM screen for the BHD Homodyne Phase Control, which is basically an overview of the c1hpc model. See Attachments 1 & 2 for details.

  17033   Mon Jul 25 17:58:10 2022 TegaConfigurationBHDc1sus2 IPC dolphin issue update

From the 40m wiki, I was able to use the instructions here to map out what to do to get the IPC issue resolved. Here is a summary of my findings.

I updated the /etc/dis/dishost.conf file on the frame builder machine to include the c1sus2 machine which runs the sender model, c1hpc, see below. After this, the file becomes available on c1sus2 machine, see attachment 1, and the c1sus2 node shows up in the dxadmin GUI, see attachment 2. However, the c1sus2 machine was not active. I noticed that the log file for the dis_nodemgr service, see attachment 3, which is responsible for setting things up, indicated that the dis_irm service may not be up, so I checked and confirmed that this was indeed the case, see attachment 4. I tried restarting this service but was unsuccessful. I restarted the machine but this did not help either. I have reached out to Jonathan Hanks for assistance.

  17031   Mon Jul 25 09:37:39 2022 DeekshaUpdateElectronicsUsing the DFD to measure PZT TF

The DFD was setup to measure the change in beatnote when excited. A long long (128in) cable goes from the SR785 near the DFD all the way to the Xend AUX which it accordingly excites and the DFD is monitored by the oscilloscope at the other end. This was completed on Friday. The wires and stand have been moved to the side but the setup is still a bit chaotic. As of writing this post, there is still atleast some minor issue with the setup as we aren't getting the expected output. 

[I will shortly update this elog with more pictures]

Edit: the SR785 was replaced by the AG 4395, and pictures added


  17030   Mon Jul 25 09:05:50 2022 PacoSummaryGeneralTesting 950nm laser found in trash pile

[Paco, Yehonathan]

==== Late elog from Friday ====

Koji provided us with a QFLD-950-3S (QPHOTONICS) salvaged from Aidan's junk pile (LD is alive according to him). We tested the Jenne laser setup with this just to decide if we should order another one, and it worked.

The laser driver anode and cathode pins (8/9, 4/5 respectively) on the rear DB9 port from the  ILX Lightwave LDX-3412 driver were connected to the corresponding anode and cathode pins in the laser package (5, and 9; note the numbers are reversed between driver and laser). Then, interlock pins 1 and 2 in the driver were shorted to enable operation. This is all illustrated in Attachments #1-2.

After setting a limit of 27.6 mA current in the driver, we slowly increased the actual current to ~ 19 mA until we could see light on a beam card. We can go ahead and get a 1060 nm replacement.

  17029   Sun Jul 24 08:56:01 2022 HangUpdateCalibrationError propagation to astrophysical parameters from detector calibration uncertainty

Sorry I forgot to put tc & phic in the example. 

I modified astroFisherLib.py to include these parameters. Please note that their meaning is that we don't know when the signal happens and at which phase it merges.

It does not mean the time & phase from a reference frequency to the merger. This part is not free to vary because it is fixed by the intrinsic parameters.  

It might be good to have a quick scan through the Cutler & Flanagan 94 paper to better understand their physical meanings.


  17028   Fri Jul 22 17:46:10 2022 yutaConfigurationBHDc1sus2 watchdog update and DCPD ERR channels

[Tega, Yuta]

We have added C1:HPC-DCPD_A_ERR and C1:HPC-DCPD_B_ERR testpoints, which can be used as A+B, A-B etc.
Restarting c1hpc crashed c1sus2, and also made c1lsc/ioo/sus models red.
We run /opt/rtcds/caltech/c1/Git/40m/scripts/cds/restartAllModels.sh to restart all the machines. It worked perfectly without manually pressing power buttons! Wow!heart

We have also edited /opt/rtcds/caltech/c1/medm/c1su2/C1SU2_WATCHDOGS.adl so that it will use new /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/medm/resetFromWatchdogTrip.sh instead of old /opt/rtcds/caltech/c1/scripts/SUS/damprestore.py.

  17027   Fri Jul 22 17:43:19 2022 KojiUpdateGeneralObtained a functional CRT

[Koji Paco]

Koji went to Downs and found a CRT labeled "for 40m Rana?". So I decided to salvage it to the 40m after getting approval from Rich/Todd.

Paco and I tried this unit with the control room CCD signal and it just worked fine. So we can use this as a spare for any purpose in the lab.

  17026   Fri Jul 22 15:05:26 2022 TegaConfigurationBHDc1sus2 shared memory and ADC fix

[Tega, Yuta]

We were able to fix the shared memory issue by updating the receiver model name from ''SUS' to 'SU2' and the ADC zero issue by including both ADC0 and ADC1 in the c1hpc and c1bac models as well as removing the grounding of the unused ADC channels (including chn#16 and chn#17 which are actually used in c1hpc) in c1su2. We also used shared memory to move the DCPD_A/B error signals (after signal conditioning and mixing A/B; now named A_ERR and B_ERR) from c1hpc to c1bac.
C1:HPC-DCPD_A_IN1 and C1:HPC-DCPD_B_IN1 are now availableangel (they are essentially the same as C1:LSC-DCPD_A_IN1 and C1:LSC-DCPD_B_IN1, except for they are ADC-ed with different ADC; see elog 40m/16954 and Attachment #1).
Dolphin IPC error in seding signal from c1hpc to c1lsc still remains.crying

  17025   Thu Jul 21 21:50:47 2022 TegaConfigurationBHDc1sus2 IPC update

IPC issue still unresolved.

Updated shared memory tag so that 'SUS' -> 'SU2' in c1hpc, c1bac and c1su2. Removed obsolete 'HPC/BAC-SUS' references from IPC file, C1.ipc. Restarted the FE models but the c1sus2 machine froze, so I did a manual reboot. This brought down the vertex machines---which I restarted using /opt/rtcds/caltech/c1/scripts/cds/rebootC1LSC.sh---and the end machines which I restarted manually. Everything but the BHD optics now have their previous values. So need to burtrestore these.

# IPC file:

# Model file locations:

# Log files:

SUS overview medm screen :

  • Reduced the entire screen width
  • Revert to old screen style watchdog layout
  17024   Wed Jul 20 18:07:52 2022 PacoUpdateBHDBHD MICH test

[Paco, Yuta, JC]

We did some easy tests on the BHD readout in preparation for BHD MICH. With the arm cavities and LO beam misaligned, but the MICH aligned, we measured the transfer function from C1:LSC-DCPD_A_OUT to C1:LSC-DCPD_B_OUT to get a rough estimate of the gain balance: 1.8 * DCPD_A = DCPD_B. We then locked MICH using REFL55_Q and looked at

  • 1.8 * A - B (which we encoded using C1:LSC-PRCL_A_IN1)
  • 1.8 * A + B (which we encoded using C1:LSC-PRCL_B_IN1)

namely the DCPD BHD signals. After turning the MICH_OSC on (2000 gain @ 311.1 Hz), we took some power spectra under the following three configurations:

  1. LO misaligned, no MICH offset.
  2. LO overlap, no MICH offset.
  3. LO overlap and MICH offset.

For 1. the expectation was that since LO is misaligned and the AS port is dark, we would get no signal. In 2., however both A and B would might see some incoherent signal, but still no MICH. Finally in 3. all signals should be able to see MICH, including A-B. Attachment #1 shows the measurements 1, 2, and 3 (offset = -5.0). Then, with increasing offset values, the BHD MICH signals increased as well; discussion to follow.

  17023   Wed Jul 20 15:58:52 2022 KojiSummaryGeneralJenne laser kaput!

For troubleshooting, the proper laser driver (found beneath the AG network analyzer) was connected.
The current ~1mA was provided and the driver detected the "open circuit", which means the laser diode was busted.


The laser diode in the parts list is: "GTRAN GaAs Strained QW Laser Diode, Part # LD-1060".

  17022   Wed Jul 20 14:12:07 2022 PacoSummaryGeneralJenne laser kaput!

[Koji, Yehonathan, Paco]

Koji pointed out that this laser was always driven with a current driver (which was not nearby), and after finding it on one of the rolling carts, we hooked up the system but found that the laser driver displayed open circuit near the usual 20mA operating point. We therefore have to conclude that this laser is no more. We will look for a reasonable replacement.


[Paco, Yehonathan, JC]

We were trying to setup the Jenne laser to characterize the response of three 1811s that Yehonathan is using for his WOPA experiment (in QIL). We hooked up a ~ 5 VDC power supply to the bias tee and looked to see if there was any DC response in the REF PD. We used a DB9 breakout board and a DB9 cable, and saw some current being drawn. The DC current was a bit too high (500 mA), so we turned the DC voltage off, and realized the VDC power was reversed, probably along the DB9 cable which we didn't check before. As we flipped the power supply leads and turned power back on, we could no longer see any current even though the voltage was now right (or was it???). We would like to debug this laser, and continue using it if it still works (!), but there is negligible documentation either here or in the wiki, so if there are any known places to look at it would be helpful to know them.


  17021   Wed Jul 20 11:58:45 2022 PacoSummaryGeneralJenne laser kaput?

[Paco, Yehonathan, JC]

We were trying to setup the Jenne laser to characterize the response of three 1811s that Yehonathan is using for his WOPA experiment (in QIL). We hooked up a ~ 5 VDC power supply to the bias tee and looked to see if there was any DC response in the REF PD. We used a DB9 breakout board and a DB9 cable, and saw some current being drawn. The DC current was a bit too high (500 mA), so we turned the DC voltage off, and realized the VDC power was reversed, probably along the DB9 cable which we didn't check before. As we flipped the power supply leads and turned power back on, we could no longer see any current even though the voltage was now right (or was it???). We would like to debug this laser, and continue using it if it still works (!), but there is negligible documentation either here or in the wiki, so if there are any known places to look at it would be helpful to know them.

  17020   Tue Jul 19 18:41:42 2022 yutaUpdateBHDContrast measurements for Michelson and ITM-LO

[Paco, Yuta]

We measured contrast of Michelson fringe in both arms locked and mis-aligned. It was around 90%.
We also measured the contrast of ITM single bounce vs LO beam using BHD DC PDs. It was around 43%.
The measurement depends on the alignment and how to measure the maximum and minimum of the fringe. ITM-LO fringe was also not stable because motions of AS/LO mirrors are large. More tuning necessary.

 - As measured in elog 40m/17012, we see a lot of CARM in AS, which indicates large contrast defect.
 - We want to check mode-matching of LO beam to AS beam.

BHD DC PD conditioning
 - We added DCPD_A and DCPD_B to /opt/rtcds/caltech/c1/scripts/LSC/LSCoffsets3 script, which zeros the offsets when shutters are closed.
 - We also set C1:LSC-DCPD_(A|B)_GAIN = -1 since they are inverted.

Contrast measurement
 - Contrast was measured using channels ['C1:LSC-ASDC_OUT','C1:LSC-POPDC_OUT','C1:LSC-REFLDC_OUT','C1:LSC-DCPD_A_OUT','C1:LSC-DCPD_B_OUT']. For LO, only DCPD_(A|B) are used.
 - We took 15%-percentile (40% for ITM-LO fringe) from the maximum and minimum of the data, and took the median to estimate the maximum value and the minimum value (see Attachment).
 - Contrast = (Imax - Imin) / (Imax + Imin)
 - We measured three times in each configuration to estimate the standard error.
 - Jupyter notebook: https://git.ligo.org/40m/scripts/-/blob/main/CAL/BHD/measureContrast.ipynb

Both arms locked, MICH fringe (15% percentile)
Contrast measured by C1:LSC-ASDC_OUT is 89.75 +/- 0.17 %
Contrast measured by C1:LSC-POPDC_OUT is 79.41 +/- 0.86 %
Contrast measured by C1:LSC-REFLDC_OUT is 97.34 +/- 0.34 %
Contrast measured by C1:LSC-DCPD_A_OUT is 95.41 +/- 1.55 %
Contrast measured by C1:LSC-DCPD_B_OUT is 89.76 +/- 1.49 %
Contrast measured by all is 90.34 +/- 1.68 %

Both arms mis-aligned, MICH fringe (15% percentile)
Contrast measured by C1:LSC-ASDC_OUT is 89.32 +/- 0.57 %
Contrast measured by C1:LSC-POPDC_OUT is 94.55 +/- 0.62 %
Contrast measured by C1:LSC-REFLDC_OUT is 97.95 +/- 1.37 %
Contrast measured by C1:LSC-DCPD_A_OUT is 96.40 +/- 1.04 %
Contrast measured by C1:LSC-DCPD_B_OUT is 90.98 +/- 1.07 %
Contrast measured by all is 93.84 +/- 0.94 %

ITMY-LO fringe (40% percentile)
Contrast measured by C1:LSC-DCPD_A_OUT is 45.51 +/- 0.45 %
Contrast measured by C1:LSC-DCPD_B_OUT is 38.69 +/- 0.43 %
Contrast measured by all is 42.10 +/- 1.03 %

ITMX-LO fringe (40% percentile)
Contrast measured by C1:LSC-DCPD_A_OUT is 46.65 +/- 0.65 %
Contrast measured by C1:LSC-DCPD_B_OUT is 39.82 +/- 0.51 %
Contrast measured by all is 43.24 +/- 1.45 %

 - As you can see from the attachment, REFLDC is noisy and over estimating the contrast. ASDC is reliable. We need to tune the threshold to measure the maximum value and minimum value. We should also use the mode instead of median.
 - Contrast depends very much on the alignment. We didn't tweak too much today.
 - ITM-LO fringe was not stable, probably due to too much motion in AS1, AS4, LO1, LO2. Their damping needs to be re-tuned.

 - Model FPMI sensing matrix with measured contrast defect
 - Estimate AS-LO mode-mismatch using the measured contrast
 - Lock ITM-LO fringe using DCPD_(A|B) as error signal, and ITM or LO1/2 as actuator
 - Lock MICH with DCPD_(A|B), and with LO beam
 - Get better contrast data with better alignment and better AS1, AS4, LO1, LO2 damping

ELOG V3.1.3-