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.
 

The first part of the shit was dedicated to the LNFS replacement.

After that the commissioning team worked at the CARM NULL recovery; activity concluded at around 19:00 UTC.

At 19:33 UTC the ITF was set in NI single bounce for 5 minutes.

ITF left in LOCKED ARMS IR.

SUSP

SR LC opened by the guardian at 16:00 UTC; properly closed.

After the LNFS replacement we started the recovery of the interferometer.

Despite the smooth operations of yesterday evening, today's shift was plagued by a variety of instabilities that always manifested differently: high gain oscillation of PR_TX, low gain oscilation of MICH and other similar effects that did not repeat sistematically at each lock.

At the end of the shift the 11.6 Hz vertical (bounce) motion of the PR was excited and prevented us from proceeding further with the recovery (Fig.1). We changed the damper gain to solve this issue (default: -0.017, changed between -0.014 to -0.025 to no avail).

The recovery will continue tomorrow.

The thresholds used for the definition of the QPD_B1s flag have been update in DetMoni. The checks on the B1s centering and the status of the galvo loop will be performed only after the state "SHUTTER OPEN".

Still digging in the data of July 28^th switch off, we further characterize acoustic noise entering the INJ room from outside. This investigation profits for the very low noise condition while the INJ HVAC was off.

A first point is the noise that enters from the Atrium. Figure 1 shows the effect of opening the Atrium door. There is a broadband noise increase of sound and vibration noise above 100Hz, particularly enhanced between 500 and 600 Hz (a factor 10) and the amplification of some narrow lines (105, 134 ... 290 ... 1010, 1048 Hz) which are indicated in Figure 2 with red markers.  For accelerometers see Figure 9. Inspecting this morning with Suzanne, we verified that the main (and seems only) sound source in the Atrium is the cooling fan of the ALS amplifier module (see Picture).   

The second  point is shown in Figure 4: note that structures between roughly 100 Hz and 1kHz in the acoustic and bench vibrations have large coherence with the IB tower vibration (sensor ENV_IB_ACC_X). We think this noise is related with the Turbo pump, as reported in these old tests (5 yrs ago.. and it seems yesterday!): elog 52500, this Figure  

Figure 4 also shows coherence with IB tower vibration in the region 1-3 kHz, that highligted in red circle. This is most probably noise from racks. Although we have not able to identify them: also the microphone placed on the platform near SIB1 tower does not show enhanced and coherent noise at these frequencies. And no evidence from EEroom microphone either.

Last point concerns the noise entering from EEroom: it is a triplet of acoustic lines (also with seismic counterpart) between 44 and 48 Hz  (Figure 5) and one important peak at 60Hz (Figure 6): all of them more intense in EEEroom mic.

The quadrant photodiode acquiring previously the B5_QD2 beam is now used to acquire the B1s_QD1 beam .

To be compliant with the new name of the beam, we  proceeded with the renaming of the B5_QD2 channels to B1s_QD1 channels .

The operations were performed between 2026-09-08-06h39m28-UTC and 2026-09-08-09h18m52-UTC 

Below the details of the operations performed:

• SDB2_dbox_bench server
  • DBox SN106 - demodulation mezzanine SN87
    • rename  as SDB2_DEMOD_B1s_QD1 instead of  SDB2_DEMOD_B5_QD2 previously
    • add the demodulation of the B1s_QD1 beam at  6MHz, 50MHz, 56MHz and 112MHz  for the 4 quadrant sectors
  • DBox SN007 - ADC2378 mezzanine SN43
    • renamed as  SDB2_ADC_B5_B1s_QD instead of SDB2_ADC_B5_QD previously
    • add the readout of the B1s_QD1_{H,V,SUM} channels  instead of the B5_QD2 ones
• SDB2_Tpro server and SDB2_ Fb server
  • Replace the old Tolm packets' name by the new ones
• SDB2_Quadrants  server 
  • Remove all the functionalities related to the B5_QD2 quadrants channels 
  • Add the last part of the demodulation of the B1s_QD1_{6,50,56,112}MHz channels
  • Add the B1s_QD1 galvo loops part
• SDB2_readout server
  • swap the B5_QD2 channels with the B1s_QD1 ones
• QPDMoni server
  • change the name associated to the interface ethmt7-2011 as B1s_QD1 instead of B5_QD2
• ASC_Acl server
  • the internal channels labelled B1s_QD1 are build using the SDB2_B1s_QD1 input channels
  • the internal channels labelled B1s_QD2 are build using the EDB_B1s_QD2 input channels
  • the B5_QD2 channels used in the TX_SENSING matrix and in the TY_SENSING matrix have been replaced by the B1s_QD1 respective channels
• Automation servers. ARMS_LOCK, DRMI_LOCK,
  • The related python config files have been updated by commenting the parts related to the SDB2_B5_QD2 quadrants 
• DetMoni server
  • all the parts related to the B5_QD2 quadrant photodiode have been commented
  • the monotoring part related to the B1s_QD1  quadrant photodiode have been added and remains to be tuned
  • A new flag B1s_QD1 has been in the DMS interface : the DMSserver server has been restarted to take in account this modification