Where 'current' is typically < 1A and 'period' is around 2000 milliseconds. 2160000000 is the number of milliseconds in an hour. The problem arises because 2000/2160000000 equates to zero with float.
I guess I could use a much longer time period, but would lose precision with current changes during the 'slot'.
I'd welcome any ideas to help me with the problem, please!
If total_amp_hours is an integer, the roundoff lost by adding a small floating point number to an integer is going to be quite substantial.
E.G. if the new amount is 1.95 Ah then you will only add 1 to total_amp_hours.
You would be better off declaring total_amp_hours as a float and when it is being displayed, round it off to an integer.
I'm not certain I completely understand your problem. If calculating in msec means working with a too small number, then why not calculate in microseconds and scale back (or not) to milliseconds in your calculated result?
Agree with PeterH. I'd say total_amp_hours needs to be typed as float for sure. If current and period are not floats, then coerce them as follows and all should be well.
There is a very simple answer: When you measure to small scale, use smaller rulers.
Instead of units in Amp hours, use micro-Amp or pico-Amp hours and do your math in 32 or 64 bit integers. That will give you 6 to 9 digits right of Amp hours decimal, 32 bit integer will give you that from +2 to -2A. If you're going to need roots, trig or logs, either use a table in PROGMEM or get a finite series formula into a function, except for power of 2 operations. It should still be faster than FP as well as more accurate. Need more accuracy, use nano-Amp hour units. They still add up to Amps, just more zeros.
Thanks for all the helpful replies. I think I've enough to work on now.
It was pretty stupid of me to say that there are 2160000000 milliseconds in an hour! The only excuse I can offer is that I was befuddled by the number of zeros accumulating and multiplied by an extra 60!