Add battery mapping for more accurate battery levels

[luigi311]

This adds battery chemistry type mapping for more accurate battery percentage to be calculated for companion devices. It also adds in the battery percentage as a number in the sensor screen on the companion ui-new.

This is similar to the approach used by meshtastic and i think its one of the easy ways to handle this without bloating the memory usage as only a single OCV table needs to be loaded in at a time, li-ion is used by default since most devices use that. Using a similar approach to meshtastic and using the same table definition should also allow for easy collaboration down the line for these curves, say a new device is released and its got a new battery chemistry or a funky curve, either meshtastic or meshcore can do the initial implementation and the OCV_ARRAY should be able to be copied over between the two projects.

It can be changed in the variants.h file for devices in case some devices come from the factory with a different chemistry type by setting
-D CELL_TYPE_LIFEPO4=1

It should also allow variants to define their own curve with the OCV_ARRAY build flag with their own 11 values map.

This will not impact the percentages displayed from the mobile app side as that uses its own calculations for it from my understanding and that probably always maps over to li-ion curve so it either needs to be updated to pull battery percentage from the device that way it uses the correct chemistry curve automatically or meshcore needs to broadcast the chemistry type externally so the app can chose the correct curve.

For now i left it out of the main meshcore code and only used it in the ui but it should hopefully be easy to add in everywhere else and use it instead voltages so it does certain tasks when percentage thresholds are reached such as shutting down at X percentage.

This also adds a NUM_CELLS_IN_SERIES build flag that defaults to 1 that way it brings the pack voltage down to an averaged cell value to be used for the mapping. This is untested though as i only have the t-echo with the single cell.

I only have t-echo devices for now so this was only tested two t-echos to compare the before and after % so it probably needs to be tested by other devices and other chemistry types to see if its calculating the percentages correctly.

Inspired by #413
Fixes #1124 #398

[luigi311]

Heres what it looks like with this change on the t-echo, left is with the change, right is with the current linear calculation

Here is also what all the battery voltages -> SoC look like when graphed out

[luigi311]

@jbrazio since it seemed like you were the most involved person with reviews on the 413 implementation.

[luigi311]

accidently built this on top of main, has been retargeted to dev and rebased

[jbrazio]

@luigi311 very well implemented. 👏

I added some comments for brainstorming if it would make sense to decouple the battery properties from the boards, as almost none of them have a battery standard.

[1nerdherder]

Has anyone working on this noticed that PR#2088 allows the setting of a battery chemistry in the CLI - and therefore the battery % calculation should look to that variable to apply the correct scale factors to calculate percentage?

[446564]

@luigi311 still interested? please address conflicts are review comments/suggestions if you are, otherwise can we close?

[luigi311]

@446564 this has been rebased. Rebuilt and flashed on my techo and seems to be working correctly still 3.39V on device right now and it reads 17% which lines up with my chart above

[luigi311]

i saw someone added in a min/max mv overrides for the lilygo_tbeam_1w so i converted it to the new structure for this by specifying that it has two cells in series but i can not test this change myself.

I also updated the ui-orig to use the new helper to remove the min/max mv override there too so its consistent. I have no way to test ui-orig though as i only have a techo on me. I did see that the R1 neo is using ui-orig so i did do a build for it and looks like it compiles correctly.

[luigi311]

@stevenlafl looks like you made the min/max v changes to support the lilygo tbeam 1w. Can you take a look at this and see how the percentages look to you.

[446564]

Looks good and working as described.

I only wonder about instead of build flags this is a configurable user pref with the same default. Configurable over CLI to start. To avoid having all tables in memory at once we could require a restart to change either chemistry or cell number.

I even wonder if the entire OCV array should be user configurable, for example I have Li-Po devices that die at 3.4v and others that die at 3.2v so seeing 10-20% SoC when it's about to die is still pretty misleading.

Then we can possibly also send this over telemetry instead of the app guessing.

But all of this can always be done in future changes. Awesome work.