Reports 1-1 of 1 Clear search Modify search
AdV-COM (AdV commissioning (1st part) )
bersanetti, ruggi, heitmann, fidecaro, cohen - 1:39 Friday 26 May 2017 (37737) Print 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
Comments to this report:
bersanetti - 17:55 Friday 26 May 2017 (37749) Print this report

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.

Search Help
×

Warning

×