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

  15878   Mon Mar 8 12:40:35 2021 gautamSummarytrainingInvestigate how-to XARM locking

For the arm locking, the "Restore Xarm (XARM POX)" script from the "IFO_CONFIGURE" MEDM screen should get you there (I just checked it and it works fine). It is worth getting a hang of the PDH signal chain (read what the script is doing and map it to the signal chain) so you get a feel for where there may be offsets, saturations, what the trigger logic is etc. The LSC overview screen is supposed to be pretty intuitive (if you think it can be improved, I'd love to hear it but please don't change it without documenting) and there are also the webviews of the simulink models (these are RO so feel free to click around, for the LSC the c1lsc model is the relevant one).

  15881   Mon Mar 8 19:22:56 2021 ranaSummarySUSIMC suspension characterization

Herewith, I describe an adventure

  1. Balance the OSEM input matrix using the free swinging data (see prev elogs).
  2. Balance the coil actuation by changing the digital coil gains. This should be done above 10 Hz using optical levers, or some IMC readout (like the WFS). At the end of this process, you should put a pringle vector into the column of the SUS output matrix that corresponds to one of the SUS OSC/LOCKIN screens. Verily, the pringle excitation should produce no signal in MC_F or da WFS.
  3. use the Malik doc on the single suspension to design feed-forward filters for the SUS COIL filter banks. You can get the physical parameters using the design documents on DCC / 40m wiki and then modify them a bit based on the eigenfrequencies in the free swinging data.
  4. Model the 2x2 system which includes longitudinal and pitch motion. Consider how accurate the filters must be to maintain a cross-coupling of < 3% in the 0.5-2 Hz band.
  5. Is this decoupling forsooth still maintained when you close the SUS damping loops in the model? If not, why so?
  6. Make step response measurements of the damping loops and record/plot data. Use physical units of um/urad for the y-axes. How much is the step response cross-coupling?
  7. Consider the IMC noise budget: are the low pass filters in the damping loops low-passing enough? How much damping is demasiado (considering the CMRR of the concrete slab for seismic waves)?
  8. Can we use Radhika's AAA representation to auto-tune the FF and damping filters? It would be very slick to be able to do this with one button click.

gautam: For those like me who don't know what the AAA representation is: the original algorithm is here, and Lee claims his implementation of it in IIRrational is better, see his slides.

  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. 

Attachment 1: 20210309_POX11_Spec_XARMLocked.pdf
Attachment 2: 20210309_XARM_Locked.tar.gz
  15885   Tue Mar 9 12:41:29 2021 KojiSummaryElectronicsInvestigation on the invacuum Dsub cables

I believe the aLIGO style invac dsub cables and the conventional 40m ones are incompatible.
While the aLIGO spec is that Pin1 (in-vac) is connected to the shield, Pin13 (in-vac) is the one for the conventional cable. I still have to check if Pin13 is really connected to the shield, but we had trouble before for the IO TTs https://nodus.ligo.caltech.edu:8081/40m/7864.
(At least one of the existing end cables did not show this Pin13-chamber connection. However, the cables OMC/IMC chambers indicated this feature. So the cables are already inhomogenious.)

- Which way do we want to go? Our electronics are updated with aLIGO spec (New Sat amp, OMC electronics, etc), so I think we should start making the shift to the aLIGO spec.

- Attachment Top: The new coil drivers can be used together with the old cables using a custom DB25 cable (in-air).

- Attachment Mid: The combination of the conventional OSEM wiring and the aLIGO in-vac cable cause the conflict. The pin1 which is connected to the shield is used for the PD bias.

- Attachment Bottom: This can be solved by shifting the OSEMs by one pin.

o The aLIGO cables have 12 twisted pair wires, but paired signals do not share a twisted pair.
   --- No. This can't be solved by rotating the connectors.
o This modification should be done only for the new suspension.
   --- In principle, we can apply this change to any SOSs. However, this action involves the vent. We probably want to install the new electronics for the existing suspensions before the vent.
o ^- This means that we have to have two types of custom DB25 in-air cables.
   --- Each cable should handle "Shield wire" from the sat amp correctly.

Related Links:

Active TT Pin Issue
and the thread

Hacky solution

Active TT Pin Swapping (December 21, 2012)

TT Wiring Diagram (Wiki)

Attachment 1: SOS_OSEM_cabling.pdf
  15887   Tue Mar 9 14:37:26 2021 gautamSummarySUSPRM suspension

The PRM got tripped ~5AM this morning. The cause is unclear - the seismometer reports elevated activity ~10 minutes before the ringdown starts (as judged using the OSEMs). But the other optics didn't seem to receive as much of an impulse (I only show the BS sensors here as it sits on the same stack as the PRM). Anyway it certainly wasn't me trying to make life difficult for the morning team.

I was able to restore the damping with reEnableWatchdogs.py. I am now running some suspension tests on the PRM by letting it swing freely so please let that finish. I plan to attempt some locking this evening.


[Paco, Anchal]

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

Attachment 1: PRMtrip.png
  15889   Tue Mar 9 15:22:56 2021 KojiSummarySUSPRM suspension

I just saw the PRM watchdog tripped at ~15:20 local (23:20UTC). I restored the PRM but I saw only the side watchdog tripped.
Again at 15:27

17:55 I found the PRM was oscillating while the watchdogs were not tripped. I turned off the OPLEV servos and this made the PRM calmed down. But I didn't turn on the OPLEVs for the past two trips. How were the OPLEVs turned on???

Ah, I'm sorry, I missed the line that Gautam was running the free-swinging test on the PRM.
The two kicks starting from 23:08:50 and from 23:26:31 were spoiled. Did it make the measurement completely waisted?


  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.

  15895   Wed Mar 10 15:00:16 2021 gautamSummaryIMCIMC free swinging prep

Did you fix this issue? It is helpful to post a screenshot of the offending MEDM screen in addition to witticisms. The elog says "sitemap>Shutter>PSL" but I can't find PSL under the dropdown for shutters from Sitemap.

# 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."

  15896   Wed Mar 10 15:29:58 2021 AnchalSummaryIMCIMC free swinging prep

No we didn't fix the issue. We'll post some screenshots tomorrow. From "sitemap>Shutter>PSL" we meant in Shutter medm window, we clicked on the PSL close button. As pointed later, it switches C1:AUX-PSL_ShutterRqst while the PSL shutter switch on Lock MC medm screen switches C1:PSL-PSL_ShutterRqst. We were not sure if this was intentional, so we didn't change anything.

  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.

Attachment 1: freeSwingMC.py.zip
  15901   Thu Mar 11 02:10:06 2021 KojiSummaryBHDBHD Platform vertical dimentions

Stephen and I discussed the nominal heights of the BHD platform components.

  • The beam height from the stack is 5.5"
  • The platform height is 1.5" and the thickness of 0.4", according to the VOPO suspension, which we want to be compatible with.
  • Thus the beam height on the BHD platform is 4".
  • The VOPO platform has a minimum 0.1" gap from the installation surface when it is suspended.
  • When the BHD platform is fixed on the table, we'll use positioners that are fixed on the stack table. Then the BHD platform is fixed on the positioner rather than fixing the entire platform on the stack. This leaves us the option to suspend the platform in the future. The number of the positioners is TBD.
  • Looking at the head size for 1/4-20 socket head screws, It'd be nice to have the thickness of 0.5" for the positioners. This makes the thin part of the stiffener to be 0.6" in thickness.
  • The numbers are nominal for the initial design and subject to the change along with FEA simulations to determine the resonant frequency of the body modes.
Attachment 1: BHD_Platform_Vertical_Dimentions.pdf
  15907   Fri Mar 12 03:08:23 2021 KojiSummarySUSCoil Rs & Ls for PRM/BS/SRM


Per Gautam's request, I've checked the coil resistances and inductances.

  • PRM/BS/SRM coils were tested.
  • All the PRM coils look well-matched in terms of the inductance. Also, I didn't find a significant difference from BS coils.
  • Pin 1 of the feedthru connectors is shorted to the vacuum chamber.
  • A discovery was that: The SRM DSUB pinouts are mirrored compared to the other suspensions.


A DSUB25 breakout was directly connected to the flange (Attachment 1).
The impedance meter was nulled every time the measurement range and type (R or L) were changed.


Feedthru connector: PRM1
Pin1 - flange: R = 0.8Ω
Pin11-23 / R = 1.79Ω / L=3.21mH
Pin 7-19 / R = 1.82Ω / L=3.22mH
Pin 3-15 / R = 1.71Ω / L=3.20mH

Feedthru connector: BS1
Pin1 - flange: R = 0.5Ω
Pin11-23 / R = 1.78Ω / L=3.26mH
Pin 7-19 / R = 1.63Ω / L=3.30mH
Pin 3-15 / R = 1.61Ω / L=3.29mH

Feedthru connector: SRM1
Pin1 - flange: R = 0.5Ω

Pin11-24 / R = 18.1Ω / L=3.22mH
Pin 7-20 / R = 18.8Ω / L=3.25mH
Pin 3-16 / R = 20.3Ω / L=3.25mH

Feedthru connector: PRM2
Pin1 - flange: R = 0.6Ω
Pin11-23 / R = 1.82Ω / L=3.20mH
Pin 7-19 / R = 1.53Ω / L=3.20mH
Pin 3-15 / R = N/A

Feedthru connector: BS2
Pin1 - flange: R = 0.6Ω
Pin11-23 / R = 1.46Ω / L=3.27mH
Pin 7-19 / R = 1.54Ω / L=3.24mH
Pin 3-15 / R = N/A

Feedthru connector: SRM2
Pin1 - flange: R = 0.7Ω
Pin11-24 / R = N/A

Pin 7-20 / R = 18.5Ω / L=3.21mH
Pin 3-16 / R = 19.1Ω / L=3.25mH


The SRM pinouts seem mirrored compared to the others. In fact, these two connectors are equipped with mirror cables (although they are unshielded ribbons) (Attachment 2).

The SRM sus is located on the ITMY table. There is a long in vacuum DSUB25 cable between the ITMY and BS tables. I suspect that the cable mirrors the pinout and this needs to be corrected by the in-air mirror cables.

I went around the lab and did not find any other suspensions which have the mirror cable.

WIth the BHD configuration, we will move the feedthru for the SRM to the one on the ITMY chamber. So I believe the situation is going to be improved.


Attachment 1: P_20210311_224651.jpg
Attachment 2: P_20210311_225359.jpg
  15913   Fri Mar 12 12:32:54 2021 gautamSummarySUSCoil Rs & Ls for PRM/BS/SRM

For consistency, today, I measured both the BS and PRM actuator balancing using the same technique and don't find as serious an imbalance for the BS as in the PRM case. The Oplev laser source is common for both BS and PRM, but the QPDs are of course distinct.

BTW, I thought the expected resistance of the coil windings of the OSEM is ~13 ohms, while the BS/PRM OSEMs report ~1-2 ohms. Is this okay?

  • All the PRM coils look well-matched in terms of the inductance. Also, I didn't find a significant difference from BS coils.
Attachment 1: BS_actuator.pdf
Attachment 2: PRMact.pdf
  15914   Fri Mar 12 13:01:43 2021 ranaSummarySUSCoil Rs & Ls for PRM/BS/SRM

ugh. sounds bad - maybe a short. I suggest measuring the inductance; thats usually a clearer measurement of coil health

  15915   Fri Mar 12 13:48:53 2021 gautamSummarySUSCoil Rs & Ls for PRM/BS/SRM

I didn't repeat Koji's measurement, but he reports the expected ~3.2mH per coil on all the BS and PRM coils.


ugh. sounds bad - maybe a short. I suggest measuring the inductance; thats usually a clearer measurement of coil health

  15916   Fri Mar 12 18:10:01 2021 AnchalSummaryComputer Scripts / ProgramsInstalled cds-workstation on allegra

allegra had fresh Debian 10 installed on it already. I installed cds-workstation packages (with the help of Erik von Reis). I checked that command line caget, caput etc were working. I'll see if medm and other things are working next time we visit the lab.

  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.
Attachment 1: IMC_InputMatrixDiagonalization.pdf
IMC_InputMatrixDiagonalization.pdf IMC_InputMatrixDiagonalization.pdf IMC_InputMatrixDiagonalization.pdf
Attachment 2: inputMatrixCalculationMC.tar
Attachment 3: freeSwingMC.py.tar
Attachment 4: SUSfreeswing_1299514263.txt.tar
  15950   Sun Mar 21 19:31:29 2021 ranaSummaryElectronicsRTL-SDR for monitoring RF noise / interference

When we're debugging our RF system, either due to weird demod phases, or low SNR, or non-stationary noise in the PDH signals, its good to have some baseline measurements of the RF levels in the lab.

I got this cheap USB dongle (RTL-SDR.COM) that seems to be capable of this and also has a bunch of open source code on GitHub to support it. It also comes mith an SMA coax and rabbit ear antenna with a flexi-tripod.

I used CubicSDR, which has free .dmg downloads for MacOS.It would be cool to have a student write some python code (perhaps starting with RTL_Power) for this to let us hop between the diffierent RF frequencies we care about and monitor the power in a small band around them.

  15966   Thu Mar 25 16:02:15 2021 gautamSummarySUSRepeated measurement of coil Rs & Ls for PRM/BS


Since I am mainly concerned with the actuator part of the OSEM, I chose to do this measurement at the output cables for the coil drivers in 1X4. See schematic for pin-mapping. There are several parts in between my measurement point and the actual coils but I figured it's a good check to figure out if measurements made from this point yield sensible results. The slow bias voltages were ramped off under damping (to avoid un-necessarily kicking the optics when disconnecting cables) and then the suspension watchdogs were shutdown for the duration of the measurement.

I used an LCR meter to measure R and L - as prescribed by Koji, the probe leads were shorted and the readback nulled to return 0. Then for R, I corroborated the values measured with the LCR meter against a Fluke DMM (they turned out to be within +/- 0.5 ohms of the value reported by the BK Precision LCR meter which I think is reasonable).


Pin1-9 (UL)   / R = 30.6Ω / L=3.23mH  
Pin2-10 (LL)  / R = 30.3Ω / L=3.24mH
Pin3-11 (UR) / R = 30.6Ω / L=3.25mH
Pin4-12 (LR) / R = 31.8Ω / L=3.22mH
Pin5-13 (SD) / R = 30.0Ω / L=3.25mH

Pin1-9 (UL)   / R = 31.7Ω / L=3.29mH
Pin2-10 (LL)  / R = 29.7Ω / L=3.26mH
Pin3-11 (UR) / R = 29.8Ω / L=3.30mH
Pin4-12 (LR) / R = 29.7Ω / L=3.27mH
Pin5-13 (SD) / R = 29.0Ω / L=3.24mH


On the basis of this measurement, I see no problems with the OSEM actuators - the wire resistances to the flange seem comparable to the nominal OSEM resistance of ~13 ohms, but this isn't outrageous I guess. But I don't know how to reconcile this with Koji's measurement at the flange - I guess I can't definitively rule out the wire resistance being 30 ohms and the OSEMs being ~1 ohm as Koji measured. How to reconcile this with the funky PRM actuator measurement? Possibilities, the way I see it, are:

  1. Magnets on PRM are weird in some way. Note that the free-swinging measurement for the PRM showed some unexpected features.
  2. The imbalance is coming from one of the drive chain - could be a busted current buffer for example.
  3. The measurement technique was wrong.
  15971   Sun Mar 28 14:16:25 2021 AnchalSummarySUSMC3 new Input Matrix not providing stable loop

Rana asked us to write out here the new MC3 input matrix we have calculated along with the old one. The new matrix is not working out for us as it can't keep the suspension loops stable.


Old (Current) MC3 Input Matrix (C1:SUS-MC3_INMATRIX_ii_jj)
POS 0.288 0.284 0.212 0.216 -0.406
PIT 2.658 0.041 -3.291 -0.674 -0.721
YAW 0.605 -2.714 0.014 3.332 0.666
SIDE 0.166 0.197 0.105 0.074 1


New MC3 Input Matrix (C1:SUS-MC3_INMATRIX_ii_jj)
POS 0.144 0.182 0.124 0.086 0.586
PIT 2.328 0.059 -3.399 -1.13 -0.786
YAW 0.552 -2.591 0.263 3.406 0.768
SIDE -0.287 -0.304 -0.282 -0.265 0.871

Note that the new matrix has been made so that the norm of each row is the same as the norm of the corresponding row in the old (current) input matrix.

Peak finding results:

  Guess Values Fittted Values
PIT Resonant Freq. (Hz) 0.771 0.771
YAW Resonant Freq. (Hz) 0.841 0.846
POS Resonant Freq. (Hz) 0.969 0.969
SIDE Resonant Freq. (Hz) 0.978 0.978
PIT Resonance Q 600 345
YAW Resonance Q 230 120
POS Resonance Q 200 436
SIDE Resonance Q 460 282
PIT Resonance Amplitude 500 750
YAW Resonance Amplitude 1500 3872
POS Resonance Amplitude 3800 363
SIDE Resonance Amplitude 170 282

Note: The highest peak on SIDE OSEM sensor free swinging data as well as the DOF basis data created using existing input matrix, comes at 0.978 Hz. Ideally, this should be 1 Hz and in MC1 and MC2, we see the resonance on SIDE DOF to show near 0.99 Hz. If you look closely, there is a small peak present near 1 Hz actually, but it is too small to be the SIDE DOF eigenfrequency. And if it is indeed that, then which of the other 4 peaks is not the DOF we are interested in?

On possiblity is that the POS eigenfrequency which is supposed to be around 0.97 Hz is split off in two peaks due to some sideways vibration and hence these peaks get strongly coupled to SIDE OSEM as well.

P.S. I think something is wrong and out limited experience is not enough to pinpoint it. I can show up more data or plots if required to understand this issue. Let us know what you all think.

Attachment 1: MC3_Input_Matrix_Diagonalization.pdf
  15973   Mon Mar 29 17:07:17 2021 gautamSummarySUSMC3 new Input Matrix not providing stable loop

I suppose you've tried doing the submatrix approach, where SIDE is excluded for the face DoFs? Does that give a better matrix? To me, it's unreasonable that the side OSEM senses POS motion more than any single face OSEM, as your matrix suggests (indeed the old one does too). If/when we vent, we can try positioning the OSEMs better.

  15981   Wed Mar 31 03:56:37 2021 KojiSummaryElectronicsA bunch of electronics received

We have received 9x 18bit DAC adapter boards (D1000654)

Attachment 1: P_20210331_013257.jpg
Attachment 2: P_20210331_014020.jpg
  15989   Thu Apr 1 23:55:33 2021 KojiSummaryGeneralHEPA AC cord replacement

I think the PSL HEPA (both 2 units) are not running. The switches were on. And the variac was changed from 60% to 0%~100% a few times but no success.
I have no troubleshooting power anymore today. The main HEPA switch was turned off.

  15992   Fri Apr 2 15:17:23 2021 gautamSummaryGeneralHEPA AC cord replacement

From the last failure, I had ordered 2 extra capacitors (they are placed on top of the PSL enclosure above where the capacitors would normally be installed). If the new capacitors lasted < 6months, may be symptomatic of some deeper problem though, e.g. the HEPA fans themselves need replacing. We don't really have a good diagnostic of when the failure happened I guess as we don't have any channel recording the state of the fans.


I think the PSL HEPA (both 2 units) are not running. The switches were on. And the variac was changed from 60% to 0%~100% a few times but no success.
I have no troubleshooting power anymore today. The main HEPA switch was turned off.

  16002   Tue Apr 6 21:17:04 2021 KojiSummaryGeneralPSL HEPA investigation

- Last week we found both of the PSL HEPA units were not running.

- I replaced the capacitor of the north unit, but it did not solve the issue. (Note: I reverted the cap back later)
- It was found that the fans ran if the variac was removed from the chain.
- But I'm not certain that we can run the fans in this configuration with no attendance considering fire hazard.

@3AM: UPON LEAVING the lab, I turned off the HEPA. The AC cable was not warm, so it's probably OK, but we should wait for the continuous operation until we replace the scorched AC cable.

The capacitor replacement was not successful. So, the voltages on the fan were checked more carefully. The fan has the three switch states (HIGH/OFF/LOW). If there is no load (SW: OFF), the variac out was as expected. When the load was LOW or HIGH, it looked as if the motor is shorted (i.e. no voltage difference between two wires).

I thought the motors may have been shorted. But if the load resistance was measured with the fluke meter, it showed some resistance

- North Unit: SW LOW 4.6Ohm / HIGH 6.0Ohm
- South Unit: SW LOW 6.0Ohm / HIGH 4.6Ohm (I believe the internal connection is incorrect here)

I believed the motors are alive! Then the fans were switched on with the variac removed... they ran. So I set the switch LOW for the north unit and HIGH for the south unit.

Then I inspected the variac:

  • The AC output has some liquid leaking (oil?) (Attachment 1)
  • The AC plug on the variac out has a scorch mark (Attachments 2/3)

So, this scorched AC plug/cable connected directly to the AC right now. I'm not 100% confident about the safety of this configuration.
Also I am not sure what was wrong with the system.

  • Has the variac failed first? Because of the heat? I believe that the HEPA was running @30% most of the time. Maybe the damage was already there at the failure in Nov 2020?
  • Or has the motor stopped at some point and this made the variac failed?
  • Was the cable bad and the heat made the variac failed (then the problem is still there).

So, while I'm in the lab today, I'll keep the HEPA running, but upon my taking off, I'll turn it off. We'll discuss what to do in the meeting tomorrow.


Attachment 1: 20210406211741_IMG_0554.jpeg
Attachment 2: 20210406211840_IMG_0555.jpeg
Attachment 3: 20210406211850_IMG_0556.jpeg
  16016   Mon Apr 12 08:32:54 2021 Anchal, PacoSummaryPSLPMC unlocked at 2pm on Sunday; ~ Restored

PMC lost lock between 21:00 and 22:00 UTC on April 11th as seen in the summary pages:


That's between 2pm and 3pm on Sunday for us. We're not sure what caused it. We will attempt to lock it back.

Mon Apr 12 08:45:53 2021: we used milind's python script in scripts/PSL/PMC/pmc_autolocker.py. It locked the PMC in about a minute and then IMC catched lock succefully.

However, the PMC transmission PD shows voltage level of about 0.7V. On medm, it is set to turn red below 0.7 and yellow above. In Summary pages in the past, it seems like this value has typically been around 0.74V. Simil;arly, the reflection RFPD DC voltage is around 0.063 V right now while it is supposed to be around 0.04 nominally So the lock is not so healthy.

We tried running this script and the bashscript version too (scripts/PSL/PMC/PMCAutolocker) a couple of times but it was unable to acquire lock.

Then we manually tried to acquire lock by varying the C1:PSL-PMC_RAMP (with gain set to -10 dB) and resetting PZT position by toggling Blank. After a few attempts, we were able to find the lock with transmission PD value around 0.73V and reflection RFPD value around 0.043. PZT control voltage was 30V and shown in red in medm to begin with. So we adjusted the output ramp again to let it come to above 50V (or maybe it just drifted to that value by itself as we could se some slow drift too). At Mon Apr 12 09:50:12 2021 , the PZT voltage was around 58V and shown in green.

We assume this is a good enough point for PMC lock and move on.

  16019   Mon Apr 12 18:34:26 2021 YehonathanSummaryPSLPMC unlocked at 2pm on Sunday; ~ Restored

PMC lost lock again at around 16:00 April 12. I was able to lock it again but the transmission is only 0.6 now and REFL is 0.14.

Rana came in and realigned the PMC stirring mirrors. Now the transmission is 0.757V, and the REFL is 0.03V.

I noticed that the PZT was around 250V. Given that the PMC got unlocked at 16:00, which is around the peak temperature time in the lab (lagging behind the outside weather), due to the PZT voltage going down to 0V, I figured that the PZT voltage would go up during the night when the lab gets cold and therefore will likely go out of range again.

I found a different working point at 150V and relocked the PMC.


  16060   Wed Apr 21 10:59:07 2021 ranaSummaryCamerasnote on new GigE cam @ 1064

Note from Stephen on more sensitive Baslers.

  16070   Thu Apr 22 01:42:38 2021 KojiSummaryElectronicsHV Supply Comparison

New HV power supply from Company 'M' has been delivered. So I decided to compare the noise levels of some HV supplies in the lab. There are three models from companies 'H', 'K', and 'M'.

The noise level was measured with SR785 via Gautam's HP filter with protection diodes.

'H' is a fully analog HV supply and the indicator is analog meters.
'K' is a model with a LCD digital display and numerical keypad.
'M' is a model with a knob and digital displays.

All the models showed that the noise levels increased with increased output voltage.

Among these three, H showed the lowest noise. (<~1uV/rtHz@10Hz and <50nV/rtHz@100Hz) (Attachment 1)

K is quite noisy all over the measured freq range and the level was <50uV/rtHz. Also the PSD has lots of 5Hz harmonics. (Attachment 2)

M has a modest noise level (<~30uV/rtHz@10Hz and <1uV/rtHz@100Hz)except for the noticeable line noise (ripple). (Attachment 3)

The comparison of the three models at 300V is Attachment 4. The other day Gautam and I checked the power spectrum of the HV coil driver with KEPCO and the output noise level of the coil driver was acceptable. So I expect that we will be able to use the HV supply from Company M. Next step is to check the HV driver noise with the model by M used as the supply.

Attachment 1: HV_Supply_PSD_H.pdf
Attachment 2: HV_Supply_PSD_K.pdf
Attachment 3: HV_Supply_PSD_M.pdf
Attachment 4: HV_Supply_PSD.pdf
  16095   Thu Apr 29 11:51:27 2021 AnchalSummaryLSCStart of measuring IMC WFS noise contribution in ar cavity length noise

Tried locking the arms

  • Ran IFO > Configure > ! (YARM) > Restore YARM. Nothing happened.
  • Trying to align through tip-tilt:
    • Previous values: TT1: PIT: -1.7845, YAW: -0.2775; TT2: PIT: -1.3376, YAW: -0.0436
    • Couldn't get flashing of light in the arms at all.
    • Restored values to previous values.
  • Noticed that ITMY OPLEV YAWW Error has gone very high overnight while other oplevs remained the same.
  • Trying to change the C1:SUS-ITMY_YAW_OFFSET to bring this oplev yaw error back to near zero.
  • Changed C1:SUS-ITMY_YAW_OFFSET from -34 to 50. OPLEV_YEROR reduced to around -23 from -70.
  • Same thing with BS PIT. OPLEV_PERROR is highlighted in red at -52.
  • Changing C1:SUS-BS_PIT_OFFSET from 55 to 30. This brought OPLEV_PERROR to -15 from -52.
  • Trying to align PRM by changing C1:SUS-PRM_PIT_OFFSET and C1:SUS-PRM_YAW_OFFSET.
  • Inital values: C1:SUS-PRM_PIT_OFFSET: -20 , C1:SUS-PRM_YAW_OFFSET: 39.

Did the WFS step response test on IMC in between while waiting for help. See 16094.

Back to trying arm locking

  • Tried IFO > Configure > ! (XARM) > Restore YARM. Nothing happened.
  • Tried IFO > Configure > ! (YARM) > Restore YARM. Nothing happened again.
  • Tried Movie Capture of AS screen from VIDEO > Movie Capture > AS. But the script failed due to module not present error.

PMC got unlocked

  • Infront of me, PMC got unlocked. I did not go to PMC locking the screen at all since morning.
  • I opened the C1PSL_PMC screen. The PSL Autolocker blinker is not blinking but the switch is set to Enable. 
  • I do not see any automatic effort happening for regaining lock at PMC.
  • I'll try it manually. I was able to get the PMC locked again. C1:PSL-PMC_PMCTRANSPD is showing 0.761 V and C1:PSL-PMC_RFPDDC is showing 0.053 V.
  • Now IMC auto locker seems to be trying to get the lock acquired.
  • It acquired a lock a few times but struggled to keep it on. I reduced C1:IOO-WFS_GAIN to 0 and then the lock could stay on. Seemed like the accumulated offsets were not good.
  • So I cleared the history on WFS1, TRANS and WFS2 filter banks and then ramped the WFS overall gain (C1:IOO-WFS_GAIN) back to 1 and now IMC seems to stay locked in a stable configuration.
  • However, I still don't know what caused the PMC to get unlocked in the first place. Did my repeated arm locking attempts did something to the main laser frequency?

Back to trying arm locking

  • Tried IFO > Configure > ! (YARM) > Restore YARM again. Nothing happened again.
  16101   Thu Apr 29 17:51:19 2021 AnchalSummaryLSCStart of measuring IMC WFS noise contribution in arm cavity length noise

t Both arms were locked simply by using IFO > Configure > ! (YARM) > Restore YARM. I had to use ASS to improve the TRX/TRY to ~0.95.

I measured C1:LSC-XARM_IN1_DQ and C1:LSC-YARM_IN1_DQ while injecting band limited noise in C1:IOO-WFS1_PIT_EXC using uniform noise with amplitude 1000 along with filter defined by string: cheby1("BandPass",4,1,80,100). I calibrated the control arms signals by 2.44 nm/cts calibration factor directly picked up from 13984.

For the duration of this test, all LIMIT switches in the WFS loops were switched OFF.

I do not see any affect on the arm control signal power spectrums with or without the noise injection. Attachement 1 shows the PSD along with PSD of the injection site IN2 signal. I must be doing something wrong, so would like feedback before I go further.

Attachment 1: WFS1_PIT_exc_80-100Hz_Arms_ASD.pdf
  16104   Fri Apr 30 00:18:40 2021 gautamSummaryLSCStart of measuring IMC WFS noise contribution in arm cavity length noise

This is the actuator calibration. For the error point calibration, you have to look at the filter in the calibration model. I think it's something like 8e-13m/ct for POX and similar for POY.


I calibrated the control arms signals by 2.44 nm/cts calibration factor directly picked up from 13984.

  16113   Mon May 3 18:59:58 2021 AnchalSummaryGeneralWeird gas leakagr kind of noise in 40m control room

For past few days, a weird sound of decaying gas leakage comes in the 40m control room from the south west corner of ceiling. Attached is an audio capture. This comes about every 10 min or so. 

Attachment 1: 40mNoiseFinal.mp3
  16115   Mon May 3 23:28:56 2021 KojiSummaryGeneralWeird gas leakagr kind of noise in 40m control room

I also noticed some sound in the control room. (didn't open the MP3 yet)

I'm afraid that the hard disk in the control room iMac is dying.


  16125   Thu May 6 16:13:39 2021 AnchalSummaryIMCAngular actuation calibration for IMC mirrors

Here's my first attempt at doing angular actuation calibration for IMC mirrors using the method descibed in /users/OLD/kakeru/oplev_calibration/oplev.pdf by Kakeru Takahashi. The key is to see how much is the cavity mode misaligned from the input mode of beam as the mirrors are moved along PIT or YAW.

There two possible kinds of mismatch:

  • Parallel displacement of cavity mode axis:
    • In this kind of mismatch, the cavity mode is simply away from input mode by some distance \large \beta.
    • This results in transmitted power reduction by the gaussian factor of \large e^{-\frac{\beta^2}{w_0^2}} where \large w_0 is the beam waist of input mode (or nominal waist of cavity).
    • For some mismatch, we can approximate this to
                                                                               \large 1 - \frac{\beta^2}{w_0^2}
  • Angular mismatch of cavity mode axis:
    • The cavity mode axis could be tilted with respect to input mode by some angle \large \alpha.
    • This results in transmitted power reduction by the gaussian factor of \large e^{- \frac{\alpha^2}{\alpha_0^2}}  where \large \alpha_0 is the beam divergence angle of input mode (or nominal waist of cavity) given by \large \frac{\lambda}{\pi w_0}.
    • or some mismatch, we can approximate this to
                                                                                \large 1 - \frac{\alpha^2}{\alpha_0^2}

Kakeru's document goes through cases for linear cavities. For IMC, the mode mismatches are bit different. Here's my take on them:


  • MC2 is the easiest case in IMC as it is similar to the end mirror for linear cavity with plane input mirror (the case of which is already studies in sec 0.3.2 in Kaker's document).
  • PIT:
    • When MC2 PIT is changed, the cavity mode simple shifts upwards (or downwards) to the point where the normal from MC2 is horizontal.
    • Since, MC1 and MC3 are plane mirrors, they support this mode just with a different beam spot position, shifted up by \large (R-L)\theta.
    • So the mismatch is simple of the first kind. In my calculations however, I counted the two beams on MC1 and MC3 separately, so the factor is twice as much.
    • Calling the coefficient to square of angular change \large \eta, we get:
                                     \large \eta_{._{2P}} = \frac{2 (R-L)^2}{w_0^2}
    • Here, R is radius of curvature of MC1/3 taken as 21.21m and L is the cavity half-length of IMC taken as 13.545417m.
  • YAW:
    • For YAW, the case is bit more complicated. Similar to PIT, there will be a horizontal shift of the cavity mode by \large (R-L)\theta.
    • But since the MC1 and MC3 mirrors will be fixed, the angle of the two beams from MC1 and MC3 to MC2 will have to shift by \large \theta/2.
    • So the overall coefficient would be:
                                     \large \eta_{._{2Y}} = \frac{2 (R-L)^2}{w_0^2} + \frac{2}{4\alpha_0^2}
    • The factor of 4 in denominator of seconf term on RHS above comes because only half og angular actuation is felt per arm. The factor of 2 in numerator for for the 2 arms.


  • First, let's establish that the case of MC1 and MC3 is same as the cavity mode must change identically when the two mirrors are moved similarly.
  • YAW:
    • By tilting MC1 by \large \theta, we increase the YAW angle between MC1 and MC3 by \large \theta.
    • Beam spot on both MC1 and MC3 moves by \large (R-L)\theta.
    • The beam angles on both arms get shifted by \large \theta/2.
    • So the overall coefficient would be:
                                     \large \eta_{._{13Y}} = \frac{2 (R-L)^2}{w_0^2} + \frac{2}{4\alpha_0^2}
    • Note, this coefficient is same as MC2, so it si equivalent to moving teh MC2 by same angle in YAW.
  • PIT:
    • I'm not very sure of my caluculation here (hence presented last).
    • Changing PIT on MC1, should change the beam spot on MC2 but not on MC3. Only the angle of MC3-MC2 arm should deflect by \large \theta/2.
    • While on MC1, the beam spot must change by \large (R-L)\theta/2 and the MC1-MC2 arm should deflect by \large \theta/2.
    • So the overall coefficient would be:
                                     \large \eta_{._{13P}} = \frac{(R-L)^2}{4 w_0^2} + \frac{2}{4\alpha_0^2}

Test procedure:

  • We first clicked on MC WFS Relief (on C1:IOO-WFS_MASTER) to reduce the large offsets accumulated on WFS outputs. This script took 10 minutes and reduced the offsets to single digits and IMC remained locked throughout the process.
  • Then we switched off the WFS to freeze the outputs.
  • We moved the MC#_PIT/YAW_OFFSET up and down and measured the C1:IOO-MC_TRANS_SUMFILT_OUT channel as an indicater of IMC mode matching.
  • Attachement 1 are the 6 measurements and there fits to a parabola. Fitting code and plots are thanks to Paco.
  • We got the curvature of parabolas \large \gammafrom these fits in units of 1/cts^2.
  • The \large \eta coefficients calculated above are in units of 1/rad^2.
  • We got the angular actuation calibration from these offsets to physical angular dispalcement in units of rad/cts by \large \sqrt{\gamma / \eta}.
  • AC calibration:
    • I parked the offset to some value to get to the side of parabola. I was trying to reduce transmission from about 14000 cts to 10000-12000 cts in each case.
    • Sent excitation using MC#_ASCPIT/YAW_EXC using awg at 77 Hz and 10000 cts.
    • Measured the cts on transmission channel at 77 Hz. Divided it by 2 and by the dc offset provided. And divided by the amplitude of cts set in excitation. This gives \large \eta_{ac} analogous to above DC case.
    • Then angular actuation calibration at 77 Hz from these offsets to physical angular dispalcement in units of rad/cts by \large \sqrt{\gamma/\eta_{ac}}.
  • Following are the results:
    Optic Act
    Calibration factor at DC [µrad/cts]
    Calibration factor at 77 Hz [prad/cts]
    MC1 PIT 7.931+/-0.029 906.99
    MC1 YAW 5.22+/-0.04 382.42
    MC2 PIT 13.53+/-0.08 869.01
    MC2 YAW 14.41+/-0.21 206.67
    MC3 PIT 10.088+/-0.026 331.83
    MC3 YAW 9.75+/-0.05 838.44


  • Note these values are measured with the new settings in effect from 16120. If these are changed, this measurement will not be valid anymore.
  • I believe the small values for MC1 actuation have to do with the fact that coil output gains for MC1 are very weird and small, which limit the actuation strength.
  • TAbove the resonance frequencies, they will fall off by 1/f^2 from the DC value. I've confirmed that the above numbers are of correct order of magnitude atleast.
  • Please let me know if you can point out any mistakes in the calculations above.
Attachment 1: IMC_Ang_Act_Cal_Kakeru_Tests.pdf
IMC_Ang_Act_Cal_Kakeru_Tests.pdf IMC_Ang_Act_Cal_Kakeru_Tests.pdf IMC_Ang_Act_Cal_Kakeru_Tests.pdf IMC_Ang_Act_Cal_Kakeru_Tests.pdf IMC_Ang_Act_Cal_Kakeru_Tests.pdf IMC_Ang_Act_Cal_Kakeru_Tests.pdf
  16128   Mon May 10 10:57:54 2021 Anchal, PacoSummaryCalibrationUsing ALS beatnote for calibration, test

Test details:

  • We locked both arms and opened the shutter for Yend green laser.
  • After toggling the shutter on.off, we got a TEM00 mode of green laser locked to YARM.
  • We then cleared the phase Y history by clicking "CLEAR PHASE Y HISTROY" on C1LSC_ALS.adl (opened from sitemap > ALS > ALS).
  • We sent excitation signal at ITMY_LSC_EXC using awggui at 43Hz, 77Hz and 57Hz.
  • We measured the power spectrum and coherence of C1:ALS-BEATY_FINE_PHASE_OUT_HZ_DQ and C1:SUS-ITMY_LSC_OUT_DQ.
  • The BEATY_FINE_PHASE_OUT_HZ is already calibrated in Hz. This we assume is done by multip[lying the VCO slope in Hz/cts to the error signal of the digital PLL loop that tracks the phase of beatnote.
  • We calibrated C1:SUS-ITMY_LSC_OUT_DQ by multiplying with
    \large 3 \times \frac{2.44 \, nm/cts}{f^2} \times \frac{c}{1064\,nm \times 37.79\, m} = \frac{54.77}{f^2} kHz/cts where f is in Hz.
    The 2.44/f2 nm/cts is taken from 13984.
  • We added the calibration as Poles/zeros option in diaggui using gain=54.577e3 and poles as "0, 0".
  • We found that ITMY_LSC_OUT_DQ calibration matches well at 57Hz but overshoots (80 vs 40) at 43 Hz and undershoots (50 vs 80) at 77Hz.


  • If we had DRFPMI locked, we could have used the beatnote spectrum as independent measurement of arm lengths to calibrate the interferometer output.
  • We can also use the beatnote to confirm or correct the ITM actuator calibrations. Maybe shape is not exactly 1/f2 unless we did something wrong here or the PLL bandwidth is too short.
Attachment 1: BeatY_ITMY_CalibrationAt57Hz.pdf
BeatY_ITMY_CalibrationAt57Hz.pdf BeatY_ITMY_CalibrationAt57Hz.pdf
Attachment 2: BeatY_ITMY_CalibrationAt43Hz.pdf
BeatY_ITMY_CalibrationAt43Hz.pdf BeatY_ITMY_CalibrationAt43Hz.pdf
Attachment 3: BeatY_ITMY_CalibrationAt77Hz.pdf
BeatY_ITMY_CalibrationAt77Hz.pdf BeatY_ITMY_CalibrationAt77Hz.pdf
  16133   Wed May 12 11:45:13 2021 Anchal, PacoSummarySUSNew IMC Settings are miserable

We picked a few parameters from 40m summary page and plotted them to see the effect of new settings. On April 4th, old settings were present. On April 28th (16091), new input matrices and F2A filters were uploaded but suspension gains remained the same. On May 5th (16120), we uploaded new (higher) suspension gains. We chose Sundays on UTC so that it lies on weekends for us. Most probably nobody entered 40m and it was calmer in the institute as well.

  • On MC_F spectrum, we see that that noise decreased in 0.3-0.7 Hz but there is more noise from 1-1.5 Hz.
  • On MC_TRANS_QPD, we see that both TRANS PIT and YAW signals were almost twice as noisy.
  • On MC_REFL_DC too, we see that the noise during the locked state seems to be higher in the new configuration.

We can download data and plot comparisons ourselves and maybe calculate the spectrums of MC_TRANS_PIT/YAW and MC_REFL_DC when IMC was locked. But we want to know if anyone has better ways of characterizing the settings that we should know of before we get into this large data handling which might be time-consuming. From this preliminary 40m summary page plots, maybe it is already clear that we should go back to old settings. Awaiting orders.


Attachment 1: MC_F_Comparison.pdf
Attachment 2: MC_TRANS_QPD_Comparison.pdf
Attachment 3: IMC_REFL_DC_Comparison.pdf
  16157   Mon May 24 19:14:15 2021 Anchal, PacoSummarySUSMC1 Free Swing Test set to trigger

We've set a free swing test to trigger at 3:30 am tomorrow for MC1. The script for tests is running on tmux session named 'freeSwingMC1' on rossa. The script will run for about 4.5 hrs and we'll correct the input matrix tomorrow from the results. If anyone wants to work during this time (3:30 am to 8:00 am), you can just kill the script by killing tmux session on rossa. ssh into rossa and type tmux kill-session -t freeSwingMC1.


We should redo the MC1 input matrix optimization and the coil balancing afterward as we did everything based on the noisy UL OSEM values.


  16158   Mon May 24 20:55:00 2021 KojiSummaryBHDHow to align two OMCs on the BHD platform?

Differential misalignment of the OMCs

40m BHD will employ two OMCs on the BHD platform. We will have two SOSs for each of the LO and AS beams. The challenge here is that the input beam must optimally couple to the OMCs simultaneously. This is not easy as we won't have independent actuators for each OMC. e.g. The alignment of the LO beam can be optimally adjusted to the OMC1, but this, in general, does not mean the beam is optimally aligned to the OMC2.


When a beam with the matched mode to an optical cavity has a misalignment, the power coupling C can be reduced from the unity as

C = 1 - \left(\frac{a}{\omega_0}\right)^2 - \left(\frac{\alpha}{\theta_0}\right)^2

where \omega_0 is the waist radius, \theta_0 is the divergence angle defined as \theta_0 \equiv \lambda/ \pi \omega, a and \alpha are the beam lateral translation and rotation at the waist position.

The waist size of the OMC is 500um. Therefore \omega_0 = 500um and \theta_0 = 0.68 mrad. If we require C to be better than 0.995 according to the design requirement document (T1900761). This corresponds to a (only) to be 35um and \alpha (only) to be 48urad. These numbers are quite tough to be realized without post-installation adjustment. Moreover, the OMCs themselves have individual differences in the beam axis. So no matter how we set the mechanical precision of the OMC installation, we will introduce a maximum of 1mm and ~5mrad uncertainty of the optical axis.


Suppose we adjust the incident beam to the OMC placed at the transmission side of the BHD BS. The reflected beam at the BS can be steered by picomotors. The distance from the BS to the OMC waist is 12.7" (322mm) according to the drawing.
So we can absorb the misalignment mode of (a, \alpha) = (0.322 \theta, \theta). This is a bit unfortunate. 0.322m is about 1/2 of the rayleigh range. Therefore, this actuation is still angle-dominated but a bit of translation is still coupled.

If we enable to use the third picomotor on the BHD BS mount, we can introduce the translation of the beam in the horiz direction. This is not too huge therefore we still want to prepare the method to align the OMC in the horiz direction.

The difficult problem is the vertical alignment. This requires the vertical displacement of the OMC. And we will not have the option to lower the OMC. Therefore if the OMC2 is too high, we have to raise the OMC1 so that the resulting beam is aligned to the OMC2. i.e. we need to maintain the method to raise both OMCs. (... or swap the OMCs). From the images of the OMC beam spots, we'll probably be able to analyze the intracavity axes of the OMCs. So we can always place the OMC with a higher optical axis at the transmission side of the BHD BS.



  16159   Tue May 25 10:22:16 2021 Anchal, PacoSummarySUSMC1 new input matrix calculated and uploaded

The test was succesful and brought back the IMC to lock point at the end.

We calculated new input matrix using same code in scripts/SUS/InMatCalc/sus_diagonalization.py . Attachment 1 shows the results.

The calculations are present in scripts/SUS/InMatCalc/MC1.

We uploaded the new MC1 input matrix at:

Unix Time = 1621963200

UTC May 25, 2021 17:20:00 UTC
Central May 25, 2021 12:20:00 CDT
Pacific May 25, 2021 10:20:00 PDT

GPS Time = 1305998418

This was done by running python scripts/SUS/general/20210525_NewMC1Settings/uploadNewConfigIMC.py on allegra. Old IMC settings (before Paco and I started workin on 40m) can be restored by running python scripts/SUS/general/20210525_NewMC1Settings/restoreOldConfigIMC.py on allegra.

Everything looks as stable as before. We'll look into long term trends in a week to see if this helped at all.

Attachment 1: SUS_Input_Matrix_Diagonalization.pdf
  16161   Tue May 25 17:42:11 2021 Anchal, PacoSummaryALSALS Single Arm Noise Budget

Here is our first attempt at a single-arm noise budget for ALS.

Attachment 1 shows the loop diagram we used to calculate the contribution of different noises.

Attachment 2 shows the measured noise at C1:ALS-BEATX_PHASE_FINE_OUT_HZ when XARM was locked to the main laser and Xend Green laser was locked to XARM.

  • The brown curve shows the measured noise.
  • The black curve shows total estimated noise from various noise sources (some of these sources have not been plotted as their contribution falls off the plotting y-lims.)
  • The residual frequency noise of Xend green laser (AUX) is measured by measuring the PDH error monitor spectrum from C1:ALS-X_ERR_MON_OUT_DQ. This measurement was converted into units of V by multiplying it by 6.285e-4 V/cts. This factor was measured by sending a 43 Hz 100 mV sine wave at the readout point and measuring the output in the channel.
  • This error signal is referred to AUX_Freq input in the loop diagram (see attachment 1) and then injected from there.
  • All measurements were taken to Res_Disp port in the 'Out-of-Loop Beat Note' block (see attachment 1).
  • In this measurement, we did not DAC noise that gets added when ALS loop is closed.
  • We added ADC noise from Kiwamu's ALS paper after referring it to DFD input. DFD noise is also taken from Kiwamu's ALS paper data.


  • Something is wrong above 200 Hz for the inclusion of AUX residual displacement noise. It is coming off as higher than the direct measured residual noise, so something is wrong with our loop diagram. But I'm not sure what.
  • There is a lot of unaccounted noise everywhere from 1 Hz to 200 Hz.
  • Rana said noise budget below 1 Hz is level 9 stuff while we are at level 2, so I'll just assume the excess noise below 1 Hz is level 9 stuff.
  • We did include seismic noise taken from 40m noise budget in 40m/pygwinc. But it seems to affect below the plotted ylims. I'm not sure if that is correct either.

Unrelated questions:

  • There is a slow servo feeding back to Green Laser's crystal temperature by integrating PZT out signal. This is OFF right now. Should we keep it on?
  • The green laser lock is very unreliable and it unlocks soon after any signal is being fed back to the ETMX position.
  • This means, keeping both IR and green light locked in XARM is hard and simultaneous oscillation does not last longer than 10s of seconds. Why is it like this?
  • We notice that multiple higher-order modes from the green laser reach the arm cavity. The HOMs are powerful enough that PDH locks to them as well and we toggle the shutter to come to TEM00 mode. These HOMs must be degrading the PDH error signal. Should we consider installing PMCs at end tables too?
Attachment 1: ALS_IR_b.svg
Attachment 2: ALS_Single_Arm_IR.pdf
  16164   Thu May 27 11:03:15 2021 Anchal, PacoSummaryALSALS Single Arm Noise Budget

Here's an updated X ARM ALS noise budget.

Things to remember:

  • Major mistake we were making earlier was that we were missing the step of clicking  'Set Phase UGF' before taking the measurement.
  • Click the clear phase history just before taking measure.
  • Make sure the IR beatnotes are less than 50 MHz (or the left half of HP8591E on water crate). The DFD is designed for this much beatnote frequency (from Gautum).
  • We took this measurement with old IMC settings.
  • We have saved a template file in users/Templates/ALS/ALS_outOfLoop_Ref_DQ.xml . This si same as ALS_outOfLoop_Ref.xml except we changed all channels to _DQ.


  • Attachment 1 shows the updated noisebudget. The estimated and measured RMS noise are very close to eachother.
  • However, there is significant excess noise between 4 Hz and 200 Hz. We're still thinking on what could be the source of these.
  • From 200 Hz to about 3 kHz, the beatnote noise is dominated by AUX residual frequency noise. This can be verified with page 2 of Attachment 2 where coherence between AUX PDH Error signal and BEATX signal is high.
  • One mystery is how the measured beatnote noise is below the residual green laser noise above 3 kHz. Could this be just because the phase tracker can't measure noise above 3kHz?
  • We have used estimated open loop transfer function for AUX from poles/zeros for uPDH box used (this was done months ago by me when I was working on ALS noise budget from home). We should verify it with a fresh OLTF measurement of AUX PDH loop. That's next on our list.
Attachment 1: ALS_Single_X_Arm_IR.pdf
Attachment 2: ALS_OOL_with_Ref.pdf
ALS_OOL_with_Ref.pdf ALS_OOL_with_Ref.pdf ALS_OOL_with_Ref.pdf ALS_OOL_with_Ref.pdf
  16168   Fri May 28 17:32:48 2021 AnchalSummaryALSSingle Arm Actuation Calibration with IR ALS Beat

I attempted a single arm actuation calibration using IR beatnote (in the directions of soCal idea for DARM calibration)

Measurement and Inferences:

  • I sent 4 excitation signals at C1:SUS-ITM_LSC_EXC wit 30cts at 31Hz, 200cts at 197Hz, 600cts at 619Hz and 1000cts at 1069 Hz.
  • These were sent simultaneously using compose function in python awg.
  • The XARM was locked to mai laser and alignment was optimized with ASS.
  • The Xend Green laser was locked to XARM and alignment was optimized.
    • Sidenote: GTRX is now normalized to give 1 at near maximum power.
    • Green lasers can be locked with script instead of toggling.
    • Script can be called from sitemap->ALS->! Toggle Shutters->Lock X Green
    • Script is present at scripts/ALS/lockGreen.py.
  • C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ was measured for 60s.
  • Also, measured C1:LSC-XARM_OUT_DQ and C1:SUS-ITMX_LSC_OUT_DQ.
  • Attachment 1 shows the measured beatnote spectrum with excitations on in units of m/rtHz.
  • It also shows resdiual displacement contribution PSD of (output referred) XARM_OUT and ITMX_LSC_OUT to the same point in the state space model.
    • Note: that XARM_OUT and ITMX_LSC_OUT (excitation signal) get coherently added in reality and hence the beatnote spectrum at each excitation frequency is lower than both of them.
    • The remaining task is to figure out how to calculate the calibration constant for ITMX actuation from this information.
    • I need more time to understand the mixture of XARM_OUT and ITMX_LSC_OUT in the XARM length node in control loop.
    • Beatnote signal tells us the actual motion of the arm length, not how much ITMX would have actuated if the arm was not locked.
  • Attachment 2 has the A,B,C,D matrices for the full state space model used. These were fed to python controls package to get transfer functions from one point to another in this MIMO.
    • Note, that here I used the calibration of XARM_OUT we measured earlies in 16127.
    • On second thought, maybe I should first send excitation in ETMX_LSC_EXC. Then, I can just measure ETMX_LSC_OUT which includes XARM_OUT due to the lock and use that to get calibration of ETMX actuation directly.

Attachment 1: SingleArmActCalwithIRALSBeat.pdf
Attachment 2: stateSpaceModel.zip
  16171   Tue Jun 1 16:55:32 2021 Anchal, PacoSummaryALSSingle Arm Actuation Calibration with IR ALS Beat

Rana suggested in today's meeting to put in a notch filter in the XARM IR PDH loop to avoid suppressing the excitation line. We tried this today first with just one notch at 1069 Hz and then with an additional notch at 619 Hz and sent two simultaneous excitations.

Measurement and Analysis:

  • We added notch filters with Q=10, depth=50dB, freq=619 Hz and 1069 Hz using foton in SUS-ETMX_LSC filter bank at FM10.
  • We sent excitation signals with amplitudes 600cts and 1000 cts for 619 Hz and 1069 Hz signals respectively.
  • We measured time series data of C1:SUS-ITMX_LSC_OUT_DQ and C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ for 60s.
  • Then, spectrum of both signals is measured with Hanning window using scipy.welch function with scaling set to  'spectrum', binwidth=1Hz.
  • The beatnote signal was converted into length units by multiplying it by 1064nm * 37.79m / c.
  • The ratio of the two spectrums at teh excitation frequency multiplies by excitation frequency squared gives us teh calibration constant in units of nm Hz^2/cts.
  • At 619 Hz, we got \frac{5.01}{f^2}nm/cts
  • At 1069 Hz, we got \frac{5.64}{f^2}nm/cts.
  • The calibration factor in use is from \frac{7.32}{f^2} nm/cts from 13984.
  • So, the calibration factor from this methos is about 23% smaller than measured using freeswinging MICH in 13984.
  • One possiblity is that our notch filter is not as effective in avoiding suppresion of excitation.
    • We tried increasing the notch filter depths to 100 dB but got the same result within 2%.
    • We tried changing the position of notch filters. We put them in POX filter banks. Again the result did not change more than 2%.
  • The open loop gain of green PDH at 619 Hz and 1069 Hz must be large enough for our assumption of green laser perfectly following length motion to be true. The UGF of green laser is near 11 kHz.
  • The discrepancy could be due to outdated freeswinging MICH measurement that was done 3 years ago. Maybe we should learn how to do the ITMX calibration using this method and compare our own two measurements.
Attachment 1: SingleArmActCalwithIRALSBeat-1306624785.pdf
  16174   Wed Jun 2 09:43:30 2021 Anchal, PacoSummarySUSIMC Settings characterization

Plot description:

  • We picked up three 10 min times belonging to the three different configurations:
    • 'Old Settings': IMC Suspension settings before Paco and I changed anything. Data taken from Apr 26, 2021, 00:30:42 PDT (GPS 1303457460).
    • 'New Settings': New input matrices uploaded on April 28th, along with F2A filters and AC coil balancing gains (see 16091). Data taken from May 01, 2021, 00:30:42 PDT (GPS 1303889460).
    • 'New settings with new gains' Above and new suspension damping gains uploaded on May5th, 2021 (see 16120). Data taken from May 07, 2021, 03:10:42 PDT (GPS 1304417460).
  • Attachment 1  shows the RMS seismic noise along X direction between 1 Hz and 3 Hz picked from C1:PEM-RMS_BS_X_1_3 during the three time durations chosen. This plot is to establish that RMS noise levels were similar and mostly constant. Page 2 shows the mean ampltidue spectral density of seismic noise in x-direction over the 3 durations.
  • Attachment 2 shows the transfer function estimate of seismic noise to MC_F during the three durations. Page 1 shows ratio of ASDs taken with median averaging while page 2 shows the same for mean averaging.
  • Attachment 3 shows the transfer function estimate of seismic noise to MC_TRANS_PIT during the three durations. Page 1 shows ratio of ASDs taken with median averaging while page 2 shows the same for mean averaging.
  • Attachment 4 shows the transfer function estimate of seismic noise to MC_TRANS_YAW during the three durations. Page 1 shows ratio of ASDs taken with median averaging while page 2 shows the same for mean averaging.


  • From Attachment 2 Page 1:
    • We see that 'old settings' caused the least coupling of seismic noise to MC_F signal in most of the low frequency band except between 1.5 to 3 Hz where the 'new settings' were slightly better.
    • 'new settings' also show less coupling in 4 Hz to 6 Hz band, but at these frequencies, seismix noise is filtered out by suspension, so this could be just coincidental and is not really a sign of better configuration.
    • There is excess noise coupling seen with 'new settings' between 0.4 Hz and 1.5 Hz. We're not sure why this coupling increased.
    • 'new settings with new gains' show the most coupling in most of the frequency band. Clearly, the increased suspension damping gains did not behaved well with rest of the system.
  • From Attachment 3 Page 1:
    • Coupling to MC_TRANS_PIT error signal is reduced for 'new settings' in almost all of the frequency band in comparison to the 'old settings'.
    • 'new settings with new gains' did even better below 1 Hz but had excess noise in 1 Hz to 6 Hz band. Again increased suspension damping gains did not help much.
    • But low coupling to PIT error for 'new settings' suggest that our decoupling efforts in matrix diagonalization, F2A filters and ac coil balancing worked to some extent.
  • From Attachment 4 Page 1:
    • 'new settings' and 'old settings' have the same coupling of seismic noise to MC_TRANS_YAW in all of the frequency band. This is in-line witht eh fact that we found very little POS to YAW couping in our analysis before and there was little to no change for these settings.
    • 'new settings with new gains' did better below 1 Hz but here too there was excess coupling between 1 Hz to 9 Hz.
  • Page 1 vs Page 2:
    • Mean and median should be same if the data sample was large enough and noise was stationary. A difference between the two suggests existence of outliers in the data set and median provides a better central estimate in such case.
    • MC_F: Mean and median are same below 4 hz. There are high frequency outliers above 4 Hz in 'new settings with new gains' and 'old settings' data sets, maybe due to transient higher free running laser frequency noise. But since, suspension settigns affect below 1 Hz mostly, the data sets chosen are stationary enough for us.
    • MC_TRANS_PIT: Mean ratio is lower for 'new settings' and 'old settings' in 0.3 hz to 0.8 Hz band. Same case above 4 Hz as listed above.
    • MC_TRANS_YAW:  Same as above.
  • Conclusion 1:  The 'new settings with new gains' cause more coupling to seismic noise, probably due to low phase margin in control loops. We should revert back the suspension damping gains.
  • Conclusion 2: The 'new settings' work as expected and can be kept when WFS loops are optimized further.
  • Conjecture: From our experience over last 2 weeks, locking the arms to the main laser with 'new settings with new gains' introduces noise in the arm length large enough that the Xend green laser does not remain locked to the arm for longer than tens of seconds. So this is definitely not a configuration in which we can carry out other measurements and experiments in the interferometer.
Attachment 1: seismicX.pdf
seismicX.pdf seismicX.pdf
Attachment 2: seismicXtoMC_F_TFest.pdf
seismicXtoMC_F_TFest.pdf seismicXtoMC_F_TFest.pdf
Attachment 3: seismicXtoMC_TRANS_PIT_TFest.pdf
seismicXtoMC_TRANS_PIT_TFest.pdf seismicXtoMC_TRANS_PIT_TFest.pdf
Attachment 4: seismicXtoMC_TRANS_YAW_TFest.pdf
seismicXtoMC_TRANS_YAW_TFest.pdf seismicXtoMC_TRANS_YAW_TFest.pdf
  16175   Wed Jun 2 16:20:59 2021 Anchal, PacoSummarySUSIMC Suspension gains reverted to old values

Following the conclusion, we are reverting the suspension gains to old values, i.e.

IMC Suspension Gains
  MC1 MC2 MC3
SUSPOS 120 150 200
SUSPIT 60 10 12
SUSYAW 60 10 8

While the F2A filters, AC coil gains and input matrices are changed to as mentioned in 16066 and 16072.

The changes can be reverted all the way back to old settings (before Paco and I changed anything in the IMC suspensions) by running python scripts/SUS/general/20210602_NewIMCOldGains/restoreOldConfigIMC.py on allegra. The new settings can be uploaded back by running python scripts/SUS/general/20210602_NewIMCOldGains/uploadNewConfigIMC.py on allegra.

Change time:

Unix Time = 1622676038

UTC Jun 02, 2021 23:20:38 UTC
Central Jun 02, 2021 18:20:38 CDT
Pacific Jun 02, 2021 16:20:38 PDT

GPS Time = 1306711256

  • Conclusion 1:  The 'new settings with new gains' cause more coupling to seismic noise, probably due to low phase margin in control loops. We should revert back the suspension damping gains.
  • Conclusion 2: The 'new settings' work as expected and can be kept when WFS loops are optimized further.
  • Conjecture: From our experience over last 2 weeks, locking the arms to the main laser with 'new settings with new gains' introduces noise in the arm length large enough that the Xend green laser does not remain locked to the arm for longer than tens of seconds. So this is definitely not a configuration in which we can carry out other measurements and experiments in the interferometer.


  16179   Thu Jun 3 17:35:31 2021 AnchalSummaryIMCFixed medm button

I fixed the PSL shutter button on Shutters summary page C1IOO_Mech_Shutter.adl. Now PSL switch changes C1:PSL-PSL_ShutterRqst channel. Earlier it was C1:AUX-PSL_ShutterRqst which doesn't do anything.


Attachment 1: C1IOO_Mech_Shutters.png
  16190   Mon Jun 7 15:37:01 2021 Anchal, Paco, YehonathanSummaryCamerasMon 7 in Control Room Died

We found Mon7 in control room dead today afternoon. It's front power on green light is not lighting up. All other monitors are working as normal.

This monitor was used for looking at IMC camera analog feed. It is one of the most important monitors for us, so we should replace it with a different monitor.

Yehonathan and Paco disconnected the monitor and brought it down. We put it under the back table if anyone wants to fix it. Paco has ordered a BNC to VGA/HDMI converter to put in any normal monitor up there. It will happen this Wednesday. Meanwhile, I have changed the MON4 assignment from POP to Quad2 to be used for IMC.

  16192   Tue Jun 8 11:40:53 2021 Anchal, PacoSummaryALSSingle Arm Actuation Calibration with IR ALS Beat

We attempted to simulate "oscillator based realtime calibration noise monitoring" in offline analysis with python. This helped us in finding about a factor of sqrt(2) that we were missing earlier in 16171. we measured C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ when X-ARM was locked to main laser and Xend green laser was locked to XARM. An excitation signal of amplitude 600 was setn at 619 hz at C1:ITMX_LSC_EXC.

Signal analysis flow:

  • The C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ is calibrated to give value of beatntoe frequency in Hz. But we are interested in the fluctuations of this value at the excitation frequency. So the beatnote signal is first high passed with 50 hz cut-off. This value can be reduced a lot more in realtime system. We only took 60s of data and had to remove first 2 seconds for removing transients so we didn't reduce this cut-off further.
  • The I and Q demodulated beatntoe signal is combined to get a complex beatnote signal amplitude at excitation frequency.
  • This signal is divided by cts amplitude of excitation and multiplied by square of excitation frequency to get calibration factor for ITMX in units of nm/cts/Hz^2.
  • The noise spectrum of absolute value of  the calibration factor is plotted in attachment 1, along with its RMS. The calibration factor was detrended linearly so the the DC value was removed before taking the spectrum.
  • So Attachment 1 is the spectrum of noise in calibration factor when measured with this method. The shaded region is 15.865% - 84.135% percentile region around the solid median curves.

We got a value of \frac{7.3 \pm 3.9}{f^2}\, \frac{nm}{cts}.  The calibration factor in use is from \frac{7.32}{f^2} nm/cts from 13984.

Next steps could be to budget this noise while we setup some way of having this calibration factor generated in realitime using oscillators on a FE model. Calibrating actuation of a single optic in a single arm is easy, so this is a good test setup for getting a noise budget of this calibration method.

Attachment 1: ITMX_Cal_Noise_Spectrum_1307143423.pdf
ELOG V3.1.3-