If you have an accurate ammeter, placing it directly in series with your battery should work without soldering and give you a good estimate of what the power consumption is.
Our 50kSps DAQ only measures voltages. To easily solve the solder-the-resistor-in-series problem, take a small piece of 2-sided copper plated PCB (plated on both sides, no connection through the FR-4 center) that is shaped like a very short popsicle stick. Solder a 1-ohm (or less) precision resistor across the two sides of the board. Then, insert this PCB stick between the battery and the terminal on your mote, placing the resistor on the end of your PCB stick in series with your battery power supply. This way, you don't have to go around soldering motes. Also, you can twist method this to help in the ammeter case by leaving the resistor off and touching your ammeter probes to both sides of the PCB stick placed between one end of a battery and the terminal. Finally, I definitely saw just below 1 mA on the mica2's, and according to what I wrote down, saw 0.102 mA during downtime on the micaz's. The mica2's use a CC1000 radio, which has a crystal that should keep oscillating even when the radio is turned off (confirmation?). It takes awhile (milliseconds) to start that oscillation back up after it's turned off, hence the reason to keep it on. But that shouldn't stop you from turning it off in something like CC1000ControlM.nc. When the CC1000 oscillator core is off, the CC1000 should consume between 0.2 - 1.0 uA. With the crystal oscillator on, 105 uA. With the xosc and bias on, 860 uA. I think there's a synthesizer that can be turned on on top of that too, to enable Rx and Tx. But that 860 uA is probably why the mote consumes just less than 1 mA during power down: 860 uA + 0.102 mA = 0.962 mA. Sounds reasonable to me. -David -----Original Message----- From: Michael Schippling [mailto:[EMAIL PROTECTED] Sent: Friday, April 28, 2006 1:18 PM To: Harri Siirtola Cc: Gregory A. Moore; David Moss; tinyos-help@Millennium.Berkeley.EDU Subject: Re: [Tinyos-help] Mica2, CPU Timed Sleep and Wakeup WOW!!! I think we have a winner for the first entry in the TOS-wiki! MS However...I'm not sure I understand the difference between soldering a 1ohm resistor in the +supply line, and cutting it to insert an ammeter. From the highly technical side of having to touch hardware anyway... Harri Siirtola wrote: > > I'll try to shed some light to most questions in this thread. > > 1. You don't have to call Powermanagement explicitly it you build the > app with > > $ make micaz MESH=LPZ > > or > > $ make mica2 MESH=LP > > or in the latest make system (make-3.80tinyos-1) > > $ make micaz route,lp > > THEN power saving is automatic when all requirements are met. This > feature isn't documented very well. > > The mote can (and must, for that matter) be woken up by a timer. That's > what you see in the examples I gave. RAM data is safe during sleep, > there's still power for the processor (how could it otherwise run any > timers?). Of course, an external interrupt could also wake up the > processor (even from a deeper sleep mode). There just aren't any > hardware implementations for this in any of the sensor boards. Or at > least in the ones I've used (MTS310, MDA300). > > Sorry for the obscure definition "current tree", I mean one or two > latest TinyOS trees. Can't remember the versions, but you can check if > you have a recent enough version by trying out the commans above. Then > see if there's a -DUSE_LOW_POWER compiler directive or similar in the > make output. > > The best way to confirm power saving is to solder a 1ohm resistor > between the positive battery terminal and the circuit board. Then > measure the voltage over that resistor. 1 mV corresponds to 1 mA. That > way you can use the mote when not measuring, as opposed to the suggested > amp meter approach where you have to cut the positive wire. Also, you > can attach a scope to the resistor to see the short current spikes when > radio communication takes place. Some volt meters may not react fast > enough for you to see there's any change in the consumption. > > Hope this clear some things out, feel free to ask more if I forgot > somethinf important. Regards, > > Harri > > At 02:04 PM 4/27/2006 -0700, Gregory A. Moore wrote: >> 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
