[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).

Yehonathan, Paco, and Hiroki helped lock the interferomter into PRMI. While locked, the sensing matrix was calaculated with scripts/CAL/SensingMatrix/ReadSensMat.ipynb. Several of the matrix elements flipped sign from the previous matrix I've used: measured in described in this elog. The results are shown in attachement 1. The interferomter was locked with AS55_Q sensing MICH and REFL11_I sensing PRCL. Also, data was recorded from the following channels from 1375574090 - 1375574170 when the lock was stable.

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"

The goal was to try both methods described in this elog about calculating new input matrices. However, there was only time to try the simplest which takes the Moore-Penrose inverss of the sensing matrix and rescaled the first row by the MICH --> AS55_Q sensing matrix element and the second row by the PRCL --> REFL11_I sensing matrix element. The matrix is given below.

[ 0.00024464  0.00237176  0.00955445  0.04220886 -0.0198488   0.0049371 -0.0044138   0.0001007 ]
[ 0.0009515   0.00924028  0.02669179  0.16685194 -0.07720723  0.01935389 -0.01722475  0.0003956 ]

There was only time to plug the matrix in and briefly close the loop and compare the error signals for MICH from the normal sensing matrix with AS55_Q and with the proposed virtual sensor. Lock was not achieved with the new sensors. A screen shot of the error signals are given in attachement 2. The fused error signal is in blue and the AS55_Q signal is in orange. The screen shot shows the error signal for the fused sensor is very different than AS55_Q: large high frequency fluctuations. Based on these results, I am going to use saved time series of the sensors to compute the error signals as functions of time for the data used in the last elog. I'm not sure whether to attribute the poor performance to the large uncertainties in the sensing matrix and the assumption that the sensing matrix is frequency independent or the noises on the sensors which weren't considered in the calculated of this input matrix. 

We moved the Zurich instruments HF2LI to CAML. IMG_7669.JPG

For monitoring the statuses of the PSL HEPA fans, we are planning to attach flow speed sensors (D6F-V03A1) on the HEPA fans.
Before installing the flow sensors, I have finished the followings:

• Tested two flow sensors with alligator clip wires (Attachment 1)
  • No flow: ~ 0.5 V
  • Saturation: ~ 2.7 V
     
• Measured the flow speed of PSL HEPA fans with an alligator-clip-wired flow sensor
  • Medium speed: ~ 0.8 V (~ 0.6 m/s )
  • Maximum speed: ~ 1.4 V (~ 1.8 m/s)
    The flow speed [m/s] was estimated from the linear approximation of the nominal value
     
• Wired flow sensors to install them in PSL and to take the output voltage by an Acromag ADC (Attachment 2)
  • Wired sensors worked as in the case of the alligator-clip-wired sensors.

Next:

• Summarize the details of the used parts and the wiring.
• Install the wired flow sensors in PSL. Monitor their outputs from CDS.

[Paco, Yehonathan, Yuta, Hiroki]  

Achieved stabler lock of sideband-resonant PRMI w/ 3f by tuning feedback damping

We worked on the PRMI and achieved the followings:

• Added an action button to lock sideband-resonant PRMI w/ REFL33 easily
• Tuned the gains for feedback damping to lower the coherences between ASDC and error signals for damping
• Achieved stable lock of sideband-resonant PRMI w/ REFL33
  • Lock stretch for ~7min. : 1375245020 - 1375245310

Details

Action button to lock sideband-resonant PRMI w/ 3f:
To switch the control loop between carrier-resonant PRMI w/ 1f and  sideband-resonant PRMI w/ 3f easily, we added an action button in the LSC window that activates the control loop for sideband-resonant PRMI w/ 3f.
The saved lock conditions are as follows (*whitening gain and demod. angle are not changed by the action button.):

• MICH:
  REFL33_Q (30 dB whitening gain, -19.275 deg demod angle), Power norm. = 0.002*POP110_I, C1:LSC-MICH_GAIN=-1.56, offset=0, boost= off, roll_off=off , Actuator = 0.5*BS-0.307*PRM
• PRCL:
  REFL33_I (30 dB whitening gain, -19.275 deg demod angle),Power norm. = 0.002*POP110_I, C1:LSC-PRCL_GAIN=0.036, offset=0, boost = on, Actuator = 1*PRM
• Trigger:
  POP110_I*1 ⇒ MICH_TRIG ⇒ Threshold upper:150, lower:100
  POP110_I*1 ⇒ PRCL_TRIG ⇒ Threshold upper:150, lower:100

The parameters above are saved in scripts/LSC/PRMIsb-REFL33.yml 

Tuning of feedback damping: 
We locked PRX and monitored the coherences between ASDC and error signals of feedback damping for BS, PR2, PR3, PRM and ITMX.
Then we changed the gains of OSEM loop and OPLEV loop so that the coherences would be small:

• PR3
  C1:SUS-PR3_SUSPIT_GAIN: 30 -> 5
  C1:SUS-PR3_SUSYAW_GAIN: 30 -> 5
• BS
  C1:SUS-BS_SUSPIT_GAIN: 7 -> 10
  C1:SUS-BS_OLPIT_GAIN: -0.1 -> -0.05
• PRM
  ​C1:SUS-PRM_OLPIT_GAIN: 9 -> 6

The resulting spectra and coherences are shown in Attachment 1.

Success in stable locking of sideband-resonant PRMI w/ 3f:
As a result of gain tuning above, we succeeded in locking sideband-resonant PRMI w/ 3f for ~7min.

• Lock stretch: 1375245020 - 1375245310

Moku:Go used for full locking of green laser - OLTF to come

Picking up from where Reuben left off, I used the Moku:Go in multi-instrument mode to replace the signal generator and uPDH box entirely (Moku:Go setup shown in Attachments 1+2). The lock-in amplifier sourced the modulation for the PZT: 210.5 kHz, 1.4 Vpp amplitude (consistent with 7dBm used by the uPDH box) This LO was used to demodulate the REFL signal input. I coarsely tuned the demodulation phase to 90 degrees until the PDH error signal looked reasonable. The PDH error signal was passed to the digital filter box using the same filter as before. After slightly adjusting the gain knob in the filter module (-8 dB), the lock seemed reasonably stable - transmission screenshot in Attachment 3. I got transmission to ~0.8 with the analog loop today, so it was exciting to see this level maintained with the Moku:Go lock (ignoring oscillations from test mass motion). The system remains locked to TEM00 for 5-10 minutes before mode hopping, which is qualitatively comparable to the analog loop as well.

An OLTF of the Moku:Go loop still needs to be taken. Since the loop error point isn't outputted from the Moku (passed direclty between instruments), I'll need to inject an excitation at the control point. When I fed the control signal to input A of the SR560 and tried to lock with the direct output, the lock would repeatedly break. I noticed that the BATT light of the SR560 was on - I'll repeat this with another SR560, but the lock might be breaking due to an offset. Once this is debugged, I can inject an excitation and measure the loop OLTF.

[JC, Paco]

We replaced the HeNe laser for the BS/PRM/SRM Oplev.

After we found a 1103P head replacement in a cabinet along the YARM, JC and I swapped the Oplev laser for BS/PRM/SRM. The head's form factor was the same luckily so we didn't struggle much to recover the QPD signals for BS and PRM. The final alignment aimed to restore ~ 5400 counts in BS (SUM_INMON) and ~ 3100 counts in PRM (SUM_INMON) when aligned.

[Koij Hiroki]

While KA was working on the DAC issue, BS/PRM/SRM Oplev died.

It seems that the BS/PRM/SRM HeNe died and was replaced in 2019 (4yrs + 200 days ago) and 2021 Jan (2yrs + 209 days ago).

We have no energy to work on the HeNe replacement tonight. This needs to be done on Monday.

Tag: OPLEV oplev HeNe died dead

As reported already, we resolved the c1sus DAC0 issue by introducing the differential receivers for the DAC output CHs.

The issue remained in DAC1 (SRM/MC2/MC1/MC3) and DAC2 (All 8 vertex side OSEMs). Their outputs were still received by the single-ended AI boards.
This meant that DAC1 and DAC2 negative side outputs were shorted to ground. This was not great.
(See Attachment 1 for the configuration)

Mitigation

The DAC SCSI-IDC40 adapter units were modified to resolve the issue. This modification was done for the two adapter units among the three.
The modified units were indicated as "DAC Neg out isolated"

These adapter boxes will eventually be removed when we make the transition to the aLIGO electronics. So it's convenient us to touch them.
In the box, the + and - outputs were lined up with a narrow gap. So the modification was a bit cumbersome. The below is the procedure

• First, the solder resist was removed at the corner of the wiring, and copper lines were cut one by one.
• The isolation of the DAC +/-, the isolation of the output sides each other were checked for all the channels.
• Note1: I used a spare PCB found on the workbench for the first modification. I found that one of the left channel (CH9-16) has the output +/- pin connected internally. This would cause + output shorted to the gnd when RevB Ai board is connected. This problem was resolved by cutting one of the IDC40 pin. So don't be surprised if you find one of the pin is missing for the left IDC40 connector for DAC1.
• Note2: One of the + signal line was damaged why the PCB for DAC2 was prepared.

Result

The replacement was done with the watchdogs shutdown. After the replacement, the watchdogs were reloaded and the MC locking were resumed.
I found the apparent behavior of the suspension looked OK but we should keep checking if everything is absolutely fine.

It was surprising that the BS/PRM/SRM OPLEVs lost their spots, but it turned out that it is not related to the electronics work. (See next elog)

[Yuta, Koji, Hiroki]  

Succeeded in locking sideband-resonant PRMI w/ 3f

We worked on the PRMI and achieved the followings:

• Achieved stable lock of carrier-resonant PRMI w/ 1f
  • Lock stretch for ~10min. : 1375235515 - 1375236135
• Succeeded in locking carrier-resonant PRMI w/ 3f
• Succeeded in locking sideband-resonant PRMI w/ 3f

Details

Stable lock of carrier-resonant PRMI w/ 1f:
We tuned the parameters and achieved the stable lock of PRMI w/ 1f:

• MICH:
  AS55_Q (24 dB whitening gain, 2.1 deg demod angle),Power norm. = 0.0008*POPDC sqrt, C1:LSC-MICH_GAIN=0.4,Actuator = 0.5*BS-0.307*PRM
• PRCL:
  REFL11_I (15 dB whitening gain, 32.638 deg demod angle, measued Diff 90),Power norm. = 0.0008*POPDC sqrt,C1:LSC-PRCL_GAIN=-0.0054, Actuator = 1*PRM

The parameters above are added to scripts/LSC/PRMI-AS55_REFL11.yml, so you can import these parameters by pushing the "Actions" button in the LSC window and choosing the PRMI lock.

Time series data of carrier-resonant PRMI lock w/ 1f: 
With the lock conditions above, we locked carrier-resonant PRMI for ~10min.:

• Lock stretch: 1375235515 - 1375236135
• Signal injection for sensing matrix (Notch filters were on):
  • MICH: 211.100 Hz with 1000 counts in amplitude
  • PRCL: 313.310 Hz with 100 counts in amplitude

Rough tuning of demod. angle for REFL33:
We decided to use the REFL33 to lock the carrier-resonant PRMI w/ 3f, so we tuned the demod. angle for REFL33 so that we can obtain MICH and PRCL from REFL33_Q and REFL33_I respectively.
The methods are as follows:

1. Locked the of carrier-resonant PRMI w/ 1f
2. Injected the signal to PRCL @ 313.310 Hz with the amplitude of 100 just the same way as measuring the sensing matrix
3. Observed C1:CAL-SENSMAT_(PRCL,MICH)_REFL33_(I,Q)_AMPMON with ndscope and tuned the demod. angle to minimize the PRCL_REFL33_Q
4. Resulting demod. angle: -20.375 deg (initial: 10 deg)

Gain compensation for locking carrier-resonant PRMI w/ 3f:
To compensate the difference of the gains between 1f lock and 3f lock, we measured the difference of the gains by measuring the transfer function between the error signals in MICH and PRCL:

• MICH: C1:LSC-REFL11_I_ERR / C1:LSC-REFL33_I_ERR (Attachment 1):
  • Signal injection: 211.100 Hz with 1000 counts in amplitude from the function of sensing matrix measurement
  • Gain ~ 3.9, Phase ~ 0 @ 211.100 Hz
• PRCL: C1:LSC-AS55_Q_ERR / C1:LSC-REFL33_Q_ERR (Attachment 2):
  • Signal injection: 313.310 Hz with 100 counts in amplitude from the function of sensing matrix measurement
  • Gain ~ 6.7, Phase ~ 0 deg @313.310 Hz

Fine tuning of demod. angle for REFL33:
We finely tuned the demod. angle for REFL33 as follows:

1. Locked the of carrier-resonant PRMI w/ 1f
2. Injected the signal to PRCL @ 313.310 Hz with the amplitude of 100 just the same way as measuring the sensing matrix
3. Observed the spectrum of C1:LSC-REFL33_(I,Q)_ERR and tuned the demod. angle to minimize the peak @ 313.310 Hz (Attachment 3)
4. Resulting demod. angle: -19.275 deg

Success in locking carrier-resonant PRMI w/ 3f:
Using the result from above and tuning some parameters, we succeeded in locking the carrirer-resonant PRMI w/ 3f.
The conditions are as follows: 

• RFPD InMTRX:
  REFL33_I*6.7 -> PRCL_B, REFL33_Q*3.9 ->MICH_B
• Offset subtraction in DOF Selector:
  PRCL_B: offset=0, MICH_B: offset=37.0 (offset in REFL33 was found when locking MICH with 1f)
• Gains in DOF Selector:
  MICH_A: 0, MICH_B: 1, PRCL_A: 0, PRCL_B: 1
• MICH:
  REFL33_Q (30 dB whitening gain, -19.275 deg demod angle), Power norm. = off, C1:LSC-MICH_GAIN=0.4, boost= off, roll_off= off , Actuator = 0.5*BS-0.307*PRM
• PRCL:
  REFL33_I (30 dB whitening gain, -19.275 deg demod angle), Power norm. = off, C1:LSC-PRCL_GAIN=-0.0054, boost= on ,  Actuator = 1*PRM

Success in locking sideband-resonant PRMI w/ 3f:
We flipped the signs of the error signals and succeeded in locking the sideband-resonant PRMI w/ 3f.
We used POP110 (demod. angle = 178 deg) to check the resonance of the sidebands and to trigger the filters.
Time series data are shown in Attachment 4.
The lock conditions are as follows (also shown in Attachment 5):

• RFPD InMTRX:
  REFL33_I*6.7 -> PRCL_B, REFL33_Q*3.9 ->MICH_B
• Offset subtraction in DOF Selector:
  PRCL_B: offset=0, MICH_B: offset=37.0
• Gains in DOF Selector:
  MICH_A: 0, MICH_B: -1, PRCL_A: 0, PRCL_B: -1
• MICH:
  REFL33_Q ( 30 dB whitening gain, -19.275 deg demod angle), Power norm. = off, C1:LSC-MICH_GAIN=0.4, boost= off, roll_off=off , Actuator = 0.5*BS-0.307*PRM
• PRCL:
  REFL33_I ( 30 dB whitening gain, -19.275 deg demod angle), Power norm. = off, C1:LSC-PRCL_GAIN=-0.0054, boost= on ,  Actuator = 1*PRM
• Trigger:
  POP110_I*2 ⇒ MICH_TRIG ⇒ Threshold upper:200, lower:100
  POP110_I*2 ⇒ PRCL_TRIG ⇒ Threshold upper:200, lower:100
   
• Lock stretch: 1375245020 - 1375245310

We measured the OLTF for PRCL and obtained the UGF of ~ 200Hz, but faied in MICH for low coherence.

The raw frame file is stored in /frames at fb. Before the disk space is flooded, the wiper script deletes the old raw frame files.
I wonder what the state of the wiper script is.

There are wiper scripts (wiper.pl) in /opt/rtcds/caltech/c1/target/fb and /opt/rtcds/caltech/c1/target/daqd, but they no longer seemed to be in use.

I went around the machines and found a service on fb

controls@fb1:~ 0$ sudo systemctl status rts-daq_wiper
● rts-daq_wiper.service - Remove old frame files to reclaim space for the new frame files
   Loaded: loaded (/etc/systemd/system/rts-daq_wiper.service; static; vendor preset: enabled)
   Active: inactive (dead) since Fri 2023-08-04 20:00:27 PDT; 9min ago
  Process: 5355 ExecStart=/opt/rtcds/caltech/c1/scripts/daq_wiper -d /frames -t 2.5 (code=exited, status=0/SUCCESS)

This python version of the wiper script (/opt/rtcds/caltech/c1/scripts/daq_wiper) is running since the last year.
According to the explanation found in the script, the trend data is kept saved, while the raw data is kept deleted to save the specified amount of space (0.25TB it says).
I think this is the configuration we want. So the script was left untouched.

As the preparation of the flow sensor installation, I added two slow channels via c1psl (Acromag IOC).
C1:PEM-HEPA_FLOW_PSL1
C1:PEM-HEPA_FLOW_PSL2

This entry explains how this was done because there is a tricky hidden process that is scarcely explained elsewhere upon adding the slow channels
Tag: How to add slow channels / C0ECDU.ini / Acromag / Advanced LIGO RTS stand-alone EPICS data concentrator

1. Edited the db file

I learned that the spare ADC channels ADC4 CH5 and CH6 are available on c1psl
(See http://nodus.ligo.caltech.edu:8080/40m/[ELOG 17727] )

Created /cvs/cds/caltech/target/c1psl/psl_pem.db

c1psl>cat psl_pem.db
# Greated for Acromag PEM - Koji Arai 2023/8/3
#

grecord(ai,"C1:PEM-HEPA_FLOW_PSL1")
{
        field(DESC,"HEPA Air Flow Speed Monitor Unit 1")
        field(SCAN,".1 second")
    field(DTYP,"asynInt32")
    field(INP,"@asynMask(C1PSL_XT1221_ADC04 5 -16)MODBUS_DATA")
        field(PREC,"3")
        field(LINR,"LINEAR")
        field(EGUF,"10")
        field(EGUL,"-10")
        field(EGU,"Volts")
        field(HOPR,"10")
        field(LOPR,"-10")
        field(ASLO,"1.09225")
}

grecord(ai,"C1:PEM-HEPA_FLOW_PSL2")
{
        field(DESC,"HEPA Air Flow Speed Monitor Unit 2")
        field(SCAN,".1 second")
    field(DTYP,"asynInt32")
    field(INP,"@asynMask(C1PSL_XT1221_ADC04 6 -16)MODBUS_DATA")
        field(PREC,"3")
        field(LINR,"LINEAR")
        field(EGUF,"10")
        field(EGUL,"-10")
        field(EGU,"Volts")
        field(HOPR,"10")
        field(LOPR,"-10")
        field(ASLO,"1.09225")
}

2. Added the db file to cmd file.
Added the following line to /cvs/cds/caltech/target/c1psl/C1_PSL.cmd as

dbLoadDatabase("/cvs/cds/caltech/target/c1psl/psl_pem.db")

3. Restart modbusIOC at c1psl

c1psl>ssh c1psl
controls@c1psl's password:
...
controls@c1psl:~$ sudo systemctl restart modbusIOC.service

4. Added the channels to C0EDCU.ini

Add the following lines to /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini

Leave the first ~20 channels untouched, as they appears on dataviewer as the default channels.

#HEPA Air Flow Mon channels @c1psl

[C1:PEM-HEPA_FLOW_PSL1]
[C1:PEM-HEPA_FLOW_PSL2]

5. Restart fb

telnet fb 8087
Trying 192.168.113...
Connected to fb.martian.
Escape character is '^]'.
daqd> shutdown

6. Ssh into c1sus and run the following command:

This is a new process. Until this is done, the channels are not recorded.

controls@nodus|daq> ssh c1sus

controls@c1sus:~$ sudo systemctl restart rts-edc_c1sus

[Yuta, Hiroki]

Calibrated the actuators after replacing anti-imaging modules.

As shown in elog #17738, the anti-imaging modules for c1sus DAC0 have been replaced with revised ones.
The new gains were predicted to be increased by a factor of 2, so we calibrated the actuators (BS, ITMX, ITMY and PRM) again.
The results showed that the gains have been increased by a factor of ~2 as predicted.

Summary of calibration:
AS55_Q in MICH : 9.2e8 counts/m 

               Results                                 Previous results
BS        : 50.88e-9 /f^2 m/counts      (26.19e-9 /f^2 m/counts from elog #17679)
ITMX    : 9.50e-9 /f^2 m/counts         (5.07e-9 /f^2 m/counts from elog #17679)
ITMY    : 9.75e-9 /f^2 m/counts         (4.80e-9 /f^2 m/counts from elog #17679)
PRM     : -41.40e-9 /f^2 m/counts      (-20.10e-9 /f^2 m/counts from elog #17522)
 

Methods

Calibration of MICH error signal:
To calibrate the MICH error signal (C1:LSC-AS55_Q_ERR), we followed the same free swinging method as elog #17285 and #16929 but used the update code: scripts/CAL/OpticalGain/getOpticalGain.py.
By fitting the X-Y plot of AS55_Q and  ASDC, we obtained 9.2e8 counts/m counts/m (Attachement 1).

Actuator calibration of BS, ITMX and ITMY:
We locked the MICH and measured the transfer function from C1:LSC-(BS,ITMX,ITMY)_IN2 to C1:LSC-AS55_Q_ERR with excitation from C1:LSC-(BS,ITMX,ITMY)_EXC.
By using the optical gain, measured transfer functions were calibrated to the actuator transfer functions of BS, ITMX and ITMY (Attachment 2):
BS        : 50.88e-9 /f^2 m/counts    
ITMX    : 9.50e-9 /f^2 m/counts     
ITMY    : 9.75e-9 /f^2 m/counts    
Diaggui templates: measurements/LSC/MICH/MICH_(BS,ITMX,ITMY)EXC_Template.xml  
Fitting code: scripts/CAL/MICH/MICHActuatorCalibration.ipynb

Actuator calibration of PRM:
We locked PRCL with PRY misalingning ITMX and measured the transfer function from C1:LSC-(ITMY,PRM)_IN2 to C1:LSC-REFL55_I_ERR with the excitation from C1:LSC-(ITMY,PRM)_EXC (Attachment 3).
Then we obtained the ratio between the transfer functions (Attachment 4) and estimated the actuator transfer function of PRM: -41.40e-9 /f^2 m/counts
Diaggui templates: measurement/LSC/PRM/PRY_(ITMY,PRM)EXC_Template.xml
Fitting code: scripts/CAL/PRMI/PRMActuatorCalibration.ipynb​

Balancing the actuation of MICH in PRMI:
Using the obtained results, we updated the output matrix for PRMI locking by revising scripts/LSC/PRMI-AS55_REFL11.yml: 
C1:LSC-OUTPUT_MTRX MICH-PRM: -0.33 -> -0.307

I went to /cvs/cds/caltech/target and found some folders for apparently old targets.
c0daqawg
c0daqctrl
c0dcu1
c1acro
c1dcuepics
c1losepics
c1psl2
epics-gateway

They were tarballed (.tar.gz) and the folders were removed.

I don't know why we have c1auxey and c1auxey1. And it seems that c1auxey1 is the new one???

We should remove some of them from the autoburt request files.

If there is any unexpected error let me know so that I can revert.

Repeating ADC/DAC noise measurements

I carried out the same measurements of the Moku:Go ADC and DAC noise to compare to the results from Ando Lab. Instead of a flat filter with 50dB of gain, I used the uPDH box fitted filter shape. I recorded spectral densities with an SR785; results are in Attachment 1. These measurements are consistent with those measured in Ando Lab. I included the SR785 noise floor, measured by terminating its input.

DAC noise measurement with single-tone input

Next I tried to measure the Moku's DAC noise using its Waveform Generator and Digital Filter Box in multi-instrument mode. I generated a single-tone digital signal and passed it to an elliptic bandstop filter (fit tightly around the tone). The filtered signal was measured by the SR785. I performed this measurement with 1 kHz and 10 kHz tones [Attachement 2]. While the fundamental peak is suppressed, we still see it and its harmonics (not DAC noise). The floor of these measurements is consistent with the DAC noise reference from the first test, and we can say that the Moku:Go's DAC noise above 100 Hz is below 1 µV/rtHz.

Further ADC noise measurements to come.

After the exploration of c1psl, the IMC locking was not functioning well. It looked like the MC autolocker issue.

Now I remember that the autolocker was running on docker. I followed the instruction on the wiki page. https://wiki-40m.ligo.caltech.edu/Computers_andScripts/AlwaysRunningScripts

Remember: Docker is running on optimus / systemctl is running on megatron!

Then: I noticed that MC autolocker heartbeat was blinking even with the docker stopped (!?). I confirmed that autolocker is not running on systemctl

I had no hope who is toggling the heartbeat, but "ps -def" on megatron showed me that "AutoLockMC_LowPower.csh" is running! I was afraid that it is a remnant from vent!? But, is that possible?

The process was killed and the docker locker is running well now.

[JC Koji]
c1vac was hard rebooted. This fixed the PSL shutter issue.

• Checked the Unibritz Shutter Controller for the PSL shutter. It seems that it responds to the NO/NC switch no matter how the REMOTE/LOCAL switch is. (Normal action)
• Checked the BNC input to the shutter controller. There was no trigger/gate or whatever signal from Acromag.
• c1psl reboot did not help
  • Upon this action, a snapshot was taken.
  • Stopped/restarted modbusIOC.services. Did not work.
  • Rebooted c1psl. Didn't work.
• c1psl was shutdown and c1psl acromag chassis was power-cycled. This didn't help. c1psl was burtrestored.
  • Stopped modbusIOC.services. Shutdown c1psl.
  • Power cycled the Acromag chassis.
  • After a while, c1psl was turned on. The epics channels came back.
  • Confirmed modbusIOC.services was running.
  • Burtrestored the snapshot.
• I remembered that the vacuum pressure could make an interlock action on the PSL shutter.
  Found that c1vac values were all whited out. c1vac was not reachable from Martian.
• Went to c1vac and found it was frozen. Pushed hard reset.
• c1vac came back, and it closed the gate valve V1 (main GV for the main vacuum manifold). We opened V1 from the vac control screen.
• Confirmed the PSL shutter is now operational.

BHD platform is estimated to stop baking by the end of the day. We are following the LIGO Procedure and baking at 150°C By tomorrow morning, I will have the platform out of the Air Bake Oven.

· I have began to prepare the smaller components for the assembly for baking. I am trying to get all of these components cleaned and together by the end of next week.

[Yuta, Hiroki]

In preparation for locking the PRFPMI, we tried to lock the sideband-resonant PRMI (but failed) on Aug. 1st:

• Locked PRY. The resulting UGFs were consistent with the previous lock (elog #17521).
• Locked carrier-resonant PRMI with 1f. The resulting UGFs were consistent with the previous lock (elog #17696)
• Tried to lock sideband-resonant PRMI with 1f (REFL55_I for PRCL and _Q for MICH) but failed. This should be due to the large mixed PRCL signal in REFL55_Q.

Next:

• Precisely tune the demod. angle and minimize the PRCL signal in REFL55_Q so that the MICH signal is dominant over the PRCL signal.
• Try locking sideband-resonant PRMI again.

We tried locking PRMI for the first time since we have solved the strange ITMX/Y issue by replacing the anti-imaging modules (elog #17738).
So we started with locking PRY and carrier-resonant PRMI before locking sideband-resonant PRMI.

Locking PRY:
We misaligned ITMX and locked PRY. Locking conditions are as follows:

• MICH​
  REFL55_I (24 dB whitening gain, 76.02 deg demod. angle), C1:LSC-PRCL_GAIN=-0.03, Actuator=
  1*PRM
  -> UGF ~ 200 Hz
   
• PRCL
  REFL11_I (15 dB whitening gain, 32.638 deg demod angle) C1:LSC-PRCL_GAIN=-0.8, Actuator=
  1*PRM
  -> UGF ~ 120 Hz 

These UGFs are consistent with the previous lock (100 Hz for both, elog #17521) taking into account the increased gain (*2) of the anti-imaging modules (elog #17738) and the difference of the whitening gains.

Locking carrier-resonant PRMI:
We succeeded in locking PRMI after restoring ITMX and aligning PRMI. There was nothing strange in this locking.
The locking conditions and the results are as follows:

• MICH
  AS55_Q (24 dB whitening gain, 2.1 deg demod angle), Power norm. = 1*POPDC, C1:LSC-MICH_GAIN=400, Actuator=0.5*BS-0.33*PRM
  -> UGF ~ 50 Hz (consistent with elog #17696)
   
• PRCL
  REFL11_I (15 dB whitening gain, 32.638 deg demod angle), Power norm. = off, C1:LSC-PRCL_GAIN=-0.005, Actuator = 1*PRM
  -> UGF ~ 220 Hz (consistent with elog #17696)
   
• Resulting POPDC: ~1600 at maximum
• Data for noise budget: gpstime 1374968385 - 1374968500

Trials for locking sideband-resonant PRMI:
We calculated the appropriate gains for MICH and PRCL to realize the same UGFs as carrier-resonant PRMI.
Also, we reduced the whitening gain for REFL55_Q to 12 dB as the error signal were saturated at its peak.
We tried locking changing some parameters based on the following conditions but failed:

• MICH
   REFL55_Q (12 dB whitening gain, 76.02 deg demod angle), Power norm. = off, C1:LSC-MICH_GAIN=0.1,Actuator = 0.5*BS-0.33*PRM
   
• PRCL
  REFL55_I (12 dB whitening gain, 76.02 deg demod angle), Power norm. = off, C1:LSC-PRCL_GAIN=-0.0004, Actuator = 1*PRM 
   
• Trigger
  Varied the threshold using the POP110_I (The power of the upper and lower sidebands. In other words, the beatnote between upper and lower sidebands).

This failure should be due to the large mixed PRCL signal in REFL55_Q.
We need to precisely tune the demod. angle and minimize the PRCL signal in REFL55_Q so that the MICH signal is dominant over the PRCL signal.
 

[Yuta, Hiroki]

Remote switching of PSL shutter is not working.

When we tried to reset the LSC offsets, we found that the remote switching of the PSL shutter was not working.
We closed the shutter manually by using the toggle switch on the front panel of the shutter driver (N.C. -> N.O. (Attachment 1)) for the momment.
 

This post is reprinted from the elog of Ando Lab at the University of Tokyo.
[Author: Satoru Takano]

Recently some people are interested in ADC/DAC noise of Moku:GO. I measured them, and found that ADC noise is much larger than expected (quantization error).
I used "PID Controller" module for the measurement of ADC/DAC noise.

DAC Noise

I set up the module as follows:

• Input channel: open, no input
• Output channel: ch1

I took data by data logger DL-750 and calculated PSDs by myself. Measured DAC noise is shown in Fig.1.

I modeled the noise spectrum by:
​

ADC Noise

I set up the module as follows:

• Input channel: ch1, terminated by 50Ω
• Output channel: ch1
• Filter: Flat, 50dB amplification

I took data by data logger DL-750 and calculated PSDs by myself. Measured ADC noise is shown in Fig.2.

I modeled the noise spectrum by:

Comparison with Theoretical Value

I estimated quantization error of ADC/DAC. Specification of the inputs/outputs are as follows:

• Sampling rate: 125 MHz
• Bit number: 12 Bit
• Voltage range: ±5V, 10Vpp

From these specifications, the estimated quantization noise is . I plotted measured noise and this estimation noise in Fig.3.

Comparing with this value,

• DAC noise: the floor level is almost the same as the estimated quantization noise. Below 1.4kHz an additional 1/f noise exists.
• ADC noise: the floor level at 100kHz is about 10 times larger, and at 100Hz about 100 times larger than the estimation. Below 46Hz another 1/f noise exists.

There is a measured data about ADC noise of Moku:Lab at here. Comparing with this, ADC noise of Moku:GO has a stranger shape than that of Moku:Lab.

Summary

If we are using Moku:GO and worried about sensitivities, we should insert some whitening filter before the input of Moku:GO.

This elog post refers to this previous post which details a PRMI lock where the sensing matrix and OLTFs for MICH and PRCL were measured. In addition, I grabbed the time series data during this lock from AS55, REFL11, REFL55, and REFL165 for I and Q demodulations from GPS time 1373763480 - 1373763560. During the lock, the MICH signal was normalized by POPDC, but I confirmed with Koji this didn't affect the data in the channels I used.

Channels I grabbed from:

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

I calculate (what I'm calling)the covariance matrix: COVAR(X) = [CSD(x_i,  x_j)]_i,j where X is the vector of measurements from each sensor and CSD is the cross spectral density. Each element is the CSD between two sensors and the diagonals are the PSD of each sensor. The ASDs of this data is shown in attachement 1.  

Attachement 4 depicts a block diagram I am using to represnt the feedback system. PC includes details of the control filters, actuators and mechanical plant. After this block, n_d represents displacement noise that enters in Y, the state of MICH and PRCL. S is the sensing matrix and M is the input matrix that fuses the sensors. n_s represnts all other noise on the sensors. Based on this model, the measured data form the sensors had this relation to the input noise sources: X = (I+SPCM₀)^-1(Sn_d+n_s), where M₀ is the input matrix used during the lock. COVAR(X) = COVAR( (I+SPCM₀)^-1(Sn_d+n_s) ) =  (I+SPCM₀)^-1COVAR(Sn_d+n_s)((I+SPCM₀)^-1)^H. These transfer functions take linear combinations of the frequency representations of the signals/noises so the PSDs and CSDs of the new signals get new cross terms based on the mixing. This is captured by maping the covariance matrix between the transfer function and its hermitian conjugate. This was used to remove the suppression by the feedback loop by mapping COVAR(X) with (I+SPCM₀). I define COVAR(X)_unsupressed = (I+SPCM₀)COVAR(X)(!+SPCM₀)^H =  (I+SPCM₀)(I+SPCM₀)^-1COVAR(Sn_d+n_s)((I+SPCM₀)^-1)^H(I+SPCM₀)^H  = COVAR(Sn_d + n_s). The ASDs of the unsuppressed noises in each sensor are shown in attachements 2 and 3. In 2, these ASDs are calibrated to meters by multiplying them by the recipricol of the sensing matrix coefficient mapping MICH to that sensor. In 3, the same is done for PRCL.

The theoretical closed loop performance of new M's can be calculated by mapping the COVAR(X)_unsuppressed by the closed loop transfer function for a signal injected at the sensors, X, to the fused sensors, Z. This TF is (I+MSPC)^-1M. Then, from Z the signals are mapped by (MS)^-1 to simulate the new ability to control and sense Y. As before, these transfer functions are used to map the covariance matrix. I define COVAR(Y) = [(MS)^-1 (I+MSPC)^-1M] COVAR(X)_unsuppressed[(MS)^-1 (I+MSPC)^-1M]^H. I have previouly tried using a transfer function from noise injected at the sensors directly to Y, but I don't think this captures the important dynamics since S and M are rectangular matricies. M maps from a vector space with dimension equal to the number of sensors(8 in this case) to dimension equal to the number of DoFs(2 in this case). Previously, I was using S^-1(I+SPCM)^-1 as the transfer function to map COVAR(X)_unsuppressed --> COVAR(Y) where S^-1 is the Moore-Penrose inverse of S. At low frequencies I think this can be equivalent for a class of M's, but all M dependence goes away for high frequencies when PC --> 0. On the other hand, we expect M to be very important at high frequencies since it determines what sensing noise enters the system. 

Attachements 5 and 6 show the theoretical ASD for MICH and PRCL with several choices of M as well as the open loop noise. These correspond to the square root of the diagonal elements of COVAR(Y). The M₀ curve shows the performance of the lock in which the data was taken. The calculation for this is the same as described above but M₀ was chosen to select AS55_Q for MICH and REFL11_I for PRCL. The MS=G₀ data was calculated by starting with the Moore-Penrose inverse of S, so that MS is diagonal, and scaling the rows to have the same MICH and PRCL gain as M₀. The top row of S^-1 was scaled by the MICH --> AS55_Q sensing matrix element and the bottom row by the PRCL --> REFL11_I sensing matrix element. The last matrix shown, MS=G_0 w/ noise fit is subject to the MS=G_0 constraint just described, but it was also fit to reduce noise entering the system at high frequencies. Above 1KHz, the noise is pretty white in all sensors. The ASDs for 1KHz to just below the cutoff frequency are shown in attachment 8. For these range of frequencies I used M*COVAR(X)_unsuppressed*M^H as a cost function to approximate the open loop sensing noise entering the fused sensors. I used scipy.optimize.minimize() to optimize M for this cost function with repsect to the MS=G_0 constraint that I assumed would be crucial for decent closed loop performance at low frequencie. This optimization was done at every frequency step, but the result was unsuprisingly pretty constant over the chosen frequency range so I averaged the elements of the matrix to make a constant matrix. This matrix is used to calculate the MS=G_0 w/ noise fit data.

Both matrices suggested show improvements in these calculations. The both rely on the sensing matrix, which has large uncertainties and is assumed to be frequency independent which may strongly hinder their performance in the real PRMI LSC system.

The matrices are given below. The order of the channel names above determines the order of the coefficients along each row. 

MS=G_0 matrix:
[ 0.06554358  0.89041025 -0.02285036 -0.08922597  0.0720552   0.00681149 -0.24507124 -0.15858639]
[  4.0546419   55.0763957   -0.46854116  -5.7461138    4.48030295 0.4226362  -15.15734417  -9.809963  ]
MS=G_0 w/ noise fit
[ 0.20865055  0.194148   -1.70063937 -7.07367426  0.04610331 -0.01614077 -0.10858281 -0.06099116]
[  12.91008472   12.00303754 -104.26878095 -437.86044383    2.82103162 -0.99588645   -6.71642619   -3.77348024]

Update

1. I have finished setting up Neptune for easy access to the train/eval metrics of the RL models. Here is a link where you can track my progress. Neptune is an extremely useful tool that allows you to see in real time how the models are bahving: you can see nice plots of losses and returns, as well as my source code, the stdout and stderr, and even the resources plots for the node that my jobs got allocated to. Feel free to play around with it.
2. Currently, there are are only 2 runs (I just started them): one with DQN (RLCON-8), the other with PPO (RLCON-7).
3. As outlined before, I have tried improving the PPO agent by replacing the replay buffer with a reverb server (which is supposed to be the fast way of doing a replay buffer). However, no big speed ups have been achieved. The problem is that PPO is using a special type of layer: a distributional layer. I am unsure as to how this layer works, but certainly it is not a normal "dense" layer. After changing all other components, it seems that the PPO algorithm is very slow not because of the replay as I initially thought, but because of the actual training of the agent at line agent.train(experience).  However, I still have a lead: there is an error signal about tensorflow retracing (see run RLCON-8). I am now looking into that.
4. In the mean time, I will start increasing the size of the Q-net for the DQN and increasing the num_actions to 201 (so a resolution of 0.5% in duty cycle). That is because RLCON-7 seems to not learn too much: the loss is really unstable and the evaluation avg_return is terrible.

Aside on avg_return if you wonder what this number means: basically, at each step of the environment (the code that simulates the temperature of the puck) I am takig the error to be . Then, for an entire episode, the reward is given by the average of these errors (so it gives you average error for all steps in one episode). Then, the reported avg_return is calculated by taking the mean of average errors for 5 (as of now) episodes. Basically, sqrt(|avg_return|) gives you an average deviation away from T_ref: so if avg_return=-25, then you should expect the model to be consistently around 5 degrees away from T_ref.

Mode-matching breadboard has been constructed

I have constructed the mode-matching breadboard for aligning the BHD OMCs.
I also measured the profile of the resulting beam:

Beam waist X: 496 +/- 2 um
Beam waist Y: 504 +/- 3 um
Waist position X (from the front surface of the collimator mount): 224 +/- 1 cm
Waist position Y (from the front surface of the collimator mount): 236 +/- 2 cm
Maximum mode-matching efficiency to OMC: 99.78 +/- 0.07 % (if the waist of the OMC eigen mode is place at 230 cm)
(OMC eigen mode: 489.6 um (horizontal), 490.5 um (veritical))

The details are shown in the following attachments:

• Attachment 1: Current configuration and summary of beam profile
• Attachment 2: Resulting beam profile
• Attachment 3: Photo of mode-matching bread board

[Hiroki, Yehonathan, Yuta, Koji]

Summary

• The c1sus DAC0 issue seemed to be the driving capability of the DAC card.
• The DAC issue was solved by replacing 2x Anti-Imaging modules (D000186 RevB) with 2x Rev C equipped with input amps.
• This may mean that the previous DAC card failure was also the same issue. (i.e. The card could still be OK)
   
• This change may have increased the coil driver responses of the vertex suspensions by a factor of 2
  as the conventional RevB had the single-end inputs, but Rev C has the differential ones.
   
• Enabling the full actuation range caused significant misalignment of the suspensions. But the IFO was realigned and now looks much more normal than before.
  • The ITMX OPLEV servos could be engaged with the conventional gain. No instability is observed anymore.
  • The BS OPLEV gains were too high. |G|=0.4 -> 0.2 to maintain stability.
  • Confirmed Yarm ASS functioning well as before
  • Xarm ASS is partially functioning as before. Some gains were reduced to keep the stability, but still, careful inspection is necessary.

Details

• The monitor outputs of the Anti Anti-Imaging modules (D000186 RevB) were checked while the corresponding coil EXC channels were excited via awggui.
• When the DAC was fully driven, we observed the output was only limited to the negative side of the full scale. The negative side was clipped at -5V. (See Attachment 1). This was the case for all 16 channels for DAC0. We found no issue for DAC1 and DAC2.
• Disconnect the DAC0 SCSI cable from the SCSI-IDC40 adapter unit to isolate the DAC from the analog chain. Could we observe the bipolar signal? Indeed yes, we saw the bipolar signal. (Attachment 2). (We use a SCSI-DSUB9 adapter board.)
• We wondered if this was the failure of the AI modules. Replacing the left D000186 with the same Rev B spare. No change.
• Checked if power cycling the AI module reset it. As this was done with the DAC connected, we lost positive and negative outputs of the DAC (OMG!)
• Rebooting c1sus solved the issue, and indeed the DAC exhibited a bipolar signal even with the Rev B cards.
• We thought we solved the issue! Came back to the control room and worked on a boot fest. After about an hour of struggle, all the RTS are back online. (GJ!)
• But we found that we are back to the original state. (same as Attachment 1)

Some break ....

• Went back to the rack. My thought was that the DAC could work when it was not connected to the AI modules. Once it is connected to the AI modules, the positive side disappears. Probably can't DAC drive all the load?
• Disconnected the 2nd IDC40 cable from the adapter (i.e., 2nd AI isolated). This brings the bipolar signals back! (Attachment 3)
• If the 1st IDC40 was this connected while the 2nd cable was connected, this brings the bipolar signals back to the later half 8chs (Attachment 4)
   
• We have a couple of D000186 Rev C spares. I checked the circuit diagram of Rev C (it is not on DCC but in Jay's circuit diagram archive on 40m BOX). I found that each channel of Rev C has an INA134. This is not a true instrumentation amplifier but a differential amplifier with R=25kOhm. So it was promising.
• Indeed, replacing a RevB with a RevC already solved the issue. Just in case, I've replaced both RevBs for DAC0.

• I wondered what the input impedance of RevB was. The Frequency Devices Filter module has the min input impedance of 10kOhm. However, the Rev B input is single-ended. I believe the negative side is shorted to GND! This probably mean that the gain with Rev C is x2 of the conventional one
   
• IFO alignment / locking / oplev test: as described at the summary.

[JC]
I began to prepare the temporary clean room where we will be putting together the BHD Platform Assembly - D2100085. I wiped down the table with the Acetone and IPA multiple times. After this, I used Mylar sheets to use as the cleanroom walls. I slit the sheet into separate pieces to allow easy access and held these sheets up by using Kapton tape. Next, I connected the HEPA booth to an extension cord which was plugged into the Wall outlet of 1X3. 

I did the same test we did in 40m/17616 to see if DACs are working fine for ITMX and ITMY.
I used awggui to excite all the coil outputs of the optic with 0.1 Hz with an amplitude of 3000 counts, and checked VMons.
Found that ITMX, ITMY, PRM and BS face coil DAC outputs cannot drive positive voltages. In contrast, SRM is fine (see attached).
This is consistent with what we have found in June (40m/17616).
We need to investigate what is causing this DAC failure...

[Maty, JC]
This morning, Maty and I proceeded to work on the BHD Platform work. We rinsed off the BHD platform one more time with water and placed onto the work bench. Here, we wiped down using IPA and removed a ton of the metal shavings from the platform. (Attachment #2 & #3 ) The threads in the platform had a ton of shaving, but we were able to get majority, if not all, off the part. 

Next, we garbed up and prepared the large tub for the BHD Platform. The tub contained 107 L of water, so we added 1000 mL of Liquinox into the tub. The Platform was a bit too wide, so we had to put it in at an angle. We used a beaker to pour the solution over all of the part. Along with this, we used the Sonicating probe to clean the threads. ( Attachment #3 ) We did this for the entire part and then drained the tub. 

I lifted and placed the platform into the blue machine parts washer to rinse off the part. We went thread by thread to make sure all of the Liquinox was rinsed off of the part, this to ~30 minutes. ( Attachment #4 )After rinsing the part off, we brought it over to the clean room flow bench. Here, Maty placed large clothes under to platform. She then went through each hole of the platform with the TopGun to remove the loose excess water. ( Attachement #5 )

We have stopped here and are leaving the BHD Platform to dry overnight. We will insert the BHD Platform into the Large Air Bake Oven TOMORROW! We plan to have it ready by the end of the week. 

I had a suspicion that some of the ITMX coils were not properly working. So individual coils of the 4 test masses were excited while the arm-locking servo output was observed.

The servo output of the arm locking (denoted as ) can be expressed as:

,

where G is the open loop TF, A is the actuator TF, and dx is the displacement noise of the FP arm.
When the arm is shaken with a coil, dx is A' dv where A' is the actuator TF of the coil in question, and dv is the applied excitation.

i.e.

If the length coupling of the coil is all identical, A' is expected to be A/4 and this TF should be ~1/4 well below the control bandwidth.

For ETMs the TFs were close to 1/4 and all the phases were the same, although I could not understand why the gain goes down at low frequency.
This needs more careful thinking. But at least the TF were close to identical between the coils.

However, the situation is different for the ITMs:
- ITMX LL and LR seemed OK. However, the UL response was too low (by ~1/25) and the UR response had an opposite phase.
- ITMY LL and LR seemed OK. However, the UL and UR responses were too low (by ~1/25)

We want to check if the CDS is behaving properly, or this is the electronics issue.

[Koji, Hiroki]

We investigated the cause of the unstable OPLEV damping in ITMX and found some clues.
 

Transfer functions from coils to OPLEVs:

We measured the transfer functions from the OSEM coils (UL, UR, LR, LL) to the OPLEV sensors (PIT, YAW) for ITMX, ITMY, ETMX and ETMY under the condition of OSEM damping.
Attachment 1 shows the transfer function from the ITMX UR coil to the ITMX OPLEV as an example.
We compared the obtained transfer functions at 10Hz: 

COIL    OL     Response @10 Hz [dB]
                      ITMX    ITMY    ETMX    ETMY
LL       PIT      -78      -93*      -87       -52
LL       YAW    -72      -97*      -87       -50
LR      PIT      -93*     -94*      -88       -53
LR      YAW    -70      -94*      -84       -46
UL      PIT      -73      -65       -91        -46
UL      YAW    -73      -65       -87        -50
UR     PIT       -91*    -63       -87        -53
UR     YAW     -73     -63       -87        -52

Noteworthy poinsts:

• For ITMY, responses from LL and LR are small compared to UL and UR. Something wrong with LL and LR?
• For ITMX, responses from LR and UR to PIT are small. I wonder why the responses to PIT are different from that to YAW.
   

OLTF of OPLEV servo for ITMX PIT:

We measured the OLTF of the OPLEV servo for ITMX PIT with the condition of only OSEM damping (OPLEV servo loop was disconnected during the measurement).
Attachment 2 shows the modelled OLTF and Attachment 3 shows the measured OLTF.
We found some structure and its huge phase delay around 1 Hz. This structure seems to be affecting the stability of ITMX OPLEV servo.

The shape of this structure changed with diffrent OLTF gain of ITMX POS for some reason.

We tried to avoid this structure by increasing the gain of OPLEV servo (0.2 -> ~40).
As a result, the movement of the OPLEV beam spot was stabilized but ITMX POS got noisy (large fringing at AS).

BHD Platform has been washed and set to dry over the weekend
 

Yesterday, I began to wipe down the BHD platform in the C&B lab. While I was cleaning, I wanted to be very particulate of how clean it was here because of how long it was sitting in Don’s office. There was dust that was built up in the crevasses of the underside of the platform and it was be difficult to get out. I spent ~30 min clean and I felt like I was better off washing the entire piece. 

I contacted Maty and this morning we decided to place the platform inside the Machine Washer. We had to remove the 2 basket and shelves in order to fit the Platform inside. We decided to stand the platform vertically as shown in Attachment #1 and hold in place using Zipties. After a few soft tugs on the platform, Matt and I agreed that it was pretty secure. We started the parts washer and ran it for 10 minutes. The Machine washer was set to use water at 120°F. 

After the machine washer was done, Maty removed the platform from the machine and we were rinsed of using water. 

What’s next ? 

We agreed to leave the platform to dry over the weekend. This will set us back a day, but we did not want to insert to platform to be baked while it was still wet. We left the platform under the vent to dry over the weekend.
 

I added a heater circuit to the seismometer, and moved the 4 channel temperature readout circuit that I built in there as well. The heater uses the lowermost power supply available on the 1x9 rack, visible below reading 24V -

• It was turned off prior to my using it, and there is no current drawn when I'm not using it - so I think it is not connected to any other device. I mentioned how I added DIN fuses to complete the circuit in another elog.
• The heater circuit is simply a MOSFET being operated as a switch, with a 2x scaled version of the DAC signal being fed into the gate, letting current through when the DAC is at 4.6V (30000 counts).
• The resistance of the heating pads is 13 ohms. This means we can achieve a max power of roughly 44W, which is delivered to the can that weighs 15 kg.

I also interfaced the temperature sensors to the BNCs we laid earlier, enabling readout through EPICS. This let us do a step response test where I heated the can for 4 hours and let it cool after that, letting us observe the temperature profiles - 

This plot is a lot noisier than the ones we got through the RPi ADC for the puck, and we think this is due to the EPICS system being worse. The noise is initially absolutely terrible, and then suddenly improves after around 1.5 hours. We are not sure what would cause this behaviour and will have to investigate.

The code for this is available at /users/Mayank/step.py

Even though the noise issue of an OSEM was resolved, the issue with ITMX still continues.
OPLEV pitch servo can't be turned on as it induces the suspension running. So there is something systematically wrong with the suspension.

This requires some checking of the whitening / dewhitening situation, or even other unknown cause.

[Koji, Hiroki]

We resotred the noisy ITMX UL sensor reported in elog #17713

Based on Koji's experience, we checked the cables from ITMX sensors and pressed their connectors (Attachment 1).

We confirmed that the noise spectrum of the ITMX UL sensor was improved (Attachment 2: measuered w/o damping) but we do not know the exact connector that had been affecting the spectrum.

Here is the OLTF from the model of the system I made in Python. https://github.com/CaltechExperimentalGravity/LaserStabilization/blob/main/code/PlantSim/plant_model.py

With this model, I should be able to plug in potential optimal controllers and see how the OLTF might improve. The green line shows the OLTF of the model with the PDH box zpk values inputted into the Mokus, which in turn was eyeball fitted to the analog uPDH box frequuncy response. 

In hindsight I realise I have made a mistake that could explain the discrepancy in data between the Mokus. I forgot to account for the difference in sampling rate of either Mokus while making the SOS filter file. I used the same file, one that had the Moku:Gos sampling rate for both devices. Using the correct sampling rate could solve the large delta in phase, and minor changes made to the model for better estimation of the Mokus response.

I looked at the Acromag situation of c1psl to prepare for the PSL air flow speed sensor.
Someone clever did a great job of binding all the spare channels into DB37s.

The pin-outs and channel assignments are all listed in a Google spreadsheet. The link can be found on the following wiki page.

https://wiki-40m.ligo.caltech.edu/CDS/SlowControls/c1psl (Click "Feedthrough wiring with test status")

According to the spreadsheet, we are supposed to have

• 14 DAC CHs
• 14 ADC channels
• 15 sinking BIO channels
• 12 sourcing BIO channels

For now, we can hook up the sensors via a DB37 breakout or even just a connector. If we have many cables coming in the future, we can make a breakout 1U unit.

Here is a rundown of my work so far on RL controllers for the puck:

Environment: I implemented an environment that simulates the puck's temperature, according to our crude fits of the step response and pid controller of the puck in foam. Currently, this environment assumes constant ambient temperature and doesn't simualte the delays between the applied heat and the measured temperature change. However, one can easily adjust this environment by just changing the underlying Tdot equation. The environment works in steps of 10s and executes 3600*5 steps (for a total simulated time of 50h). The reward function is L2: at every timestep, it adds -(T_puck - T_ref)^2 to the total reward. The reward is only disclosed to the agent on the last timstep, so far this seemed to have work better, perhaps because the reward you get at any timestep is heavily dependent on the previous state (in 10s you can't raise the temperature enough if you are 5 degrees away from T_ref, so the agent gets penalized again).

Agents: I have made the first implementations for two agents: DQN and PPO, that could be used to controller the puck's temperature. Currently, these implementations are rough and require hyperparameter tuning and bigger networks.

• PPO: this agent works on continuous environemnts, meaning that it outputs any real number between min and max as its action. In the case of the puck, the action is the applied heat (in Watts). However, this agent has proven very slow to train on the LIGO-Caltech cluster (despite the networks being very small: 3 dense layers, 2->10->5->output for both critic and policy networks), so I only have a very rough training done, of 20 episodes Here is a plot:
  
  Here T_ref is represented by the red line and the blue line is the output bahvior of the policy. Keep in mind that this is only 20 episodes, and at the time of writing the training was killed (don't know why) but the measured total reward at 25 episodes was around 10% better than the above policy (sadly, no plot for that).
• DQN: this agent works on discrete environments, meaning that I had to modify the training environment to be dsicrete (which can be done in 1 line of code using a wrapper, see env.ipynb). There is an argument to be made that the actuator (in our case the PWM of the Raspberry Pi) has only a limited number of possible outputs: for example, the RPi PWM doesn't produce any measureable difference in duty cycles that differ by less than 0.05%. As Rana suggested, it would be best to discretize according to the number of bits that the plant can work with (I am not sure how many that is for the case of the RPi). Anyways, I am currently training the DQN on the env discretized to 100 actions, but it currently seems very unstable, even after I lowered the learning rate. The great thing about DQN is that it has been very fast to train, even on a cpu. Hence, I think the next step would be to just increase the size of the q-network, as the currrent 3 dense layers seems inadequate (2->10->5->100). I will come back with a better plot of this agent very soon.

Moving on, I want to:

1. Implement a reverb replay server for the PPO in hopes that it will speed up the training
2. Add T_env noise and sensor noise simulations to the environment.
3. Start hyperparameter tuning
4. Check results and compare with lthe inear controller

As we move towards the goal of controlling the temperature of the seismometer near the X end, I am setting up hardware and interfaces to provide sensor readout and heater control there.

Seismometer temperature sensor configuration:

• Yesterday night I removed the foam-insulated can off the seismometer to attach AD590 temperature sensors (we are using the TO-52 package).
• I attached one to curved surface of the can and another to the seismometer inside :

• The wires go through a hole in the concrete base and are long enough to reach the top of the whole enclosure. In the image of the can, the thick red wires to the right lead to the heater (a parallel combination of two resistances, which I measured to be 12.9 ohms), while the sensor is on the left. 
• I've used duct tape to secure the sensors, and ensured there is good contact and it doesn't wobble around. The wires are also taped down so that the sensor doesn't move a lot if someone tugs them.

There was already an older sensor attached to the seismometer, presumably from 5 years ago when Kira was working on this. This one used the 8-pin SOIC package, and in our experience it was hard to achieve and maintain good contact with this variety of the sensor because of the awkward shape, so this sensor was replaced. The new sensor circuit also has pin headers for connection, unlike the old one where the sensor was permanently soldered to a board.

Wow, this is awesome. Can you plot the comparison between the measured and expected OLTFs for both (or either) Moku cases?
At low freq, the measurement of OLTFs gets difficult due to high loop suppression and the estimation will give us an idea of how the loop can be improved.

I almost finished constructing the mode-matching breadboard today.

What I did on July 26th:

• Constructed the mode-matching telescope on a breadboard (Attachment  1).
  • Height of optical axis: 3.5" (from the bottom of the breadboard)
  • Used two lenses of f = 200 mm @ ~6 cm and ~24 cm from the surface of the collimator mount
    (Used JamMt to obtain the solution)
  • Tuned the position of the two lenses monitoring the resulting beam waist so that the waist becomes ~ 500 um
    (OMC eigen mode: 489.6 um (horizontal), 490.5 um (veritical))

Next:

• Measure the dimensions of the resulting mode-matching telescope
• Measure the beam profile of the resulting beam
• Estimate the upper limit of the mode-matching efficiency to the OMC

Supplementary

Output beam profile from collimator:
I measured the beam profile of the output from the collimator (Attachment 2).

Beam waist X: 44.3 +/- 0.5 um
Beam waist Y: 46.1 +/- 0.6 um
Waist position X (from the front surface of the collimator mount): 1.64 +/- 0.04 cm
Waist position Y (from the front surface of the collimator mount): 1.70 +/- 0.05 cm

I found that the resulting beam is not collimated but focused.
The model number is not written on the collimator so I was not able to find its specification.