Virgo Logbook

Virgo Runs (O4c)

Sposito - 7:00 Wednesday 25 June 2025 (67121)

Operator Report - Night shift

Today, I found the ITF in SCIENCE. During the shift, we experienced some unlocks. Here is the list:

22:09 UTC ITF unlocked
00:01 UTC ITF back in SCIENCE,
00:11 UTC ITF unlocked.
01:02 UTC ITF back in SCIENCE,
03:57 UTC ITF unlocked.

During the shift, I also noticed an unusual behavior of the ITF that after an unlock from Science, we experienced similar unlocks during relocking at this state: LOCKING_OMC_DARM_B1_PD3. Here is the list of these types of unlocks:

19:38 UTC
22:37 UTC
23:07 UTC
04:30 UTC

Images attached to this report

67121_1750827304_Screenshot 2025-06-25 at 06-53-43 Plots for logbook report.png

67121_1750827305_Screenshot 2025-06-25 at 06-54-51 DMS Event Monitor.png

Comments to this report:

masserot - 8:52 Wednesday 25 June 2025 (67123)

I had a look at the unlocks after the LSC_Acl mimimun elapsed_time tuning performed the 2025-06-24-16h20m30s-UTC:

2025-06-24-17h35m14s-UTC - Sc_WE glitch
2025-06-24-19h05m24s-UTC - Sc_WE glitch
2025-06-24-19h37m27s-UTC - Sc_WE glitch
2025-06-24-22h09m14s-UTC - Sc_WE glitch
2025-06-24-22h37m44s-UTC - unknown reason : not the standard shape of DSP glitches
2025-06-24-23h07m36s-UTC - Sc_WE glitch
2025-06-26-00h11m41s-UTC - Sc_WE glitch
2025-06-26-03h57m50s-UTC - Sc_WE glitch
2025-06-26-04h30m26s-UTC - Sc_WE glitch
2025-05-26-05h05m48s-UTC - Sc_WE glitch
2025-05-26-05h16m06s-UTC - unknown reason : not the standard shape of DSP glitches

Remarks

None error in the return channels to the SUSP_rtpc
None unlock due to NE DSP glitches
the majority of the unlocks are due to WE DSP glitches

As new trial, the LSC_Acl minimum elapsed_time has been set to 33us instead of 29us previously at 2025-06-25-05h29m20-UTC

Images attached to this comment

67123_1750832256_LSC_Acl-Sc_WE-20250624-17h35m12s-UTC.png

67123_1750832441_LSC_Acl-Sc_WE-20250624-19h05m24s-UTC.png

67123_1750832554_LSC_Acl-Sc_WE-20250624-19h38m27s-UTC.png

67123_1750832621_LSC_Acl-Sc_WE-20250624-22h09m14s-UTC.png

67123_1750833058_LSC_Acl-Sc_WE-20250624-23h07m36s-UTC.png

67123_1750833151_LSC_Acl-Sc_WE-20250625-00h11m41s-UTC.png

67123_1750833240_LSC_Acl-Sc_WE-20250625-03h57m50s-UTC.png

67123_1750833299_LSC_Acl-Sc_WE-20250625-04h30m26s-UTC.png

67123_1750833638_LSC_Acl-Sc_WE-20250625-05h05m48s-UTC.png

viret - 11:59 Wednesday 25 June 2025 (67127)

Related to that I don't know if it has been noted already but looking at the WE DSP server logfile on vpm there is a warning message related to DSP temperature

I don't know what's the issue with the DSP, but the fact that the chip seems to be overheating is not good anyway I guess

Images attached to this comment

viret - 12:07 Wednesday 25 June 2025 (67128)

On the same topic, seems that temperature has already caused issue there in the past:
https://logbook.virgo-gw.eu/virgo/?r=64910

ruggi - 15:40 Thursday 26 June 2025 (67137)

After the latest unlock, a few probes have been added from Sc_WE, in order to monitor more GLB input channels. The signals have been added to existing unused channels and the name of the probes have not been changed. The legend is:

Sc_WE_noise --> GLB00 (LOCK FLAG)

Sc_WE_txAA --> GLB0a (calib lines on MI)

Sc_WE_tyAA --> GLB0b (calib lines on MA)

Sc_WE_ErrPost --> GLB0c (calib lines on MI)

The signals from calib are added to the locking correction (MA or MI) before the latest high pass filter, compensating the analog filter after the DACs.

A glitch has been catched; all the new probes show an anomalous sample. In one of the signals, the bad data is large enough to explain the unlock.

Images attached to this comment

ruggi - 17:13 Thursday 26 June 2025 (67139)

As a side effect of the download of the master board, a few probes don't work anymore. They are the output signals of MIR_PSDF, the signals acquired by the board itself. The problem seems to be only on the probes, because the signals are used to generate MIR_Z, MIR_TX and MIR_TY, which don't show any issue. They are anyway signals not used for the control.

Images attached to this comment

mwas - 18:22 Thursday 26 June 2025 (67141)

It is hard to imagine how a glitch at ~400 can be created out of a calibration noise channel that usually contains only small numbers. One possibility is if the issue is that the channel order become wrong for a few samples. So that the LSC_B8_DC (third channel in the packet) is received instead of LSC_CAL_WE_MIR_Z_NOISE (thirteenth channel in the packet). LSC_B8_DC has a mean value of ~535, so that could create a value around 400, if it is wrong for 3 out of 4 of the 40kHz samples used by the DSP and recorded back in the DAQ at 10kHz.

ruggi - 22:04 Thursday 26 June 2025 (67144)

Another event with similar values, in different position. The channel with the power could be probably removed, or at least reduced in amplitude before sending it to the DSP. I would also propose to remove the unused channels: MAR calib and a channel supposed to send some damping of violin modes, never used.

Images attached to this comment