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



  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.


  16156   Mon May 24 10:19:54 2021 PacoUpdateGeneralZita IOO strip

Updated IOO.strip on Zita to show WFS2 pitch and yaw trends (C1:IOO-WFS2_PIY_OUT16 and C1:IOO-WFS2_YAW_OUT16) and changed the colors slightly to have all pitch trends in the yellow/brown band and all yaw trends in the pink/purple band.

No one says, "Here I am attaching a cool screenshot, becuz else where's the proof? Am I right or am I right?"

Mon May 24 18:10:07 2021 [Update]

After waiting for some traces to fill the screen, here is a cool screenshot (Attachment 1). At around 2:30 PM the MC unlocked, and the BS_Z (vertical) seismometer readout jumped. It has stayed like this for the whole afternoon... The MC eventually caught its lock and we even locked XARM without any issue, but something happened in the 10-30 Hz band. We will keep an eye on it during the evening...

Tue May 25 08:45:33 2021 [Update]

At approximately 02:30 UTC (so 07:30 PM yesterday) the 10-30 Hz seismic step dropped back... It lasted 5 hours, mostly causing BS motion along Z (vertical) as seen by the minute trend data in Attachment 2. Could the MM library have been shaking? Was the IFO snoring during its afternoon nap?

Attachment 1: Screenshot_from_2021-05-24_18-09-37.png
Attachment 2: 24and25_05_2021_PEM_BS_10_30.png
  16155   Mon May 24 08:38:26 2021 ChubUpdateElectronics18-bit AI, 16-bit AI and 16-bit AA

- High priority units: 2x 18AI / 1x 16AI / 3x 16AA

All six are reworked and on the electronics workbench. The rest should be ready by the end of the week.


  16154   Sun May 23 18:28:54 2021 JonUpdateCDSOpto-isolator for c1auxey

The new HAM-A coil drivers have a single DB9 connector for all the binary inputs. This requires that the dewhitening switching signals from the fast system be spliced with the coil enable signals from c1auxey. There is a common return for all the binary inputs. To avoid directly connecting the grounds of the two systems, I have looked for a suitable opto-isolator for the c1auxey signals.

I best option I found is the Ocean Controls KTD-258, a 4-channel, DIN-rail-mounted opto-isolator supporting input/output voltages of up to 30 V DC. It is an active device and can be powered using the same 15 V supply as is currently powering both the Acromags and excitation. I ordered one unit to be trialed in c1auxey. If this is found to be good solution, we will order more for the upgrades of c1auxex and c1susaux, as required for compatibility with the new suspension electronics.

  16153   Fri May 21 14:36:20 2021 Ian MacMillanUpdateCDSSUS simPlant model

The plant transfer function of the pendulum in the s domain is:


Using Foton to make a plot of the TF needed and using m=40kg, w0=3Hz, and Q=50 (See attachment 1). It is easiest to enter the above filter using RPoly and saved it as Plant_V1

Attachment 1: Plant_Mod_TF.pdf
  16152   Fri May 21 12:12:11 2021 PacoUpdateNoiseBudgetAUX PDH loop identification

[Anchal, Paco]

We went into 40m to identify where XARM PDH loop control elements are. We didn't touch anything, but this is to note we went in there twice at 10 AM and 11:10 AM.

  16151   Fri May 21 09:44:52 2021 Ian MacMillanUpdateCDSSUS simPlant model

The transfer function given in the previous post was slightly incorrect the units did not make sense the new function is:

\frac{x}{F}=\frac{1}{m\omega_0^2-m\omega^2+im\frac{\omega_0 \omega }{Q}}

I have attached a quick derivation below in attachment 1

Attachment 1: Transfer_Function_of_Damped_Harmonic_Oscillator.pdf
  16150   Fri May 21 00:15:33 2021 KojiUpdateElectronicsDC Power Strip delivered / stored

DC Power Strip Assemblies delivered and stored behind the Y arm tube (Attachment 1)

  • 7x 18V Power Strip (Attachment 2)
  • 7x 24V Power Strip (Attachment 2)
  • 7x 18V/24V Sequencer / 14x Mounting Panel (Attachment 3)
  • DC Power Cables 3ft, 6ft, 10ft (Attachments 4/5)
  • DC Power Cables AWG12 Orange / Yellow (Attachments 6/7)

I also moved the spare 1U Chassis to the same place.

  • 5+7+9 = 21x 1U Chassis (Attachments 8/9)


Attachment 1: P_20210520_233112.jpeg
Attachment 2: P_20210520_233123.jpg
Attachment 3: P_20210520_233207.jpg
Attachment 4: P_20210520_231542.jpg
Attachment 5: P_20210520_231815.jpg
Attachment 6: P_20210520_195318.jpg
Attachment 7: P_20210520_231644.jpg
Attachment 8: P_20210520_233203.jpg
Attachment 9: P_20210520_195204.jpg
  16149   Fri May 21 00:05:45 2021 KojiUpdateSUSNew electronics: Sat Amp / Coil Drivers

11 new Satellite Amps were picked up from Downs. 7 more are coming from there. I have one spare unit I made. 1 sat amp has already been used at MC1.

We had 8 HAM-A coil drivers delivered from the assembling company. We also have two coil drivers delivered from Downs (Anchal tested)

Attachment 1: F3CDEF8D-4B1E-42CF-8EFC-EA1278C128EB_1_105_c.jpeg
  16148   Thu May 20 16:56:21 2021 KojiUpdateElectronicsProduction version of the HV coil driver tested with KEPCO HV supplies

HP HV power supply ( HP6209 ) were returned to Downs

Attachment 1: P_20210520_154523_copy.jpg
  16147   Thu May 20 10:35:57 2021 AnchalUpdateSUSIMC settings reverted

For future reference, the new settings can be upoaded from a script in the same directory. Run python /users/anchal/20210505_IMC_Tuned_SUS_with_Gains/uploadNewConfigIMC.py from allegra.


There isn't any instruction here on how to upload the new settings

  16146   Wed May 19 18:29:41 2021 KojiUpdateSUSMass Properties of SOS Assembly with 3"->2" Optic sleeve, in SI units

Calculation for the SOS POS/PIT/YAW resonant frequencies

- Nominal height gap between the CoM and the wire clamping point is 0.9mm (cf T970135)

- To have the similar res freq for the optic with the 3" metal sleeve is 1.0~1.1mm.
As the previous elog does not specify this number for the current configuration, we need to asses this value and the make the adjustment of the CoM height.

Attachment 1: SOS_resonant_freq.pdf
SOS_resonant_freq.pdf SOS_resonant_freq.pdf
Attachment 2: SOS_resonant_freq.nb.zip
  16145   Tue May 18 20:26:11 2021 ranaUpdatePSLHEPA speed raised

Fluke. Temp fluctuations are as usual, but the overall temperature is still lower. We ought to put some temperature sensors at the X & Y ends to see what's happening there too.

  16144   Tue May 18 00:52:38 2021 ranaUpdatePSLHEPA speed raised

Looks like the fan lowered the temperature as expected. Need to get a few more days of data to see if its stabilized, or if that's just a fluke.

The vertical line at 00:00 UTC May 18 is about when I turned the fans up/on.

Attachment 1: Untitled.png
  16143   Sat May 15 14:54:24 2021 gautamUpdateSUSIMC settings reverted

I want to work on the IFO this weekend, so I reverted the IMC suspension settings just now to what I know work (until the new settings are shown quantitatively to be superior). There isn't any instruction here on how to upload the new settings, so after my work, I will just restore from a burt-snapshot from before I changed settings.

In the process, I found something odd in the MC2 coil output filter banks. Attachment #1 shows what it it is today. This weird undetermined state of FM9 isn't great - I guess this flew under the radar because there isn't really any POS actuation on MC2. Where did the gain1 filter I installed go? Some foton filter file corruption? Eventually, we should migrate FM7,FM8-->FM9,FM10 but this isn't on my scope of things to do for today so I am just putting the gain1 filter back so as to have a clean FM9 switched on.


The old setting can be restored by running python3 /users/anchal/20210505_IMC_Tuned_SUS_with_Gains/restoreOldConfigIMC.py from allegra or donatella.


I wrote the values from the c1mcs burt snapshot from ~1400 Saturday May 15, at ~1600 Sunday May 16. I believe this undoes all my changes to the IMC suspension settings.

Attachment 1: MC2coilOut.png
  16142   Sat May 15 12:39:54 2021 gautamUpdatePSLNPRO tripped/switched off

The NPRO has been off since ~1AM this morning it looks like. Is this intentional? Can I turn it back on (or at least try to)? The interlock signal we are recording doesn't report getting tripped but I think this has been the case in the past too.

After getting the go ahead from Koji, I turned the NPRO back on, following the usual procedure of diode current ramping. PMC and IMC locked. Let's see if this was a one-off or something chronic.

Attachment 1: NPRO.png
  16141   Fri May 14 17:45:05 2021 ranaUpdatePSLHEPA speed raised

The PSL was too hot, so I turned on the south HEPA on the PSL. The north one was on and the south one was off (or so slow as to be inaudible and no vibration, unlike the north one). Lets watch the trend over the weekend and see if the temperature comes down and if the PMC / WFS variations get less. Fri May 14 17:46:26 2021

  16140   Fri May 14 03:29:50 2021 KojiUpdateElectronicsHV Driver noise test with the new HV power supply from Matsusada

I believe I did the identical test with the one in [40m ELOG 15786]. The + input of PA95 was shorted to the ground to exclude the noise from the bias input. The voltage noise at TP6 was measured with +/-300V supply by two HP6209 and two Matsusada R4G360.

With R4G360, the floor level was identical and 60Hz line peaks were less. It looks like R4G360 is cheap, easier and precise to handle, and sufficiently low noise.

Attachment 1: HV_Driver_PSD.pdf
  16139   Thu May 13 19:38:54 2021 AnchalUpdateSUSMC1 Satellite Amplifier Debugged

[Anchal Koji]

Koji and I did a few tests with an OSEM emulator on the satellite amplifier box used for MC1 which is housed on 1X4. This sat box unit is S2100029 D1002812 that was recently characterized by me 15803. We found that the differential output driver chip AD8672ARZ U2A section for the UL PD was not working properly and had a fluctuating offset at no input current from the PD. This was the cause of the ordeal of the morning. The chip was replaced with a new one from our stock. The preliminary test with the OSEM emulator showed that the channel has the correct DC value.

In further testing of the board, we found that the channel 8 LED driver was not working properly. Although this channel is never used in our current cable convention, it might be used later in the future. In the quest of debugging the issue there, we replaced AD8672ARZ at U1 on channel 8. This did not solve the issue. So we opened the front panel and as we flipped the board, we found that the solder blob shorted the legs of the transistor Q1 2N3904. This was replaced and the test with the LED out and GND shorted indicated that the channel is now properly providing a constant current of 35mA (5V at the monitor out).

After the debugging, the UL channel became the least noisy among the OSEM channels! Mode cleaner was able to lock and maintain it.

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

Attachment 1: MC1_UL_Channel_Fixed.png
  16138   Thu May 13 11:55:04 2021 Anchal, PacoUpdateSUSMC1 suspension misbehaving

We came in the morning with the following scene on the zita monitor:

The MC1 watchdog was tripped and seemed like IMC struggled all night with misconfigured WFS offsets. After restoring the MC1 WD, clearing the WFS offsets, and seeing the suspension damp, the MC caught lock. It wasn't long before the MC unlocked, and the MC1 WD tripped again.

We tried few things, not sure what order we tried them in:

  • Letting suspension loops damp without the WFS switched on.
  • Letting suspension loops damp with PSL shutter closed.
  • Restoring old settings of MC suspension.
  • Doing burt restore with command:
    burtwb -f /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2021/May/12/08:19/c1mcsepics.snap -l /tmp/controls_1210513_083437_0.write.log -o /tmp/controls_1210513_083437_0.nowrite.snap -v <

Nothing worked. We kept seeing that ULPD var on MC1 keeps showing kicks every few minutes which jolts the suspension loops. So we decided to record some data with PSL shutter closed and just suspension loops on. Then we switched off the loops and recorded some data with freely swinging optic. Even when optic was freely swinging, we could see impulses in the MC1 OSEM UL PD var which were completely uncorrelated with any seismic activity. Infact, last night was one fo teh calmer nights seismically speaking. See attachment 2 for the time series of OSEM PD variance. Red region is when the coil outputs were disabled.


  • We think something is wrong with the UL OSEM of MC1.
  • It seems to show false spikes of motion when there is no such spike present in any other OSEM PD or the seismic data itself.
  • Currently, this is still the case. We sometimes get 10-20 min of "Good behavior" when everything works.
  • But then the impulses start occuring again and overwhelmes the suspension loops and WFS loops.
  • Note, that other optic in IMC behaved perfectly normally throughout this time.
  • In the past, it seems like satellite box has been the culprit for such glitches.
  • We should look into debugging this as ifo is at standstill because of this issue.
  • Earlier, Gautum would post Vmon signals of coil outputs only to show the glitches. We wanted to see if switching off the loops help, so we recorded OSEM PD this time.
  • In hindsight, we should probably look at the OSEM sensor outputs directly too rather than looking at the variance data only. I can do this if people are interested in looking at that too.
  • We've disabled the coil ouputs in MC1 and PSL shutter is off.

Edit Thu May 13 14:47:25 2021 :

Added OSEM Sensor timeseries data on the plots as well. The UL OSEM sensor data is the only channel which is jumping hapazardly (even during free swinging time) and varying by +/- 30. Other sensors only show some noise around a stable position as should be the case for a freely suspended optic.

Attachment 2: MC1_Glitches_Invest2.pdf
  16137   Wed May 12 17:06:52 2021 JordanUpdateSUSMass Properties of SOS Assembly with 3"->2" Optic sleeve, in SI units

Here are the mass properties for the only the test mass assembly (optic, 3" ring, and wire block). (Updated with g*mm^2)


No, this is the property of the suspension assembly. The mass says 10kg

Could you do the same for the testmass assembly (only the suspended part)? The units are good, but I expect that the values will be small. I want to keep at least three significant digits.


Attachment 1: Moments_of_Inertia_SI.PNG
  16136   Wed May 12 16:53:59 2021 KojiUpdateSUSMass Properties of SOS Assembly with 3"->2" Optic sleeve, in SI units

No, this is the property of the suspension assembly. The mass says 10kg

Could you do the same for the testmass assembly (only the suspended part)? The units are good, but I expect that the values will be small. I want to keep at least three significant digits.

  16135   Wed May 12 14:23:20 2021 JordanUpdateSUSMass Properties of SOS Assembly with 3"->2" Optic sleeve, in SI units
Attachment 1: Moments_of_Inertia_SI.PNG
  16134   Wed May 12 13:06:15 2021 Ian MacMillanUpdateCDSSUS simPlant model

Working with Chris, we decided that it is probably better to use a simple filter module as a controller before we make the model more complicated. I will use the plant model that I have already made (see attachment 1 of this). then attach a single control filter module to that: as seen in attachment 1. because I only want to work with one degree of freedom (position) I will average the four outputs which should give me the position. Then by feeding the same signal to all four inputs I should isolate one degree of freedom while still using the premade plant model.

The model I made that is shown in attachment 2 is the model I made from the plan. And it complies! yay! I think there is a better way to do the average than the way I showed. And since the model is feeding back on itself I think I need to add a delay which Rana noted a while ago. I think it was a UnitDelay (see page 41 of RTS Developer’s Guide). So I will add that if we run into problems but I think there is enough going on that it might already be delayed.

Since our model (x1sup_isolated.mdl) has compiled we can open the medm screens for it. I provide a procedure below which is based on Jon's post

[First start the cymac and have the model running]
$  cd docker-cymac
$  eval $(./env_cymac)

$  medm -x /opt/rtcds/tst/x1/medm/x1sup_isolated/X1SUP_ISOLATED_GDS_TP.adl

To see a list of all medm screens use:

$  cd docker-cymac
$  ./login_cymac
 #  cd /opt/rtcds/tst/x1/medm/x1sup_isolated
 #  ls

Some of the other useful ones are:

adl screen Description
X1SUP_ISOLATED_Control_Module.adl This is the control filter module shown in attachment 2 at the top in the center. This module will represent the control system.

See attachment 4. This screen shows the POS plant filter module that will be filled by the filter representing the transfer function of a damped harmonic oscillator:        \frac{x}{F}=\frac{\omega_0^2}{\omega_0^2+i\frac{\omega_0 \omega}{Q}-\omega^2}


The first one of these screens that are of interest to us (shown in attachment 3) is the X1SUP_ISOLATED_GDS_TP.adl screen, which is the CDS runtime diagnostics screen. This screen tells us "the success/fail state of the model and all its dependencies." I am still figuring out these screens and the best guide is T1100625.

The next step is taking some data and seeing if I can see the position damp over time. To do this I need to:

  1. Edit the plant filter for the model and add the correct filter.
  2. Figure out a filter for the control system and add it to that. (I can leave it as is to see what the plant is doing) 
  3. Take some position data to show that the plant is a harmonic oscillator and is damping away.
Attachment 1: SimplePlant_SingleContr.pdf
Attachment 2: x1sup_isolated.pdf
Attachment 3: X1SUP_ISOLATED_GDS_TP.png
Attachment 4: X1SUP_ISOLATED_C1_SUS_SINGLE_PLANT_Plant_POS_Mod.png
  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
  16132   Wed May 12 10:53:20 2021 Anchal, PacoUpdateLSCPSL-IMC PDH Loop and XARM PDH Loop diagram

Attached is the control loop diagram when main laser is locked to IMC and a single arm (XARM) is locked to the transmitted light from IMC.

  • I'll post a clean loop diagram soon to make this loopology clearer.


Attachment 1: IMC_SingleArm.pdf
  16131   Tue May 11 17:43:09 2021 KojiUpdateCDSI/O Chassis Assembly

Did you match the local PC time with the GPS time?

  16130   Tue May 11 16:29:55 2021 JonUpdateCDSI/O Chassis Assembly

Timing system set-up

The next step is to provide the 65 kHz clock signals from the timing fanout via LC optical fiber. I overlooked the fact that an SPX optical transceiver is required to interface the fiber to the timing slave board. These were not provided with the timing slaves we received. The timing slaves require a particular type of transceiver, 100base-FX/OC-3, which we did not have on hand. (For future reference, there is a handy list of compatible transceivers in E080541, p. 14.) I placed a Digikey order for two Finisar FTLF1217P2BTL, which should arrive within two days.

Today I brought and installed the new optical transceivers (Finisar FTLF1217P2BTL) for the two timing slaves. The timing slaves appear to phase-lock to the clocking signal from the master fanout. A few seconds after each timing slave is powered on, its status LED begins steadily blinking at 1 Hz, just as in the existing 40m systems.

However, some other timing issue remains unresolved. When the IOP model is started (on either FE), the DACKILL watchdog appears to start in a tripped state. Then after a few minutes of running, the TIM and ADC indicators go down as well. This makes me suspect the sample clocks are not really phase-locked. However, the models do start up with no error messages. Will continue to debug...

Attachment 1: Screen_Shot_2021-05-11_at_3.03.42_PM.png
  16129   Mon May 10 18:19:12 2021 Anchal, PacoUpdateLSCIMC WFS noise contribution in arm cavity length noise, Corrections

A few corrections to last analysis:

  • The first plot was not IMC frequency noise but actually MC_F noise budget.
    • MC_F is frequency noise in the IMC FSS loop just before the error point where IMC length and laser frequency is compared.
    • So, MC_F (in high loop gain frequency region upto 10kHz) is simply the quadrature noise sum of free running laser noise and IMC length noise.
    • Between 1Hz to 100 Hz, normally MC_F is dominated by free running laser noise but when we injected enough angular noise in WFS loops, due to Angle to length coupling, it made IMC length noise large enough in 25-30 Hz band that we started seeing a bump in MC_F.
    • So this bump in MC_F is mostly the noise due to Angle to length coupling and hence can be used to calculate how much Angular noise normally goes into length noise.
  • In the remaining plots, MC_F was plotted with conversion into arm length units but this was wrong. MC_F gets suppressed by IMC FSS open loop gain before reaching to arm cavities and hence is hardly present there.
  • The IMC length noise however is not suppresed until after the error point in the loop. So the length noise (in units of Hz calculated in the first step above) travels through the arm cavity loop.
  • We already measured the transfer function from ITMX length actuation to XARM OUT, so we know how this length noise shows up at XARM OUT.
  • So in the remaining plots, we plot contribution of IMC angular noise in the arm cavities. Note that the factor of 3 business still needed to be done to match the appearance of noise in XARM_OUT and YARM_OUT signal from the IMC angular noise injection.
  • I'll post a clean loop diagram soon to make this loopology clearer.
Attachment 1: ArmCavNoiseContributions.pdf
ArmCavNoiseContributions.pdf ArmCavNoiseContributions.pdf ArmCavNoiseContributions.pdf ArmCavNoiseContributions.pdf ArmCavNoiseContributions.pdf ArmCavNoiseContributions.pdf ArmCavNoiseContributions.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
  16127   Fri May 7 11:54:02 2021 Anchal, PacoUpdateLSCIMC WFS noise contribution in arm cavity length noise

We today measured the calibration factors for XARM_OUT and YARM_OUT in nm/cts and replotted our results from 16117 with the correct frequency dependence.

Calibration of XARM_OUT and YARM_OUT

  • We took transfer function measurement between ITMX/Y_LSC_OUT and X/YARM_OUT. See attachment 1 and 2
  • For ITMX/Y_LSC_OUT we took calibration factor of 3*2.44/f2 nm/cts from 13984. Note that we used the factor of 3 here as Gautum has explicitly written that the calibration cts are DAC cts at COIL outputs and there is a digital gain of 3 applied at all coil output gains in ITMX and ITMY that we confirmed.
  • This gave us callibration factors of XARM_OUT: 1.724/f2 nm/cts , and YARM_OUT: 4.901/f2 nm/cts. Note the frrequency dependence here.
  • We used the region from 70-80 Hz for calculating the calibration factor as it showed the most coherence in measurement.

Inferring noise contributions to arm cavities:

  • For converting IMC frequency noise to length noise, we used conversion factor given by \lambda L / c where L is 37.79m and lambda is wavelength of light.
  • For converting MC1 ASCPIT OUT cts data to frequency noise contributed to IMC, we sent 100,000 amplitude bandlimited noise  from 25 Hz to 30 Hz at C1:IOO-MC1_PIT_EXC. This noise was seen at both MC_F and ETMX/Y_LSC_OUT channels. We used the noise level at 29 Hz to get a calibration for MC1_ASCPIT_OUT to IMC Frequency in Hz/cts. This measurement was done in 16117.
  • Once we got the calibration above, we measured MC1_ASCPIT_OUT power spectrum without any excitaiton and multiplied it with the calibration factor.
  • Attachment 3 is our main result.
    • Page 1 shows the calculation of Angle to Length coupling by reading off noise injects in MC1_ASCPIT_OUT in MC_F. This came out to 10.906/f2 kHz/cts.
    • Page 2-3 show the injected noise in X arm cavity length units. Page 3 is the zoomed version to show the matching of the 2 different routes of calibration.
    • BUT, we needed to remove that factor of 3 we incorporated earlier to make them match.
    • Page 4 shows the noise contribution of IMC angular noise in XARM cavity.
    • Page 5-6 is similar to 2-3 but for YARM. The red note above applied here too! So the factor of 3 needed to be removed in both places.
    • Page 7 shows the noise contribution of IMC angular noise in XARM cavity.


  • IMC Angular noise contribution to arm cavities is atleast 3 orders of magnitude lower then total armc cavity noise measured.

Edit Mon May 10 18:31:52 2021

See corrections in 16129.

Attachment 1: ITMX-XARM_TF.pdf
Attachment 2: ITMY-YARM_TF.pdf
Attachment 3: ArmCavNoiseContributions.pdf
ArmCavNoiseContributions.pdf ArmCavNoiseContributions.pdf ArmCavNoiseContributions.pdf ArmCavNoiseContributions.pdf ArmCavNoiseContributions.pdf ArmCavNoiseContributions.pdf ArmCavNoiseContributions.pdf
  16126   Fri May 7 11:19:29 2021 Ian MacMillanUpdateCDSSUS simPlant model

I copied c1scx.mdl to the docker to attach to the plant using the commands:

$  ssh nodus.ligo.caltech.edu
[Enter Password]
$  cd opt/rtcds/userapps/release/isc/c1/models/simPlant
$  scp c1scx.mdl controls@c1sim:/home/controls/docker-cymac/userapps
  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
  16124   Thu May 6 16:13:24 2021 Ian MacMillanUpdateCDSSUS simPlant model

When using mdl2adl I was getting the error:

$  cd /home/controls/mdl2adl
$  ./mdl2adl x1sup.mdl
error: set $site and $ifo environment variables

to set these in the terminal use the following commands:

$  export site=tst
$  export ifo=x1

On most of the systems, there is a script that automatically runs when a terminal is opened that sets these but that hasn't been added here so you must run these commands every time you open the terminal when you are using mdl2adl.

  16122   Wed May 5 15:11:54 2021 Ian MacMillanUpdateCDSSUS simPlant model

I added the IPC parts back to the plant model so that should be done now. It looks like this again here.

I can't seem to find the control model which should look like this. When I open sus_single_control.mdl, it just shows the C1_SUS_SINGLE_PLANT.mdl model. Which should not be the case.

  16121   Wed May 5 13:05:07 2021 ChubUpdateGeneralchassis delivery from De Leone

Assembled chassis from De Leone placed in the 40 Meter Lab, along the west wall and under the display pedestal table.  The leftover parts are in smaller Really Useful boxes, also on the parts pile along the west wall.

Attachment 1: de_leone_del_5-5-21.jpg
  16120   Wed May 5 09:04:47 2021 AnchalUpdateSUSNew IMC Suspension Damping Gains uploaded for long term testing

We have uploaded the new damping gains on all the suspensions of IMC. This completes changing all the configuration to as mentioned in 16066 and 16072. The old setting can be restored by running python3 /users/anchal/20210505_IMC_Tuned_SUS_with_Gains/restoreOldConfigIMC.py from allegra or donatella.

GPSTIME: 1304265872

UTC May 05, 2021 16:04:14 UTC
Central May 05, 2021 11:04:14 CDT
Pacific May 05, 2021 09:04:14 PDT


  16119   Tue May 4 19:14:43 2021 YehonathanUpdateGeneralOSEMs from KAGRA

I put the box containing the untested OSEMs from KAGRA near the south flow bench on the floor.

  16118   Tue May 4 14:55:38 2021 Ian MacMillanUpdateCDSSUS simPlant model

After a helpful meeting with Jon, we realized that I have somehow corrupted the sitemap file. So I am going to use the code Chris wrote to regenerate it. 

Also, I am going to connect the controller using the IPC parts. The error that I was having before had to do with the IPC parts not being connected properly. 

  16117   Tue May 4 11:43:09 2021 Anchal, PacoUpdateLSCIMC WFS noise contribution in arm cavity length noise

We redid the WFS noise injection test and have compiled some results on noise contribution in arm cavity noise and IMC frequency noise due to angular noise of IMC.

Attachment 1: Shows the calibrated noise contribution from MC1 ASCPIT OUT to ARM cavity length noise and IMC frequency noise.

  • For calibrating the cavity length noise signals, we sent 100 cts 100Hz sine excitation to ITMX/Y_LSC_EXC, used actuator calibration for them as 2.44 nm/cts from 13984, and measured the peak at 100 hz in time series data. We got calibration factors: ETMX-LSC_OUT: 60.93 pm/cts , and ETMY-LSC_OUT: 205.0 pm/cts.
  • For converting IMC frequency noise to length noise, we used conversion factor given by \lambda L / c where L is 37.79m and lambda is wavelength of light.
  • For converting MC1 ASCPIT OUT cts data to frequency noise contributed to IMC, we sent 100,000 amplitude bandlimited noise (see attachment 3 for awggui config) from 25 Hz to 30 Hz at C1:IOO-MC1_PIT_EXC. This noise was seen at both MC_F and ETMX/Y_LSC_OUT channels. We used the noise level at 29 Hz to get a calibration for MC1_ASCPIT_OUT to IMC Frequency in Hz/cts. See Attachment 2 for the diaggui plots.
  • Once we got the calibration above, we measured MC1_ASCPIT_OUT power spectrum without any excitaiton and multiplied it with the calibration factor.
  • However, something must be wrong because the MC_F noise in length units is coming to be higher than cavity length noise in most of the frequency band.
    • It can be due to the fact that control signal power spectrum is not exactly cavity length noise at all frequencies.  That should be only above the UGF of the control loop (we plan to measure that in afternoon).
    • Our calibration for ETMX/Y_LSC_OUT might be wrong.
Attachment 1: ArmCavNoiseContributions.pdf
ArmCavNoiseContributions.pdf ArmCavNoiseContributions.pdf ArmCavNoiseContributions.pdf
Attachment 2: IOO-MC1_PIT_NoiseInjTest2.pdf
IOO-MC1_PIT_NoiseInjTest2.pdf IOO-MC1_PIT_NoiseInjTest2.pdf
Attachment 3: IOO-MC1_PIT_NoiseInjTest_AWGGUI_Config.png
  16116   Tue May 4 07:38:36 2021 JonUpdateCDSI/O Chassis Assembly

IOP models created

With all the PCIe issues now resolved, yesterday I proceeded to build an IOP model for each of new FEs. I assigned them names and DCUIDs consist with the 40m convention, listed below. These models currently exist on only the cloned copy of /opt/rtcds running on the test stand. They will be copied to the main network disk later, once the new systems are fully tested.

Model Host CPU DCUID
c1x06 c1bhd 1 23
c1x07 c1sus2 1 24

The models compile and install successfully. The RCG runtime diagnostics indicate that all is working except for the timing synchronization and DAQD data transmission. This is as expected because neither of these have been set up yet.

Timing system set-up

The next step is to provide the 65 kHz clock signals from the timing fanout via LC optical fiber. I overlooked the fact that an SPX optical transceiver is required to interface the fiber to the timing slave board. These were not provided with the timing slaves we received. The timing slaves require a particular type of transceiver, 100base-FX/OC-3, which we did not have on hand. (For future reference, there is a handy list of compatible transceivers in E080541, p. 14.) I placed a Digikey order for two Finisar FTLF1217P2BTL, which should arrive within two days.

Attachment 1: Screen_Shot_2021-05-03_at_4.16.06_PM.png
  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.


  16114   Mon May 3 20:36:46 2021 Yehonathan, JonUpdateCDSUpdated c1auxey wiring plan

It seemed like the BIO channels were not working, both the inputs and the outputs. The inputs were working on the windows machine though. That is, when we shorted the BIO channel to the return, or put 0V on it, we could see the LED turn on on the I/O testing screen and when we ramped up the voltage above 3 the LED turned off. This is the expected behavior from a sinking digital input. However, the EPICs caget didn't show any change. All the channels were stuck on Disabled.

We checked the digital outputs by connecting the channels to a fluke. Initially, the fluke showed 13V. We tried to toggle the digital output channels with caput and that didn't work. We checked the outputs with the windows software. For that, we needed to stop the Modbus. To our surprise, the windows software was not able to flip the channels either. We realized that this BIO Acromag unit is probably defective. We replaced it with a different unit and put a warning sticker on the defective unit. Now, the digital outputs were working as expected. When we turned them on the voltage output dropped to 0V. We checked the channels with the EPICs software. We realized that these channels were locked with the closed loop definition. We turned on the channels tied to these output channels (watchdog and toggles) and it worked. The output channels can be flipped with the EPICs software. We checked all the digital output channels and fixed some wiring issues along the way.

The digital input channels were still not working. This is a software issue that we will have to deal with later.

(Yehonathan) Rana noticed that the BNC leads on the chassis front panel didn't have isolation on them so I redid them with shrinking tubes.

  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
  16112   Mon May 3 17:28:58 2021 Anchal, Paco, RanaUpdateLSCIMC WFS noise contribution in arm cavity length noise

Rana came and helped us figure us where to inject the noise. Following are the characteristics of the test we did:

  • Inject normal noise at C1:IOO-MC1_PIT_EXC using AWGGUI.
  • Excitation amplitude of 54321 in band 12-37Hz with Cheby1 8th order bandpass filter with same limits.
  • Look at power spectrum of C1:IOO-MC_F_DQ, C1:IOO-WFS1-PIT_OUT_DQ and the C1:IOO-MC1_PIT_EXC itself.
  • Increased the gain of the noise excitation until we see some effect in MC_F.
  • Diaggui also showed coherence plot in the bottom, which let's us have an estimate of how much we need to go further.

Attachment 1 shows a screenshot with awggui and diaggui screens displaying the signal in both angular and longitudinal channels.

Attachment 2 shows the analogous screenshot for MC2.


Attachment 1: excitationoftheMCanglessothatwecanseesomethingdotpng.png
Attachment 2: excitationoftheMCanglessothatwecanseesomethingdotpngbutthistimeitsMC2.png
  16111   Mon May 3 16:49:04 2021 YehonathanUpdateBHDSOS assembly

I found a "vice" in the cleanroom (attachment 1). I used it to push dowel pins into the last suspension block using some alcohol as a lubricant.

I then assembled the 7th and last suspension tower (attachment 2).

Things that need to be done:

1. Push Viton tips into vented screws and assemble the earthquake stops.

2. Glue magnets to dumbells.

Attachment 1: 20210503_161422.png
Attachment 2: 20210503_161456.jpg
  16110   Mon May 3 16:24:14 2021 AnchalUpdateSUSIMC Suspension Damping Gains Test Repeated with IMC unlocked

We repeated the same test with IMC unlocked. We had found these gains when IMC was unlocked and their characterization needs to be done with no light in the cavity. attached are the results. Everything else is same as before.


With the input matrix, coil ouput gains and F2A filters loaded as in 16091, I tested the suspension loops' step response to offsets in LSC, ASCPIT and ASCYAW channels, before and after applying the "new damping gains" mentioned in 16066 and 16072. If these look better, we should upload the new (higher) damping gains as well. This was not done in 16091.

Note that in the plots, I have added offsets in the different channels to plot them together, hence the units are "au".

Edit Tue May 4 14:43:48 2021 :

  • Adding zoomed in plots to show first 25s after the step.
  • MC1:
    • Our improvements by new gains are only modest.
    • This optic needs a more careful coil balancing first.
    • Still the ring time is reduced to about 5s for all step responses as opposed to 10s at old gains.
  • MC2:
    • The first page of MC2 might be bit misleading. We have not changed the damping gain for SUSPOS channel, so the longer ringing is probably just an artifact of somthing else. We didn't retake data.
    • In PIT and YAW where we increased the gain by a factor of 3, we see a reduction in ringing lifetime by about half.
  • MC3:
    • We saw the most optimistic improvement on this optic.
    • The gains were unusually low in this optic, not sure why.
    • By increasing SUSPOS gain from 200 to 500, we saw a reduction of ringing halftime from 7-8s to about 2s. Improvements are seen in other DOFs as well.
    • You can notice rightaway that YAW of MC3 keeps oscillating near resonance (about 1 Hz). Maybe more careful feedback shaping is required here.
    • In SUSPIT, we increased gain from 12 to 35 and saw a good reduction in both ringing time and initial amplitude of ringing.
    • In SUSYAW, we only increased the gain to 12 from 8, which still helped a lot in reducing big ringing step response to below 5s from about 12s.

Overall, I would recommend setting the new gains in the suspension loops as well to observe long term effects too.

Attachment 1: MC1_SusDampGainTest.pdf
MC1_SusDampGainTest.pdf MC1_SusDampGainTest.pdf MC1_SusDampGainTest.pdf
Attachment 2: MC2_SusDampGainTest.pdf
MC2_SusDampGainTest.pdf MC2_SusDampGainTest.pdf MC2_SusDampGainTest.pdf
Attachment 3: MC3_SusDampGainTest.pdf
MC3_SusDampGainTest.pdf MC3_SusDampGainTest.pdf MC3_SusDampGainTest.pdf
  16109   Mon May 3 13:35:12 2021 Ian MacMillanUpdateCDSSUS simPlant model

When the cymac is started it gives me a list of channels shown below. 

 $  Initialized TP interface node=8, host=98e93ecffcca
 $  Creating X1:DAQ-DC0_X1IOP_STATUS
 $  Creating X1:DAQ-DC0_X1IOP_CRC_CPS
 $  Creating X1:DAQ-DC0_X1IOP_CRC_SUM
 $  Creating X1:DAQ-DC0_X1SUP_STATUS
 $  Creating X1:DAQ-DC0_X1SUP_CRC_CPS
 $  Creating X1:DAQ-DC0_X1SUP_CRC_SUM

But when I enter it into the Diaggui I get an error:

The following channel could not be found:

My guess is that need to connect to the Diaggui to something that can access those channels. I also need to figure out what those channels are.

ELOG V3.1.3-