Closed ericklein closed 11 months ago
I'll fix this when I do the UI refresh
Units are also not showing 100% charge when fully charged. Fully charged is battery dependent, so maybe we loosen our battery display algorthym requirements to larger (%) visual "chunks" that give the user an approximate range the battery is in?
Assuming the LC709203F percent value is accurate, you could use its values to validate key value (<10%, 100%, 50%?) visualization. It's a known bug that the software calculation is a straight line degradation and therefore not accurate (independent of visualization) once you get close to 3.6v, where voltage drops precipitously to 3.2v.
I've reviewed this issue using an upgraded battery_check app with the battery gauge code from RCO2/AQ. The gauge is accurate. The code for software approximation of battery percentage is incorrect and will be fixed via a custom LUT vs linear approximation.
The formula for determining the width of the displayed battery level based on battery percentage is incorrect. Any battery percentage below ~18% in the current calculation will display as an empty (no pixel width) battery. A more correct pseudo-formula is int(0.5+((battery_percentage*(barWidth-4)/100)). The roundup for the int calculation introduces some error rate in overestimating remaining battery, but the # of pixels used to represent the value is so low it is "good enough".
implemented in rco2. These two changes need to be tested.
implemented in aq for testing. AQ does not have software approximation changes yet as deployed hardware uses LC709203F.
Battery levels displayed on screen are incorrect, appearing lower than they actually are. 18% is being visualized as ~ 10% in the graphic.