40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 19 of 346 Not logged in
ID Date Author Type Category Subject
17436   Tue Jan 31 20:49:46 2023 AnchalUpdateALSMoku Phasemeter AM coupling and comparison

Model changes and addition of Moku Phasemeter

Today I setup Moku:Pro MP1 with phasemeter app to replace DFD + Phase tracker.

Phasemeter settings:

• Both channels:
• Frequency: Auto (Auto track frequency)
• Bandwidth: 1 MHz
• Freewheeling: ON
• Single input: ON (Used for now, later the two channels will use different inputs)
• Output for both outputs:
• Signal: Freq offset
• Scaling: 1.000 mV/Hz
• Invert: off
• Offset: 0.0000 V

Moku Input output settings:

• In 1 and In 2:
• AC: 50 Ohm
• -20 dB attenuation: 4 Vpp range
• Out1 and Out2:
• +14 dB gain: 10 Vpp range

The phasemeter is set to autotrack the frequency with PLL bandwidth fo 1 MHz. The output of the phasemeter (frequency offset) is sent out through the output channels at 1mV/Hz rate. These are digitized at c1lsc ADC and are available as an alternative to phase tracker output channel. One can switch between the two ways of measurement by using C1:ALS-SEL_PHASE_SOURCE channel. See attachment 1 and 2 for the two mode options. For this, I modified c1lsc model today

Moku Phasemeter calibration

I used marconi to send 45 MHz RF output as -2 dBm level with internal FM modulation of peak 200 Hz at 211 Hz. This was used to calibrate the Moku Phasemeter outputs to set channels

C1:ALS-BEATX_MOKU_PHASE_OUTPUT_HZ and C1:ALS-BEATY_MOKU_PHASE_OUTPUT_HZ in units of Hz. This method is not very reliable as I do not know if marconi actually sent 200 Hz peak. The calculations from ADC conversion and moku slope of 1mV/Hz give similar numbers though. However, if we want to be accurate in our calibration project, more detailed calibration of these channels is required with a better technique. For now, I assumed that this value is good atleast to a 1% level.

AM coupling test and noise measurement

I followed the exact same setup as in 40m/17409 to create a RF signal using MP1 waveform generator which is AM modulated by awggui noise excitation to create similar AM noise as measured for BEATY RF output. The measurement can then take AM coupling transfer function measurements. Attachment 3 are the results of this measurement. In comparison to DFD + Phase tracker system, the transfer function is 2 orders of magnitude less. Even if my calibration of AM modulation is wrong, same calibration is sued for both transfer functions, so the difference measured is real. We are mostly measuring noise in this measurement as the coherence is also very low for all of the frequency range. See the 4th plot to see the inferred measurement noise of Moku phasemeter setup. Attachment 4 shows this data in comparison to data taken in 40m/17409 with DFD + Phase Tracker setup. Moku Phasemter setup provides roughly factor of 4 less noise in our calibration line frequency band.

Quote:

I took transfer function measurement of DFD AM coupling using noise excitation.

Noise excitation setup

Noise is injected using C1:BAC-SPARE_CH14_EXC using awggui which is filtered by a foton filter to simulate the real beatnote RF amplitude noise measured by taking quadrature sum of C1:ALS-BEATY_FINE_I_OUT and C1:ALS-BEATY_FINE_Q_OUT. See attachment 1.

The DAC output is connected to MP1 at CH1. MP1 is set to run in waveform generation mode with following settings:

• Carrier frequency: 45 MHz
• Carrier Level: 500 mVpp
• No offset or phase offset
• Amplitude modulation ON
• Modulation slope: 100%/V
• Source Input: Ch1

The AWGUI is set to excite C1:BAC-SPARE_CH14_EXC using settings mentioned in attachment 2.

With this setup, the RF amplitude noise is simulated with MP1 and DAC excitation.

Transfer function measurement

With AWGGUI running as mentioned above, I simply used diaggui in spectrum mode for channels C1:BAC-SPARE_CH14_EXC and C1:ALS-BEATY_FINE_PHASE_OUT_HZ. The second channel is already calibrated into Hz, and the first channel is in counts. To convert it into voltage of amplitude fluctuation, I first converted DAC excitation to voltage by assuming 16 bit DAC with +/- 10 V range, this gives conversion constant of 10/2**15 V/cts. Then since MP1 is doing 100%/V AM modulation, for 500 mVpp RF level, this means 0.25 V/V AM modulation. Multiplying these two together gives, 7.6294e-5 V/cts. I put this number in teh diaggui calibration for C1:ALS-BEATY_FINE_PHASE_OUT_HZ.

This created the transfer function measurement attached in attachment 3.

The measurement resulted in roughly 2kHz/V AM to frequency coupling in DFD + phase tracker setup. The previous measurement with coherent sinusoidal excitation was exactly a factor of 1000 less than this, so I believe I might have made some error in calibrating or there could be an error in the previous elog. Please check my calculations. But a solid thing to note is the coherence measured below 1Hz. I'll do more sophisticated analysis on weekdays.

I also think that coherence was low because of low excitation. We should redo this test with more noise power to get good coherence in all frequency band to have good idea of what would happen to ebatnote RF amplitude noise at all frequencies.

Mon Jan 23 11:47:23 2023 Adding Attachment 4:

I realised that with the noise excitation setup set to mimic real beatnote amplitude noise with very low frequency noise as it is seeded with Moku:Pro, the measured frequency noise by the DFD+Phase Tracker setup at C1:ALS-BEATY_FINE_PHASE_OUT_HZ is an indicator of how much RF amplitude noise of beatnote contribute to the frequency noise measured by DFD+Phase tracker. Attachment 4 is the spectrum measured during this measurement.

Attachment 1: ALS_DFD_Phase_Tracker_Mode.png
Attachment 2: ALS_Moku_Phasemeter_Mode.png
Attachment 3: MokuPhaseMeter_AM_Coupling_TF_and_Noise.pdf
Attachment 4: PhaseMeasurementComparisonWithSimulatedRFsource.pdf
17438   Wed Feb 1 11:52:13 2023 AnchalUpdateALSMoku Phasemeter AM coupling and comparison

I wondered if Moku could have lied about its noise measurement since the RF source was the same Moku device. To avoid this bias, today I repeated this measurement with sendinf RF from Marconi. Marconi settings were:

• Carrier Frequency: 45 MHz
• RF Level: -2 dBm
• Mod AM ext DC: 90 %

The Marconi was fed noise from DAC output to match the measured BEATY RF amplitude like the previous posts: Attachment 1 shows AWGGUI settings required and attachment 2 shows the measured RF amplitude noise with the simulated source.

This source was then fed one by one to DFD + Phase tracker system (attachment 3) and then Moku Phasemeter setup (attachment 4). The phasemeter settigns were same as the previous post. Attachment 5 shows the two transfer functions of AM to frequency coupling on the same plot for comparison. Attachment 6 shows the comparison of frequency noise floor between the two methods on the same plot. In this measurement, I rechecked by DAC actuation calibration by measuring it directly. For Marconi AM modulation slope, I took into account the fact that the slope is in %/Vrms. I got it crosschecked with Paco this time. I think the calibration is correct. Moku phasemeter is indeed better by atleast 20 times in the frequency region of interest. The nosie floor is a factor of 3 less. I think this measurement clears Moku phasemter as the choice of frequency discriminator for calibration project. Any comments/opinions are welcome.

Attachment 1: AWGGUI_Setting.png
Attachment 2: BeatYRFAmplitudeNoiseASDwithSimulation.pdf
Attachment 3: DFD_AM_Coupling_TF_BW0p187493.pdf
Attachment 4: MokuPhaseMeter_AM_Coupling_TF_BW0p187493.pdf
Attachment 5: AMtoFrequency_Coupling_Comparison.pdf
Attachment 6: PhaseMeasurementComparisonWithSimulatedRFsource.pdf
17443   Thu Feb 2 19:41:49 2023 AnchalSummaryPowerShutdownRecovery from power outage events

JC reported that power outage happened twice in 40m today at around 4:17 pm.

We followed instructions from this page mostly to recover today. Following are some highlights:

Main laser controller fan broke

Paco reported that the adhoc fan in the back of main laser controller slid down and broke. Their might be contamination on the table from broken fan parts. Paco replaced this fan with another fan which is larger. I think it is time to fix this fan on the controller for good.

Main volume valve V1 shutdown

The main volume valve shut down because c1vac turned off. We restored the vacuum state by simply opening this valve again. Everything else was same as until the final step in vacuum resetting steps.

Mode cleaner locking issues

The burt restore for mode cleaner board settings do not bring back the state of channels C1:IOO-MC_FASTSW and C1:IOO-MC_POL. This has been an issue which has puzzled us in the past too as we try to get the mode cleaner to lock after power outage recovery. I have now added these channels and their required state in autolocker settings so that autolocker scan in the correct state always. It seems like I added with Yuta's name in the commit author.

17444   Fri Feb 3 12:50:47 2023 AnchalUpdateASCAS WFS model changes and phase calibration

Model and medm changes

After incrementally doing the model changes, I found out that the model was failing to build because of creation of a subsystem. If I just kept all divertor blocks out in the main model instead of in a single subsystem, the compilation works. Maybe the reason is because RCG can only take subsystems at base level which have top_names attribute. But I did nto test this, I just went with what works.

In summary, I added a new subsystem in c1ioo model called AWS (stands for Antisymmetric Wavefront Sensors). This subsystem and IOO subsystem receive teh WFS RF demodulated signals based on a single binary switch named C1:IOO-SEL_WFS_IMC_OR_AS. Value 0 connects the subsystem IOO to the inputs and value 1 connects AWS to the inputs. There is a switch on the left edge in the WFS screens now to select between the two.

Inside the AWS, the WFS I/Q phase rotation is done and then it goes into one of the two subsystems called AWS-XARM or AWS-YARM for using the AS for either XARM or YARM. THis is based on a single binary switch called C1:AWS-SEL_ARM_X_OR_Y. Value 0 selects output to XARM and value 1 selects output to YARM. There is a switch near top left of  C1AWS_XARM_WFS_MASTER.adl and C1AWS_YARM_WFS_MASTER.adl screens. I copied these screens from C1IOO_WFS_MASTER.adl, so they have same structure. See attachment 1. Any edits should be made to /opt/rtcds/caltech/c1/medm/c1ioo/master/C1AWS_XARM_WFS_MASTER.adl and simply run python opt/rtcds/caltech/c1/medm/c1ioo/master/createYARMWFSscreensFromX.py to create teh YARM screen from it.

Along with this, models c1scy and c1scx were edited also to take in IPC directly from c1ioo instead of going through RFM. We should phase out use of RFM eventually and directly connect all IPC connections with the ends.

First tests

[Anchal, Yuta]

After the model is up and running, we flipped the WFS path to use AS beam. I switched the 8 RF outputs of the WFS from IMC WFS boads to AS WFS boards and switched the IDC connectors to WFS. Attachment 2 shows teh photo in this flipped state. Then we misaligned both ITMX and ETMX. First simple test was to check if we see the YARM PDH error signal when YARM was flashing. And indeed we saw that on all 16 channels. So next we locked YARM and injected 311 Hz line with 300 counts amplitude at ETMY. We looked for this peak in the Q channels of WFS outputs and adjusted all phases to 0.1 degrees to minimize Q signal to the noise floor. For WFS2 case, teh SNR is bit higher due to more power than WFS1 and their phase angle might be adjusted to even better degree but we did not got for it.

Then I used C1AWS_XARM_WFS_MASTER.adl>!Actions>Correct WFS RF offsets button to remove offsets in all the RF demodulated signals. I have set this button to use /opt/rtcds/caltech/c1/Git/40m/scripts/RFPD/resetOffsets.py script.

At this point, we are ready to see if we have WFS sensitivity but I need to work on other projects today and Yuta and Paco took over interferometer for 60 Hz noise hunting.

Attachment 1: YARM_WFS_MASTER.png
Attachment 2: PXL_20230203_211014833.jpg
17448   Sat Feb 4 14:55:25 2023 AnchalUpdateASCDC sensing matrix for AS WFS for YARM

Filter and scripts setup

I copied IOO_WFS1_I filter bank to AWS_WFS1/2_I/Q filter banks to copy the dewhitening and 60comb filters. Then I turned them on.

Similarly, I copied IOO_WFS1_PIT filter bank to AWS_YARM/XARM_WFS1/2_PIT/YAW filter banks. I created a generalised script to handle all WFS on/off.hold/onfromhold operations here. I also generalized toggleWFSoffsets script to be used for measuring DC sensing matrix.

DC sensing matrix measurement

This measurement folllowed the method used by Koji in 40m/17354. The measurement is pushed here. Ntoe that when using this method, while the test finishd in ~1000 seconds, it takes dtt >20 min to retrieve the timeseries data from DQ channels. Thisis weird because cdsutils.getdata does not have this lag. If anyone knows why this is the case, it would be helpful in making this method faster.

• Locked YARM and misaligned ITMX and ETMX
• Centered the AS beam on WFS using DC value.
• Ran ASS on YARM to get to best aligned cavity state.
• Unlocked YARM and ran C1AWS_YARM_WFS_MASTER>!Actions>Correct WFS RF offsets to zero teh offsets.
• Locked YARM again and waited for >120 seconds.
• Ran python /opt/rtcds/caltech/c1/Git/40m/scripts/AWStoggleWFSoffsets.py AWS BOTH -a YARM -t 120
• Measurement start time: 04/02/2023 22:37:00 UTC
• The offset values required for step response test above were determined by trying out values and making sure that transmission does not go down by more than 15%.
• I had to leave by 3:30 pm, so I couldn't complete the analysis of measured data.I'll post data here soon.
17449   Sun Feb 5 10:25:49 2023 AnchalSummaryPowerShutdownMain laser tripping

Our main laser has tripped suspiciously twice since the power shutdown. The last time it happened on Thursday Feb 2 night (the day of power outage happened). Next morning Paco turned the laser back on, I'm not sure if he did anything else other than turning the diode current driver ON. Paco, please add anything else you did.

Chris reported that the laser tripped again last night on Feb 4th around 6 pm. I came today to see the same situation, laser diode turned OFF. After a discussion with a friend in the weekend, it turned out that sometimes when brief power outages happen, the TEC circuit for mainitaing laser tremperature turns OFF while the current driver keeps running. I'm not sure if that is the case for us but that can cause such tripping due to over heating. So today instead of simply turning on the current driver again, I power cycled the laser controller. Laser is back on and mode cleaner is locked with fewer counts though since PMC transmission dropped. I don't have time to realign PMC today and I think it might be the case that the transmission would increase once laser has reached a steady state. On Monday, we need to consult with people with more experience and understand why our laser is tripping. I hope it is not sick.

15851   Mon Mar 1 11:40:15 2021 Anchal, PacoSummaryIMCgetting familiar with IMC controls

[Paco, Anchal]

tl;dr: Done no harm, no lasting change.

Learn burtgooey

- Use /cvs/cds/caltech/target/c1psl/autoBurt.req as input to test snapshot "/users/anchal/BURTsnaps/controls_1210301_101310_0.snap" on rossa after not succeeding in donatella

- Browse /opt/rtcds/caltech/c1/burt/autoburt/snapshots/TODAY just to know where the snapshots are living. Will store our morning work specific snapshots in local user directories (e.g. /users/anchal/BURTsnaps)

Identifying video monitors

- Switched channels around on video controls; changed C1:VID-MON7 to 16, back to 30, then C1:VID-QUAD2_4 to 16, to 18, then 20, back to 16, to 14 (which identified as PMCT), to 1 (IMC). Anyways, looks like IMC is locked.

[Yehonathan, Paco, Anchal]

Unlocking MC

- From IOO/LockMC, MC_Servo, FSS --> closed PSL shutter, reopen it and see the lock recovers almost instantly. Try MCRFL shutter, no effect. Toggled PSL shutter one more time, lock recovered.

- From IOO/LockMC, MC_Servo, toggle OPTION (after IP2A), lose and recover lock in similar fashion. MCRFL gets most of the light.

- Looked at IFO_OVERVIEW just to get familiar with the various signals.

15982   Wed Mar 31 22:58:32 2021 Anchal, PacoUpdateSUSMC2 Coil Balancing Test

A cross-coupling test has been set to trigger at 05:00 am on April 1st, 2021. The script is waiting on tmux session 'cB' on pianosa. /scripts/SUS/OutMatCalc/MC2crossCoupleTest.py is being used here. The script will switch on oscillator in LOCKIN1 of MC2 at 13 Hz and 200 counts and would send it along the POS, PIT and YAW vectors on output matrix one by one, each for 2 minutes. It will take data from C1:IOO-MC_F_DQ, C1:IOO-MC_TRANS_PIT_ERR and C1:IOO-MC_TRANS_YAW_ERR and use it to measure 'sensing matrix' S. Sensing matrix S is defined as the cross-coupling between excited and sensed DOF and we ideally want it to be an identity matrix. The code will use the measured S to create a guess matrix A which on being multiplied by ideal coil output matrix would give us a rotated coil output matrix O. This guess O will be applied and the measurement will be repeated. On each iteration, next, A matrix is defined by:

$A_{k+1} = (1 + \beta) A_k - \beta S_k A_k$

This recursive algorithm converges A to the inverse of initial S. The above relation is derived by noticing that in steady state $A S = \mathrm{I} \Rightarrow A = A S A \Rightarrow A = A - \beta(A S A - A)$. I've taken this idea from a mathematics paper I found on some more complex stuff (c.f. https://doi.org/10.31219/osf.io/yrvck).

At each iteration, all three matrices A, O and S will be stored in a text file for analysis later.

The code has the error-catching capability and would restore the optic to the status quo if an error occurs or watchdogs trip due to earthquakes.

15984   Thu Apr 1 13:56:49 2021 Anchal, PacoUpdateSUSMC2 Coil Balancing Test Results

The coil balancing attempt failed. The off-diagonal values in the measured sensing matrices either remained the same or increased.

The attempt in the morning was too slow. By the time we reached, it had reached to iteration 7 only and still nowhere near optimum sensing matrix had reached. We still needed to see if the optimum would eventually reach if more iterations happened.

So we worked a bit on speeding up the data loading process and then ran the code again which now was running much faster. Still within 1 hr or so, we saw it had reached to iteration 7 with no sign of sensing matrix getting any better.

<Paco left for vaccination>

To determine if the method would work in principle, I decided to stop the current run and start with a 0.5 Hz bandwidth run (so about 7 averages with 8s duration data and welch method). This completed 20 iterations before Gautum came. But it was clear now that the method is not converging to a better solution. Need to find a bug in the implementation of the algorithm mentioned in last post or find a better algoritm.

Attachment 1 is the plot of how the sensing matrix's distance from the identity matrix increased over iterations in the last run.

Attachment 2 is the plot for different off-diagonal terms in the sensing matrix. It is clear that POS->PIT,YAW coupling is not being measured properly as it remains constant.

Attachment 3 Gautum told us that there is some naming error in nds and MC_TRANS_PIT/YAW can be read through C1:IOO-MC_TRANS_PIT_ERR and C1:IOO-MC_TRANS_YAW_ERR channels instead. To test if they indeed point to same values, we did a test of exciting YAW degree through LOCKIN1 and seeing if the peaks are visible in the channels. This was also done to give Radhika an opportunity to do something I could confidently mentor about. and to experience using diaggui.

Attachment 1: SDistanceFromIdentity.pdf
Attachment 2: SmatIterations.pdf
Attachment 3: TestingExcitationAlongYAW.pdf
15985   Thu Apr 1 18:01:06 2021 Anchal, PacoUpdateSUSMC2 Coil Balancing Test Results Success??

After fixing a few things we felt were wrong in our implementation of the algorithm, we ran the coil balancing for 12 iterations with just 11s per excitation and still taking CSD with 0.1 Hz bandwidth. This time we saw the distance of sensing matrix from identity going down.

Performance Analysis

• Attachment 1 shows the trend of distance of Sensing matrix from identity matrix over iterations.
• Attachment 2 shows the trend of off-diagonal terms in sensing matrix over iterations.
• Attachment 3 shows the ASD for the different sensed DOF when excited in different DOFs with the new output matrix. This is the better truth of what happened by the end. The true sensing matrix is proportional to the peak heights in this plot. Rows are different sensed DOFs (POS, PIT, YAW) and columns are excited DOFs (POS, PIT, YAW). The black dotted curves are ASD when no excitation was present.

Next step

• We want to run it for longer, more iterations and more duration to get better averaging. Hopefully, this will do a better job. We'll try running this new code tomorrow at 5:00am.
• We'll work on using uncertainties of measured data.
• Use awg to excite all DOF together at different frequencies and make the code faster.
Attachment 1: SDistanceFromIdentity.pdf
Attachment 2: SmatIterations.pdf
Attachment 3: MC2CoilCrossCoupling_opt.png
15995   Mon Apr 5 08:25:59 2021 Anchal, PacoUpdateGeneralRestore MC from early quakes

[Paco, Anchal]

Came in a little bit after 8 and found the MC unlocked and struggling to lock for the past 3 hours. Looking at the SUS overview, both MC1 and ITMX Watchdogs had tripped so we damped the suspensions and brought them back to a good state. The autolocker was still not able to catch lock, so we cleared the WFS filter history to remove large angular offsets in MC1 and after this the MC caught its lock again.

Looks like two EQs came in at around 4:45 AM (Pacific) suggested by a couple of spikes in the seismic rainbow, and this.

As mentioned in last post, we earlier made an error in making sure that all time series arrays go in with same sampling rate in CSD calculation. When we fixed that, our recursive method just blew out in all the efforts since then.

We suspect a major issue is how our measured sensing matrix (the cross-coupling matrix between different degrees of freedom on excitation) has significant imaginary parts in it. We discard the imaginary vaues and only use real parts for iterative method, but we think this is not the solution.

Here we present cross-spectral density of different channels representing the three sensed DOFs (normalized by ASD of no excitation data for each involved component) and the sensing matrix (TF estimate) calculated by normalizing the first cross spectral density plots column wise by the diagonal values. These are measured with existing ideal output matrix but with the new input matrix. This is to get an idea of how these elements look when we use them.

Note, that we used only 10 seconds of data in this run and used binwidth of 0.25Hz. When we used binwidth of 0.1 Hz, we found that the peaks were broad and highest at 13.1 Hz instead of 13 Hz which is the excitation frequency used in these measurements.

How should we proceed?

• We feel that we should figure out a way to use the imaginary value of the sensing matrix, either directly or as weights representing noise in that particular data point.
• Should we increase the excitation amplitude? We are currently using 500 counts of excitation on coil output.
• Are there any other iterative methods for finding the inverse of the matrix that we should be aware of? Our current method is rudimentary and converges linearly.
• Should we use the absolute value of the sensing matrix instead? In our experience, that is equivalent to simply taking ratios of the PSD of each channel and does not work as well as the TF estimate method.
Attachment 1: FirstMeasurementPlots.pdf
16007   Thu Apr 8 17:04:43 2021 Anchal, PacoUpdateSUSFirst Successful Coil Balancing

Today, we finally crossed the last hurdle and got a successful converging coil balancing run.

What was the issue with POS?

• Position of the MC2 mirror is being sensed using C1:IOO-MC_F_DQ channel which is proportional to the resonant frequency of the locked IMC.
• However, this sensor is always 180 degrees out of phase of our actuator, the coils.
• When the coils push the mirror forward, the length of the cavity actually decreases.
• We added an extra option of providing a sign to the sensors such that -1 will be multiplied to sensed values for sensors which measure in opposite direction to the actuation.
• This is important, because the feedback is applied to the coil output matrix assuming a particular direction of acctuation.
• When we gave negative sign for the position sensor, it all started making sense and the algorithm started converging.

First run parameters:

• We used binwidth of 0.25 Hz and duration of excitation as 41s. This would give welch and csd averaging of 19. We used median averaging to ignore outliers.
• This iteration was run after PIT and YAW were separetly uncoupled before. We'll post a clean start to end run results in near future.
• The iteration works in following manner:
• Define a constant coil matrix C = [[1, 1, 1], [1, 1, -1], [1, -1, 1], [1, -1, -1]] which is ideal coil output matrix.
• In each iteration, the output matrix Ok is defined as (note @ is the matmul operator):
Ok = C @ Ak
where Ak is a 3x3 matrix. A-1 is identity matrix.
• At the end of each iteration, a sensing matrix is calculated in dimensions sensedDOF x excitedDOF, Sk
• For next iteration, Ak+1 is calcualted by:
Ak+1 = Ak - b * (Sk - I)
where I is the identity matrix.
• At convergence, the sensing matrix would become same as identity and matrix A will stop updating.
• For this run, we kept the parameter b to be 0.05. This is similar to the KP parameter in PID loops. It should be between 0 and 1.
• Since b value was small enough to allow for convergence from the inital point, but later it slowed down the process a lot.
• Ideally, we should figure out a way to increase this paramter when the coil has been balanced somewhat, to increase the speed of the algorithm.
• Secondly, we have a code which excites all DOFs at different frequencies directly using excitation channels in coil output matrix using awg.py. But for some reason, the excitation channel for 4th row in the output matrix column only connects intermittantly. Because of this, we can't use this method reliably yet. We can investigate more into it if suggested.

Balancing characteristics:

• Attachment 1 shows how the distance of sensing matrix falls as iterations increase. We only ran for 50 iterations.
• Attachment 2 shows how different off-diagonal terms of sensing matrix decreased.
• Note that POS -> PIT, POS -> YAW and PIT-YAW have settled down to the noise floor.
• The noise floor can be improved by increasing the excitation amplitude and/or increasing the duration of measurement.
• Attachment 3 shows the evolution of sensing matrix as iterations move.

Final balanced output matrix:

Final balanced output coil matrix for MC2
POS PIT YAW COILS
1.02956 1.13053 1.19116 UL
1.01210 1.09188 -0.74832 UR
0.98737 -0.85502 0.70485 LR
0.96991 -0.89366 -1.23463 LR
Final Sensing Matrix
Exc POS Exc PIT Exc YAW
Sens POS 1 -2.96e-2 8.00e-3
Sens PIT 8.58e-4 1 -4.84e-3
Sens YAW 5.97e-4 -1.15e-3 1

Code features and next:

• Majority of the code is in two files: scripts/SUS/OutMatCalc/MC2crossCoupleTest.py and scripts/SUS/OutMatCalc/crossCoupleTest.py .
• The code runs from start to end without human involevement and restores the state of channels in any case (error, kyboard interrupt, end of code) using finally statement.
• Currently, each excitation is done one at a time through LockIn1. As mentioned above, this can be sped up 3 times if we get the awg.py to work reliably.
• The complete code is in python3 and currently is run through native python3 on allegra (a new debian10 workstation with latest cds-workstation installed).
• The code can be easily generalized for balancing any optic. Please let us know if we should work on making the generalized optic.
• We're also working on thinking about increasing b as iterations move forward and the error signal becomes smaller.
• We can also include the uncertainty in the Sensing matrix measurement to provide a weighted feedback. That way, we can probably increase b more.
Attachment 1: SDistanceFromIdentity.pdf
Attachment 2: SmatIterations.pdf
Attachment 3: SmatrixPlots.pdf
16009   Fri Apr 9 13:13:00 2021 Anchal, PacoUpdateSUSFaster coil balancing

We ran again this method but with the 'b' parameter as a matrix instead. This provides more gain on some off-diagonal terms than others. This gave us a better convergence with the code reaching to the tolerance level provided (0.01 distance of S matrix from identity) within 16 iterations (~17 mins).

Attachment 1 again shows how the off-diagonal terms go down and how the overall distance of sensing matrix from identity goes down. This is 'Cross coupling budget' of the coils as iterations move forward.

Jumping to near zero-crossing:

• Rana mentioned a ezlockin code which first makes 5 step changes in output matrix without using feedback and calculates the changes required to reach zero-crossing in the behavior of the off-diagonal terms during these steps.
• This is similar to what we did above by hand where we increased the value of b for slowly converging off-diagonal elements.
• We plan to implement this 'jump' to near zero-crossing method next. Aim is to get a coil balancing code that does the job in ~5 min.
• We have been throwing away imaginary part of sensing matrix so far. We wanted to get to some owrking solution before we try more complex stuff. We have to figure out global phases in each transfer function estimate to rotate the measured transfer function appropriately.
Attachment 1: SmatIterations.pdf
Attachment 2: MC2AllOutmat.txt
1.027604652272846142e+00 1.193175249772460367e+00 1.091939557371080394e+00
1.010054273887021292e+00 1.156057452309880551e+00 -8.392112351146234772e-01
9.895057930131009316e-01 -7.685799469766890768e-01 6.200896409311776880e-01
9.719554146272761930e-01 -8.056977444392685594e-01 -1.311061151554526294e+00

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:

https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20210411/psl/#gallery-4

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.

16042   Fri Apr 16 11:36:36 2021 Anchal, PacoUpdateSUSTested proposed filters for POS colum in MC2 output matrix

We tried two sets of filters on the output matrix POS column in MC2. Both versions failed. Following are some details.

How test was done:

• PSL shutter was closed and autolocker was switch off.
• Turned off damping on POS, PIT, and YAW using C1:SUS-MC2_SUSPOS_SW2, C1:SUS-MC2_SUSPIT_SW2, and C1:SUS-MC2_SUSYAW_SW2.
• Reference data was taken with no excitation to get relative increase at excitation.
• Channels C1:SUS-MC2_SUSPIT_IN1, C1:SUS-MC2_SUSPOS_IN1, and C1:SUS-MC2_SUSYAW_IN1.
• Frist we sent an excitation through LOCKIN1 at 0.11 Hz and 500 counts amplitude.
• LOCKIN column in MC2 output matrix was kept identical to POS column, so all ones.
• This formed our reference data set when no filters were used. Attachment 1.
• Note that the peak at 0.03 Hz is due to LOCKIN2 that was left switched on due to autolocker.
• Then the calculated filters were loaded using foton. Procedure:
• Right click on filter bank med. Got to Execute-> Foton.
• Go to File and uncheck 'Read Only'.
• Find the filter module name in Module drop down.
• Select an empty module section in Sections.
• Write a name for the filter. We used DCcoupF2A and DCcouF2A2 for the two version respectively.
• Paste the zpk foton format in Command.
• Check with Bode plot if these are correct filters. Then click on Save. It will take about 30s to become responsive again.
• GO back to filter bank medm screen and click on 'Load Coefficients'. This should start displaying your new filter module.
• To switch on the module, click on the button below its name.
• Once fitlers were loaded, we realized we can not use the LOCKIn to excite anymore as it comes as separate excitation.
• So we used awggui to excite C1:SUS-MC2_LSCEXC at 0.11 Hz and 500 counts.
• Then we retook the data and checked if the peaks are visible on PIT and YAW channels and how high they are.

Filer version 1

• This was calculated by starting from ideal output matrix elements as they are currently loaded. All 1's for POS and so on.
• The calculations were done in scripts/SUS/OutMatCalc/coilBalanceDC.py.
• This file uses a state space model of the suspension and calculated the cross-coupling. Then the cross coupling is inverted and applied to the current output matrix elements to get correction DC gains.
• These corrected DC gains are then used to create the filters as described in last post.
• Attachment 2 shows the filter transfer functions and Attachment 3 shows the test results. Failed :(.
• There was practivally no change in cross coupling that we can see.

Filter version 2:

• In this version we used the output matrix optimized at high frequencies earlier (16009).
• While testing this version, we also uploaded this optimised output amtrix at high frequency.
• In this test, we realized the LOCKIN2 was on and switched it off manually. All excitations were done through awggui.
• Attachment 4 shows the filter transfer functions and Attachment 5 shows the test results. Failed :(.
• There was again practivally no change in cross coupling that we can see.

Forgot to upload new MC2 input matrix:

• In hindsight, we should have uploaded our diagonalized suspension input matrix in MC2.
• Without it, there was cross-coupling the in the sensor data to begin with.
• But this can only be part of the reason why all our filters failed miserably.
• Because the output matrix was not diagonalized earlier but it was not so bad. Onyl a fresh test can tell if it was the culprit.
Attachment 1: 20210416_MC2DCcoilBalancingNoFilters.pdf
Attachment 2: uncFilters.pdf
Attachment 3: 20210416_MC2DCcoilBalancingWithFilters.pdf
Attachment 4: uncFilters_v2.pdf
Attachment 5: 20210416_MC2DCcoilBalancingWithFilters_v2.pdf
16049   Mon Apr 19 12:18:19 2021 Anchal, PacoUpdateSUSTested proposed filters for POS colum in MC2 output matrix

The filters were somewhat successful, how much we can see in attachment 1. The tip about difference between eigenmode basis and cartesian basis was the main thing that helped us take data properly. We still used OSEM data but rotated the output from POS, PIT, YAW to x, theta, phi (cartesian basis where x is also measured as angle projected by suspension length).

Eigenmode basis and Cartesian basis:

• It is important to understand the difference between these two and what channels/sensors read what.
• Eigenmode basis as the name suggests is the natural basis for the suspended pendulum.
• It signifies the motion along three independent and orthogonal modes of motion: POS (longitudinal pendulum oscillation), PIT, and YAW.
• The position of optic can be written in eigenmode basis as three numbers:
• POS: Angle made by the center of mass of optic with verticle line from suspension point.
• PIT: Angle made by the optic face with the suspension wires (this is important to note).
• YAW: Angle made by optic surface with the nominal plane of suspension wires. (the yaw angle basically).
• Cartesian basis is the lab reference frame.
• Here we define three variables that can also represent an optic positioned and orientation:
• x: Angle made by the center of mass of optic with verticle line from suspension point. (Same as POS)
• $\large \theta$: Angle made by the optic surface with absolute verticle (z-axis) in lab frame.
• $\large \phi$: Twist of the optic around the z-axis. Same as YAW angle above.
• We want to apply the feedback gains and filters in eigenmode basis because they are a set of known independent modes. (RXA: NOOO!!!!!! read me elog entry on this topic)
• Hence, the output from input matrix of suspensions comes out at POS, PIT and YAW in the eigenmode basis.
• However, the sensors of optic positional, and orientation such at MC_F, wave front sensors and optical levers measure it in lab frame and thus in cartesian basis.
• Essentially, the $\large \theta$ measured by these sensors is different from the PIT calculated using the OSEM sensor data and is related by:
• $\large \theta = PIT - POS$, where PIT and POS both are in radians as defined above.
• When we optimized the cross-coupling in output matrix at high frequencies using the MC_F and WFS data, we actually optimized it In cartesian basis.
• The three feedback filters from POS, PIT and YAW which carry data in the eigenmode basis need to be rotated into the cartesian basis in the output matrix before application to the coils.
• The so-called F2A and A2L filters are essentially doing this rotation.
• Above the resonant frequencies, the PIT and $\large \theta$ become identical. Hence we want our filters to go to unity

The two filter sets:

• The filters are named Eg2Ctv1 and Eg2Ctv2 on the POS column of MC2 output matrix.
• This is to signify that these filters convert the POS, PIT, and YAW basis data (eigenmode basis data) into the cartesian basis (x, theta, phi) in which the output matrix is already optimized at higher frequencies.
• v1 filter used an ideal output matrix during the calculation of filter as described in 16042 (script at scripts/SUS/OutMatCalc/coilBalanceDC.py).
• Attachment 2 shows these filter transfer functions.
• v2 filter use the output matrix optimized to reduce cross-coupling amount cartesian basis modes (MC_F, WFS_PIT and WFS_YAW) in 16009.
• Attachment 3 shows these filter transfer funcitons.
• Because of this, the v2 filter is different among right and left coils as well. We do see in Attachment 1 that this version of filter helps in reducing POS->YAW coupling too.

Test procedure:

• We uploaded both the diagonalized input matrix and the diagonalized output matrix as calculated earlier.
• We measured channels C1:SUS-MC2_SUSPOS_IN1_DQ, C1:SUS-MC2_SUSPIT_IN1_DQ, and C1:SUS-MC2_SUSYAW_IN1_DQ throughout this test.
• These channels give output in an eigenmode basis (POS, PIT, and YAW) and the rows of the input matrix have some arbitrary normalization.
• We normalize these channels to have same input matrix normalization as would be for ideal matrix (2 in each row).
• Then, assuming the UL_SENS, UR_SENS, LR_SENS, and LL_SENS channels that come at input of the input matrix are calibrated in units of um, we calculate the cartesian angles x, theta, phi. for this calculation, we used the distance between coils as 49.4 mm (got it from Koji) and length of suspension as 0.2489 m and offset of suspension points from COM, b = 0.9 mm.
• Now that we have true measures of angles in cartesian basis, we can use them to understand the effect on cross coupling from the filters we used.
• PSL shutter is closed and autolocker is disabled. During all data measurements, we switched of suspension damping loops. This would ensure that our low frequency excitation survives for measurement at the measurement channels.
• We first took reference data with no excitation and no filters for getting a baseline on each channel (dotted curves in Attachment 1).
• We then send excitation of 0.03 Hz with 500 counts amplitude at C1:SUS-MC2_LSC_EXC and switched on LSC output.
• One set of data is taken with no filters active (dashed curve in attachment 1).
• Then two sets of data are taken with the two filters. Each data set was of 500s in length.
• Welch function is used to take the PSD of data with bin widht of  0.01Hz and 9 averages.

Results:

• Filter v1 was the most successful in reducing $\large x \rightarrow \theta$ coupling by factor of 17.5.
• The reduction in $\large x \rightarrow \phi$ coupling was less. By a factor of 1.4.
• Filter v2 was worse but still did a reduction of $\large x \rightarrow \theta$ coupling by factor of 7.8.
• The reduction in $\large x \rightarrow \phi$ coupling was better. By a factor of 3.3.

Next, filters in PIT columns too

• We do have filters calculated for PIT as well.
• Now that we know how to test these properly, we can test them tomorrow fairly quickly.
• For the YAW column though, the filters would probably just undo the output matrix optimization as they are derived from ideal transfer function models and ideally there is no coupling between YAW and other DOFs. So maybe, we should skip putting these on.
Attachment 1: CrossCoupleTestForEgToCtFilters.pdf
Attachment 2: uncFilters.pdf
Attachment 3: uncFilters_v2.pdf
16054   Tue Apr 20 10:52:49 2021 Anchal, PacoUpdateSUSAC gain coil output balancing for IMC

[Paco, Anchal]

• We adopted the following procedure to balance the coil output gains using a high-frequency (> 10 Hz) excitation on "C1:SUS-MCX_ASCPIT_EXC", "C1:SUS-MCX_ASCYAW_EXC", and "C1:SUS-MCX_LSC_EXC", where X is one of {1, 2, 3} for the three IMC optics, and the cavity sensors (MC_F, and MC_TRANS);
1. We load the new input matrix found on March-23rd.
2. Using awggui, we launch a single 23.17 Hz sine with 500 - 1000 counts amplitude on the aforementioned channels.
• We are still unable to launch multiple excitations simultaneously through either API (python-awg or dtt-awggui)
3. Using our built-in hominid neural networks, we look at the "C1:IOO-MC_F", "C1:IOO-MC_TRANS_PIT_IN", and "C1:IOO-MC_TRANS_YAW_IN" exponentially averaging power spectra, on and about the excitation frequency, and identify the amount of cross-coupling going into angular or longitudinal motion depending on the excited degree of freedom.
4. We step the "C1:SUS-MCX_URCOIL_GAIN", "C1:SUS-MCX_ULCOIL_GAIN", "C1:SUS-MCX_LRCOIL_GAIN", "C1:SUS-MCX_LLCOIL_GAIN" coil output gains by hand in the presence of an excitation (e.g. "LSC") along a given degree of freedom (e.g. along "PIT") to try and minimize the coupling.
5. We iterate step (4) until we find an optimum gain set, and move on to another optic.

Results

• For MC2 the optimal gains changed from: [1.0, -1.0, 1.0, -1.0] → [1.05, -1.05, 0.995, -1.03] **
• Here we were able to first decouple PIT and YAW from a POS excitation almost entirely (see Attachment #1), but weren't as successful in decoupling YAW and POS from PIT, or PIT and POS from YAW excitations (Attachment #2).
• For MC1 the optimal gains changed from: [1.0, 1.0, 1.0, 1.0] → [0.282, 0.035, 0.302, 2.46] **
• Here we mostly succeeded in decoupling POS from YAW and PIT excitations (see Attachments #3 - 4).
• For MC3 the optimal gains changed from: [1.0, -1.0, 1.0, -1.0] → [0.126, -0.123, 0.298, -0.306] **
• Here the LSC_EXC didn't show up on MC_F (??), and the PIT/YAW excitations decouple by virtue of seemingly low gains, so maybe the optimum is an artifact of the lower coil gains...
• Plots are to follow up for this one.

** The notation here is [UL, UR, LR, LL]

Attachment 1: POS2PYuncoupled.pdf
Attachment 2: PIT2PYuncoupled.pdf
Attachment 3: MC1YAWexc.pdf
Attachment 4: MC1PITexc.pdf
16063   Wed Apr 21 11:38:27 2021 Anchal, PacoUpdateSUSMC2 Damping Gains Optimized

We did a step response test with MC2 Suspensoin Damping Gains and optimized them to get <5 oscillations in ringdown.

Procedure:

• We uploaded the diagonalized input matrix.
• We uploaded the coil balancing gains at high frequencies found in 16054.
• We applied Eg2CtQ1 filter module for DC gain balancing foun inf 16055.
• We set TRAMP to 0 in C1:SUS-MC2_SUSPOS_TRAMP, C1:SUS-MC2_SUSPIT_TRAMP, and C1:SUS-MC2_SUSYAW_TRAMP.
• We played with offsets to get a good step height. Finally we used:
• C1:SUS-MC2_SUSPOS_OFFSET: 3000
• C1:SUS-MC2_SUSPIT_OFFSET: 100
• C1:SUS-MC2_SUSYAW_OFFSET: 100
• We looked at channels C1:SUS-MC2_SUSPOS_INMON, C1:SUS-MC2_SUSPIT_INMON, and C1:SUS-MC2_SUSYAW_INMON on a striptool screen to see the step response of the switching on/off of the offsets.
• We tried to decrease/increase gain to get <5 oscillations during ringdown due to the step inputs.
• Restored everything back to old values at the end.

Results:

• Gain in POS was found to be already good. In PIT and YAW we changed the gains from 10 -> 30.
• Attachment 1 shows the striptool screen when offset was switched ON/Off in POS, PIT and YAW respectively after appling the optimized gains.
• Attachment 2 shows the same test with old gains for comparison.

In the afternoon, we'll complete doing the above steps for MC1 and MC3. Their coil balancing has not been done on DC so, it is bit non-ideal right now. We'll look into scripting this process as well.

Attachment 1: MC2_DampGainStepTestWithNewGains.png
Attachment 2: MC2_DampGainStepTestWithOldGains.png
16066   Wed Apr 21 15:50:01 2021 Anchal, PacoUpdateSUSMC2 Suspension Optimization summary
MC2 Coil Balancing DC and AC Gains
POS PIT YAW COIL_GAIN (AC balancing)

UL

1.038 1 1 1.05
UR 1.009 1 -1 -1.05
LL 0.913 -1 1 -1.030
LR 0.915 -1 -1 0.995

MC2 Diagonalized input matrix
UL UR LR LL SIDE
POS 0.2464 0.2591 0.2676 0.2548 -0.1312
PIT 1.7342 0.7594 -2.494 -1.5192 -0.0905
YAW 1.2672 -2.0309 -0.9625 2.3356 -0.2926
SIDE 0.1243 -0.1512 -0.1691 0.1064 0.9962

MC2 Suspension Gains
Old gain New Gain
SUSPOS 150 150
SUSPIT 10 30
SUSYAW 10 30

16072   Thu Apr 22 12:17:23 2021 Anchal, PacoUpdateSUSMC1 and MC3 Suspension Optimization Summary
MC1 Coil Balancing DC and AC Gains
POS (DC coil Gain) PIT (DC coil Gain) YAW (DC coil Gain) Coil Output Gains (AC)
UL 0.6613 1 1 0.5885
UR 0.7557 1 -1 0.1636
LL 1.3354 -1 1 1.8348
LR 1.0992 -1 -1 0.5101

Note: The AC gains were measured by keeping output matrix to ideal values of 1s. When optimizing DC gains, the AC gains were uploaded in coil ouput gains.

MC1 Diagonalized input matrix
UL UR LR LL SIDE
POS 0.1700 0.1125 0.0725 0.1300 0.4416
PIT 0.1229 0.1671 -0.1021 -0.1463 0.1567
YAW 0.2438 -0.1671 -0.2543 0.1566 -0.0216
SIDE 0.0023 0.0010 0.0002 0.0015 0.0360

MC1 Suspension Damping Gains
Old gains New Gains
SUSPOS 120 270
SUSPIT 60 180
SUSYAW 60 180

MC3 Coil Balancing DC and AC Gains
POS (DC coil Gain) PIT (DC coil Gain) YAW (DC coil Gain) Coil Output Gains (AC)
UL 1.1034 1 1 0.8554
UR 1.1034 1 -1 -0.9994
LL 0.8845 -1 1 -0.9809
LR 0.8845 -1 -1 1.1434

Note: The AC gains were measured by keeping output matrix to ideal values of 1s. When optimizing DC gains, the AC gains were uploaded in coil ouput gains.

MC3 Input matrix (Unchanged from previous values)
UL UR LR LL SIDE
POS 0.28799 0.28374 0.21201 0.21626 -0.40599
PIT 2.65780 0.04096 -3.2910 -0.67420 -0.72122
YAW 0.60461 -2.7138 0.01363 3.33200 0.66647
SIDE 0.16601 0.19725 0.10520 0.07397 1.00000

MC3 Suspension Damping Gains
Old gains New Gains
SUSPOS 200 500
SUSPIT 12 35
SUSYAW 8 12
16085   Mon Apr 26 18:52:52 2021 Anchal, PacoHowToComputer Scripts / Programsawg free slot

Today we had some trouble launching an excitation on C1:IOO-MC_LSC_EXC from awggui. The error read:

awgSetChannel: failed getIndexAWG C1:SUS-MC2_LSC_EXC ret=-3

What solved this was the following :

1. launch the dtt command line interface
2. Anchal remembers a slot number 37008
3. We issue >> awg free 37008
4. Slot freed, launch a new instance of awggui
16086   Mon Apr 26 18:55:39 2021 Anchal, PacoUpdateSUSMC2 F2A Filters Tested

Today we tested the F2A filters created from the DC gain values listed in 16066.

Filters:

• For a DC gain $G_{DC}$ required for balancing the coil at DC and $f_0$ being the resonance frequency of the mode (POS in this case), we calculate the filter using:
$\frac{1 + i \frac{f_z}{f Q} - \frac{f_z^2}{f^2}}{1 + \frac{f_0}{f} - \frac{f_0^2}{f^2}}$where $f_z = f_0 \sqrt{G_{DC}}$.
• Attachment 1 shows the motivation for choosing the resonant frequency in the formula above. It makes gain at DC as $G_{DC}$ while keeping AC gain as 1.
• Attachment 2 shows the transfer functions of the filters uploaded.
• Filters are named Eg2CtQ3, Eg2CtQ7 and Eg2CtQ10 for Q=3,7,10 filters respectively. (Named for Eigenmode Basis to Cartesian Basis conversion filters, aka F2A filters).

Testing procedure:

• We uploaded the new input matrix listed in 16066.
• We then uploaded the coil output gains (AC gains) that are also listed in 16066.
• Then we reduced the C1:IOO-WFS_GAIN to 0.05 (by a factor of 20).
• Rana asked us to test the WFS sensors' impulse response to observe a minimum 10s decay to ensure that the UGF of WFS control loops is at or below 0.1 Hz.
• We were unable to have any effect on this decay actually. We tried setting offsets without tramps in multiple places but whenever we were able to excite this loop, it will always damp down in about 5-6s regardless of the value of C1:IOO-WFS_GAIN.
• So we moved on.
• Then, with MC locked we took reference data with no excitation or filters uploaded. (dotted curves)
• We took cross spectral density from C1:IOO-MC_F to C1:IOO-MC_TRANS_PIT_IN1, C1:IOO-MC_TRANS_YAW_IN1, C1:IOO-WFS1_PIT_IN1, C1:IOO-WFS1_PIT_IN1, C1:IOO-WFS2_PIT_IN1, and C1:IOO-WFS2_PIT_IN1.
• We were also looking at the power spectral density of these channels.
• Then using awggui (after the fix we did as in 16085), we added noise in C1:SUS-MC2_LSC_EXC as uniform noise between 0.05 Hz to 3.5 Hz with amplitude of 100 and gain of 100.
• We took a set of data without switching on the filters to have a comparison later. (Dash-dort curves)
• We then took data after switching on the filters. (Solid curves)

Next:

• Tomorrow we'll repeat this for MC1 and MC3 if we get a favourable grade in our work here.
• Even if not, we'll jsut conclude the suspension optimization work tomorrow morning and get into main interferometer.
Attachment 1: f2a.pdf
Attachment 2: IMC_F2A_Params_MC2.pdf
Attachment 3: MC2_F2A_FilterChar_POS2Ang.pdf
16087   Tue Apr 27 10:05:28 2021 Anchal, PacoUpdateSUSMC1 and MC3 F2A Filters Tested

We extended the f2a filter implementation and diagnostics as summarized in 16086 to MC1 and MC3.

MC1

Attachment 1 shows the filters with Q=3, 7, 10. We diagnosed using Q=3.

Attachment 2 shows the test summary, exciting with broadband noise on the LSC_EXC and measuring the CSD to estimate the transfer functions.

MC3

Attachment 3 shows the filters with Q=3, 7, 10. We diagnosed using Q=3.

Attachment 4 shows the test summary, exciting with broadband noise on the LSC_EXC and measuring the CSD to estimate the transfer functions.

Our main observation (and difference) with respect to MC2 is the filters have relative success for the PIT cross-coupling and not so much for YAW. We already observed this when we tuned the DC output gains to compute the filters.

Attachment 1: IMC_F2A_Params_MC1.pdf
Attachment 2: MC1_POStoAng_CrossCoupling.pdf
Attachment 3: IMC_F2A_Params_MC3.pdf
Attachment 4: MC3_POStoAng_CrossCoupling.pdf
16089   Wed Apr 28 10:56:10 2021 Anchal, PacoUpdateSUSIMC Filters diagnosed

Good morning!

We ran the f2a filter test for MC1, MC2, and MC3.

Filters

The new filters differ from previous versions by a adding non-unity Q factor for the pole pairs as well.

$\frac{f^2 - i \frac{f_z}{Q}f + f_z^2}{f^2 - i \frac{f_0}{Q}f + f_0^2}$
This in terms of zpk is: [ [zr + i zi, zr - i zi], [pr + i pi, pr - i pi], 1] where
$z_r = -\frac{f_z}{2Q}, \quad z_i = f_z \sqrt{1 - \frac{1}{4Q^2}}, \quad p_r = -\frac{f_0}{2Q}, \quad p_i = f_0 \sqrt{1 - \frac{1}{4Q^2}}$$, \quad f_z = f_0 \sqrt{G_{DC}}$

• Attachment #1 shows the filters for MC1 evaluated for Q=3, 7,and 10.
• Attachment #2 shows the filters for MC2 evaluated for Q=3, 7, and 10.
• Attachment #3 shows the filters for MC3 evaluated for Q=3, 7, and 10.
• Attachment #4 shows the bode plots generated by foton after uploading for Q=3 case.

We uploaded all these filters using foton, into the three last FM slots on the POS output gain coil.

Tests

We ran tests on all suspended optics using the following (nominal) procedure:

2. Lower the C1:IOO-WFS_GAIN to 0.05.
3. Upload AC coil balancing gains.
4. Take ASD for the following channels:
• C1:IOO-MC_TRANS_PIT_IN1
• C1:IOO-MC_TRANS_YAW_IN1
• C1:IOO-MC_WFS1_PIT_IN1
• C1:IOO-MC_WFS1_YAW_IN1
• C1:IOO-MC_WFS2_PIT_IN1
• C1:IOO-MC_WFS2_YAW_IN1
5. For the following combinations:
• No excitation** + no filter
• No excitation + filter
• Excitation + no filter
• Excitation + filter

** Excitation = 0.05 - 3.5 Hz uniform noise, 100 amplitude, 100 gain

Plots

• Attachment 5-7 give the test results for MC1, MC2 and MC3.
• In each pdf, the three pages show ASD of TRANS QPD, WFS1 and WFS2 channels' PIT and YAW, respectively.
• Red/blue correspond to data taken while F2A filters were on. Pink/Cyan correspond to data taken with filters off.
• Solid curves were taken with excitation ON and dashed curves were taken with excitation off.
• We see good suppression of POS-> PIT coupling in MC2 and MC3. POS->YAw is minimally affected in all cases.
• MC1 is clearly not doing good with the filters and probably needs readjustement. Something to do later in the future.
Attachment 1: IMC_F2A_Params_MC1.pdf
Attachment 2: IMC_F2A_Params_MC2.pdf
Attachment 3: IMC_F2A_Params_MC3.pdf
Attachment 4: IMC_F2A_Foton.pdf
Attachment 5: MC1_POS2ANG_Filter_Test.pdf
Attachment 6: MC2_POS2ANG_Filter_Test.pdf
Attachment 7: MC3_POS2ANG_Filter_Test.pdf
16108   Mon May 3 09:14:01 2021 Anchal, PacoUpdateLSCIMC WFS noise contribution in arm cavity length noise

Lock ARMs

• Try IFO Configure ! Restore Y Arm (POY) and saw XARM lock, not YARM. Looks like YARM biases on ITMY and ETMY are not optimal, so we slide C1:SUS-ETMY_OFF from 3.0 --> -14.0 and watch Y catch its lock.
• Run ASS scripts for both arms and get TRY/TRX ~ 0.95
• We ran X, then Y and noted that TRX dropped to ~0.8 so we ran it again and it was well after that. From now on, we will do Y, then X.

WFS1 noise injection

• Turn WFS limits off by running switchOffWFSlims.sh
• Inject broadband noise (80-90 Hz band) of varying amplitudes from 100 - 100000 counts on C1:IOO-WFS1_PIT_EXC
• After this we try to track its propagation through various channels, starting with
• C1:LSC-XARM_IN1_DQ / C1:LSC-YARM_IN1_DQ
• C1:SUS-ETMX_LSC_OUT_DQ / C1:SUS-ETMY_LSC_OUT_DQ
• C1:IOO-MC_F_DQ
• C1:SUS-MC1_**COIL_OUT / C1:SUS-MC2_**COIL_OUT / C1:SUS-MC3_**COIL_OUT
• C1:IOO-WFS1_PIT_ERR / C1:IOO-WFS1_YAW_ERR
• C1:IOO-WFS1_PIT_IN2

** denotes [UL, UR, LL, LR]; the output coils.

• Attachment 1 shows the power spectra with IMC unlocked
• Attachment 2 shows the power spectra with the ARMs (and IMC) locked
Attachment 1: WFS1_PIT_Noise_Inj_Test_IMC_unlocked.pdf
Attachment 2: WFS1_PIT_Noise_Inj_Test_ARM_locked.pdf
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
Attachment 2: IOO-MC1_PIT_NoiseInjTest2.pdf
Attachment 3: IOO-MC1_PIT_NoiseInjTest_AWGGUI_Config.png
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.

Conclusions:

• 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
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
$\dpi{150} \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.

Conclusions:

• 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
Attachment 2: BeatY_ITMY_CalibrationAt43Hz.pdf
Attachment 3: BeatY_ITMY_CalibrationAt77Hz.pdf
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
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.

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

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

Inference:

• 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
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.

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

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.

Inference:

• 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
16163   Wed May 26 11:45:57 2021 Anchal, PacoConfigurationIMCMC2 analog camera

[Anchal, Paco]

We went near the MC2 area and opened the lid to inspect the GigE and analog video monitors for MC2. Looked like whatever image is coming through the viewport is split into the GigE (for beam tracking) and the analog monitor. We hooked the monitor found on the floor nearby and tweaked the analog video camera around to get a feel for how the "ghost" image of the transmission moves around. It looks like in order to try and remove this "extra spots" we would need to tweak the beam tracking BS. We will consult the beam tracking authorities and return to this.

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.

Conclusions:

• 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
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.

Inferences:

• 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
Attachment 2: seismicXtoMC_F_TFest.pdf
Attachment 3: seismicXtoMC_TRANS_PIT_TFest.pdf
Attachment 4: 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

 Quote: 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.

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
16194   Wed Jun 9 11:46:01 2021 Anchal, PacoSummaryAUXXend Green Laser PDH OLTF measurement

We measured the Xend green laser PDH Open loop transfer function by following method:

• We first measured the feedback transfer function 'K' directly.
• See attachment 2 for this measurement. We measured Out2/exc here.
• Then, we closed the loop as shown in attachment 1with SR560 as a summing juntion at error point.
• We injected excitation through B channel in SR560 and measured transfer function Out1/Out2.
• This measurement should give us $G_{OL} / K$ by loop alegbra.
• Then we multiplied the two transfer function measurements to get open loop transfer function.

Result:

• Our measurement gives the same UGF of 10kHz and phase margin of 53.5 degrees as reported in 13238.
• The shape of measurement also follows 1/f above 10 Hz atleast.
• Our measurement might not be correct below 10 Hz but we did not see any saturation or loss of lock in 1Hz to 10 Hz measurement.
• This OLTF is different from the modelled OLTF here even though the UGF matches.
• The feedback gain is supposed to roll-off faster than 1/f in 30Hz to 1kHz region but it does not seem to in our measurement.
• This suggests that the actual uPDH box is shaping the loop different from what schematic suggests. This might mean that the gain is much lower in the low frequency region than we would like it to be.
• We will investigate the reason of difference between model and measurement unless someone has a better explaination for the descripancy.
Attachment 1: image-6f2923a3-01ce-4d04-bc53-d8db0238e195.jpg
Attachment 3: X_Green_ARM_PDH_OLTF.pdf
16196   Wed Jun 9 18:29:13 2021 Anchal, PacoSummaryALSCheck for saturation in ITMX SOS Driver

We did a quick check to make sure there is no saturation in the C1:SUS-ITMX_LSC_EXC analog path. For this, we looked at the SOS driver output monitors from the 1X4 chassis near MC2 on a scope. We found that even with 600 x 10 = 6000 counts of our 619 Hz excitation these outputs in particular are not saturating (highest mon signal was UL coil with 5.2 Vpp). In comparison, the calibration trials we have done before had 600 counts of amplitude, so we can safely increase our oscillator strength by that much

Things that remain to be investigated -->

• What is the actual saturation level?
• Two-tone intermodulation?
16202   Tue Jun 15 15:26:43 2021 Anchal, PacoSummaryAUXXend Green Laser PDH OLTF measurement loop algebra, excitation at control point

Attachment 1 shows the case when excitation is sent at control point i.e. the PZT output. As before, free running laser noise $\eta$ in units of Hz/rtHz is added after the actuator and I've also shown shot noise being added just before the detector.

Again, we have a access to three output points for measurement. $\alpha$ right at the output of mixer (the PDH error signal), $\beta$ the feedback signal to be applied by uPDH box (PZT Mon) and $\gamma$ the output of the summing box SR560.

Doing loop algebra as before, we get:

$\large \alpha = \frac{\eta}{K(s) A(s)} \frac{G_{OL}(s)}{1 - G_{OL}(s)} + \frac{\chi}{C(s) K(s) A(s)} \frac{G_{OL}(s)}{1 - G_{OL}(s)} - \frac{\nu_e}{K(s) } \frac{G_{OL}(s)}{1 - G_{OL}(s)}$

$\large \beta = \frac{\eta}{A(s)} \frac{G_{OL}(s)}{1 - G_{OL}(s)} + \frac{\chi}{C(s) A(s)} \frac{G_{OL}(s)}{1 - G_{OL}(s)} - \nu_e \frac{G_{OL}(s)}{1 - G_{OL}(s)}$

$\large \gamma= \frac{\eta}{A(s)} \frac{G_{OL}(s)}{1 - G_{OL}(s)} + \frac{\chi}{C(s) A(s)} \frac{G_{OL}(s)}{1 - G_{OL}(s)} - \nu_e \frac{1}{1 - G_{OL}(s)}$

So measurement of $\large G_{OL}(s)$ can be done by

$\large G_{OL}(s) \approx \frac{\beta}{\gamma}$

• For frequencies, where $\large G_{OL}(s)$ is large enough, to have an SNR of 100, we need that ratio of $\large \nu_e$ to integrated noise is 100.
• Assuming you are averaging for 'm' number of cycles in your swept sine measurement, time of integration for the noise signal would be $\large \frac{m}{f}$where f is the frequency point of the seeping sine wave.
• This means, the amplitude of integrated laser frequency noise at either $\large \beta$ or $\large \gamma$ would be $\large \sqrt{\left(\frac{\eta(f)}{A(f)}\right)^2\frac{f}{m}} = \frac{\eta(f) \sqrt{f}}{A(f)\sqrt{m}}$
• Therefore, signal to laser free running noise ratio at f would be $\large S = \frac{\nu_eA(f)\sqrt{m}}{\eta(f) \sqrt{f}}$.
• This means to keep a constant SNR of S, we need to shape the excitation amplitude as $\large \nu_e \sim S \frac{\eta(f) \sqrt{f}}{A(f)\sqrt{m}}$
• Putting in numbers for X end Green PDH loop, laser free-running frequency noise ASD is 1e4/f Hz/rtHz, laser PZT actuation is 1MHz/V, then for 10 integration cycles and SNR of 100, we get: $\large \nu_e \sim 100 \times \frac{10^4 \sqrt{f}}{f \times10^6 \sqrt{10}} = \frac{30\, mV}{\sqrt{f}}$
• Assuming you are averaging for a constant time $\large \tau$ in swept sine measurement, then the amplitude of integrated laser free noise would be $\large \sqrt{\left(\frac{\eta(f)}{A(f)}\right)^2 \frac{1}{\tau}} = \frac{\eta(f) }{A(f)\sqrt{\tau}}$
• In this case, signal to laser free-running noise ratio at f would be $\large S = \frac{\nu_eA(f)\sqrt{\tau}}{\eta(f)}$
• This means to keep a constant SNR of S, we need to shape the excitation amplitude as $\large \nu_e \sim S\frac{\eta(f)}{A(f)\sqrt{\tau}}$
• Again putting in numbers as above and integration time of 1s, we need an excitation amplitude shape $\large \nu_e \sim 100 \times \frac{10^4 }{f \times10^6 \sqrt{1}} = \frac{1\, V}{f}$

This means at 100 Hz, with 10 integration cycles, we should have needed only 3 mV of excitation signal to get an SNR of 100. However, we have been unable to get good measurements with even 25 mV of excitation. We tried increasing the cycles, that did not work either.

This post is to summarize this analysis. We need more tests to get any conclusions.

Attachment 1: AuxPDHloop.pdf
16204   Wed Jun 16 13:20:19 2021 Anchal, PacoSummaryCamerasMon 7 in Control Room Replaced

We replaced the Mon 7 with an LCD monitor from back bench. It is fed the analog signal from BNC converted into VGS with a converter box that Paco bought. We can replace this monitor with another monitor if it is required on the back bench. For now, we definitely need a monitor to show IMC camera's up there.

Attachment 1: IMG_20210616_083810.jpg
16209   Thu Jun 17 11:45:42 2021 Anchal, PacoUpdateSUSMC1 Gave trouble again

TL;DR

MC1 LL Sensor showed signs of fluctuating large offsets. We tried to find the issue in the box but couldn't find any. On power cycling, the sensor got back to normal. But in putting back the box, we bumped something and c1susaux slow channels froze. We tried to reboot it, but it didn't work and the channels do not exist anymore.

Today morning we came to find that IMC struggled to lock all night (See attachment 1). We kind of had an indication yesterday evening that MC1 LL Sensor PD had a higher variance than usual and Paco had to reset WFS offsets because they had integrated the noise from this sensor. Something similar happened last night, that a false offset and its fluctuation overwhelmed WFS and MC1 got misaligned making it impossible for IMC to get lock.

In the morning, Paco again reset the WFS offsets but not we were sure that the PD variance from MC1 LL osem was very high. See attachment 2 to see how only 1 OSEM is showing higher noise in comparison to the other 4 OSEMs. This behavior is similar to what we saw earlier in 16138 but for UL sensor. Koji and I fixed it in 16139 and we tested all other channels too.

So, Paco and I, went ahead and took out the MC1 satellite amplifier box S2100029 D1002812, opened the top, and checked all the PD channel testpoints with no input current. We didn't find anything odd. Next we checked the LED dirver circuit testpoints with LED OUT and GND shorted. We got 4.997V on all LED MON testpoints which indicate normal functioning.

We just hooked back everything on the MC1 satellit box and checked the sensor channels again on medm screens. To our surprise, it started functioning normally. So maybe, just a power cycling was required but we still don't know what caused this issue.

BUT when I (Anchal) was plugging back the power cables and D25 connectors on the back side in 1X4 after moving the box back into the rack, we found that the slow channels stopped updating. They just froze!

We got worried for some time as the negative power supply indicator LEDs on the acromag chassis (which is just below the MC1 satellite box) were not ON. We checked the power cables and had to open the side panel of the 1X4 rack to check how the power cables are connected. We found that there is no third wire in the power cables and the acromag chassis only takes in single rail supply. We confirmed this by looking at another acromag chassis on Xend. We pasted a note on the acromag chassis for future reference that it uses only positive rails and negative LED monitors are not usually ON.

Back to solving the frozen acromag issue, we conjectured that maybe the ethernet connection is broken. The DB25 cables for the satellite box are bit short and pull around other cables with it when connected. We checked all the ethernet cabling, it looked fine. On c1susaux computer, we saw that the monitor LED for ethernet port 2 which is connected to acromag chassis is solid ON while the other one (which is probably connection to the switch) is blinking.

We tried doing telnet to the computer, it didn't work. The host refused connection from pianosa workstation. We tried pinging the c1susaux computer, and that worked. So we concluded that most probably, the epics modbus server hosting the slow channels on c1susaux is unable to communicate with acromag chassis and hence the solid LED light on that ethernet port instead of a blinking one. We checked computer restart procedure page for SLOW computers on wiki and found that it said if telnet is not working, we can hard reboot the computer.

We hard reboot the computer by long pressing the power button and then presssing it back on. We did this process 3 times with the same result. The ethernet port 2 LED (Acromag chassis) would blink but the ethernet port 1 LED (connected to switch) would not turn ON. We now can not even ping the machine now, let alone telnet into it. All SUS slow monitor channels are not present now ofcourse. We also tried once pressing the reset button (which the manual said would reboot the machine), but we got the same outcome.

Now, we decided to stop poking around until someone with more experience can help us on this.

Bottomline: We don't know what caused the LL sensor issue and hence it has not been fixed. It can happen again. We lost all C1SUSAUX slow channels which are the OSEM and COIL slow monitor channels for PRM, BS, ITMX, ITMY, MC1, MC2 and MC3.

Attachment 1: SummaryScreenShot.png
16210   Thu Jun 17 16:37:23 2021 Anchal, PacoUpdateSUSc1susaux computer rebooted

Jon suggested to reboot the acromag chassis, then the computer, and we did this without success. Then, Koji suggested we try running ifup eth0, so we ran sudo /sbin/ifup eth0 and it worked to put c1susaux back in the martian network, but the modbus service was still down. We switched off the chassis and rebooted the computer and we had to do sudo /sbin/ifup eth0 again (why do we need to do this manually everytime?). Switched on the chassis but still no channels. sudo systemctl status modbusioc.service' gave us inactive (dead) status. So  we ran sudo systemctl restart modbusioc.service'.

The status became:

● modbusIOC.service - ModbusIOC Service via procServ
start condition failed at Thu 2021-06-17 16:10:42 PDT; 12min ago
ConditionPathExists=/opt/rtcds/caltech/c1/burt/autoburt/latest/c1susaux.snap was not met

After another iteration we finally got a modbusIOC.service OK status, and we then repeated Jon's reboot procedure. This time, the acromags were on but reading 0.0, so we just needed to run sudo /sbin/ifup eth1`and finally some sweet slow channels were read. As a final step we burt restored to 05:19 AM today c1susaux.snap file and managed to relock the IMC >> will keep an eye on it.... Finally, in the process of damping all the suspended optics, we noticed some OSEM channels on BS and PRM are reading 0.0 (they are red as we browse them)... We succeeded in locking both arms, but this remains an unknown for us.

16213   Fri Jun 18 10:07:23 2021 Anchal, PacoSummaryAUXXend Green Laser PDH OLTF with coherence

We did the measurement of OLTF for Xend green laser PDH loop with excitation added at control point using a SR560 as shown in attachment 1 of 16202. We also measured coherence in our measurement, see attachment 1.

Measurement details:

• We took the $\beta/\gamma$ measurement as per 16202.
• We did measurement in two pieces. First in High frequency region, from 1 kHz to 100 kHz.
• In this setup, the excitation amplitude was kept constant to 5 mV.
• In this region, the OLTF is small enough that signal to noise ratio is maintained in $\gamma$ (SR560 sum output, measured on CH1). The coherence can be seen to be constant 1 throughout for CH1 in this region.
• But for $\beta$ (PZT Mon, measured on CH2), the low OLTF actually starts damping both signal and noise and to elevate it above SR785 noise floor, we had a high pass (z:0Hz, p:100kHz, k:1000) SR560 amplifying $\beta$ before measurement (see attachment 2). This amplification has been corrected in Attachment 1. This allowed us to improve the coherence on CH2 to above 0.5 mostly.
• Second region is from 3 Hz to 1 kHz.
• In this setup, the excitation was shaped with a low pass (p: 1Hz, k:5) SR560 filter with SR785 source amplitude as 1V.
• We took 40 averaging cycles in this measurement to improve the coherence further.
• In this freqeuency region, $\beta$ is mostly coherent as we shaped the excitation as $1/f$ and due to constant cycle number averaging, the integrated noise goes as $1/\sqrt{f}$(see 16202 for math).
• We still lost coherence in $\gamma$ (CH1) for frequencyes below 100 Hz. the reason is that the excitation is suppressed by OLTF while the noise is not for this channel. So the $1/f$ shaping of excitation only helps fight against the suppression of OLTF somewhat and not against the noise.
$\gamma = \left( \frac{\eta}{A(s)} - \frac{\nu_e}{G_{OL}(s)} + \frac{\chi}{A(s) C(s)} \right)\frac{G_{OL}(s)}{1-G_{OL}(s)}$
• We need $1/f^2$ shaping for this purpose but we were loosing lock with that shaping so we shifted back to $1/f$ shaping and captured whatever we could.
• It is clear that the noise takes over below 100 Hz and coherence in CH1 is lost there.

Inferences:

• Yes, the OLTF does not look how it should look but:
• The green region in attachment 1 shows the data points where coherence on both CH1 and CH2 was higher than 0.75.  So the saturation measured below 1 kHz, particularly in 100 Hz to 500 Hz (where coherence on both channels is almost 1) is real.
• This brings the question, what is saturating. As has been suggested before, our excitation signal is probably saturating some internal stage in the uPDH box. We need to investigate this next.
• It is however very non-intuitive to why this saturation is so non-uniform (zig-zaggy) in both magnitude and phase.
• In past experiences, whenever I saw somehting saturating, it would cause a flat top response in transfer function.
• Another interesting thing to note is the reduced UGF in this measurement.
• UGF is about 40-45 kHz. This we believe is due to reduced mode matching of the green light to the XARM when temperature of the end increases too much. We took the measurement at 6 pm and Koji posted the Xend's temperature to be 30 C at 7 pm in 16206. It certainly becomes harder to lock at hot temperatures, probably due to reduced phase margin and loop gain.
Attachment 1: XEND_PDH_OLTF_with_Coherence.pdf
Attachment 2: Beta_Amp.pdf

We checked back in time to see how the BS and PRM OSEM slow channels are zero. It was clear that they became zero when we worked on this issue on June 17th, Thursday. So we simply went back and power cycled the c1susaux acromag chassis. After that, we had to log in to c1susaux computer and run

sudo /sbin/ifdown eth1
sudo /sbin/ifup eth1

This restarted the ethernet port acromag chassis is connected to. This solved this issue and we were able to see all the slow channels in BS and PRM.

But then, we noticed that the OPLEV of ITMX is unable to read the position of the beam on the QPD at all. No light was reaching the QPD. We went in, opened the ITMX table cover and confirmed that the return OPLEV beam is way off and is not even hitting one of the steering mirrors that brings it to the QPD. We switched off the OPLEV contribution to the damping.

We did burt restore to 16th June morning using
burtwb -f /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2021/Jun/16/06:19/c1susaux.snap -l /tmp/controls_1210622_095432_0.write.log -o /tmp/controls_1210622_095432_0.nowrite.snap -v

This did not solve the issue.

Then we noticed that the OSEM signals from ITMX were saturated in opposite directions for Left and Right OSEMs. The Left OSEM fast channels are saturated to 1.918 um for UL and 1.399 um for LL, while both right OSEM channels are bottomed to 0 um. On the other hand, the acromag slow PD monitors are showing 0 on the right channels but 1097 cts on UL PDMon and 802 cts in LL PD Mon. We actually went in and checked the DC voltages from the PD input monitor LEMO ports on the ITMX dewhitening board D000210-A1 and measured non-zero voltages across all the channels. Following is a summary:

C1-SUS-ITMX_XXSEN_OUT
C1-SUS-ITMX_xxPDMon
(Slow Acromag Monitors) (cts)
Multimeter measurements at input to Dewhitening Boards
(V)
UL 1.918 1097 0.901
LL 1.399 802 0.998
UR 0 0 0.856
LR 0 0 0.792
SD 0.035 20 0.883

We even took out the 4-pin LEMO outputs from the dewhitening boards that go to the anti-aliasing chassis and checked the voltages. They are same as the input voltages as expected. So the dewhitening board is doing its job fine and the OSEMs are doing their jobs fine.

It is weird that both the ADC and the acromags are reading these values wrong. We believe this is causing a big yaw offset in the ITMX control signal causing the ITMX to turn enough make OPLEV go out of range. We checked the CDS FE status (attachment 1). Other than c1rfm showing a yellow bar (bit 2 = GE FANUC RFM card 0) in RT Net Status, nothing else seems wrong in c1sus computer. c1sus FE model is running fine. c1x02 (the lower level model) does show a red bar in TIM which suggests some timing issue. This is present in c1x04 too.

Bottomline:

Currently, the ITMX coil outputs are disabled as we can't trust the OSEM channels. We're investigating more why any of this is happening. Any input is welcome.

Attachment 1: CDS_FE_Status.png
ELOG V3.1.3-