40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 141 of 344  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  17145   Tue Sep 20 07:03:04 2022 PacoSummaryGeneralPower Outage 220916 -- restored all

[JC, Tega, Paco ]

I would like to mention that during the Vacuum startup, after the AUX pump was turned on, Tega and I were walking away while the pressure decreases. While we were, valves opened on their own. Nobody was near the VAC Desktop during this. I asked Koji if this may be an automatic startup, but he said the valves shouldn't open unless they are explicitely told to do so. Has anyone encountered this before?


Restore lab

[Paco, Tega, JC, Yehonathan]

We followed the instructions here. There were no major issues, apart from the fb1 ntp server sync taking long time after rebooting once.

ETMY damping

[Yehonathan, Paco]

We noticed that ETMY had to much RMS motion when the OpLevs were off. We played with it a bit and noticed two things: Cheby4 filter was on for SUS_POS and the limiter on ULCOIL was on at 0 limit. We turned both off.

We did some damping test and observed that the PIT and YAW motion were overdamped. We tune the gain of the filters in the following way:


SUSPOS_GAIN 200->150


These action seem to make things better.


  17150   Wed Sep 21 17:01:59 2022 PacoUpdateBHDBH55 RFPD installed - part I

[Radhika, Paco]

Optical path setup

We realized the DCPD - B beam path was already using a 95:5 beamsplitter to steer the beam, so we are repurposing the 5% pickoff for a 55 MHz RFPD. For the RFPD we are using a gold RFPD labeled "POP55 (POY55)" which was on the large optical table near the vertex. We have decided to test this in-situ because the PD test setup is currently offline.

Radhika used a Y1-1025-45S mirror to steer the B-beam path into the RFPD, but a lens should be added next in the path to focus the beam spot into the PD sensitive area. The current path is illustrated by Attachment #1.

We removed some unused OPLEV optics to make room for the RFPD box, and these were moved to the optics cabinet along Y-arm [Attachment #2].


[Anchal, Yehonathan]

PD interfacing and connections

In parallel to setting up the optical path configuration in the ITMY table, we repurposed a DB15 cable from a PD interface board in the LSC rack to the RFPD in question. Then, an SMA cable was routed from the RFPD RF output to an "UNUSED" I&Q demod board on the LSC rack. Lucky us, we also found a terminated REFL55 LO port, so we can draw our demod LO from there. There are a couple (14,15,20,21) ADC free inputs after the WF2 and WF3 whitening filter interfaces.

Next steps

  • Finish alignment of BH55 beam to RFPD
  • Test RF output of RFPD once powered
  • Modify LSC model, rebuild and restart
  17159   Mon Sep 26 11:39:37 2022 PacoUpdateBHDBH55 RFPD installed - part II

[Paco, Anchal]

We followed rana's suggestion for stress relief on the SMA joint in the BH55 RFPD that Radhika resoldered. We used a single core, pigtailed wire segment after cleaning up the solder joint on J7 (RF Out) and also soldered the SMA shield to the RF cage (see Attachment #1). This had a really good effect on the rigidity of the connection, so we moved back to the ITMY table.

We measured the TEST in to RF Out transfer function using the Agilent network analyzer, just to see the qualitative features (resonant gain at around 55 MHz and second harmonic suppression at around 110 MHz) shown in Attachment #2. We used 10kOhm series resistance in test input path to calibrate the measured transimpedance in V/A. The RFPD has been installed in the ITMY table and connected to the PD interface box and IQ demod boards in the LSC rack as before.

Measurement files

  17160   Tue Sep 27 10:50:11 2022 PacoUpdateBHDcalibrated LO phase noise

Locked LO phase to ITMX single bounce beam at the AS port, using the DCPD (A-B) error point and actuating on LO1 POS. For this the gain was tuned from 0.6 to 4.0. A rough Michelson fringe calibration gives a counts to meters conversion of ~0.212 nm/count, and the OLTF looks qualitatively like the one in a previous measurement (~ 20 dB at 1 Hz, UGF = 30 Hz). The displacement was then converted to phase using lambda=1e-6; I'm not sure what the requirement is on the LO phase (G1802014 says 1e-4 rad/rtHz at 1 Hz, but our requirement doc says 1 to 20 nrad/rtHz (rms?)... anyways wit this rough calibration we are still off in either case.

The balancing gain is obvious at DC in the individual DCPD spectra, and the common mode rejection in the (A-B) signal is also appreciable. I'll keep working on refining this, and implementing a different control scheme.

  17161   Wed Sep 28 16:37:26 2022 PacoUpdateBHDcalibrated LO phase noise; update

[yuta, paco]

Update; the high frequency ( > 100 Hz) drop is of course not real and comes from a 4th order LP filter in the HPC demod I filter which I haven't accounted for. Furthermore, we have gone through the calibration factors and corrected a factor of 2 in the optical gain. Then, I also added the CLTF to show in loop and out of loop error respectively. The updated plot, though not final, is in Attachment #1.

  17163   Wed Sep 28 21:54:08 2022 PacoUpdateBHDcalibrated LO phase noise; update

Repeated the LO phase noise measurement, this time with the LO - ITMY single bounce, and a couple of fixes Koji hinted at including:

  1. The DEMOD angle was the missing piece! The previous error point showed lower noise than the individual DCPDs because the demodulation angle had not been checked. I corrected it so that the error point in LO_PHASE control was exactly equal to the LO-ITMY single bounce fringe. With this, the gain on the servo had to be adjusted from 4.00 to 0.12, still using FM4, FM5, and this time also FM8 (BLP600).
  2. Turned off 60 Hz harmonics comb notches on DCPDs, they are unecessary.
  3. Acquired noise spectra down to 0.1 Hz, with 0.03 Hz bin width to increase resolution and identify resonant SUS noise near 1 Hz.

This time, after alignment the fringe amplitude was 500 counts. Attachment #1 shows the updated plot with the calibrated noise spectra for the individual DCPD signals A and B as well as their rms values. Attachment #2 shows the error point, in loop and the estimated out of loop spectra with their rms as well. The peak at ~ 240 Hz is quite noticeable in the error point time series, and dominates the high frequency rms noise. The estimated rms out of loop noise is ~ 9.2 rad, down to 100 mHz.

  17167   Fri Sep 30 20:18:55 2022 PacoUpdateBHDLO phase noise with different actuation points

[Paco, Koji]

We took lo phase noise spectra actuating on the for different optics-- LO1, LO2, AS1, and AS4. The servo was not changed during this time with a gain of 0.2, and we also took a noise spectrum without any light on the DCPDs. The plot is shown in Attachment #1, calibrated in rad/rtHz, and shown along with the rms values for the different suspension actuation points. The best one appears to be AS1 from this measurement, and all the optics seem to show the same 270 Hz (actually 268 Hz) resonant peak.

268 Hz noise investigation

Koji suspected the observed noise peak belongs to some servo oscillation, perhaps of mechanical origin so we first monitored the amplitude in an exponentially averaging spectrum. The noise didn't really seem to change too much, so we decided to try adding a bandstop filter around 268 Hz. After the filter was added in FM6, we turned it on and monitored the peak height as it began to fall slowly. We measured the half-decay time to be 264 seconds, which implies an oscillation with Q = 4.53 * f0 * tau ~ 3.2e5. This may or may not be mechanical, further investigation might be needed, but if it is mechanical it might explain why the peak persisted in Attachment #1 even when we change the actuation point; anyways we saw the peak drop ~ 20 dB after more than half an hour... After a while, we noticed the 536 Hz peak, its second harmonic, was persisting, even the third harmonic was visible.

So this may be LO1 violin mode & friends -

We should try and repeat this measurement after the oscillation has stopped, maybe looking at the spectra before we close the LO_PHASE control loop, then closing it carefully with our violin output filter on, and move on to other optics to see if they also show this noise.

  17171   Mon Oct 3 15:19:05 2022 PacoUpdateBHDLO phase noise and control after violin mode filters

[Anchal, Paco]

We started the day by taking a spectrum of C1:HPC-LO_PHASE_IN1, the BHD error point, and confirming the absence of 268 Hz peaks believed to be violin modes on LO1. We then locked the LO phase by actuating on LO2, and AS1. We couldn't get a stable loop with AS4 this morning. In all of these trials, we looked to see if the noise increased at 268 Hz or its harmonics but luckily it didn't. We then decided to add the necessary output filters to avoid exciting these violin modes. The added filters are in the C1:SUS-LO1_LSC bank, slots FM1-3 and comprise bandstop filters at first, second and third harmonics observed previously (268, 536, and 1072 Hz); bode plots for the foton transfer functions are shown in Attachment #1. We made sure we weren't adding too much phase lag near the UGF (~ 1 degree @ 30 Hz).

We repeated the LO phase noise measurement by actuating on LO1, LO2 and AS1, and observe no noise peaks related to 268 Hz this time. The calibrated spectra are in Attachment #2. Now the spectra look very similar to one another, which is nice. The rms is still better when actuating with AS1.


After the above work ended, I tried enabling FM1-3 on the C1:HPC_LO_PHASE control filters. These filters boost the gain to suppress noise at low frequencies. I carefully enabled them when actuating on LO1, and managed to suppress the noise by another factor of 20 below the UGF of ~ 30 Hz. Attachment #3 shows the screenshot of the uncalibrated noise spectra for (1) unsupressed (black, dashed), (2) suppressed with FM4-5 (blue, solid), and (3) boosted FM1-5 suppression (red).

Next steps:

  • Compare LO-ITMY and LO-ITMX single bounce noise spectra and MICH.
  • Compare DC locking scheme versus BH55 once it's working.
  17206   Mon Oct 24 18:01:00 2022 PacoSummaryBHDBHD actuation measurements

[Yuta, Paco]

Today we calibrated the actuation on BHD suspended optics: LO1, LO2, AS1, AS4.
Actuation transfer functions for these optics look good.

ITMY actuation

For a reference we locked LO-ITMY single bounce using the LSC MICH loop. The error point was BH55_Q, the whitening filter gain was 45 dB, IQ demod rotation angle = 151.061 deg, the servo gain was -10, and the actuation point was ITMY. The measured UGF for this loop was ~ 150 Hz when FM2, 3, 4, 5 and 8 were all enabled. Note FM8 is an elliptic low pass (600 Hz cutoff).

LO1, LO2, AS1, AS4 actuation

We then lock the LO phase by feeding back BH55_Q_ERR to the actuation points under test with exactly the same filters but a servo gain of 0.6 but otherwise we are using the same servo filters FM2, 3, 4, 5 and 8 for this controls. The measured UGFs were all near ~ 70 Hz.

Here we had to be careful not to excite mechanical (?) resonances similar to the previously observed "violin" modes in LO1. In particular, we first noticed unsupressed 816 Hz noise in AS1 was being reinjected by the loop sometimes tripping the local damping loops, so we added bandstop filters at the AS1_LSC output filter bank. The resulting loop was then allowed to increase the gain and turn on FM2 and FM3 (boosts). This was also the case in AS4, where 268 Hz and second + third harmonics appeared to be excited by our feedback control. Finally, AS4 also displayed some mechanical excitation at 96.7 Hz, which seemed too low to be a "violin" mode, and its "Q" factor was not as high. We added a bandstop for this as well.

Attachment #1 shows LO_PHASE OLTFs when actuating in the different optics. By taking the actuation ratios (Attachment #2) with respect to our ITMY actuation reference and which had previously been calibrated to be 4.74e-9 / f^2 m / cts, we now have estimated our BHD suspension actuation calibrations to be:

  • LO1 = 3.14e-8 / f^2 m / cts
  • LO2 = 2.52e-8 / f^2 m / cts
  • AS1 = 3.14e-8 / f^2 m / cts
  • AS4 = 2.38e-8 / f^2 m / cts

This magnitudes are consistent with the expected coil driver ranges (about a factor of 10 difference).

  17209   Tue Oct 25 09:57:34 2022 PacoConfigurationPEMAuto Z on trillium interface board

I pressed the Auto-Z(ero) button for ~ 3 seconds at ~9:55 local (pacific) time on the trillium interface on 1X5.

  17211   Tue Oct 25 14:29:56 2022 PacoSummarySEIEarthquake tripped SUS

[Yuta, Paco, JC]

This eq  potentially tripped ETMY, PR2, PR3, AS1, AS4, SR2, LO1, LO2 suspensions during today's WB meeting. We restored them into normal local damping.

We aligned the arm cavities just to verify things were ok and then moved on to BHD comissioning. No problems spotted so far.

  17212   Tue Oct 25 17:27:11 2022 PacoSummaryBHDLO phase control with RF + audio sidebands

[Yuta, Paco]

Today we locked LO phase with BH55 + Audio dithering


We worked with MICH locked using AS55_Q with an offset = 50. Our BH55_Q_ERR is the same as in the previous elog (in this thread). We enabled audio dithering of AS1 to produce 280.54 Hz sidebands (exc gain = 15000). We used ELP80 (elliptic, 4th order lowpass with the second resonant notch at 280.54 Hz) at the BH55_Q_AS1_DEMOD_I output. This allowed us to generate an error signal to feedback into AS1 POS. Attachment #1 shows a screen capture of this configuration.


We close a loop with the above configuration to lock the LO phase using only filters FM5, FM8 and then optionally boost with FM2. The compromise we had to make because of our phase margin was to achieve UGF ~ 20 Hz (in contrast with ~ 70 Hz used in single bounce). Attachment #2 shows the measured OLTFs for LO_PHASE control using this scheme; the red was the final measured loop, while the blue was our initial reference before increasing the servo gain.


  17215   Wed Oct 26 10:28:05 2022 PacoUpdateIOOHEPA ON / WFS ON

Turned HEPA ON this morning at 10:28 local (pacific time) or gpstime = 1350802758. WFS ON right after that. IMC was locked and nominally aligned at this time.

  17216   Wed Oct 26 16:04:12 2022 PacoSummaryBHDLO phase control with RF + audio sidebands

[Yuta, Paco]

Today we again locked the LO phase with BH55 + Audio dithering under a zero-offset MICH


We worked with MICH locked using AS55_Q with an offset = 0. Our BH55_Q_ERR is the same as in the previous elog (in this thread).We reduced the MICH offset from 50 to 0 slowly and kept an eye on the BH55 error signals. We realized that at zero offset, most of the error signal was in BH55_I_ERR (why?) so we rotated it back to BH55_Q_ERR (146 deg --> 56 deg). We then looked at the audio demod angle, and optimized it to allocated the error signal in the I quadrature (-15 deg --> 40 deg).


We close a loop with the above configuration to lock the LO phase using only filters FM5, FM8 and then optionally boost with FM2. The measured UGF ~ 20 Hz similar to the configuration with an offset present; and it seems there is some residual noise at ~ 20 Hz (observed in the residual error signal time trace with ndscope).

Next tasks:

  • Noise budget residual error in this configuration
  • Investigate negative count offset in DCPDs
  • Investigate why does the rotation angle change from single bounce to MICH?
  17221   Wed Nov 2 16:34:56 2022 PacoSummaryCalibrationSingle arm calibration run

[Anchal, Paco]

We added a notch filter on ETMY (the actuation point of the YARM control loop) to inject our calibration line at 575.170 Hz. The excitation is injected using the DARM Oscillator, with an exc. gain of ~ 500 (this gets us a decent > 10 SNR line in the ALS Y beat). With the arm cavity locked to the PSL (~150 Hz control bandwidth), and the aux laser locked to the cavity (~10 kHz control bandwidth) the goal of this run is to calibrate our actuator strength and more importantly to budget its uncertainty. For this we have looked at the ALS beat stability using Allan statistics; we noticed the ALS beatnote frequency fluctuations start to become dominated by 1/f (or divergent noise due to systematic drifts in the YARM loop) after 10 seconds (see Attachment #1) (we have managed to see 30 seconds stability with the HEPAs off and without locking to IMC).

Our prediction is that our demodulated calibration lines will display the least residual rms noise when averaging down to around this time. This is the only reason one would use allan statistics; to quantify the separation between statistical and systematic effects in a frequency measurement. To be continued...


  • 1351464997 to 1351467139
  • 1351467259 to 1351468221
  • 1351468318 to ...
  17253   Thu Nov 10 17:40:31 2022 PacoSummaryCalibrationCalibration Plan

Plan to calibrate single arm actuation strength

  1. Lock single arm cavity (e.g. YARM)
  2. Lock YAUX laser to arm cavity (actuation point is ETMY)
  3. With the notch on the YARM loop filter (actually on ETMY),
  4. Turn on cal line (e.g. DARM osc) to move ITMY; here the frequency is chosen to be away from 600 Hz (line harmonic) and from violin modes for ITMY (642 Hz). The lower value of 575.17 Hz was chosen to avoid demodulating noise peaks at 455 Hz and 700 Hz.
  5. Get raw YALS beatnote (we chose the demod angle of -35 deg to minimize Q).

The analysis is as follows:

  1. Get demodulated IQ timeseries for the duration of the locks before lowpass filter (C1:CAL-SENSMAT_DARM_BEATYF_I_DEMOD_I_IN1); we are also storing the raw beatnote if we want to do software demodulation.
  2. Look at the allan deviation of I and Q to establish the timescale over which our measurement is dominated by statistical uncertainty -- after this time, the uncertainty is expected to be due to systematic error / drift. In this case as shown by Attachment #1 the time is around 60.6 seconds.
  3. At this frequency and with 500 gain the ITMY coils should be actuating 7.32 pm of amplitude displacement.
  4. The minimum allan deviation does indeed predict the statistical uncertainty limited rms if we look at the power spectra of the demodulated cal line over different time periods (Attachment #2), notice I lowpassed the raw timeseries.
  5. I think the next step is to get the nominal calibration value and repeat the measurment for more than a single cal line.
  6. Roughly from the deviation plot, our fractional beatnote deviation is a proxy for the calibration uncertainty. 1.15e-16 of beatnote stability should translate to a fractional displacement stability of ~4.57e-15 at 60 seconds; giving an ultimate statistical calibration uncertainty of 0.06% at this particular frequency when averaging for this long. It might be interesting to see a calibration frequency dependent allan deviation plot.
  17257   Fri Nov 11 14:15:45 2022 PacoSummaryCalibrationSingle arm cal with 5 lines

I turned all the LSC oscillators on and used the digital demod for BEATYF (fine y als beat) to grab the data. For this I added notches onto SCY ETMY LSC filter banks FM6-10 to account for these lines at 30.92, 211.10, 313.31, 315.17 Hz (basically just reusing the osc models) and adjusted the sensing matrix to actuate on ITMY.

I aligned and locked YARM, and then I aligned and locked the YAUX. The lock seems pretty robust with an avg green transmission GTRY ~ 0.185 counts for TEM00.

Trying to see other lines appear on the BEATYF demod channels, but so far no luck. I scaled down the exc gain from 500 counts (snr ~ 20 at 575 Hz) and verified the notches are working. Since I am unsure of the issue here and WFS tests are happening at 4 today, I decided to take some beat data under different conditions -->

HEPA OFF and PSL Shutter Open

gpstime start = 1352244763 gpstime end = 1352245405


PSL Shutter Closed

gpstime start = 1352245574

gpstime end = 1352246216


PSL Shutter Closed

gpstime start = 1352246240 gpstime end = 1352246882
  17264   Mon Nov 14 14:52:56 2022 PacoConfigurationSUSBHD SUS Coil output balance

[JC, Paco]

We installed a steering mirror intersecting the BHD beam path and put the AS beam on the ITMY Oplev QPD (see Attachment #1 for a photo of this temporary hack) . This is done to do coil balancing of AS1/AS4, LO1/LO2. QPD sees ~ 10000 counts when the beam is centered.

[Paco, Yuta]

We follow this procedure -- but with different sensors for all BHD suspension coil output balancing.


We dither BUTT first, lock the LO-AS fringe (DC lock), and look at the residual LO_PHASE spectrum to minimize POS coupling. We then unlock, misalign LO beam and look at the hijacked Oplev (ITMY) while dithering POS to minimize PIT and YAW couplings.


We dither BUTT first, lock thChangeset summarye LO-AS fringe (DC lock), and look at the residual LO_PHASE spectrum to minimize POS coupling. We then unlock, misalign AS beam and look at the hijacked Oplev (ITMY) PIT/YAW residual noise while dithering POS to minimize PIT/YAW coupling.

Changeset summary

The new coil output gains are summarized in the table below:

Optic / Coil UL UR LR LL
AS1 -0.939 1.040 -1.026 0.995
AS4 -0.9785 0.9775 -1.0695 0.9745
LO1 -0.939 1.003 -1.074 0.984
LO2 -1.051 1.342 -0.976 0.631

Finally, I reverted the hacked QPD setup to restore the ITMY OPLEV.

  17266   Tue Nov 15 11:04:01 2022 PacoSummaryCalibrationSingle arm cal with 5 lines

YALS Hardware inspection

The ALS Cal for ITMY actuation was off by ~ 1000, so I decided I don't trust / understand what this beatnote is seeing. Then, I went in the lab to inspect things;

  1. ALS DFD and DEMOD: The demod box was off no perhaps on purpose, more likely by accident... the switch was off in the rear of the 1U box in the LSC rack... Also, the DB9 cable labeled ALS was disconnected. Fixed both these bugs and verified it worked all the way into cds.
  2. YARM Green injection: Did some re-alignment, and noted the mode was hopping a bit too much (once every couple of seconds) so I rotated the half waveplate before the green PZT steering mirrors by  ~ 8 deg and used the latter to get a GTRY transmission of > 0.320 (counts), about 75% more than last time. Finally I made sure the mode is robustly locked for several minutes.

Beatnote calibration

The factor above may be explained by the bogus signals coming into the beat fine phase channels on the ALS model. After locking the YARM with POY11, and locking the YAUX to the YARM cavity, I turned on the LSC oscillators -- all five of them see Attachment #1 for the screenshot -- and looked for the lines in the C1:ALS-BEATY_FINE_PHASE_OUT channel. Here, again the sensing output matrix was set up to actuate on ITMY, while the ETMY (control point of YARM loop) had all the output notches on. Once all lines were visible in the YAUX beatnote, I had to reduce the LSC filter gain from 0.012 to 0.011 to prevent loop oscillations... Then I recorded the gpstimes below with different conditions.

  • HEPA ON (JC Inside lab)
    • gpstime = 1352575798 to 1352576046
  • HEPA OFF (JC Inside lab)
    • gpstime = 1352576125 to 1352576216
  • HEPA OFF (JC in the control room)
    • gpstime = 1352576641 to 1352577591


Basically, only the DARM line was recorded (DQ channs) so I modified the c1cal to store the SIG_OUT and DEMOD_I_IN1 channels for both BEATX and BEATY cal signals. This means I need to repeat this measurement. In the meantime I am also going to try and rerun calibrate the BEAT HZ transfer function.

  17268   Tue Nov 15 17:08:59 2022 PacoUpdateBHDRequest for estimates

[Yehonathan, Yuta, Paco]

We would like to estimate:

  • LO phase sensitivty (for RF55 + audio dither scheme), as a function of RF demod angle (both I and Q); not to be confused with audio dither angle.
  • LO phase sensitivity (for all schemes like in Attachment #2 of this previous post) but with some nonzero MICH offset.
  • LO phase sensitivity (for RF55 + audio dither scheme) but with the uBHDBS (44:56) values from this post.
  17269   Tue Nov 15 17:58:00 2022 PacoConfigurationCamerasPOP camera realignment after IFO alignment

[Paco, Yuta]

I swapped the 1 inch BS and lenses along the POP beam to clear the apertures and avoid clipping this beam. The results are illustrated by the attached pictures; this was done right after Yuta had optimized IFO alignment so it's hopefully a good reference from now on. Yuta also tuned the alignment of BHDC path in ITMY table, which mostly improved the alignment to DCPD A (90-ish counts improved to 100-ish counts with ITMY single bounce).

  17278   Thu Nov 17 12:24:48 2022 PacoConfigurationCamerasITMX Camera -- attempt at fix

I found that an old BNC cable for ITMXF video existed so I first tried swapping both ends of the cable, one on the ITMX viewport and the other one in the video MUX input in the rear. This didn't fix the issue.

I searched around in the CCD cabinet by XARM and found an identical analog camera so I swapped it and got the same image ...

I then searched for a AC/DC supply cable, but couldn't find one.


Coming in this morning, I found ITMX Camera malfunctioning.


  17303   Wed Nov 23 14:59:11 2022 PacoSummaryBHDBHD_DIFF sensitivity to BS dither with MICH Offset

[Yuta, Paco, Anchal]

We measured

(a) BHDC_DIFF sensitivity to BS dither for a set of MICH offsets.


  • MICH locked with AS55_Q
    • The MICH offset was varied below
  • LO_PHASE locked with BH55_Q
    • Balanced DCPD_A and DCPD_B by applying a digital gain of 1.00 to DCPD_A
    • Changed the BH55 demod angle to 140.07 deg to minimize BH55_I
  • BS dither at 311.1 Hz
    • Use newly added HPC_BS Lockins to readback the demodulated signals

Results & Discussion

The analysis was done with the '/cvs/cds/rtcds/caltech/c1/Git/40m/scripts/CAL/BHD/BHD_DIFFSensitivity.ipynb' notebook.

Attachment #1 shows the main result showing the sensitivity of various demodulated error signals at 311.1 Hz for a set of 21 MICH offsets. We noted that if we didn't randomize the MICH offset scan, we observed a nonzero "zero crossing" for the offset.
Note that, although LO_PHASE loop was always on to control the LO phase to have zero crossing of BH55_Q, actual LO phase is not constant over the measurement, as MICH offset changes BH55_Q zero crossing.
When MICH offset is zero, LO_PHASE loop will control the LO phase to 0 deg (90 deg away from optimal phase), and BHDC_DIFF will not be sensitive to MICH, but when MICH offset is added, BHDC_DIFF start to have MICH sensitivity (measurement is as expected).
For BHDC_SUM, MICH sensitivity is linear to MICH offset, as it should be the same as ASDC, and does not depend on LO phase (measurement is as expected).
For BH55_Q, MICH sensitivity is maximized at zero MICH offset, but reduces with MICH offset, probably because LO phase is also being changed.

  17318   Mon Nov 28 16:58:20 2022 PacoUpdateCDSpypi package added

[Paco, Tega]

I added the pypi package "restoreEpics" to the donatella clone under test. This is required by some of Anchal's scripts that turn on F2A filters as well as other recovery stages during some measurements.

  17319   Mon Nov 28 18:21:50 2022 PacoSummaryBHDBH44 prep

I checked the LSC rack to evaluate what we might need to generate 44 MHz rf in the hypothetical case we go from BH55 to BH44 (a.k.a. double RF demod scheme). There is an 11 MHz LO port labeled +16 dBm (measured 9 Vpp ~ 23 dBm actually) on the left hand side. Furthermore, there is an unused 55 MHz port labeled "Spare 55 LO". I checked this output to be 1.67 Vpp ~ +8.4 dBm. Anyways the 55 MHz doesn't look very nice; after checking it on the spectrum analyzer it seems like lower frequency peaks are polluting it so it may be worth checking the BH55 LO (labeled REFL 55) signal to see if it's better. Anyways we seem to have the two minimum LOs needed to synthesize 44 MHz in case we move forward with BH44.

[Paco, Yuta]

We confirmed the noisy 55 MHz is shared between AS55, BH55 and any other 55 MHz LOs. Looking more closely at the spectrum we saw the most prominent peaks at 11.06 MHz and 29.5 MHz (IMC and PMC nominal PM freqs). This 55 MHz LO is coming all the way from the RF distribution box near the IOO rack. According to this diagram, this 55 MHz LO should have gone through a bandpass filter; interestingly, checking the RF generation box spare 55 MHz the output is *cleaner* and displays ~ 17 dBm level... ??? Will continue investigating when we actually need this RF.

  15857   Wed Mar 3 12:00:58 2021 Paco, AnchalHowToIMCMC_F ASD

[Paco, Anchal]

- Saved BURT backup in /users/anchal/BURTsnaps/
- Copied existing code for mode cleaner noise budget from /users/rana/mat/mc. Will work on this from home to convert it inot new pynb way.

Get baseline IMC measurements (passive):
- MC_F:
  - What is MC_F? Let's find out.
  - On MC_F Cal window titled 'C1IOO-MC_FREQ', we turned off ON/OFF and back on again.
  - Using diaggui, we measured ASD of MC_F channel in units of counts/rtHz.

[Rana, Paco]

- Using diaggui, measured ASD from a template (under /users/Templates) and overlay the 1/f noise of the NPRO (Attachment 1)

[Anchal, Paco]

- WFS Master
  - Went through the schematic and tried to understand what is happening.
  - Accidentally switched on MC WF relief (python 3). Bunch of things were displayed on a terminal for a while and then we Ctrl-C it.
  - The only thing we noticed that change is a slight increase in WFS1 Yaw, and a corresponding decrease in WFS1 Pitch, WFS2 Pitch, and WFS2 Yaw.
  - We need to find out what this script does.

Future work:

  • Create an automated script for taking MC_F_DQ spectrum and refer it against reference trace.
  • Use pynb to create a noise budget for mode cleaner.
  • Identify excess noise between 10-40 Hz.
  • Configure output matrix in WFS Master to reduce the noise. Automate this process as well.
  15861   Thu Mar 4 10:54:12 2021 Paco, AnchalSummaryLSCPOY11 measurement, tried to lock Green Yend laser

[Paco, Anchal]

- First ran burtgooey as last time.

- Installed pyepics on base environment of donatella

- Clicked on ON in the drop down of "! More Scripts" below "! Scripts XARM" in C1ASS.adl
- Clicked on "Freeze Outputs" in the same menu after some time.
- Noticed that the sensing and output matrix of ASS on XARM and YARM look very different. The reason probably is because the YARM outputs have 4 TT1/2 P/Y dof instead of BS P/Y on the XARM. What are these TT1/2?

(Probably, unrelated but MC Unlocked and kept on trying to lock for about 10 minutes attaining the lock eventually.)

Locking XARM:
- From scripts/XARM we ran lockXarm.py from outside any conda environment using python command.
- Weirdly, we see that YARM is locked??? But XARM is not. Maybe this script is old.
- C1:LSC-TRY-OUTPUT went to around 0.75 (units unknown) while C1:LSC-TRX-OUTPUT is fluctuating around 0 only.

POY11 Spectrum measurement when YARM is locked:
- Created our own template as we couldn't find an existing one in users/Templates.
- Template file and data in Attachment 2.
- It is interesting to see most of the noise is in I quadrature with most noise in 10 to 100 Hz.
- Given the ARM is supposed to be much calmer than MC, this noise should be mostly due to the mode cleaner noise.
- We are not sure what units C1:LSC-POY11_I_ERR_DQ have, so Y scale is shown with out units.

Trying to lock Green YEND laser to YARM:
- We opened the Green Y shutter.
- We ensured that when temperature slider og green Y is moved up, the beatnote goes up.
- ARM was POY locked from previous step.
- Ran script scripts/YARM/Lock_ALS_YARM.py from outside any conda environment using python command.
- This locked green laser but unlocked the YARM POY.

Things moving around:
- Last step must have made all the suspension controls unstable.
- We see PRM and SRM QPDs moving a lot.
- Then we did burt restore to /opt/rtcds/caltech/c1/burt/autoburt/today/08:19/*.snap to go back to the state before we started changing things today.

[Paco left for vaccine appointment]

- However the unstable state didn't change from restore. I see a lot of movement in ITMX/Y. PRM and BS also now. Movement in WFS1 and MC2T as well.
 - I closed PSL shutter as well to hopefully disengage any loops that are still running unstably.
 - But at this point, it seems that the optics are just oscillating and need time to come back to rest. Hopefully we din't cause too much harm today :(.

My guess on what happened:

  • Us using the Lock_ALS_YARM.py probably created an unstable configuration in LSC matrix and was the start of the issue.
  • On seeing PRM fluctuate so much, we thought we should just burst restore everything. But that was a hammer to the problem.
  • This hammer probably changed the suspension position values suddenly causing an impulse to all the optics. So everything started oscillating.
  • Now MC WFS is waiting for MC to lock before it stablizes the mode cleaner. But MC autolocker is unable to lock because the optics are oscillating. Chicken-egg issue.
  • I'm not aware of how manually one can restore the state now. My only known guess is that if we wait for few hours, everything should calm back enough that MC can be locked and WFS servo can be switched on.
  15862   Thu Mar 4 11:59:25 2021 Paco, AnchalSummaryLSCWatchdog tripped, Optics damped back

Gautam came in and noted that the optics damping watchdogs had been tripped by a >5 magnitude earthquake somewhere off the coast of Australia. So, under guided assistance, we manually damped the optics using following:

  • Using the scripts/SUS/reEnableWatchdogs.py script we re-enabled all the watchdogs.
  • Everything except SRM was restored to stable state.
  • Then we clicked on SRM in SUS-> Watchdogs, disabled the Oplevs, shutdown the watchdog.
  • We changed the threshold for watchdog temporarily to 1000 to allow damping.
  • We enabled all the coil outputs  manually. Then enabled watchdog by clicking on Normal.
  • Once the SRM was damped, we shutdown the watchdog, brought back the threshold to 215 and restarted it.

Gautum also noticed that MC autolocker got turned OFF by me (Anchal), we turned it back on and MC engaged the lock again. All good, no harm done.

  15877   Mon Mar 8 12:01:02 2021 Paco, AnchalSummarytrainingInvestigate how-to XARM locking

[Paco, Anchal]

- Started zoom stream; thanks to whoever installed it!
- Spent some time trying to understand how anything we did last thursday lead to the sensing matrix change, but still cannot figure it out. 
- Tracking back on our actions, at ~10:30 we ran burt Restore with the 08:19/.*snap and in lack of a better suspect, we blame it on that action for now.

# ARM locking??
- Reading (not running) the scripts/XARM/lockXarm.py script and try to understand the workflow. It is pretty confusing that the result was to lock Yarm last time.
- It looks like this script was a copy of lockYarm.py, and was never updated (there's a chance we ran it for the first time last thursday)
- *Is there a script to lock the Arms?* Or should we write one? To write one, we first attempt a manual procedure;
    1. No need to change RFPD InMTRX
    2. All filters inputs / outputs are enabled 
    3. Outputs from XARM and YARM in the Output matrix are already going to ETMX and ETMY
      - Maybe we can have the ARM lock engage by changing the MC directly?
    4. Change C1:SUS-MC2_POS_OFFSET from -38 to -0, and enable C1:SUS-MC2_POS_OFFSET_ON
    5. Manually scan MC2_POS_OFFSET to 250 (nothing happens), then -250, then back to -38 (WFS1 PIT and YAW changed a little, but then returned to their nominal values)
      - Or maybe we need to provide the right gain...
    6. Disabled C1:SUS-MC2_POS_OFFSET_ON (back to nominal state)
    7. Look into manually changing C1:LSC-XARM_GAIN;
      From the command line using python:
      >> import epics
      >> ch_name = 'C1:LSC-XARM_GAIN'
      >> epics.caput(ch_name, 0.155) # nominal = 0.150
      - Could be unrelated, but we noted a slow spike on C1:PSL-FSS_PCDRIVE (definitely from before we changed anything)
      - Still nothing is happening
    8. Changed the gain to 0.175, then back to 0.150, no effect... then 0.2, 0.3 ...
      - Stop and check SUS_Watchdogs (should not have changed?) and everything remains nominal
      - Revert all changes symmetrically.
      - Could we have missed enabling FM1?
      - Briefly lost MC lock, but it came back on its own (probably unrelated)

- Wrap it up for the day. In summary; no harm done to our knowledge.

  15884   Tue Mar 9 10:57:06 2021 Paco, AnchalSummaryIMCXARM lock and POX spectra

[Paco, Anchal]

- Upon arrival, MC is locked, and we can see light in MON5 (PRM) (usually dark).

# XARM locking
- Read through "XARM POX" script (path='/cvs/cds/rtcds/caltech/c1/burt/c1configure/c1configureXarm')
- Before running the script, we noticed the PRM watchdog is down, so we manually repeat the procedure from last time, but see more swinging even though the watchdog is active.
- Run a reEnablePRMWatchdogs.py script (a copy of reEnableWatchdogs.py with optics=['PRM']), which had the same effect. 
- We manually disable the watchdog to recover the state we first encountered, and wait for the beam in MON5 to come to rest.
    - The question is; is it fine to lock Xarm with PRM watchdog down?
    - To investigate this, we look at the effect of the offset on the unwatchdog-PRM.
    - Manually change 'PRM_POS_OFFSET' to 200, and -800 (which is the value used in the script) with no effect on the PRM swinging.
- Moving on, run IFO > CONFIGURE > ! (X Arm) > RESTORE XARM (XARM POX), and ... success.

# MC-POX noise spectra
- With XARM locked, open diaggui and take spectra for C1:LSC-POX11_I_ERR_DQ, C1:LSC-POX11_Q_ERR_DQ, C1:IOO-MC_F_DQ
- Lost XARM lock while we were figuring out unit conversions...
    - Assuming 2.631e-13 m/counts (6941) and using 37.79 m (arm length), 1064.1 nm wavelength, we get a calibration factor of 2.631e-13 * c / (2*L*lambda) ~ 0.9809 Hz/count 
    - (FAQ?, how to find/compute/measure the correct calibration factors?)
- Relock XARM, retake spectra. Attachment 1 has plots for POX11_I/Q_ERR_DQ spectrum (cts/rtHz, we couldn't find relevant calibration) and MC_F_DQ in (Hz/rtHz from referring to 15576, we couldn't get the units to show on y scale.)

# MC-POY noise spectra (attempt)
- Now, run IFO > CONFIGURE > ! (Y Arm) > RESTORE YARM (YARM POY), and XARM locks (why?)
    - Could PRM watchdog being down be the cause? 
- Try C1ASS > (YARM) ! More Scripts > ON, and looked at YARM PIT/YAW striptool. 
- C1ASS > (YARM) ! Freeze Outputs, then OFF
- Go back to IFO > CONFIGURE > ! (Y Arm) > Align YARM  (ASS ON: Unfreeze), try running this then Freeze, then OFF Zero Outputs.
- Try RESTORE YARM (POY) again, still not working.
- Try RESTORE YARM ALS, then try again after opening the shutter, but also fail to lock AUX.
    - Is the PRM WD behind some evil misalignment? Will move forward with XARM bc it is happy.

# ARM locking
- Attempted the IFO > CONFIGURE > ! (X Arm) > RESTORE Xarm (XARM ALS) but green failed to lock and we lost XARM lock.
- Try to recover XARM lock... success. It's nice to have a (repeatable) checkpoint.
- Attempt YARM lock. Not successful. It just seems like the lock Triggers are not raised (misalignment?)
    - From C1SUS_ETMY, try changing the bias "C1:SUS-ETMY_YAW_OFFSET" manually to reduce the OPLEV_YERROR. Changed from -47 to -57.
    - Retry YARM lock script... no luck
    - From C1SUS_PRM, try changing the bias "C1:SUS-PRM_PIT_OFFSET" manually to reduce OPLEV errors. Changed from 34 to 22 with no effect, then realized the coil outputs are disabled because the WD is down...
    - So we do the following BIAS changes "C1:SUS-PRM_PIT_OFFSET" = 34 > 770 and "C1:SUS-PRM_YAW_OFFSET" = 134 > -6
    - Enable all Coil Outputs, turn WD to Normal, turn OPLEVs ON, (this time the beam does not swing like crazy).
    - Fine tune BIASes "C1:SUS-PRM_PIT_OFFSET" = 770 > 805  and "C1:SUS-PRM_YAW_OFFSET" = -6 > 65
        - Saw YARM locking briefly, then unlocking, but we stopped once the OPLEV_ERRs no longer overloaded (from magnitudes > 50 to ~ 40).
- Retry YARM lock... no luck
    - From C1SUS_ETMY, try changing the bias "C1:SUS-ETMY_PIT_OFFSET" from -1 to 6. 

Stop for the day. Leave XARM locked, MC locked. 

  15893   Wed Mar 10 11:46:22 2021 Paco, AnchalSummaryIMCIMC free swinging prep

[Paco, Anchal]

# Initial State
- MC is locked. The PRM monitor shows some oscillations.
- POP monitor shows light flashing once in a while.
- AS monitor shows one beam along with some other flashing beam around it.
- PRM Watchdog is tripped and shutdown. Everything else is normal except for overload on SRM OpLevs.
- Donatella got a mouse promotion

# Reenabling PRM watchdog:
- The custom reEnablePRMWatchdog.py has been deleted.
- Tried enabling the coil outputs manually and switching watchdog to Normal.
- Again saw large fluctuations like yesterday.
- Probably still the same issue of how current calculated actuations to the coils is in range -600 to -900 and gives and impulse to the optics when suddenly turned on.
- Waiting for PRM to damp down a little.
- Today we plan to change the position bias on PRM C1:SUS-PRM_POS_OFFSET instead of changing biases in pitch and yaw.
- Changing C1:SUS-PRM_POS_OFFSET from 0 to +/- 100 without enabling the coils, it seems upper and lower coils are anticorrelated with just changing the position. So going back to changing pitch.
- Changing C1:SUS-PRM_PIT_OFFSET from 0 -> 780. Switched on watchdog to normal.
- PRM damped down. OpLev errors are also within range.
- Enabled both OpLevs.

# Try locking Y-Arm
- IFO>CONFIGURE>YARM>Restore YARM (POY) using Donatella. See a bunch of python error messages in the call complaining about unable to find some python 2 files. Closed it with Ctrl-C after a stuck state.
- Tried running it on Pianosa, the script ran without error but Y-Arm didn't lock.

# Try locking X-Arm
- IFO>CONFIGURE>XARM>Restore XARM (POX) on Donatella. Again a bunch of OSError messages. Donatella is not configured properly to run scripts.
- Tried running it on Piasnosa, the script ran without error but X-Arm didn't lock.
- This might mean that both arms are misaligned or the BS/PRM is misaligned.
- Moving around C1:SUS-PRM_PIT_OFFSET and C1:SUS-PRM_YAW_OFFSET in order to see if the transmitted light is misalgined. Both arms are set to acquire lock if possible. No luck.

# Hypothesis: The Arm cavity is not aligned within itself (ITM-ETM)
- Will try to lock X-Arm with green light while tuning the ETMX. Hopefully the BS and ITM are aligned so that once we align ETMX to get a green lock, the IR will also lock from the other side.
- Running IFO>CONFIGURE>XARM>Restore XARM (ALS) on Pianosa. No lock, moving forward with tunning ETMX pitch and yaw offsets. Nothing changed. Brought back to same values.

[Rana joined, Anchal moved to Rossa from Pianosa]

# Moving on to IMC suspensions characterization:
- Closed the PSL shutter, to our suprise, the MC was still locked. We thought this would take away any light from IMC but it doesn't. Maybe the IFO Overview needs to show the schematic in a way where this doesn't happen: "No light from any laser entering the MC but it still is locked with a resonating field inside."
- Shutting IMCR shutter (hoping that would unlock the IMC), still nothing happend.
- Tried shutting PSL shutter from Rossa, nothing happened to MC lock still.
- Closed shutter IOO>Lock MC> Close PSL and this unlocked the IMC. Found out that this shutter channel is C1:PSL-PSL_ShutterRqst while the one from the sitemap>Shutter>PSL changes C1:AUX-PSL_ShutterRqst. Some clarification on these medm screens would be nice.
- Disabled the MC autolocked from IOO>Lock MC screen (C1:IOO-MC_LOCK_ENABLE).
- Checked the scripts/SUS/freeswing.py to understand how kick is delivered and optic is left to swing freely.
- Next, we are looking at the C1SUS_MC1 screen to understand what channels to read during data acquisition.
- In sensor matrix, we see INMON for each sensor which is probably raw counts data from the OSEMs. Rana mentioned that OSEM data comes out in units of microns. These are C1:SUS-MC1_ULSEN_OUTPUT (and so on for UR, LL, LR, SD).

- In prep for finishing, recovered Autolocker by first opening the PSL mechanical shutter, then re-enabling the Autolocker. The IMC lock didn't immediately recover, and we saw some fuzz on the PSL-FSS_FAST trace, so we closed the shutter again, waited a minute, then re-opened it and MC caught its lock.

  15897   Wed Mar 10 15:35:25 2021 Paco, AnchalSummaryIMCIMC free swinging experiment set to trigger at 5:00 am

A tmux session named "MCFreeSwingTest" will run on Rossa. This session is running script scripts/SUS/freeSwingMC.py (also attached) which will trigger at 5:00 am to impart 30000 counts kick to MC1, MC2, and MC3 after shutting PSL shutter and disabling the MC autolocker. It will let them freely swing for 1050 sec and will repeat 15 times to allow some averaging. In the end, it will undo all the changes it does and switches on autolocker on IMC. The script is set to restore any changes in case it fails at any point or a Ctrl-C is detected.

  15902   Thu Mar 11 08:13:24 2021 Paco, AnchalUpdateSUSIMC First Free Swing Test failed due to typo, restarting now

[Paco, Anchal]

The triggered code went on at 5:00 am today but a last minute change I made yesterday to increase number of repititions had an error and caused the script to exit putting everything back to normal. So as we came in the morning, we found the mode cleaner locked continuously after one free swing attempt at 5:00 am. I've fixed the script and ran it for 2 hours starting at 8;10 am. Our plan is to get some data atleast to play with when we are here. If the duration is not long enough, we'll try to run this again tomorrow morning. The new script is running on same tmux session 'MCFreeSwingTest' on Rossa

10:13 the script finished and IMC recovered lock.

Thu Mar 11 10:58:27 2021

The test ran succefully with the mode cleaner optics coming back to normal in the end of it. We wrote some scripts to read data and analyze it. More will come in future posts. No other changes were made today to the systems.

  15912   Fri Mar 12 11:44:53 2021 Paco, AnchalUpdatetrainingIMC SUS diagonalization in progress

[Paco, Anchal]

- Today we spent the morning shift debugging SUS input matrix diagonalization. MC stayed locked for most of the 4 hours we were here, and we didn't really touch any controls.

  15919   Mon Mar 15 08:55:45 2021 Paco, AnchalSummarytraining 

[Paco, Anchal]

  • Found IMC locked upon arrival.
  • Since "allegra" was set up as an additional workstation, we tried using it but discovered the monitor ist kaput. For the sake of debugging, we tested VGA and DVI inputs and even the monitor lying around (also labeled "allegra") with no luck. So <ssh> it is for now.

IMC Input sensing matrix

  • Rana joined us and asked us to use Rossa for now so that we can sit socially distantly.
  • Attaching some intermediate results on our analysis as pdf and zip file containing all the codes we used.
  • We used channels C1:SUS-MC1_USSEN_OUTPUT  (16 Hz channels) and so on which might not be the correct way to do it as Rana pointed out today, we should have used channels like C1:SUS-MC1_SENSOR_UL etc.
  • During the input matrix calculation, we used the method of TF estimate (as mentioned in 4886) to calculate the sensor matrix and inverted it and normalized all rows with the maximum absolute value element (we tried few other ways of normalization with no better results either).
  • We found the peak frequencies by fitting lorentzian to the sensor data rotated by the current input matrix in the system. We also tried doing this directly on the sensor data (UL for POS, UR for PIT, LR for YAW and SD for SIDE as this seemed to be the case in the old matlab codes) but with no different results.
  • The fitted peak frequencies, Q and amplitude values are in fittedPeakFreqs.yml in the attached zip.
  15926   Tue Mar 16 19:13:09 2021 Paco, AnchalUpdateSUSFirst success in Input Matric Diagonalization

After jumping through few hoops, we have one successful result in diagonalizing the input matrix for MC1, MC2 and MC3.


  • Attachment 2 has the code file contained. For now, we can only guarantee it to work on Donatella in conda base environment. Our code is present in scripts/SUS/InMatCalc
  • We mostly follow the steps mentioned in 4886 and the matlab codes in scripts/SUS/peakFit.
  • Data is first multiplied with currently used inpur matrix to get time series data in DOF (POS, PIT, YAW, SIDE) basis.
  • Then, the peak frequencies of each resonance are identified.
  • For getting these results, we did not attempt to fit the peaks with lorentzians and took the maxima point of the PSD to get the peak positions. This is only possible if the current input matrix is good enough. We have to adjust some parameters so that our fitting code works always.
  • TF estimate between the sensor data w.r.t UL sensor is taken and the values around the peak frequencies of oscillations are averaged to get the sensing matrix.
  • This matrix is normalized along DOF axis (columns in our case) and then inverted.
  • After inversion, another normaliation is done along DOF axis (now rows).
  • Finally we plot the comparison of ASD in DOF basis when using current input matrix and when using our calculated inpur matrix (diagonalizing).
  • You can notice in Attachment 1 that after the diagonalization, each DOF shows resonance at only one and its own resonance frequency while earlier there was some mixing shown.
  • Absolute value of the calculated DOF might have changed and we need to calibrate them or apply appropriate gain factors in the DOF basis filter chains.

Next steps:

  • We'll complete our scripts and make them more general to be used for any optic.
  • We'll combine all of them into one single script which can be called by medm.
  • In parallel, we'll start onwards from step 2 in 15881.
  • Anything else that folks can suggest on our first result. Did we actually do it or are we fooling ourselves?
  15928   Wed Mar 17 09:05:01 2021 Paco, AnchalConfigurationComputers40m Control Room Changes
  • Switched positions of allegra and donatella.
  • While doing so, the hdmi cable previously used by donatella snapped. We replaced this cable by another unused cable we found connected only on one end to rossa. We should get more HDMI cables if that cable was in use for some other purpose.
  • Paco bought a bluetooth speaker/mic that is placed infront of allegra and it's usb adapter is connected to iMac's keyboard in the bottom. With the new camera installed, the 40m video call environment is now complete.
  • Again, we have placed allegra's monitor for place holder but it is not working and we need new monitors for it in future whenever it is going to be used.
  15937   Thu Mar 18 09:18:49 2021 Paco, AnchalUpdateSUSTesting of new input matrices with new data

[Paco, Anchal]

Since the new generated matrices were created for the measurement made last time, they are of course going to work well for it. We need to test with new independent data to see if it works in general.

  • We have run scripts/SUS/InMatCal/freeSwingMC.py for 1 repition and free swinging duration of 1050s on tmux session FreeSwingMC on Rossa. Started at GPS: 1300118787.
  • Thu Mar 18 09:24:57 2021 : The script ended successfully. IMC is locked back again. Killing the tmux session.
  • Attached are the results of 1-kick test, time series data and the ASD of DOFs for calculated using existing input matrix and our calculated input matrix.
  • The existing one was already pretty good except for maybe the side DOF which was improved on our diagonalization.


After Anchal left for his test, I took the time to set up the iMAC station so that Stephen (and others) can remote desktop into it to use Omnigraffle. For this, I enabled the remote login and remote management settings under "Sharing" in "System Settings". These two should allow authenticated ssh-ing and remote-desktopping respectively. The password is the same that's currently stored in the secrets.

Quickly tested using my laptop (OS:linux, RDP client = remmina + VNC protocol) and it worked. Hopefully Stephen can get it to work too.

  15943   Fri Mar 19 10:49:44 2021 Paco, AnchalUpdateSUSTrying coil actuation balance

[Paco, Anchal]

  • We decided to try out the coil actuation balancing after seeing some posts from Gautum about the same on PRM and ETMY.
  • We used diaggui to send swept sine excitation signal to C1:SUS-MC3_ULCOIL_EXC and read it back at C1:SUS-MC3_ASCPIT_IN1. Idea was to create transfer function measurements similar to 15880.
  • We first tried taking the transfer function with excitation amplitude 0f 1, 10, 50, 200 with damping loops on (swept from 10 to 100 Hz lograthmically in 20 points).
  • We found no meaningful measurement and looked like we were just measuring noise.
  • We concluded that it is probably because our damping loops are damping all the excitation down.
  • So we decided to switch off damping and retry.
  • We repeated teh above measurements going up in amplitudes of excitation as 1, 10, 20. We saw the oscillation going out of UL_COIL but the swept sine couldn't measure any meaningful transfer function to C1:SUS-MC3_ASCPIT_IN1. So we decided to just stop. We are probably doing something wrong.

Trying to go back to same state:

  • But C1:SUS-MC3_ASCYAW_INMON had accumulated about 600 offset and was distrupting the alignment. We switched off C1:SUS-MC3_ASCYAW_SW2 hoping the offset will go away once the optic is just damped with OSEM sensors, but it didn't.
  • Even after minutes, the offset in C1:SUS-MC3_ASCYAW_INMON kept on increasing and crossed beyond 2000 counts limit set in C1:IOO-MC3_YAW filter bank.
  • We tried to unlock the IMC and lock it back again but the offset still persisted.
  • We tried to add bias in YAW DOF by increasing C1:SUS-MC3_YAW_OFFSET, and while it was able to somewhat reduce the WFS C1:SUS-MC3_ASCYAW_INMON offset  but it was misalgning the optic and the lock was lost. So we retracted the bias to 0 and made it zero.
  • We tried to track back where the offset is coming from. In C1IOO_WFS_MASTER.adl, we opened the WFS2_YAW filter bank to see if the sensor is indeed reading the increasing offset.
  • It is quite weird that C1:IOO-WFS2_YAW_INMON is just oscillating but the output in this WFS2_YAW filter bank is slowly increasing offset.
  • We tried to zero the gain and back to 0.1 to see if some holding function is causing it, but that was not the case. The output went back to high negative offset and kept increasing.
  • We don't know what else to do. Only this one WFS YAW output is increasing, everything else is at normal level with no increasing offset or peculiar behavior.
  • We are leaving C1:SUS-MC3_ASCYAW_SW2 off as it is disrupting the IMC lock.

[Jon walked in, asked him for help]

  • Jon suggested to do burt restore on IOO channels.
  • We used (selected through burtgooey):
    burtwb -f /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2021/Mar/19/08:19/c1iooepics.snap -l /tmp/controls_1210319_113410_0.write.log -o /tmp/controls_1210319_113410_0.nowrite.snap -v <
  • No luck, the problem persists.
  15951   Mon Mar 22 11:57:21 2021 Paco, AnchalUpdateSUSTrying coil actuation balance

[Paco, Anchal]

  • For MC coil balancing we will use the ASC (i.e. WFS) error signals since there are no OPLEV inputs (are there OPLEVs at all?).

Test MC1

  • Using the SUS screen LockIns the plan is to feed excitation(s) through the coil outputs, and look at the ASC(Y/P) error signals.
  • A diaggui xml template was saved in /users/Templates/SUS/MC1-actDiag.xml which was based on /users/Templates/SUS/ETMY-actDiag.xml
  • Before running the measurement, we of course want to plug our input matrix, so we ran /scripts/SUS/InMatCalc/writeMatrix.py only to find that it tripped the MC1 Watchdog.
    • The SIDE input seems to have the largest rail, but we just followed the procedure of temporarily increasing the WD max! threshold to allow the damping action and then restoring it.
    • This happened because in latest iteration of our code, we followed an advice from the matlab code to ensure the SIDE OSEM -> SIDE DOF matrix element remains positive, but we found out that MC1 SIDE gain (C1:SUS-MC1_SUSSIDE_GAIN) was set to -8000 (instead of a positive value like all other suspensions).
    • So we decided to try our new input matrix with a positive gain value of 8000 at C1:SUS-MC1_SUSSIDE_GAIN and we were able to stablize the optic and acquire lock, but...
    • We saw that WFS YAW dof started accumulating offset and started disturbing the lock (much like last friday). We disabled the ASC Input button (C1:SUS-MC1_ASCYAW_SW2).
    • This made the lock stable and IMC autolocker was able to lock. But the offset kept on increasing (see attachment 1).
    • After sometime, the offset begain to exponential go to some steady state value which was around -3000.
  • We wrote back the old matrix values and changed the C1:SUS-MC1_SUSSIDE_GAIN back to -8000. But the ASCYAW offset remained to the same position. We're leaving it disabled again as we don't know how to fix this. Hopefully, it will organically come back to small value later in the day like last time (Gautum just reenabled the ASCYAW input and it worked).

Test MC3

  • Defeated by MC1, we moved to MC3.
  • Here, the gain value for C1:SUS-MC3_SUSSIDE_GAIN was already positive (+500) so it could directly take our new matrix.
  • When we switched off watchdog, loaded the new matrix and switched the watchdog back on.
  • The IMC lock was slightly distrupted but remain locked. There was no unusual activity in the WFS sensor values. However, we saw the the SIDE coil output is slowly accumulating offset.
  • So we switched off the watchdog before it will trip itself, wrote back the old matrix and reinstated the status quo.
  • This suggests we need to carefully look back our latest changes of normalization and have new input matriced which keep the system stable other than working on paper with offline data.
  15954   Mon Mar 22 19:07:50 2021 Paco, AnchalUpdateSUSTrying coil actuation balance

We found that following protocol works for changing the input matrices to new matrices:

  • Shut the PSL shutter C1:PSL-PSL_ShutterRqst. Switch off IMC autolocker C1:IOO-MC_LOCK_ENABLE.
  • Switch of the watchdog, C1:SUS-MC1_LATCH_OFF.
  • Update the new matrix. (in case of MC1, we need to change sign of C1:SUS-MC1_SUSSIDE_GAIN for new matrix)
  • Switch on the watchdog back again which enables all the coil outputs. Confirm that the optic is damped with just OSEM sensors.
  • Switch on IMC autolocker C1:IOO-MC_LOCK_ENABLE and open PSL shutter C1:PSL-PSL_ShutterRqst.

We repeated this for MC2 as well and were able to lock. However, we could not do the same for MC3. It was getting unstable as soon as cavity was locked i.e. the WFS were making the lock unstable. However, the unstability was different in different attempts but we didn't try mroe times as we had to go.

Coil actuation balancing:

  • We set LOCKIN1 and LOCKIN2 oscillators at 10.5 Hz anf 13.5 Hz with amplitude of 10 counts.
  • We wrote PIT, YAW and Butterfly actuation vectors (see attached text files used for this) on LOCKIN1 and LOCKIN2 for MC1.
  • We measured C1:SUS-MC1_ASCYAW_IN1 and C1:SUS-MC1_ASCPIT_IN1 and compared it against the case when no excitation was fed.
  • We repeated the above steps for MC2 except that we did not use LOCKIN2. LOCKIN2 was found to already on at oscillator frequency of 0.03Hz with amplitude of 500 counts and was fed to all coils with gain of 1 (so it was effectively moving position DOF at 0.03 Hz.) When we changed it, it became ON back again after we turned on the autolocker, so we guess this must be due to some background script and msut be important so we did not make any changes here. But what is it for?
  • We have gotten some good data for MC1 and MC2 to ponder upon next.
  • MC1 showed no cross coupling at all while MC2 shoed significant cross coupling between PIT and YAW.
  • Both MC1 and MC2 did not show any cross coupling between butterfly actuation and PIT/YAW dof.

On another news, IOO channels died!

  • Infront of us, the medm channels starting with C1:IOO just died. See attachment 8.
  • We are not sure why that happened, but we have reported everything we did up here.
  • This happened around the time we were ready to switch back on the IMC autolocker and open the shutter. But now these channels are dead.
  • All optics were restored with old matrices and settings and are damped in good condition as of now.
  • IMC should lock back as soon as someone can restart the EPICS channels and switch on C1:IOO-MC_LOCK_ENABLE and C1:PSL-PSL_ShutterRqst.
  15955   Tue Mar 23 09:16:42 2021 Paco, AnchalUpdateComputersPower cycled C1PSL; restored C1PSL

So actually, it was the C1PSL channels that had died. We did the following to get them back:

  • We went to this page and tried the telnet procedure. But it was unable to find the host.
  • So we followed the next advice. We went to the 1X1 rack and manually hard shut off C1PSL computer by holding down the power button until the LEDs went off.
  • We wait for 5-7 seconds and switched it back on.
  • By the time we were back in control room, the C1PSL channels were back online.
  • The mode cleaner however was struggling to keep the lock. It was going in and out of lock.
  • So we followed the next advice and did burt restore which ran following command:
    burtwb -f /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2021/Mar/22/17:19/c1psl.snap -l /tmp/controls_1210323_085130_0.write.log -o /tmp/controls_1210323_085130_0.nowrite.snap -v 
  • Now the mode cleaner was locked but we found that the input switch of C1IOO-WFS1_PIT and C1IOO-WFS2_PIT filter banks were off. Which meant that only YAW sensors were in loop in the lock.
  • We went back in dataviewer and checked when these channels were shut down. See attachments for time series.
  • It seems this happened yesterday, March 22nd near 1:00 pm (20:00:00 UTC). We can't find any mention of anyone else doing it on elog and we left by 12:15pm.
  • So we shut down the PSL shutter (C1:PSL-PSL_ShutterRqst) and switched off MC autolocker (C1:IOO-MC_LOCK_ENABLE).
  • Switched on C1:IOO-WFS1_PIT_SW1 and C1:IOO-WFS2_PIT_SW1.
  • Turned back on PSL shutter (C1:PSL-PSL_ShutterRqst) and MC autolocker (C1:IOO-MC_LOCK_ENABLE).
  • Mode cleaner locked back easily and now is keeping lock consistently. Everything looks normal.
  15961   Thu Mar 25 11:46:31 2021 Paco, AnchalUpdateSUSMC2 Coil Balancing updates


  • We excited PIT and YAW dofs using LOCKIN1 in MC2 on Monday.
  • We analyzed this data in a simple analysis explained in Attachment 1 python notebook (also present at /users/anchal/20210323_AnalyszingCoilActuationBalance/)
  • Basically, we tried to estimate the cross coupling in 2x2 matrix from actuated DOF to sensed DOF, inverted it, and applied it to output matrix to undo the cross coupling.
  • Attachments 2 and 3 show how much we performed in undoing the cross coupling.
  • The ratio of 13.5 Hz peaks shows how much coupling is still present.

Going towards 3x3 Coil balancing:

  • In a conversation with Rana yesterday, we understood that we can use MC_F data as POS sensing data out of the loop.
  • So today, we repreated the excitation measurements while exciting POS, PIT and YAW dofs from LOCKIN1 on MC2 and measuring C1:IOO-MC_F, C1:SUS-MC2_ASCPIT_IN1 and C1:SUS-MC2_ASCPIT_IN2.
  • Data from MC_F is converted into units of um using factor 9.57e-8 um/Hz.
  • We changed the excitation amplitude in order to see cross coupling peaks when they were not visible with low excitation.
  • The data was measured while new calculated input matrix was loaded which from our calculations diagonalized the sensing matrix of OSEMs.

Some major changes:

  • We actually found that the C1:SUS-MC2_ASCPIT_IN1 showed a broadband increase in noise today (from Monday) by factor of about 100 in range 0-20 Hz.
  • We were not sure why this changed from our 22nd March measurement.
  • We checked if the gain values in the loops changed in alst 3 days, but they didn't.
  • Then we realized that the WFS1_PIT and WFS2_PIT switched that we turned ON on Tuesday were the only changes that were made in the loop.
  • We turned back OFF C1:IOO-WFS1_PIT_SW1 and C1:IOO-WFS2_PIT_SW1. This actually brought back the noise level of C1:SUS-MC2_ASCPIT_IN1 down to what it was on Monday.


  15970   Fri Mar 26 11:54:37 2021 Paco, AnchalUpdateSUSMC2 Coil Balancing updates

[Paco, Anchal]

  • Today we spent the morning testing the scripts under ~/c1/scripts/SUS/OutMatCalc/ that automate the procedure (which we have been doing by hand) and catch any "bad" behavior instances that we have identified. In such instances, the script sets up to restore the IMC state smoothly.
  • After some testing and debugging, we managed to get some data for MC2 using ~/c1/scripts/SUS/OutMatCalc/getCrossCouplingData.py
  15972   Mon Mar 29 10:44:51 2021 Paco, AnchalUpdateSUSMC2 Coil Balancing updates

We ran the coil balancing procedure 4 times while iterating through the output matrix optimization.

Attachment 1, pages 1 to 4 show the progression of cross coupling from current output matrix (which is theoretical ideal) to the latest iteration. We plot the sensed DOF ASD which we used to determine the cross coupling when different excitations are fed using the LOCKIN1 feeding 13Hz oscillation of 200 counts amplitude along the vector defined in output matrix. That means, when we change the output matrix, in subsequent tests, we alos change the exciation direction along with it.

Unfortunately, we don't see a very good optimizations over iterations. While we see some peaks going down in sensed PIT and sensed POS (through MC_F), we rather see an increase in cross coupling in the sensed YAW.


  • For running the tests, we used script in scripts/SUS/OutMatCalc/crossCoupleTest.py and wrote commanding scripts in the /users/anchal/20210329_MC2_TestingNewOutMat .
  • The optimization code is at in scripts/SUS/OutMatCalc/outMatOptimize.py.
  • The code reads sensed DOF data using nds2 and calculated cross spectral density among the sensed DOF at the excitation frequencies.
  • This is normalized by the power spectral density of reference data (no excitation) and power spectral density of position data to create a TF estimate.
  • The real values of the sensor matrix thus created is used to get the inverse matrix.
  • The inverse matrix is first normalized along each row by diagonal elements to get 1 there and then multiplied by previous output matrix to create a new output matrix.
  • I guess, reading the code will be a better way of understanding this algorithm.
  16233   Thu Jul 1 10:34:51 2021 Paco, AnchalSummaryLSCETMY QPD fixed

Paco worked on alignign the beam splitter to get light on the ETMY QPD and was successful in centering it without any other changes in the settings.

  16238   Tue Jul 6 10:47:07 2021 Paco, AnchalUpdateIOORestored MC

MC was unlocked and struggling to recover this morning due to misguided WFS offsets. In order to recover from this kind of issue, we

  1. Cleared the bogus WFS offsets
  2. Used the MC alignment sliders to change MC1 YAW from -0.9860 to -0.8750 until we saw the lowest order mode transmission on the video monitor.
  3. With MC Trans sum at around ~ 500 counts, we lowered the C1:IOO-WFS_TRIGGER_THRESH_ON from 5000 to 500, and the C1:IOO-WFS_TRIGGER_MON from 3.0 to 0.0 seconds and let the WFS integrators work out some nonzero angular control offsets.
  4. Then, the MC Trans sum increased to about 2000 counts but started oscillating slowly, so we restored the delayed loop trigger from 0.0 to 3.0 seconds and saw the MC Trans sum reach its nominal value of ~ 14000 counts over a few minutes.

The MC is now restored and the plan is to let it run for a few hours so the offsets converge; then run the WFS relief script.

  5418   Thu Sep 15 16:45:59 2011 PaulUpdateSUSITMY and SRM Oplev status

Today I worked on getting the ITMY and SRM oplevs back in working order. I aligned the SRM path back onto the QPD. I put excitations on the ITMY and SRM in pitch and yaw and observed the beam at the QPDs to check for clipping. They looked clean from clipping.

Measurements of the beam power at various points:
Straight after the laser - 7.54mW
After the BS in the SRM path - 1.59mW
After the BS in the ITMY path - 3.24mW
Incident on the SRM QPD - 0.03mW
Incident on the ITMY QPD - 0.25mW
Counts registered from the QPD sum channels:
SRM QPD SUM dark count - 1140
SRM QPD SUM bright count - 3250
ITMY QPD SUM dark count - 150
ITMY QDP SUM bright count - 12680
The power incident on the SRM QPD seems very low with respect to the ITMY QPD. Is the SRM mirror coating not very reflective for the He-Ne laser?There are some back reflections from lenses, which we should be careful of to avoid scattering.
  5422   Thu Sep 15 18:24:54 2011 PaulUpdateSUSITMY and SRM Oplev current status - comparison with ITMY

Just to find out where we are currently, I plotted the ITMY and SRM oplev spectra along with the ETMY oplev spectra. ETMY seems to be very good, so comparing with this seemed useful, so we know how much we have to improve by. The SRM power spectrum appears to be around 2 orders of magnitude higher than ETMY over pretty much the whole measurement band. The ITMY power spectrum is not so bad as the SRM above about 60Hz. Next thing to do is to check the dark noise level for the ITMY and SRM QPDs.

  5423   Thu Sep 15 18:31:27 2011 PaulUpdateSUSITMY and SRM Oplev current status - comparison with ITMY


Just to find out where we are currently, I plotted the ITMY and SRM oplev spectra along with the ETMY oplev spectra. ETMY seems to be very good, so comparing with this seemed useful, so we know how much we have to improve by. The SRM power spectrum appears to be around 2 orders of magnitude higher than ETMY over pretty much the whole measurement band. The ITMY power spectrum is not so bad as the SRM above about 60Hz. Next thing to do is to check the dark noise level for the ITMY and SRM QPDs.

 The title of this post should of course have been " ... - comparison with ETMY" not " ... - comparison with ITMY"

ELOG V3.1.3-