Affected all unified targets as USE_VTX_RTC6705 must be defined to allow supporting that VTX option. Would cause the low power index settings for RTC6705 to override the settings for other VTX type and set the vtxtable power level index to 2 instead of 1.
Adds a fixed delay after the motors are enabled before DSHOT commands can be sent. Fixes a problem caused by sending DSHOT commands too soon and prevent the ESC from properly detecting the protocol.
SPI5 and SPI6 are only available in packages >= 144,
and these are not defined in bus_spi_pinconfig.c either.
Accessing spiInitDevice() with SPIDEV_5 or SPIDEV_6 would cause hard fault.
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.
