40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 1 of 339  Not logged in ELOG logo
New entries since:Wed Dec 31 16:00:00 1969
ID Datedown Author Type Category Subject
  17088   Wed Aug 17 11:10:51 2022 ranaUpdateComputersc1teststand rack mounting for CDS upgrade

we want to be able to run SimPlant on the teststand, test our new controls algorithms, test watchdogs, and any other software upgrades. Ideally in the steady state it will run some plants with suspensions and cavities and we will develop our measurement scripts on there also (e.g. IFOtest).


[Tega, Yuta]

I keep getting confused about the purpose of the teststand. The view I am adopting going forward is its use as a platform for testing the compatibility of new hardware upgrade, instead of thinking of it as an independent system that works with old hardware.

  17087   Wed Aug 17 10:27:49 2022 CiciUpdateGeneralLocking X-arm AUX laser

TL;DR: Got the x-arm aux laser locked again and took more data - my fit on my transfer functions need improvement and my new method for finding coherence doesn't work so I went back to the first way! See attached file for an example of data runs with poor fits. First one has the questionable coherence data, second one has more logical coherence. (ignore the dashed lines.)


  • The aux laser on the x-arm was still off after the power shutdown, so Paco and I turned it back on, and realigned the oplev of the ETMX - initial position was P = -0.0420, Y = -5.5391.
  • Locked the x-arm and took another few runs - was calculating coherence by I/Q demodulation of the buffers and then recombining the I/Q factors and then taking scipy.signal.coherence(), but for some reason this was giving me coherence values exclusively above 0.99, which seemed suspicious. When I calculated it the way I had before, by just taking s.s.coherence() of the buffers, I got a coherence around 1 except for in noisy areas of the data where it dropped more significantly, and seemed to be more correlated to the data. So I'll go back to using that way.
  • I also think my fits are not great - my standard error of the fits (calculated using the coherence as weight, see Table 9.6 of Random Data by Piersol and Bendat for the formula I'm using) are enormous. Now that I have a good idea that the UGF is between 1 - 15 kHz, I'm going to restrict my frequency band and try to fit just around where the UGF would be. 


To do:

  • Reduce frequency band and take more data
  • Get fit with better standard error, use that error to calculate the uncertainty in the UGF!
Attachment 1: rpi_OLG_2022_08_16_17_00_41.pdf
Attachment 2: rpi_OLG_2022_08_16_17_01_21.pdf
  17086   Wed Aug 17 10:23:05 2022 TegaUpdateGeneralc1vac issues, pressure gauge replacement

- Disk full

I updated the configuration file '/etc/logrotate.d/rsyslog' to set a file sise limit of 50M on 'syslog' and 'daemon.log' since these are the two log files that capture caget & caput terminal outputs. I also reduce the number of backup files to 2.

controls@c1vac:~$ cat /etc/logrotate.d/rsyslog
    rotate 2
    size 50M
        invoke-rc.d rsyslog rotate > /dev/null

    rotate 2
    size 50M
        invoke-rc.d rsyslog rotate > /dev/null
    rotate 4
        invoke-rc.d rsyslog rotate > /dev/null

- Vacuum gauge

The XGS-600 can handle 6 FRGs and we currently have 5 of them connected. Yes, having a spare would be good. I'll see about placing an order for these then.


- Disk Full: Just use the usual /etc/logrotate thing

- Vacuum gauge

I rather feel not replacing P1a. We used to have Ps and CCs as they didn't cover the entire pressure range. However, this new FRG (=Full Range Gauge) does cover from 1atm to 4nTorr.

Why don't we have a couple of FRG spares, instead?

Questions to Tega: How many FRGs can our XGS-600 controller handle?



  17085   Wed Aug 17 07:35:48 2022 yutaBureaucracyGeneralMy wish list for IFO commissioning

FPMI related
- Better suspension damping HIGH
 - Investigate ITMX input matrix diagonalization (40m/16931)
 - Output matrix diagonalization
 * FPMI lock is not stable, only lasts a few minutes for so. MICH fringe is too fast; 5-10 fringes/sec in the evening.
- Noise budget HIGH
 - Calibrate error signals (actually already done with sensing matrix measurement 40m/17069)
 - Make a sensitivity curve using error and feedback signals (actuator calibration 40m/16978)
 * See if optical gain and actuation efficiency makes sense. REFL55 error signal amplitude is sensitive to cable connections.
- FPMI locking
 - Use CARM/DARM filters, not XARM/YARM filters
 - Remove FM4 belly
 - Automate lock acquisition procedure
- Initial alignment scheme
 - Investigate which suspension drifts much
 - Scheme compatible with BHD alignment
 * These days, we have to align almost from scratch every morning. Empirically, TT2 seems to recover LO alignment and PR2/3 seems to recover Yarm alignment (40m/17056). Xarm seems to be stable.
 - Install alignment PZTs for Yarm
 - Restore ALS CARM and DARM
 * Green seems to be useful also for initial alignment of IR to see if arms drifted or not (40m/17056).
 - Suspension output matrix diagonalization to minimize pitch-yaw coupling (current output matrix is pitch-yaw coupled 40m/16915)
 - Balance ITM and ETM actuation first so that ASS loops will be understandable (40m/17014)
- Suspension calibrations
 - Calibrate oplevs
 - Calibrate SUSPOS/PIT/YAW/SIDE signals (40m/16898)
 * We need better understanding of suspension motions. Also good for A2L noise budgeting.
- CARM servo with Common Mode Board
 - Do it with single arm first

BHD related
- Better suspension damping HIGH
 - Invesitage LO2 input matrix diagonalization (40m/16931)
 - Output matrix diagonalization (almost all new suspensions 40m/17073)
 * BHD fringe speed is too fast (~100 fringes/sec?), LO phase locking saturates (40m/17037).
- LO phase locking
 - With better suspensions
 - Measure open loop transfer function
 - Try dither lock with dithering LO or AS with MICH offset (single modulation)
 - Modify c1hpc/c1lsc so that it can modulate BS and do double demodulation, and try double demodulation
- Noise Budget HIGH
 - Calibrate MICH error signal and AS-LO fringe
 - Calibrate LO1, LO2, AS1, AS4 actuation using ITM single bounce - LO fringe
 - Check BHD DCPD signal chain (DCPD making negative output when fringes are too fast; 40m/17067)
 - Make a sensitivity curve using error and feedback signals
- AS-LO mode-matching 
 - Model what could be causing funny LO shape
 - Model if having low mode-matching is bad or not
 * Measured mode-matching of 56% sounds too low to explain with errors in mode-matching telescope (40m/16859, 40m/17067).

IMC related
- WFS loops too fast (40m/17061)
- Noise Budget
- Investigate MC3 damping (40m/17073)
- MC2 length control path

  17084   Wed Aug 17 01:18:54 2022 KojiUpdateGeneralNotice: SURF SUS test setup blocking the lab way

Juan and I built an analog setup to measure some transfer functions of the MOS suspension. The setup is blocking the lab way around the PD test bench.
Excuse us for the inconvenience. It will be removed/cleared by the end of the week.

Attachment 1: PXL_20220817_060428109.jpg
  17083   Tue Aug 16 18:22:59 2022 TegaUpdateComputersc1teststand rack mounting for CDS upgrade

[Tega, Yuta]

I keep getting confused about the purpose of the teststand. The view I am adopting going forward is its use as a platform for testing the compatibility of new hardware upgrade, instead of thinking of it as an independent system that works with old hardware.

The initial idea of clearing 1X7 cannot be done for now, because I missed the deadline for providing a detailed enough plan before Monday power up of the lab, so we are just going to go ahead and use the new rack as was initially intended and get the latest hardware and software tested here.

We mounted the DAQ, subnet and dolphin IX switches, see attachement 1. The mounting ears that came with the dolphin switch did not fit and so could not be used for mounting. We looked around the lab and decided to used one of the NavePoint mounting brackets which we found next to the teststand, see attachment 2.

We plan to move the new rack to the current location of the teststand and use the power connection from there. It is also closer to 1X7 so that moving the front-ends and switches to 1X7 should be straight forward after we complete all CDS upgrade testing.

Attachment 1: IMG_20220816_180157132.jpg
Attachment 2: IMG_20220816_175125874.jpg
  17082   Mon Aug 15 20:09:18 2022 KojiUpdateGeneralc1vac issues, 1 pressure gauge died

- Disk Full: Just use the usual /etc/logrotate thing

- Vacuum gauge

I rather feel not replacing P1a. We used to have Ps and CCs as they didn't cover the entire pressure range. However, this new FRG (=Full Range Gauge) does cover from 1atm to 4nTorr.

Why don't we have a couple of FRG spares, instead?

Questions to Tega: How many FRGs can our XGS-600 controller handle?


  17081   Mon Aug 15 18:06:07 2022 AnchalUpdateGeneralc1vac issues, 1 pressure gauge died

[Anchal, Paco, Tega]

Disk full issue:

c1vac was showing /var disk to be full. We moved all gunzipped backup logs to /home/controls/logBackUp. This emptied 36% of space on /var. Ideally, we need not log so much. Some solution needs to be found for reducing these log sizes or monitoring them for smart handling.

Pressure sensor malfunctioning:

We were unable to opel the PSL shuttter, due to the interlock with C1:Vac-P1a_pressure. We found that C1:Vac-P1a_pressure is not being written by serial_MKS937a service on c1vac. The issue was the the sensor itself has become bad and needs to be replaced. We believe that "L 0E-04" in the status (C1:Vac-P1a_status) message indicates a malfunctioning sensor.

Quick fix:

We removed writing of C1:Vac-P1a_pressure and C1:Vac-P1a_status from MKS937a and mvoed them to XGS600 which is using the sensor 1 from main volume. See this commit.

Now we are able to open PSL shutter. The sensor should be replaced ASAP and this commit can be reverted then.

  17080   Mon Aug 15 15:43:49 2022 AnchalUpdateGeneralComplete power shutdown and startup documentation

All steps taken have been recorded here:

  17079   Mon Aug 15 10:27:56 2022 KojiUpdateGeneralRecap of the additional measures for the outage prep

[Yuta Koji]

(Report on Aug 12, 2022)

We went around the lab for the final check. Here are the additional notes.

  • 1X9: The x-end frontend machine still had the AC power. The power strip to which the machine is connected was disconnected from the AC at the side of the rack. (Attachment 1)
  • 1X8: The vacuum rack still supplied the AC to c1vac. This was turned off at the UPS. (Attachment 2)
  • 1X6: VMI RFM hub still had the power. This was turned off at the rear switch. (Attachment 3)
  • PSL: The PSL door was open (reported above). Closed. (Attachment 4)
  • 1Y2: The LSC rack still had the DC power. The supplies were turned off at the KEPCO rack (the short rack). (Attachment 5)
    Note that the top-right supply for the +15V is not used. (The one in the empty slot got busted). We may need some attention to the left-most one in the second row. It indicated a negative current. Is this just the current meter problem or is the supply broken?
  • Control room: The CAD WS was turned off.

I declare that now we are ready for the power outage.

Attachment 1: PXL_20220812_234438097.jpg
Attachment 2: PXL_20220812_234655309.jpg
Attachment 3: PXL_20220812_234748559.jpg
Attachment 4: rn_image_picker_lib_temp_b5f3e38d-796c-4816-bc0e-b11ba3316cbe.jpg
Attachment 5: PXL_20220812_235429314.jpg
  17078   Fri Aug 12 13:40:36 2022 JCUpdateGeneralPreparing for Shutdown on Saturday, Aug 13

[Yehonathan, JC]

Our first step in preparing for the Shutdown was to center all the OpLevs. Next is to prepare the Vacuum System for the shutdown.


  17077   Fri Aug 12 02:02:31 2022 KojiUpdateGeneralPower Outage Prep: nodus /home/export backup

Took the backup (snapshot) of /home/export as of Aug 12, 2022

controls@nodus> cd /cvs/cds/caltech/nodus_backup
controls@nodus> rsync -ah --progress --delete /home/export ./export_220812 >rsync.log&

As the last backup was just a month ago (July 8), rsync finished quickly (~2min).

  17076   Thu Aug 11 17:15:33 2022 CiciUpdateGeneralMeasuring AUX Laser UGF with Red Pitaya

TL;DR: Have successfully measured the UGF of the AUX laser on my Red Pitaya! Attached is one of my data runs (pdf + txt file). 


  • Figured out how to get a rudimentary coherence (use scipy.signal.coherence to get Cxy = abs(Pxy)**2/(Pxx*Pyy), then find what point is the closest to the frequency I'm inserting on that iteration of the swept sine and get the coherence closest to that). Not precisely the coherence at the frequency I'm inserting though, so not perfect... more of a lower bound of coherence.
  • Figured out how to get the UGF from the data automatically (no error propagation yet... necessary next step)
  • Put my red pitaya in the X-arm AUX laser control electronics (thank you to Anchal for help figuring out where to put it and locking the x-arm.) Counts dropped from 4500 to 1900 with the x-arm locked, so 58% mode matching. I lose lock at an amplitude >0.05 or so.
  • Wrote a little script to take data and return a time-stamped text file with all the parameters saved and a time-stamped pdf of the TF magnitude, UGF, phase, and coherence, so should be easy to take more data next time!


  • need to take more accurate coherence data
  • need to propagate uncertainty on UGF (probably high...)
  • take more data with higher coherence (the file attached doesn't have great coherence and even that was one of my better runs, will probably increase averaging since increasing amplitude was a problem)
Attachment 1: rpi_OLG_2022_08_11_16_51_53.pdf
Attachment 2: rpi_OLG_2022_08_11_16_51_53.txt
# frequency start: 500.0
# frequency stop: 50000.0
# samples: 50
# amplitude: 0.01
# cycles: 500
# max fs: 125000000.0
# N: 16384UGF: 9264.899326705621
# Frequency[Hz] Magnitude[V/V] Phase[rad] Coherence
4.999999999999999432e+02 5.216612299292965105e+01 -7.738468629291910261e-01 7.660920305860696722e-02
5.492705709937790743e+02 3.622076363933444298e+01 -5.897393740774580229e-01 3.183076012979469405e-01
... 49 more lines ...
  17075   Thu Aug 11 16:48:59 2022 ranaUpdateComputer Scripts / ProgramsNDS2 updates

We had several problems with our NDS2 server configuration. It runs on megatron, but I think it may have had issues since perhaps not everyone was aware of it running there.

  1. channel lists were supposed to updated regularly, but the nds2_nightly script did not exist in the specified directory. I have moved it from Joe Areeda's personal directory (/home/nds2mgr/joework/server/src/utils/) to nds2mgr/channel-tracker/.
  2. The channel history files (/home/nds2mgr/channel-tracker/channel_history/) are stored on the local megatron disk. These files had grown up to ~50 GB over tha past several years. I backed these up to /users/rana/, and then wiped them out so that the NDS could regen them. Now that the megatron local disk is not full, it seems to work in giving raw data.
  3. Need to confirm that this serves up trend data (second and minute)
  4. I think there is a nds2-server package for Debian, so we should update megatrons OS to the preferred flavour of DebIan and use that. Who to get to help in this install?

Since Megatron is currently running the "Shanghai" Quad-core Opteron processor from ~2009,  its ~time to replace it with a more up to date thing. I'll check with Neo to see if he has any old LDAS leftovers that are better.

  17074   Wed Aug 10 20:51:14 2022 TegaUpdateComputersCDS upgrade Front-end machine setup

Here is a summary of what needs doing following the chat with Jamie today.


Jamie brought over the KVM switch shown in the attachment and I tested all 16 ports and 7 cables and can confirm that they all work as expected.



1. Do a rack space budget to get a clear picture of how many front-ends we can fit into the new rack

2. Look into what needs doing and how much effort would be needed to clear rack 1X7 and use that instead of the new rack. The power down on Friday would present a good opportunity to do this work on Monday, so get the info ready before then. 

3. Start mounting front-ends, KVM and dolphin network switch

4. Add the BOX rack layout to the CDS upgrade page.

Attachment 1: IMG_20220810_171002928.jpg
Attachment 2: IMG_20220810_171019633.jpg
  17073   Wed Aug 10 20:30:54 2022 TegaSummarySUSCharacterisation of suspension damping

[Yuta, Tega]

We diagnosed the suspension damping of the IMC/BHD/recycling optics by kicking the various degree of freedom (dof) and then tuning the gain so that we get a residual Q of approx. 5 in the cases where this can be achieved.

MC1: Good
MC2: SIDE-YAW coupling, but OK
MC3: Too much coupling between dofs, NEEDS ATTENTION
LO1: Good
LO2: Good
AS1: POS-PIT coupling, close to oscillation, cnt2um off, NEEDS ATTENTION
AS4: PIT-YAW coupling, cannot increase YAW gain because of coupling, No cnt2um, No Cheby, NEEDS ATTENTION
PR2: No cnt2um, No Cheby
PR3: POS-PIT coupling, cannot increase POS/PIT/YAW gain because of coupling, No cnt2um, No Cheby, NEEDS ATTENTION
SR2: No cnt2um

Attachment 1: BHD_SUSPIT_KICK.png
Attachment 2: BHD_SUSPOS_KICK.png
Attachment 3: BHD_SUSSIDE_KICK.png
Attachment 4: BHD_SUSYAW_KICK.png
Attachment 5: IMC_SUSPIT_KICK.png
Attachment 6: IMC_SUSPOS_KICK.png
Attachment 7: IMC_SUSSIDE_KICK.png
Attachment 8: IMC_SUSYAW_KICK.png
Attachment 9: PRSR_SUSPIT_KICK.png
Attachment 10: PRSR_SUSPOS_KICK.png
Attachment 11: PRSR_SUSSIDE_KICK.png
Attachment 12: PRSR_SUSYAW_KICK.png
  17072   Wed Aug 10 19:36:45 2022 KojiBureaucracyGeneralLab cleaning and discovery

During the cleaning today, we found many legacy lab items. Here are some policies what should be kept / what should be disposed


  • VME crates and VME electronics as long as they are not in use
  • Eurocard SUS modules that are not in use.
  • Eurocard crates (until we remove the last Eurocard module from the lab)
  • Giant steel plate/palette (like a fork lift palette) along the Y arm. (Attachment 1)
  • An overhead projector unit.


  • Spare Eurocard crates / ISC/PZT Eurocard modules
  • Boxes of old 40m logbooks behind the Y arm (see Attachment 2/3).
  • Ink-plotter time-series data (paper rolls) of 1996 IFO locking (Attachment 4). Now stored in a logbook box.
  • A/V type remnants: Video tapes / video cameras / casette tapes as long as they hold some information in it. i.e. Blank tapes/blank paper rolls can be disposed.
Attachment 1: steel_plate.jpg
Attachment 2: logbook1.jpg
Attachment 3: logbook2.jpg
Attachment 4: paper_plots.jpg
  17071   Wed Aug 10 19:24:19 2022 ranaUpdateGeneralWorking Red Pitaya VNA



  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.
Attachment 1: rpi_vna_test.pdf
  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 %

Attachment 1: HPC-DCPD_B_OUT_1344118517_ITMY-LO.png
Attachment 2: HPC-DCPD_A_OUT_1344118517_ITMY-LO.png
Attachment 3: HPC-DCPD_B_OUT_1344118318_ITMX-LO.png
Attachment 4: HPC-DCPD_A_OUT_1344118318_ITMX-LO.png
  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.

Attachment 1: IMG_20220808_170349717.jpg
  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.

Attachment 1: 20220805_164434.jpg
Attachment 2: LaserActuation_TF_Measurement.drawio.pdf
  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.


Attachment 1: Screen_Shot_2022-08-05_at_12.04.01.png
  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)

Attachment 1: Screenshot_2022-08-04_22-17-19.png
Attachment 2: Screenshot_2022-08-04_22-18-45.png
  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.


Attachment 1: IMC_SUS_channels_TF.pdf
Attachment 2: IMC_WFS_channels_TF.pdf
Attachment 3: IMC_WFS_segment_TF.pdf
Attachment 4: IMC_WFS_220804.xlsx
  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)

Attachment 1: Screenshot_2022-08-04_22-10-57.png
Attachment 2: Screenshot_2022-08-04_22-11-16.png
Attachment 3: Screenshot_2022-08-04_22-11-53.png
Attachment 4: Screenshot_2022-08-04_22-12-39.png
  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).

Attachment 1: IMG_20220804_184444473.jpg
Attachment 2: IMG_20220804_191658206.jpg
Attachment 3: IMG_20220804_185336240.jpg
Attachment 4: IMG_20220804_185023002.jpg
  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

Attachment 1: Screenshot_2022-08-03_15-46-36_BHDfringeAlmostUnclipped.png
  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

Attachment 1: PXL_20220803_215819580.jpg
  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
Attachment 1: c1lsc_IPC_status.png
Attachment 2: FE_lsmod_dependencies_c1sus2_b4_after_iop_unpdate.png
  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

Attachment 1: 220801_IMC_WFS_DEMOD.pdf
Attachment 2: 220801_IMC_WFS_DEMOD2.pdf
Attachment 3: WFS1.png
Attachment 4: WFS2.png
  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.

Attachment 1: c1sus2_dolphin.png
Attachment 2: fb1_dxamin_status.png
Attachment 3: dolphin_num_mem_init2.png
  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

Attachment 1: PXL_20220730_040900843.jpg
Attachment 2: PXL_20220730_041216848.jpg
  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.

Attachment 1: LO_and_oldAS_settings.png
Attachment 2: BHD_fringe_settings.png
Attachment 3: Screenshot_2022-07-29_19-37-39.png
Attachment 4: FromTheLeft-AS-POP-LO.JPG
  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



Attachment 1: Screenshot_2022-07-28_16-58-34_LOandASShaking.png
Attachment 2: Screenshot_2022-07-28_18-08-55_DCPDPOPSuspensionCoherence.png
  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

Attachment 1: LOBeamAtBHD.JPG
Attachment 2: ITMXSingleBounceAtBHD.jpg
  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.


Attachment 1: tf_data.png
Attachment 2: latest_data.zip
Attachment 3: dfd_-_new.drawio.png
ELOG V3.1.3-