Reports of 34317
MIF (ITF Control)
satoru.takano - 2:07 Monday 01 June 2026 (36979) Print this report
Comment to SRMI was locked stably at f1 resonance in SRC (36978)

SRMI was also locked with 3f signals (REFL 51I for SRCL, REFL 51Q for MICH) under the same conditions. It should be noted that the demodulation phase of REFL51 was optimised not for sensing SRCL & MICH signals, but for avoiding glitches when IR flashes at REFL table. This may cause weird phase rotation of the measured open loop transfer functions, as attached (Fig. 1 for MICH, Fig. 2 for SRCL). For stable locking of SRMI and DRMI, the phasing work seems necessary.

Images attached to this comment
MIF (ITF Control)
satoru.takano - 23:35 Sunday 31 May 2026 (36978) Print this report
SRMI was locked stably at f1 resonance in SRC

[Fujimoto, Takano]

Summary

We noticed that the previous locking point of SRMI was not as intended, somewhere very weird. Finally, we found the good locking point, where MICH is at the dark fringe and the f1 sidebands are on resonance in the SRC.

Detail

Once we thought that we could lock SRMI (see here), but after further discussion, we concluded that this locking point was not as expected, because the AS34 buildup was -0.04, whereas we observed it can reach ~ 0.9. After several trials and errors, we found out the optimal conditions for locking it at the point we wanted: MICH is at the dark fringe and the f1 sidebands are on resonance in SRC (Fig. 3). We implemented the appropriate servo settings in the VERTEX guardian. We could lock SRMI by requesting it. The measured open loop transfer functions are as attached (Fig. 1 and Fig. 2).

During the trial, we noticed that PR3 often moved quite largely, sometimes more than 10 urad. It looked like big glitches pushed it. These glitches sometimes unlocked the interferometers during the initial alignment (Fig. 4).

Images attached to this report
Comments to this report:
satoru.takano - 2:07 Monday 01 June 2026 (36979) Print this report

SRMI was also locked with 3f signals (REFL 51I for SRCL, REFL 51Q for MICH) under the same conditions. It should be noted that the demodulation phase of REFL51 was optimised not for sensing SRCL & MICH signals, but for avoiding glitches when IR flashes at REFL table. This may cause weird phase rotation of the measured open loop transfer functions, as attached (Fig. 1 for MICH, Fig. 2 for SRCL). For stable locking of SRMI and DRMI, the phasing work seems necessary.

Images attached to this comment
MIF (General)
satoru.takano - 23:33 Sunday 31 May 2026 (36976) Print this report
Comment to Initial alignment updates (36972)

Attached figures show the latest open-loop transfer functions of PRCL and MICH in PRMI 3f locked after changing the REFL HWP angle. The overall gain of each loop was tuned to match the old measurement.

Images attached to this comment
MIF (General)
takahiro.yamamoto - 16:58 Sunday 31 May 2026 (36975) Print this report
Comment to Initial alignment updates (36972)
A camera issue in OMC_LSC guardian came from an incomplete bug fix in klog#36772.

We found that this error was caused by multiple accesses to a subprocess pipe in counter==3. It was solved by allowing the pipe access only in subcounter==0. This fix worked well in the FIND_RESONANCE state. A same code fix around TEM00 analysis in the FIND_RESONANCE state was applied to FIND_RESONANCE_FOR_10W and FIND_RESONANCE_FOR_IAL_WITH_RF states.

Old code:
 303         elif self.counter == 3:
304 if self.p.poll() is not None:
305 a = self.p.communicate()
306 mode_number = int(a[0][:-1])
New code:
 303         elif self.counter == 3:
304 if self.p.poll() is not None:
305 if self.subcounter == 0:
306 a = self.p.communicate()
307 self.mode_number = int(a[0][:-1])

By the way, 1-minute-long waiting for the interval limitation of the new pylon-camera-server still remains in the DOWN state. The interval issue had been already solved in klog#36397 by using the client side snapshot implemented in klog#36370. So the waiting time in the DOWN state should be now unnecessary.
MIF (General)
shun.saito - 14:22 Sunday 31 May 2026 (36974) Print this report
PLL Attempt

[Takano, Dan, Hirose, Saito]

Following klog:36916, we continued our attempts to achieve PLL lock. We tested both flat filters and low-pass filters. Although loose locking was achieved, we were unable to add an integrator while maintaining lock. In addition, we were unable to measure the open-loop transfer function successfully.
 

  • First, we confirmed the beat signal between the sub-laser beam and the beam coming from the interferometer. Next, the 100 kHz low-pass filter after the mixer was replaced with a 1.9 MHz low-pass filter. A control filter was then implemented using Moku:Lab, and lock acquisition was attempted by matching the LO frequency to the beat signal frequency. For a flat control filter, the system appeared to be most stable with a gain of -10 dB. Increasing or decreasing the gain from this value resulted in poor locking performance. For a low-pass control filter, higher gains could be used compared to the flat-filter case while maintaining lock. However, as the cutoff frequency was reduced, lock acquisition became increasingly difficult.

    The control filters and corresponding beat signals are shown below. In the filter screenshots, the red trace represents the error signal and the blue trace represents the feedback signal.

    Flat filter with a gain of -20 dB (Photo 1), corresponding beat signal (Photo 2)
    Flat filter with a gain of -10 dB (Photo 3), corresponding beat signal (Photo 4)
    Flat filter with a gain of 0 dB (Photo 5), corresponding beat signal (Photo 6)
    Low-pass filter with a gain of 0 dB and a cutoff frequency of 100 kHz (Photo 7), corresponding beat signal (Photo 8)
    Low-pass filter with a gain of 40 dB and a cutoff frequency of 10 kHz (Photo 9), corresponding beat signal (Photo 10)
    Low-pass filter with a gain of 30 dB and a cutoff frequency of 1 kHz (Photo 11), corresponding beat signal (Photo 12)

    In addition, we attempted to add an integrator while the system was locked using either the flat filter or the low-pass filter. However, the lock was lost after the integrator was enabled. Since the integrator cutoff frequency was set directly to a relatively high value such as 1 kHz, it is possible that the lock could have been maintained if the integrator had been introduced gradually, starting from a much lower frequency. We also attempted to measure the open-loop transfer function while the PLL was locked in order to determine the UGF. However, we were unable to obtain a successful measurement.

Images attached to this report
MIF (General)
satoru.takano - 10:53 Sunday 31 May 2026 (36972) Print this report
Initial alignment updates

[Takano]

Summary

Many updates on the initial alignment for DRMI were made. They are implemented in the initial alignment guardian, but no documents for them have been written so far. Also, PRMI ADS problem was solved (I hope).

Detail

When we tried SRMI locking, it seemed that the alignment to AS port looked bad. Until then, we aligned the beam up to OMMT1 using the OMMT2 trans QPD, but left the alignment to OMC as is. We already have the guardian state for the alignment to OMC using OMMT2 and OSTM, but they didn't work because the power after the SRM is now attenuated by 15%. To fit the guardian to the current situation, we added new states for OMC alignment, including OMMT1 alignment using the OMMT2 trans QPD.

The revised procedure is as follows:

  1. Lock one of the arm cavities (Y arm is easier, because normally we align the beam to OMC after Yarm alignment)
    1. Set PRM to MISALIGNED_BF in order to increase the input power later
    2. Because of this, these states are different from the normal IR_LOCKED state, in which PRM is in MISALIGNED_FOR_LOCK_ACQ state.
  2. Increase the input power to 8.5 W while keeping the arm cavity locked
    1. When the input power is 8.5 W, OMC transmission is 30 mW.
    2. The HWPs on both PSL table and REFL table are rotated in iterations. When the input power is increased, the power going to REFL PD gets increased; to compensate for this change, the HWP on REFL table is rotated.
  3. Engage OMMT2 transmission QPD control loop for OMMT1 alignment
  4. Lock OMC and engage OMC QPD control loop for OMMT2 and OSTM loop

These actions were written in INITIAL_ALIGNMENT guardian.

While locking OMC, we faced the guardian error again, which was once reported here. The previous procurement didn't work well unfortunately, but YamaT-san finally found a solution and now it's resolved.

After OMC alignment, I tried to lock PRMI, but it failed even with a decent alignment (POP90I buildup of 0.5). Looking at the error signal, REFL51Q had an offset. I subtracted the dark offset, but still an offset of 2.6 was there. I subtracted it manually by adding an offset in MICH1 filter, then I could lock PRMI, but ADS for it didn't work. Through many many investigations, I found that the angle of REFL HWP was different: when ADS for PRMI worked well, the angle was 125; when it did not, it was 146. The angle depended on which guardian we called to lock PRMI; when we didn't use INITIAL_ALIGNMENT guardian, the angle was 125 and ADS worked successfully, but INITIAL_ALIGNMENT guardian set the HWP angle to 146 when it was called. I changed the guardian so that we set the angle to 125 initially, then we could successfully engage the ADS loop for PRMI. This also removed the REFL51Q offset and PRMI was locked more easily than before.

 

Comments to this report:
takahiro.yamamoto - 16:58 Sunday 31 May 2026 (36975) Print this report
A camera issue in OMC_LSC guardian came from an incomplete bug fix in klog#36772.

We found that this error was caused by multiple accesses to a subprocess pipe in counter==3. It was solved by allowing the pipe access only in subcounter==0. This fix worked well in the FIND_RESONANCE state. A same code fix around TEM00 analysis in the FIND_RESONANCE state was applied to FIND_RESONANCE_FOR_10W and FIND_RESONANCE_FOR_IAL_WITH_RF states.

Old code:
 303         elif self.counter == 3:
304 if self.p.poll() is not None:
305 a = self.p.communicate()
306 mode_number = int(a[0][:-1])
New code:
 303         elif self.counter == 3:
304 if self.p.poll() is not None:
305 if self.subcounter == 0:
306 a = self.p.communicate()
307 self.mode_number = int(a[0][:-1])

By the way, 1-minute-long waiting for the interval limitation of the new pylon-camera-server still remains in the DOWN state. The interval issue had been already solved in klog#36397 by using the client side snapshot implemented in klog#36370. So the waiting time in the DOWN state should be now unnecessary.
satoru.takano - 23:33 Sunday 31 May 2026 (36976) Print this report

Attached figures show the latest open-loop transfer functions of PRCL and MICH in PRMI 3f locked after changing the REFL HWP angle. The overall gain of each loop was tuned to match the old measurement.

Images attached to this comment
DGS (General)
takahiro.yamamoto - 1:45 Sunday 31 May 2026 (36973) Print this report
Applying a new live patch for Debian workstations
A new mitigation measure was applied for the Debian system without a system shutdown.
RH like OS are not affected.
VIS (IX)
ryutaro.takahashi - 14:49 Saturday 30 May 2026 (36971) Print this report
Comment to Offload of GAS filters (33170)

I offloaded the F1 and F2 GAS filters with the FR. The standalone stepper motor driver for the F3 GAS didn't work. 

VIS (IY)
ryutaro.takahashi - 14:46 Saturday 30 May 2026 (36970) Print this report
Comment to Offload of GAS filters (36614)

I offloaded the F0 and F3 GAS filters with the FRs.

VIS (EY)
ryutaro.takahashi - 14:45 Saturday 30 May 2026 (36969) Print this report
Offload of BF GAS

I offloaded the BF GAS with the FR.

DGS (General)
takahiro.yamamoto - 14:11 Friday 29 May 2026 (36968) Print this report
Comment to Lost PCIe connection on K1IOO1 (36952)
[Ikeda, Nakagaki, Oshino, YamaT]

A preparation of new fiber cables was completed.

In addition to the HIB cable, an MTP cable was also installed in a corrugated pipe. This is a backup plan for the case that the HIB cable won't work properly. In this case, IO chassis of K1IOO1 will be also replaced from V1 to V2. When the HIB cable will work properly, it will become a spare cable after the DGS upgrade in future.

The corrugated pipe containing HIB and MTP cables will be laid from the server room to the IOO1 rack on next Tuesday. Until then, the corrugated pipe will be kept at the front room.

Memo for similar cabling works in future
It is more robust to have the extra cable length on the field rack side in case of future changes. And also, HIB and MTP cables have specific orientations as the host (server) side and the target (IO chassis) side. So length of cables of different lengths must be aligned at the host side and placed in a corrugated pipe.

Since the HIB cable reel purchased previously can only be unwrapped from the target side, the easiest way is to pull it all out first and then install it in the corrugated pipe from the host side. When purchasing MTP cables in the future, it is best to choose ones designed as it can be pulled out form the host side (usually the terminal with the pins). Handling ~100m-long cables that have come off the reel is a tough work.
MIF (General)
hirose.chiaki - 12:27 Friday 29 May 2026 (36967) Print this report
Initial alignment in the morning [Xarm, Yarm, OMMT, SRY]

[Yokozawa, Chen, Hirose]

We performed the initial alignment for Xarm, Yarm, OMMT and SRY.
Before Xarm initial alignment, SRM was in LOCK AQ state. So we request SRM GRD to Misalign state.
After that, we completed the Xarm initial alignment.

Subsequently, when we requested ‘IRY LOCK state’ in the initial alignment GRD(Guardian) for the Yarm initial alignment, the IMC’s alignment deteriorated and the lock was lost. To lock Yarm using IR light, we feed feedback to the laser at a high frequency. However, due to the IMC's L2A coupling, it caused the IMC to become misaligned and loss lock.
At that time, the ASC feedback signal was no longer at the normal level, so when we tried to recover the lock again, it became unstable. Therefore, we adjusted the OPLEV on the MCs and the PZT on the IMC’s IP to the values used when the lock was stable. When we tried to lock again, it locked stably. (We reset the PZT offset value to the standard 75V.)

We performed the initial alignment of Yarm. If the transmission power of GRY is low, adjust the PITYAW of SR3; if the transmission power of IRY is low or the flash light is not visible, adjust the PITYAW of BS. This time, we moved BS.

We performed the initial alignment of the OMMT. For the OMMT initial alignment, we referred to klog36759. We also recorded the OMMT1 alignment in the ‘PRFPMI’ of the MEDM screen ‘all oplev’.

For SRY, we request the “Aligning the SRY” state, which is currently in the initial alignment guardian. If the lock is unstable, we adjust the SRM’s PITYAW while monitoring the POPSpol camera and the AS RF34 PD power or AS DC PDA1 OUT power. 
Furthermore, once it was confirmed that the “Aligning the SRY” state had been reached (i.e. SRY lock was complete and the SRM’s ADS was operating stably), the SRY initial alignment was finished. The SRM alignment was recorded and offloaded in the “PRFPMI” on the MEDM “all oplev” screen.

Safety (General)
takashi.uchiyama - 8:18 Friday 29 May 2026 (36965) Print this report
Comment to The top plate is dropped off in the central parking area (34900)
2026/05/28

Kamioka mine company, Hayakawa

We performed a yearly safety inspection of the top ceiling in the central parking lot by Kamioka Mine company on 28 May, 2026.
MIF (ITF Control)
satoru.takano - 1:05 Friday 29 May 2026 (36923) Print this report
SRMI locking test

[Fujimoto, Tanaka, Hirose, Takano]

Summary

We tried locking SRMI. After tuning the filter gain, we easily succeeded in locking it, but further investigation is necessary for good stability.

Detail

For locking DRMI, we tried the SRMI configuration. The idea is to know a hint for a good servo gain of SRCL and MICH in DRMI.

We chose the locking condition as follows:

  1. The Carrier is at the dark fringe in MICH.
    • The f1 sidebands are transmitting MICH by 85 %
  2. The f1 sidebands are on resonance in SRC
    • The carrier would be on anti-resonance, but before entering SRC most carriers are reflected by MICH
  3. Error signals are taken from POP17
    • SRCL: POP17I
    • MICH: POP17Q
    • No guarantee that these two are well degenerated

The conditions for the light fields are different from those in DRMI, but the signal conditions are similar. We expect that, from the servo gain for locking SRMI in these conditions, we would have a good estimate of them for locking DRMI, especially for locking SRCL and MICH in DRMI.

Once we finished the initial alignment of PRMI with ADS, we misaligned PRM and aligned SRM. First we tried the manual locking by tuning the servo gain of MICH and SRCL. After several trials and errors, we found good numbers:

  • SRCL2 gain: 0.5
  • MICH2 gain: -40

We could also enable the integrator on each servo. The measured open-loop transfer functions are shown in Fig.1 and Fig. 2. While locking SRMI, we saw many glitches and they disturbed locking (Fig. 3), resulting in lock loss occasionally. We first suspected the reflection back from PRM, so we misaligned it more by requesting MISALIGNED_BF state, but the situation didn't improve at all.

After succeeding in locking, we implemented the guardian state and tested it. However, every time the guardian failed to lock it when the servos were engaged or the integrators were engaged. After other trial and errors, it turned out that the order of engaging servo gains and the integrators was important: without the integrators, we first need to engage the MICH servo first, then SRCL servo. Also, we found that we couldn't engage the integrator in SRCL servo cannot be enabled without breaking locking, nor increase the SRCL servo gain either. It could be that the demodulation phase is not optimised for SRMI and now POP17I and POP17Q are mixed, which makes the control loops unstable. Further investigation is necessary for stable locking.

 

Images attached to this report
MIF (General)
hirose.chiaki - 22:32 Thursday 28 May 2026 (36964) Print this report
Initial alignment[Xarm, Yarm, OMMT, SRY, PRMI]

[Fujimoto, kTanaka, Hirose]

We performed the initial alignment in order to perform PLL work. However, as the initial alignment took longer than expected, I ended up working on the SRMI instead of the PLL. The initial alignment work done was on the Xarm, Yarm, OMMT, SRY and PRMI. I will post the details later.

IOO (IMC)
hirose.chiaki - 21:29 Thursday 28 May 2026 (36963) Print this report
The restoration of IMC after restarting IOO0

[Yamamoto, kTanaka, Hirose]
I explain the restoration of IMC during the klog36960.

  • The PIT and YAW SUMOUT values for MCI, MCO, and MCE, which had been stable whilst the IMC was locked and ASC was active, had dropped to 0.
    To re-lock the IMC, I set the OPTICALIGN OFFSET to the PIT and YAW SUMOUT values for MCI, MCO and MCE recorded just before the system failed.
  • If it still does not flash, the PZT must be adjusted. In this instance, as it is known that the PZT / DOF5 is effective, I first adjusted the PZT’s OFFSET to a value equal to the DOF5 OUTPUT value minus the nominal 75 V.
  • With this setting, apply LSC and ASC.
  • Check that the DOF5 Input value is 0.
  • Then, slowly return the OFFSET to 75 V.

I will comment further if there are any errors.

MIF (General)
hirose.chiaki - 20:56 Thursday 28 May 2026 (36959) Print this report
Supplied voltage manually to the PZT of the GreenX and GreenY fibre inputs in order to perform the initial alignment

[Tanaka, Yokozawa, Hirose]

To perform the initial alignment, it is necessary to use GreenX and GreenY. 
Currently, as the IOO1 control is under maintenance (klog36952), the PZT voltage cannot be remotely input at k1:ALSFIB under the k1:IOO0 control.
Therefore, we have manually set it to 75V. (Fig.1) If IOO1 recovers, it will be necessary to manually reset it to 0 again.

PZTs adjusted on PSL table at this time: Gr M24, Gr M25(woofer for FIBX_locking), Gr M8(tweeter for FIBX_locking), Gr M20, Gr M21(woofer for FIBY_locking), Gr M19(tweeter for FIBY_lock); To adjust the phase of the input light to the fiber for sending GreenX and GreenY to POP and POS, or to adjust the alignment (optical axis shift).

Images attached to this report
MIF (General)
shun.saito - 19:03 Thursday 28 May 2026 (36962) Print this report
Comment to PLL Test Using a PFD (36955)

The open-loop transfer function measured in klog:36958 is attached.

  • Photo 1 shows the open-loop transfer function obtained using the filter shown in Photo 1 of klog:36958 with the PFD.
  • Photo 2 shows the filter used when the UGF was adjusted to 10 kHz using the mixer.
  • Photo 3 shows the open-loop transfer function obtained using the filter shown in Photo 2 when using the mixer.
Images attached to this comment
DGS (General)
takahiro.yamamoto - 13:10 Thursday 28 May 2026 (36960) Print this report
Comment to Lost PCIe connection on K1IOO1 (36952)
[Kenta, Hirose, Yokozawa, YamaT]

An operation mode of shutter circuit was changed as the local control mode once.
We confirmed the local control mode worked fine.
But, after then, we noticed the shutter model is running on K1IOO0 not K1IOO1.
So we reverted the operation mode as the remote control mode again.

Finally, the models on K1IOO0 were restarted and we confirmed IR shutter can be operated via EPICS.
Lock recovery of PMC and IMC will be reported later by Hirose-san or Kenta.

Turning the power supply breaker for K1IOO1 somehow makes a timing glitch on K1IOO0.
So, when we recovered K1IOO1, K1IOO0 must be in SAFE mode though PMC/IMC lock can be kept during the cabling work for K1IOO1.
Please remind this fact when K1IOO1 will be turned ON/OFF after the cabling work.

For using the IO guardian, ezca for ISS channel was commented out in DOWN state of IO (see attachment).
It might be a temporal modifcation, but same operation is written also in DOWN state of ISS.
So it may be able to be removed permanently.
Images attached to this comment
MIF (General)
shun.saito - 5:24 Thursday 28 May 2026 (36958) Print this report
Comment to PLL Test Using a PFD (36955)

[Ushiba, Takano, Saito]

The VCO efficiency was set to match the efficiency of the sub-laser PZT, which is 1.871 MHz/V. Under this condition, a filter was designed so that the UGF of the open-loop transfer function became 10 kHz. Since the PFD requires an input signal larger than 300 mVpp, while the actual beat signal is only about 0.2 mVpp, it may be difficult to use the PFD in practice. PLL operation was also successfully achieved using a mixer instead of the PFD. Furthermore, it was confirmed that if the beat signal fluctuation is smaller than approximately 936 kHz, lock acquisition is possible by turning on the integrator at the appropriate timing.
 

  • To match the efficiency of the VCO in Moku:Lab to that of the sub-laser PZT, the VCO efficiency was set to 1.871 MHz/V. Then, as in the previous experiment, the open-loop transfer function was measured, and the filter was adjusted so that the UGF became 10 kHz. The filter used is shown in Photo 1. According to klog:35917, resonance of the main laser PZT is observed above 80 kHz, and the resonance frequency of the sub-laser PZT is expected to be similar. Therefore, setting the UGF to 10 kHz is considered sufficiently safe. In addition, the PFD requires an input signal larger than 300 mVpp, whereas the current PLL beat signal (klog:36919) is only about 0.2 mVpp. Since amplification by more than a factor of 1000 would be required, the PFD is not suitable for use in the PLL system.

  • When a mixer was used instead of the PFD, the filter was designed in the same manner as for the PFD case, and PLL operation with a UGF of 10 kHz was successfully achieved. Furthermore, because the frequency of the actual beat signal fluctuates, an additional signal with an amplitude of 500 mVpp and a frequency of 100 mHz was applied to verify whether PLL operation could still be maintained under frequency fluctuations. This corresponds to a fluctuation of approximately 936 kHz. If the same filter used for the non-fluctuating case was applied directly, oscillation occurred. Therefore, one of the two integrators was turned off, and lock acquisition was achieved by turning the integrator on when the error signal frequency became sufficiently low.

Images attached to this comment
CRY (General)
nobuhiro.kimura - 20:02 Wednesday 27 May 2026 (36957) Print this report
Comment to Cryo-cooler Unit Maintenance Work (36134)

[Kimura, Yasui and M. Takahashi]
 On May 27 as part of maintenance work on the cryogenic cooling units, we set up two valve units for the radiation shield cryo-coolers (EYC P-53 and EYC P-55).
We also replace adosorver and filter units in the EYC P-53 and EXC P-55 helium compressoers.
 The remaining tasks are filling the system with G-1 class helium gas up to 15 bar and performing leak tests on all connections.

DGS (General)
takahiro.yamamoto - 16:50 Wednesday 27 May 2026 (36956) Print this report
Comment to Lost PCIe connection on K1IOO1 (36952)

[Ikeda, Nakagaki, Oshino, YamaT]

K1IOO1 was able to be launched properly with a spare 100m fiber laid on the floor.
So, we finally concluded that malfunction and/or aging of a HIB cable is a cause.
Because the contact cleaner of cable terminals didn’t fix this problem, we plan to lay a new HIB cable between the server room and the IOO1 rack.

----
Preparation status of a recovery work:

  • It appears we have an enough amount of corrugated tube in stock.
  • There is a space to lay a new corrugated tube in the hole on the wall at the server room.
  • It looks like we won’t need to drill any holes in the wall this time.
    (We need to consider a hole issue at the future DGS upgrade.)
  • We need to discuss a route of the new cable, human assignment of technical staffs, and a use of an aerial work platform.
    (Hopefully, we can discuss them with Hayakawa-san tomorrow.)


Prospect of recovery
I expect 0.5~1 day for cabling work except at heights. It’s now still unclear when the technical staffs will be available and the aerial work platform can be used, but even if we can do so Thursday afternoon or Friday morning, it will likely take at least until the end of Friday or around noon on Monday.

Consideration about temporary measures until full restoration:
k1shutter (shutter control for main IR), k1alsfib (fiber noise cancelation) and k1psliss don't work at all now. So the shutter cannot be opened now. And also, according to Ushiba-kun, green lasers cannot be aligned because the offsets of the woofer PZTs from DAC are dead.

IR laser shutter can be opened by the local operation mode of the laser shutter circuit. Though a shutter operation remotely via EPICS cannot be done in this mode, IMC lock can be recovered. (Thanks to the hardware interlock, there should be no concern about laser safety). We can also change the output power from PSL room via HWP, so we can use main IR beam for some purposes by this operation. But I'm not sure the stability and noise level because ISS is still unavailable.

Regarding the PZT offset, we can use the 75V output from the Thorlabs(?) PZT driver instead of the 5V output from the DAC. (In my understanding, we normally use 5V offset output from DAC without any offset output from PZT driver.) Fine and remote alignment cannot be available, but rough alignment of green lasers should come back.
 

MIF (General)
shun.saito - 3:28 Wednesday 27 May 2026 (36955) Print this report
PLL Test Using a PFD

[Abe, Tanaka, Hasegawa, Fujimoto, Saito]

To use in the PLL system, we verified the output signal of a Phase Frequency Discriminator (PFD) built by Nishino-san and brought from Mitaka. A PLL test was performed using Moku:Go and Moku:Lab. In addition, the open-loop transfer function was measured.
 

  • First, the output signal of the PFD was examined. Please refer to JGW-D1809187 for the circuit diagram. A signal generated by the Moku:Go function generator with an amplitude of 300 mVpp and a frequency of 10.1 MHz was input to the PFD as the RF signal, while another signal with an amplitude of 300 mVpp and a frequency of 10 MHz was input as the LO signal. The output signal was then observed using the oscilloscope function of Moku:Lab. The observed waveform resembled a partially saturated version of Figures 8 and 9 in the datasheet of the PFD component AD9901KP. In addition, when the RF signal was changed to 10 MHz and the LO signal to 10.1 MHz, the output signal was found to invert. Furthermore, when the frequency difference between the RF and LO signals was reduced to 1 Hz and the output signal was observed as a function of phase difference, a linear response was confirmed, although part of the signal appeared to be saturated.
     
  • However, since this behavior was considered acceptable for practical use, we proceeded to test whether PLL operation could be achieved using Moku:Go and Moku:Lab. First, a signal with an amplitude of 300 mVpp and a frequency of 10.1 MHz generated by the Moku:Go function generator was input to the PFD as the RF signal, while a signal with an amplitude of 300 mVpp and a frequency of 10 MHz was input as the LO signal. Next, the PFD output signal was connected to Moku:Lab and passed through a flat filter with 0 dB gain implemented using a PID controller. The output signal from Moku:Lab was then fed back to Moku:Go, where the frequency modulation function of the function generator was used to apply feedback. While observing the RF and LO signals on the oscilloscope, it was found that, after the control loop was engaged, the RF signal stopped drifting relative to the LO signal (Photo 1). The yellow trace corresponds to the RF signal, and the blue trace corresponds to the LO signal. Therefore, the PLL appeared to operate successfully.
     
  • Next, the open-loop transfer function was measured. Another Moku:Lab unit was prepared, and the measurement was performed using the input and output signals of the Moku:Lab used for filter generation. The excitation signal was applied through the other input port and summed using the PID controller. The signal path connected to PID Controller Output 1 was used for the PLL loop, while the path connected to Output 2 was used for open-loop transfer function measurements. As a result, the UGF was found to be around 387.90 kHz, as shown in Photo 2. Since the phase had already crossed 180 degrees, the loop should theoretically have been unstable. However, the oscilloscope still indicated successful PLL operation, suggesting that the open-loop transfer function might not have been measured correctly.
     
  • Upon closer consideration, because a filter existed between the signals used for the measurement, the measured transfer function actually represented only the Moku:Go and PFD section. In other words, if the open-loop transfer function is represented as G and the filter transfer function as F, the measured quantity was -G/F. To determine the phase delay of the filter section, the transfer function of Moku:Lab was measured separately (Photo 3). From this measurement, the phase delay of Moku:Lab was estimated to be approximately 0.865 μs. Based on this result, the gain of the PLL loop filter alone was changed to -23 dB so that the UGF would shift to a frequency region where the Moku:Lab phase delay is nearly zero. The resulting transfer function is shown in Photo 2. Since the oscilloscope signal also behaved similarly to that shown in Photo 1, the PLL operation is considered to have been successful.
Images attached to this report
Comments to this report:
shun.saito - 5:24 Thursday 28 May 2026 (36958) Print this report

[Ushiba, Takano, Saito]

The VCO efficiency was set to match the efficiency of the sub-laser PZT, which is 1.871 MHz/V. Under this condition, a filter was designed so that the UGF of the open-loop transfer function became 10 kHz. Since the PFD requires an input signal larger than 300 mVpp, while the actual beat signal is only about 0.2 mVpp, it may be difficult to use the PFD in practice. PLL operation was also successfully achieved using a mixer instead of the PFD. Furthermore, it was confirmed that if the beat signal fluctuation is smaller than approximately 936 kHz, lock acquisition is possible by turning on the integrator at the appropriate timing.
 

  • To match the efficiency of the VCO in Moku:Lab to that of the sub-laser PZT, the VCO efficiency was set to 1.871 MHz/V. Then, as in the previous experiment, the open-loop transfer function was measured, and the filter was adjusted so that the UGF became 10 kHz. The filter used is shown in Photo 1. According to klog:35917, resonance of the main laser PZT is observed above 80 kHz, and the resonance frequency of the sub-laser PZT is expected to be similar. Therefore, setting the UGF to 10 kHz is considered sufficiently safe. In addition, the PFD requires an input signal larger than 300 mVpp, whereas the current PLL beat signal (klog:36919) is only about 0.2 mVpp. Since amplification by more than a factor of 1000 would be required, the PFD is not suitable for use in the PLL system.

  • When a mixer was used instead of the PFD, the filter was designed in the same manner as for the PFD case, and PLL operation with a UGF of 10 kHz was successfully achieved. Furthermore, because the frequency of the actual beat signal fluctuates, an additional signal with an amplitude of 500 mVpp and a frequency of 100 mHz was applied to verify whether PLL operation could still be maintained under frequency fluctuations. This corresponds to a fluctuation of approximately 936 kHz. If the same filter used for the non-fluctuating case was applied directly, oscillation occurred. Therefore, one of the two integrators was turned off, and lock acquisition was achieved by turning the integrator on when the error signal frequency became sufficiently low.

Images attached to this comment
shun.saito - 19:03 Thursday 28 May 2026 (36962) Print this report

The open-loop transfer function measured in klog:36958 is attached.

  • Photo 1 shows the open-loop transfer function obtained using the filter shown in Photo 1 of klog:36958 with the PFD.
  • Photo 2 shows the filter used when the UGF was adjusted to 10 kHz using the mixer.
  • Photo 3 shows the open-loop transfer function obtained using the filter shown in Photo 2 when using the mixer.
Images attached to this comment
DGS (General)
takahiro.yamamoto - 21:39 Tuesday 26 May 2026 (36954) Print this report
Comment to Lost PCIe connection on K1IOO1 (36952)
[Ikeda, Nakagaki, YamaT]

Abstract

Similar trouble occurred again on K1IOO1 around 1:15 JST on May 26th and we weren't able to resolve that issue today.
Based on the results of several investigations, a 100-meter HIB cable emerged as the prime suspect.
Two additional tests are needed to confirm the suspicion, and we plan to conduct them tomorrow.
If the HIB cable is indeed the cause of this issue, we will need to run a new cable from the server room to the REFL area.

Details

Because K1IOO1 was dead again, restarting real-time models on K1IOO0 was postponed and recovering K1IOO1 was resumed.
According to the server logs, it seemed to a same issue as one in yesterday. At first, K1IOO1 front-end was just rebooted and it's confirmed that IO chassis was missed from the real-time OS. After then all cables were removed from IO chassis (actually, one DB37 cable for BIO was forgotten to remove). It's a different procedure and investigation under different situation from yesterday, so, strictly speaking, reproducibility and identity of the problem weren't able to be checked by today's investigation. (Since we had already confirmed early this morning on the test stand that a problematic HIB card in yesterday's work wasn't broken, there was no reason to hurry up to disconnect the cable out of fear of a malfunction.) Anyway, IO chassis couldn't be found by real-time OS after removing all signal cables.

Even if all signal cables were removed, electrical connection between IO chassis and another equipment in the field racks because GND of power line of IO chassis (DC24V) is connected to one of DC18V and also AC. So we prepared dedicated power supply unit to float IO chassis completely from the field racks. In this situation, IO chassis should work as the standalone. But the problem was not solved. From this result, we assumed this issue was different from the trouble on MCF0 that another equipment around field racks affects stability of IO chassis.

Note that, at this point, we have not been able to determine whether the problem lies with the HIB cable itself or with the combination of the long cable and the power supply conditions around the REFL. So we plan to connect IO chassis located in K1IOO1 and the server room with the spare cable by the temporal cabling. A result of this test will tell us HIB cable is really bad or not. Also, if the HIB cable is a cause of this issue, it might be worth checking to see if cleaning the terminals improves the situation or not. (The IOO area gets incredibly dusty.) The standard approach is to run a new cable from the server room to the IOO1 rack. In that case, the action items are as follows:
  • Checking a stock of corrugated pipe (and purchasing if necessary)
  • Checking a route of the new cable
  • Drilling work on the wall of the server room
  • Drilling work on the wall between the front room and the corner station
  • Assigning human resources for work at heights
CRY (General)
nobuhiro.kimura - 16:45 Tuesday 26 May 2026 (36953) Print this report
Comment to Cryo-cooler Unit Maintenance Work (36134)

[Kimura, Yasui, M. Takahashi and H. Sawada]
 On May 25 and  26, as part of maintenance work on the cryogenic cooling units, we set up two valve units for the radiation shield cryo-coolers (EXC P-53 and EXC P-55).
Then we charged G-1 class helium gas into the helium commpressors ( EXC P-53,EXC P-55)    up to 15 bar. 

Search Help
×

Warning

×