Power envelope (was Re: radio off guarantee?)

[Mike C. Fletcher]

John Watlington wrote:
>>> Suppose I'm someplace where I don't expect or want to do any mesh
>>> networking.
>>> How much would turning off the radio help battery life?
>>>       
>> Last I checked, the effect was very small.  There will be occasional
>> scans as the unit hunts around for nearby radios.  One could save more
>> by making those scans back off rather than provide a UI element.
>>     
>
> We see 700 to 800 mW consumed by the mesh interface, and as with most
> WiFi interfaces, receiving consumes as much power as transmitting.
>   
Isn't that about 1/2 of our total power budget?  .7 to .8 W on a < 2W 
machine?  I'd thought the Marvell chip was supposed to be down in the 
.3W range.  Obviously haven't been following the hardware closely 
enough.  (http://wiki.laptop.org/go/Power_Management is where I got the 
.3W idea).  Is that .7W something we'll be able to bring down with 
software to reduce collisions or the like?  University of Toronto's 
system's group has algorithms that optimise for power savings by 
reducing collisions, if that would help.

 From the same page, we'd only last 20 hours at ~.7W draw with a *full* 
charge (and with hand-charging a full charge likely won't be there, 
especially at the end of the day), which means that the machines are 
going to be dead each morning (having drained their batteries keeping up 
an unused network all night).  With a 40 hour period (.3W) we were 
possibly going to have some juice left in the morning (need to be at > 
1/4 power when you shut off for the night), but that becomes less likely 
with a 20 hour period (need to be at >1/2 power when you shut off for 
the night).
> While it makes sense to turn off the wireless networking interface on  
> developer
> machines, we are hesitant to add this to the UI.  We are really  
> relying on laptops
> to extend the mesh away from the school.
>   
If we really are spending half our power budget on the mesh network I 
would imagine that kids will want to be able to turn it off.  Yes, 
meshing is good, but if you could double your battery life while you're 
at home reading, that would be very worthwhile too.  What about *only* 
keeping the mesh up (continuously) if you are actually routing packets?

That is, wake up the mesh interface every few minutes, check to see if 
your new routing structure makes you a link that is desirable, and only 
stay on if that's the case.  (I realise I'm talking about long-term 
projects here).  You'd need the machines to be able to queue up messages 
to go out so that they could leap at the request and say "yes, please 
stay up" when a linking machine pops on to check for need (implying from 
activity requests on the local machine would be likely be sufficient, 
but a simple UI might be workable too).  If the network is inactive for 
X period, go into periodic sleep mode again to save energy.

Even if you had to wake up the processor for a few seconds to run the 
code that decides whether to sleep, it's only about double the power of 
running the mesh for those seconds, and it could save you the entire 
power budget for a few minutes.  Of course, in the field it may be that 
the mesh is so densely used that it's never going to go down with that 
algorithm, but it seems like something we need to investigate if we 
really are losing that much power to the interface.

Just a thought,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com