Added features to the BEACON ledstrip profile:
Added a `ledstrip_beacon_color` to allow color selection rather than forcing to white.
Added `ledstrip_beacon_period_ms` to configure the blink period in milliseconds. Smaller time periods mean faster blinking.
Added `ledstrip_beacon_percent` to configure the "ON" time duty cycle. User can set to 100% to have the beacon display a solid color. 0% can be used to turn the becaon completely off.
Added `ledstrip_beacon_armed_only` to allow the user to configure whether the beacon is only on when armed.
Added `ledstrip_visual_beeper_color` to allow configuration of the visual beeper color.
Added the new parameters to the CMS menu.
Simplified the code and combined the RACE and BEACON profile processing.
Added support for auutomatically displaying a beacon that indicates RX_SET or failsafe regardless of the other RACE or BEACON settings.
Added a flag indicating the level of ledstrip support (to allow improved Configurator behavior) along with support for reading/setting the current `ledstrip_profile`.
ledstrip support flag is as follows:
0 = basic ledstrip available
1 = advanced ledstrip available
The blackbox "P" frame is incorrectly offsetting the rcCommand[THROTTLE] value by `min_throttle`. The rcCommand value already ranges from 1000-2000 and is an input so it shouldn't be offset by a motor output value. Also this is clearly incorrect in the case of DSHOT which doesn't use `min_throttle`.
The calculation used to transform the rcCommand[THROTTLE] value to a throttle value used in the mixer was incorrectly applying the `min_check` range a second time. This leads to the mixer throttle value scaling incorrectly and adds an additional deadzone at the low range that basically doubles the `min_check` range.
Currently only rcCommand values are included in the log data and the configurator calculates the actual setpoint values based on rates values added to the blackbox header. The problem with this is that the rates information is only written at arming so if the rates change during the log (rateprofile change, in-flight adjustments, etc.) then the calculated setpoints will be incorrect. There's no way to tell from the log that this happened. This often causes confusion because it will suddenly make it appear in the log that the PID controller is not acheiving the requested rates when it's just a presentation error. Also the rates will be incorrectly calculated when the user selects Raceflight style rates as the rates type is not supplied in the log header (and the viewer doesn't have the forumla for them anyway).
This change adds the actual setpoint values for each axis as used by the PID controller, removing the necessity for the viewer to perform any calculations. In addition to showing any rate changes, it will also show any cases where other flight features have modified the setpoints from the user's input. These were invisible previously (examples include level modes, Acro Trainer, GPS Rescue, yaw spin recovery, etc.).
Also the throttle value used in the mixer is included in the throttle axis. This allow visualization of things that affect the commanded throttle like throttle boost, throttle limit, GPS Rescue, angle level strength, etc.
The range was underflowing the calculated hue value causing it to loop back to other colors. For example when battery ranged from below 20% the color would shift from red (the correct color for minimum battery) to shades of magenta. RSSI had the same problem.
Now the logic reserves the base color (red in these cases) for the minimum 20% of the range. From 20-100% the color will scale from red through to green.
