[Tinyos-devel] more bugging about current consumption on Mica Z
in tinyos-2.x
Murray, Ben
Ben.Murray at thalesgroup.com
Wed Aug 1 03:00:04 PDT 2007
Current spikes:
sounds feasible as I'd have thought the Mcu would have to partially wake,
check the taskloop and then go back to sleep? I seem to recall reading
somewhere that McuSleep.sleep() only puts the Mcu into a sleep mode for a
short while (something like tens of ms?) I'll try grab a scope at some point
to see if it's these spikes causing at least some of the current rise I'm
witnessing.
As an aside - is there a way I can control how long the MCU sleeps for
having received the McuSleep commad?
---------------
Brown out fuse:
Thanks for the suggestion wrt fuses. I tried setting the "Fuse Low Byte"
(took me a while to find out how all that worked!) to E4 (brown out off), A4
(Brown out enabled with one level), and 24 (BOD enabled at some other
level).
With the BOD disabled I get the same results as originally posted (hundreds
of uA at 3.0V, hundreds or tens of uA in the 2.5-2.8V region, <10uA at about
2.3-2.4V, and hundreds again at 2.1-2.2V) With BOD fully enabled
(wr_fuse_l=24) the current stuck at around 8-9mA (note: mA, not uA) and with
it part-enabled (wr_fuse_l=A4) the same pattern as the original was observed
between 2.7-3.0V but at anything less than 2.7V the current jumps up to the
several-mA region.
So yes the BOD does cause a higher current draw but in the order of several
mA, not the few-hundren uA rise I'm seeing. Thanks for pointing it out
though as I now know what the fuse settings mean!
---------------
I've also just installed the newer tos 2.0.2 (and the new tools rpm) - same
results as before.
also... I'm not entirely certain what the other clock source options
actually do yet from within wr_fuse_l ...could that be my problem? x?4 means
internal oscillator I believe. I'll post the make output below:
mkdir -p build/micaz
compiling NullAppC to a micaz binary
ncc -o build/micaz/main.exe -Os -finline-limit=100000 -Wall -Wshadow
-Wnesc-all
-target=micaz -fnesc-cfile=build/micaz/app.c -board=micasb
-DIDENT_PROGRAM_NAME=
\"NullAppC\" -DIDENT<<CUT>> -fnesc-dump=wiring
-fnesc-dump='interfaces(!abstract())' -fnesc-dump='reference
d(interfacedefs, components)' -fnesc-dumpfile=build/micaz/wiring-check.xml
NullA
ppC.nc -lm
compiled NullAppC to build/micaz/main.exe
680 bytes in ROM
4 bytes in RAM
avr-objcopy --output-target=srec build/micaz/main.exe build/micaz/main.srec
avr-objcopy --output-target=ihex build/micaz/main.exe build/micaz/main.ihex
writing TOS image
cp build/micaz/main.srec build/micaz/main.srec.out
installing micaz binary using mib510
uisp -dprog=mib510 -dserial=/dev/ttyS0 --wr_fuse_h=0xd9 -dpart=ATmega128
--wr_fu
se_e=ff --erase --upload if=build/micaz/main.srec.out
Firmware Version: 2.1
Atmel AVR ATmega128 is found.
Uploading: flash
Fuse High Byte set to 0xd9
Fuse Extended Byte set to 0xff
rm -f build/micaz/main.exe.out build/micaz/main.srec.out
-------------------------------------------------
Cheers
-Ben
> Hi,
>
> I'm not sure about it, but I think if the input
> voltage is too low, the brown detector may active
> and draw more current.
>
> Check your brown detector fuse.
>
> Also, lately, I've also check the Null current
> consumption profile using oscilloscope. I think
> there's a spike every 10ms (around 1 mA peak).
> I dont know why (since the Null hasn't put
> anything on the task). But I think the decay time
> also contribute to the whole sleeping current.
>
>
> Regards,
>
> -daniel
>
> -------- Original Message --------
> > From: Philip Levis <pal at cs.stanford.edu>
> > Sent: Wednesday, August 01, 2007 12:51 AM
> > To: "Murray, Ben" <Ben.Murray at thalesgroup.com>
> > Subject: Re: [Tinyos-devel] more bugging about current
> consumption on Mica Z in tinyos-2.x
> >
> > On Jul 31, 2007, at 6:36 AM, Murray, Ben wrote:
> >
> > > Hi
> > > sorry to drag up an old thread but I'm getting some
> rather strange
> > > results
> > > wrt micaz current draw vs input voltage for the null application
> > > compiled in
> > > TinyOS-2.x (I have tried the srec posted by Phil and get
> the same
> > > results).
> > > Using a bench PSU (100mA limit) and a Fluke 75 multimeter
> so should be
> > > resonably accurate down to ~10uA steps. Accurate enough to spot
> > > some trends
> > > anyway...
> > >
> > > The current drawn by a mote running the null application
> seems to
> > > depend on
> > > its input voltage and in more than just a I=V/R way. Results are
> > > given below
> > > for 3 motes (M1 and M2 bought in 2004, M3 bought in
> 2007). Currents
> > > are
> > > shown in uA and values of 5 are shown when the value was
> recorded
> > > as "less
> > > than 10uA". Values ending in a 5 record when the
> multimeter noticeably
> > > flipped between two readings. These are the stable idle
> currents,
> > > typically
> > > reached after a couple of seconds, occasionally taking longer to
> > > settle.
> > >
> > > VCC M1 M2 M3
> > > ------------------
> > > 2.1 430 430 440
> > > 2.2 520 5 5
> > > 2.3 10 5 5
> > > 2.4 15 5 20
> > > 2.5 40 5 40
> > > 2.6 125 15 50
> > > 2.7 600 30 60
> > > 2.8 350 90 60
> > > 2.9 380 140 70
> > > 3.0 500 200 100
> > >
> > > I have only been messing around with the motes and TinyOS for a
> > > short while
> > > so am certainly not adept with programming them yet - is
> there an
> > > easy way
> > > to tell the mode what power state to go into as all I seem to be
> > > able to
> > > find is McuSleep.sleep() which will set it to what the
> mote thinks
> > > is the
> > > correct sleep level. I'm having trouble locating in which
> component
> > > the
> > > McuPowerOverride interface is used?
> >
> > I believe that the only component which implements
> McuPowerOverride
> > is the atmega128 timer stack. It uses the interface to make
> sure the
> > MCU does not drop into a sleep state with a long wakeup if
> there is a
> > timer that needs to fire very soon.
> >
> > When I've measured sleep current, I've always used 3.0V as
> an input,
> > and I've seen sleep currents down at the 4uA level. I'll
> check that
> > this is still the case tomorrow (I'm not in the lab today).
> >
> > Phil
*******************************************************************************
Please consider the environment before printing this email.
*******************************************************************************
This email and any files transmitted with it are intended solely for the use of
the individual or entity to whom they are addressed and may not be divulged to
any third party without the express permission of the originator. Any views
expressed in this message are those of the individual sender, except where the
sender specifically states them to be the views of Thales Research & Technology
(UK) Limited.
*******************************************************************************
More information about the Tinyos-devel
mailing list