Phase lag pre-arm check

[andyp1per]

Made a separate PR for discussion so as to not hold up #26674

@tridge your original suggestion was bw > 0.75*freq/nsources, I assume that was a typo because that will break the configuration of all 14 of my copters that are using this feature very successfully (and for which this feature was originally written) 😄 I have changed that to bw * 0.75 > freq/nsources which at least does not break many existing configurations but it does not work on octacopters. It is impossible to get the octacopter test to pass with this setting which was my original concern with having any check like this - it simply does not filter enough noise. My suggestion therefore is either to make this a warning or simply clamp the check at f/4. Either way much discussion and testing required!

[tridge]

maybe go to 1.0 so it passes with quad multi-src with 1:4 ratio?

[andyp1per]

After discussion with @lthall we decided f/sqrt(nsources) was a suitable compromise in terms of pre-arm check. Adjusting attenuation unfortunately is unlikely to make enough of a difference.

[tridge]

Adjusting attenuation unfortunately is unlikely to make enough of a difference.

I'm surprised about this. At zero attenuation there should be no phase lag. I wrote a little test to check this out and got this:

this was for a single notch set at 60Hz with bandwidth of 60Hz. Source frequency was 50Hz, and the test frequency varies for the 5 graphs from 10Hz to 50Hz.
The test shows a strong relationship between attenuation and phase lag.
test code here:
#27164
one thing I can't explain is the stair step in the graphs