Virgo Logbook

AdV-COM (AdV commissioning (1st part) )

casanueva, derossi, masserot - 15:07 Tuesday 11 June 2019 (46076)

Measurement of the slow loop of IMC

This morning we took advantage of the maintenance to make a couple of measurements to try to understand why lately we have been forced to change the crossing point of the SSFS.

The first measurement done was of the transfer function of the slow loop that controls the length of the IMC with the RFC as error signal (Figure 1). The loop was behaving correctly, even if the UGF was slightly low, it was 135Hz, but we can push it up to 180Hz.

The next measurement done was the same trasnfer function but when we use the B4 error signal coming from the SSFS, CARM2MC (Figure 2). This time we saw something strange, since the phase was crossing cero around 190Hz, which is too close to the target UGF, 180Hz. Indeed, the loop oscillated around 175Hz when unlocking several times. If we compare with measurements done in the past we can see that we have lost phase margin, see entry #41595.

The only difference between both loops os the error signal used, so we need to understand where is the extra delay. Alain measured the delay between the Error sginal used at the MC DSP and the one demodulated by the SSFS, and the delay is 200us higher now, while doing the same thing between the error signal used at the MC DSP and the one demodulated at SIB2 there is no extra delay.

We have relocked the ITF like this, but more investigation sare ongoing to try to understand the origin of the extra delay.

Images attached to this report

Comments to this report:

masserot - 10:25 Wednesday 12 June 2019 (46086)

The attached plots show the transfer function at different stage of the pipeline from SSFS -> ISYS_Acl->Sc_MC DS for two values of INJ_IMC_LOCK_sw channels: 1(CARMtoMC), and 2(SSFS) .

For each plots

the first line show the transfer function between SSFS and ISYS_ACL
the second line show the transfer function between ISYS_ACL and Sc_MC DSP
the third line show the transfer function between SSFS and the Sc_MC DSP

I made the plots for different periodes

20190411-09h27mxxUTC : CARMtoMC delay 1/1088s - SSFS delay 1/1753s
20190511-22h54mxxUTC : CARMtoMC delay 1/1247s - SSFS delay 1/2151s
20190610-22h56mxxUTC : CARMtoMC delay 1/1086s - SSFS delay 1/1753s
20190611-01h34mxxUTC : CARMtoMC delay 1/1088s - SSFS delay 1/1753s
20190611- 12h13mxxUTC : CAMRtoMC delay 1/1088s - SSFS delay 1/1753s

According these measures, there is no additional delay in the SSFS->ISYS_Acl->SC_MC pipeline since the beginning of the O3 run.

One can see that one time, the 20190610-22h56mxx in the CARMtoMC transition the coherence between SSFS output channel and ISYS_Acl input channel is degraded related to the others times

Images attached to this comment

46086_1560326618_SSFS_MC_TF_20190411-09h27m10_IMC_LOCK_1.png

46086_1560326618_SSFS_MC_TF_20190411-09h27m20_IMC_LOCK_2.png

46086_1560326690_SSFS_MC_TF_20190511-22h54m00_IMC_LOCK_1.png

46086_1560326691_SSFS_MC_TF_20190511-22h54m20_IMC_LOCK_2.png

46086_1560326792_SSFS_MC_TF_20190610-22h56m23_IMC_LOCK_1.png

46086_1560326793_SSFS_MC_TF_20190610-22h56m40_IMC_LOCK_2.png

46086_1560326875_SSFS_MC_TF_20190611-01h34m23_IMC_LOCK_1.png

46086_1560326875_SSFS_MC_TF_20190611-01h34m40_IMC_LOCK_2.png

46086_1560326985_SSFS_MC_TF_20190611-12h13m35_IMC_LOCK_1.png

46086_1560326985_SSFS_MC_TF_20190611-12h13m42_IMC_LOCK_2.png

casanueva - 10:48 Wednesday 12 June 2019 (46087)

Yesterday I adjusted the model of the IMC length loop to match the delay that we observed last year, and the extra one needed to fit the measurement of yesterday. Figure 1 shows the phase behaviour in both cases. From the model it is necessary to add more or less 250 us to match the new delay. So for the moment the only thing we can say is that there is 250us of extra delay in the loop, now we need to understand where does it come from and if it is present all the time.

Images attached to this comment