[Tanaka, Ushiba]

Abstract:

We tried to increase the laser power more than 10W at PRFPMI_RF_LOCKED state
Laser power once reached 10W but lockoss happened after several minutes due to the oscillation of ETMY pitch oscillation at 1.3Hz.
So, some tuning of local damping control and/or ASC would be necessary.
Detail will be posted later.

Since ETMY MNOLDAMP was not yet well tuned an gain peaking around 1.32 Hz is large (more than 10dB), I tuned MNOLDAMP_P filter.
Figure 1 shows the OLTF of current loop with the reference (OLTF at room temperature).
Current gain peaking is less than 5dB, so it seems stable sufficiently at this moment.

I also checked the MNOLDAMP_Y but no significant change can be observed from the room temperature one except for the position of resonances (fig2).

[Ushiba, Komori, Tanaka]

related to klog31986 (REFL), klog31992 (MCE TRANS), klog32330 (IMC REFL), klog32348 (AS)

The optical layout on the POP table is here. Optics name convention as below is followed as the ones in this layout. Working photo are saved in the KAGRA dropbox.

We checked the POP beam path with PRMI 1f lock.

The beam spots on the periscope mirrors seem to be fine (fig.1, 2). However, we found the light was scattering at the upper mirror (fig.3). We are not sure of the origin for now.  

The beam spot could not be seen with IR camera from HBS1 to RLNS2. On the other hand, if the clipping occured at the edge of optics, the IR camera can observe the scattered light but we could not see anything. This indicates that the clipping may not occur at their optics. 

We found that the beam position on TFP after RLNS2 seemed to be lower than the TFP center (fig.4). So we adjusted the height of TFP (fig.5). After the adjustment, we aligned the beam path in the downstream from this TFP.

Then, we performed the centering for {S, P}-POL DCPDs with the single bounced beam from X-arm.

In this time, we could not perform the centering for RFPDs because PRFPMI could not lock within the working time unfortunately. However, the POP alignment was performed previously (klog26187) and the alignment of upstream was not changed. So we trust the centering for RFPDs is fine.

And also, The S-POL PD gain was set to 40dB, and if the input power were to increase to 10W in the future, it would probably cause saturation, so this time, we lowered the gain by 30dB to 10dB.

Dan Chen, Hido, Ushiba, Aso

Abstract

We installed a new OMC DCPD driver. We confirmed that it works fine.

Background

The OMC DCPD has two transimpedance options, Z=100 and 400.
The value of Z can be switched by sending a binary signal (ZSW) to a relay in the in-vac DCPD amplifier.
This ZSW signal was introduced to the vacuum through a separate D-Sub. This configuration induced a lot of noise, possibly due to the ground loop, into the DCPD.
Therefore, we disconnected the ZSW, which effectively fixed the value of Z to 100. However, the dark noise of the DCPD is now close to the current sensitivity. So, we wanted to change the transimpedance to 400.

For this reason, AEL made a new DCPD driver to send the ZSW signal through the same D-Sub as the other signals of the DCPD.

New DCPD driver design: https://gwdoc.icrr.u-tokyo.ac.jp/cgi-bin/private/DocDB/ShowDocument?docid=16157
S-number of the installed one: https://gwdoc.icrr.u-tokyo.ac.jp/cgi-bin/private/DocDB/ShowDocument?docid=16233

Overview of the new scheme: https://gwdoc.icrr.u-tokyo.ac.jp/cgi-bin/private/DocDB/ShowDocument?docid=16158

BIO converter

The old design used a modified BIO converter to drive the relay for the Z-switch. In the new design, the driver circuit for the relay is included in the DCPD driver circuit. So we should use the standard BIO converter.

Installed BIO converter: https://gwdoc.icrr.u-tokyo.ac.jp/cgi-bin/private/DocDB/ShowDocument?docid=10321

Conversion cable

The new connection scheme requires a conversion cable in front of the vacuum feedthrough.
As shown in the photo, the current conversion cable is fragile. I used a cable tie to bind the cable to the next one so that the weight of the connector is not applied to the weak conversion cable. Still, we need to make a more robust conversion cable.

Pin-out check

Before connecting the cables, we checked each pin at the vacuum feedthrough to confirm that correct signals come to the correct pins, such as power lines and bias voltage. We also confirmed that the ZSW signal turns on and off according to the press of the EPICS button.

Noise check

After the new circuits were installed, we measured the PD dark noise.

(/users/Commissioning/data/OMC/DarkNoise/2025/SPEC_Darknoise_OMCTRANSPD_20250121.xml)

The noise level with Z=100 is basically the same as in September last year.

When Z=400, the overall noise went down by a factor of 4, as expected.

There are several new noise peaks (~130Hz and ~250Hz) in Z=400. We don't know why they appeared.

Today I measured the Resistance and Inductance of the Large Coil.

I tested a newly purchased small shaker (~3,000 JPY, 4Ω, 25W) and a portable audio amplifier (Topping PA3S, both single-end and balanced-differential inputs are available) using KAGRA's DAC/ADC at the IY0 rack.

To connect the DAC output (balanced-differential signal) to amplifiers, I made a Dsub9 -> XLR connector cable. Its pin-assign follows the world standard. It is available for our large speaker's amplifier (QSC RMX850).
Since the input port of the portable audio amplifier is 6.35mm TRS, I used a commercial XLR -> TRS connector cable.
They have been tested in Mozumi yesterday.

I located the small shaker and an ACC (TEAC710) on the floor and measured their transfer functions with an amplitude of 100 counts (~30mV). The volume plug of the portable audio amplifier was max.
Plots 1 : 0-8000 Hz white noise injection (black lines are the background level, measured by turning off the audio amplifier)
Plots 2 : 10-200 Hz white noise injection
Plots 3 : 20-220 Hz, 1Hz step swept sine injection

To derive enough SNR around 100Hz,  the DAC output amplitude may need to be larger.
The maximum input voltage for this amplifier is not shown, but typically, it is 0.5~2 V.

[Yong-Xiang Yang, Chia-Hsuan Hsiung, Gui Chin Liu (from Tamkang university), Chia-Jui Chou, Yuzurihara]

We started the lockloss investigation during the end-year holiday, with powerful supporters from Taiwan. We checked the timeseries by using ndscope and time-frequency map by using the Pastavi.

Details

• This is a continuous work of klog. So, we focused on the lockloss during 2024/12/21~12/30.
• The generated plots were collected on wiki.

OMC saturation

We found the OMC saturation was happening only on 2024/12/29. (Fig) (Fig) Times are below:

• 2024-12-29 21:19:16 UTC (lock duration=151 s, saturation duration=32s)
• 2024-12-29 19:41:26 UTC (lock duration = 193 s, saturating duration = 58 s)
• 2024-12-29 19:04:37 UTC (lock duration = 702 s, saturating duration = 600 s)
• 2024-12-29 17:26:56 UTC (lock duration = 278 s, saturating duration = 100 s)

The frequency of the oscillation is ~5 Hz or ~5.2 Hz. (Fig) Even though the OMC saturation was happening, the interferometer kept the locking. Is that health?

Excess at f<=10 Hz in PRCL and MICH

Sometimes we observed the excess at ~10 Hz in error or feedback signals of PRCL and MICH, ~30 seconds before the lockloss. (Fig) For example. 2024-12-30 21:38:25 UTC.
Possible scenario is to feedback this excess to the PRM(?). We will check more data and discuss with the interferometer experts.
It's difficult to see this excess in the timeseries. We started to collect more statistics by checking the time-frequency map. We will collect more statistics abour this phenomena.

Related to this, I prepared the script to pass the lockloss time to Pastavi web page.

• Usage
  • /users/yuzu/lockloss/open_Pastavi.sh 481

Drift by BPC feedback control

Sometimes we observed the sudden drift by the BPC feedback control. (Fig) In this case, after the sudden drift, the ETMX overflow happened.
We will collect more statistics abour this phenomena.

ETMY MN oplev glitch

We checked the coincident lockloss with the ETMY MN oplev glitch, since 2024-12-28 12:24:50 UTC. After 12/28 13:05, there is no coincident lockloss with the ETMY MN oplev glitch. Three coincident lockloss are:

• 2024-12-28 13:05:36 UTC (Fig)
• 2024-12-28 12:24:50 UTC (Fig)
• 2024-12-28 10:59:28 UTC (Fig)

With Shingo Hido, Yoichi Aso

Summary

We measured the transfer functions of AA circuits for the 2 OMC DCPDs.
There are no particular problems.
Measured data are stored at CAL gitlab: GitLab/cal-measurements-raw-data-002/pre_o4/common/2025-01-21_OMC_DCPD_AA_TF
This measure was performed because the AA circuits were replaced after O4a: klog.
Detailed report: link

Details

• Information
  • Measurement tool: CF9400
  • AA S number: S2214378
  • Measurement target
    • OMC0 rack -> ADC0 -> ch1 and ch2 = num 0 and num 1
• Measurement settings
  • HR-0p01V
    • Freq: 10-100kHz
    • Res: 50 lines/decade
    • Amp: 0.01V
  • HR-1V
    • Freq: 10-100kHz
    • Res: 50 lines/decade
    • Amp: 1V
  • HR-3V
    • Freq: 10-100kHz
    • Res: 50 lines/decade
    • Amp: 3V
  • LR
    • Freq: 0.1-100kHz
    • Res: 10 lines/decade
    • Amp: 1V
• Measurement
  • At first, we measured the TF of the measurement setup without the AA circuits as background.
  • Then we measured the TF of the AA circuits.
  • Attached ones are a part of the measured results.

Since we faced PR3 sudden large oscillation (reported in klog32404) during the POP alignment work, I quickly checked what happened.

To investigate if this is real suspension motion or just sensor signals, I requested PAY_FLOAT state and see OpLev signals (fig1).
Though RMS is large due to no local control, glitch like oscillation cannot be seen, so it is very likely that the oscillation is not a real suspension motions.
Figure 2 shows the OSEM signals with the same time window of fig1.
Obviously H3 OSEM moves while the other signals including OpLev didn't move, so OSEM H3 seems strange.

Figure 3 shows the OSEM H3 raw input with the same time window of fig1.
Many glitches and large jump can be seen in the signals, so PR3 OSEM H3 needs to be checked and fixed.

[YamaT, Yuzurihara]
I tried to validate the script. When we compare the Segment generated by the new script and the Segment of regular generation with 15 cadences, there was a slight difference due to missing frame data by rebooting the computer at Kamioka. This was happening only on the maintenance day (11/08). So, it will not affect providing the Segment for the data analysis purpose. 

Detail

The Segment generated by the new script is stored in /users/yuzu/work/20250115_segment . The differences between the generated Segment by the new script and the Segment of regular generation with 15 cadences are summarized below:

For the following Segments of 2024/11/08, the period of rebooting the computer was flagged in the Segment of regular generation with 15 cadences, not flagged in the Segment generated by the new script. We guess the cause is related to rebooting the computer.

• K1-ETMX_OVERFLOW_OK
• K1-ETMY_OVERFLOW_OK
• K1-OMC_OVERFLOW_OK
• K1-GRD_UNLOCKED

For the K1-DAQ_IPC_ERROR Segment of 2024/11/08, the period of 1415118400 ~ 1415118592 was flagged in the Segment of regular generation with 15 cadences, not flagged in the Segment generated by the new script. As I heard from YamaT-san, there was multiple rebooting of k1fr0 during the maintenance day. If there was no frame data in /frame0/, the script to make a cache file will use the frame file in /frame1/ . This time, it seems not to be happening. We will check it for future maintenance days. Anyway, this happens during maintenance day. It will not affect providing the Segment for the data analysis purpose. 
For following Segments of other dates, there was no difference.

For the following Segments, there was no difference for all the dates. 

• K1-ETMX_OVERFLOW_VETO
• K1-ETMY_OVERFLOW_VETO
• K1-OMC_OVERFLOW_VETO
• K1-GRD_PEM_EARTHQUAKE
• K1-GRD_LOCKED
• K1-GRD_SCIENCE_MODE

The script was uploaded in the git repo.

Is the ring-ish shape varied when the alignment of the main optics changed? For example, when the REFL light power was reduced.

Shingo Hido, Misato Onishi, Kohei Mitsuhashi, Dan Chen

We summarize the results of WSK/GSK measurements conducted at University of Toyama between October 2024 and January 2025.

On December 10, 2024, the WSK device broke down, and we performed repairs. Therefore, we divided the graphs into periods before and after the incident.

The averaged WSK/GSK ratio calculated using all post-incident data is
         WSK/GSK = 0.9091 ± 0.0016 (0.17%) [V/V].
The measurement results are sufficiently stable.

Each measurements are reported here.

[Tanaka, Komori]

Tonight, we obtained DARM sensitivity data with DC readout.
In the attached figure, today's sensitivity is compared to the typical sensitivity before cooling and yesterday's sensitivity, without any compensation for the gain difference.
Based on the open-loop measurement, the total gain has increased by 2 dB.
Even if this increase is attributed to a larger actuator efficiency, the improvement in sensitivity at 60–100 Hz is evident, which is encouraging news.

The sensitivity in this frequency range exhibits breathing, and the 118 Hz peak—previously thought to have disappeared—also shows a breathing behavior.
To maintain the improved sensitivity (red curve), it may be necessary to reinforce the ASC.

The current optical layout at POP table is shown in the attached figure, where the related area is zoomed in.
I updated the JGWdoc file (JGW-T1909623).

[Komori, Tanaka, Uchiyama, Ushiba]

Abstract:

We aligned POP FORWARD beam path and reduced the beam power on POP FORWARD QPDs for high power operation.
Now, POP FORWARD QPD SUM value is about 10 cnts with misaligned PRM, which is corresponding to 14000 cnts with 10W PRFPMI.

Detail:

Since the beam is almost clipped at FST1 (see JGW-T1909623-v12), we changed the mirror mount to lens mount.
Thanks to this modification, the beam from FST1 to FST2 seems to be enough large gap from the optical structures now.
One note here is that we set the HR side into lens folder backwards.

Initially we planed to reduce the QPD SUM value by a factor of 5 by changing the gain switch and by a factor of 2 by inserting 50-50 BS; however we noticed the gain switches has already been low gain, so we need to reduce laser power more than 10 times.
So, we inserted BSX11 between FLNS1 and FBS1 instead of BS, which have more than 95% reflectivity for s-pol beam, according to the spcification.
Reflected beam at BSX11 is dumped by LB1/M.

Then, we aligned the beam to QPD centers and checked if all beam dumps propery dump the ghost beam.
Figure 1 shows the QPD SUM values when PRFPMI is locked with 1W after the work.
QPD SUM values are less than 2000 cnts, so QPD SUMs won't be saturated even with 10W PRFPMI.

Note:

We found that the POP FORWARD beam has a ring around the main circular beam (fig2).
This ring is not seen just after the viewport but appeares after the beam flies.
Since there seems no clipping on the optical table and the ring appears between the upper periscope mirror and the lower periscope mirror when the beam passes in air, we thought it might come from inside the chamber, but we could not confirm it.

[Ushiba, Uchiyama, Komori, Tanaka]

Today's working photo are saved in the KAGRA dropbox. We updated the current layout on AS table (JGWdoc) 

## Abstract

We bustered some ghost beams around the OMC REFL beam path. As for the ghost  on the HWP in the AS path, therer seems to be no space to put the beam dumper. But, the ghost beam hit on the rotater and the beam power is too low. We left it for now.

## What we did

• The 1st ghost was on the mirror holder as reported in previous klog32361. This ghost seemed to originate from LNS3 and this ghost beam path was very close to the main beam path. So we tweaked LNS3 to separate each path. After the tweaking, the ghost beam passes thourgh the beside of the ST6. Then we dumped it (fig.1).
• The 2nd ghost was on the lens holder of LNS5 from BS5 (fig.2). We installed an iris and block the ghost beam with the iris (fig.3).
• The 3rd ghost was on OMC REFL QPD1 (fig.4). (There are 2 beams on QPD1 in fig.4, the one of higher beam position was the 2nd ghost. This is dumped by the iris in front of LNS3. The another of the same height as the QPD element was the the 3rd ghost beam.) We moved the beam dumper near QPD1 and dumped it with the dumper (fig.5).
• The 4th ghost was on the ST14 holder. We moved ST14 and ST15 to the -Y direction. Then, the beam passes through the beside of ST15. We installed the dumper to dump it (fig.6).   
• Last ghost beams passed thourgh above ST6 from the ND filter in front of CCD. We know the ND filter has been broken previously and the CCD is not used. So we replaced from the ND filter to a beam dumper. 
• After that, we confirmed each beam position was on each center of each optics.
• As for the ghost  on the HWP in the AS path, therer seems to be no space to put the beam dumper. But, the ghost beam hit on the rotater and the beam power is too low. We left it for now.

[Oshino, YamaT]

We investigated what was the actual reason of this issue and finally concluded that it came from the timing conflict of reading and writing of measured temperature of Ondotori XML files.
We are now testing an improved code by using DAQ of the room temperature at Mozumi server room.
After we can confirm it works well, we plan to deploy the new code for the DAQ of the temperature in the mine.

-----
At first we found the immediate change as ~12degC in EPICS sampling (16Hz) on that channel as shown in Fig.1. It shouldn't be a real temperature change. So we were able to focus on the software or Ondotori device issue soon. According to a check of raw data of Ondotori (XML file shared via ftp@k1nfs0), BS cooler channel stably showed  9.6~9.7degC and we couldn't see a value of 21.9degC which was shown in slack alerts. This fact means that Ondotori device took a correct data and DAQ script couldn't read a correct value from XML files. Because there was some possibility that this problem came from some network or IOC troubles, I also checked a log of caput in the DAQ script just in case. Then, we could confirm DAQ script surely put 21.9degC to that channel.

After checks above, we considered how to put wrong value by the DAQ script and found soon that Ondotori DAQ script didn't take care about the timing relation between reading XML files and writing XML files by Ondotori device. And also the data array for read values are not initialized. In common case, when some function is called multiple time heap and stack region for local variables are assigned in same memory addresses. An another complicated issue is that XML file contains the data from multiple child devices and order of data is not constant (depending on the network speed at that time). As the result of these several intertwined issues, uncleared old value of another child device is read from memory region when DAQ script read XML files while Ondotori device are writing XML files.

After finding an actual problem, Oshino-san prepared modified DAQ code to avoid reading XML files while Ondotori device are writing files. It's running as DAQ for the room temperature monitor of Mozumi server room. After we can confirm that it works well, we plan to deploy it for all Ondotori devices in the mine.