Battery level swings
-
I'm currently working on building a sensor with a DHT-11, Dallas temperature sensor and a door switch. Currently everything is running from 2AA batteries which run through a booster. I've been monitoring the battery voltage being reported after adding in the voltage divider according to the build instructions and I am seeing swings of about 5-10% reported in the battery level between readings. Just wondering if this was typical, or if there is something I should be looking at? I've tried with and without the capacitor on R2 of the voltage divider. I'm taking the reading from the batteries by tying into the VIN pin on the regulator then through the voltage divider.
Any guidance would be appreciated. Thanks!
-
I had an issue where I would get one voltage, then a lower voltage, then the original voltage, back and forth.
I was reading the voltage every time through the loop routine and reporting it if there was a difference. It seems the battery voltage would drop slightly after a transmit, then recover, so I would get two voltages reported, one from the loop before the transmit, and one after.
I rewrote the routine to only check the voltage when I was going to send sensor data anyway, then always take the voltage before the sensor data transmitted.
That made the battery data very stable.
-
@nagelc Intersting - could you pls share your code?
-
Yes, it is probably best to read before RF transmissions. When power drain increases from the battery, the nominal voltage will drop. It is really a matter of taste if you want to report the "idle" voltage (read before transmitting) or "hyper active" (read immediately after transmitting). The first option is optimistic, while the second is pessimistic, as in that once battery level get sufficiently low, things will operate, but drop out when attempting transmission. Therefore, it would be advisable to tune the algorithm value reporting with respect to this, so that the percentage reported correspond to the behavior of the cirquit and your expectations. In other words, you want it to tell you it is ~5% battery left when the overall operation of the device is expected to fail soon.
And then you also want to (as you wrote) do the read on a stable state to reduce noise, so generally I would say that it is the "idle" level that should be the value to calibrate against.
-
I did have the battery check happening just before going into sleep mode, so I guess it makes sense that in some cases the battery would be low and trying to recover. I'm assuming the peaks I was seeing could have resulted from when sensors were checked and there was no change in value and so no transmit which would have left the battery with more juice.
I've moved my battery check routine to be the first thing in the loop and I'll see how it goes.
@Anticimex, your point about tuning the algorithm is a good one because I've been using NiMh batteries to power the system which are topping out at about 2.8V when fully charged, and the booster is supposed to work down to 0.8V, so I'd like to realign the range for the reporting to fit this. Any suggestions on the best way to do this?
-
@TroyF
There is some info and examples on the homepage.
There are also alternative approaches to measuring the battery level. I have made one proposal myself, but I have not had the time to implement and test it yet. The idea is to isolate the measurement and minimize losses.
-
Today I discovered the same "swings" in my sensor. I moved the code for measuring the voltage after the radio-sleep. Right now it seems to be stable.
-
I think it's also worth to note that the swing will increase significant near the battery end of life. At least from what I've seen.
