k1cam2 had been installed as a tertiary and a new version of GigE camera server (klog#33113. But the previous hardware was poor CPU power and it wasn't able to operate only 3 GigE cameras (larger than as 12 CPU load for 6C/6T). So I replaced k1cam2 hardware in this time as a new and a more powerful one (8C/16T).
k1cam2 with the new hardware can operate 3 GigE cameras with ~5 as CPU load for 8C/16T. Though the situation was improved, it's not enough to move all GigE cameras to k1cam2. After this work, I noticed CPU cores are running as ~0.8-1.2GHz. On the other hand, this CPU should work 3.2GHz according to the specification sheet. So we need to check BIOS settings of power saving mode. This work will be done in next Thursday.
KAGRA Pcal-Y updates (2026/01/20)
Workers: Dan Chen, Misato Onishi
We performed monthly Pcal-Y calibration on 2026/01/20.
After the calibration, we updated EPICS parameters related to the Pcal-Y system. No issues were found.
| EPICS Key | Before | After | Δ (After − Before) |
|---|---|---|---|
| K1:CAL-PCAL_EY_1_OE_R_SET | 0.99001 | 0.98973 | -0.00028 |
| K1:CAL-PCAL_EY_1_OE_T_SET | 0.99001 | 0.98973 | -0.00028 |
| K1:CAL-PCAL_EY_1_PD_BG_RX_V_SET | -0.00483 | -0.00484 | -0.00001 |
| K1:CAL-PCAL_EY_1_PD_BG_TX_V_SET | 0.02263 | 0.02704 | 0.00441 |
| K1:CAL-PCAL_EY_1_RX_V_R_SET | 0.50319 | 0.50319 | 0.00001 |
| K1:CAL-PCAL_EY_2_INJ_V_GAIN | 0.51359 | 0.51512 | 0.00153 |
| K1:CAL-PCAL_EY_2_OE_R_SET | 0.98589 | 0.98618 | 0.00029 |
| K1:CAL-PCAL_EY_2_OE_T_SET | 0.98589 | 0.98618 | 0.00029 |
| K1:CAL-PCAL_EY_2_PD_BG_TX_V_SET | 0.02549 | 0.02955 | 0.00406 |
| K1:CAL-PCAL_EY_2_RX_V_R_SET | 0.49681 | 0.49681 | -0.00001 |
| K1:CAL-PCAL_EY_WSK_PER_RX_SET | 1.84186 | 1.84214 | 0.00028 |
| K1:CAL-PCAL_EY_WSK_PER_TX1_SET | 0.33344 | 0.33376 | 0.00032 |
| K1:CAL-PCAL_EY_WSK_PER_TX2_SET | 0.90362 | 0.90500 | 0.00138 |
In case of the REFL_HWP=155 with PRFPMI_1F RF locked, the UGF was about 8 kHz as shown in Fig.1.
Then I rotated the REFL_HWP (=135), the UGF changed to about 30 kHz, but even we rotated the HPW more, the UGF didn't change.
So I changed the IN1 gain for CARM CMS from -24 dB to -21 dB, the UGF became about 40 kHz (Fig.2.)
After discussion with Ushiba-san, we decided to change it in the Increase CARM_GAIN
L2063
self.gain = -21 #-21
CMS_CARM.gain('IN1',self.gain)
MICH : increased the 1.792 dB from reference, so I will add the -1.792 to FM2 in MICH2 filter bank
PRCL : reference was too old (Komori-san's update for PRCL control), I modified the reference (2025/11/04) (Fig.1.)
increased the 2.095 dB from reference, so I will add the -2.095 to FM3 in PRCL1 filter bank
Next, investigation of the CARM gain with
LSC_LOCK guardian set PRFPMI_LOCKD_WITH_3F
request VERTEX guardian to PRMI_LOCKED
(before the rotation, we want to measure the CARM OLTF)
Then, set the threshold for the LSC-REFL_PDA1_DC_OUTPUT (L2043 LSC_LOCK guardian)
After the ENGAGE_WFSDC, locked loss frequently detected and lock duration ~100 s or shorter.
So, I checked the signals soon before the locked loss
Lock loss lists and guardian comment:
# 231 2026-01-19 22:57:33.437500 UTC ( 218s) [] ENGAGE_WFSDC 1452898671.4375
2026-01-19_22:57:33.516477Z LSC_LOCK [ENGAGE_WFSDC.run] USERMSG 0: IMC seems to be unlocked
# 232 2026-01-19 23:25:25.187500 UTC ( 92s) [] ENGAGE_WFSDC 1452900343.1875
2026-01-19_23:25:25.280429Z LSC_LOCK [ENGAGE_WFSDC.run] USERMSG 0: IMC seems to be unlocked
# 233 2026-01-19 23:39:56.312500 UTC ( 84s) [] ENGAGE_WFSDC 1452901214.3125
2026-01-19_23:39:56.383435Z LSC_LOCK [ENGAGE_WFSDC.run] USERMSG 0: IMC seems to be unlocked
# 234 2026-01-19 23:49:32.437500 UTC ( 12s) [] ENGAGE_WFSDC 1452901790.4375
026-01-19_23:49:32.521874Z LSC_LOCK [ENGAGE_WFSDC.run] USERMSG 0: PRMI seems to be unlocked
# 235 2026-01-20 00:09:21.937500 UTC ( 416s) [] ENGAGE_WFSDC 1452902979.9375
2026-01-20_00:09:22.018153Z LSC_LOCK [ENGAGE_WFSDC.run] USERMSG 0: IMC seems to be unlocked
# 236 2026-01-20 00:15:15.937500 UTC ( 2s) [] ENGAGE_WFSDC 1452903333.9375
026-01-20_00:15:16.027489Z LSC_LOCK [ENGAGE_WFSDC.run] USERMSG 0: IMC seems to be unlocked
Mostly, IMC or PMC locked loss made the IFO lock loss.
I checked the signal one by one and found that the
MCL controls signals
K1:IMC-DOF4_P_IN1_DQ
had several glitches near the locked loss (Fig.1.)
I checked the IMC ASC DOF4 P signal and I found the saturation of output(Fig.2.) and it happened 21 days ago.
I could not conclude it would be the locked loss reason, but
Could someone offload this PZT control?
[Ushiba, Washimi]
We tuned the Y4 filter more (decrease gain, bandwidth 10%->30%)
We checked the status of the WFS DC controls for the PRFPMI.
Before checking it, I tuned the alignment of ETMY with checking the gigE camera image of the AS.
Fig.1. : TMSX IR QPD
very far from center, we need to touch.
Fig.2. : TMSY IR QPD
Not bad, soso
Fig.3. - Fig.8.
REFL, POP, AS DC controls for WFS, they seemed fine, and DC control didn't saturated.
With Yokozawa-san
We performed initial alignment.
With Yokozawa-san
We offloaded ITMY MN because the MN coiloutf signals were saturating.
We used the moving mass for P and BF SET filters Y for Y
A CAL Tcam session was performed to obtain beam position information necessary for Pcal. The parameters have already been updated, and SDF at safe state has been accepted.
Operator: Dan Chen
Update Time: 2026/01/20 06:10:12
| EPICS Key | Before [mm] | After [mm] | Δ (After - Before) [mm] |
|---|---|---|---|
| K1:CAL-PCAL_EX_TCAM_PATH1_X | 0.45668 mm | 0.07325 mm | -0.38343 mm |
| K1:CAL-PCAL_EX_TCAM_PATH1_Y | 67.54717 mm | 66.15693 mm | -1.39024 mm |
| K1:CAL-PCAL_EX_TCAM_PATH2_X | 0.21250 mm | 0.56752 mm | +0.35502 mm |
| K1:CAL-PCAL_EX_TCAM_PATH2_Y | -63.32961 mm | -68.50339 mm | -5.17378 mm |
Update Time: 2026/01/20 06:12:05
| EPICS Key | Before [mm] | After [mm] | Δ (After - Before) [mm] |
|---|---|---|---|
| K1:CAL-PCAL_EY_TCAM_PATH1_X | 0.66534 mm | 1.33223 mm | +0.66689 mm |
| K1:CAL-PCAL_EY_TCAM_PATH1_Y | 65.06913 mm | 65.85923 mm | +0.79010 mm |
| K1:CAL-PCAL_EY_TCAM_PATH2_X | -1.14349 mm | -0.29757 mm | +0.84592 mm |
| K1:CAL-PCAL_EY_TCAM_PATH2_Y | -69.90162 mm | -69.75503 mm | +0.14659 mm |
I checked the transfer function and found damping didn't work as shown in Fig.1.
(blue : Jul 2024, green : Washimi-san tuned, red : this morning)
After reducing the gain to 1/10, the transfer function became healthy as shown in Fig.2.
There are possibility to have overdamping.
I modified the foton FM1
For some filters, the coefficients were not loaded. So I measured the OLG again (and also tuned again):
L3, L5, T2, T3, V1, Y2, Y3, Y4
Now the coefficient differences are not remain.
After the modification, I found that ETMX cannot be damped well for a long time when the suspension was kicked due to the lockloss (fig1).
Figure 2 shows the enlarged view of oscillation, which is at 1.67 Hz.
Since 1.67 Hz is close to 2nd mode of yaw and NBDAMP_L5 frequency, I checked both of them.
First, I checked MN_MNOLDAMP_Y loop to confirm the yaw loop is fine.
Figure 3 shows the OLTF of MN_MNOLDAMP_Y loop with Y1 and Y2 NBDAMP, which seems fine.
Note that MNOLDAMP_Y is designed to damp only 1st (0.3Hz) and 2nd (1.7Hz) resonances, so NBDAMP for 3rd (3.1Hz) and MNR(4.1Hz) should be turned on during the measurement to avoid kicking the resonance at high frequency.
Then, I measured OLTF of NBDAMP_L5 (fig4), which damps 1.67Hz longitudinal mode of Type-A tower.
During the measurement, I turned on MN_MNOLDAMP_Y and NBDAMP_{Y1,Y2} to avoid kicking the yaw resonances.
Since the resonant frequency of 2nd mode of yaw and tower longitudinal mode are very close, the yaw resonance is growing up during the measurement if there is no yaw damping.
This might be the reason of large peaking reported in klog36109.
Anyway, the OLTF of NBDAMP_L5 also seems fine, so I modified the ETMX guardian so that NBDAMP_L5 is engaged at LOCK_ACQUISITION state and disengaged at CARM_DOWN state (fig5 and fig6).
We performed the initial alignment for the Xarm, Yarm, OMC, and PRMI.
Xarm, Yarm, and OMC were done by the Guardian automatically, but for the PRMI, a manual tuning of the PRM pitch by Ushiba-san was necessary.
RECODE_GOOD_VALUES has been done.
We are checking why the ETMX suspsneion went to TRIPPED stat.
We found that the MN COILOUTF outputs gave high signal just before the state change.
(There was not earthquack observed.)
I found this L5 filter which is not used in the main pass was set to be ON in ENGAGE_RAPIDDAMP state.
So I comment-outed this line in the guardian.
Then, the ETMX suspension could reach the LOCK_AQUISITION state.
The error was at the CLOSE_MASTERSWITCH state.
While investigating the system in the situation, I found the NBDAMP L5 was ON.
After manually turing it OFF, the suspension was able to reach the SAFE state.
We need to check why the L5 was turned ON (while the state transition?).
After that, the suspension can not reach SAFE state as the guardian gives errors saying BF_COILOUTFs have outputs. (fig1)
It seems they have provided the very hight values from around 1/17 20:20. (They are still high values now.)
The TM oplev values are still oscilating.(fig2)
The ETMX have tripped around 3:50 on Jan 18.
It seemed MN H3 triged the tripped.
As the value was much lower than the trigged point, I reseted the WD.
There was not any earthquakes on the time?
After that, the suspension can not reach SAFE state as the guardian gives errors saying BF_COILOUTFs have outputs. (fig1)
It seems they have provided the very hight values from around 1/17 20:20. (They are still high values now.)
The TM oplev values are still oscilating.(fig2)
The error was at the CLOSE_MASTERSWITCH state.
While investigating the system in the situation, I found the NBDAMP L5 was ON.
After manually turing it OFF, the suspension was able to reach the SAFE state.
We need to check why the L5 was turned ON (while the state transition?).
I found this L5 filter which is not used in the main pass was set to be ON in ENGAGE_RAPIDDAMP state.
So I comment-outed this line in the guardian.
Then, the ETMX suspension could reach the LOCK_AQUISITION state.
We are checking why the ETMX suspsneion went to TRIPPED stat.
We found that the MN COILOUTF outputs gave high signal just before the state change.
(There was not earthquack observed.)
After the modification, I found that ETMX cannot be damped well for a long time when the suspension was kicked due to the lockloss (fig1).
Figure 2 shows the enlarged view of oscillation, which is at 1.67 Hz.
Since 1.67 Hz is close to 2nd mode of yaw and NBDAMP_L5 frequency, I checked both of them.
First, I checked MN_MNOLDAMP_Y loop to confirm the yaw loop is fine.
Figure 3 shows the OLTF of MN_MNOLDAMP_Y loop with Y1 and Y2 NBDAMP, which seems fine.
Note that MNOLDAMP_Y is designed to damp only 1st (0.3Hz) and 2nd (1.7Hz) resonances, so NBDAMP for 3rd (3.1Hz) and MNR(4.1Hz) should be turned on during the measurement to avoid kicking the resonance at high frequency.
Then, I measured OLTF of NBDAMP_L5 (fig4), which damps 1.67Hz longitudinal mode of Type-A tower.
During the measurement, I turned on MN_MNOLDAMP_Y and NBDAMP_{Y1,Y2} to avoid kicking the yaw resonances.
Since the resonant frequency of 2nd mode of yaw and tower longitudinal mode are very close, the yaw resonance is growing up during the measurement if there is no yaw damping.
This might be the reason of large peaking reported in klog36109.
Anyway, the OLTF of NBDAMP_L5 also seems fine, so I modified the ETMX guardian so that NBDAMP_L5 is engaged at LOCK_ACQUISITION state and disengaged at CARM_DOWN state (fig5 and fig6).
The SR3 have tripped around 3:50 on Jan 18.
An eathquake was observed around that time.
I reset it as the values monitored by the WD looks nomal now.
(same as SRM: klog36161)
The SRM have tripped around 3:50 on Jan 18.
An eathquake was observed around that time.
I reset it as the values monitored by the WD looks nomal now.
About the ~3 Hz oscillation of the yaw during the pitch OLG measurement, Ushiba-san suggested me to apply the NBDAMP Y1 filter (3.13Hz).
I followed his suggestion and confirmed the oscillation was not occurred in the yaw.
I measured the OLG of the ITMX MNOLDAMP Filter of roll. It's coherence and phase were looked OK, but the gain was smaller than the reference, about -60dB. [Fig. 1]
At that time, the ROL oplev light was almost only in thee SEG4.
Yokozawa-san went into the mine to perform the centering, and I measured the OLG. Then the result was similer to the reference. [Fig. 2]
We changed FM5 to FM1 in the T1 loop filter. As a result, the saturation disappeared.
The values of COILOUTF are now slightly larger than they were in O4c. So we decided to keep this situation.
The TF of this T1 loop when using FM1 is the attached figure.
