Smart power management (mega162) - advice needed

Go To Last Post
32 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi everyone,

This is my first post, so forgive me all mistakes.

This is my problem:
I need battery supply for my circuit that will be able to operate for minimum 3 years (battery 3.6V)and will be reliable. Most of time, device will be in sleep mode, it has to wake up every 10 minutes, wait for radio transmission from host (radio will operate maximum for 2 second)and go sleep again. As you see most of energy is taken in "power down" mode, so the minimum supply current is the key.Here goes my problem:
- minimum supply demand is in POWERDOWN mode - but uC must be woken by external circuit (external interrupt), I'm thinking about RTC like PCF8563 on INT0 - but what about reliability, uC has to wake up no matter what happen, if something will happen with RTC i wont be able to wake up uC and resolve problem.
- POWERSAVE seems to be more reliable but it takes much more energy or mayby i'm wrong,

- second problem: I need smart battery check - well, I need only to know if battery is almost dead.

Waiting for your ideas.

Thx,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

about the second problem:

The easiest way to do that is to use a resistor divider of some sort and feed the battery to one input of your AVRs analog comparator. for the other input, use the 1.1V internal reference. use as high value resistors as possible to minimize the current consumption of this solution.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you looked at the ATmega164PV? It consumes less than 1µA in power save mode. And works with a supply voltage down to 1.8V

Monitoring the battery voltage is very easy. The chip has an internal 1.1V reference voltage. The ADC can be configured to use Vcc as ADC reference voltage and select the internal 1.1V reference as ADC input. Thus the ADC result increases when the battery voltage drops.

Regards
Sebastian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bloody-orc wrote:
about the second problem:

The easiest way to do that is to use a resistor divider of some sort and feed the battery to one input of your AVRs analog comparator. for the other input, use the 1.1V internal reference. use as high value resistors as possible to minimize the current consumption of this solution.

Well, I can't use comparator beacause I need second UART. Mayby you know some good external supervisor chip?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dusza wrote:
Well, I can't use comparator beacause I need second UART. Mayby you know some good external supervisor chip?

Can you explain why the use of the analog comparator excludes the availability of the second UART?

Well, I know my english isn't the best. What I tried to explain above was that you can monitor the battery voltage without any external components. All you need is allready inside the AVR.

Regards
Sebastian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've implemented something like that using a tiny and the watchdog. After reset the AVR does its thing (in my case it turns on an external RF transmitter, transmits a short beep, shuts everything down) and goes back into power down. The watchdog wakes it up after it expires and the micro does its thing again.

Power consumption is minimal as only the watchdog is running (<10uA). If nothing else is consuming power you'll need 260mAh of Battery capacity to power it during 3 years.

I suppose you are using a Lithium Battery ?

Markus

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S-Sohn wrote:
Dusza wrote:
Well, I can't use comparator beacause I need second UART. Mayby you know some good external supervisor chip?

Can you explain why the use of the analog comparator excludes the availability of the second UART?

Well, I know my english isn't the best. What I tried to explain above was that you can monitor the battery voltage without any external components. All you need is allready inside the AVR.

Regards
Sebastian

Your idea was about using ADC (Analog To Digital Converter) and it's the best solution but only on atmega164 because it has ADC. If you want to use Analog Comparator (bloody_orc's idea above) you need AIN1 pin that is TX1 on UART1.
and atmega164 is probably more expensive...
but I have to check this out - .

Thx

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Almost every AVR with build in ADC has this feature. Even the old ATmega8535. If you're looking at price then the ATmega48 could be interesting for you. But you mentioned a 2nd UART and the mega48 has only one. The mega164 is the smallest AVR with 2 UARTs along with the mega162 which has no ADC.

When comparing prices at digikey the ATmega164PV seams to be the cheaper alternative.

EDIT: Well, could you be so kind and tell us at which AVR you're currently looking?
EDIT 2: Sorry, I oversight that you mentioned the mega162 in the subject.

Regards
Sebastian

Last Edited: Mon. Nov 5, 2007 - 01:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

markus_b wrote:
I've implemented something like that using a tiny and the watchdog. After reset the AVR does its thing (in my case it turns on an external RF transmitter, transmits a short beep, shuts everything down) and goes back into power down. The watchdog wakes it up after it expires and the micro does its thing again.

Power consumption is minimal as only the watchdog is running (<10uA). If nothing else is consuming power you'll need 260mAh of Battery capacity to power it during 3 years.

I suppose you are using a Lithium Battery ?

Markus

Hi Markus,
It's really smart solution, I have something like that already implemented in battery impulse counter but here I need fixed time interval for radio protocol. The device has to turn on RF in specific time-window every 10 minutes so I have to count the time somehow. I'm not sure if watchdog's clock is stable enough to achieve the goal.
What do you think?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Aha, I just looked at the ATmega162 datasheet and this device uses the same pins for the analog comparator and USART1. But as I said above, the ATmega164PV is the cheaper part.

Regards
Sebastian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The watchdog oscillator was designed for low power, not for stability. So it is not an ideal choice as timer, like we use it here. However, you'll have the synchronization problem with any other timing device too. You'll have to wake up early, wait for the transmission, receive it, process it and go back to sleep. There are some indication about the watchdog's precision in the datasheet.

Maybe an external device pulling an interrupt would be better, but it would consume extra power. Maybe more power over 10 minutes than waking up 10s early and waiting while powered up.

It would be helpful if you could give us some more information what the project is all about. We might be micromanaging a small aspect while forgetting bigger issues. For example you say you need two UART's, this implies two serially connected devices who consume power, maybe way more than what we want to save using the watchdog.

It might be useful to evaluate other AVR's as well, the most recent ones tend to consume the least power. For example a tiny861 needs only 4uA in PowerDown when running only the Watchdog.

Markus

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

As you see most of energy is taken in "power down" mode, so the minimum supply current is the key.

Actually, if you do your energy budget I think that you will find that with a modern (V-chip, P-chip) AVR in powerdown, awakened by the watchdog timer periodically [it ain't that far off, and can be calibrated to skip or change a period once in a while] most of your energy usage will be during the time that you have the radio enabled waiting for a "poll". Thus, with a similar system we have our unit send the message at the appropriate time(s).

You'll probably want to set up your system so no regulator should be involved [IMO].

Just saying "3.6V" isn't enough. A C-size is 8AH; a button much less.

Use a modern AVR. Set the watchdog to max (8 seconds). Count those wakeups (use watchdog interrupt) till ready to do real work, else go right back to sleep.

Now, you probably need an accurate clock for interface to your radio module. However, it take a LONG time (like several hundred ms) for a crystal to wake up and stabilize. So, we use internal oscillator and tune it periodically with a 32kHz crystal hanging on the clock pins and timer2.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lessee--3 years 24x7 is about 25000 hours. If you average 10uA during the sleep periods (2uA sleeping about 99% of the time; 200uA waking up and going back to sleep) that is a total consumption in sleep of 0.25Ah. Not a real biggie.

Now comes the question of how many Ah in the battery. Let's say 1.25Ah,; that leaves 1Ah for transmissions. You want a transaction every 10 minutes, or 150000 transactions. 7uAh per transaction. !

Our radio module draws 37mA during warmup/receive mode, and about 125mA during transmission. In this analysis we ignored the draw during transmission as we send a short packet and those us don't add significantly. Let's say 40mA draw when the radio is awake.

7uAh/40000uA = 0.000175h = 0.63 seconds of awake time per transaction, if I did the algebra correctly.

Now, that isn't bad at all if you wake up and transmit and get an acknowledgement. Retries if the base isn't listening can be a killer. And you see that you can't just sit and listen for your poll for a long period of time.

Also, you need to add the draw during data acquisition. We draw several mA when we have the A/D fired up and are checking our attached devices.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dusza wrote:
Most of time, device will be in sleep mode, it has to wake up every 10 minutes, wait for radio transmission from host (radio will operate maximum for 2 second)and go sleep again.

I understand that the device will receive a transmission from a 'host' every 10 minutes. A receiver might consume substantially less than a transmitter, but , as we need to wait for the transmission, it will be 'on' much longer.

Markus

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Device will operate in telemetry system. The goal is to collect data ones a day, but it has to be done only after request from host system. Maximum time "request to answer" should be 15 min, so device should be operational every 15 min.
So my "fast" math is:
4 time per hour goes:
2 sec for listening with 30mA
0.2 sec for transmit with 600mA (average because normally there will be only short ACK - whole data will be transmitted once per day)
and then sleep with 0.25mA
so generally:
sleep: 0.249mA/h -> 5.99mA/day -> 2188mA/year -> 6.564mA/3years
receive: 0.064mA/h -> 1.54mA/day -> 560mA/year -> 1682mA/3years
transmit:0.13mA/h -> 3.2mA/day -> 1168mA/year -> 3504mA/3years

so battery should be 11750mAh and for example DD size battery SL2790 has 35Ah (calculated by distributor)

as you can see, energy savings in sleep mode will benefit greatly.
I made this calculation for mega162 in POWERSAVE mode with 32kHz clock.
Transmision is time-oriented only with one host(base-station).

So what you think?

Regards...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
and then sleep with 0.25mA

The supply current for power save mode should be less than 20µA. So the other parts consume most power during sleep mode. If you use a switch to power on/off the peripherie, you could save around 6000mA/3years, thus cut in half power consumption.

Hmmm, the datasheet says not if the power consumption in power save mode is with or without the 32kHz oscillator. So maybe you have to add some extra current for the oscillator. So current consumption is approximately 35µA in power save mode. Note that current consumption of the ATmega164 is only 0.8µA.

Regards
Sebastian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Sebastian,

Your idea with ATmega164 is really good solution, but I've already checked my local Atmel distributors and can't purchase ATM164 now in quantity lower than 160 :(
I have to think about it...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How many do you need?
These chips are even hard to get in germany. So when I ordered my dragon at digikey, I also ordered some ATmega164P and ATmega164PV, too (40-Pin DIP package).
I could send up to 10 pieces to you. Send me a mail.

Regards
Sebastian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thx Sebastian,
You are very kind,

Problem is that I have already working RF device on atmega162 (my last project), now I would like to use this board as much as possible ( cost of development - and I'm a little bit lazy too :)) to this battery project, and I found out that atm164 has completely different pinout.
But please let me remember you offer, atm164 seems to be quite nice uC, mayby I'll change the idea.

Still have no solution for battery status (I wanna just know if it's almost dead) any new suggestions?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For a private project you don't have to count each 10th part of a cent. So you could use what you can get or you already have. Maybe an ATtiny25. The tiny25 has a build in ADC and can monitor its power supply. Via SPI interface the mega162 could trigger the tiny25 and receive the battery status. A tiny25 consumes in power down mode less than 0.6µA and less than 0.6mA in active mode (1MHz).

Regards
Sebastian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well,

It's not my private project, so costs are important, another uC will cause problems (you have to program it in every board! etc.) and I will need about 200 RF devices,
but nice try! :)

Thx

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Take a look at Atmels application note AVR180: External Brown-Out Protection There is description of a circuit which consumes only 0.5µA at 3V. If you connect the circuit to an input instead of the reset pin you might have the solution you're looking for.

Regards
Sebastian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First OP wants to save power, but is using an older generation that doesn't have nearly as good features.

Then he wants to listen for 15 minutes but then only listen for two seconds at a time?

He rejects mega164 because he needs to buy 160.
Next he rejects one-off suggestions 'cause he has to build 200 of them.

Note that you can bring battery levels into any pin with a resistor divider, and use logic level as "low battery" indication with appropriate selection of resistor values. Or even a few pins to get a range. Make the end pin low output during test, and float otherwise.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Note that you can bring battery levels into any pin with a resistor divider, and use logic level as "low battery" indication with appropriate selection of resistor values. Or even a few pins to get a range. Make the end pin low output during test, and float otherwise.

I thought about it, too. But I only see information in the datasheet about max. guaranteed low level and min. guaranteed high level. So I thought the input behavior might vary in a big range from device to device. Have you tested this feature? What are your experiences?

Regards
Sebastian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've only got it on a couple of designs on "loss of incoming power" circuits, non-battery. It is a combination of that and our battery-voltage monitoring circuits with A/D.

In my experiments at that time (several years ago), I found that on that AVR model going from 1 to 0 was very consistent, even from chip to chip, and on the same port was almost exact.

Mostly we do go-nogo battery level anyway, and batteries tend to drop fairly quickly once over the knee. So it ain't rocket science. If 4 pins are available then do a 3-step.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Lee!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want to monitor the battery voltage you will need to think very carefully about how you go about doing this, otherwise the monitor circuit could unintentionally become the biggest power consumer in the project as it is connected all the time.

A previous suggestion was a resistor divider circuit to a comparator, or perhaps the ADC. If you do this you will be making a direct path to ground, burning power through the resistor chain. One approach would be to make a standard resistor divider circuit, but put a FET transistor in series with the resistors. This way you can turn the FET on to complete the resistor divider circuit when performing a measurement, and turn the FET off, breaking the chain at all other times, and thence preventing power wastage.

------

Another problem I perceive is the period of time that the circuit is required to run for, and the comparatively small amount of time it is required to be active. I am assuming that the transmission from the host is periodic and not continuous (if it is continuous, or frequent then please ignore this part).

There will be a problem in keeping the receiver syncronised with the transmitter. You say it wakes every 10 minutes for two seconds. All clocks drift, therefore you will need a method of correcting for the drift otherwise the receiver will wake up and hear nothing because it has just missed the host's transmission, or just prior to it.

One method to ensure syncronisation would be for the receiver to be in a continuous receiving mode until it hears the first transmission from the host (a maximum of 10 minutes, statistically 5 minutes). The host will broadcast it's time along with the other data required. The receiver will set it's clock and will sleep for slightly less than 10 minutes (we don't know at this stage how good our clock is), at which point it will awake once more for the reception of data (staying awake until we hear it). The host will transmit again including the time. The receiver will compare the host's time against its own local clock and calculate the drift over the last cycle. The drift calculation is used to determin the length of time to sleep for as perceived bny the receiver when compared to the host (ie the receiver may measure the distance between host transmissions as 9 minutes and 57 seconds as its oscillator is running too slow) The process repeats. Without this the receiver will loose syncronisation with the host, and if it awakes just after the host transmits, then it has no other choice than to stay awake until the next transmission inorder to re-syncronise which could be up to 10 minutes of wasted power.

The length of time for this problem to appear depends on how accurate the oscillators are in the host and receivers, it may be hours, or even weeks, but I would expect to see it within a month. Loss of sync could cost you a lot wasted power assuming that it happened only once per month. (ie listening for 10 minutes continuous (assuming the missed reception started just after host transmission) would use the same amount of energy as used in about 2 days of standard syncronised receptions of 2 seconds each)

Tim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

A previous suggestion was a resistor divider circuit to a comparator, or perhaps the ADC.

And I mentioned using a resistor divider and logic-level trip.

Quote:

If you do this you will be making a direct path to ground, burning power through the resistor chain.

>>If<< you make a permanent path to ground.

But if you take the tail of your chain into an A/D pin that floats for all but a few seconds out of 80000 (1 day) and using highish-ohm resistors for the few seconds of on-time each day, consumption is negligible.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you post a schematic Lee? I don't quite understand your last paragraph.

Looking at the Mega162 data sheet the IO pin leakage current is stated as 1uA max, where the sleep current is stated as 2uA max, therefore pin leakage is a large proportion of the power use.

Tim

PS: I was assuming that the battery voltage is higher than the supply to the measurement circuit, and it therefore requires reduction. (trying to keep it general)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

PS: I was assuming that the battery voltage is higher than the supply to the measurement circuit, and it therefore requires reduction. (trying to keep it general)

And I was assuming that battery voltage >>is<< Vcc--a no-regulator app for minimum power consumption.

battery V --> 10k -+-> 10k -+-> 10k --> PC2
                   |        |
                  PC0      PC1

PC0 and PC1 are high-z inputs.
PC2 is a high-z input when not testing. PC0, PC1, and PC2 are at Vcc and thus no "floating" current possibilities.

I have never considered pin leakage to be a problem. In many/most cases, the shelf life of the battery is exceeded before a sleep current of a few uA could draw it down.

When testing, make PC2 a low output. PC0 and PC1 will be either logic high or low. Yes, they could be at the high-draw floating point but you only need to do this once in a while and for a fairly short time.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Sorry,I have a different work to do and I couldn't join this discussion earlier.

Well, I think that Lee's divider will work only if uC has a regulated supply voltage lower than battery, because it's max and min levels depends on it's Vcc. So in battery powered device you don't have a reference you can compare to.
But he gave me idea.
If I connect 2.0V reference to uC pin i will have low level as long as uC's supply voltage is above 3V.
I supposed so....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So in battery powered device you don't have a reference you can compare to.

I see your point. I have to dig out that old app. IIRC we had external power with a regulator, and sleep operation off the battery, and did the measurements when on regulated power.

You can measure the battery directly on most models of newer AVRs:

-- Use AVcc as Vref
-- Do a conversion on the internal reference (often 1.1V bandgap nowadays)
-- Back-calculate Avcc == Vcc == Battery voltage.

That is a no-divider solution. Given the typical sharp bend in the knee of a dying battery and varaitions in battery type, piece-to-piece, and temperature it is usually not needed to get a precision answer. So the variation in the internal reference usually isn't important. For a more accurate system, do a one-time cal of the internal reference during programming/test and store the actual value of the bandgap for use in calculations.

If you use the divider solution with the logic levels, it is approximate anyway.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.