Dumb LFP batterie monitor

Hi,

I’m toying with my old camping battery, it’s an aliexpress golf car battery. I’ve added a arduino based monitor. Because sometime the battery just shutdwon, the inegrated screen always says 90% not problem with my electric cooler… lol my beers are not cold anymore !

first Arduino project for me :stuck_out_tongue:

the code is here GitHub - quazardous/bame · GitHub

It’s not quite finished yet, the 30kb limit is very frustrating lol (but it’s also challenging)

I tried to create some kind of auto calibration and a minimal voltage helper…

Any help will be much appreciated btw !

Your battery monitor tries to "correct" its charge estimate by peeking at the voltage. But LiFePO4 batteries (assuming this is what you have because of LFP in the variables's name) hold a nearly constant voltage until they're almost dead — so the voltage always looks fine, and the monitor keeps resetting its reading to ~90%. Then the battery suddenly dies with no warning.

Your code already tracks amps flowing in and out over time — that's the right way to do it and you should stick with that. The problem is the code also has a voltage check that periodically "corrects" the reading, and since LiFePO4 voltage always looks fine until the battery is nearly dead, it just keeps resetting back to 90%. Try disabling or limiting that voltage correction so the amp tracking can do its job uninterrupted.

thx, I was sur that the voltage was evolving… so bye bye deep sleep mode. the monitor muste be always on …

Welcome Back!
I do not fully understand what you are trying to do but it sounds like a classical application for a "coulomb counter"

Just trying to learn something new and have fun

Fun with flags :face_savoring_food:

If it’s a good deep sleep mode on a good board, then the current consumption might be really really small… IOT devices get 2 year of lifetime on small coin batteries…

It looks like a classic Nano from the picture. You can free an extra 1.5kB of flash memory by treating it as Uno instead. They both have exactly the same chip (atmega328p) and this identity change can be done with the "burn bootloader" procedure. For historical reasons the Nano reserves 2kB for the bootloader although now only 512B is used.