Show battery level as % full

[geeksville]

Search the internet for tables mapping 18650 battery voltage to % full. Use that in screen.cpp instead of showing voltage.

[petermm]

http://lygte-info.dk/info/BatteryChargePercent%20UK.html

seems like a pretty big diff at 3.6V either 3% or 39% dependent on cell.. so maybe a default table that can be user configurable...

[Professr]

I've been tinkering with a graphical display for the battery, with the usual bars at 0-25%, 25-50%, 50-75%, 75-100%. I could set those based on a battery voltage threshold array from this table, though my personal experience is that these numbers look pretty pessimistic for the batteries I've got (they all read around 3.9-4.0V when fully charged). TBH, I've never done a pull request before so your patience is appreciated, but if this code would be useful...?

[geeksville]

oh yes - a PR would be appreciated! see my other comment on your other great comment.

re: voltages hmm - I think your batteries might have issues (are the 18650s or some other form factor?) On mine the all show 4.19 for fully charged.

If they are 18650s is it possible you have ones that advertise "overcharge protection"? Those batteries are slightly longer and include a small circuit in the end.

[Professr]

That's probably it (they are 18650s) but I have a new batch coming without protection so I can test with those. Given the variation in cell makes, what do you think about 3.9+ being 4/4 bars, 3.8-3.9 being 3/4 bars, 3.7-3.8 being 2/4 bars, 3.6-3.7 being 1/4 bars, and anything below 3.6 0/4 bars?

[lgoix]

The MeshProtos suggest that the BatteryLevel is sent with Position:

• 1-100 (0 means not provided)

I am not sure if we want this feature to be available for 1.0, but if we display something on screen, I am interested to display the same thing in the app (% or bars, both are useful for someone that as a phone and want to see the current state of the mesh).

off topic:

I don't like to have the battery level sent with position, I would prefer the GPS accuracy instead. A radio without GPS would never send position. BatteryLevel should be shared with other device status. As an user, I would like to know the hardware/firmware as a health status. Does the TBEAM give any temperature ?

[Professr]

1-100 should be straightforward as long as we're not expecting perfect accuracy. We could try to do nonlinear interpolation, but the table varies too much by battery for it to really be worth it IMO - except at the extremes, it's pretty linear. A simple batteryPercentage = (batteryVoltage - 3.5) / (4.1 - 3.5) clamped to 1-100 should give a number that's practical, right? We could make the upper and lower threshold voltages be constants defined in power.h (I'd also like to move the definition for MIN_BAT_MILLIVOLTS into power.h too, if that's a good place for power configuration values)

[Professr]

The TBEAM doesn't appear to have a thermometer onboard (I think the GPS module has to know it, but the API doesn't expose it). It says it supports reading it with the ADC pins, I assume via a thermistor or something. The only projects I see involving a TBEAM and temperature use a separate BME280 chip

[Professr]

I've added battery percentage support and moved the voltage definitions to power.h It's just a linear estimation, and it doesn't address sending the charge percentage to the app, so I don't know if that's pull-request-worthy or not.

[geeksville]

@Professr that sounds great. When I get your PR I'll do the minor (but poorly documented ;-)) glue so that your %full data appears for @lgoix in the protobuf messages (both for the local node and any other node we receive position reports from.

I'll also cc you so you'll have an idea what I had to do (my devious plan to lure you into doing more things ;-))

[lgoix]

Does the radio knows the elapsed time since last reset?

It could be a useful data to evaluate the battery usage per configuration to be sent for stats

[Professr]

I'm sure a timestamp could be captured at boot or at first GPS time fix... There's probably more you could do with the axp's Coulomb counters, since I think you should be able to use them for total expenditure vs. voltage drop since last boot and for a shorter-term delta that better represents immediate / recent consumption (I'm thinking that's important if you go from several hours by yourself to suddenly communicating in a 20-node mesh). I ain't touching that math, myself.

[geeksville]

@lgoix yep - the device knows both msecs since last reset (though not time of last charge - but we could add that if we wanted). Nodes with GPS (or a phone that helped them) also know absolute time (within a secondish).

@Professr thanks a bunch. alas, automatic charge data (and coulomb counters) are not actually implemented on the axp192 part (supposedly they are implemented on the axp202). And I'm with you - I'm too lazy to try and make some sort of EKF (or whatever) to try and do a good coulomb counter on the main CPU by polling the amp draw/charge and trying to integrate.

One thing that helps us is the current draw for our devices is slow low that the crude voltage based threshold is probably not too bad.

[geeksville]

fixed by @professr!