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.
* Introduce CLI parameter gyro_filter_debug_axis which defaults to 'ROLL',
the previous behavior. When set to either PITCH, or YAW, the debug logging
implementation in the gyro filtering will use that axis instead.
The menu stack counter was not being reset when CMS was initially entered and multiple entries can cause an array overflow/memory corruption and wedge.
Previosuly the problem was accidentally prevented because the user was required to "back out" through the menus to exit which decremented the array index. However with the addition of the popup exit/save menu it became possible to exit without traversing back through the menu structure and this bug was exposed.
Previous logic bypassed optimizations and updated the ws2811 on every task execution - leading to and average of 92us task execution time. Restored the previous optimizations and additionally optimized the new "RACE" and "BEACON" modes so that they only update the led's when there's an actual state change. Task time for these modes is now in the 2-4us range for F405. For the normal "STATUS" profile the performance has been restored to previous optimized levels and typical configurations will generally have task times in the 8-14us range.
Revised the LEDLOW disable mode to function all the time and disable the ledstrip completely. Previously if visual beeper was enabled that would override the disable and the ledstrip would display whatever would be otherwise displayed but only during the duration of the beep. The resulted to a very inconsistent behavior depending on the user's settings.
Added visual beeper support to the new "RACE" and "BEACON" profile modes.
General cleanup and refactoring.
Having the iterm resetting happening in the rx loop causes a sawtooth PID/motor effect while idling since the PID loop is running at a much higher rate and iterm is allowed to grow during this, and then only reset at a much lower rate in the rx loop. This can potentially lead to some oscillation and/or resonance while idling before takeoff as the sawtooth signal can make it through to the motor outputs.