Conversation
osdFormatDistanceStr() always printed an explicit '.' character, which is the DJI number format. On every other system the decimal separator is drawn into the digits around it, so the separate character wasted a column on the post-flight stats screen. Print the separator only for DJI compatible video systems and embed it into the neighbouring digits otherwise, the way osdFormatCentiNumber() and osdFormatCoordinate() already do. Fixes iNavFlight#10420
osdRefresh() runs at 62.5Hz and the percentage was taken straight from calculateBatteryPercentage(), so the digits followed every voltage dip and were unreadable in flight. Run the value through a pt1 filter in osdFilterData(), next to the other noisy OSD values, and print the filtered result. The filter is seeded with the current percentage on the first refresh so the element does not have to ramp up from zero. Only the digits are damped. The battery state, and with it the alarms, the blinking and the charge symbol, still use the raw value. Fixes iNavFlight#10053
|
ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing |
PR Summary by QodoFix OSD distance formatting and battery percentage jitter
AI Description
Diagram
High-Level Assessment
Files changed (1)
|
Code Review by Qodo
1.
|
Problem
Two OSD reports. #10420: on the post-flight stats screen, Flight Distance and Maximum Distance From Home use DJI number formatting on every video system, a separate
.character that costs a column; the reporter notes it was never a regression, it always looked like this. #10053: the Battery Remaining Percentage element is sampled so often that its digits change constantly and the value never settles in flight (INAV 7.1.1, quadcopter).Fixes #10420
Fixes #10053
Cause
src/main/io/osd.c:396,:408,:419on maintenance-10.x: the three fractional branches ofosdFormatDistanceStr()print"%d.%02d%c".osdFormatCoordinate()(osd.c:795) andosdFormatCentiNumber()only print an explicit dot on DJI systems and otherwise embed it withSYM_ZERO_HALF_TRAILING_DOT/SYM_ZERO_HALF_LEADING_DOT.src/main/io/osd.c:1949:OSD_BATTERY_REMAINING_PERCENTprintscalculateBatteryPercentage()raw on everyosdRefresh()(TASK_OSD 250 Hz /DRAW_FREQ_DENOM4 = 62.5 Hz), so every voltage dip reaches the digits.Change
New
osdFormatDistanceFractionStr()writes integer part, two-digit fraction and unit symbol; DJI-compatible systems get the same bytes as before, every other system gets the separator embedded in the two neighbouring digits. The km, mi and NM branches call it; the whole-number branches are unchanged. The battery percentage now runs through a 0.1 Hzpt1Filter_tinosdFilterData(), seeded on the first refresh and reset whenevergetBatteryState()crossesBATTERY_NOT_PRESENT; the element printslrintf()of the filtered value. Charge symbol, blink attributes andcalculateBatteryPercentage()itself keep the raw value. One comment typo ("Embbed") fixed.Test
Not run on hardware or SITL. Cause verified by reading
osd.c:396-419andosd.c:1949on maintenance-10.x; the DJI branch reproduces the old format string byte for byte. Qodo review found that the filter carried the previous battery's value across a battery swap; commit 2860242 adds the presence-change reset.osd_unittest.ccbuilds onlyosd_utils.c, soosd.chas no unit coverage. (no run exists forfix/osd-number-formatting).Flash / RAM
Not measured yet. The upstream firmware CI has not been released for this PR, so no size report exists.
Docs
No documentation change needed:
docs/OSD.mdlists the element and the stats rows but does not describe number formatting or smoothing for any element, anddocs/DJI compatible OSD.mdsays nothing about the decimal separator.