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?
Best Answer
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.