Increase battery voltage resolution to 10mV

[shellixyz]

Battery voltage resolution of 100mV is not enough for me. This patch increases the voltage resolution to 10mV.

• Voltage scaling/calibration resolution is increased 10 fold. Previous calibration value should be multiplied by 10. Previous default was 110. New default is 1100.
• Increased battery voltage min/max/warning thresholds resolution to 10mV
• OSD can now display battery voltage with 2 decimals. It can be configured with the new setting osd_main_voltage_decimals
• 100% backwards compatible with current configurator code and existing MSPV1 protocol usages.
• Adds new MSP2 frame types with increased resolution support: MSP2_ANALOG, MSP2_MISC, MSP2_SET_MISC, MSP2_VOLTAGE_METER_CONFIG, MSP2_SET_VOLTAGE_METER_CONFIG

Matching configurator update: iNavFlight/inav-configurator#328

[giacomo892]

Nice work! Would be awesome to add battery profiles to this battery code overhaul like the ability of having separate low voltage alarms for LiPo and LiOn batteries with the ability to switch profiles via the OSD.

[shellixyz]

Good idea. You should open a new issue for discussing the best way to do it. I also have one or two other ideas about the battery management.

[shellixyz]

I'm pretty sure the comment is wrong. If vfasVoltage = vbat and vbat resolution is 100mV then vfasVoltage * 10 gives result in 10mV increments not in 1V increments.

[shellixyz]

I'm pretty sure the comment is wrong. If vbat resolution is 100mV then vbat * 10 / batteryCellCount gives the individual cell voltage in 10mV increments not in 1V increments.

[shellixyz]

I tested this apart from the telemetry. Looks good to me.

• The telemetry modifications are pretty straightforward I just divided all the calculations by 10 since the code was expecting a vbat value with 0.1V increments and now getting 0.01V increments (10 times more per unit)
• The blackbox data will only show 100mV resolution (same as before) because for it to stay compatible with older versions and support 10mV resolution it needs to detect the version but it looks like iNav still declares himself as Cleanflight which would most likely be an issue.

[digitalentity]

@shellixyz is this ready for merge?

[shellixyz]

@digitalentity Yes it is ready

[digitalentity]

@shellixyz another thought. Maybe use voltage/current readings float and in "proper" volts/amps?
@DzikuVx @fiam @stronnag what do you think?

[shellixyz]

@digitalentity If it is an option for sure would make the code easier to read. Not sure about the practicality though. Can the OSD code manage formatting floats ? And we will still need to convert the floats to integer representation for communication purposes (telemetry, MSP). I will look into it.

[fiam]

I'm a bit scared of floats for performance reasons. F3 and F4 only have hardware FPU for 32 bits, not for 64 (not sure about F7, I think it does but F3 and F4 is like 99% of the userbase right now). Doing an accidental promotion to double in a calculation is very easy to introduce and difficult to spot later. However, from a functional standpoint and code clarity float would probably be better.

Is there an easy way either via compiler options or via runtime configuration to make sure we don't accidentally introduce operations that require soft-fp? I've taken a quick look to the ARM specific options in GCC but I can't find how to produce an error when the code requires FP via software.

[digitalentity]

@fiam -Wdouble-promotion -Wfloat-equal -Wfloat-conversion -Wunsuffixed-float-constants is what you're looking for

[shellixyz]

@digitalentity Compiling the development branch with these options is already producing a lot of warnings (153).

[shellixyz]

I suggest merging this before considering the float conversion.

[digitalentity]

@shellixyz agreed on float-point related warnings

[shellixyz]

@digitalentity I intend to make another pull-request for improving the battery management even more. Adding mWh draw calculation (better than mAh), improving the way the battery capacity percentage is calculated and also the possibility to use the battery capacity as thresholds for the battery warnings. I am talking about this here because the changes also involve data that should be included in the new MSPV2 messages created by this PR and the mWh calculation also depends on the voltage resolution. So it would be better if this PR and the new one could be merged close in time to each other and that I could base the new PR on the changes made by this one.

[digitalentity]

@shellixyz sure, no problem. BTW I'm ok with merging this right away.

[shellixyz]

Nice. I have some polishing to do but I will be working on the new PR tomorrow and should be ready soon :)