Use the final calculated throttle value that may be affected by throttle limiting, throttle boost, etc. instead of the rcCommand input when calculating the virtual current meter.
Fix compilation when USE_DMA and USE_DMA_SPEC are not defined.
Cleanup calling code of `isMotorProtocolDshot`.
Fix 'unused' warning when USE_PWM_OUTPUT is not defined.
Undo isMotoroProtocolDshot change.
Disable USE_SERIAL_4WAY_BLHELI_INTERFACE when USE_PWM_OUTPUT is not
enabled.
Style cleanup.
If DSHOT telemetry is enabled but one or more ESC's are not supplying valid telemetry packets, then send the DSHOT command to enable telemetry once a second while disarmed until all ESC's are supplying telemetry.
Addresses the issue of the flight controller booting without the ESC's powered. In this case the initial command at boot to enable bidirectional telemetry will be missed by the ESC since they're not powered. If the battery is subsequently plugged in the ESC's will default to bidirectional telemetry disabled.
This change will detect that ESC's are not supplying telemetry and attempt to preiodically enable them.
raise dc offset immediately
Add airmode noise fix
no filter when inactive and slightly more throttle
hpf throttle to avoid large moves increasing throttle persistently
fix ws
fix ununsed variable and default to off
include airmode throttle offset in loggingThrottle
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 DSHOT digital idle value is quite low (4.5%) and is often the cause of support issues as users are unaware that they may have to adjust this based on their motor/ESC requirements - leading to de-syncs and "death rolls" or other flip-outs.
While DSHOT capable ESC's (BLHeli_S & BLHeli32) have faster MCU's and are often capable of smoother low speed idling, 4.5% is still quite low. For comparison the `min_throttle` default is 1070 equating to a 7% idle.
I propose raising the digital idle to 5.5% to reduce occurrences of de-syncs from too low idle speed.
Current logic produces excessive load because it updates the filter cutoffs every PID loop based on the throttle value.
The throttle values only change based on receive RX packets so they change relatively infrequently compared to the PID loop. However with rc smoothing on throttle the value can change every PID loop. But in reality we don't really need to adjust the filter cutoffs for every tiny change to the floating point throttle value.
This change quantizes the throttle in to 100 steps and uses that to compare to the previous value to decide if the filter cutoffs need to be updated. While this reduces the resolution of the filter cutoffs it in turn dramatically reduces the processing overhead. IF needed the quantization steps can be increased for more resolution but at the cost of some performance.
Adds a race start assistance system that allows the pilot to pitch forward and then release the sticks with the quad holding position for the race start.
