The maximum power capability supplied from different VTX models is inconsistent. Sometimes correctly representing the VTX's capabilities, while for others not accurate or misrepresentative. So the previously added check is preventing accessing power levels in cases where the VTX doesn't properly report its max limit.
Some VTX don't respond to every request so it's necessary to retransmit. A previous PR fixed a bug that caused more retries than expected and made the actual retries only be 2 as configured. Unfortunately this exposed the problem with the non-responding VTX with cases of it not responding to both retries. The problem was accidentally masked by a previous bug with the retry counter causing many retries to actually occur.
This then exposed a secondary problem in `vtx_common` that lead to a "lockup" condition if the actual VTX channel didn't match our expectation of what the channel should be based on the settings. We were getting into this state because of the (now working) retry limit and cases where the VTX didn't respond and change channels as expected.
Increased the retry count to 20.
Fixed the logic that would prevent subsequent channel changes if the actual VTX channel didn't match the expected value based on the settings. Also fixed a problem where the channel change would not work if the VTX was on a frequency that was not defined in `vtxtable`.
Timeout logic was ignored if the user had the accelerometer enabled and the quad wasn't within the angle limit. This was made doubly troublesome as the angle limit could be set to zero preventing crash recovery from ever deactivating.
Also adjusted the ranges of the parameters to be more rational to avoid invalid configurations.
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.
