Electronic – Low power IR detector for microcontroller wake-up

TI's MSP430 is well known for its low-power: I've used the MSP430F1101 in an application which included the microcontroller, a voltage regulator and a reset circuit, which, with the controller active, consumed less than 5\$\mu\$A typical.

It depends on your needs. My controller didn't need high speed, so I could operate it on a 32.768kHz crystal, which saves a lot of power compared to for instance 4MHz. You say you have an update rate of 3200Hz, then a 32.768kHz crystal may be too slow; you can only execute 10 instruction per sample.
The MSP430F1101A is specified at 160\$\mu\$A at 1MHz and 2.2V. This current is almost linear with frequency, so at 100kHz you'd have about 16\$\mu\$A. That's 48\$\mu\$W at 3V. Then it will run for 250 days on a single CR2430 coin cell rated at 290mAh. That's even without using powerdown modes. If you can put the microcontroller in the 0.7\$\mu\$A standby mode most of the time you can extend this easily to several years.
If you would need an opamp with that, there's the LPV521, which needs a miserly 0.4\$\mu\$A. Also discussed here.

Be careful with the Cortex-M0 figures on the ARM website. 52\$\mu\$W/MHz and lower is indeed spectacular, but that's just the core, a complete controller needs more. The LPC1102, for instance, consumes 2mA at 12MHz and 3.3V, that's 550\$\mu\$W/MHz. Ten times the ARM figure, and almost twice what the MSP430 needs.
The Wolverine doesn't seem to be a real product yet.

Edit 1:

3\$\times\$3200 bytes/s is a lot for a standalone low-power application. You'll fill a 64Mb Flash in less than 15 minutes. If your data is 16-bit, less than 7 minutes. And what are you going to do next? I presume you have no connection with a PC to collect the data, otherwise you probably wouldn't need that very low power. But if you're finished in 15 minutes low power is a silly requirement, let alone that the Flash needs a lot more than the microcontroller.

Edit 2:

Aha, wireless! That's new. This may be much more of an issue than the microcontroller. We've seen that < 1mA is achievable, but a RF transceiver will often require 100 to 150mW when active. Try to find a solution for this. You'll have to switch off the transceiver for most of the time, but it may need some time to become active again. Even at a 1% duty cycle it will consume much more than the microcontroller. Do you have specs for the transceiver yet?

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.