Update to 17809. The free swing test for ETMX took quite some time, here's a brief summary of what was going wrong and a small update on it.

tldr: The scripts haven't been too helpful to obtain the resonant frequencies. Paco (to the rescue) suggested pulling up the raw data from the channels and get a spectrum manually. From the free swing test that was run on Wednesday (1:00am, was ended abruptly), there was enough data to be able to obtain the resonant frequencies for the Position (0.9524Hz) and Pitch (0.7238Hz) DOFs. The resonant frequencies for Yaw (0.8334Hz) and Side (1.0001Hz) were obtained as well (Aug_Res_Freqs.png).
The percent change in resonant frequencies from the last free swing test run by Yehonathan (17714) for all modes was < 2%. Thus, I will skip the diagonalization and moving to the next step of tuning the coils.

Procedure & Possible Changes

The data was collected in batches, for POS, PITCH (SUSfreeswing_ETMX_1377417624_POS_PIT_YAW_SIDE.txt) (1050 seconds, 15 kicks, 10000 counts) first and then for YAW (SUSfreeswing_ETMX_1377619412_YAW.txt) and SIDE (SUSfreeswing_ETMX_1377623258_SIDE.txt) (720 seconds, 5 kicks, 10000 counts) respectively. At some point, the default could be changed for freeSwing.py as the default setting (15 kicks, 1050 seconds) or 4 DOFs takes (4*15*1050/3600 = 17.5 hours) to new setting (5 kicks, 720 seconds) (4*5*720/3600 = 4 hours). getResFreqs.py is still troublesome so the analysis for this particular test was done in python. The notebook (freeSwingtest_Aug23.ipynb) is attached. It uses 2 really nice snippets of code that Paco has written to obtain the channel data and get the spectra (welch) .

Troublemakers
With some hardware changes to the ETMX (suspectedly the acromag), the script assumes some things which were important to run the test. Manual adjustments: Damping turned off, ramp times for DAMP FILTERS and Coil Outputs set to 0 in EPICS. 

The default value for the kick is 30000. However, kicking with this offset in the DOF basis gave clipping in the coil outputs. This was changed by giving it a 10000 offset using options.

Suspicion: In order to run the subsequent scripts (getResFreqs.py and sus_diagonalization.py), it's important to run freeSwing.py by giving the degrees of freedom for which you would want to obtain the resonant frequencies (eg  -k POS PIT YAW SIDE) as there is an internal dependency for it. Not sure how the UR Coil kick (default) is usually processed ahead (need to read into this in detail)

Even with the above changes, getResFreqs.py was having trouble reading data from the channel (ValueError: could not broadcast input array from shape (xxxx) into shape (xxxx)). Unsure why. 

With the same options (5 kicks, 720 seconds, 10000 counts) for the freeswing test conducted at 01:00am (SUSfreeswing_ETMX_1377565258_YAW_SIDE.txt) and 09:00am (SUSfreeswing_ETMX_1377619412_YAW.txt), the time series for YAW looks terrible for the former (?????). The comparisions are attached (freeswing_yaw_5kicks_10000counts_720s_good.png , freeswing_yaw_5kicks_10000counts_720s_bad.png)

Resonant Frequency in Position:  0.9524518193317955 Hz
Resonant Frequency in Pitch:  0.7238633826921645 Hz
Resonant Frequency in Yaw:  0.833423765599566 Hz
Resonant Frequency in Side:  1.0001085187194791 Hz

The intented AOI for PR2 is 1.5 degrees. I averaged the peak measurements from the Moku:Go spectrum analyzer and from manual python FFT.

The transmissivities for p- and s-polarizations are:

Ready / Soon Ready
- BHD OMC Cables ready
- OMC#1 / OMC#4 ready
- BHD Platform parts being cleaned
- Assembly area HEPA being built
=> We will be soon ready to assemble BHD Platform and test with the OMC

In progress
- OMC locking setup (Moku)
- Connectors being attached to the BHD Platform actuators (picos & rotation stage)
- BHD Platform OFI parts drawing/procurement

- 40m BHD Electronics (BHD Adapter / DCPD TIA / Actuator driver I/F)

Other vent items
- In-vac ribbon cable holder (JC)

- Connector holder

- Scattered light control

- Pre-vent work
    * ASS recovery / extension

    * ETMX tuning
    * Vertex Eletronics upgrade
    * Fix PZT amps / PZT
    * Acromag

- Vent work items
    * New PR2
    * Alignment
 

40m BHD OFI Inventory

• OFI HWP 1
  • Motorized Rotary Stage Thorlabs PDR1V Qty 1
  • 0.5inch HWP: QWPO-1064-05-2 IDEX Optical Tech aka CVI Qty 1
  • Stainless SM5 retainer ring POLARIS-SM05RR (Qty 1 + spare 1)
  • Thorlabs KIM001
  • Power Supply KPS201
  • Post D2300286 (86.69mm = 3.413"), Newport Type https://dcc.ligo.org/LIGO-D2300286
  • Fork, Newport Type
• OFI TFP 1/2
  • Thorlabs LMR1V Qty2
  • Post (84.455mm = 3.325), Newport Type Qty2
  • Fork, Newport Type Qty2
  • 1" TFP obtained from LHO
• OFI FR
  • Already in hand
• OFI HWP2
  • D1600166 mount already in hand
  • 1" HWP already in hand
  • Post D2300287 (78.105mm = 3.075"), Newport Type https://dcc.ligo.org/LIGO-D2300287
  • Fork, Newport Type

Took the backup (snapshot) of nodus' /home/export as of Aug 25, 2023

controls@nodus> cd /cvs/cds/caltech/nodus_backup
controls@nodus> rsync -ah --progress --delete /home/export ./export_230825 >rsync.log&

A bit improved the design of OMC Interface Aligner

The idea is...The OMC I/F aligner covers the OMC for aligning the kinematic mounts (3 pairs of a V-groove and a ball) on the OMC. This makes the kinematic mount of two OMCs identical.

However, the OMC kinematic mount can't be adjusted because all the fasteners of the kinematic mounts are hidden by their counterparts.
We can copy the alignment of the OMC to the aligner, but the opposite is not possible.

Paco took the data which means he already had the beat note.

There is some chance that the beat was recovered after some mode "jumps" but usually the temp gap for the same beat frequency is ~2degC.
So my speculation is that there is a big temp gradient in the crystal now and had to compensate it with the struggle of the crystal TEC.

For the past data see https://nodus.ligo.caltech.edu:8081/40m/3759 or http://nodus.ligo.caltech.edu:8080/40m/12078
http://nodus.ligo.caltech.edu:8080/40m/4439 and so on.

Koji suggested going through the following steps to check the ETMX suspension:

1. Do a free swing test to obtain the input matrix
2. Run the coil balancing script to change the gains on the them
3. Do the ring down test without closing the loop with the OPLEV and just with the OSEM to get Q~5
4. Tune the OPLEV servo gains

Suggestions welcome.
Tuning the ASC would make more sense once ETMX has been calibrated. Will run the free swing test tonight.

With such a big temperature change, do you still get a reasonable beat note frequency? There's some previous elog of Koji I think that explains how we need to tune the lasers to get the 3 lasers to give 2 beat notes that are below 150 MHz.

OMC Interface Aligner - (It's upside down...)

BHD OFI arrangement

Dolphin Investigation

- I made a basic description on a wiki page: https://wiki-40m.ligo.caltech.edu/CDS/DolphinSwitch

- Investigation crashed c1lsc/c1sus/c1iscex/c1sus2. Well, it's time to test the dolphin fencing. It seemed successful.

- Rebooted the crashed machines. I accidentally rebooted nodus, but Apache and elog were restarted.

- Burtrestoring to 18:19 snapshots. I suffered from the zero alignment gain issue, but the two arms are aligned and locked.

During the crash, I tried to reboot c1sus2 while the others were running. I actually did not install the script. It seems that it has been there since 2022 Sep.
Here is the instruction:

• Suppose you have one (or multiple) machines are dead (freeze, dolphin glitch, DK, etc).
• From the following list, determine which host you want to restart:
  PORT HOST
1    c1sus
2    c1lsc
3    c1iscex
4    c1iscey
5    c1ioo
6    c1sus2
• ssh into fb1. At the login directory, run the following command with the above port name (replace the "#" with it). If you have multiple hosts, run the command one by one.
  ./dolphin_ix_port_control.sh --disable 192.168.113.40 #
   
• ssh into the problematic machine. Use the following command to reboot it. Now this does not crash other machines!
  sudo reboot
   
• Once the machine starts rebooting, run the dolphin enabling command on fb1.
  ./dolphin_ix_port_control.sh --enable 192.168.113.40 #
  This should be done before the IOP (c1x07 etc) comes up. Otherwise, that IOP fails. It's allright. If the IOP (and other processes fails), just stop them with
  rtcds stop --all
  and enable dolphin with the above command. And then run
  rtcds start --all
   
• Once everything is up, burtrestore appropriate snapshots.

We can improve the process and the location of the script, but this is a good progress I suppose.

We're trying to reduce the demodulated error signals after running the ASS script for the XARM.

After running the ASS script, we initially tried to play around with the with the EXC Gain and brought all of them down to 300. It didn't make a huge difference on the error signals or the transmission signal. We then tried tweaking the XARM_OUT_MTRX by flipping the signs/changing the magnitude but it mostly just made things worse. We then changed that matrix to closely resemble the YARM_OUT_MTRX (structurally). At an XARM GAIN of about 0.02, with the EXC Gains at 300 and the XARM_SEN_MTRX having 1.00 on the diagonal terms, the error signals slowly started converging to 0. However, X_ARM_ETM_PIT_L_DEMOD_I_OUT16 kept oscillating which wasn't good.

We later tried looking at the spectrum for the demodulated signals to see if there were any peaks at frequencies outside of the delmodulating frequencies. Most of them looked consistent with peaks at demodulation frequencies (and modes) and signal input frequencies (60Hz and modes). We compared the spectrum with the YARM where everything was optimized, there were no noticable differences.

Later in the day, both XARM and YARM lost lock a couple of times for reasons unknown. We restored to an earlier point in the day (12:00) suspecting there was misalignment with the input optics.

THE XARM ASS MYSTERY REMAINS.

[Paco]

Tuning the YAUX laser lowered the excess BEATY noise.

Since as of this post the only change in the YAUX setup was the death and replacement of the NPRO controller, I decided to play with the parameters. I found that increasing the laser power (and compensating for the frequency change by adjusting the temperature) successfully lowers the rms noise of the ALS beat. This is still not as good as it was before (1 Hz/rtHz at 100 Hz), but it is a hint of what may have happened. The initial settings were

ADJ = 0, T=43.6 deg

The final settings were:

ADJ = +6, T=25.8 deg

The maximum power adjustment is +10. Attachment #1 shows a reference (black) before the tuning was made, and after (red and cyan). The cyan trace has the noise eater off, while the red trace had noise eater on. There is no difference as per this measurement, so I left it ON.

Here are the results for Moku Go/Pro delay measurements with the filter shapes removed [Attachments 1, 2]. The PID controller, IIR filter, and FIR filter were all flat in magnitude and phase. The PID controller was the same as before: P=1, I=D=0. The IIR filter was given the form H(s) = 1. The FIR filter was given an exponential form e^(-10t), as done here. The configurations for the Moku:Go (same for the Pro, just 10x higher sampling rate) can be found in Attachments 3-5.

The Agilent 4395A was used once again for measurement. Excluding the FIR low-pass with 201 coefficients, the old measurements with low-pass filters and these flat filters have consistent delay. The Moku:Go IIR filter box used for locking the green laser would still give us a delay of ~12 seconds. 

Photodiode inventory: [OMC ELOG 615]

[Ian, Torrey Cullen, Sander Vermeulen]

We are trying to calibrate one of the Wilcoxon accelerometers from the cryo lab to do a seismic study of campus. To calibrate it, we took data on Friday afternoon until about 6 pm for the Wilcoxon in the X, Y, and Z orientations and took cross-spectra with the seismometer down the end of the X arm from the channels C1:PEM-SEIS_EX_X_IN1, C1:PEM-SEIS_EX_Y_IN1, C1:PEM-SEIS_EX_Z_IN1. For the Wilcoxon, we used the channel from [17717] that was not being used. In the image of the panel in [17717] we tried channel 5, with the channel name C1:X01-MADC0_EPICS_CH28 but it was a slow channel. We asked Koji if there was a fast channel we could use, and he lent us channel 4 on that board with the channel name C1:ALS-X_SLOW_SERVO1_IN1. We took data from this channel to do our measurements. nothing was plugged into this channel when we started using it so we left it that way when we were done. 

I have attached our data.

NOTE: As it turns out the seismometer down the x end is not calibrated. We will recalibrate using the seismometer at the vertex

There is a version of this on the McCuller Logbook. It includes some plots. More non-40m related posts will continue there.

[JC, Koji-remote, paco]

ITMY stuck --> Shaken remotely and restored, ARMS aligned

With Koji's assistance we restored ITMY (it was stuck) and finished aligning both arms. Then JC centered the OpLevs for ETMs, ITMs and BS

ITMY camera blinking --> Replaced camera

JC checked the situation with our ITMYF (face) camera as the image seemed faulty and blinking. The issue this time was not in the power supply as has been before, but rather the CCD itself. After replacing the unit and aligning the ARM cavity, we redrew the marker "guides" on the control room screen for quick reference.

This is an update for 17794.

The UMIK 1 + REW combination gave satisfactory results for creating the acoustic noise spectrum for various spaces. This combination was corroborated using the NIOSH app on iOS (by OSHA) and the real time readings were usually in the +-2dB range of each other. dBA scale (reference values)  and NC scale (reference values) were used for measurement. Since the microphone is omnidirectional, the data was collected in the upright position. About 300 averages were taken for each reading and for open spaces, the data was collected with minimal activity (a few people walked by while collecting the stairwell data but they tried to be discreet). For closed spaces, readings were taken at 2/3 positions depending on the size of the room.

HIGHLY SUGGEST GETTING A CALIBRATION DEVICE IN THE FUTURE TO MAKE FAITHFUL MEASUREMENTS.

This is the Noise Floor of the UMIK-1 for reference (it was taken by covering it in a multiple layers of a bedsheet). The remaining readings can be found in ANS_Script_Data_Images.zip

The zip file contains the following:
Acoustic Noise Spectrum.pdf - This contains the keywords and spectrums consolidated in one pdf document
ANS_Positions.pdf - This contains images of the mic position while collecting the data
NC_Data_points.txt - This contains the data points used to generate the NC curves (Spline fit)
Spectrum Data - This folder contains the text files with the raw data to create the spectrum as well as some additional information about the recordings (source, date, etc)
Spectrum Images - This folder contains individual images for all the spaces
Final_Analyze_Signal.ipynb - Notebook used to create the spectrum from the text data

Update: Added spectrums for Downs-Lauritsen Rooms (226, 314, Sub Basement Corridor)
Update: Superimposed noise floor on each spectrum

[JC, paco]

This morning we noted most optics were tripped, probably as a result of a recent M>5 earthquake in the area (on Sun 08/20). Most optics were restored and damped nicely, except for ITMY.

PMC locked to HOM --> realigned and locked

We aligned PMC to maximize its transmission to ~ 0.670, after this IMC was locked and we engaged the WFS to recover the alignment.

ETMY oplev laser --> replaced aligned and locked

Most suspended optics were restored, but we noticed the OpLev sum on ETMY and ITMY were too low so we checked the lasers on both optics. The ITMY HeNe laser is on, but the one on ETMY is off. JC tested with a new laser head and the controller was determined to be good. Then, we tried resetting the previous one (labeled Oct 25 2020) but didn't have luck, so yet another HeNe laser died. We removed the old one and luckily our spare had the same form factor so it wasn't hard to recover the nominal alignment. After this we verified that the OPLEV loops on ETMY were working.

ITMY local damping --> still "stuck" or worse

The local damping on ITMY is not working properly. This puts it in a weird alignment state which is why we also don't see a large Oplev sum count on the QPD. The shadow sensor (OSEM) signals are all small, the available rms monitors are ~ 0.0, 0.1 mV, and kicking the optic around doesn't produce a corresponding OSEM signal, even when undamped. Therefore, we believe ITMY is either stuck (UR/LR) or worse. We tried the usual "shake" technique but didn't see any sensors being restored.

There was a loss of N2 pressure over this weekend. When I came in to check the cylinder pressures, I was able to hear a hissing sound come from the copper fittings. I attached a photo of where the leak was coming from. I proceeded to tighten the fitting and check with soap and water for any leaks. To do this, I preffered to work with low pressure to make sure nothing would pop off while I was fixing this. Everything is back to normal here, but the vacuum interlocks tripped while I was working on the N2. I got the system back up to its nominal place by following the instructions on the wiki. I've attached a screenshot of what the Vacuum state is now.

I've turned off the power supply. I've attached a picture of the rack with the switch that I flipped circled

Dismantled the seismometer circuit

At Rana's request, Deven and I have pulled all the wires out of the seismometer at the X end that Adviat set up the heater and sensors for. Right now, the seismometer is uncovered (no can) and the can I had to move next to the server rack that is close to the X end. I am attaching pictures of both the seismometer and the can.

I now realize that I have not turned off the power supply for the heater. If someone can please turn off the power supply that is shown in Advait's elog, please turn it off and reply to this elog. If you are unsure which power supply to turn off, read the first line of the elog that I replied to. Thanks!

Advait's circuits have been removed from the seismometer and stored in a box underneath the desk at the end of the control room (see picture). There is even a label on the box which reads "ANDREI CIRCUITS". At the seismometer there are still a few BNC cables left there: these are the cables that were used to interact with Advait's circuits. They have labels on them so that I can put back the circuits when I come back/when the seismometer can is available again

dB(A) (A-weighted) scale and the Noise Criterion (NC) scale are popularly used in the United States for creating the spectrum. 

dB(A) Explanation: https://www.engineeringtoolbox.com/decibel-d_59.html

NC Explanation: https://www.engineeringtoolbox.com/nc-noise-criterion-d_725.html

(tldr: dBA applies an A-weighted filter to the dB scale to account for relative loudness that humans perceive at different frequencies. NC scale assigns a number, eg NC-55 such that at no frequency does the noise go beyond 55dB)

To capture this coherently, engineers usually use a SPL (Sound Pressure Level) Meter which is in essence, just another microphone. It is calibrated using a SPL Calibration Device which plays sound at a given loudness (usually 94dB, 114dB) and at a set frequency (usually 1kHz). You latch it on your SPL meter and make sure it is reading the output. 

The good thing about an SPL meter is, you don’t need to worry about the internal gains and so forth, it does all of that under the hood and gives you the measurement straight in decibels (A/B/C weighted if required).

The alternative to this suggested was using a UMIK 1 (a microphone that has a low noise floor - needs to be measured, online blogs mention it as ~30dbA). The suggested softwares are REW and Dirac Live (this one is paid).

UMIK 1 can be used in a couple of ways:

1. UMIK 1 + REW has a fair amount of documentation online for setting up. You can calibrate the microphone by pressing some keys which brings you in the green zone which the software likes (hopefully). This video explains it well.
   https://www.youtube.com/watch?v=3mOn6_3j5DU.
   UMIK-1 also comes with a calibration file, however one of the blogs mentions that it does not make a huge difference. This calibration file can be used directly in the REW software. This old graph does not show a huge difference in the bandwidth of interest between the factory settings and the calibrated settings. Additionally, it has a Sens Factor which I don't fully understand. (explained in this blog).
   The two REW features that may get the job done are the SPL Meter and the RTA (Real Time Analyzer). However, the issues with both are as described in this question I posted on their forum. https://www.avnirvana.com/threads/rew-umik-1-measurements-dba-nc.12420/#post-94154 (Update: There was a reply on the post needs to be checked out).

2. The signal can be read directly into something like Audacity and the time series can then be analyzed manually. However, the specification sheet for UMIK 1 does not provide it’s sensitivity so it’s difficult to know what it’s actually reading (have contacted the tech support, they said they’ll get back on Monday posted on a forum as well). A couple of recordings that were done on Audacity were of extremely low level using the UMIK 1 which probably means there’s some gain configurations that need to be figured out to get a good signal.

(Another microphone, the YETI Nano Blue may be used with Audacity, have requested for the specifications sheet. Update: 4.5mV/Pa at 1kHz).

[Yuta, Yehonathan, JC]

The Frame for The Cleanroom has Constructed and Placed.

What we did:
  - Put together the Clean room frame.
  - Lifted and placed the cleanroom into.

  - Temporarily moved the portable HEPA to the side.
  - Disconnnect the HEPA Booth.

Summary:

     · Put together the Clean room frame.

In the mornings, I have been coming in and assembling the frame one side at a time. Today I finish by attaching all the part together. It does still feel a bit wobbly at the bottom, but theis will be more fixed one I add a cross beam in the backside and bolt the legs to the ground.

After Yuta locked PRMI and measured the sensing matrix, I changed the input matrix to the following and measured the MICH and PRCL OLTFs.

              AS55Q           |      REFL11_I

MICH A:   0.99752413, 0.00247587

PRCL A:  -0.99752413, 0.99752413

This input matrix was calculated by taking the 2x2 submatrix of the AS55Q and REFL11_I components of the sensing matrix. I took the inverse and then scaled the first row by the MICH->AS55_Q sensing matrix element and likewise for the second row with the PRCL->REFL11_I sensing matrix element.

GPS time for data from lock with new input matrix: 1376274300 - 1376274400.

The OLTFs are saved in:

users/deven/PRCL_OLTF_8-16

users/deven/MICH_OLTF_8-16

[JC, Yuta]

Transitioning from 1f to 3f in both PRMI carrier and sideband is now smooth once you have PRMI nicely aligned (key is to tweak TT1 and TT2).
We measured the sensing matrix for PRMI carrier/sideband locks and measured MICH and PRCL sensitivity with different locking configurations.
PRCL sensitivity does not change between different sensors, but MICH sensitivity gets worse with REFL33_Q.

PRMI sensing matrix during 1f carrier lock:
(whitening gains: AS55 24 dB, REFL55 24 dB, REFL11 15 dB, REFL33 30 dB, REFL165 24 dB)

Sensing matrix with the following demodulation phases (counts/m)
{'AS55': 2.1, 'REFL55': 76.02, 'REFL11': 32.638, 'REFL33': -19.275, 'REFL165': 108.88}
Sensors       MICH @211.1 Hz           PRCL @313.31 Hz           
AS55_I       (+1.77+/-0.44)e+09 [90]    (+3.31+/-0.93)e+09 [0]    
AS55_Q       (+1.45+/-0.10)e+10 [90]    (-0.90+/-1.15)e+09 [0]    
REFL55_I       (-0.06+/-2.51)e+12 [90]    (+1.17+/-0.18)e+13 [0]    
REFL55_Q       (+0.32+/-6.10)e+11 [90]    (-4.99+/-0.38)e+12 [0]    
REFL11_I       (-1.28+/-0.93)e+10 [90]    (+1.16+/-0.07)e+12 [0]    
REFL11_Q       (-0.07+/-1.76)e+09 [90]    (+3.47+/-0.25)e+10 [0]    
REFL33_I       (-3.00+/-1.02)e+09 [90]    (+1.65+/-0.10)e+11 [0]    
REFL33_Q       (+2.06+/-0.64)e+09 [90]    (-8.01+/-0.55)e+09 [0]    
REFL165_I       (-4.16+/-0.51)e+09 [90]    (+8.11+/-0.52)e+10 [0]    
REFL165_Q       (-2.85+/-0.21)e+09 [90]    (-5.59+/-0.56)e+09 [0]    

Ratio AS55_Q/REFL33_Q for MICH was 1.45e10/2.06e9 = 7.0 (it was 3.9 in 40m/17755)
Ratio REFL11_I/REFL33_I for PRCL was 1.16e12/1.65e11 = 7.0 (it was 6.7 in 40m/17755)

PRMI sensing matrix during 3f sideband lock:
(whitening gains: AS55 24 dB, REFL55 24 dB, REFL11 15 dB, REFL33 30 dB, REFL165 24 dB)

Sensing matrix with the following demodulation phases (counts/m)
{'AS55': 2.1, 'REFL55': 76.02, 'REFL11': 32.638, 'REFL33': -19.275, 'REFL165': 108.88}
Sensors       MICH @211.1 Hz           PRCL @313.31 Hz           
AS55_I       (-1.09+/-1.48)e+09 [90]    (-5.73+/-3.01)e+09 [0]    
AS55_Q       (+1.59+/-0.13)e+10 [90]    (-5.50+/-3.46)e+09 [0]    
REFL55_I       (+1.42+/-0.16)e+12 [90]    (-3.70+/-0.17)e+13 [0]    
REFL55_Q       (-1.39+/-0.09)e+12 [90]    (-2.39+/-0.12)e+13 [0]    
REFL11_I       (+1.34+/-0.36)e+10 [90]    (-1.23+/-0.06)e+12 [0]    
REFL11_Q       (+9.64+/-0.78)e+09 [90]    (+1.77+/-0.10)e+11 [0]    
REFL33_I       (+2.89+/-0.54)e+09 [90]    (-1.85+/-0.09)e+11 [0]    
REFL33_Q       (-2.10+/-0.19)e+09 [90]    (+1.77+/-0.10)e+10 [0]    
REFL165_I       (+2.50+/-0.37)e+09 [90]    (-8.24+/-0.38)e+10 [0]    
REFL165_Q       (+3.73+/-0.25)e+09 [90]    (+2.15+/-0.11)e+10 [0]    

Signs flip from carrier lock for REFL33_I and Q, and REFL11_I, but not for AS55_Q.

Jupyter notebook: /Git/40m/scripts/CAL/SensingMatrix/ReadSensMat.ipynb

Locking configurations:
PRMI 1f carrier
 - MICH: 1*AS55_Q
 - PRCL: 1*REFL11_Q

PRMI 1f sideband
 - MICH: 1*AS55_Q
 - PRCL: -1*REFL11_Q

PRMI 3f carrier
 - MICH: 7*REFL33_Q
 - PRCL: 7*REFL33_Q

RPMI 3f sideband
 - MICH: -7*REFL33_Q
 - PRCL: -7*REFL33_Q

Common
 - Trigger on POPDC for carrier, POP110_I for sideband (we can also use POP110_I for both by flipping the sign)
 - C1:LSC-MICH_GAIN = 0.4
 - C1:LSC-PRCL_GAIN = -0.0054
 - No power normalization
 - MICH actuator is 0.5*BS-0.307*PRM
 - PRCL actuator is 1*PRM

PRCL and MICH sensitivity curves:
 See Attachment #1.
 Calibration factors used are as follows.
 C1:CAL-MICH_CINV FM3 is "PRMI_AS55Q" 1/1.45e10=6.9e-11 (from sensing matrix above)
 C1:CAL-MICH_A FM2 is 50.88e-09 (40m/17752)
 C1:CAL-PRCL_CINV FM3 is "PRMI_REFL11I" 1/1.16e12=8.6e-13 (from sensing matrix above)
 C1:CAL-PRCL_A FM2 is 41.40e-09 (40m/17752)

/Git/40m/measurements/LSC/MICH/MICH_Sensitivity_PRMI.xml
/Git/40m/measurements/LSC/PRMI/PRCL_Sensitivity_PRMI.xml

Sensing matrix comparison with past measurements:
 - It is pretty hard to read Gautam's radar plots, but REFL33 and REFL165 both had optical gain of ~10^7 V/m for PRCL and ~10^5 V/m for MICH in PRMI with no arms in 2021 (40m/15883)
 - From his thesis (see Figure 3.21), REFL33 and REFL165 had whitenings gain of 30 dB and 24 dB, respectivly, which are the same as the current gains.
 - Using ADC conversion of 2^16 counts/20 V, ~10^7 V/m for PRCL and ~10^5 V/m for MICH is ~3e11 counts/m for PRCL and ~3e9 counts/m for MICH. This is roughly consistent with the measurement above.
 - This means that REFL33 and REFL165 are probably working as they were in 2021.

Next:
 - Restore PRMI ASS. Alignment takes too much time. (AS WFS?)
 - Further tune REFL33 demodulation phase
 - Tweak suspension damping of ETMX (it is also contributing to ALS out-of-loop noise 40m/17773; coil balancing not enough? 40m/17771; oplev servo tweak necessary?)
 - Investigate ALS out-of-loop noise around 100 Hz (both ALSY 40m/17766 and ALSX 40m/17773)
 - Try PRMI 1f to 3f transition during both arms holded with ALS

== BHD Components ==

BHD BS:
We still have a spare BHD BS @South end optics cabinet. (Attachment 1)

18bit DAC AI:
We have 4x D1000305 aLIGO 18-bit AI Chassis Top Assembly Drawing (4xDB9 Version) @1X3B Rack (Attachment 2)
This version has two DB25M connectors to be connected to DAC. (Attachment 3)

16bit DAC AI kit: To turn the above 18bit AI to D1101521 aLIGO AI 16-Bit DAC Chassis Top Assembly (4xDB9 Dsub config) @Y10 section beneath the tube
- We have 5x rear panels in "Front Panel" box. They are labeled "ADC" rather than "DAC" but work with DACs. (Attachment 4)
- We hacve 4x D0700101 16 bit DAC AI Rear Interface Board in "16bit DAC AI Rear PCB" box. They have already been assembled. (Attachments 5/6)

== Misc discovery ==

Many Eurocard Anti Imaging Boards (Rev C) D000186-C @Y10 section beneath the tube (Attachment 7)
Whaaat! It's the differential version of the iLIGO AI boards... orz

Hidden NPRO set marked broken @Y9 section beneath the tube (Attachments 8-10)
It's the broken NPRO from an end, but we should try to determine which head and controller are broken.
Related ELOG in 2017

I measured the Moku:Go and Moku:Pro delay using a Agilent 4395A network analyzer. I considered the PID controller (0 dB gain); the IIR filter box with a 2nd-order low-pass filter; the FIR filter box with 2 coefficients and 201 coefficients (both low-pass). The current XAUX laser lock is done with a Moku:Go using the IIR filter box, so we would expect ~12 µs of delay.

Basic Idea

The idea behind this study was that in several frequency ranges, there are spikes, or just dominant features, in the ASD of each of the sensors. I’ll model these noise sources as a signal  where  is a Nx1 matrix that describes how the single noise source couples into each sensor. Lets assume that this noise source is the dominant source of noise power in the sensors between  and . Then the band limited covariance matrix will have the following form.

 is the integral of the PSD of the noise source over the frequency band. We can use SVD of  to calculate the result of the PCA.  . Since  is a Nx1 dimensional matrix,  is a 1x1 matrix,  is a Nx1 matrix with a the singular value in the first component and 0’s in the rest, and  is a NxN matrix. The first column of  is equal to  up to a scalar. The result of the columns of  for an orthogonal basis for the space perpendicular to . Therefore, for prominent features in the ASD of the sensors, we can "zoom in" and do a PCA. The first principle component will tell us how the noise source is coupling into the sensor vector space. The rest of the principle components will define subspace orthogonal to the noise source. Therefore a virtual sensor designed in this orthogonal subspace will avoid the noise spike.

Test with simulated noise

The first test I did was to choose some S_n at random and a noise source ASD of  with = 1KHz. I started with the CSD of the unsupressed sensor data, , and calculated the CSD with the new simulated noise: . Attachement 1 shows the ASD of the unsuppressed sensors with this added noise. The second figure is zoomed in on the noise peak. The results of the PCA analysis are summarized by attachment 2. The first figure in attachment 2 shows the ASDs of the virtual sensors formed by the principle components of the PCA. The second figure zooms in on the 1Khz feature. The solid blue curves are the ASDs of the sensors and the dotted red lines are the PCA virtual sensors. This figure shows that the first PCA sensors clearly contains the noise spike but the other N-1 (7) PCA sensors are now flat over this frequency range.

Test with real noise

Attachements 3 and 4 show the same anaylsis done on a real noise feature in the sensors ASDS at ~180Hz and attachments 5 and 6 show the same for a ~640 Hz feature. Both tests show results consistent with the simulated noise test. These are the only tests I've performed thus far so I haven't found a feature yet that doesn't play well with this analysis. 

Conclusions

Virtual sensors could be designed to avoid particular noise spikes this way but a more optimal sensor could avoid multiple noise spikes by transitioning, as a function of frequency, between the othogonal subspaces defined by the PCA. Also, ths technique provides a measure of  up to a scaling. Perhaps this can allow for the origin of these noise features to be identified. 

Summary

The problem in the PMC Frequency Reference Card (35.5MHz) was fixed.
The last opamp stage of the attenuator control (LT1125) had the negative rail, and the EOM drive level was maximally attenuated.
The chip was replaced, and the card was back in the euro crate. The PMC is locking as before.

Diagnosis

Yesterday, I already found that the modulation level was basically zero and had no response to the level slider. Today, the card was extracted from the rack and tested on the workbench. It required +/-24V supplies for the main power and +10V supply for high-power RF amps (SMA-202). Additionally, a function generator to supply a DC voltage is needed to tune the attenuation level manually. (Attachment 1)

Some notes:
- This circuit was previously fixed in 2015 by Yutaro and me: [ELOG 11763]
- Even before that, Jenne and Rana looked at the board for LO fix in 2014 [ELOG 10160]
- The boards DCC number is D980353 however the 35.5MHz version is D000419 and the 40m version has a dedicated DCC number D1400221

Initial look was horrible because some greasy material was covering some parts on the boards (I had the same thing in 2015 too). It turned out that it is a leaked thermal paste from the heat sink at the bottom side. (Attachment 2)

Firstly, the suspicious ERA-5SM was checked. The attenuator control path was suspiciously dead (-5V) but the function generator was attached to the attenuator control pin, the ERA-5SM in the EOM path received the signal and it was working fine(!). The ERA-5SM received 20mVpp and spit out 270mVpp, observed with a 1/10 probe. The LO path one was also alive, receiving 173mVpp_max and yielding 200mVpp.

Then, the high-power amps (SMA-202) were checked. This is an old chip which is not commercially available anymore. So I thought I would be reluctant to replace it was broken. But the amps were just fine. With the above condition, the LO and PC paths' outputs were ~9Vpp and 6.1Vpp.

Now I went into the attenuator control part. And it turned out that the last stage (low pass filter part) was broken. By replacing the LT1125, the attenuator control chain recovered the function. (Attachment 3)

Calibration

The attenuator control voltage was applied to the board, then this control voltage was measured together with the RF output powers (LO and PC). (Attachment 4)

LO power is about 16dBm~17dBm and almost independent with the setting (as expected).
PC power changes from -24dBm to +25dBm.

Attachment 5 is the relationship between the PC RF power and the MODEL Voltage measured in analog.

Restore the setting:

The module was returned to the rack. One thing we should take care of is that the external 10V should be disconnected when the output is not terminated with 50Ohm loads. This is to protect SMA-202 from reflection damage.

Once the board was secured and the 10V supply was connected, the MODET voltage was dependent on the slider setting. The PC output RF power was calibrated against the RFADJ setting. (Attachment 6) It is consistent with the above analog measurements.

The RF level (C1:PSL-PMC_RFADJ) was set to 6.0. This imposes the PC output of +14dBm. C1:PSL-PMC_MODET came back to ~-0.34, which is consistent with the number before the trouble.
I also checked the LO power in situ. The direct output was ~17dBm and the 9dB attenuator made the LO level down to 8dBm. The mixer is ZAD-6, which is 7dBm LO level. So it looks fine.

PDH error signal

The amplitude of the PDH error signal was observed at the IF output of the frequency mixer. The cavity was swept around one of the resonances. It showed a clear PDH error shape with the P-P amplitude of ~130mV. (Attachment 7)

By the way, the PMC error offset slider was swept while the cavity was locked. The error signal indicated

The error signal / Offset slider value
-5.23mV / +10V
-6.11mV / 0V
-7.03mV / -10V
It seems that there is a 1/10⁴ reduction factor between the slider value and the actual applied voltage.

[JC, Yuta]

PMC was unlocked from last night, so we aligned PMC
c1sus2 crashed again during the PMC alignment, so we ran

./opt/rtcds/caltech/c1/Git/40m/scripts/cds/restartAllModels.sh

We burt restored to 2023/Aug/14/16:19 by

./opt/rtcds/caltech/c1/Git/40m/scripts/cds/burtRestoreAndResetSUS.sh /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2023/Aug/14/16:19

Update

In the past 2 weeks I have finalized the pipeline for hyperparameter testing and speeding up the training dramatically. Here is a rundown of the most recent developments:

1. I have pushed a lot of code in the git repo with pipeline for training models using the TF Agent library. Now, all of the models' hyperparameters are specified via config files (config_ppo.yaml), allocated resources on HPC and starting a new run are managed via a bash script (start.sh), and a basic plotting functionality now comes built-in for each model run for easy plotting and evalution of the trained policy.
2. I have increased the speed of the code by making use of more advanced training methods from TF Agents: Compared to PPO_v5.py which uised to take around 25 seconds per iteration, PPO_v6_2.py takes 4 seconds per iteration (given the same training parameters). This allows not only for very fast training, but also much faster debug.
3. I have managed to train a model that effectively solved the environment with constant T_env and no measurement noise. Here is a plot of the policy applied for one episode:
   
   This particular plot comes from the policy of RLCON-60 run, which ran for 12.5 hours, but which seems to have reached "peak" performance in about 2-3 hours judging by the evaluation curve (from neptune.ai):
   
   I know this plot is not great, but basically the plateau has a return between -11064 and -11061 (so effectively constant). The evaluation runs are done 50 interations from each other, which in the case of this run corresponds to around 40 mins of training. Please feel free to check out more details about RLCON-60 at the provided link.
4. I have written an extensive manual in the same git repo with guidance as to how to use the code, and also a mini tutorial on Reinforcement Learning and TF Agents. The manual is not exhaustive and I am still adding to it regularly, but I am always happy to answer questions about the code (I am particularly active in the git issue tracker for the repo).

Moving on, I am ready to start making the environment more complicated: I now need to add things like varying T_env, measurement noise, heating delays, etc. Luckily, these changes can be done independently in PuckEnv.py, allowing us to just use the same code for training once the environment is up and bug-free. For testing purposes of the environments, I also have the env.ipynb, although it is not as streamlined as the rest of the code.

Elog was continuously accessed by net crawlers or something similar. They continuously retrieve random logs and also randomly hits the entries with invalid attachments. The invalid attachments call "convert" to make thumbnails, but fail. Because the crawlers fail to obtain the thumbnails, they try the same URL again, and again.

I decided to setup the firewall (NAT router) to block specified IPs. This was very much successful and made the ELOG lightning fast.

Blocked Spam IP addresses are listed in an IP group in the NAT router setting. It's easy to add more IPs there.

The current setting and some instructions are found on a wiki page: https://wiki-40m.ligo.caltech.edu/FirewallSetting

I went down to the IFO hall and checked the PMC situation. The freq mixer fixed on the rack 1X1 had BNC-T, so the raw error was checked while the PMC was swept around the resonance.
The error signal was ~1mVpp while there is ~1mV offset.

There are a few possibilities: modulation, beam, PD, demodulator, or something else.

I checked if the PD was busted, misaligned, unpowered, etc, but there was no clear sign of what was wrong.
The beam was not well steered on the PD but realigning the PD didn't help the size of the error signal.

Modulation... a possibly high-power RF amp is usually delicate so without consulting with the circuit schematic, I did not want to disconnect the output from a proper load.
Instead, I just checked the modulation level monitor on the PMC Phaseshifter screen. C1:PSL-PMC_MODET said 0~-0.004, which didn't mean anything.
By the way, the LO output had ~1Vpp observed with 50ohm termination on an oscilloscope. That looked OK.

But the history of this channel told us that there was some negative number, which we lost ~3.5 days ago. So it's suspicious.

I checked the circuit schematic of the oscillator box D980353. As I said, the LO was OK. So the oscillator would also be OK. Maybe the EOM path has something.
There is a notorious ERA-5SM in the path. So the first thing to check is this chip. Of course, we have many spares in the blue tower.
 

1. Well, it seems that the PMC error offset issue still remains.

2. The IMC transmon QPD had been aligned for some reference e.g. Max transmission, Center of the MC2 mirror, lowest noise, or else. It's not arbitrary.
    Find the appropriate spot poisiton and then align the QPD for the given spot.

{JC, Yehonathan}

When JC came this morning the IMC was completely misaligned. After tweaking the MC alignment we realized the MC WFS where comletely off the rail. We cleared their history and returned the suspensions to their original position. MC locked immediately.

However there still issues:

1. When WFS where turned on it (now its at 8.194) would slowly misalign the IMC.

2. PMC would get unlocked very quickly everytime the IMC tweaked due the PMC input offset being at the slider's edge at 10V.

First we dealt with the PMC issue. We brought the offset down and tried locking the PMC. When it didn't work we went to the PMC table and connected a triangular wave to EXT DC in the PMC servo. PMC reflection and tansmission where observed using a scope while triggering on the triangular wave.

We changed the input volatge until we could see transmission peaks during the voltage ramp. We aligned the PMC so that the HOMs are minimized. We were then able to lock the PMC at an offset input voltage of 8.2V. Transmission is at 0.67V REFL is at 0.03V.

WFS Servo fix:

We went to the AS table and centered the WFS. We run correct DC and AC WFS offset scripts. When then we locked the IMC and turned on the WFS servo. This time the WFS didn't rail, at least not for the last 1 hour. We also realigned MC2 transmission QPD.

[Koji, Hiroki] 

Calibrated flow sensor signals from [volt] to [m/s] and displayed them on CDS screen

We added the EPICS calc records to /cvs/cds/caltech/target/c1psl/psl/pem.db (Attachment 1) and made two channels for the calibrated signals of the flow sensors as follows:

C1:PEM-HEPA_FLOW_PSL1_CAL : Calibrated signal of flow sensor 1 [m/s]
C1:PEM-HEPA_FLOW_PSL2_CAL : Calibrated signal of flow sensor 2 [m/s]

At first, we tried to calibrate the output signal by using the 6-order approximation written in the user's manual (P11, D6F-V03A1) but the resulting outputs became 0 and we failed.
The cause of this failure might be due to the large number of the calculation of the 6-order approximation.
Then we used 5-order approximation that was fitted to the 6-order approximation and succeeded in obtaining the calibrated signals.
The used 5-order approximation is as follows:

    v: output voltage from flow sensor [V]
    A=5.11938
    B=-29.7601
    C=68.6169
    D=-78.4301
    E=46.0640
    F=-10.2767  

Attachment 2 shows the time series data of the raw signals and the calibrated signals when the flow speed was changed in minimum - middle - maximum.
Attachment 3 shows the CDS screen displaying the calibrated signals.

[JC, Koji]

In the morning, JC came in and found that c1sus had crashed. JC tried to save the situation by rebooting the host, inevitably, all the CDS machines needed to be rebooted.
But it was successful! Thanks, JC!

The remaining issue was that the PMC was in a strange state.
- The transmission was low (0.45~0.5V vs 0.67~0.68V nominal)
- The input alignment didn't help much
- The refl spot was not well centered on the CCD

We jiggled the setting for a while and found that the PMC error input offset needs to be significantly increased from the nominal value.
In fact, the offset hit the end of the range (+10V), this made the transmission to be ~0.67, but there may be slight room to improve it.
To investigate this, we need to look at the analog error signal, but I don't have enough energy to look into it today.

After the PMC recovery, the IMC was locking already, and the arms were flashing. I took the alignment of both arms.

[Hiroki, Paco, Yuta]

As mentioned in elog #17768, we are trying to lock PRFPMI.
To start with a simpler system step by step, we locked FPMI by revising the script for automated locking on Aug. 10th.

Revised automated locking of FPMI:

At first we tried to lock FPMI with the existing script and failed locking because of the changes of some gains.
We revised the script for the automation with the procedure explained in the Supplementary and succeeded in locking FPMI.
The script is easily accessed from the LSC - Actions submenu.
Locking configurations are saved in /opt/rtcds/caltech/c1/Git/40m/scripts/LSC/FPMI-AS55_REFL55.yml. 
The locking procedure by the script is as follows:

• Lock XARM and YARM with CARM and DARM using POX11_I and POY11_I.
• Lock MICH with REFL55_Q.
• Hand off the error signals of CARM and DARM from (POX11_I, POY11_I) to (REFL55_I, AS55_Q).

Attachment 1 shows the screenshot of the locked FPMI with the script above.
Attachment 2 shows the OLTF of MICH. UGF ~ 30 Hz.
 

Supplementary

Gain tuning of CARM and DARM with REFL55_I and AS55_Q:

Firstly, we used the existing script (/opt/rtcds/caltech/c1/Git/40m/scripts/LSC/FPMI-AS55_REFL55.yml) to lock FPMI and succeeded in locking with CARM and DARM by (POX11_I, POY11_I).
However, we failed in locking FPMI with CARM and DARM by (REFL55_I, AS55_Q).
So we measured the OLTF of CARM and DARM by (POX11_I, POY11_I) and that by (REFL55_I, AS55_Q) while FPMI is locked with (POX11_I, POY11_I) and REFL55_Q to see the difference of the OLTFs.

Attachment 3 shows the CARM OLTFs by (POX11_I, POY11_I) (red) and REFL55_I (blue).
UGF of POXY_CARM：~200Hz
UGF of REFL55_CARM: ~220Hz
Gain ratio at 200Hz: (POXY_CARM/REFL55_CARM) = (1.04/1.14) = 0.915

Attachment 4 shows the DARM OLTFs by (POX11_I, POY11_I) (red) and AS55_Q (blue).
UGF of POXY_DARM：~150Hz
UGF of AS55_DARM: ~90Hz
Gain ratio at 150Hz: (POXY_CARM/REFL55_CARM) = (0.9972/0.76)=1.31

In the existing script, CARM and DARM by (POX11_I, POY11_I) are assinged to CARM_A and DARM_A, and CARM and DARM by (REFL55_I, AS55_Q) are assinged to CARM_B and DARM_B.
To match the OLFTs of A and B above, we modified the following gains in the script using the results from the OLTFs measurement above:

CARM_B_GAIN: 1 -> 0.92  
DARM_B_GAIN: 1 -> 1.31

With this modification, we succeeded in locking the FPMI with (REFL55_I, AS55_Q).

Tips on aligning FPMI:

After locking the FPMI, you may find a higher order mode in the AS camera and the ASDC is not fully minimized.
If you misaligned ETMX and ETMY just before locking FPMI, the higher order mode may be produced by the misalignment in pitch for ETMX and ETMY because Misalign -> Restore command in the IFO window does not ensure the perfect restoration.
So you may minimize the ASDC by aligning the pitch of ETMX and ETMY.

[JC, Koji, Yuta, Hiroki]

When we tried to measure the spectrum of C1:LSC-DARM_IN2 with the diaggui, the following error was occured and were not able to measure the spectrum:

"Unable to obtain measurement data" 

We solved this issue by clearing the test points in c1lsc with the following commands:

~> diag
diag> open
diag> tp clear 42 *

"42" corresponds to the DCUID of c1lsc and "*" specifies all the test points.

Details of Clear command: tp clear node# tp#
node# = dcu# of the RTS (see CDS status screen to find the DCU #)
tp# (see CDS status screen to find the TP #)

I just wanted to take the same time series data I took back in 2012 (40m/6874).
ALS noise look much better than 2012, but MICH contrast during both arms hold on IR resonance with ALS looks pretty bad compared with 2012, which indicate unbalance of the arms.

[Radhika, Yuta, Hiroki, Paco]

During YAUX noise measurements, we also locked IR and green lasers in xarm (using Moku:Go lock-in amplifier + digital controller) to look at ALS noise in XARM. I adjusted the controller gain until green transmission looked tightly controlled (less fuzzy). We measured the out-of-loop ALS X beat note fluctuations at 2 gain levels: -12 dB and -14 dB down from the uPDH box fitted response. These are Attachments 1 and 2 respectively.

Note that there was some mirror motion at 1 Hz that is reflected in the spectral densities (coil balancing of ETMX had just been taking place). The -12dB gain adjustment causes frequency noise ~3x higher than the reference above ~70Hz. The -14dB gain adjustment has higher noise from 70-400 Hz, but has slightly suppressed noise above 1 kHz (relative to -12dB gain).

Moku:Go delay measurements will help clarify if this excess noise is a fundamental limitation of the device, or if there is room for improvement by optimizing the controller or further tweaking the gain/offset.

[Hiroki, Paco, Yuta, JC]

Hiroki realized the gain on the AUX feedback loop was slightly high, which was at least partially responsible for the excess frequency noise; after this the lock would still break and result in a mode hop so we tried adjusting the loop gains again this morning. The algorithm that seemed to work was reduce the gain on the analog (UPDH) box until the rail indicators (LEDs) stopped flashing and compensate using the SR560 --

[Paco, yehonathan]

Following Yehonathan's work from yesterday, I found the following coil balancing gains for ETMX:

['UL', 'UR', 'LR', 'LL'] = [-0.993  1.047 -1.007  0.953]

Prompted by the events documented in this previous elog, I used the data I grabbed from the sensors during a previous PRMI lock, described here. I took the time series data from the following channels and compared AS55_Q and REFL11_I to the signals from the fused sensors. 

Sensors measured on the following channels

x1 = "C1:LSC-AS55_I_ERR_DQ" #AS55_I
x2 = "C1:LSC-AS55_Q_ERR_DQ" #AS55_Q
x3 = "C1:LSC-REFL11_I_ERR_DQ" #REFL11_I
x4 = "C1:LSC-REFL11_Q_ERR_DQ" #REFL11_Q
x5 = "C1:LSC-REFL55_I_ERR_DQ" #REFL55_I
x6 = "C1:LSC-REFL55_Q_ERR_DQ" #REFL55_Q
x7 = "C1:LSC-REFL165_I_ERR_DQ" #REFL165_I
x8 = "C1:LSC-REFL165_Q_ERR_DQ" #REFL165_Q

Sensing Matrix

The following sensing matrix was measured during this lock. This is not a new measurement but I'm including it for context since its an important input to the calculations of the fused sensors.

Sensing matrix with the following demodulation phases (counts/m)
{'AS55': 2.0999999046325684, 'REFL55': 76.0199966430664, 'REFL11': 32.638, 'REFL165': 92.23478110797188}
Sensors       MICH @211.1 Hz           PRCL @313.31 Hz           
AS55_I        (+4.44+/-2.93)e+08 [90]    (+1.69+/-0.37)e+10 [0]    
AS55_Q        (+9.89+/-1.00)e+09 [90]    (-3.77+/-0.50)e+09 [0]    
REFL55_I      (-6.12+/-2.24)e+11 [90]    (+3.70+/-0.37)e+13 [0]    
REFL55_Q      (+1.46+/-0.53)e+11 [90]    (-8.89+/-0.86)e+12 [0]    
REFL11_I      (-1.43+/-0.53)e+10 [90]    (+9.13+/-0.86)e+11 [0]    
REFL11_Q      (-7.73+/-3.71)e+08 [90]    (+5.13+/-0.50)e+10 [0]    
REFL165_I     (-3.73+/-0.49)e+09 [90]    (+6.20+/-0.60)e+10 [0]    
REFL165_Q     (-1.38+/-0.10)e+09 [90]    (-2.24+/-0.17)e+10 [0]  

Fused Sensors

The fused senor linear combinations are shown in the bar graphs in attachements 1-3. The the bar height is the weight for each sensor in the linear combination. For attachement 1, I only considered AS55_Q and REFL11_I and formed the fused sensors by choosing the input matrix to be the inverse of the AS55_Q & REFL11_I sensing matrix. This sensing matrix is square so the inverse is unique. The fused sensors in attachements 2 and 3 were calculated from methods described in this previous elog. 

Fused Sensor Signals

Attachment 4 shows the fused sensor signals for the 1 seconds of data for MICH and PRCL. AS55_Q and REFL11_I are plotted for comparison. Those two sensors were used for the PRMI lock so they have no visible low frequency noise. The ASD of the fused sensors are shown in attachement 5. My interpretation of this data is that a higher ASD at low frequencies and a lower ASD at high frequencies are the marker of a good fused sensor. Residual motion of MICH and PRCL during this lock will generate low frequency signals that the good fused sensor will detect. At high frequencies, there is little feedback so the noise measured here is just sensing noise that we want to minimize. 

[Hiroki, Paco, Yuta]

Success in XARM locking with ALSX:

We automated the XARM locking using ALS, the script is easily accessed from the LSC - Actions submenu.
Locking configurations are saved in /opt/rtcds/caltech/c1/Git/40m/scripts/LSC/XARM-ALS.yml . 
The OLTFs for POX11 and ALSX are shown in Attachment 1 (Red: POX11, Blue: ALSX), and the spectra of error signals for POX11 and ALSX are shown in Attachment 2.
Similar to the YARM case, the XARM required FM4 to be off, but also a lower control gain (0.006 instead of the nominal 0.012). To demonstrate the control, we ran an offset lock ramp as with YARM, shown in Attachment 3.

Trials for locking PRFPMI:

We then aligned the PRM and locked PRMI to the carrier while holding the YARM and XARM at an offset using ALS control.  
Then we tried to lock PRMI to the sidebands but we found that the resonant peak of POP110, which was used for the trigger, was negative and failed.
We confirmed that this issue of negative peak is solved by lowering the offset of ALSX and ALSY (Attachment 4 (with 0 offset), Attachment 5 (with slight offset)), so this negative peak might be due to the reflective phase shift of XARM and YARM for sidebands.
However, we were still unable to lock PRMI to the sidebands despite the improved trigger.
We need further investigation...

Upgrading the ETMX coil drivers calls for new coil balancing.

XARM locking using ETMX actuation shows a lot of TRX variation. To make life slightly easier I switch to ITMX actuation. Indeed, the ITMX variation.

1. I drive the ETMX butterfly mode at 13Hz, 10000 cts, and measure the XARM_IN1 signal on diaggui to minimize BUT->POS coupling. There is significant peak at 13Hz.

2. Changing the current coil gains from [-0.8, 1, -1, 1] to [-1,1,-1,1] already reduced the coupling significantly and it seemed that even for 20000 cts the 13 Hz could not be obsereved.

Next, I minimize the POS->PIT coupling

1. I turn off ETMX damping loops.

2. I drive the ETMX POS mode at 13Hz, 1000cts and measure C1:SUS-ETMX_OL_PIT_IN1

3. POS->PIT coupling is minimized using Anchal's technique. When the peak disappears I increase the dither amp to 100000

Next, POS->YAW is minimized in the same way.

Note: when the coil gains change so does the alignment. It is necessary to bring the optic back to the center of the QPD to make fair comparisons.

Since the gains have changed it is necessary to tune the damping loops again.

I measure Q=6 for POS, Q=4 for PIT and Q=3 for YAW.
I decide to reduce the gain of YAW a from 5 to 2.5. Q=5 for PIT now.

I also tune the ETMX OPLEV gains from 1.2 to 1.4.

Final coil balancing gains were:

UL = -1.233 , UR = 0.801, LL =0.767, LR = -1.199

[Paco, yuta]

We found excess noise on the YAUX - PSL ALS beat.

While preparing for a PRFPMI lock, we checked the ALS noise first on YAUX. To our surprise there is significant excess noise above 10 Hz as seen in Attachment #1 (dark blue is today's measurement, cyan is reference from the past). For example, the noise floor at around 100 Hz was 1 Hz, now it is ~ 20 Hz, and the 1 - 1000 Hz rms went up from ~ 200 Hz to > 1 kHz. This may be an issue for CARM offset locking, so we decided to investigate further.

Reviewing the elog, the recent significant change was the breakdown and subsequent replacement of the laser controller. Could the swap made by Koji a few weeks back have introduced excess frequency noise? We also noted the YAUX transmission (C1:ALS-TRY_OUT) has an rms level of ~ 10% which seems excessive but this could be a pathological symptom of our frequency noise or viceversa. The first thing we checked was the OLFT of the YAUX, the shape looks ok and the UGF looks typical, maybe a bit low around 6 kHz. We will repeat this measurement in more detail later.

We took an updated YARM cavity noise budget (see Attachment #2) and confirm that the PSL side looks normal (i.e. MC_F noise spectrum is nominal).

[Paco, Hiroki]  

Installed two flow sensors on the PSL HEPA fans 

To monitor the flow speed of the PSL HEPA fans, we installed two flow sensors:

• Attached two flow sensors on the ceiling of PSL table and connected their outputs to the Acromag ADC:
  • Attachment 1: Connected DB37 to the Acromag ADC
  • Attachment 2: Wiring from the Acromag ADC to the PSL table
  • Attachment 3: Attached flow sensors on the ceiling of the PSL table
  • Attachment 4: Wiring diagram
     
• Changed the flow speed of HEPA fans and monitored the signals from the corresponding sensors with StripTool (Attachment 4):
  • ​Sensor 1:
    • Minimum speed: ~ 0.52 V 
    • Medium speed:   ~ 0.78 V 
    • Maximum speed: ~ 0.83 V 
  • ​Sensor 2:
    • Minimum speed: ~ 0.50 V 
    • Medium speed:   ~ 0.72 V 
    • Maximum speed: ~ 0.83 V 

The results above are non-linear. This might be due to the non-linearity of the flow sensors and the non-linearity of the controllers for HEPA fans.
*Regarding the HEPA fan 1, which the sensor 1 is attached on, there was slight flow even when the speed was minimized. This is why the minimum output of sensor 1 was ~ 0.52 V and not 0.50 V.

Next:

• Calibrate the Acromag ADC by injecting signal from a function generator.
• Calibrate the measued voltage to the flow speed (with linear approximation?) and show them on the CDS screen.

[Paco, Yuta, Hiroki]

We locked PSL frequency using ALSY beat signal and succeeded in sweeping IR resonance for YARM (Attachment 1):

• UGF ~ 150 Hz (Attachment 2)

Automated locking:
Locking configurations are saved in /opt/rtcds/caltech/c1/Git/40m/scripts/LSC/YARM-ALS.yml, and the procedure is almost automated.
When handing off from POY11_I to ALSY, we had to turn FM4 of LSC_YARM off to have more phase margin, as ALSY had excess phase delay compared with POY11_I.
Relative gain including the sign between POY11_I and ALSY need to be tuned in a better way for further automation.
We tried to use 16.4 Hz bounce mode or 29.5 Hz mode to measure the relative gain, but so far not successful.

Noisy ALSY:
The error signal of ALSY is much noisier compared with POY11_I (Attachment 3).
This might be due to the replaced NPRO controller (elog #17685).