David,

I wrote the application you are talking about where I enable PowerManagement in the StdControl.start command. Then whenever I want to save power I just turn off the radio or, RadioControl.stop(). The lowest current I can acheive is slightly less than 1mA. This is better than before, but not as low as I would like.

I have a few questions for you:
1. This current draw seems like there is an internal oscillator running, could this be because I have a timer running even while the motes power is being adjusted? 2. If I were to manually place the mote to sleep in a Power save or standby mode, would I have to store my ram contents in the external flash to recall the values, or is the ram safe after the mote starts back up? 3. What is the process you used to get the mote to a sleep state using HPLPowerManagementM where it is only drawing ~.1mA? Do you have a timer still running and can you wake the mote up from that stata?

Thank you so much for your help already, I appreciate it.

Greg

 Moss <[EMAIL PROTECTED]> wrote:

I'm using 1.1.15, and have found similar to previous versions that your app
for mica(2|2dot|z) must wire in HPLPowerManagementM and then call
HPLPowerManagement.enable() at start before anything useful happens.

Without doing this, the mote consumes somewhere around 2-3 mA while the
radio is disabled.  With HPLPowerManagement.enable()'d at startup, the mote
consumes approximately 0.102 mA when the radio is disabled and everything is
quiet.

For reference, using a 0.106% duty cycling CC2420 radio on a micaz, the mote
will last about 16 days on 1500 mAh batteries with no power management.
When you add in that power management, you get about 266 days on the same
1500 mAh batteries.

That's a big difference.  I think HPLPowerManagement should be enabled by
default when compiling for the mica2/z's

-david




-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael
Schippling
Sent: Thursday, April 27, 2006 12:20 PM
To: Harri Siirtola
Cc: tinyos-help@Millennium.Berkeley.EDU
Subject: Re: [Tinyos-help] Mica2, CPU Timed Sleep and Wakeup


wow...coulda fooled me about the automatic part...kewel.
Will have to try it sometime.
Which is the "current tree" however?
MS

Harri Siirtola wrote:

First, as far as I know, the Snooze component is deprecated. There are
many improvements in the newer TInyOS versions that make things much
more simple. For example, the CountSleepRadio app (previously in
"contrib/ucb", now in the "apps" dir IIRC) is good for just testing that
power saving works. It just sends an incremented integer over the air
and goes to sleep. When a timer expires, the mote wakes up and sends the
next one. There's another example, "apps/examples/TestSleep" which
toggles a led between sleeping periods.

Second, in the current tree, power saving is transparent to the user.
When there are no interrupts (nor tasks, IIRC) pending, and only Timer 0
running, power saving kicks in. You can test it with the latest
measuring apps, just study the "make/avr/route.extra" to see which
commad line switches you must use to enable power saving. The
"PowerManagement.AdjustPower()" call is deeper down the radio stack and
is automatic once you compile the app correctly.

Regards,

        Harri

At 01:18 PM 4/26/2006 -0600, Michael Schippling wrote:
Sorry, I'm at a loss. I thought that one of the features of the motes
was the ability to sleep between samples to save power, but I never
paid attention to how/where/why this might work. I actually have it
on my list of things to do for a project that I never work on anymore...

Assuming as usual that no one who actually knows how to do this will
answer your question...Perhaps there is something in the atmega spec
book about it?

MS

Gregory A. Moore wrote:
Michael,
Thank you for your response, but:
SnoozeC only works for Mica motes, not Mica2.  They have a slightly
different processor so I am sure there are some dependency issues
that don't quite fit.
I have also looked at the OnOffApp which is supposed to essentially
be the Snooze for the mica2, but it relies on a radio packet to start
the mote again.
If you have any other suggestions I am greatly appreciative.
Thanks,
Greg

There is a module tos\platform\mica\SnoozeC.nc that purports to
do the shutdown and timer wakeup. And a TestSnooze demo app.
I haven't tried them, YMMV...
MS


Gregory A. Moore wrote:
Hi All,

I have perused the archives about this pesky timed mica2 sleep
problem and have not found
any code snippets or anything of huge benifit.

So I repeat the question:
I am working with Mica2.
I would like to put the mote's CPU to sleep for a set period of
time and then have it
awoken by some timer, not an incomming radio packet.

I have done the power measurements with the use of
HPPowerManagementM and I have not
gotten any successful current readings that show me that the
module  is doing anything in
the way of sleeping.

The code from Berkely's study for P-TOSSIM shows us how to set the
mote's CPU to sleep,
but it does not show us how to wake it up with a timer.

I write nesC well, but I am not an experienced embedded programmer
so I am not quite sure
how to program the awake tasks from the schematics.

I hope there is someone out there who can help me with my woes.

The code snippet I am using to put the mote to sleep is at the end
of this email.

Thank you in advance,

Greg


Successful code. thanks to Berkely folks, to put the mote to sleep:

task void gotoSleep() {
 cli();
 //fires the interupt pin to signal data recording
 //This is PIN5 on the connector, use probe to read signal
 TOSH_SET_INT1_PIN();
 TOSH_CLR_INT1_PIN();

 // set the PA_POW to 00h to ensure lowest possible leakage current
 call CC1000Control.SetRFPower(0x00);

 // power down the radio
 call CC1000StdControl.stop();
 //call CC1000RadioIntM.StdControl.stop();
 //call HPLPowerManagement.adjustPower()


 ///Code taken from Snooze.nc,  this is current code used to
 //put the Mica2 into different low power states
 // save port state
 port[0] = inp(PORTA); nops(8);
 port[1] = inp(PORTB); nops(8);
 port[2] = inp(PORTC); nops(8);
 port[3] = inp(PORTD); nops(8);
 port[4] = inp(PORTE); nops(8);
 port[5] = inp(DDRA);  nops(8);
 port[6] = inp(DDRB);  nops(8);
 port[7] = inp(DDRD);  nops(8);
 port[8] = inp(DDRE);  nops(8);
 port[9] = inp(TCCR0); nops(8);
 // Disable TC0 interrupt and set timer/counter0
 //to be asynchronous from the CPU
 // clock with a second external clock (32,768kHz) driving it.
 //Prescale to 32 Hz.
 cbi(TIMSK, OCIE0);  nops(8);

 // set minimum power state
 // NOTE: this enables pull-ups;
 //       -may be sensor board dependant
 //       - (ex: Port C should be lo during sleep, not hi?)

 outp(0x00, DDRA);        // input
 outp(0x01, DDRB);        // input

 // changed 00 to ff because the impedance was high in the sleep
 // state, drawing 8mA for 5 sec before sleeping. Now it immediately
 // snoozes.
 outp(0xff, DDRC);        // input
 outp(0x00, DDRD);        // input
 outp(0x00, DDRE);        // input

 outp(0xff, PORTA);        // enable pull-ups
 outp(0xfe, PORTB);  // enable pull-ups except for PB0

 // changed the value of PORTC from ff to 0 because ff
 // sounds the alarm when the mote goes to sleep.
 outp(0x00, PORTC);        // enable pull-ups
 outp(0xff, PORTD);        // enable pull-ups

 cbi(ADCSRA, ADEN);     //  disable adc
 sbi(ACSR,ACD);         //  disable analog comparator

 //goes into sleep modes
 if (sm2 == 1){
       sbi(MCUCR, SM2); nops(8);
 }
 if (sm1 == 1){
       sbi(MCUCR, SM1); nops(8);
 }
 if (sm0 == 1){
       sbi(MCUCR, SM0); nops(8);
 }

 //enable sleep, clocks stop
 sbi(MCUCR, SE);  nops(8);

 //enable interupts (after wakingup - if you do)
 sei(); nops(8);
 //fires the red LED, and the pin
 TOSH_SET_INT1_PIN();
 call Leds.redOn();
}





_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU

https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


--Gregory Moore
[EMAIL PROTECTED]
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help


_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help




--
Gregory Moore
[EMAIL PROTECTED]


_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to