Instead of hard coding paralyze this makes the code extensible to possible
future sticky modes
_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._
On bootup aux channels start out at default and allow sticky modes right away,
although they should only be allowed once they are actually not active.
_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._
When the separate rc rates and rc expos for roll/pitch were added the descriptive names were never added to the OSD display strings array. Then later PID audio was added causing the array to be out of sync with the enumerated adjustment types. This led to a corrupted pointer reference in the OSD display.
Also the adjustment display name used for the OSD display was never initialized so the pointer was pointing to random memory.
Removed the use of globals and changed to use "getter" functions.
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._
In the OSD display the warning "RCSMOOTHING". Also play a beep pattern of 3 short, 1 long that will repeat.
If rx rate filter training completes the warning/beeper will stop. The warnings are only active when armed.
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
Decrease the minimum on the valid rx frame time window. SPI FrskyD seems to have frames with quite variable timing and if a frame was outside the valid window training would get reset and never complete. The valid frame timings have no impact on the calculations or operation - they are just sanity checks.
