dyn_notch_min_hz provides a lower frequency limit below which the dynamic notch cannot go.
The current minimum is 100hz.
For low rpm quads (>7" to X class), when the dynamic notch mode is 'LOW', we should allow the user to enter the lowest possible value that can be detected by the FFT.
That is theoretically the centre of the second bin. In low mode that is half-way between 31 and 63hz. In practice, that value will be biased upwards a little bit by the uppers shoulder. In practice the lowest value returned by the FFT is likely to not be less than 60hz.
This PR lowers the limit from 100hz to 60hz, allowing access to the full range of possible FFT tracking frequencies in LOW mode for low rpm quads.
Will hopefully reduce the number of cases where users incorrectly disable MSP on the VCP port and then can no longer connect.
Should be supplemented with changes to the configurator that prevents turning off MSP on the VCP port.
Logic was not expecting there to be multiple MPU6000's connected simultaneously. There are currently no boards manufactured with this config, but it's possible to do using boards that have an onboard MPU6000 and an external gyro box containing a second MPU6000.
Change to a state machine that tracks the progress of each dshot command in the queue as it moves through the various phases. Simplifies the code to make it easier to understand and maintain.
Transition to timing based on motor output cycle counts calculated from desired delays instead of using direct time comparisons. Since the output timing is always based on the motor update schedule, there were cases where if the time between motor updates was a significant percentage of the desired dshot command timing, then the output could get irregular and skip cycles (for example trying to use 2K pid loop with 500us timing conflicting with 1ms timing between dshot command outputs).
In the case of multiple queued non-blocking dshot commands, a single motor command frame would get erroneously sent in the idle time between the commands when arming. This change contains some workarounds to prevent this behavior.
Defaults will be the same regardless of whether the target has `USE_DYN_LPF` included. Previously the defaults would vary and it wouldn't be obvious why.
Defaults are as follows:
gyro lowpass 1: 150/BIQUAD
gyro lowpass 2: OFF
dterm lowpass 1: 150/BIQUAD
dterm lowpass 2: 150/BIQUAD
Nothing has changed int eh dynamic lowpass logic. If it's enabled those settings will be used in place of the static lowpass cutoff.
Needs coordination with the Configurator to change the defaults used when re-eanbling the lowpass filters as they are currently based on previous version settings and will dfault to inappropriate values.
