Reports 1-1 of 1 Clear search Modify search
MIF (General)
takahiro.yamamoto - 19:59 Monday 02 December 2024 (31874) Print this report
Comment to Lockloss during engagement of dewhitening filters (31872)

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

×