Analyze the rc modes activation conditions and only process configured entries. Previously the entire possible list was processed even though typically only a handful are configured.
Reduces the RX task processing time by about 25% (~44us to ~33us) with an average setup of 3 modes configured (F405, SBUS). Processing time savings will diminish as the user configures more modes. But typically far fewer than the maximum of 20 will be configured.
Eliminate unnecessary register writes by keeping previous state information and only writing the registers when the related settings actually change. Saves 17 register writes per `clearScreen()` call.
Also fixed character invert flag handling. Previously changes to the flag would only affect subsequently drawn characters and previous characters would remain unchanged. So for static OSD elements it produced an inconsistent state. Now all characters immediately reflect the current state of the invert flag.
Results in appoximately a 33% reduction in processing time for the OSD task at default settings (~31us reduced to ~21us on F405).
It's long past time for this! The vast majority of airmode related support issues we encounter involve people forgetting to enable airmode.
For the tiny percentage that still (mistakenly) believe they don't want to enable airmode, they can disable if they desire.
Adds available profiles and currently selected OSD profile. If the `USE_OSD_PROFILES` feature is not available then the profile count and selected profile will be 1.
Adds OSD stick overlay radio mode. A zero value indicates OSD stick overlay is not available.
Preserve gyro/acc alignment backwards compatibility for configurator versions unaware of the revised sensor alignment scheme.
Update MSP to add support for:
1. Flag to indicate whether `USE_MULTI_GYRO` is available
2. `gyro_to_use`
3. `gyro_1_sensor_align` and `gyro_2_sensor_align`.
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.
* 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.
Extends the possible OSD warnings elements from 16 to 32.
Adds a warnings count to MSP data to enable improved handling of warnings added to the firmware but not in the Configurator. Incremental Configurator development required.
Exposes each telemetry sensor disable flag as a separate OFF/ON parameter. Makes the settings more accessible without the user having to calculate the binary bitmask directly.
Only added for F4+ due to flash usage. F3 will continue to present the `telemetry_disabled_sensors` 32bit bitmask setting.
Would almost like to reverse the logic to make them enabling flags. Having a "disabled = ON" is a little counterintuitive.
Since we really can't conditionally build the list of options, it's possible to select an invalid blackbox device type using CLI `set blackbox_device =`. This change validates that the selected device is included in the code and if not resets to "no logging".
Replaced the existing `PERSISTENT_OBJECT_BOOTLOADER_REQUEST` that was bootloader specific, with `PERSISTENT_OBJECT_BOOTMODE_REQUEST` that can be shared by any required boot mode based on it's contents. Currently supports bootloader and MSC, but is extensible for additional future needs. The previous hardcoded memory address usage for MSC boot was removed.
This code cuts D by a specified percentage durning normal flight.
It lets D smoothly rise up to normal during rapid gyro moves like flips and rolls, and increase during prop wash events.
D should now be tuned to values the 'normal' 30-45 range.
If D is 40, a dterm_cut_percentage of 65 will cut D to 14 in normal flight, but the quad will still get full 40 of D to control bounce-back after flips and about 25 of D during strong prop wash.
The dterm_cut_percentage can be adjusted via the OSD, from the D filtering page.
Adding d_cut results in cooler motors, lower amounts of noise in motor traces and faster reactions to quick stick inputs.
Too high a dterm_cut_percentage may bring out P oscillation from lack of D. Values of 70% are generally OK.
Input is gyro differential (delta). Frequencies above 40hz (above propwash) are attenuated with a configurable (dterm_cut_range_hz) biquad filter. Lower values for range can be used if the quad is very noisy or gets low frequency D resonant oscillation. Up to 50 or 60hz may suit clean quads where prop wash control is the main priority. Too high a range value results in D being boosted from noise in normal flight.
The boost signal is 'integrated, smoothed and delayed' with a 7hz PT1 'dterm_cut_lowpass_hz' filter. The default of 7Hz gives about the right amount of smoothing and delay. Higher numbers cause the boost to come on faster, with less delay. Lower values delay the boost effect and cause it to last longer.
The dterm_cut_gain amount controls the strength of the boost effect by amplifying the input to the boosting effect. If the quad is flow gently, a higher gain value may be needed to gain full boost.
Logging with set debug_mode = D_CUT allows recording of realtime D values on roll and pitch into debug 2 and 3. The reatime D value should reach its set maximum during rapid turns, ideally at about the time D itself peaks. If it fails to reach the maximum, gain should be increased.
The D_Cut feature is not enabled on LUXV2RACE, OMNIBUS, SPRACINGF3NEO because there isn't enough flash space.
The logic already performed a reboot if mass storage init failed, but it never reset the boot vector value so it continued to contain the `MSC_MAGIC` value leading to a boot loop.
Also fixed fixed the F7 version of `mscWaitForButton()` as it was using the F4 vector.
Previously the logic would only validate whether one or more of the defined flash device types was ready and not examine the user selected blackbox device. Then on reboot during `mscStart()` the logic there would use the selected blackbox device type to decide which mode to operate in. If a flash device wasn't selected the msc initialization failed (like if serial port or "no logging" were selected).
This change only checks the status of the selected blackbox device to ensure that a reboot will properly start mass storage mode.
Michael Keller
Bruce Luckcuck
warhog
brettcollis2212
jflyper
Sean M
MJ666
SteveCEvans
Tony Cabello
AJ Christensen
Scavanger
Andrey Mironov
Pieter Kruger
phobos-
ctzsnooze
Kenneth Mitchell
Thorsten Laux
Cheng Lin
Hans Christian Olaussen