Sunday, March 1, 2015

Battery Operated Temperature Sensor - Now About Battery Life

The previous entry on this project is here <link>.

I'm still working on my battery operated sensor and have been testing it for battery life and stability. I've learned a thing or two. First, this is absolutely possible, but not like the various tutorials out there lead you to believe; I'll never be able to get years of battery life like they imply, Second, I'll never be able run a battery completely down.

There's a number of reasons for this, but it will take some explaining. I've been saving the data I'm gathering and some things are noteworthy. Here's a graph of the data I've accumulated so far:

For this, only pay attention to the black line, I'll address the temperature (blue) later. Notice that it starts off around 2.9 volts, that's because I didn't get to uploading the data until the battery had dropped some, then there's some chatter where it started to drop to 2.8 volts and a long string of 2.8 volts until it jumps up. What happened was I only kept one digit to the right of the decimal and the chatter is where it was close to the rounding point, 2.85 volts. Then, because it quit transmitting just after noon on the 26th, I have a straight line until I changed the batteries on the 28th.

So the jump and relatively rapid decline is where I changed the battery and the code to a 50 second on versus 10 second off rate. I wanted data faster than a week at a time. I also added code to sense that it stopped transmitting and drop the reading. This way the battery getting too low would be readily apparent. I learned two things from this: use more precision, and heavier drain to get experience in a shorter amount of time.

Now about the weird temperature readings. After a couple of days of watching the temperature inside, I got bored with the flat line and took it outside. That's what the cyclic activity is from the 20th to the 23rd is.  The drops are experiments I did with the temperature sensor. Things settled down in the temperature sensor before the 26th, but I did still move it around the house some.

Now, take a look at this chart. This is the period after I changed the batteries and was using 50sec on, 10 sec off timing:

No, the batteries didn't last long, but that was my objective for this test. Notice that the device quit when the batteries dropped to 2.754 volts; that makes perfect sense when you think about it a bit. All electronics have some cut off point where they just quit working, for this combination of components, that's the cut off point. The temperature sensor is only good down to 2.7 volts and the processor is over-clocked as it is since I'm running it at the full 16Mhz, and lowered voltage.

What this means is that the rating of the battery doesn't mean much. These things have roughly 1600-1800 mah, but since the device dies at 2.75 volts, I'm only getting a portion of that. Don't make the mistake of thinking you can get all the power out of a battery, the lower voltage will step up and bite you.

There's a lot I can do to extend the battery's usefulness now that I know where it dies. First, I can adjust the sleep-awake factor. It turns out I need less than 10 seconds to take a reading and send it. I could probably drop it as low as 2 seconds. That will mean 58 seconds of sleep where it is drawing microamps of power to keep the timer running. I could add a battery and make it a three battery device. With three batteries I would start out with close to 4.65 volts, giving me almost two volts of range before it quit. This would mean a voltage regulator, but there are low current versions of them that would work. Ideas like a boost power supply aren't going to work because they take a lot of power just to run them. I'd get more out of the batteries, but it would mostly go to supporting the boost supply. I could lower the clock speed on the processor, but that makes timing and other things much more complex.

The test also told me that the battery voltage declines relatively rapidly from 3.1 down to 2.8 where it hangs in for a long period of time. Most of the current I got out of the battery was at this voltage.

Now, I'm going to set it up again for a shorter awake time and keep the code in that indicates when it dies and see what happens while I wait for a nice regulator to come in the mail. Then I'll test it with three batteries and regulation to see how that works out. I don't really want to use three batteries in each device, but I'll take the best road when I know more. Batteries are cheap in bulk, and I'd rather use more if it means the device will last longer.

Some of you will wonder, "Other devices can last a year or more on two batteries, what's the big deal?" Well, that's true, but they're activated by something. The smoke detector you have is asleep most of the time, and awakened by an external signal. For something like a door sensor, I could put it to sleep for several minutes at a time and wake up to send a message saying it was still alive. It would also wake up on a change in level of the actual sensor; I could probably get a year out of something like that. It's a different ball game. I want to monitor the temperature often enough to be of value, but not constantly. Once a minute is fine and maybe once every couple of minutes, but longer is something I'll have to think about.

More later as I get more experience.

The next entry on this project is here <link>


  1. I used to log data whenever it changed by 3 lsb, which led to a lot of data sometimes. For a room I now log wirelessly every 20mins and this does give a battery life of a year or so. The other change I made was to run the transmitter off one cell and the pic off the other. The transmitter 1 lasts maybe 2-3 years. The tx PA is more tolerant to fluctuation.

    1. I like the idea of sending only when it changes by some threshold, but that still means I have to wake up to check it, which will turn on the radio ... or maybe not. I'm going to test this idea, it could be a nice savings. Especially if I go right back to sleep if the reading didn't change enough.

      What kind of cells are you using? I can't run this stuff on a single AA without a boost supply and that will eat more power.

      Thanks for the idea.

  2. I was given a new laptop lion battery which I split into 4v x 1ah. Boost converters are no real use as they use a lot of quiescent power. However, if you keep a battery just to power the uP, that can switch on the boost, but I doubt it's worth the effort. If you can some how just wake up the uP to do checks, that shouldn't use much juice. Lion batteries are nice as the output stays pretty constant until they die.

    1. I see. For this project I want to use disposable batteries, and the cheaper the battery, the better. So, I have to deal with a dying battery. I may go to three cells if I can't get enough life out of just two.

  3. Try 3 cells as the current will reduce. Also extend the antenna as much as possible and reduce the PA power right down. I send the same transmission 3 times. As you're using xbee, you could maybe store up data and send it one burst, then send a confirmation back. A larger aerial in the house helps too.

    1. I thought about the burst technique, but discounted it for my application because I want to eventually use the data to control the air in the house. It's a good idea though for just gathering data over time. The XBee antenna is already as big as is reasonable for something like this, and I have a network the devices can leverage, so I should be able to reduce the power. I'll check into that some.

      Nice thoughts, thank you.

  4. I've probably got the wrong end of the wrong stick, but you say you need a regulator for 3 cells; the atmega328p is good for 5.5V, with a standby current of 0.75uA with RTC running. Can't this wake up at a programmable internal, switch on a regulator for XBee & sensor, TX, and sleep? As a cheat, you could run the XBee off the first 2 cells, then the atmega off the 3rd in series, but you'd probably squeeze more life with a regulator.

    1. Yes, the arduino can run on three batteries, but the XBee would die. I never thought of using two cells for the XBee, that's worth a try. If I try to control a regulator using the arduino, I need a regulator that will shutoff, and I haven't found one in a thru hole configuration (yet).

      But with those low quiescent current regulators, I may not need to. This is one of those projects that takes a LOT of experimenting to get working like one wants it to.

      Thanks for the suggestions, I'll try them out.

  5. I am reading Robert Faludi's book "Building Wireless Sensor Networks" and he has a nice section on Xbee sleep modes (Chapter 6). In his book Figure 6.5 he uses a Power Switch relay driven by a 2N2904 off of a digital out pin on the end device to essentially shut everything down during sleep (except the Xbee of course) and turn on upon wake. The rely is a bit of a power hog, but if you keep your radio wake time short, this could extend the battery life. Also, I am considering using C batteries.

    My project idea is to measure temperature of attic, room and crawl space for a place we have in the White Mountains. I will take average readings and if any of the three drops below freezing, I will get an SMS status message. So the batteries need to last 6 months or longer.

    Your posts are very helpful with the development of my project.

    1. I just discovered he rechargeable lithium ion batteries that are showing up everywhere. The ones that really caught my eye is the 18560 or 16340. I've used them in flashlights and they last a long time. I already get more than six months using cheap AA batteries, but these things could last a really long time and then be rechargeable.

      In my sensors I use the Arduino to turn itself and the XBee off leaving only the timer circuitry on the Arduino running. I get erratic results on battery life because I use the cheapest AA batteries I can get, but they all last more than six months.

      I currently have five of the devices scattered around the house.