The only remaining ISC related explanation that I can think of to explain the large decrease in sidebands are large offset in PRCL or MICH.

Figure 1 shows an example of a lock acquisition on Friday. Around 15:24 UTC there is a transition where the B2 8MHz I signal becomes 3 times smaller, other B2 signals have also a step, and the SSFS line height in B2 DC decreases by a factor 4. But it has no incidence on the sideband recycling gain. This step behaves like a large improvement in PRCL offset, and thas not impact on the sideband gain, which would mean that a PRCL offset doesn't play a role in the sideband gain decrease.

On the other hand at 15:20:30 UTC there is another large transition. Where the sideband gains decreases, especially the 6MHz. At the same time the misbalance of the 56MHz sideband on B1p increases by a factor 3, and the 6Mhz power on B1p also increases by almost a factor 2. This misbalance then continues to increase over time, the B1p 6MHz power increases over time, and the sideband gain decreases. This could be explained by a very large offset on MICH, that then continues to increase over time. 

Figure 2, 3 and 4 shows phase camera images on B4 and B1p during the CARM null lock. The sidebands on B4 progressively move away from the position of the carrier on B4. And the shape of the 6MHz sideband, and 56MHz LSB becomes more and more like a doughnut, which would be a sign of a mismatch between the north and west short Michelson, which could mean one of the input mirrors absorbs much more than the other.

After adjusting the B1 PD3 offset the DET_MAIN checks of the slow shutter were successful and I could relock the arms. The offset adjustment will probably need to be undone in a few hours as the temperature of the SDB2 bench is slowly coming back up once it is back to be supplied in power. 

I ran an OSCAR simulation considering an input power of 12 W and an absorption of 0.3 ppm, as specified by LMA for the new mirrors. With these values, the absorbed power is about 20 mW.

In the absence of thermal effects (i.e. in the ideal case), the gains are about 74 and 51 for the 6 MHz and 56 MHz sidebands, respectively, assuming 1500 ppm losses in the recycling cavities.

No cold maps of the mirrors were included, except for the POP cold maps. I assumed PR and SR RoCs of 1430 m, RoCs of 1427.8 m and 1428.8 m for the new input mirrors, and RoCs of 1670 m for the end mirrors, corresponding to the expected value with the RHs on.

Including the OPL variation induced by 20 mW of absorbed power, shown in the attached figure, the 6 MHz and 56 MHz sideband gains decrease to about 29 and 22, respectively. The gains are calculated considering all modes, not only the TEM00.

To obtain a 6 MHz sideband gain of about 10 in the simulation, the assumed absorption needs to be increased by approximately a factor of 3, from 0.3 ppm to 0.9 ppm. Equivalently, keeping the absorption at 0.3 ppm, the same thermal load would correspond to an input power of about 36 W.

For the third time, the SDB2_DBOX_LeftUp became unreachable on the Tolm network at 2026-09-12-21h02m15-UTC

• its power supply remotely driven has been switched OFF/ON at 2026-09-13-05h56m45-UTC
  • this allows to recover the  SDB2_DBOX_LeftUp dbox  from the Tolm network 
• All the SDB2 DAQ boxes have been successfully reconfigured 
• Only the SDB2 LC loops closed  successfully
• DET_MAIN is undefined state  

Operations performed between  2026-09-13-05h56m37-UTC and 026-09-13-06h16m38-UTC

The attached plot shows the SDB2 DaqBoxes timing error signals, their  +/-12V  power supplies monitoriing channels and each DBOX external temperature sensors (the one of RightDown doesn't work)

Yesterday morning I found all the ALS photodiodes at NE giving strange values (see fig. 1). Looking back in time, it appears that right after the opening of most of the suspension guardians  on Thursday night, all the ALS photodiodes (CEB, NE, WE) went to 0 several times as a consequence of the frequent unlocks. However, at NE those values stucked at 0 at 22.20UTC and almost one hour later they went to negative values (fig. 2). Also the SOA stopped to work.

Investigating the electronics of the power supply, we find out that apparently there was a loose connector on the +24 DC distribution box that started to became a problem only on Thursday night for no apparent reason. 

 Repairing the connector solved the problem. The NE ALS signals are stable since the restart of the photodiodes and SOA.

Yesterday afternoon, I did a first check of the NI mirror during the short CARM NULL locks of yesterday, no PAs has been observed so far, but the focus point of the camera has to be better set next days. 

Moreover, profiting of some down period during the commissioning shift at the end of the afternoon, I installed a new thermocamera at the WI, at the small ZnSe viewport access. 

As usual, the camera stream is accessible only from devices connected to the EGO WiFi network, via the address : http://172.31.10.153:8080/. Data will be acquired next week. Both camera should be accessible at the same time.

In order to check if ISC actions could help in the survival of the CARM null 1f step we have checked and tuned:

- SSFS phase and gain (tuned)

- PR tx and ty phase 

- B2 8MHz (input beam alignment) 

- SR alignment behavior

- DiffP set servo

None of these actions helped in reducing the drop of the sidebands

We tried also a lock acquisition with the SR misaligned -2urad in ty. No effect.

In view of the next commissioning activities, we set up a very basic (and temporary) check on the power reflected by the IMC (INJ_IMC_REFL_DC); this is done only in the IMC_RESTORED state of the INJ_MAIN node and, if failed, it will prevent moving forward to the lock acquisition if such power is out of a specific range (+- 50 mW around the current average, changes may still happen); this is to avoid bad lock attempts after unlocks following manual or automated changes of the input power, especially for lower power that may make the lock of the IMC itself less reliable.

A forced failure of the check has been tested, and the new cyclic decorator is now in operation.

06:00 UTC ITF found with the following loops open:

• top stage IB, OB, PR, SR, BS, NI, WI
• F7 BS, WI
• LC BS
• Position and angular SPRB, SDB2, SNEB, SEWB

ITF was put in DOWN with ITF_LOCK and INJ_MAIN nodes in pause.

I was able to close some of them but SIB1 and WI had too high a correction to hold. Manuel started working on the issue while I called Valerio (work in progress), since we noticed that many stages of different suspensions were close to saturation and needed to be moved with motors.

SBEs closed.

08:15 UTC I changed the TCS Aux cooling chiller setpoint from 17 to 16.1. Heating loop setpoints: WI 17.4, NI 17.2. CO2 CH powers are back to before adding glycol.

10:00 UTC ALS NE malfunction assessment: L1 power supply not working (Cavalieri, Spinicelli)

12:00 UTC ITF in LOCKED_ARMS_IR

Figure 1. The 6MHz sideband gain drops from 60 to around 10, and the decrease is still on-going when the unlock happens. During O4 in CARM NULL the sideband gain was around 23. Maintaing the CARM NULL lock in this case for longer than 5 minutes may be a challenge without thermal compensation, or at least requires UGF servos and MICH/PRCL/SRCL diagonalization that can react on a time scale of one minute.

The automated lock loss analysis points the finger at DIFFp low gain as the reason for the unlock. Figure 2 and 3 show that in two examples where the interferometer stayed in CARM NULL for a few minutes the DIFFp gain servo has been struggling, with the gain adjustment oscillating by a factor 2 or 3 on a time scale of minute, with increasingly large oscillations.

The activity of the shift was the CARM_NULL_1F recovery.

In agreement with Mattia I kept trying to lock up to 20:20 UTC when I park the ITF in locked arms.

Automation

At 20:13 UTC the Automation nodes of DRM_LOCK, ITF_LOCK and SUSP_PR got stuck: to restore the situation I restarted the nodes and performed some INIT cicles.

DAQ

SuspFB restarted at 15:42 UTC to recover data after an event of missing data.

The goal of this shift was to recover CARM_NULL_1F.

During the shift we suffered from issues related to a few passages in the lock acquisition:

• the hand-off of DARM to B1p_56MHz failed rather frequently. We fixed it by reducing the calibration factor between the green signal and the 56 MHz signal from 1e6 to 8e5 and adjusting the demodulation phase from -1.8 to -1.6.
• the DRMI locked with a lot of difficulties, which compounded with other issues and made caused us to waste a lot of time. Reducing MICH gain by roughly 30% to 0.9 helped with this.
• the initial acquisitions of CARM_NULL_3F were difficult, as the MICH/SRCL gains appeared to be too high, but increasing them beforehand would cause an unlock soon after as the sidebands power dropped. We worked around this by reducing the gains significantly for the 3F engagement and modifying the UGF servos coding to make them more aggressive:
  • we modified the PyUGF.py script in /virgoDev/Automation/PyALP/PyUGF/ by chainging the scaling factors of the gains from * 0.95/* 1.05 to *(1-step)/*(1+step) and then we set step to 0.1, to make the modification (and its future reversal) cleaner, then we stopped and started the process with no issues.

It should be noticed that CARM_NULL_3F remains a highly unstable state that only lasts long enough to go to 1F. In our case it worked 3 times. 

The initial attempts to engage CARM_NULL_1F failed for what seemed to be a wrong phase for B4_56MHz. We attempted to rotate it by 45 degrees and we were lucky enough to pick the right way, yielding a successful transition for the next attempt. We then proceeded to fine tune both B4_56MHz and B1p_56MHz phases to minimize the MICH_PRCL_COUPLING and the DPHI channel respectively.

The first proper lock in CARM_NULL_1F (the first actual one was accdentally killed by human error) lasted for about 4 and a half minute (Fig.1). The sidebands power in the PRC drops by about 60% in this time.

We leave the ITF chasing CARM_NULL_1F to accumulate potentially useful data for TCS and instruct the operator to park it in locked arms before leaving at 11pm.

This morning I found the cavities locked on the infrared; the ITF lock recovery went on all the morning without any major problem, the ITF was locked up to CARM_NULL_3F, the work will go on in the afternoon... 

TCS
13:35 UTC auxiliary cooling system chiller setpoint changed from 17.8 to 17. Heating control loops setpoint changed accordingly (Cavalieri, Zaza)

Today around 13:38 UTC the setpoints of the etalon loops have been changed to:

• NI: 19.68 degC (+0.15) in 259200 s (3 days)
• WI: 19.30 degC (+0.15) in 259200 s (3 days)

Yesterday afternoon we made some additional test to confirm that this additional noise was coming from the new LNFS. 

We used one of the two free output of the LNFS used now for the 22MHz  to generate a twin 56MHz signal to feed *only* the demodulation box (not the EOM). In fig. 1 we can observe that the noise disappears in the LNFS dfreq channel, but not in the EOM one, confirming that there is an issue with this device.

For the time being, the only one possibility left for the generation of the 6/8/56MHz  is to use the LNFS used up to Monday morning, which appeared to be more noisy than usual , but good enough to work on the interferometer.

We replaced the old LNFS at 14.45UTC.

The afternoon and the evening were spent working on Lock recovery up to STEP 3 #69724 (Bersanetti, Spincelli)

Commissioning activity ended at 19:30 UTC

21:00 UTC ITF left in LOCKED_ARMS_IR state and COMMISSIONING mode

Guard Tour

18.35 UTC

After the replacement of the LNFSs to the configuration that was in use last Monday afternoon, we reverted the automation configuration files to the svn snapshot in use at the time , in order to have a usable starting point.

We then proceeded to examine all steps of the lock acquisition from DRMI_1F onwards. We did notice some changes also at that stage, in terms of gains and demodulation phases. As usual, the 3F step was the most impacted.

Then we moved to the CARM/DARM handoffs to the IR, and the following STEP1/2/3 states of the CARM offset reduction, which had to be tuned more heavily.

We consider the recovery relatively reliable up to STEP3, with the following observations:

• MICH is apparently the loop giving more trouble in terms of stability and unlocks; it is also the one that easily gets to higher corrections (also in quiet times), hence the first one to lose control
• PRCL shows downgoing trends at each lock (in terms of UGF) that can be compensated up to a point with the loop gain; the situation is the same in subsequent locks;
• the engagement of DARM back on the IR is statistically not robust, although the loop configuration looks ok; tomorrow we should check better is something is not working of if the weather conditions had some impact (although they were not particularly bad);
• DIFFp has not been checked, and it is now disabled in STEP3 as we wanted not too many things moving at the same time.

The problem of not displaying correctly channels at different sampling frequencies (specifically when a 1 Hz channel is involved) is still present; dataDisplay v11r4 doesn't crash anymore but the visualization still has issues.

This plot , and its zoom,  shows the demodulated signals related to the LNFS generator and the EOM monitoring:

• the  *_raw_dFreq channel is the derivative of phase of the demodulated channel
• Usually the difference between the *_dFreq_min and *_dFreq_max is tiny 
• but around  2026-09-08-18h10m_UTC the first time for a short period  the frequency became different and noisy
  • the *_dFreq red cuves are the *_dFreq  signals low-pass filtered at 300Hz
• and around the 2026-09-08-18h16m_UTC ,the frequency difference and the  noise reappered  to remain :
  • the *_raw_dFreq signal is the derivative of the phase computed with the outputs of the demodulation board
  • the *_phi signal is the phase after the rotation using the LNFS demodulated channels and the *_dFreq the derivative of this phase
  • One can see that the noise is well present on the *_raw_dFreq of  the SIB2_RFC_PD1_6MHz and of the INJ_EAB_EOM_TRA_6MHz an it s not removed by the LNFS rotation 

The last plot shows the LNFS phase noise for the 6Mz and the 56MHz for according the LNFS devce used 

I have calculated the mismatch and throughput losses before and after the intervention.

INJ throughput losses on 07/09 (08:51:40 UTC):

INJ throughput losses on 08/09 (15:02:00 UTC):

Comparing both measurements, we have overall throughput losses increasing of less than 1% while the mismatch increased of roughly 3% after the power decrease. 

In addition to this change of LNFS devices, we had to change also the Lnfs100 server to take into account that we now need to remotely control only one LNFS. In particular, we reverted the python scritp PyLnfs100.py to the version used before the addition of the 81Mhz sideband (back in 2022). 

The server has been restarted and running without troubles since yesterday afternoon.

R. Cavalieri, F. Nocera, P. Spinicelli

Brief recap on recent events and current status concerning our sideband generators a.k.a. LNFS (Spectradynamics' LNFS-100).

We have purchased a total of four identical 3-output synthesizers over the years (starting in 2011) and we have been using two of them at the same time to generate our 4 sideband frequencies for a very long time (the entire O4 and even before that), namely 6, 8, and 56 MHz (Synth1) and 22 MHz (Synth2).

Following Feb 28th blackout, one of the two used syntesizers (Synth1) failed and had to be swapped with a spare (https://logbook.virgo-gw.eu/virgo/?r=68788), let's call it Synth3. The failure consisted in a problem at the power on which has not been observed ever since during the following months of tests and monitoring in the Lab.

Starting on Jul 11th, Synth3 showed "additional noise" on both 6 and 56 MHz (https://logbook.virgo-gw.eu/virgo/?r=69359) and, for that reason, was in turn swapped back with Synth1, on Jul 15th. No tests in the lab have been performed on Synth3 since to verify and understand whether or not the problem was reproducible.

Synth1 too proved to be noisier than one would have liked (https://logbook.virgo-gw.eu/virgo/?r=69656) and therefore the idea of putting in a different one in its place popped up. This was what we set out to do yesterday.

First attempt: we tried Synth3 which worked just fine when in "Local Mode" (i.e., when not controlled via RS-232) but did not when in "Remote Mode", behavior never seen so far. 
Second attempt saw the swap of Synth3 with Synth4, the one we use in our Lab setup to test and characerize RF devices before intergation in Virgo, which failed miserably since the device did not even turn on.

The solution found to allow commissioning activities to go on has been to use Synth2 to generate 6, 8, and 56 and accept temporarily a slightly degraded performance (which has no impact on the ITF performance) on the 22 MHz, now generated with Synth1.

For completeness, it is useful to remind the original (AdV) 22 MHz sideband does not need to have the low phase-noise performance offered by the LNFS-100 and used to be generated with a different, garden variety DDS; we could revert to that at any time if required. As it often happens, at some point in the past we tried out the solution with the LNFS for the 22 "for a test" and we never went back.