My next task was to get the partially functioning battery monitoring code worked out. I made several different attempts to work out something that I was happy with, before finally settling on the current solution, which may get changed yet again!
Basically the monitor pin on the Lithium Backpack outputs the current voltage of the battery. Knowing that this is approximately 2 – 4.5v I decided to try to use the full range of the analog pin, but build a voltage divider to get a 4.5v reference voltage. I’m not an electronics guy, although I’m learning fast, so sometimes I still get excited about the little victories. Needless to say I was excited about getting a little circuit made out of resistors working! A little math in the code, and I had a somewhat accurate display of the percentage of battery remaining. Well kind of, that is until the voltage dropped. With the bottom end of the voltage range being ~2v instead of 0, the percentage was only partially accurate through the top half of the range.
I decided to use raw numbers instead, and map them to known high and low values. I set up a test sketch to send the analog output to the Bluetooth (so I could stay on battery power, and not plug into the USB), and built a quick and dirty .NET app that would log the data to a text file. I then left the unit running overnight and logged the values from fully charged to shutdown. I ran it again the next day while I was working, and took the lowest / highest values from those two runs as my base points for mapping the % of battery remaining.
I should point out that I’m pretty sure that this is not a 100% accurate method. I bet that if I charted the results I would see that the voltage drop is not constant over the life of the charge. Implementing my current solution only requires a call to map(), where implementing a more accurate solution would require a lookup table with time and voltage parameters, or some math that I’m really not in the mood to deal with at this point!. At the end of the project, if there is memory left on the Arduino, I will come back to this particular feature and investigate a more thorough solution.
I also added a routine to average the percentage; the output of voltage jumps around quite a bit, and once it is mapped and converted to a percentage it tends to constantly hover in a +-3% area. By averaging the last 10 reads I was able to slow the “flutter” down a bit. I may increase the sample rate on this as I refine the code.