AI Generated issue-ticket
Current Behaviour
OSD_WARNINGS is implemented as a strict priority cascade (see src/main/io/osd.c, case OSD_WARNINGS). Each condition check ends with break, so the first true condition wins and no other warnings are evaluated for that render frame. Only one warning is ever visible at a time.
When multiple warning conditions are simultaneously active — e.g. LOW BATTERY + ALTITUDE HI — the pilot sees only the highest-priority one. There is no indication that a second condition is also active.
Betaflight Behaviour
Betaflight uses the same fixed-priority cascade model. No rotation or time-slicing — single winner per frame, priority order baked into source order.
iNav Behaviour
iNav implements a time-sliced rotation across active OSD warnings. Each active warning is shown in turn on a fixed interval, so the pilot cycles through all active conditions rather than being shown only the most severe. This is notably more informative when two or more independent warnings are simultaneously active (e.g. low battery + altitude limit + GPS accuracy degraded).
Reference: src/main/io/osd.c in iNav — osdFormatAlerts() cycles through a warning list rather than breaking on first match.
Impact
Affects all warnings, not just altitude. The most practically significant case is simultaneous LOW BATTERY + a secondary warning (altitude, RC smoothing, etc.) — the secondary warning is silently suppressed for as long as the higher-priority condition remains active.
Proposal
Implement time-sliced rotation through all currently-active warnings in OSD_WARNINGS, modelled on iNav's approach. Priority ordering can still gate life-safety conditions (e.g. BATTERY_CRITICAL / LAND NOW should not rotate away), but secondary warnings should cycle.
This is a standalone OSD architecture change, independent of any individual warning feature. Raised in context of #1260 (altitude limit warning) where simultaneous low-battery + altitude conditions demonstrate the limitation.
AI Generated issue-ticket
Current Behaviour
OSD_WARNINGSis implemented as a strict priority cascade (seesrc/main/io/osd.c,case OSD_WARNINGS). Each condition check ends withbreak, so the first true condition wins and no other warnings are evaluated for that render frame. Only one warning is ever visible at a time.When multiple warning conditions are simultaneously active — e.g.
LOW BATTERY+ALTITUDE HI— the pilot sees only the highest-priority one. There is no indication that a second condition is also active.Betaflight Behaviour
Betaflight uses the same fixed-priority cascade model. No rotation or time-slicing — single winner per frame, priority order baked into source order.
iNav Behaviour
iNav implements a time-sliced rotation across active OSD warnings. Each active warning is shown in turn on a fixed interval, so the pilot cycles through all active conditions rather than being shown only the most severe. This is notably more informative when two or more independent warnings are simultaneously active (e.g. low battery + altitude limit + GPS accuracy degraded).
Reference:
src/main/io/osd.cin iNav —osdFormatAlerts()cycles through a warning list rather than breaking on first match.Impact
Affects all warnings, not just altitude. The most practically significant case is simultaneous
LOW BATTERY+ a secondary warning (altitude, RC smoothing, etc.) — the secondary warning is silently suppressed for as long as the higher-priority condition remains active.Proposal
Implement time-sliced rotation through all currently-active warnings in
OSD_WARNINGS, modelled on iNav's approach. Priority ordering can still gate life-safety conditions (e.g.BATTERY_CRITICAL/LAND NOWshould not rotate away), but secondary warnings should cycle.This is a standalone OSD architecture change, independent of any individual warning feature. Raised in context of #1260 (altitude limit warning) where simultaneous low-battery + altitude conditions demonstrate the limitation.