Adds accuracy to the frame rate measurements used to configure RC smoothing. Prevents looptime delays and jitter from affecting the calculations. Significantly improves the accuracy of the measurement in cases where CPU load is high.
Implemented so that each protocol can individually provide the functionality if appropriate. If a protocol doesn't support the more granular measurement then the system will fallback to the original measurement calculated in the RX task.
Found through static analysis with GrammaTech CodeSonar
Need to make sure escapeCharFound is initialized to false. It doesn't look like anything really can go wrong (yet), but the loop in 804 could be executed even if not needed.
Found through static analysis (GrammaTech CodeSonar).
I am quite convinced that the VTX_TABLE_MAX_BANDS on line 2829 should be VTX_TABLE_MAX_CHANNELS.
Possible the same replacement should be done on Line 2834, but I am not 100%.
Previously stick arming was assumed to be the case if an arming switch was not configured. This leads to a less safe default state and can lead to beginners thinking that stick arming is the default.
This change adds an `enable_stick_arming` setting which defaults to `OFF`. For stick arming to function the user must actively change this setting. The previous condition about there not being an arming switch configured still applies.
Fixes support for the multi-range method of configuring profile type adjustments that stopped working when "slots" were removed. Although this type of setup will now work again, the correct method is to have a single adjustment set to the full channel range.
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.
Fixes a copy/paste error introduced in #8282.
Only a cosmetic bug that affected the informational blackbox header. Had no effect on RC smoothing operation.
Significantly reduces the time the OSD task spends drawing elements that are completely or mostly static. The larger the element the more time savings are realized. Currently implemented support for:
- Crosshairs
- Artificial Horizon Sidebars
- Craft name
- Display name
- Stick overlay
Since the static portions are only rendered once, the static elements add no processing time to the OSD task. As an example, enabling the above elements prior to these changes results in a total rendering time of 47us. After the enhancements they take only 6us (basically the rendering phase minimum overhead). So effectively 41us are removed from the OSD task.
Opens the possibility to add large mostly static elements with no additional overhead. An example would be a camera framing element that might draw a "box" around most of the screen. Previously this would add significant processing overhead to the OSD task, but now it will have no impact.
In recent releases we have been increasing PID I.
We haven't reduced the antigravity gain value in the same proportion.
Low authority / low P quads can get I wobbles that are apparent on throttling up.
A lower default anti-gravity gain is likely to work alright and be a fraction less likely to cause I wobbles.
