A new control filter for DARM has been tested twice. The first time the ITF unlocked soon, apparently for a reason not really correlated to DARM loop: maybe a wrong command was executed at the same time of DARM filter swap. The second time the things went smoothly for a while: in fig 1 one can see DARM ERR becoming more accurate during five second of ramp, as expected because the new loop should have much more gain. Just at the end of the ramp the lock exploded (fig 2). Even in this case we could suspect that something wrong happened at software level.
Today we engaged again the new DARM filter but, as suggested by Alain, with a slower ramp of 100sec.
GPS: 12.15.03 UTC.
As reported in the attached plots, during the whole ramp the transition went through as the accuracy of the loop gradually improved as expected.
At the exact moment of the finsih of the ramp (12.16.43 UTC), when the new filter is already totally running an enormous spike in the error signal occurred. This is somehow what has been already partially observed in yesterday's trials, but this time the handoff survived and the ITF didn't unlock.
Still not sure what is the cause of this spike.
Fig.1 : transition between the filters
Fig.2: zoom of the spike occurred at the end of the ramp.
