Which low power microcontroller for short active periods at long intervals?

Question

Regarding this question.

In the question was asked for a solution for monitoring a voltage over a long time. The question contains hints to a microcontroller solution, and a couple of answers also covered that, but the real question didn't need a microcontroller at all.

Now if it would require a microntroller, what are the best choices for low power? Concrete: I need to measure temperature once every 5 minutes and wirelessly transmit the value and go back to sleep. Transmission is <20m, not line-of-sight. Any protocol/frequency. Just two bytes of data to send. I want the battery, a 600mAh CR2450, to last as long as possible. Interval precision better than 0.5% possible (that's 1.5" in 5 minutes)?

edit (by stevenvh)
Federico mentions a home weather station with wireless outdoor thermometer in a comment. I think that could give a good idea of the type of application. The thermometer indeed transmits its data every 5 minutes, and works for more than a year on one set of batteries.

If it makes any difference: how about sampling once every hour?

Answer 1

The new Microchip PICs with the "XLP" designation are very low power. I hear that the TI MSP430 are also quite low power but have not investigated that myself.

0.5% accuracy rules out using a internal R-C oscillator for wakeup. The best accessible solution for that will be a micro that is intended to run a 32768 Hz crystal like is used in wrist watches. In the PIC line, this is a micro with a timer 1 oscillator, which is most of them. The main oscillator and the CPU can be shut down, but the watch crystal and timer 1 keep running and can be used to wake the processor periodically. Without doing anything special, this will happen every 2 seconds. The firmware then counts 2 second wakeups to get to whatever longer time you want. If your processing requirements are small, one of the newer four digit PIC 16LFxxxx should do nicely. They have a internal oscillator to run the CPU from when it does wake up and are otherwise small, cheap, and low power.

As for the radio transmission, it's not as simple as just sending a couple of bytes. The other end has to identify you are transmitting, figure out the level to detect 1 from 0, etc. In practise this ususally means manchester encoding with maybe 10 bits of preamble, a start bit, the 16 data bits, then a checksum.

The chance of any one bit of a RF transmission getting messed up is high enough that you need to plan for that happening. With CRC checksum you at least have a good chance to determine it happened. You then have to decide how likely that is and what the consequences are of the data not getting thru. You could send two packets every time hoping that at least one gets thru. But if you're going to spend the power on that, you could just as well send at half the interval so that when things do work right you get better data. There is no easy answer. Reliability can not be guaranteed without two-way communication. It's a probability and cost versus risk game.

If you really want to reduce overall power, then you have to look into fancy error correction encoding schemes. Some of these won't be easy to do in a small micro. Some put most of the burden onto the receiver. There are lots of schemes. For example, one of the Venus probes of the 1970s sent the data both forwards and backwards (and probably a few more tricks). It took over a day on a high end mainframe at the time to decode the last frame before the probe went into clouds and couldn't be heard from. Again, there are lots of schemes with different tradeoffs, but consider them against the cost of a larger battery.

Added:

I had originally thought that power would be dominated by the RF transmitter, but hadn't really worked thru the numbers. I saw Clabacchio's answer where he states the opposite, so let's do the math.

Let's say the transmitter draws 20 mA average when on. This is plausible for a ISM band 434 MHz OOK transmitter. Let's say data is sent using manchester coding at 10 kHz bit rate. This is easily doable with a small PIC. I have done exactly this with a PIC 10F202 in some small active RFID tags. Let's say the total transmitted stream is 10 preamble bits, 1 start bit, 16 data bits, and 16 checksum bits, for a total of 43 bits. It takes 4.3 ms to send those bits. The transmitter will need a millisecond or two startup time during which it draws some power but less than when actually transmitting. So let's round up and say the power draw is equivalent to 5 ms at 20 mA every 5 minutes. That comes out to 333 nA average. That means the sleep current of the processor is a significant factor in overall battery life, particularly since it will be running a 32768 Hz watch crystal during that time. In fact, it looks like the sleep plus watch crystal current will be more than the average RF transmission current.

Answer 2

I can tell you about my experience with Jennic JN5148, which I'm now using for my thesis. It's a module embedding a microcontroller and a 2.4 GHz transceiver, working with ZigBee and JenNet, a very simple proprietary protocol. Plus, it embeds error checking in the 802.15 protocol and, if you want, encryption.

With a proper power management, you can go down to 2 uA in sleep mode, or even lower but then you need an external event to wake your microcontroller. It uses a 32 kHz oscillator for sleep time, so you can check if it's stable enough for your application. The current when transmitting-receiving is 15-17.5 mA. The range is nominal 100-500 m clear space, tested by me to be (very approximately) around 30 m with walls and doors.

Since I'm going low low power, I'm collecting some statistics about the consumption, and for your application (just measuring voltage), you should stay below 3 uA of current during sleep time (considering some leakage from the board), and around 50-100 uC (A*s), which at your duty cycle (once every 5 minutes) gives an average current of 3.5 uA. You'll see that this current is much lower than the leakage of the battery, and for the 600 mAh case you should run for 171'000 hours (fair enough?) in theory.

About the average power, I disagree with Olin :). In my experience, at that low duty cycle the power consumption will largely be dominated by the standby current (no matter how small), which should be below 1 uA (very very small for a real circuit, not only the specs) to be comparable. And you have to CAREFULLY design and program your board (pay attention to I/O pins) to achieve those low values.

Energy scavenging

If it's an outdoor application, and it has to run for a long time, why don't you provide it with a small solar panel (around 5-10$) which may give to your thermometer a virtually infinite life?

We're doing it, and the panel provides - indoor - enough current for the circuit to survive, outdoors will really be a breeze, and a 50 mAh LiPo battery (again, few dollars) will be enough.

Answer 3

For low-power processors that you can purchase in the US, the battle is MSP430 v. PIC XLP. Both manufacturers will claim lower power. You have to compare against your specs to make sure.

If you want to measure temperature, you can use the microcontroller by itself. The MSP430 temperature sensor will need a single-point calibration, or the PIC will need a two-point calibration to get good temperature measurement.

You can do your own calculation based on the datasheet currents, but in my experience the MSP430 has lower current than Microchip XLP. The current you care about will be the idle current with a 32.768 kHz clock running. For MSP430G2231 this is 0.65 μA typical at 3V, 25C. (The 2231 is the chip included in Launchpad, as is a 32.768 crystal). The PIC XLP equivalent would be PIC16LF1823, which runs the clock at 2.3 μA typical at 3V, 25C. Be warned, these values go up with temperature with both parts:

It is my assumption (based on the very low duty cycle) that the 32.768 kHz current will dominate your battery life, but you should definitely do the calculation.

It is also my assumption that the radio can be chosen independently from the processor. But the radio current will be a big part of the power budget.

Answer 4

"Innovative Techniques for Extremely Low Power Consumption with 8-bit Microcontrollers" by Arne Martin Holberg and Asmund Saetre has a (possibly slightly biased) comparison of two TI MSP430 chips, an Atmel ATmega165P, and a couple other microcontrollers.

While for years the TI MSP430 series was by far the lowest-power microcontroller available, the Atmel "Picopower" series and the Microchip "XLP" series are now very close and better in some applications.

Answer 5

I have personally done something very similar to what you describe. I found that the PIC24FJ64GB002 and MRF24J40MA 2.4GHz transceiver module were a good fit (there's a free 802.15.4 RF stack from Microchip if you don't want to write it yourself). In this case I have automatic retries and confirmation of delivery.

I found that it was best to have 2 batteries in series to squeeze every last mAHr out of the batteries. I used a 1uA Iqq LDO to power the micro, and a buck to power the RF whose power was disconnected in sleep mode by a MOSFET.

My results were about 3.6uA of sleep current, and several years of battery life on 2x 200mAHr CR2032s (depends, of course, on your update interval - mine was 1 hour). Your precise timing requirements will demand a 32.768kHz crystal as well, and the RTCC/TMR1 clock source running in sleep, which will add a few more microamps.

btw, Don't forget to tie down all unused IO by connecting them to the ground plane or, if that isn't possible, driving them in software.

Answer 6

the msp430 was known for being low power but supposedly the cortex-m0 is lower power than everyone else. I have used these but not measured power no run off of a battery...