Reports 1-1 of 1 Clear search Modify search
MIF (General)
takafumi.ushiba - 12:32 Monday 02 December 2024 (31872) Print this report
Lockloss during engagement of dewhitening filters

[Dan, Tanaka, Yokozawa, Ushiba]

In this morning, IFO often lost lock at LOW_NOISING_SUS_FOR_PRFPMI state.
After several investigations, we found that the lockloss happened due to the glitches when dewhitening filters were turned on.
Figure 1 shows the PRCL and MICH error signals when PR3 dewhitening filters were engaged in this morning.
Figure 2 shows the same signals in last week: the glitches were much smaller than those today.

Since we modified the real-time model related to dewhitening filters on last Friday, we suspected the order of dewhitening filter engagement.
So, we checked the signals by turning on dewhitening filter manually in the following condition.
1. Turn on the first stage dewhitening filter: no glitch (or very small glitches).
2. Turn on the second state dewhitening filter: slightly large glitches compared to the case 1.
3. Turn on the third state dewhitening filter: large glitches.

After that, we tested the swapping of dewhitening filter setting as follows:
1. Turn on the first stage of dewhitening filter and switch it to the second stage dewhitening filter: no glitch (or very small glitches).
2. Turn on the first stage of dewhitening filter and switch it to the third stage dewhitening filter: slightly large glitches compared to the case 1.
3. Turn on the second stage of dewhitening filter and switch it to the third stage dewhitening filter: no glitch (or very small glitches).

According to the results, we can switch the dewhitening filter from 1 to 2 and 2 to 3 without large glitches.
So, we modified the VIS params to engage the first stage dewhitening filter and then switch to second and third step by step.
After this modification, IFO can pass the state of LOW_NOISING_SUS_FOR_PRFPMI state.

Note:

I picked up PR3 case but we could observe similar glitches on all Type-Bp and BS (we didn't check the other suspensions but probably same thing happen).

We are still not sure why the dewhitening filter makes glitches when turning on from 2nd or 3rd stages but one possibility might be the order of FMs at COILOUTF.
Currently, when the 3rd stage of dewhitening filter is turned on, FM3 instead of FM1 is turned off to compensate the analog low-pass filter while it was FM1, which might affect the signals.
So, we need to check if our guess is correct or not.

Images attached to this report
Comments to this report:
takahiro.yamamoto - 19:59 Monday 02 December 2024 (31874) Print this report

It appears that the software simulated de-whitening filters need to be engaged the former stage first though engaging latter stage of analog real de-whitening filters is better for the circuit noise.
I checked the glitch situation with 4 cases below and confirmed engagement order of simulated de-whitening filters is important for glitches.
1) Engaging the 1st stage of analog de-whitening filter and disengaging FM1 (original implementation)
2) Engaging the 3rd stage of analog de-whitening filter and disengaging FM3 (previous update for improving circuit noise in klog#31774)
3) Engaging the 3rd stage of analog de-whitening filter and disengaging FM1
4) Engaging the 1st stage of analog de-whitening filter and disengaging FM3

Finally, I concluded that 3) is the best implementation from the view points of both glitches and circuit noise.

-----
Setup
In order to monitor glitches by engaging de-whitening filters, AI output and coil driver output were connected to the input of coil driver and AA chassis, respectively. And then
I repeated to engage/disengage de-whitening filters with Gaussian noise (0-100Hz) injection from the DAC as shown in Fig.1.

Glitch situation in each case
Figure 2-4 show the case of 1) which is the original implementation. Three figures are just a 3 times trial with a same situation for checking the reproducibility. BIO request is shown in the top panel and a signal at DAC and at output of coil driver monitored on ADC are shown in the middle and bottom panels, respectively. Though reproducibility of glitch appearance is not very high, the maximum amplitude at the output of coil driver is a few hundred counts. Glitch appearance and its amplitude seemed to depend on the relation between a timing of switching and phase of signal at that time. But it's not realistic to control them for the real control signals. So I haven't checked it in detail. In addition, note that a possibility not to detect maximum amplitude by the sampling points.

Figure 5-7 show the case of 2) which is the current implementation modified in klog#31774. In this case, glitch amplitude is a few thousand counts. Please ignore the glitches when BIO request downs because disengaging de-whitening filter is basically done only in LOCKLOSS state and we should now focus on the case of engaging de-whitening filter during the lock acq.

Figure 8-10 show the case of 3). In this case, glitch amplitude is a few hundred counts. This result suggest that we can mitigate large glitches even if we use the 3rd stage of analog de-whitening filters. From the view point of the circuit noise pointed in klog#31771, This is probably the best implementation.

Figure 11-13 show the case of 4). In this case, glitch amplitude is a few thousand counts. This result suggest that using FM3 as the 1st simulated de-whitening makes large glitches independent about used stage of analog de-whitening. This is the worst case that both circuit noise and glitches become large.


Thought experiment
In the case of disengaging FM1 at first, glitches made by disengaging FM1 are suppressed above 10Hz as a factor of 0.01 by the software simulated de-whitening at FM2 and FM3 and are enhanced as a factor of 1000 by the anti-dewhitening at FM6, FM7 and FM8. After then glitches are suppressed as a factor of 0.1 by the analog de-whitening filter. In this case, glitches at the output of coil driver chassis are same amplitude as one at the output of FM1.

In the case of disengaging FM3 at first, glitches made by disengaging FM3 are just enhanced in digital as a factor of 1000 by the anti-dewhitening at FM6, FM7 and FM8. After then glitches are suppressed as a factor of 0.1 by the analog de-whitening filter. So glitches at the output of coil driver chassis are 100 times larger than one at the output of FM3.

In the case of disengaging FM3 as the 3rd stage of de-whitening filter, glitches are enhanced as a factor of 1000 by the anti-dewhitening same as above. On the other hand, they are suppressed as a factor of 0.001 by the 3 analog de-whitening filters. So glitches at the output of coil driver chassis are same amplitude as one at the output of FM1.

This scenario also suggests we should engage former stage of software simulated de-whitening filter first.

New implementation
In the cases of both 1) and 2), software simulated de-whitening at FM1, FM2, and FM3 are used with the 1st, the 2nd and the 3rd stage of analog de-whitening, respectively. So changing the assignment of state number for actual situation was enough for the implementation of 2). For the case of 3), FM1 and FM3 must be used with the 3rd and the 1st stage of analog de-whitening, respectively. This means bit assign for the filterbank control and analog circuit control must be twisted each other. Bit control signal on Simlink model is already converted as Int16. So I decided to twist bit assignment in C-code instead of Simlink model.

New code is prepared as /opt/rtcds/userapps/release/vis/common/src/CD_STATE_MACHINE_KAGRA.c.glitchmitigation. VIS model should be rebuilt with this code in the next maintenance day. MEDM screens of the coil driver BIO situation with new code are shown in Fig.14 and Fig.15. In Fig.14, BIO readback from the coil driver shows the 3rd stage of de-whitening is engaged. On the other hand the 1st stage of simulated de-whitening is disengaged on FilterBank. Fig.15 shows the case that analog de-whitening at the 2nd and the 3rd stage are engaged with disengaging the simulated de-whitening at the 1st and the 2nd stage.

Images attached to this comment
Search Help
×

Warning

×