4
\$\begingroup\$

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?

\$\endgroup\$
13
  • 4
    \$\begingroup\$ TI's MSP430 are claimed to consume very little power. But I think I in your application, the wireless transmission will the dominant factor. Perhaps, it might be better to sample every 5 minutes but transmit the entire data once an hour. \$\endgroup\$
    – Saad
    May 29 '12 at 15:33
  • \$\begingroup\$ If I remember correctly, there are MSP430s which do wireless out of the box. \$\endgroup\$
    – AndrejaKo
    May 29 '12 at 15:36
  • \$\begingroup\$ @Saad: no that won't do. They need the data on the other side, you can't buffer it. \$\endgroup\$ May 29 '12 at 16:02
  • \$\begingroup\$ You could set limits to temperature change required before it transmits. If temperature is stabale within set bounds it does not transmit. \$\endgroup\$
    – Russell McMahon
    May 29 '12 at 16:42
  • 1
    \$\begingroup\$ @AndrejaKo and Kellenjb: you guys babble too much :). Why don't you post as an answer? \$\endgroup\$ May 29 '12 at 17:10
8
\$\begingroup\$

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.

\$\endgroup\$
15
  • \$\begingroup\$ I second Olin's recommendation of a XLP PIC, and suggest using a Bluetooth low energy (BLE) for the wireless module. It has a range of 50m line of sight, so should be good for 20m otherwise, and has 24-bit CRC, 3 ms setup time, and is designed to run off of a coin cell (max 15 ma). \$\endgroup\$
    – tcrosley
    May 29 '12 at 20:00
  • \$\begingroup\$ @tcrosley, 15mA is a bit too high for a single coin cell, that is going to show significantly reduced life. \$\endgroup\$
    – Kortuk
    May 30 '12 at 4:04
  • 2
    \$\begingroup\$ @Kortuk, Because BLE has been touting the 15 mA figure, TI did some tests and concluded that peak currents up to 30 mA have minimal impact on battery capacity of a CR2032 cell. Nordic ran similar tests, and found that as you get to 50 or 80 mA peaks, the effective capacity of a CR2032 is severely degraded. \$\endgroup\$
    – tcrosley
    May 30 '12 at 5:01
  • \$\begingroup\$ @tcrosley, interesting. When we did testing passing 10mA showed a sharp curve in the capacity of the batteries, maybe we never tried short enough pulse lengths. I wish I had a thousand batteries to test this more thoroughly. Someone disagreed with olin, although I am questioning a figure that was not me olin(dont want any rage :) \$\endgroup\$
    – Kortuk
    May 30 '12 at 6:45
  • \$\begingroup\$ @tcrosley I hate to disagree with you, but I I have personally tested a number of bulk, commercially available LiMn cells, and they barely can reach 15mA in a short circuit as they age, never mind at a usable voltage. I suppose you could use a low-voltage capable boost regulator to salvage some usable range, but yuck. For reference, see graph 2/3 under the CR2032 section in the following link. Even by 3mA, you are rapidly accelerating to an unusable voltage: panasonic.com/industrial/includes/pdf/… \$\endgroup\$ May 30 '12 at 6:46
5
\$\begingroup\$

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.

\$\endgroup\$
2
  • \$\begingroup\$ +1 for realizing that sleep current does dominate total power consumption. I have updated my answer accordingly. \$\endgroup\$ May 30 '12 at 19:22
  • \$\begingroup\$ @OlinLathrop I would have never said that, but I've also done a lot of measurements, and learned a lot in the last months \$\endgroup\$
    – clabacchio
    May 31 '12 at 6:54
2
\$\begingroup\$

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:

enter image description here

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.

\$\endgroup\$
1
\$\begingroup\$

"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.

\$\endgroup\$
1
0
\$\begingroup\$

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.

\$\endgroup\$
14
  • 1
    \$\begingroup\$ You dont have to tie down unused IO, it actually works just as well to drive them all as outputs. \$\endgroup\$
    – Kortuk
    May 30 '12 at 8:59
  • \$\begingroup\$ You also don't need the RTC peripheral, just the watch crystal oscillator and associated timer. There is no requirement to know absolute time, only relative elapsed time. \$\endgroup\$ May 30 '12 at 16:57
  • \$\begingroup\$ @Kortuk You DO need to tie down unused IO, whether in software of hardware. Personally, I prefer hardware where possible because I'd rather not have my PCB any more ESD-vulnerable than necessary, especially when the it has no batteries in it. I think most PCB designers would consider floating CMOS I/O a nasty habit, no matter what you plan to do in software. \$\endgroup\$ May 30 '12 at 19:06
  • \$\begingroup\$ @Olin I view it the other way around. Why do a bunch of hacking on TMR1 interrupts with unneccesary 2 sec. wakeups when you can set an RTCC alarm once and forget about it. The 2 sec. wakeups might not seem like a big deal if your application uses the FRC, but if you have to wakeup a PLL or crystal, that could figure into your power budget if you don't use a bunch of run-time clock switching. Given that both have the same TMR1 clock requirement in terms of sleep current, I think the RTCC is a cleaner solution. \$\endgroup\$ May 30 '12 at 19:13
  • \$\begingroup\$ @Olin I should add that I was not suggesting you actually set the RTCC to absolute time, only to use a periodic alarm (requiring the RTCC/TMR1 clock to be enabled in sleep). \$\endgroup\$ May 30 '12 at 19:14
-1
\$\begingroup\$

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...

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.