Configurable OSD refresh rate

[hntirgeam]

Summary

Implements configurable OSD refresh rate via osd_framerate_hz CLI command.

Fixes mentioned here behaviour.

Problem

INAVs element drawing updates only one element per frame. With many enabled elements (e.g., 30), each element updates at ~2Hz (62.5Hz / 30) which doesn't help when flying in harsh conditions. Only artificial horizon and telemetry updates as fast as possible (each frame)

Solution

• Added osd_framerate_hz setting (range: -1 to 60 Hz)
  • -1 (default): Legacy (current) mode
  • 1-60: all elements update at specified Hz
  • 0: all elements update each frame

Video showing default behaviour, osd_framerate_hz=12 (default in betaflight) and osd_framerate_hz=0 (each frame)

osd_framerate_hz_hd.mp4

[github-actions]

Branch Targeting Suggestion

You've targeted the master branch with this PR. Please consider if a version branch might be more appropriate:

• maintenance-9.x - If your change is backward-compatible and won't create compatibility issues between INAV firmware and Configurator 9.x versions. This will allow your PR to be included in the next 9.x release.

• maintenance-10.x - If your change introduces compatibility requirements between firmware and configurator that would break 9.x compatibility. This is for PRs which will be included in INAV 10.x

If master is the correct target for this change, no action is needed.

---

This is an automated suggestion to help route contributions to the appropriate branch.

[hntirgeam]

Can also be ported to 8.x.x (which I tested on). I can open another PR if needed.

[MrD-RC]

There won't be any more updates for 8.x. This would need to go in to 9.1.

[MrD-RC]

I'm not sure updating all elements every cycle is a good idea. If there are a lot of elements. This could cause issues.

Maybe instead of a timeout where all elements are updated. Maybe just set the number of elements to be updated each cycle. Maybe with a range of 1 to 10.

1 would be the current way, with a single element updated each cycle.

10 would be 10 elements per cycle. I think that would be plenty fast enough.

With a 30 element OSD and this set to 10. All elements would be updating at ~21Hz. Thats more than fast enough. Setting to 5 and them updating at ~10Hz would be fast enough too.

[sensei-hacker]

Maybe instead of a timeout where all elements are updated. Maybe just set the number of elements to be updated each cycle. Maybe with a range of 1 to 10.

Yeah. This is the way. After a certain number of microseconds, it's going to be time for the PID task to run. Rather than the OSD task occasionally trying to take far more than the available time, it should consistently do what it can in the time available. Consistently do two or three elements each cycle.

Same as you might work 8 hours per day. Not try to work 40 hours one day per week.