barometric pressure. The commit which introduced the error was:
35f0a8e4b0
It transposed (inadvertently, I believe) the last two digits of the
constant 0.190259f. A nearby comment references code in Ardupilot,
in which the constant is 0.190259f.
Addesses the possible edge case of runaway takeoff detection still being active and getting triggered by the quick yaw turn when GPS Rescue is activated.
If the `vtxDevice` was not valid then the `vtxStatus` variable never got initialized but was still used in the pit mode flag determination - leading to random behavior.
Previously there were cases where the input was not compared to the currently defined vtxtable limits and this could lead to a wedge as code referenced the uninitialize string arrays.
1. Excludes yaw from ff_boost.
2. Removes suppression for 3x greater up-steps in FF to reduce boost glitching around zero sticks
3. Spike detection gets cleaner passband and tighter rejection above threshold; higher threshold is now possible with better suppression of large spikes.
The feed forward boost concept improves stick response by adding a stick acceleration factor to feed forward. Generating spikes when there are steps in the RC signal is the main problem.
This PR makes one small change to how the spike suppression method is determined.
It no longer uses the 'jerk' signal to generate the spike suppression 'clip' value. Instead it just uses the magnitude of the boost signal itself.
We originally used jerk because it is more sensitive to spikes. Detailed testing shows that jerk is that it has an unwanted impact one full RC step after the spike.
If we use the boost (acceleration) signal as the attenuator, that delayed impact does not occur, making the boost component more precise.
The threshold value for suppression needs to be a bit higher to achieve equivalence.
I've re-named the function to reflect it being related to spike suppression and removed 'jerk' since we aren't using that any more.
Previous logic was updating updating the DMA buffer for all possible LED positions (32) regardless of how many were used. Since there are 24 bytes per LED, this performed a lot of unnecessary processing in cases where the user had less than 32 LEDs configured.
Also includes a bug fix in that if the LED count was decreased (like making changed using the Configurator LED tab), the now unused LEDs at the end of the string would remain on at the last color applied. Now they will be properly turned off. The bug was minor as it was resolved by a reboot, but made setup using the Configurator confusing since changes made are reflected when the user clicked the "Save" button (which does not reboot).
