LOG-IN
Displaying reports 1-25 of 34998.Go to page 1 2 3 4 5 6 7 8 9 10 End
AdV-COM (AdV commissioning (1st part) )
Print this report.
swinkels, martynov, hoak, ruggi - 00:59, Saturday 27 May 2017 (37765)Get code to link to this report
Comment to noise investigations -- first shot at beam jitter coupling (Click here to view original report: 37762)
Attached some more plots related to the alpha tuning: Fig 1, 2 and 3 show the longitudinal noise budget before tuning, after tuning and after increasing the roll-off of PRCL. Implementing a subtraction of PRCL noise should be done soon. Fig 4 shows that we reached a surpression close to a factor 100, but the coherence gets so low that the estimate might not be accurate. Fig 5 shows the difference between the online suppresion (as visible in the disappearing bump around 25 Hz) and the suppression in Hrec.
Images attached to this comment
37765_20170527005736_nbold.png 37765_20170527005744_nbnew.png 37765_20170527005754_nbnewprclrolloff.png 37765_20170527005800_suppression.png 37765_20170527005812_alphadarmhrec.png
AdV-COM (AdV commissioning (1st part) )
Print this report.
ruggi - 00:50, Saturday 27 May 2017 (37763)Get code to link to this report
noise correlated to B1p_DC fluctuations

It can be useful to identify the structures in the sensitivity which amplitude depends on B1p alignment. It is not so hard, because there are periods lasting some tens of seconds with low level of B1p_DC (for example, 1179866636, lasting 40 s). Comparing the spectrum of DARM that condition to a normal condition (Fig. 1), many differences are visible.

The rms of one of that structures (193 Hz) has been computed during 1800 seconds of lock (one point each 5 seconds). The result has been superposed to the time series of B1p_DC square (Fig. 2). The correlation is almost perfect.

Images attached to this report
37763_20170527004010_b1plow.jpg 37763_20170527004021_bandrms193.jpg
AdV-COM (AdV commissioning (1st part) )
Print this report.
swinkels - 00:34, Saturday 27 May 2017 (37764)Get code to link to this report
IMC systematically unlocking after the interferometer
Looking into some issues with the FMOD_ERR, I found that the IMC is surviving the unlock of the interferometer in most cases, but is systematically unlocking a few seconds later, see attached figure. It seems that the SSFS is correctly switched off, but something fishy is going on with the correction sent to the MC end mirror. I find at least line 450 of ISYS_Acl suspect, which calculates a flag for the MC DPS (0 = Control by RFC, 1 = CARM2MC, 2 = SSFS, 3 = SSFS+Boost):

ACL_OP_CH IMC_LOCK_SW "V" "sum+" MC_LOCK_ON SSFS_LOCK_ON SSFS_BOOST_ON

It seems that MC_LOCK_ON (which is equal to and SSFS_LOCK_ON do both correctly go to zero at the moment of the unlock, while SSFS_BOOST_ON, which is derived from the channel SSFS_B4_selectFilter in SSFS_Ctrl, only goes to zero a few seconds later (when metatron detects the unlock?). The result of this is that the MC DSP thinks we are still using CARM2MC, so it is sending all the junk from the unlock to the MC mirror for a few seconds, which causes a huge kick. This bug costs maybe half a minute for every unlock of the interferometer, since it sometimes triggers the alignment instability of the IMC. It was probably also the cause for an issue with the FMOD_ERR macro, which did not check for an unlock of the IMC, so it sometimes started a measurement while the IMC was still recovering from the unlock. Fixing this should be trivial, but I leave it to INJ/SSFS experts for fear of messing up the complex logic.

Something else curious is that SSFS_SelectFilt0 is not zero but a very small number. This might be an artifact of the decimation, but if this channel is used to reset the filter when it is equal to zero, it might never do the reset. To be checked by the experts.

Images attached to this report
37764_20170527003311_imcunlock.png
AdV-COM (AdV commissioning (1st part) )
Print this report.
hoak, martynov, swinkels, ruggi, carbognani - 00:32, Saturday 27 May 2017 (37762)Get code to link to this report
noise investigations -- first shot at beam jitter coupling

Tonight we made a number of simple investigations of the noise:

  • Paolo fixed the SSFS glitches by switching back to the 2nd order boost.  This wasn't a problem for the rest of the night.  It looked like these glitches were happening on the integer second boundaries, so we suspected a cm command like the digital noise reset, but this 1) didn't seem to cause a glitch, and 2) doesn't necessarily happen on integer seconds.
  • We tried changing the OMC dither amplitudes, by up to a factor of 100.  This didn't change anything in the noise.  The OMC1 locking wasn't so happy with the dither line reduced by 100x, probably switching this loop to B1_DC will help (we did not try this).
  • OMC1 locking still required some help.  It looks like it is stopping the ramp just barely before the cavity reaches the full fringe, or it gives up due to flickers in the transmitted light power.
  • Bas improved the alpha tuning, which has now completely eliminated the MICH coherence with DARM.  This is not reflected in the calibrated strain channel.  We need to share MICH subtraction filters so that we aren't doing the same job twice.
  • We made a new PRCL control filter with a more aggressive rolloff, designed for a UGF of 25Hz. We gave the filter a try, but it didn't change the noise.
  • Turning off the MICH, PRCL, and DARM lines gave us another Mpc or so.  The sidebands of the DARM line are particularly bad.
  • Moving to LOW_NOISE_2 did not change the shape of the noise between 10 and 100Hz.  This should have reduced the DAC noise by 20x.  This transition was only 50% successful tonight, we might try some handoff tricks to make sure this switch is 100% successful.
  • Noise injections on the BPC gave some evidence that beam jitter noise might be within a factor of ten of the current noise floor, see below.

 

=== BPC Noise Injections ===

We made some quick injections to the BPC TX and TY dofs.  We were able to see a clear effect on DARM (and more in PRCL and the SSFS), see Figures 1 and 2.  The noise injections should be valid for +/- 25 seconds around the time of the plot.  It looks like the TX coupling is worse than TY, but they both could be too close for comfort.

A quick transfer function of BxC TX to DARM (Figure 3) shows the coupling in the 100-1000 Hz band is more than 1e-4.  A very simple projection (using 2e-4 coupling) shows the noise is not far below the DARM spectrum in this region, see Figure 4.  However, there is not usually any coherence between DARM and these channels, see Figure 5.  Anyways, we should make a careful set of BPC injections to all four dofs (TX TY X Y) and build a noise budget.

Images attached to this report
37762_20170527002453_bpctx26may.png 37762_20170527002458_bpcty26may.png 37762_20170527002502_bpctxtodarm.png 37762_20170527002506_bpctxproj.png 37762_20170527003012_bpcdarmcoh.png
Comments related to this report
swinkels, martynov, hoak, ruggi - 00:59, Saturday 27 May 2017 (37765)
Attached some more plots related to the alpha tuning: Fig 1, 2 and 3 show the longitudinal noise budget before tuning, after tuning and after increasing the roll-off of PRCL. Implementing a subtraction of PRCL noise should be done soon. Fig 4 shows that we reached a surpression close to a factor 100, but the coherence gets so low that the estimate might not be accurate. Fig 5 shows the difference between the online suppresion (as visible in the disappearing bump around 25 Hz) and the suppression in Hrec.
Images attached to this comment
37765_20170527005736_nbold.png 37765_20170527005744_nbnew.png 37765_20170527005754_nbnewprclrolloff.png 37765_20170527005800_suppression.png 37765_20170527005812_alphadarmhrec.png
AdV-COM (AdV commissioning (1st part) )
Print this report.
ruggi - 23:29, Friday 26 May 2017 (37758)Get code to link to this report
Some noise from SDB1 LC

With low MICH noise, some structure due to SDB1 motion excited by the controls are again visible.

Fig 1 is the TF of SDB1_LC_TX_corr. The main structure is the already seen 29.7 Hz resonance.

Fig 2 is the TF of SDB1_LC_TY_corr. There is a peak at 89 Hz and a low broadband coherence up to 300 Hz.

The coupling depend poor stability of B1p power, and will be lower when an alignment based on B1p quadrant will work, but it would be nice to reduce more SDB1 LC correction.

Images attached to this report
37758_20170526231730_sdb1tx.jpg 37758_20170526231738_sdb1ty.jpg
AdV-COM (AdV commissioning (1st part) )
Print this report.
swinkels, ruggi, carbognani - 23:27, Friday 26 May 2017 (37759)Get code to link to this report
Comment to MICH noise versus FmodERR (Click here to view original report: 37751)
The manual procedure was roughly: unlock the RFC, increase the line amplitude, and move the MC top stage to zero FMOD_ERR. After that, unlock the IMC, set the master laser thermal correction to the value when it was last locked to the RFC, and relock everything. Any residual mistuning could in future be nulled by tuning the modulation frequency once locked, but for now this causes an unlock in the SSFS. Something similar should be implemented in Metatron.

The mistuning of 80 and 260 um of the IMC length should correspond to a mistuning of the 56 MHz of respectively 30 and 100 Hz.
Detector Operation (Operations Report)
Print this report.
Gherardini - 23:04, Friday 26 May 2017 (37757)Get code to link to this report
Operator Report - afternoon shift 26/05
This afternoon shift was dedicated to locking, automation and mich noise investigation; the work went on without any major problem with the itf locked up to low_noise_2 configuration.
Nothing else to report, the activity is still in progress...
AdV-COM (AdV commissioning (1st part) )
Print this report.
ruggi - 22:43, Friday 26 May 2017 (37755)Get code to link to this report
naive projection of frequency noise

Even with a 2nd order boost on SSFS, frequency noise is not yet limiting so much the sensitivity.

Fig. 1: SSFS error signal rescaled by a constant value  in order to match the sensitivity in some point, in the frequency range 1KHz - 3kHz

Fig. 2: coherence between SSFS Err and DARM, in the frequency range 1KHz - 3kHz

Fig. 3: SSFS error signal rescaled by the same value, in the frequency range 100 Hz - 1kHz

Fig. 4: coherence between SSFS Err and DARM, in the frequency range 100 Hz - 1kHz

Below 900 Hz there is a relevant coherence only at 340-350 Hz, and the projection matches the sensitivity using the same scaling factor which works above 1 kHz.

Images attached to this report
37755_20170526222544_ssfsproj.jpg 37755_20170526222551_ssfscohe.jpg 37755_20170526222559_ssfsproj1.jpg 37755_20170526222608_ssfscohe1.jpg
AdV-COM (automation)
Print this report.
carbognani, hoak, mantovani - 22:10, Friday 26 May 2017 (37754)Get code to link to this report
Automatic tuning of the demodulation phase of B4 56MHz
Tired of keep doing it manually, today we have introduced in ITF_LOCK an automatic tuning of the demodulation phase of B4 56MHz.

The tuning is performed at the end of the LOCKED_SSFS state.
An average over 10 samples of LSC_B4_56MHz_DPHI, monitoring the deviation from the optimal phase, is made with a buffer reinitialized if the the SSFS_LINE coherence (LSC_SSFS_LINE_COH) is not good for a 1 sec sample.

Once a meaningful value for LSC_B4_56MHz_DPHI is obtained then this is added to the actual value of the demodulation phase SSFS.B4_56MHz_phi0_offset to obtain the new setpoint.
Then the newly calculated setpoint is written back into SSFS.B4_56MHz_phi0_offset and saved permanently in the CARM_DARM_LOCK.ini config file as B4_dphi.
The new value of B4_dphi will be taken in account at the next transition to LOCKING_CARM_TO_MC.

The behavior of this new strategy has been checked over few transition through LOCKED_SSFS and seems fine.

Images attached to this report
37754_20170526220647_b4phi.jpg
AdV-INJ (Input Mode Cleaner cavity)
Print this report.
carbognani, mantovani, ruggi, swinkels - 21:20, Friday 26 May 2017 (37752)Get code to link to this report
Comment to FmodErr: tuning of the modulation frequencies update (Click here to view original report: 37614)

This week we have been working further on the new FModErr strategy:

  • First the problem of incorrect transitions, reported in this entry should have been fixed by forbidding redirection on all states involved in the FModErr sequence. This can bee seen on the updated state transition diagram (Fig. 1) were all states involved in the FModErr can now be identified by the red border (specific of a state in which redirect is set to False).
  • Two different thresholds on FModErr has been introduced: fmod_tol_z (8e-5) for MC_F0_Z tuning and fmod_tol_f (2e-5) for Frequency tuning
  • A 8MHz_reference (8361036.0 Hz) and a threshold have been introduced to avoid moving away too much with the nominal frequency. In case the newly calculated frequency is max_freq_corr (50Hz) away from 8MHz_reference then the frequency is set back to the reference

Trying to engage  the frequency tuning we encountered again the problem mentioned in this entry and we were unlocking while reaching LOCKED_CARM_TO_MC (See Fig. 2)

Today we have retuned the thresholds for the thermal correction reset. We also realized that a protection must be introduced against IMC unlock. The whole FModErr strategy is also  being revised

Images attached to this comment
37752_20170526211440_noredirectinjmain.jpg 37752_20170526211449_carmtomcunlock.jpg
AdV-COM (AdV commissioning (1st part) )
Print this report.
ruggi - 21:16, Friday 26 May 2017 (37753)Get code to link to this report
Comment to glitches on SSFS_Corr (Click here to view original report: 37732)

The glitches are still there, so we decided to use a 2nd order boost.

AdV-COM (AdV commissioning (1st part) )
Print this report.
ruggi,swinkels,carbognani - 21:10, Friday 26 May 2017 (37751)Get code to link to this report
MICH noise versus FmodERR

We found a method to perform by hand a fine tuning of IMC length which minimize  Fmod ERR. In figure we see MICH noise when IMC length is good, compared to the case of 80 um and 260 um of mistuning. The experiment confirms that the high level of MICH noise depend on the mistuning of modulation frequency with respect to IMC length.

Images attached to this report
37751_20170526210129_fmoderr.jpg
Comments related to this report
swinkels, ruggi, carbognani - 23:27, Friday 26 May 2017 (37759)
The manual procedure was roughly: unlock the RFC, increase the line amplitude, and move the MC top stage to zero FMOD_ERR. After that, unlock the IMC, set the master laser thermal correction to the value when it was last locked to the RFC, and relock everything. Any residual mistuning could in future be nulled by tuning the modulation frequency once locked, but for now this causes an unlock in the SSFS. Something similar should be implemented in Metatron.

The mistuning of 80 and 260 um of the IMC length should correspond to a mistuning of the 56 MHz of respectively 30 and 100 Hz.
AdV-DET (Commissioning)
Print this report.
bersanetti, ruggi - 18:03, Friday 26 May 2017 (37750)Get code to link to this report
Comment to RFC at 8Mhz and B1p at 112 Mhz (Click here to view original report: 37739)

We acquired the new RFC_8MHz_I channel into LSC_Acl and used it to restore the CARM_SLOW loop; its phase has been adjusted and the value saved in the SIB2_Photodiodes process. Then we closed the loop and it worked with the same parameters as with the 6MHz error signal, as their SNR are similar, but we needed to add a little offset to the loop (-0.035) after looking at the signal when the RFC was still locked on the INJ side.

However we noted that such loop, which has not been optimized for noise/science mode yet, quite spoiled the correction on the ITM in the region where the dither lines are (see the Figure, purple is with loop engaged). Therefore we disabled it for the time being but we can now work on its improvement and test it during lock acquisitions.

Images attached to this comment
37750_20170526180315_carmrfccorr.png
AdV-COM (AdV commissioning (1st part) )
Print this report.
bersanetti - 17:55, Friday 26 May 2017 (37749)Get code to link to this report
Comment to SSFS Shift (Click here to view original report: 37737)

This morning the communication and missing data issues of SSFS were still present; some checks and fixes were made by Alain, who also restored a newer version of Acl for SSFS_Ctrl, then an additional tuning in the SSFS_dbox configuration and a restart of the SSFS_Ctrl process to force a re-synchronization made the system working again with no data loss; the glitches are still present, but they seem less severe.

AdV-INJ (Beam Pointing Control)
Print this report.
genin, pillant, paoletti, derossi - 16:32, Friday 26 May 2017 (37726)Get code to link to this report
noise in the correction signal sent to the piezo of the BPC loop
Since it has been noticed some coupling between the piezo corrections of the BPC and the dark fringe signal when the ITF is locked (last plot), we tried to investigate the possible sources. We found out that the correction signal which is sent to the piezo is very noisy in the peak at 50 Hz and its harmonics.

Yesterday morning we made some in parallel measurements of the correction signal sent to the piezo. Even though a resistance has been put in series with the piezo to filter out the higher frequencies (first plot), the amplitude of the harmonics which is directly sent to the piezo is still high (second plot). It will probably excite some resonances of the piezo, and could then be injected in ITF signal as beam jitter.

We conclude that the dac introduces noise in the way it is connected now (last plot) and we are currently working on a solution to improve this signal.
Images attached to this report
37726_20170526104851_lowpassfilter.png 37726_20170526104903_pztdrvoutputafterr.png 37726_20170526111925_noisefromdac.png 37726_20170526121238_gps1179651093coherbsxvslscmichzoom.gif
Detector Operation (Operations Report)
Print this report.
Montanari - 16:00, Friday 26 May 2017 (37748)Get code to link to this report
Operator Report - Morning Shift 26/05
This morning I found ITF and RFC unlocked due to B.Mours' remote activity (at 7:20LT). E.Jules restore the RFC at 8:40LT.
At the beginning we had some troubles in going on with the lock, so M.Mantovani started to investigate and finally at around 10:30LT we succeeded to lock in low_noise_1 and works on alignment and noise injection started. Still in progress
The lock stability was not so good this morning
AdV-COM (AdV commissioning (1st part) )
Print this report.
genin - 15:26, Friday 26 May 2017 (37747)Get code to link to this report
B2_PD1 shutter closed since the 24th of May.

I found that there is no light anymore on  B2_PD1 photodiode (see first plot).

Looking at the VPM I found the shutter closeda nd the vbias off.

I have open the shutter and rearmed the Bias at approximately 15.24LT.

Now everything is back to normal as you can see on the seocnd plot.

Images attached to this report
37747_20170526150903_b2pd1.gif 37747_20170526152542_openshutter.gif
AdV-DET (Output mode cleaner)
Print this report.
mwas - 15:12, Friday 26 May 2017 (37746)Get code to link to this report
OMC locking point change with laser thermal correction
As a follow up to Thursday morning OMC locking troubles. As Bas noted before. The OMC temperature lock point depends on the master laser correction BsX_ML_TH_CORR. During Wednesday night the correction jumped for 1 hour lock, which change the OMC lock point from ~22.71 to ~22.73, and then the OMC saved that value and was trying to lock starting the ramp from 22.72 degrees, so above the resonance that went back to ~22.71 degrees.
Images attached to this report
37746_20170526145945_screenshotfrom20170525202025.png
AdV-COM (AdV commissioning (1st part) )
Print this report.
trozzo,majorana,ruggi - 13:39, Friday 26 May 2017 (37745)Get code to link to this report
Angular control noise budget (OpLev)
We have estimated the residual motion of the arm mirrors due to the angular controls using optical levers.
In order to tune the contribution of the angular correction on the DARM, we have matched the actual amplitude of the drift control lines used in the automatic alignment.
In the figure we can see also the nominal displacement sensitivity for both steel and fused silica suspensions;
we notice that:

-at the moment the angular noise budget is well below DARM; just below 10 Hz (almost 6-8 Hz) it gets closer to DARM (due to known effects related to cryotraps on the NARM)
- above 10 Hz pitch is 50 times noisier than yaw. Moreover, pitch contribution is above the nominal sensitivity expected for O2 ( it should be improved ).
Images attached to this report
37745_20170526133511_oplevnb.png
Environmental Monitoring (Environmental Monitoring)
Print this report.
koley, fiori - 12:41, Friday 26 May 2017 (37744)Get code to link to this report
Investigating the 107 Hz Noise Trend in LSC_MICH signal
The LSC_MICH signal during the C8 run starting GPS second 1178033418 was analyzed with respect to the noise that was observed around 107 Hz with an approximate width of 2 Hz around it.

Figure psdtrend.png shows the PSD computed for a 10000 second stretch of data, during a good lock period, and the trend of the noise is picked.
Steps to compute the trend-
1) PSD is computed in 20 second windows with 8 averages and an overlap of 50 %
2) The peak frequency from the PSD is extracted in the frequency band 105-109 Hz for every 20 second window.
3) The resulting trend of the peak frequency that is extracted has a sampling frequency of 0.05 Hz.
4) The peak frequency of this trend is observed around 0.0017 Hz, or approximately has a cycle length of 600 s.
5) For getting this low frequency trend out, a low pass equi-ripple FIR filter with a corner frequency of 0.0035 Hz is applied to the trend.

freqtrendandheaterpresout.png subplot(1) shows the smoothed trend in red and the raw signal with high frequency noise in blue.

The smoothed trend was henceforth subject to cross correlation analysis, for obtaining a dependence with several other channels.

A total of 14000 channels were tested against the observed trend.

A good correlation was observed for a period of 19000 seconds with the pressure variation of the channel named as V1:INF_WEB_HEATER_PRES_OUT. Figure 3 attached shows a scatter plot of the two quantities, which is frequency vs the pressure. An approximate linear dependence was observed.

For further verification of whether the WEB_HEATER pressure changes was responsible for the noise, we propose to switch it off for an hour or so, and observe if the 107 Hz noise pattern changes.
Images attached to this report
37744_20170526123412_psdtrend.png 37744_20170526123439_freqtrendandheaterpresout.png 37744_20170526123450_freqvspreswebheaterscatter.png
AdV-DET (Commissioning)
Print this report.
mantovani - 10:17, Friday 26 May 2017 (37742)Get code to link to this report
Comment to RFC at 8Mhz and B1p at 112 Mhz (Click here to view original report: 37739)

It has been finely tuned at 1.9066 rad

AdV-DET (Commissioning)
Print this report.
mours - 09:31, Friday 26 May 2017 (37741)Get code to link to this report
Checking photodiode shutter reliability

To investigate the reliability of the photodiode shutter, I looked at the B7/8_PD1 shutters that are closed during a lock sequence. The first figure is showing the counter of the number of closure over a bit less than a month. This counter is reset when the monitoring program is restarted. We are close to one thousand cycles over one month.

The second figure is showing a typical lock sequence. The top plot shows the power seen by both photodiodes (PD2 was rescale by a factor 13 to compensate for the splitter and match PD1). When PD1 reach about 8 mW, its shutter is closed, so there is no more power on this photodiode, and then the locking sequence continue with more power on PD2. The bottom plot is the shutter count. Since this count is sample only every 5 seconds by the slow frame builder the step of the counter do not exactly time match the power drop on PD1.

The third figure is showing the power measured before a step in the shutter counter and after the step (taking few seconds of margin given the poor timing resolution of the shutter counter) for all closure events with at least 1 mW before closure. This corresponds to 954 closures. For all cases, the power after closure is very small showing a success rate of 100% for this shutter.

The last figure is the same plot for B8_PD1. We have the same number of events (the shutters are closed when both arms are locked), with again 100% of success.

This kind of analysis is more difficult to do for the B1 photodiode since after a closure, there is no more power. But the fact that B1_PD2 was not damaged given the many unlock events we had, while B1_PD1 was damaged after a few unlocks, combined with the B7/B8 results, is showing that either a shutter (and its driving electronic) is working reliably for a thousand of cycles (or more) or it will show problem very quickly.

Images attached to this report
37741_20170526092828_b7b8closingcount.png 37741_20170526092848_closingb7.png 37741_20170526092858_b7pd1.png 37741_20170526092908_b8pd1.png
AdV-DET (Commissioning)
Print this report.
genin - 08:41, Friday 26 May 2017 (37740)Get code to link to this report
Comment to RFC at 8Mhz and B1p at 112 Mhz (Click here to view original report: 37739)

The RFC didn't relock after this operation. I had to change de demodulation phase from -2.229 to 1.529 rad.

ACL_CONST_CH    RFC_6MHz_phi0     "rad" 0      LOOP_FREQ 1.529 #-2.229

I have not fine tuned the demodulation phase but it was enough to relock the RFC and lock the 3km arms.

AdV-DET (Commissioning)
Print this report.
mours - 07:53, Friday 26 May 2017 (37739)Get code to link to this report
RFC at 8Mhz and B1p at 112 Mhz

The RFC 8 MHz signals has been added this morning as well as the B1p_PD2_112MHz_mag signal.

Comments related to this report
genin - 08:41, Friday 26 May 2017 (37740)

The RFC didn't relock after this operation. I had to change de demodulation phase from -2.229 to 1.529 rad.

ACL_CONST_CH    RFC_6MHz_phi0     "rad" 0      LOOP_FREQ 1.529 #-2.229

I have not fine tuned the demodulation phase but it was enough to relock the RFC and lock the 3km arms.

mantovani - 10:17, Friday 26 May 2017 (37742)

It has been finely tuned at 1.9066 rad

bersanetti, ruggi - 18:03, Friday 26 May 2017 (37750)

We acquired the new RFC_8MHz_I channel into LSC_Acl and used it to restore the CARM_SLOW loop; its phase has been adjusted and the value saved in the SIB2_Photodiodes process. Then we closed the loop and it worked with the same parameters as with the 6MHz error signal, as their SNR are similar, but we needed to add a little offset to the loop (-0.035) after looking at the signal when the RFC was still locked on the INJ side.

However we noted that such loop, which has not been optimized for noise/science mode yet, quite spoiled the correction on the ITM in the region where the dither lines are (see the Figure, purple is with loop engaged). Therefore we disabled it for the time being but we can now work on its improvement and test it during lock acquisitions.

Images attached to this comment
37750_20170526180315_carmrfccorr.png
AdV-COM (AdV commissioning (1st part) )
Print this report.
bersanetti, ruggi, heitmann, fidecaro, cohen - 01:39, Friday 26 May 2017 (37737)Get code to link to this report
SSFS Shift

Today's shift has been about several tests and possible optimizations for the SSFS, here are the main points:

  • we did more tests on the gain margin we have with the new rolloff at 50 kHz for the boost filter; we could easily use up to double the standard gain (i.e. 1800) without gain peaking or unlocking; the improvement was visible on the fly on the error signal, but a proper estimation has still to be done, because of the glitches reported in #37732; also, a more precise noise projection on DARM could not be done in order to estimate the real improvement of the frequency noise suppression on the sensitivity;
  • during all day we saw a much worse performance of the CARM_TO_MC loop, leading also to several unlocks before the engagement of the SSFS; we found that such loop was saturating the correction on the IMC; as reported, this could be a side effect of the realignment of the beam from the PSL to the EIB, as this CARM loop is very sensitive to gain variations; we reduced both CARM_MC_GAIN in LSC_Acl and IMC_cal in ISYS_Acl from -2.1e-5 to -1.8e-5, and the loop is now working as expected;
  • at this point we tried to repeat the boost filter changes we already tried: we moved the boost filter's zeros from 500 Hz and 1000 Hz to 750 Hz and 1500 Hz respectively. This time the change did not have any side effect in the first part of the lock acquisition procedure, so we could test it:
    • the first trials were not successful, as the transition was for some reason too abrupt and either it broke the lock or triggered oscillations in MICH, which is suspicious since it is the other quadrature of the SSFS signal (example in Figure 1); we found out that putting a rising time of 0.01 on the SSFS_B4_selectFilter RELAY_CH mitigated such effect, and we managed to engage the new boost; notice that using such rising time reduced the overshoot of the flag itself (which we could see transition from 0 to ~ 1.2 on the rising edge, and from 1 to ~ -0.2 on the falling edge);
    • we then suffered several unlocks (always with the boost filter on) shortly after engaging the boost filter itself; looking at the data we found out that the SSFS signals were absent for around 1 second every time shortly before the unlock itself (see Figures 2, 3, 4); this was confirmed by the SSFS_Ctrl process' log file, which stated:
      • 2017-05-25-19h21m33-UTC>WARNING-AcAdcChCheck> B4_Err_pre - start delayed or missing at GPS1179775310-090018650
        2017-05-25-19h21m33-UTC>WARNING-AcAdcChCheck> B4_Err_Q - start delayed or missing at GPS1179775310-090018650
        2017-05-25-19h21m33-UTC>WARNING-AcAdcChCheck> B4_Err_post - start delayed or missing at GPS1179775310-090018650
        2017-05-25-19h21m33-UTC>WARNING-AcAdcChCheck> B4_Flt0Out - start delayed or missing at GPS1179775310-090018650
        2017-05-25-19h21m33-UTC>WARNING-AcAdcChCheck> B4_Flt1Out - start delayed or missing at GPS1179775310-090018650
        2017-05-25-19h21m33-UTC>WARNING-AcAdcChCheck> B4_Corr - start delayed or missing at GPS1179775310-090018650
        2017-05-25-19h21m33-UTC>INFO...-CfgReachState> Active(Active) Ok
        2017-05-25-19h21m34-UTC>WARNING-AcAdcChCheck> B4_Err_pre - SSFS_B4_Err_pre_DS delayed or missing from GPS1179775310-090018650 for more or less 1.0044(s) - nLoop 45501@50000Hz
        2017-05-25-19h21m34-UTC>WARNING-AcAdcChCheck> B4_Err_Q - SSFS_B4_Err_Q_DS delayed or missing from GPS1179775310-090018650 for more or less 1.0044(s) - nLoop 45501@50000Hz
        2017-05-25-19h21m34-UTC>WARNING-AcAdcChCheck> B4_Err_post - SSFS_B4_Err_post_NS delayed or missing from GPS1179775310-090018650 for more or less 1.0044(s) - nLoop 45501@50000Hz
        2017-05-25-19h21m34-UTC>WARNING-AcAdcChCheck> B4_Flt0Out - SSFS_B4_Flt0Out_NS delayed or missing from GPS1179775310-090018650 for more or less 1.0044(s) - nLoop 45501@50000Hz
        2017-05-25-19h21m34-UTC>WARNING-AcAdcChCheck> B4_Flt1Out - SSFS_B4_Flt1Out_NS delayed or missing from GPS1179775310-090018650 for more or less 1.0044(s) - nLoop 45501@50000Hz
        2017-05-25-19h21m34-UTC>WARNING-AcAdcChCheck> B4_Corr - SSFS_B4_Corr_DS delayed or missing from GPS1179775310-090018650 for more or less 1.0044(s) - nLoop 45501@50000Hz
  • since this problem is new and nothing else changed in the meantime, we tried to revert the Acl version used for the SSFS_Ctrl process to the older v0r34p2 which was used before; after this change, we witnessed far less data losses (1 as I'm writing), so we left the older Acl version in VPM (for SSFS_Ctrl only);
  • we used a simpler 2nd order boost filter for a 'natural' frequency noise injection in order to see the effects on the sensitivity and other loops; see the dedicated entry;
  • given the various issues, we decided to reinstate the configuration with the old boost filter and the old Acl version, since this seems the configuration that works the best;

Some side notes:

  • we had to change both the B4_56 demodulation phases continuosly during the whole shift (see Figure 5); in absolute value the changes seem not too big, but they were high enough to almost completely mix the I and Q signals;
  • later during the evening, the glitches we often observe at MICH_SET = 0.1 were higher and caused more unlocks; to be better understood;
  • during the shift it was planned the test and implementation of the CARM_SLOW loop with the RFC error signal demodulated at 8 MHz, but this activity was postponed.

We leave the ITF in LOW_NOISE_1 in order to collect some data, mostly on the possible phase drifts and the SSFS glitches.

Images attached to this report
37737_20170526012021_ssfsnewboostunlock.png 37737_20170526012311_ssfsdataloss1.png 37737_20170526012317_ssfsdataloss2.png 37737_20170526012324_ssfsdataloss3.png 37737_20170526013321_b4phis.png
Comments related to this report
bersanetti - 17:55, Friday 26 May 2017 (37749)

This morning the communication and missing data issues of SSFS were still present; some checks and fixes were made by Alain, who also restored a newer version of Acl for SSFS_Ctrl, then an additional tuning in the SSFS_dbox configuration and a restart of the SSFS_Ctrl process to force a re-synchronization made the system working again with no data loss; the glitches are still present, but they seem less severe.