40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 17 of 344 Not logged in
ID Date Author Type Category Subject
15920   Mon Mar 15 20:22:01 2021 gautamUpdateASCc1rfm model restarted

On Friday, I felt that the ASC performance when the PRFPMI was locked was not as good as it used to be, so I looked into the situation a bit more. As part of my ASC model revamp in December, I made a bunch of changes to the signal routing, and my suspicion was that the control signals weren't even reaching the ETMs. My log says that I recompiled and reinstalled the c1rfm model (used to pipe the ASC control signals to the ETMs), and indeed, the file was modified on Dec 21. But for whatever reason, the C1RFM.ini (=Dolphin receiver since the ASC control signals are sent to this model over the Dolphin network from the c1ioo machine which hosts the C1:ASC- namespace, and RFM sender to the ETMs, but this path already existed) file never picked up the new channels. Today, I recompiled, re-installed, and restarted the models, and confirmed that the control signals actually make it to the ETMs. So now we can have the QPD-based ASC loops engaged once again for the PRFPMI lock. The CDS system did not crash 🎉 . See Attachments #1-3.

I checked the loop performance in the POX/POY locked config by first deliberately misaligning the ETMs, and then engagin the loops - seems to work (Attachment #4). The loop shapes have to be tweaked a bit and I didn't engage the integrators, hence the DC pointing wasn't recovered. Also, added a line to the script that turns the ASC loops on to set limits for all the loops - in the testing process, one of the loops ran away and I tripped the ETMY watchdog. It has since been recovered. I SDFed a limit of 100cts just to be on the conservative side for model reboot situations - the value in the script can be raised/lowered as deemed necessary (sorry, I don't know the cts-->urad number off the top of my head).

But the hope is this improves the power buildup, and provides stability so that I can begin to commission the AS WFS system a bit.

Attachment 1: RFM.png
Attachment 2: CDSoverview.png
Attachment 3: RFMchans.png
Attachment 4: ASCloops.png
15953   Mon Mar 22 16:29:17 2021 gautamUpdateASCSome prep for AS WFS commissioning
1. Added rough cts2mW calibration filters to the quadrants, see Attachment #1. The number I used is:
0.85 A/W         *       500 V/A            *          10 V/V                              *         1638.4 cts/V
(InGaAs responsivity)     (RF transimpedance)  (IQ demod conversion gain)      (ADC calibration)
2. Recovered FPMI locking. Once the arms are locked on POX / POY, I lock MICH using AS55_Q as a sensor and BS as an actuator with ~80 Hz UGF.
3. Phased the digital demod phases such that while driving a sine wave in ETMX PIT, I saw it show up only in the "I" quadrant signals, see Attachment #2.

The idea is to use the FPMI config, which is more easily accessed than the PRFPMI, to set up some tests, measure some TFs etc, before trying to commission the more complicated optomechanical system.

16267   Mon Aug 2 16:18:23 2021 PacoUpdateASCAS WFS MICH commissioning

[anchal, paco]

We picked up AS WFS comissioning for daytime work as suggested by gautam. In the end we want to comission this for the PRFPMI, but also for PRMI, and MICH for completeness. MICH is the simplest so we are starting here.

We started by restoromg the MICH configuration and aligning the AS DC QPD (on the AS table) by zeroing the C1:ASC-AS_DC_YAW_OUT and C1:ASC-AS_DC_PIT_OUT. Since the AS WFS gets the AS beam in transmission through a beamsplitter, we had to correct such a beamsplitters's aligment to recenter the AS beam onto the AS110 PD (for this we looked at the signal on a scope).

We then checked the rotation (R) C1:ASC-AS_RF55_SEGX_PHASE_R and delay (D) angles C1:ASC-AS_RF55_SEGX_PHASE_D (where X = 1, 2, 3, 4 for segment) to rotate all the signal into the I quadrature. We found that this optimized the PIT content on C1:ASC-AS_RF55_I_PIT_OUT and YAW content on C1:ASC-AS_RF55_I_YAW_OUTMON which is what we want anyways.

Finally, we set up some simple integrators for these WFS on the C1ASC-DHARD_PIT and C1ASC-DHARD_YAW filter banks with a pole at 0 Hz, a zero at 0.8 Hz, and a gain of -60 dB (similar to MC WFS). Nevertheless, when we closed the loop by actuating on the BS ASC PIT and ASC YAW inputs, it seemed like the ASC model outputs are not connected to the BS SUS model ASC inputs, so we might need to edit accordingly and restart the model.

16909   Fri Jun 10 20:11:46 2022 yutaUpdateASCYarm ASS re-tuning in progress

[Anchal, Yuta]

We tried to re-tune Yarm ASS today. It cannot be fully closed as of now. I think we need to play with signs.

Motivation:
- We want to make sure Yarm ASS work with current ITMY coil matrix (40m/16899).
- ASS makes the beam positions on test masses to be the same every day.

What we did:
- Adjusted A2L paths of C1:ASS-YARM_OUT_MTRX based on cavity geometry. For the paths to maximize the transmission using TT1 and TT2, we just assumed they are correctly calculated by someone in the past.
- Adjusted OSC_CLKGAINs so that ITMY and ETMY will be shaken in the same amplitude in terms of radians. The ratio of the excitation was determined to take into account for the oscillator frequency difference between DOFs.
- Checked the time constant of A2L paths by turning on A2L paths only, and checked that of max-transmission paths by turining on them only.
- Adjusted DEMOD_SIG_GAINs so that their time constants will be roughly the same, with C1:ASS-YARM_SEN_MTRX fully identity matrix and all servo GAINs to be +1.
- Re-tuned DEMOD_PHASEs to minimize Q signal. C1:ASS-YARM_ITM_PIT_L_DEMOD_PHASE and C1:ASS-YARM_ITM_YAW_T_DEMOD_PHASE were re-tuned within +/- 5 deg.
- These changes are recorded in /opt/rtcds/caltech/c1/Git/40m/scripts/ASS/ASS_DITHER_ON.snap now.

Result:
- A2L loops seems to be working, but max-transmission paths seems to diverge at some point. I think we need to play with the signs/gains of max-transmission paths for C1:ASS-YARM_OUT_MTRX.
- Attached is the current configuration we achieved so far.

Attachment 1: Screenshot_2022-06-10_20-10-52.png
16911   Mon Jun 13 20:26:09 2022 yutaUpdateASCYarm ASS re-tuning in progress -part 2-

[Anchal, Yuta]

We are still in the progress of re-commissioning Yarm ASS.
Today, we tried to adjust output matrix by measuring the sensing matrix at DC.
Turning on yaw loops kind of works, but pitch does not. It seems like there is too much coupling in pitch to yaw.
We might need to adjust the coil output matrix of ITMY and ETMY to go further, and/or try measuring the sensing matrix including pitch - yaw coupling.

What we did:
- Confirmed that turning on TT1 and TT2 loops (max-transmission loops) work fine. When we intentionally misalign TT1/2, the ASS loops correct it. So, we moved on to measure the sensing matrix of A2L paths, instead of using theoretical matrix caluclated from cavity geometry we used last week (40m/16909).
- Instead of +/-1's, we put +/-2's in the ITMY coil output matrix to balance the actuation between ETMY and ITMY to take into account that ITMY is now using only two coils for actuating pitch and yaw (40m/16899).
- Measured the change in C1:ASS-YARM_(E|I)TM_(PIT|YAW)_L_DEMOD_I_OUT16 error signals when offset was added to C1:SUS-(E|I)TMY_ASC(PIT|YAW)_OFFSET. We assumed pitch-yaw coupling is small enough here. Below was the result.

                            ETM PIT error  ITM PIT error ETM PIT OFFSET of +100cnts: -3.0cnts       -2.99cnts ITM PIT OFFSET of +100cnts: -11.94cnts      -5.38cnts

                            ETM PIT error  ITM PIT error ETM YAW OFFSET of +100cnts: -3.42cnts      -16.93cnts
ITM YAW OFFSET of +10 cnts: +1.41cnts      +0.543cnts

- Inverted the matrix to get A2L part of C1:ASS-YARM_OUT_MTRX. Attachment #1 is the current configuration so far.
- With this, we could close all yaw loops when pitch loops were not on. But vise versa didn't work.
- Anyway, we aligned the IFO by centering the beams on test masses by our eyes and centered all the oplevs (Attachment #2).

Next:
- Do coil balancing to reduce pitch-yaw coupling
- Measure sensing matrix also for pitch-yaw coupling
- Xarm ASS is also not working now. We need to do similar steps also for Xarm

Attachment 1: Screenshot_2022-06-13_20-47-12.png
Attachment 2: Screenshot_2022-06-13_20-44-43.png
16915   Tue Jun 14 20:57:15 2022 AnchalUpdateASCYarm ASS working now

I finally got YARM AS to work today. It is hard to describe what worked, I did a lot of monkey business and some dirty offset measurements to create the ASS output matrix that gave results. Note that I still had to leave out ITMY PIT L error signal, but transmission was maximizing without it. The beam does not center fully on ITMY in Pit direction right now, but we'll mvoe on from this problem for now. Future people are welcome to try to make it work for this last remaining error signal as well.

commit

16930   Mon Jun 20 19:46:04 2022 TomislavUpdateASCSimulation plots

In the attachment please find IMC ASC simulation plots. Let me know what you think, if you want some other plots, and if you need any clarification.

Attachment 1: pit_mot_cl_MCs.png
Attachment 2: loc_damp_cl_MCs.png
Attachment 3: contr_output_cl_MCs.png
Attachment 4: sens_output_cl_MCs.png
Attachment 5: BS_motion_cl_MCs.png
16934   Tue Jun 21 18:41:46 2022 TomislavUpdateASCSimulation plot

In the attachment please find a comparison of error signals of simulation and reality. For C1:IOO-WFS1/2_PIT_IN1 excess signal ('belly') between a few Hz up to 70-80 Hz might be caused by air turbulence (which is not included in the simulation).

Attachment 1: sens_output_comparison.png
16937   Tue Jun 21 22:22:37 2022 TomislavUpdateASCPlots

In the attachment please find a comparison of error signals of simulation and reality after including air turbulence as input noise.

Attachment 1: sens_output_comparison_with_air_turbulence.png
16948   Sat Jun 25 22:18:41 2022 TomislavUpdateASCSimulation and reality comparisons

In the attachment please find plots comparing controller output, local damping output, and error signals.

Input noises of the simulation are seismic noise, osem noise, input power fluctuations, sensing noises of WFSs and QPD, and air turbulence noise for WFSs. There is also optical torque noise (radiation pressure effect).

The procedure to get optical gains and sensing noises:
Having the actuator response A rad/cnts @ 3 Hz. I was shaking MC1/2/3 in pitch with B cnts @ 3 Hz and getting WFS1/2 QPD signals of C cnts @ 3 Hz, which means WFS1/2 QPD optical gain is D cnts/rad = C / (A * B) cnts/rad. So, if WFS1/2 QPD IN1 has a noise spectrum (at higher freqs) of E cnts/rtHz, that corresponds to E/D rad/rtHz of sensing noise for WFS1/2 QPD.

Actuator response [rad/cts] I was getting shaking mirrors at 3 Hz and measuring amplitudes of OSEM output (knowing the geometry of the mirror). I scaled it to DC. From here I was getting ct2tau_mc (knowing the mirror's moment of inertia, Q, and natural pitch frequencies). OSEM calibration factors [cts/rad] I was getting from the input matrix and geometry of the mirror.

The flat noise at higher frequencies from the local damping and controller output channels is presumably quantization/loss of digits/numerical precision noise which I don't include in simulations for now?!

Regarding air turbulence, in KAGRA it has been reported that air turbulence introduces phase fluctuations in laser fields that propagate in air. According to Kolmogorov’s theory, the PSD of phase fluctuations caused by air turbulence scales as ∝ L*V^(5/3)*f^(−8/3). Here, L is the optical path length and V is a constant wind speed. Since it is not obvious how can one estimate typical V in the beam paths I was taking this excess noise from the error signals data between 10 Hz and 50 Hz, extrapolated it taking into account ∝ f^(−8/3) (not for frequencies below 2 Hz, where I just put constant, since it would go too high). I expect that I won't be able to get a parameterized model that also predicts the absolute value. The slope is all I can hope to match, and this I already know. QPD chamber is much smaller (and better isolated?) and there is no this excess noise.

Regarding other things in simulations (very briefly): beam-spots are calculated from angular motions, length change is calculated from beam-spots and angular motion, cavity power depends on length change and input power, and torque on the mirrors depends on beam-spots and cavity power. From other things, local-sensor basis conversion (and vice versa) is worth noting.

Attachment 1: sens_output_comparison_23_6_new.png
Attachment 2: contr_out_comparison_23_6_new.png
Attachment 3: local_damp_out_comp_23_6_new.png
17217   Mon Oct 31 21:04:43 2022 KojiUpdateASCWFS inspection

Inspected the lab to see what we can do about the IFO WFS:

• 1 functional WFS head (tuned at 11/55MHz) @AS Table [40m ELOG 15736]
• 1 WFS head case (empty) @Section Y10 below the tube, plastic box
• 2 WFS PCBs, components stuffed, tuning freq unknown @Section Y10 below the tube, plastic box
• Deomdulators
• no 4ch IQ demod unit (some component possibly spare)
• Build 4 iLIGO demods?
• Whitening / AA
• No permanent unit: Maybe we can borrow something from the BHD
• c1ioo seems to have just 8 more spare channels.
• Borrow a card from bhd? This will require an AI. But their location would be close to the final positions.
17255   Thu Nov 10 20:46:32 2022 ranaUpdateASCIMC WFS servo diagnosis

To check out the bandwidths and cross-coupling in the WFS loops, I made a script (attached) to step the offsets around, sleeping between steps. Its also in the scripts/MC/WFS/ dir.

You can see from the steps that there is some serious cross coupling from WFS1-PIT to MC_TRANS PIT. This cross-coupling is not a disaster because we run the MC2 centering loop with such a low gain. This gain hirearchy means that you can effectively consider the IMC with the WFS loops closed to be an "open loop" plant that the MC TRANS loop is trying to control.

I've started another run at 4:40 UTC since my previous one only paused for 30 seconds after turning each offset OFF/ON. This is clearly not long enough to grab the MC_TRANS loop; although you can tell sort of how slow it is from the slope of the error signal after the step is applied.

To make the plot, I used diaggui in the time series mode, with a 3 Hz BW. I applied a 4th order Butterworth filter at 0.3 Hz to low pass the data using the foton string in the time series tool.

Attachment 1: toggleWFSoffsets.py
#!/usr/bin/env python
#
# toggles the offsets on the WFS loops so that we can estimate the
# loop UGF from the step response
#
# requires that you have put appropriate size offsets
# in the WFS1/WFS2/MC_TRANS filter banks.
# the offset should be just enough to see in the error signal,
# but not so much that the transmitted power drops by more than ~10%
#

... 30 more lines ...
Attachment 2: imc-wfs-steps.pdf
17272   Wed Nov 16 12:53:36 2022 ranaUpdateASCIMC WFS ongoing

In the middle of aportioning gains and signs in the IMC WFS screen, so beware. More updates soon.

17288   Fri Nov 18 23:21:54 2022 ranaUpdateASCIMC WFS ongoing

On Wednesday, I did some rework of the MC WFS gains. I think it should still work as before as long as the overall input gain is set to 0.1 (not 1.0 as the button on the screen sets it to).

1. The MC_TRANS P/TY signals were very small because they are normalized by the SUM. I added a '+80 dB' gain filter to the MC2_TRANS_PIT and MC2_TRANS_YAW filter banks which increase the signal gain before the digital signals are sent from the MC2 model to the MC_WFS control screen's Input Matrix. Now if you plot the MC_TRANS and WFS signals on dataviewer, the time series all have roughly the same magnitude.
2. I put a "-80 dB" gain button into the MC2_TRANS servo filter banks. This should make it have the same overall gain as before, since the (sensor to servo) Input Matrix is diagonal.
3. The servo gains (WFS1_PIT, WFS2_YAW, etc.) had some negative signs. To make all the servo gains positive, I moved those signs into the Output Matrix.
4. The Output Matrix had some values with 4-5 significant digits. I think its not necessary to have more than 2 places after the decimal point since out measurements are not that accurate, so I rounded them off. We can/should change that screen to reduce the PREC field on the matrix element display.
5. Now, if the overall INPUT_GAIN slider is increased beyond 0.1, there is some pitch oscillation. I think that is happening because the Output Matrix is not that great. In principle, if we have diagonalized the system, putting offsets into the various loops' error points won't make offsets in the other loops, but this is not the case. The pitch loops have a lot of cross coupling (my guess is that the off-diagonal elements are of order 0.1); the yaw loops are several times better. I suggest someone redo the Output Matrix diagonalization and then use the error point offset method to check that they are diagonal.

We mainly want these loops to work well at DC, so it is perhaps better if we can measure the matrix at DC. Its less automatic than at 13 Hz, but I think it could be done with a script and some iterative matrix inversion:

1. IMC locked, IMC ASC loops all open (by setting the overall input gain slider to zero)
2. apply an offset in the WFS1_P basis (turn off the integrators in all the servo loops, and apply a ~400 count offset in the error point)
3. tweak the WFS1_P output matrix until the WFS2_P and MC2_TRANS_P signals go to zero.
4. repeat for all 6 loops.

I haven't tried this procedure before, but I think it should work. You can use something like "cdsutils servo" to slowly adjust the Output Matrix values.

17311   Thu Nov 24 15:37:45 2022 AnchalUpdateASCIMC WFS output matrix diagonalization effort

I tried following the steps and the method I was using converged to same output matrix upto 2 decimal points but there is still left over cross coupling as you can see in Attachment 1. With the new output matrix, WFS loop can be turned on with full overall gain of 1.

### Changes:

• I switched off +20dB FM2 on C1IOO-WFS1_PIT and increased gain C1:IOO-WFS1_PIT_GAIN from 0.1 to 1 to be uniform with other filters.
• Output matrix change:
• Old matrix:
-2.   4.8 -7.3
3.6  3.5 -2.
2.   1.  -6.8
• New Matrix:
3.44  4.22 -7.29
0.75  0.92 -1.59
3.41  4.16 -7.21
• I think the main change that allowed the WFS loop to become stable was the 0,0 element sign change.

### Method:

• I made overall gain C1:IOO-WFS_GAIN 0
• Switched of (0:0.8) FM3 on PIT filter modules (IOO-WFS1_PIT, IOO-WFS2_PIT, IOO-MC2_TRANS_PIT)
• Changed ramp time to 2 seconds on all these modules
• Used offset of 10000 for WFS2 and MC2_TRANS, and 30000 for WFS1 (for some reason, response to WFS1 step was much lower than others)
• Measured the following sensor channels
• C1:IOO-WFS1_I_PIT_OUT
• C1:IOO-WFS2_I_PIT_OUT
• C1:IOO-MC_TRANS_PIT_OUT
• First I took 30s average of these channels, then applied the offsets in the three modules one by one and recorded steps in each sensor.
• Measured step from reference value taken before, and normalized each step to the DOF that was actually stepped to get a matrix.
• Inverted this matrix and multiplied with existing output matrix. Made sure column norm1 is same as before and column signs are same as before.
• Repeated a few times.

Note: The standard deviation on the averages was very high even after averaging for 30s. This data should be averaged after low passing high frequencies but I couldn't find the filter module medm screens for these signals, so I just proceeded with simple averaging of full rate signal using cdsultis avg command.

Fri Nov 25 12:46:31 2022

The WFS loop are unstable again. This could be due to the matrix balancing done while vacuum was disrupted. The above matrix does not work anymore.

Attachment 1: WFS_Step_DCResponses_Offsets_Marked.png
17320   Mon Nov 28 20:14:27 2022 AnchalUpdateASCAS WFS proposed path to IMC WFS heads

In Attachment 1, I give a plan for the proposed path of AS beam into the IMC WFS heads to use them temporarily as AS WFS. Paths shown in orange are the existing MC REFL path, red for the existing AS path, cyan for the proposed AS path, and yellow for the existing IFO refl path.  We plan to overlap AS beam to the same path by installing the following new optics on the table:

• M1 will be a new mirror mounted on a flipper mount reflecting 100% of AS beam to SW corner of the table.
• M2 will be a new fixed mirror for steering the new AS beam path to match with MC WFS path.
• M3 will be the existing beamsplitter used to pick off light for MC refl camera. We'll just mount this on a flipper so that it can be removed from the path. Precaution will be required to protect the CCD from high intensity MC reflection by putting on more ND filters.
• The AS beam would need to be made approximately 1 mm in beam width. The required lenses for this would be placed between M1 and M2.

I request people to go through this plan and find out if there are any possible issues and give suggestions.

PS: Thanks JC for the photos. I got it from foteee google photos. It would be nice if these are also put into the 40m wiki page for photos of optical tables.

RXA: Looks good. I'm not sure if ND filters can handle the 1 W MC reflection, so perhaps add another flipper there. It would be good if you can measure the power on the WFS with a power meter so we know what to put there. Ideally we would match the existing power levels there or get into the 0.1-10 mW range.

Attachment 1: F5B115E5-885F-463C-9645-BB2EB73B6144_1_201_a.jpeg
17332   Sat Dec 3 17:42:25 2022 AnchalUpdateASCIMC WFS Fixed for now

Today I did a lot of steps to eventually reach to WFS locking stably for long times and improving and keeping the IMC transmission counts to 14400. I think the main culprit in thw WFS loop going unstable was the offset value set on MC_TRANS_PIT filter module  (C1:IOO-MC_TRANS_PIT_OFFSET). This value was roughly correct in magnitude but opposite in sign, which created a big offset in MC_TRANS PIT error signal which would integrate by the loops and misalign the mode cleaner.

WFS offsets tuning

• I ran C1:IOO-WFS_MASTER > Actiona > Correct WFS DC offsets script while the two WFS heads were blocked.
• Then I aligned IMC to maximize transmission. I also made PMC transmission better by walking the input beam.
• Then, while IMC is locked and WFS loops are off, I aligned the beam spot on WFS heads to center it in DC (i.e. zeroing C1:IOO-WFS1_PIT_DC, C1:IOO-WFS1_YAW_DC, C1:IOO-WFS2_PIT_DC, C1:IOO-WFS2_YAW_DC)
• Then I ran C1:IOO-WFS_MASTER > Actiona > Correct WFS DC offsets script while keeping IMC locked (note the script says to keep it unlocked, but I think that moves away the beam). If we all agree this is ok, I'll edit this script.
• Then I checked the error signals of all WFS loops and still found that C1:IOO-MC_TRANS_PIT_OUTPUT and C1:IOO-MC_TRANS_YAW_OUTPUT have offsets. I relieved these offsets by averaging the input to these filter moduels for 100s and updating the offset. This is where I noticed that the PIT offset was wrong in sign.

WFS loops UGF tuning

• Starting with only YAW loops, I measured the open loop transfer functions (OLTFs) for each loop by simultaneously injecting gaussian noise from 0.01 Hz to 0.5 Hz using diaggui at the loop filter module excitation points and taking ration of IN1/IN2 of the filter modules.
• Then I scaled the YAW output matrix columns to get UGF of 0.1 Hz when YAW loop was along turned on.
• Then I tried to do this for PIT as well but it failed as even with overall gain of 0.1, the PIT loops actuate a lot of YAW motion causing the IMC to loose lock eventually.
• So I tried locking PIT loops along with YAW loops but with 0.1 overall gain. This worked for long enough that I could get a rough estimate of the OLTFs. I scaled the columns of PIT output matrix and slowly increased the overall gain while repeating this step to get about 0.1 Hz UGF for all PIT loops too.
• Note though that the PIT loop shape did not come out as expected with a shallower slope and much worse coherence for same amount of excitation in comparison to YAW loops. See attached plots.
• Never the less, I was able to reach to an output matric which works at overall gain of 1. I tested this configuration for atleast 15 minutes but the loop was working even with 6 excitations happening simultaneously for OLTF measurement.
• We will need to revisit PIT loop shapes, matrix diagonalization, and sources of noise.

OLTF measurements were done using this diaggui file. The measurement file got deleted by me by mistake, so I recreated the template. Thankfully, I had saved the pdf of the measurements, but I do not have same measurement results in the git repo.

Attachment 1: IMC_WFS_OLTF.pdf
17334   Sun Dec 4 16:44:04 2022 AnchalUpdateASCIMC WFS Fixed for now

Today, I worked on WFS loop output matrix for PIT DOFs.

• I began with the matrix that was in place before Nov 15.
• I followed the same method as last time to fist get all UGFs around 0.06 Hz with overall gain of 0.6 on the WFS loops.
• This showed me that MC2_TRANS_PIT loop shape matches well with the nice working YAW loops, but the WFS1 and WFS2 loops still looked flat like before.
• This indicated that output matrix needs to be fixed for cross coupling between WFS1 and WFS2 loops.
• I ran this script WFSoutMatBalancing.py which injects low frequency (<0.5 Hz) oscillations when the loops are open, and measures sensing matrix using error signals. I used 1000s duration for this test.
• The direct inverse of this sensing matrix fixed the loop shape for WFS1 indicating WFS1 PIT loop is disentangled from WFS2 now.
• Note this is a very vague definition of diagonalization, but I am aiming to reach to a workign WFS loop asap with whatever means first. Then we can work on accurate diagonalization later.
• I simply ran the script WFSoutMatBalancing.py again for another 1000s and this time the sensing matrix mostly looked like an identity.
• I implemented the new output matrix found by direct inversion and took new OLTF.Again though, the WFS2_PIT loop comes out to be flat. See Attachment 1.
• Then noting from this elog post, I reduced the gain values on MC2 TRANS loops to 0.1 I think it is better to use this place to reduce loop UGF then the output matrix as this will remind us that MC2 TRANS loops are slower than others by 10 times.
• I retook OLTF but very unexpected results came. The overall gain of WFS1_YAW and WFS2_YAW seemed to have increased by 6. All other OLTFs remained same as expected. See attachment 2.
• To fulfill the condition that all UGF should be less than 0.1 Hz, I reduced gains on WFS1_YAW and WFS2_YAW loops but that made the YAW loops unstable. So I reverted back to all gains 1.
• We probably need to diagonalize Yaw matrix better than it is for letting MC2_TRANS_YAW loop to be at lower UGF.
• I'm leaving the mode cleaner in this state and would come back in an hour to see if it remains locked at good alignment. See attachment 3 for current state.

Sun Dec 4 17:36:32 2022 AG: IMC lock is holding as strong as before. None of the control signals or error signals seem to be increasing monotonously over the last one hour. I'll continue monitoring the lock.

Mon Dec 5 11:11:08 2022 AG: IMC was locked all night for past 18 hours. See attachment 4 for the minute trend.

Attachment 1: IMC_WFS_OLTF_All_Gains_1.pdf
Attachment 2: IMC_WFS_OLTF_Nom_Gain.pdf
Attachment 3: WFS_Loop_Configuration.png
Attachment 4: WFS_Loop_Performance.png
17336   Mon Dec 5 16:24:45 2022 AnchalUpdateASCIMC WFS servo diagnosis

I ran the toggleWFSoffsets.py script to generate a step response of the WFS loops in operation. Attachment 1 shows the diaggui measured time response following the parameters mentioned in 40m/17255. There are few things to quickly note from this measurement without doing detailed analysis:

• WFS2_PIT is heavily cross-coupled with WFS1_PIT and MC2_TRANS_PIT. This was also the inference from the previous post based on loop shape for WFS2_PIT loop. This needs to be fixed.
• Weirdly enough, it seems that WFS2_PIT is also cross coupled with MC2_TRANS_YAW.
• MC2_TRANS_PIT is not coupled to WFS1_PIT or WFS2_PIT. This was the major issue in last measurement in 40m/17255.
• WFS1_PIT is coupled to MC2_TRANS_PIT by about half, but is not cross-coupled to WFS2_PIT.
• For YAW, the DOFs are mostly disentangled except for a cross coupling of WFS1_YAW to MC2_TRANS_YAW by about 60%.

To get out the UGF of the loops from the step responses, I need to read this into python and apply the same filters and analyze time constants. I still have to do this part, but I thought I'll put out the result before spending more time on this.

Attachment 1: IMC_WFS_Step_Response.pdf
17337   Mon Dec 5 20:02:06 2022 AnchalUpdateASCIMC WFS heads electronic feasibility test for using for Arm ASC

I took transfer function measurement of WFS2 SEG4 photodiode between 1 MHz to 100 MHz in a linear sweep.

### Measurement details:

• The reincarnated Jenne laser head was used for this test. The laser diode is 950 nm though, which should just mean a different responsivity of the photodiode while we are mainly interested in relative response of the WFS heads at 11 MHz and 55 MHz with respect to 29.5 MHz.
• See attachment 2 for how the laser was placed on AP table.
• The beam was injected in between beam splitter for MC reflection camera and beam splitter for beam dump.
• The input was aligned such that all the light of the laser was falling on Segment 4 of WFS2.
• Using moku, I took RF transfer function from 1 MHz to 100 MHz, 512 points, linearly spaced, with excitation amplitude of 1 V and 100,000 cycles of averaging.
• Measurement data and settings are stored here.

### Results:

Relative to 29.5 MHz, teh photodiode response is:

• At 11 MHz: -20.4 dB
• At 55 MHz: -36.9 dB
• At 71.28 MHz: -5.9 dB

I'm throwing in an extra number at the end as I found a peak at this frequency as well. This means to use these WFS heads for arm ASC, we need to have 10 times more light for 11 MHz and roughly 100 times more light for 55 MHz. According to Gautam's thesis Table A.1 and this elog post, the modulation depth for 11 MHz is 0.193 and for 55 MHz is 0.243 in comparison to 0.1 for 29.5 MHz., so the sideband TEM00 light available for beating against carrier TEM01/TEM10 is roughly twice as much for single arm ASC. That would mean we would have 5 times less error signal for 11 MHz and 40 times less error signal for 55 MHz. These are rough calculations ofcourse.

Attachment 1: 20221205_193105_WFS2_SEG4_RF_TF_Screenshot.png
Attachment 2: PXL_20221206_033419110.jpg
17342   Tue Dec 6 16:52:26 2022 AnchalUpdateASCIMC WFS heads electronic feasibility test for using for Arm ASC

I tested teh WFS demod board for possibility of demodulating 11 MHz or 55 MHz signal with it. It definitely has some bandpass filter inside as the response is very bad for 11 MHz and 55 MHz. See attached the ASD curves for the excitations seens on I and Q inputs of WFS1 Segment 2 when it was demodulated with a clock of different frequencies but same amplitude of 783.5 mVpp (this was measured output of 29.5 MHz signal from RF distribution board). See attachments 2-4 for mokulab settings. Note for 29.5 MHz case, I added an additional 10 dB attenuator to output 1.

The measurement required me to change signal power level to see a signal of atleast 10 SNR. If we take signal level of 29.5 MHz as reference, following are the responses at other frequencies:

• At 11 MHz:
• I: -92 dB
• Q: -97 dB
• At 55 MHz:
• I: -75 dB
• Q: -72 dB

Note that I and Q outputs are unbalanced as well for the two different demodulation frequencies.

This means that if we want to use the WFS demodulation boards as is, we'll need to amplify the photodiode signal by the above amounts to get same level of outputs. I stil need to see the DCC document of these board and if the LO is also bandpassed. In which case, we can probably amplify the LO to improve the demodulation at 11 and 55 MHz. THe beatnote time series for the measured data did not show an obvious sinusoidal oscillation, so I chose to not show a plot with just noise here.

Attachment 1: WFS1_SEG2_DEMOD_Test.pdf
Attachment 2: 11MHz.png
Attachment 3: 29.5MHz.png
Attachment 4: 55MHz.png
17344   Tue Dec 6 17:40:13 2022 KojiUpdateASCIMC WFS heads electronic feasibility test for using for Arm ASC

We have spare WFS demods in a plastic box along the Y arm. So you don't need to modify the IMC demod boards, which we want to keep in the current state.

387   Thu Mar 20 17:45:36 2008 ranaSummaryASSAdaptive Filtering in the ASS system
Over the past couple weeks we (Matt, Alex, Rob, me) have worked on getting an adaptive filter
system working. We wanted to load this system into c1ass to use this processor. The dither alignment
system hasn't been employed here for awhile and so we have just used this box.

The signals are acquired in the PEM ADCU. Alex modified the code there to send the signals over to
the new system. We also get the SUS-LSC_OUT signals from each of the suspensions so that we can
try to minimize them.

The outputs of the adaptive filter go into the unused SUS-MCL inputs of all the suspensions (except
for MC2). In the current setup, we have 6 accelerometers and 1 seismometer around the MC to be used
to demonstrate the principle of the whole thing.

Much more documentation and description of everything is necessary. We'll try to get Matt, Rob, and Alex
to use the elog.
428   Fri Apr 18 19:46:08 2008 ranaUpdateASScheck adaptive
I restarted the adaptive code today using 'startass' and 'upass'.
I moved them into the scripts/ASS/ subdirectory.

Things seem OK. With a MU=0.03 and a TAU=0.00001, there is a still
a good factor of 10 reduction of the 3 Hz stack peak from the MC2
drive by doing FF into MC1.

I edited the ASS-TOP screen so that we could see such small numbers. I
also re-aligned the MC SUS to match the input beam (mainly MC3). The
cavity was locking on a TEM10 mode mostly -- we should look in the SUS
OSEM trends to see if MC3 has moved a lot in the last month or so.

Caryn Palatchi (a Caltech undergrad who just started working with us)
illustrated to me today that using even 1000 FIR taps is not very effective
for low frequency noise cancellation if you have a 2048 Hz sample rate. More
precisely, the asymptotic Wiener filter which our 'LMS' algorithm converges
to, can often amplify the noise at frequencies below f_sample/N_taps.

A less obvious thing that she also noticed is that there is almost no cancellation
of the 16.25 Hz bounce mode when using such a short filter. That's because that
mode is fairly high Q: the transfer function from the Z-ACC to the cavity signal
goes through the high-Q vertical suspension resonance; the FF signal we send back
goes through the low-Q horizontal pendulum response only. Therefore the filter
needs to be able to simulate ~100 cycles at 16.25 Hz in order to cancel that peak.

Duh.

The message here is: we need to find a computationally efficient way to do FIR filtering
or its not going to ever be cool enough to help us find the Crab.
Attachment 1: 0052_xray_thm45.jpg
432   Mon Apr 21 12:58:42 2008 robUpdateASScheck adaptive

 Quote: Caryn Palatchi (a Caltech undergrad who just started working with us) illustrated to me today that using even 1000 FIR taps is not very effective for low frequency noise cancellation if you have a 2048 Hz sample rate. More precisely, the asymptotic Wiener filter which our 'LMS' algorithm converges to, can often amplify the noise at frequencies below f_sample/N_taps. A less obvious thing that she also noticed is that there is almost no cancellation of the 16.25 Hz bounce mode when using such a short filter. That's because that mode is fairly high Q: the transfer function from the Z-ACC to the cavity signal goes through the high-Q vertical suspension resonance; the FF signal we send back goes through the low-Q horizontal pendulum response only. Therefore the filter needs to be able to simulate ~100 cycles at 16.25 Hz in order to cancel that peak. Duh. The message here is: we need to find a computationally efficient way to do FIR filtering or its not going to ever be cool enough to help us find the Crab.

This is the reason for "RDNSAMP" parameter in the ASS code. The FIR filtration is applied at the downsampled rate, not the machine rate. So, if RDNSAMP=32, the effective sampling rate of the FIR filter is 64Hz, and thus noise cancellation should be good down to 64Hz/1000, or 64mHz, and the filter has an impulse response time that extends to 15 secs. I'm not convinced the filter length is what's limiting the performance at the bounce mode, but I agree that a faster FIR implementation would be good.
579   Thu Jun 26 21:07:11 2008 ranaConfigurationASSdust & MC1
I realized today, that yesterday while we were trying to debug the adaptive noise canceler, I turned
off the analog dewhitening on MC1. I did this by changing settings on the Xycom screen but I
forgot to elog this -- this may have caused problems with locking via increased frequency noise.
I have now returned it to its nominal, dewhitening on, configuration.

I also used mDV to look at the last year of dust trend. I have plotted here the cumulative
histogram in percentile units of the 0.5 micron dust level. The x-axis is in units of particles per cu. ft.
and the y-axis is percentage. For example, the plot tells us that over the last year, the counts were
below 6000, 90% of the time. I have set the yellow and red alarm levels to alarm at the 95-th and 99-th
percentile levels, respectively.
Attachment 1: Screenshot-2.png
981   Mon Sep 22 21:54:05 2008 ranaUpdateASSNew Wiener result with x10 gain in ACC
The 2 attached PDF files show the performance of the Wiener filter code on 2 hours of data
with a 4000 tap filter on 64 Hz data. All 6 accelerometers around the MC and the Ranger seismometer
were used.

I attribute the improved performance in the 3-10 Hz band to the better SNR of the ACC channels. To
do better below 1 Hz we need the Guralps.
Attachment 1: f.pdf
1105   Sun Nov 2 20:44:58 2008 ranaUpdateASSWiener Filter performance over 5 hours
I took one 2 hour stretch of data to calculate a MISO Wiener filter to subtract the Ranger seismometer
and the 6 Wilcoxon accelerometers from the IOO-MC_L channel. I then used that static filter to calculate
the residual of the subtraction in 10 minute increments for 5 hours. The filter was calculated based upon
the first 2 hours of the stretch.

The MC lock stretch is from Oct 31 03:00 UTC (I think that we are -8 hours from UTC, but the DST confounds me).
So its from this past Thursday night.

I wrote a script (/users/rana/mat/wiener/mcl_comp.m) which takes the static filter and does a bunch of loops
of subtraction to get a residual power spectrum for each 10 minute interval.

In the attached PNG, you can see the result. The legend is in units of minutes from the initial t0 = 03:00 UTC.

BLACK-DASHED -- MCL spectrum before subtraction

I have also used dashed lines for some of the other traces where there is an excess above the unsubtracted data.
Other than those few times, the rest are all basically the same; this indicates that we can do fine with a very
slow adaptation time for the feed-forward filters
-- a few hours of a time constant is not so bad.

After making the plot I noticed that the Ranger signal was totally railed and junky during this time.
This probably explains the terrible performance below 1 Hz (where are those Guralps?)

The second attached image is the same but in spectrogram form.
Attachment 1: f.png
Attachment 2: f1.png
1111   Mon Nov 3 22:35:40 2008 ranaUpdateASSWiener Filter performance over 5 hours
To speed up the Wiener filter work I defined a 256 Hz version of the original 16kHz IOO-MC_L signal. The
attached plots show that the FE decimation code works correctly in handling the anti-aliasing and
downsampling as expected.
Attachment 1: DAQ.pdf
1112   Tue Nov 4 00:47:53 2008 ranaUpdateASSWiener Filter performance over 5 hours
Same as before, but now with a working Ranger seismometer.

In the spectrogram, the color axis is now in dB. This is a whitened spectrogram, so 0 dB corresponds to
the average (median) subtraction. The color scale is adjusted so that the large transients are saturated
since they're not interesting; from the DV trend its some kind of huge glitch in the middle of the
night that saturated the MC1 accelerometers only (maybe a pump?).

The attached trend shows the 5 hours used in the analysis.
Attachment 1: f2.png
Attachment 2: f.png
1985   Fri Sep 11 17:11:15 2009 SanjitUpdateASSOAF: progress made

[Jenne & Sanjit]

Good news: We could successfully send filtered output to MC1 @ SUS.

We used 7 channels (different combinations of 3 seismometer and six accelerometer)

We tried some values of \mu (0.001-0.005) & gain on SUS_MC1_POSITION:MCL and C1ASS_TOP_SUS_MC1 (0.1-1).

C1:ASS-TOP_SUS_MC1_INMON is huge (soon goes up to few times 10000), so ~0.1 gains at two places bring it down to a reasonable value.

Bad news: no difference between reference and filtered IOO-MC_L power spectra so far.

Plan of action: figure out the right values of the parameters (\mu, \tau, different gains, and may be some delays), to make some improvement to the spectra.

** Rana: there's no reason to adjust any of the MCL gains. We are not supposed to be a part of the adaptive algorithm.

2434   Sun Dec 20 21:39:40 2009 rana, jenne, kiwamuUpdateASSOAF Model update and build instructions

### After a lot of headache, I got the OAF working again - read on for details.....................

Sometime last week, Jenne, Kiwamu, and I tried to update the OAF model to include the IIR "feed-around" path.

This path is in parallel to the existing FIR-based adaptive FXLMS stuff that Matt put in earlier. The reason for the

new path is that we want to try emulating the same FF technology which has been successful lately at LLO.

However, we were unable to make the ASS work after this work. Mostly, the build stuff worked fine, but we couldn't get DTT

to make a transfer function. The excitation channels could be selected and the excitation would actually start and get all the

way into MC1, but DTT would just hang on the first swep-sine measurement with no time-out error. Clearly our ASS building

documentation is no good. We tried using the instructions that Koji gave us for AAA, but that didn't completely work.

In particular, the 'make-uninstall-daq-ass' command gave this command:

[controls@c1ass advLigo]$make uninstall-daq-ass grep: target/assepics/assepics*.cmd: No such file or directory Please make ass first make: *** [uninstall-daq-ass] Error 1 re-arranging the order to do 'make-ass' first fixes this issue and so I have fixed this in the OAF Wiki. The there's the whole issue with the tpchn_C3.par file. This contains all the test point definitions for the ASS/OAF machine. The main IFO numbers are all in tpchn_C1.par and the OMC is all in tpchn_C2.par. When we do the usual build, in the 'make install-daq-ass' part: [controls@c1ass advLigo]$ make install-daq-ass
Installing GDS node 3 configuration file
/cvs/cds/caltech/target/gds/param/tpchn_C3.par
Updating DAQ configuration file
/cvs/cds/caltech/chans/daq/C1ASS.ini

we get this .par file installed in the target area. The ACTUAL param file seems to actually be in /cvs/cds/caltech/gds/param  !!

Of course, it still doesn't work. That's because the standard build likes to point to /cvs/cds/caltech/gds/bin/awgtpman and the one that runs on

linux is actually /opt/gds/awgtpman. So I've now made a file called startup_ass.cmd.good which runs the correct one. However, the default build

will try to start the wrong one and we have to fix the 'startass' script to point to the correct one on each build. Running the correct awgtpman

allows us to get the TP data using tools like tdsdata, so far no luck with DTT.\

UPDATE (23:33): It turns out that it was my old nemesis, NTPD. c1ass had a /etc/ntp.conf file that was pointing at an ntp server called rana113. I

am not an NTP server; I don't even know what time it is. I have fixed the ntp.conf file by making it the same ass c1omc (it now points to nodus). After

this I set the date and time manually (sudo date -s "20 DEC 2009 23:27:45") and then restarted NTPD. It should now be fine even when

we reboot c1ass.

After all of this nonsense, I am able to get TP data from c1ass and take transfer functions between it and the rest of the world !

2437   Mon Dec 21 02:22:31 2009 rana, jenne, kiwamuUpdateASSOAF Model update and build instructions

This allowed measuring the MC1 -> MCL TF finally. Its mostly flat. Data saved as Templates/OAF/OAF-MCLTF.xml

Attachment 1: Untitled.png
2438   Mon Dec 21 07:30:58 2009 ???UpdateASSOAF Model update and build instructions

What does OAF stand for? The entry doesn't say that. Also the acronym is not in the abbreviation page of the wiki.

2440   Mon Dec 21 10:09:06 2009 jenneUpdateASSOAF Model update and build instructions
OAF stands for Online Adaptive Filtering. We use the same computer which was once the ASS. One of these days, we'd like to completely be rid of all things which refer to ASS, and make even the computer's name OAF.
2441   Mon Dec 21 19:24:29 2009 ranaUpdateASSOAF Model update and build instructions

I fit the MC1 -> MCL TF using vectfit4.m (from mDV). The wrapper file is mDV/extra/C1/ fitMC12MCL.m.

Plotted here are the data (RED), the fit (BLUE), and the residual x10 (GREEN).

For the magnitude plot, residual is defined as ------   res = 1 - fit / data

For the phase plot the residual is defined as -------    res =  phase(data)-phase(fit)

You can see that the agreement is very good. The phase match is better than 5 deg everywhere below 10 Hz.

This TF is so smooth that we could have probably done without using this, but its good to excercise the method anyway.

Attachment 1: mc12mcl.png
2442   Tue Dec 22 02:50:09 2009 rana, kiwamu, jenneUpdateASSOAF Feedaround ON and doing something good

Kiwamu made the OAF screen functional today - screenshot attached.

After this, I used the measured TF of the MC1 to MCL to filter the signals from the Wilcoxon accelerometers and feed them into the MC.

The noise at 3 Hz went down by a factor of ~3. There's a little excess created at 100 Hz. Its good to see that our intuition about feed-forward is OK.

I did all of the filter calculations by adapting the scripts that Haixing, Valera, and I got going at LLO. They're all in the mDV/extra/C1 SVN.

The Wiener code predicts much better performance from using more than just 2 horizontal accelerometers, but I was too lazy to do more channels today.

I also added the Rai box to the Ranger readout today - the noise at 0.1 Hz went down by a factor of 10 and the noise at 1 Hz is close to 10^-11 m/rHz.

Attachment 1: oaf.png
Attachment 2: oaf.png
2449   Wed Dec 23 17:33:14 2009 ranaUpdateASSOAF Feedaround ON and doing something good

The Rai box ran out of batteries a couple of days ago and so the data is no good. I've put the Ranger back on the SR560 for now (but with the damping resistor removed, so the gain is 2x more than before).

4696   Wed May 11 23:02:52 2011 valeraUpdateASSDither angular stabilizitaion system update

This is what was done in past two days:

- The ETMY and ITMY pitch and yaw dofs are modulated at 40, 44, 42, 46 Hz respectively (oscillator A=30). The c1ass lockin numbers are 12, 14, 27, 29.

- The NAS55I signal is demodulated at the above frequencies. The demodulated I/Q signal phase is set to shift all signal into I-phase. The lockin inputs are bandpassed around respective frequency f with butter("Bandpass",2,f-0.5,f+0.5). The demod signals are then additionally low passed with butter ("Lowpass",4,0.5) so the servo ugf has to be below 0.5 Hz. The servo filter is p:z 0.0001:0.1.

- The ETMY demodulated signal is fed back to ITMY and visa versa.

- With the above 2x2 servo running we moved the input beam PZTs by hand to follow the cavity.

- At the end we offloaded the servo control signals to the SUS biases again by hand.

- The beam spot centering was estimated by unbalancing the ETMY/ITMY pitch/yaw coil combinations intentionally by 5%, which produces 1.3 mm shift of the node, and comparing the response to the residual signals.

- The dof set up currently is: ETMY pitch lockin 12 -> dof2, ITMY pitch lockin 14 -> dof4, ETMY yaw lockin 27 -> dof7, ITMY yaw lockin 29 -> dof9

- The next step is to demodulate the TRY(X) and servo the input beam PZTs

4709   Fri May 13 00:39:53 2011 valeraUpdateASSc1ass update

Here the status of the dither alignment or c1ass:

- Both pitch and yaw centering on ETMY/ITMY were closed simultatenously with ugf of ~1/30 Hz.

- I made a medm screen with beam positions as measured by the dither system.The snapshot is attached. There are visual perimeter alarms (red box around the display) to warn about arm power being low or the dither lines not being on. The screen has a pull down menu with 4 scripts:

. assUp - sets up the gains, phases and matricies for the dither system (both the spot centering and the input beam alignment)

. assOn - turns on the dithers and servo - just the Y-arm centering part at the moment

. assOff - turns off the servo and dither lines

. assDitherOn - turns on the dither lines but does not turn on the servo

- All scripts are in scripts/ASS and the medm screen is in medm/c1ass/master/

Still to do:

- Commission the input beam and X-arm servos

- Make scripts for X-arm

Attachment 1: c1assqpds.jpg
4726   Mon May 16 11:47:59 2011 kiwamuUpdateASSc1ass update part II

The medm screen for c1ass started being modified to be more user-friendly.

The modification is still ongoing, but the goal is to make a screen which anyone can easily understand and play with.

Still to do : ( need a volunteer )

- Modification of the screens

- Commission the input beam and X-arm servos

- Make scripts for X-arm

- Measure the PZT mirrors' matrix for the translation and angle

 Quote from #4709 Here the status of the dither alignment or c1ass: Still to do: - Commission the input beam and X-arm servos - Make scripts for X-arm

4795   Wed Jun 8 16:41:48 2011 valeraUpdateASSX and Y arm dither alignment status

The current status of the dither alignment system:

- Both Xarm and Yarm alignment are working. The scripts are: scripts/autoDither/alignX(Y). Each script sets up the respective arm, turns on the dither lines and servos for 66 sec, offloads the control signals to TM alignment biases and PZT sliders in case of  Yarm, and to TM and BS alignment biases in case of Xarm, and finally turns off and clears the servo filters and turns off the dither lines.

- Jammie witnessed the final tests of both scripts - both X and Y arm power went up from 0.6-0.7 to close to 1 and the AS beam became symmetric. Also Jammie wanted me to leave the ETMY oplev in its current non-nominal but more stable state i.e. the oplev signals go to the ADC from the D010033 card not the D020432 one. The scripts can now run from the CONFIGURE medm screen.

- Both arms use signals derived from modulating ITM and ETM in pitch and yaw dofs and demodulating the arm power (TRX or TRY) and the cavity length signal (AS55I). The Yarm actuation has 8 dofs - pitch and yaw of the ITM, ETM, and two input beam PZTs so all the sensed dofs are controlled. The Xarm actuation has only 6 dofs - pitch and yaw of the ITM, ETM, and BS. The Xarm servo is set up to servo the beam position on the ETMX and the relative alignment of the cavity and the input beam. The ITMX spot position is unconstrained and provides the null test. The residual displacement on the ITMX is 0.2-0.3 mm in yaw and 0.9-1.0 mm in pitch. The I phases of the beam centering lockins, which are also the error points of corresponding DOF filters, are calibrated in mm by unbalancing the TM coils by known amount. The attached snap shot of the medm screen now has both X and Y arm calibrated beam spot positions and uncalibrated input beam indicators. The input beam angle and position signals can/should be calibrated by tapping the signals digitally and applying the proper matrix transformation - this will require the model change.

- Currently there is no lock loss catching in the model. We should add a trigger on arm power (or an equivalent mechanism) to turn off the inputs to prevent the spurious inputs.

Attachment 1: BeamPositionIndicators.png
6723   Thu May 31 01:20:41 2012 JenneUpdateASSASS filter outputs are non-zero with no input

I was looking a little at ASS, while Yuta was doing some Green transmitted DC PD work, and I find that the output of some filters is totally insane with no deliberate input or excitation signals.

Note in the figure that the filter (which is a 2nd order butter bandpass in the C1:ASS-LOCKIN29_SIG filter bank) is ringing a lot - this needs fixing.  But, more disconcertingly, sometimes (not every time) the arm flashes, the input to the filter bank gets a ~1 sample long spike that is ~9,000,000 counts.  9 million is a lot of counts.  This is then making the filter go crazy.

Any ideas on how this can happen, and how we can stop / fix it?  It's certainly a CDS issue, but I'm not sure where or how.

Attachment 1: ASS_Yarm_crazyOutputs_30May2012.png
6980   Tue Jul 17 11:28:29 2012 JenneUpdateASSNames of DoF filters in ASS wrong

The names of the DoF filters in the ASS loop were wrong.  The filters themselves were correct (low pass filters at super low freq, for the Lock-in), but the names were backward.

Our convention is to name filters "poles:zeros", but they had been "z:p".  The names of FM1 in all the DoF filter banks are now fixed.

7017   Tue Jul 24 03:14:13 2012 JenneUpdateASSCalibration of MC ASS lockins

I wanted to check that the calibration of the MC ASS lockins was sensible, before trusting them forevermore.

To measure the calibration, I took a 30sec average of C1:IOO-MC_ASS_LOCKIN(1-6)_I_OUT with no misalignment.

Then step MC1 pitch by 10% (add 0.1 to the coil output gains).  Remeasure the lockin outputs.

2.63 / (Lockin1noStep - Lockin1withStep) = calibration.

Repeat, with Lockin2 = MC2 pit, lockin3 = MC3 pit, and lockins 4-6 are MC1-3 yaw.

The number 2.63 comes from: half the side of the square between all 4 magnets.  Since our offsets are in pitch and yaw, we want the distance between the line connecting the lower magnets and the center line of the optic, and similar for yaw.  Presumably if all of the magnets are in the correct place, this number is the same for all magnets.  The optics are 3 inches in diameter.  I assume that the center of each magnet is 0.9mm from the edge of the optic, since the magnets and dumbbells are 1.9mm in diameter. Actually, I should probably assume that they're farther than that from the edge of the optic, since the edge of the dumbbell ~touches the edge of the flat surface, but there's the bevel which is ~1mm wide, looking normal to the surface of the optic.  Anyhow, what I haven't done yet (planned for tomorrow...) is to figure out how well we need to know all of these numbers.

We shouldn't care more than ~100um, since the spots on the optics move by about that much anyway.

For now, I get the following #'s for the calibration:

Lockin1 = 7.83

Lockin2 = 9.29

Lockin3 = 8.06

Lockin4 = 8.21

Lockin5 = 10.15

Lockin6 = 6.39

The old values were:

C1:IOO-MC_ASS_LOCKIN1_SIG_GAIN = 7
C1:IOO-MC_ASS_LOCKIN2_SIG_GAIN = 9.6
C1:IOO-MC_ASS_LOCKIN3_SIG_GAIN = 8.3
C1:IOO-MC_ASS_LOCKIN4_SIG_GAIN = 7.8
C1:IOO-MC_ASS_LOCKIN5_SIG_GAIN = 9.5
C1:IOO-MC_ASS_LOCKIN6_SIG_GAIN = 8.5

The new values measured tonight are pretty far from the old values, so perhaps it is in fact useful to re-calibrate the lockins every time we try to measure the spot positions?

7074   Wed Aug 1 22:37:21 2012 JenneUpdateASSFilters installed in the ASS

As part of trying to figure out what is going on with the ASS, I wanted to figure out what filters are installed on which lockins.

Each "DoF"(1-6) has a zpk(0.1,0.0001,1)gain(1000), which is a lowpass with 60dB of gain at DC, and unity gain at high frequencies.

For the lockins, since there are so many, I made a spreadsheet to keep track of them (attached).

So, what's the point?  The point is, I think that all of the LOCKIN_I filter modules should be the same, with a single low pass filter.  The Q filter banks don't matter, since we don't use those signals, and the signals are grounded inside the model.  The phase of each lockin was / should be tuned such that all of the interesting signal goes to I, and nothing goes to Q.  The SIG filter modules seem okay, in that they're all the same, except for their band pass frequency.  I just need to check to see what frequency the ASS scripts are trying to actuate at, to make sure we're bandpassing the correct things.

Attachment 1: ASS_lockin_filters_1Aug2012.pdf
7075   Thu Aug 2 00:43:55 2012 JenneUpdateASSMajor cleanup of the ASS model

[Jamie, Jenne]

We are trying to figure out what the story is with the ASS, and in order to make it more human parse-able, we cleaned up the c1ass.mdl.

So far, we have made no changes to how the signals are routed.  The local oscillators from each lockin still get summed, and go directly to the individual optics, and the demodulated signals from each lockin go through the sensing matrix, the DoF filters, then the control output matrix, and then on to the individual optics.  So far, so good.

Much of the cleanup work involved making a big library part, which is then called once for PIT and once for YAW in the ass top level, rather than have 2 code-copies, which give Jamie conniptions.  Inside the library part GoTo and From tags were used, rather than having all the lines cross over one another in a big spaghetti mess.

One of the big actual changes to the ass was some name changes. Rather than having mysterious "ASS-LOCKIN(1-30)", they are now named something like "ASS-PIT_LOCKIN_ETMY_TRY", indicating that this is in the pitch set, actuating on ETMY, and looking at TRY for the demodulated signal.  The "DOF" channels are similar to what they were, although we would like to change them in the future.....more on this potential change later.  Previously they were "ASS-DOF(1-10)", but now they are "ASS-PIT_DOF(1-5)" and "ASS-YAW_DOF(1-5)". This channel naming, while it makes things make more sense, and is easier to understand, means that all of the ASS scripts need to be fixed.  However, they all needed updating / upgrading anyway, so this isn't the end of the world.

This channel name fixing also included updating names of IPC (shmem/dolphin/rfm things) blocks, which required matching changes in the SUS, RFM and LSC models.  All 4 models (ASS, SUS, RFM, LSC) were recompiled and installed.  They all seem fine, except there appears to be a dolphin naming mismatch between OAF and SUS that showed up when the SUS was recompiled, which presumably it hadn't been in a while.  We need to figure this out, but maybe not tonight.  Den, if you have time, it would be cool if you could take a look at the OAF and SUS models to make sure the names match when sending signals back and forth.

______________________

We also had a long chat about the deeper meaning of the ASS.

What should we be actuating on, and what should we be sensing?  A potential thought is to rename our DOF channels to actual DoF names: input axis translation, input axis angle, cavity axis translation, cavity axis angle.  Then actuate the dither lines on a cavity degree of freedom, sense the influence on TRX, TRY and an LSC PD (as is currently done), then actuate on the cavity degree of freedom.

Right now, it looks like the actuation is for individual optics, the sensing is the influence on TRX, TRY and an LSC PD, then actuate on a cavity degree of freedom.  So the only change with the new idea is that we actuate in the DoF basis, not the optics basis.  So the Lockin local oscillators would go through the control output matrix.  This makes more sense in my head, but Jamie and I wanted to involve more people in the conversation before we commit.

The next question would be: how do we populate the control output matricies?  Valera (or someone) put something in there, but I couldn't find anything on the elog about how those values were measured/calculated/came-to-be.  Any ideas?  If we want to dither and then push on isolated degrees of freedom, we need to know how much moving of which optics affects each DoF.  Is this something we should do using only geometry, and our knowledge of optic placements and relative distances, or is this measurable?

7081   Thu Aug 2 23:31:04 2012 JenneUpdateASSMajor cleanup of the ASS model

Jamie re-redid the ASS model a few hours ago.

I have just compiled it, and restarted c1ass.  (The model from last night is currently called c1ass3.mdl)  I had to delete and re-put inthe goto and from tags for the LSC signal coming in from the shmem.  For some reason, it kept claiming that the inputs using the from tags were not connected, even when I redid the connections.  Finally deleting and dragging in new goto and from tags made the model happy enough to compile.  Whatever.  I'm going to let Jamie do the svn-ing, since he's the one who made the changes.  Before I had figured out that it was the tags, I was concerned that the shmem was unhappy, so there was no signal connecting to the input of the goto tag, and that was somehow bad....anyhow, I recompiled the LSC model to re-create the shmem sender, but that had no effect, since that wasn't the problem.

The change from last night is that now the library parts are by DoF.  There is only one matrix in each library part, before the servo filters. Now we can DC-actuate on a single mode (ETM or ITM, pitch or yaw), and see how it affects all 4 sensors (the demodulated signals from the lockins). We need to measure the sensing matrix to go from the several sensors to the servo input.

7082   Fri Aug 3 03:24:13 2012 JenneUpdateASSNew ASS screens

I wanted to try out the ASS tonight, but I wanted some kinds of screens thrown together so I would know what I was doing.  Turns out screens take longer than I thought.  Am I surprised? Not really.

They're probably at the ~85% mark now, but I should be able to try out the ASS tomorrow I think.

7092   Mon Aug 6 17:15:15 2012 JenneUpdateASSFilter banks not working

I was trying to load some filters into the ASS so that I can try it out, but for some reason the filter banks aren't working - clicking the on/off buttons doesn't do anything, filters (which exist in the .txt file generated by foton) don't load.

I've emailed cds-announce to see if anyone has any ideas.

ELOG V3.1.3-