Previously the logic would process all possible ranges defined by MAX_ADJUSTMENT_RANGE_COUNT even if some (or even all) ranges were not configured. This change first builds a list of configured ranges and only processes thos entries.
Reduces CPU load by skipping unnecessary processing and minimizes the impact of increasing the number of available ranges.
- Move conditionals from pg/usb.c to common_defaults_post.h
- Add detectPin to usbDev_s.
- Bump PG version for usbDev_s.
- Add resource manipulation for USB_DETECT.
Validates the index for lookup values to prevent referencing random memory. Also validates the range of numeric parameters.
diff output will clearly show any corrupted parameters.
This allows modes to be linked, for example to link vtx pit mode to paralyze. Whenever paralyze is activated, vtx pit mode is activated as well. Also the logic to prevent mode changes when enabling paralyze can be removed in favor of making paralyze sticky.
Modes can be linked in CLI by providing the mode id as the last parameter of the aux command. For example in order to link vtx pit mode to paralyze, replace the last 0 of the pit mode aux (39) with the mode id of paralyze (45):
```
aux 2 39 2 1700 2100 0 0
```
becomes
```
aux 2 39 2 1700 2100 0 45
```
_Legal disclaimer: I am making my contributions/submissions to this project solely in my personal capacity and am not conveying any rights to any intellectual property of any third parties._
The short syntax `smix reverse` is meant to print the table. When the logic was checking for parameters it was failing to deal with the null pointer when no parameters were present. Additionally the `smix reverse` was called at the end of a successful command to display the table so even though the command was succeeding it was crashing on the null pointer reference when trying to display the result.
Also some stylistic cleanup
Adds in flight monitoring of the rx frame rate and adapts the filters if the frame rate changes. Primarily to add support for Crossfire with its ability to switch from 150hz to 50hz (and back) under some circumstances. Will work with any protocol - not CRSF specific. So if future receivers add the ability to switch frame rates dynamically the logic should support them.
If the current rx frame rate is more than +-20% from the previously detected rate, then the process will retrain for the next 50 samples as long as the rate continues to be outside the 20% tolerance. Once 50 samples are collected the new frame rate is updated and the filter cutoffs are adjusted. Only filters set with their cutoffs = 0 (auto) will be adjusted. There is a 2 second guard time after a successful update before retraining can start again to prevent rapid switching back and forth.
The logic is optimized to not perform any training if the filters are set to manual cutoffs. So there is an opportunity for advanced users to choose specific cutoffs and reduce the PID loop load slightly. However this is not recommended for Crossfire or other protocols that might change their rx frame rate.
Updated the output of the `rc_smoothing_info` cli command to match the revised logic.
Improved the rx frame rate detection/training by delaying calculation to avoid loop time jitter during flight controller initialization.
For auto cutoffs calculate a value appropriate for BIQUAD or PT1 depending on the configuration.
Added a new rc_smoothing_info cli command to display internal details about its operation.
