fix some comments
some requested fixes
initialLandingAltitude converted in meters
removed landing altitude setting from msp, added missing comma
re-added gps_rescue_landing_alt in settings.c
made target landing distance configurable, renamed descentDistance
added slow down distance and improved return speed
changed newSpeed formula
moved newSpeed variable in gps rescue inizialization phase
newSpeed declared as int32_t
modified slow down distance to constant
added some comments
fix type-casting bug
removed extra space
changed slow down distance for better landing
changed default targetLandingAltitudeM to 5 meters
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).
