Hi Mark,

Mark Borgerson wrote:
>> For example, when I travel, I carry one or two portable GPS's
>> with me (a "large screen" unit that acts as an electronic map
>> and a smaller "pocket size" for walking/hiking).  It's fun
>> to turn them on *while* flying -- both to get an idea as to where
>> you currently are located (since you can rarely identify
>> landmarks from 35,000 feet!), how soon you will "arrive" as well
>> as the novelty factor:  "current speed 550 MPH"
>>
>> However, I have to balance my desire to "play" with them
>> (flights are boring; I only carry one book on the plane and
>> that will typically only occupy me for 3 hours before "FINI")
>> with my need for them to be operational when I touch down!
> 
> We have some of the same interests---although with slightly
> different goals.  On a recent cruise from Ketchikan AK to 
> Bellingham WA,  I often had 3 GPS units running:  a Garmin
> GPS76C,  an IPAD, and a custom-built logger that saved positions
> only once per minute.  (On an 8-knot trawler yacht, that's often
> enough for a good cruise track.)   The GPS76C would last about
> 10 hours on 2 AA alkaline cells.  The IPAD lasted more than
> 8 hours on a charge, while displaying the position on
> Navionics nautical charts.  The custom logger lasted about a
> week on 4 D Cells.   It is the last system that I need to
> optimize---but the 60mA as the GPS gets lock is a limiting
> factor.

My point is that you aren't given any/enough information
(by the device or its manufacturer) to intelligently
manage your usage of those devices.  *And*, if you really
*need* them (which is the case with many of the devices that
I "use" -- when not in use, they sit, ignored, in a desk
drawer), you don't want to take the *risk* of experimenting!

Sort of like wondering where "empty" ACTUALLY is on your car's
gas gauge... I'm too lazy to throw a gallon of gas in a can
in the trunk and "drive it dry" just to satisfy my curiosity  :>

>> What is the cost for me to use them in flight?  Does blanking
>> the screen save me anything?  How much?  Will I have enough
>> battery left when I land to reach my ultimate destination?
>> If I can see how my behavior drives that reserve time up or
>> down, then I can make a value judgement on the worth of
>> "playing" with them instead of reading *another* book, etc.
> 
> Get yourself one of the e-book readers that will download free
> books from your local library.  I got one of the Kobo readers
> for about $130.   It will last several weeks on a charge and
> hold enough books for many months of reading.

I have never been able to get accustomed to reading anything
"of length" in any form other than paper -- much to my
dismay.  :<  Nowadays with the 1,000 page datasheets for many
devices, this is *really* frustrating as I end up going through
a ream of paper *just* so I can take the sheets into another
room and *thumb* through them.

I have cognitive problems *listening* to read text so that
option is also "out".  Means I am pretty much stuck with paper
(which, I suspect, will be around at least as long as *I* am
likely to live!  :> )

Thankfully, my music listening hasn't clinged (clung?) to
*vinyl*!  :>

Besides, after three hours of reading, I want to do something
*else* -- not read Yet Another Book  :-/  (Next trip I'll
load some movies onto a PDA or PSP and keep that as a
distraction)

>>> After all, a user movement of less than one meter would make all
>>> alternatives viable. Of course, telling the worst case time could
>>> require using the full handset transmitter power, while the marketing
>>> department would expect you to tell the time available, when climbing
>>> the cellular tower :-).
>> <grin> Marketing would want to sell a small cable to let the user
>> connect directly to the tower!  :>
>>
>> I suspect using the phone as an MP3 player (with screen NOT
>> blanked) is a sizable fraction of "typical" power usage
>> "as a phone" (screen blanked).  Dunno.  I never use any of my
>> cell phones *as* phones!  :>
> 
> I exchange text messages with the kids and make about 2 calls a month.

I dislike the telephone, in general (i.e., don't even answer the
land line at home), prefering email, instead.  At one point, I
thought about this philosophically and came to the realization
that The Phone exists for the convenience of the *caller* (this
is incredibly obvious once you think about it) often at the
INconvenience of the "callee".  (i.e., just because *you* want
to talk to me *now* doesn't mean *I* want to talk to *you*
now!  ;-)

Email is far more egalitarian.  I write when *I* want to; you
reply when *you* want to!  (it also has the wonderful side-effect
of documenting conversations)

> I've got an SD card of music on the phone, but haven't yet gotten 
> headphones with the smaller jack.  Just sitting idle at home (1/4mi
> from a cell tower), the phone needs charging about once every 10 days.

I use mine primarily as a tiny WiFi "terminal".  Screen is a bit too
small to be useful -- I prefer a 4" screen for *real* utility -- but
the tradeoff of overall size is a win in many cases (I'm always afraid
of sitting on my PDA and cracking the screen whereas the phone fits
nicely in a *front* pocket).

I have an assortment of MP3/media players that I rotate through on
a regular basis depending on my needs, etc.  E.g., on daily walks,
I've taken to carrying a little Sony "Network Walkman" (no idea
where they came up with that name) as it is relatively small,
robust and easily operated "without eyes" (except, of course,
for the clock  :-/ ).  I recently inherited a Zune but can't see
a real use for something that holds more than one movie (as does
my 60G iPod-w-video).

All are more useful as examples of user interfaces -- what's good
vs. what's bad (hint:  iPod sucks!)

In article <i8gduh$mu0$1@speranza.aioe.org>, not.going.to.be@seen.com 
says...
> Hi Paul,
> 
> Paul Keinanen wrote:
> > On Tue, 05 Oct 2010 13:53:22 -0700, D Yuniskis
> > <not.going.to.be@seen.com> wrote:
> > 
> >> E.g., if your cell phone told you that "listening to music (MP3's)"
> >> is costing you W minutes of talk time per minute of music "consumed"
> >> or X minutes of standby time *and* you currently only have Y/Z minutes
> >> of talk/standby time ON RESERVE, then you could better manage your
> >> phone usage -- ESPECIALLY IF RECHARGING IS NOT PRESENTLY AN OPTION!
> > 
> > What figure are you going to report to the user in this example ?
> > The time remaining at minimum cellular transmitter power ?
> > The time remaining at maximum cellular transmitter power ?
> > The time remaining at most recent phone contact transmitter power ?
> 
> I don't think actual numbers are as important as something that
> gives the user a way to modify his behavior to *meaningfully*
> alter those results.  Even a range of figures is informative if
> the user can see how changes in his behavior affect them.
> 
> We, as users, *want* to use these devices.  More than we *need*
> to use them.  But, without meaningful feedback on the consequences
> of our usage patterns, we have no way of ensuring the device's
> availability when we *really* "need" it.
> 
> For example, when I travel, I carry one or two portable GPS's
> with me (a "large screen" unit that acts as an electronic map
> and a smaller "pocket size" for walking/hiking).  It's fun
> to turn them on *while* flying -- both to get an idea as to where
> you currently are located (since you can rarely identify
> landmarks from 35,000 feet!), how soon you will "arrive" as well
> as the novelty factor:  "current speed 550 MPH"
> 
> However, I have to balance my desire to "play" with them
> (flights are boring; I only carry one book on the plane and
> that will typically only occupy me for 3 hours before "FINI")
> with my need for them to be operational when I touch down!
> 

We have some of the same interests---although with slightly
different goals.  On a recent cruise from Ketchikan AK to 
Bellingham WA,  I often had 3 GPS units running:  a Garmin
GPS76C,  an IPAD, and a custom-built logger that saved positions
only once per minute.  (On an 8-knot trawler yacht, that's often
enough for a good cruise track.)   The GPS76C would last about
10 hours on 2 AA alkaline cells.  The IPAD lasted more than
8 hours on a charge, while displaying the position on
Navionics nautical charts.  The custom logger lasted about a
week on 4 D Cells.   It is the last system that I need to
optimize---but the 60mA as the GPS gets lock is a limiting
factor.
> What is the cost for me to use them in flight?  Does blanking
> the screen save me anything?  How much?  Will I have enough
> battery left when I land to reach my ultimate destination?
> If I can see how my behavior drives that reserve time up or
> down, then I can make a value judgement on the worth of
> "playing" with them instead of reading *another* book, etc.

Get yourself one of the e-book readers that will download free
books from your local library.  I got one of the Kobo readers
for about $130.   It will last several weeks on a charge and
hold enough books for many months of reading.
> 
> > After all, a user movement of less than one meter would make all
> > alternatives viable. Of course, telling the worst case time could
> > require using the full handset transmitter power, while the marketing
> > department would expect you to tell the time available, when climbing
> > the cellular tower :-).
> 
> <grin> Marketing would want to sell a small cable to let the user
> connect directly to the tower!  :>
> 
> I suspect using the phone as an MP3 player (with screen NOT
> blanked) is a sizable fraction of "typical" power usage
> "as a phone" (screen blanked).  Dunno.  I never use any of my
> cell phones *as* phones!  :>
> 

I exchange text messages with the kids and make about 2 calls a month.
I've got an SD card of music on the phone, but haven't yet gotten 
headphones with the smaller jack.  Just sitting idle at home (1/4mi
from a cell tower), the phone needs charging about once every 10 days.



Mark Borgerson

Hi Paul,

Paul Keinanen wrote:
> On Tue, 05 Oct 2010 13:53:22 -0700, D Yuniskis
> <not.going.to.be@seen.com> wrote:
> 
>> E.g., if your cell phone told you that "listening to music (MP3's)"
>> is costing you W minutes of talk time per minute of music "consumed"
>> or X minutes of standby time *and* you currently only have Y/Z minutes
>> of talk/standby time ON RESERVE, then you could better manage your
>> phone usage -- ESPECIALLY IF RECHARGING IS NOT PRESENTLY AN OPTION!
> 
> What figure are you going to report to the user in this example ?
> The time remaining at minimum cellular transmitter power ?
> The time remaining at maximum cellular transmitter power ?
> The time remaining at most recent phone contact transmitter power ?

I don't think actual numbers are as important as something that
gives the user a way to modify his behavior to *meaningfully*
alter those results.  Even a range of figures is informative if
the user can see how changes in his behavior affect them.

We, as users, *want* to use these devices.  More than we *need*
to use them.  But, without meaningful feedback on the consequences
of our usage patterns, we have no way of ensuring the device's
availability when we *really* "need" it.

For example, when I travel, I carry one or two portable GPS's
with me (a "large screen" unit that acts as an electronic map
and a smaller "pocket size" for walking/hiking).  It's fun
to turn them on *while* flying -- both to get an idea as to where
you currently are located (since you can rarely identify
landmarks from 35,000 feet!), how soon you will "arrive" as well
as the novelty factor:  "current speed 550 MPH"

However, I have to balance my desire to "play" with them
(flights are boring; I only carry one book on the plane and
that will typically only occupy me for 3 hours before "FINI")
with my need for them to be operational when I touch down!

What is the cost for me to use them in flight?  Does blanking
the screen save me anything?  How much?  Will I have enough
battery left when I land to reach my ultimate destination?
If I can see how my behavior drives that reserve time up or
down, then I can make a value judgement on the worth of
"playing" with them instead of reading *another* book, etc.

> After all, a user movement of less than one meter would make all
> alternatives viable. Of course, telling the worst case time could
> require using the full handset transmitter power, while the marketing
> department would expect you to tell the time available, when climbing
> the cellular tower :-).

<grin> Marketing would want to sell a small cable to let the user
connect directly to the tower!  :>

I suspect using the phone as an MP3 player (with screen NOT
blanked) is a sizable fraction of "typical" power usage
"as a phone" (screen blanked).  Dunno.  I never use any of my
cell phones *as* phones!  :>

On Tue, 05 Oct 2010 13:53:22 -0700, D Yuniskis
<not.going.to.be@seen.com> wrote:

>
>E.g., if your cell phone told you that "listening to music (MP3's)"
>is costing you W minutes of talk time per minute of music "consumed"
>or X minutes of standby time *and* you currently only have Y/Z minutes
>of talk/standby time ON RESERVE, then you could better manage your
>phone usage -- ESPECIALLY IF RECHARGING IS NOT PRESENTLY AN OPTION!

What figure are you going to report to the user in this example ?

The time remaining at minimum cellular transmitter power ?

The time remaining at maximum cellular transmitter power ?

The time remaining at most recent phone contact transmitter power ?

After all, a user movement of less than one meter would make all
alternatives viable. Of course, telling the worst case time could
require using the full handset transmitter power, while the marketing
department would expect you to tell the time available, when climbing
the cellular tower :-).
  

Hi Mark,

Mark Borgerson wrote:

[much elided]

>>> That's true.  I generally look at overall power consumption
>>> for a fairly fixed set of data logging tasks.  I go a bit
>>> finer grain when looking at the cost of individual tasks,
>>> such a writing a block to SD, but I'm mostly concerned about
>>> how many months an instrument will be able to log data with
>>> a particular set of lithium primary cells.
>> Yes.  Sorry, I should have elaborated on the different
>> nature of the application  :-/
>>
>> E.g., in your case, you're pretty much pared down to doing
>> the *least* that you can -- while still satisfying your
>> overall design goals.  So, there's nothing to "throw away"
>> when power gets in short supply.
>>
>> And, power reserves are a monotonically decreasing function;
>> you *know* you'll have less power available at EVERY time
>> in the future than you have now.
> 
> Well, that's ALMOST true.  However, the polarization effects
> on chemical batteries can result in short-term increases
> in cell resistance that disappear after a resting period.

Yes.  But that assumes you can "power off" and then power
back on.  I had assumed your devices got turned on, sealed
up, thrown overboard and then fished out sometime later
(possibly *after* the batteries had been exhausted).

In my case, the device can be powered off, recharged, etc.
so making decisions about "The Future" has one extra
unknown (i.e., when/if/how-much power will be reintroduced
to the battery)

> I've had that result in systems that reset when writing
> to SD, then re-awaken and run OK a while later.  That
> requires good brown-out detection and hysteresis in the
> reset generator.
>>> However, I suppose that a high-priority interrupt could
>>> measure power and assign the measured current to the
>>> task which it had preempted.
>> I'm not sure whether just taking a snapshot of the *current*
>> (taking your comment literally) would work.  I.e., that assumes
>> it has been constant over the past quantum.  I think you
>> have to integrate *power* consumed instead of just looking
>> at instantaneous current.
> 
> That's the reason that I usually have a pretty long time
> constant in the RC filter on the current sensor.

But, you don't "reset" that at the start of the next
integration period (?) -- presumably, you could "do the math"
to eliminate the need for this?

I was thinking more along the lines of integrating the
charge pulses coming out of the inverter(s) and using that
to reflect the near-instantaneous demands of the system
(assuming you chop at a frequency >> the jiffy)

>> Also, assuming that the power consumed "now" is chargeable
>> to the "recent task" can be misleading.  Especially in synchronous
>> environments.  E.g., task A starts some (hardware) process/device,
>> then blocks.  Power consumption changes *while* task B (which follows
>> task A) executes and B is charged with that -- even though the
>> power consumed was a result of A's actions!  I.e., if B is unlucky
>> enough to get stuck following A all/most of the time, then B is
>> wrongly accused of using more power than it actually *did*.
> 
> I guess you would have to not only capture which task is running,
> but the state of various peripherals. Then the monitoring task
> is starting to consume a significant percentage of the current
> in shorter tasks.

Yes.  Though you can decide that certain tasks can be efffectively
approximated by "Kt" (you can determine this a priori by looking at how
they behave "on the bench").

The big problem is the power hungry tasks -- those that intentionally
use peripherals that draw lots of power *or* those that, by their
nature, *need* lots of resources to achieve their goals.

E.g., to fall back on the cell phone analogy, I suspect you
could track power in the radio and backlight and get a good
first-order handle on overall consumption.  So, showing the
user the (relative?) costs of "talking" vs. "looking at
the screen" vs. "waiting for a call" shouldn't be difficult.

>> (the same problem happens in *time* when A sets up an ISR that
>> occurs *during* B's time slot -- B pays the price for A's actions
>> by losing the CPU cycles that A's ISR consumed)
>>
>>>> I'm wanting to look at the costs of particular activities and
>>>> adjust them dynamically to *manage* power in just the same
>>>> way you would manage "execution time", "memory", "temperature",
>>>> etc. in a device.
>>> OK.  That is a bit different.  I generally work with a fixed
>>> set of tasks that allows little flexibility.  About all I can
>>> decide is whether to use 1, 2 or 4KB of buffer before I write
>>> to SD.
>> Understood.  I'm trying to come up with metrics that can let
>> the "application set" tune itself to better use available power;
>> *and*, so that "it" can better inform the user of the costs of
>> particular user actions.
>>
>> E.g., if your cell phone told you that "listening to music (MP3's)"
>> is costing you W minutes of talk time per minute of music "consumed"
>> or X minutes of standby time *and* you currently only have Y/Z minutes
>> of talk/standby time ON RESERVE, then you could better manage your
>> phone usage -- ESPECIALLY IF RECHARGING IS NOT PRESENTLY AN OPTION!
>>
>> I haven't found anything that addresses this sort of issue to date.
>> Instead, any metrics tend to look at the *overall* power consumption
>> and, at best, say (in effect) "if you keep using the device in the
>> same way that you have *been* using the device recently, then the best
>> estimate is that you have X reserves available".  This is essentially
>> useless information as it doesn't let the user know how to *change*
>> his usage pattern to alter those reserves -- nor the *range* of
>> possible reserves that he might attain best'/worst case *if* he
>> altered his usage patterns! (e.g., if drastically altering usage
>> only results in a tiny incremental advance in reserves, then the
>> user might as well keep doing what he is doing!)
> 
> This is definitely a more complex problem than those I have
> faced.  Good Luck.

<grin>  I suspect this will become more commonplace as I can't
see battery technology progressing much faster than our demands
for features, etc.  Decades ago, 100% CMOS processors were
few and far between (1802, 8085 and perhaps 6502 variants?).
Then "sleep modes" on processors (often crudely timer driven
instead of any particular heuristics).  Sooner or later,
you will be able to query the core itself for an accounting of
its recent power requirements...

In article <i8g2tb$2or$1@speranza.aioe.org>, not.going.to.be@seen.com 
says...
> Hi Mark,
> 
> [much elided]
> 
> Mark Borgerson wrote:
> >>> In some applications, I've found it useful to use a high-side
> >>> current monitoring chip (MAX471 or equivalent).   I generally
> >>> filter the output with an RC filter and sample the current
> >>> as part of the internal timer tick chore.   The trick is to
> >>> balance the power drain from the monitoring and record-keeping
> >>> against the need for the data.
> >> But I suspect you are just trying to track your *total* power
> >> consumption -- not "charge" that to a particular "task"?
> >> I.e., you just want to know when you are headed for disaster
> >> and then, perhaps, implement some a priori scheme for conserving
> >> power (?).
> > 
> > That's true.  I generally look at overall power consumption
> > for a fairly fixed set of data logging tasks.  I go a bit
> > finer grain when looking at the cost of individual tasks,
> > such a writing a block to SD, but I'm mostly concerned about
> > how many months an instrument will be able to log data with
> > a particular set of lithium primary cells.
> 
> Yes.  Sorry, I should have elaborated on the different
> nature of the application  :-/
> 
> E.g., in your case, you're pretty much pared down to doing
> the *least* that you can -- while still satisfying your
> overall design goals.  So, there's nothing to "throw away"
> when power gets in short supply.
> 
> And, power reserves are a monotonically decreasing function;
> you *know* you'll have less power available at EVERY time
> in the future than you have now.

Well, that's ALMOST true.  However, the polarization effects
on chemical batteries can result in short-term increases
in cell resistance that disappear after a resting period.
I've had that result in systems that reset when writing
to SD, then re-awaken and run OK a while later.  That
requires good brown-out detection and hysteresis in the
reset generator.
> 
> > However, I suppose that a high-priority interrupt could
> > measure power and assign the measured current to the
> > task which it had preempted.
> 
> I'm not sure whether just taking a snapshot of the *current*
> (taking your comment literally) would work.  I.e., that assumes
> it has been constant over the past quantum.  I think you
> have to integrate *power* consumed instead of just looking
> at instantaneous current.

That's the reason that I usually have a pretty long time
constant in the RC filter on the current sensor.
> 
> Also, assuming that the power consumed "now" is chargeable
> to the "recent task" can be misleading.  Especially in synchronous
> environments.  E.g., task A starts some (hardware) process/device,
> then blocks.  Power consumption changes *while* task B (which follows
> task A) executes and B is charged with that -- even though the
> power consumed was a result of A's actions!  I.e., if B is unlucky
> enough to get stuck following A all/most of the time, then B is
> wrongly accused of using more power than it actually *did*.

I guess you would have to not only capture which task is running,
but the state of various peripherals. Then the monitoring task
is starting to consume a significant percentage of the current
in shorter tasks.
> 
> (the same problem happens in *time* when A sets up an ISR that
> occurs *during* B's time slot -- B pays the price for A's actions
> by losing the CPU cycles that A's ISR consumed)
> 
> >> I'm wanting to look at the costs of particular activities and
> >> adjust them dynamically to *manage* power in just the same
> >> way you would manage "execution time", "memory", "temperature",
> >> etc. in a device.
> > 
> > OK.  That is a bit different.  I generally work with a fixed
> > set of tasks that allows little flexibility.  About all I can
> > decide is whether to use 1, 2 or 4KB of buffer before I write
> > to SD.
> 
> Understood.  I'm trying to come up with metrics that can let
> the "application set" tune itself to better use available power;
> *and*, so that "it" can better inform the user of the costs of
> particular user actions.
> 
> E.g., if your cell phone told you that "listening to music (MP3's)"
> is costing you W minutes of talk time per minute of music "consumed"
> or X minutes of standby time *and* you currently only have Y/Z minutes
> of talk/standby time ON RESERVE, then you could better manage your
> phone usage -- ESPECIALLY IF RECHARGING IS NOT PRESENTLY AN OPTION!
> 
> I haven't found anything that addresses this sort of issue to date.
> Instead, any metrics tend to look at the *overall* power consumption
> and, at best, say (in effect) "if you keep using the device in the
> same way that you have *been* using the device recently, then the best
> estimate is that you have X reserves available".  This is essentially
> useless information as it doesn't let the user know how to *change*
> his usage pattern to alter those reserves -- nor the *range* of
> possible reserves that he might attain best'/worst case *if* he
> altered his usage patterns! (e.g., if drastically altering usage
> only results in a tiny incremental advance in reserves, then the
> user might as well keep doing what he is doing!)
> 

This is definitely a more complex problem than those I have
faced.  Good Luck.


Mark Borgerson

Hi Mark,

[much elided]

Mark Borgerson wrote:
>>> In some applications, I've found it useful to use a high-side
>>> current monitoring chip (MAX471 or equivalent).   I generally
>>> filter the output with an RC filter and sample the current
>>> as part of the internal timer tick chore.   The trick is to
>>> balance the power drain from the monitoring and record-keeping
>>> against the need for the data.
>> But I suspect you are just trying to track your *total* power
>> consumption -- not "charge" that to a particular "task"?
>> I.e., you just want to know when you are headed for disaster
>> and then, perhaps, implement some a priori scheme for conserving
>> power (?).
> 
> That's true.  I generally look at overall power consumption
> for a fairly fixed set of data logging tasks.  I go a bit
> finer grain when looking at the cost of individual tasks,
> such a writing a block to SD, but I'm mostly concerned about
> how many months an instrument will be able to log data with
> a particular set of lithium primary cells.

Yes.  Sorry, I should have elaborated on the different
nature of the application  :-/

E.g., in your case, you're pretty much pared down to doing
the *least* that you can -- while still satisfying your
overall design goals.  So, there's nothing to "throw away"
when power gets in short supply.

And, power reserves are a monotonically decreasing function;
you *know* you'll have less power available at EVERY time
in the future than you have now.

> However, I suppose that a high-priority interrupt could
> measure power and assign the measured current to the
> task which it had preempted.

I'm not sure whether just taking a snapshot of the *current*
(taking your comment literally) would work.  I.e., that assumes
it has been constant over the past quantum.  I think you
have to integrate *power* consumed instead of just looking
at instantaneous current.

Also, assuming that the power consumed "now" is chargeable
to the "recent task" can be misleading.  Especially in synchronous
environments.  E.g., task A starts some (hardware) process/device,
then blocks.  Power consumption changes *while* task B (which follows
task A) executes and B is charged with that -- even though the
power consumed was a result of A's actions!  I.e., if B is unlucky
enough to get stuck following A all/most of the time, then B is
wrongly accused of using more power than it actually *did*.

(the same problem happens in *time* when A sets up an ISR that
occurs *during* B's time slot -- B pays the price for A's actions
by losing the CPU cycles that A's ISR consumed)

>> I'm wanting to look at the costs of particular activities and
>> adjust them dynamically to *manage* power in just the same
>> way you would manage "execution time", "memory", "temperature",
>> etc. in a device.
> 
> OK.  That is a bit different.  I generally work with a fixed
> set of tasks that allows little flexibility.  About all I can
> decide is whether to use 1, 2 or 4KB of buffer before I write
> to SD.

Understood.  I'm trying to come up with metrics that can let
the "application set" tune itself to better use available power;
*and*, so that "it" can better inform the user of the costs of
particular user actions.

E.g., if your cell phone told you that "listening to music (MP3's)"
is costing you W minutes of talk time per minute of music "consumed"
or X minutes of standby time *and* you currently only have Y/Z minutes
of talk/standby time ON RESERVE, then you could better manage your
phone usage -- ESPECIALLY IF RECHARGING IS NOT PRESENTLY AN OPTION!

I haven't found anything that addresses this sort of issue to date.
Instead, any metrics tend to look at the *overall* power consumption
and, at best, say (in effect) "if you keep using the device in the
same way that you have *been* using the device recently, then the best
estimate is that you have X reserves available".  This is essentially
useless information as it doesn't let the user know how to *change*
his usage pattern to alter those reserves -- nor the *range* of
possible reserves that he might attain best'/worst case *if* he
altered his usage patterns! (e.g., if drastically altering usage
only results in a tiny incremental advance in reserves, then the
user might as well keep doing what he is doing!)

In article <i8fti3$n2c$1@speranza.aioe.org>, not.going.to.be@seen.com 
says...
> Hi Mark,
> 
> Mark Borgerson wrote:
> > In article <ivima6hisvh1i406uabuorc3625lkjg86c@4ax.com>, keinanen@sci.fi 
> > says...
> >> On Tue, 05 Oct 2010 07:51:04 -0700, D Yuniskis
> >> <not.going.to.be@seen.com> wrote:
> >>
> >>> I have an application that is extremely power conscious
> >>> (VERY long uptimes on battery, etc.).  It sees lots of extended
> >>> usage -- i.e., can benefit from "watching itself".  The RTOS
> >>> and API have special hooks to support power management very
> >>> elegantly in a fine-grained manner.  I.e., the application
> >>> has the tools it needs to optimize its power consumption
> >>> *if* it knows what that is!
> >>>
> >>> I'm looking for suggestions as to the least invasive means of
> >>> monitoring actual power consumption in an equally fine-grained
> >>> manner.
> >> Assuming the processor has a nearly zero power wait_for_interrupt
> >> instruction or state, just monitor, how long each routine is
> >> executing.
> >>
> >> A typical small RTOS will just scan the task list after a significant
> >> event (interrupt completed or task state change) to find the highest
> >> priority runnable task and execute it. If no runnable tasks have been
> >> detected, go to sleep to wait for the next interrupt.
> >>  
> >> Time stamping at the scheduler should give an estimate, how long a
> >> task is executing and how much power it is consumed.
> >
> > A very low-power processor may expend a significant part of
> > its power in peripheral operations.  That can be particularly
> > true with high speed clocks to things like SPI-connected
> 
> Exactly.  Or, what's the cost of "displaying" information
> (vs. the cost of *preserving* it?!)
> 
> You also have tasks that can quickly (in terms of CPU cycles)
> do things that result (eventually) in big power consumption.
> For example, turning on the "vibrator" (e.g., in a phone).
> This can probably be done in 10 CPU clock cycles -- yet burn
> enough power to run the entire processor for more time than the
> annunciator is active!
> 
> > peripherals.   Different tasks may have different power drain
> > in the same time interval.
> > 
> > In some applications, I've found it useful to use a high-side
> > current monitoring chip (MAX471 or equivalent).   I generally
> > filter the output with an RC filter and sample the current
> > as part of the internal timer tick chore.   The trick is to
> > balance the power drain from the monitoring and record-keeping
> > against the need for the data.
> 
> But I suspect you are just trying to track your *total* power
> consumption -- not "charge" that to a particular "task"?
> I.e., you just want to know when you are headed for disaster
> and then, perhaps, implement some a priori scheme for conserving
> power (?).

That's true.  I generally look at overall power consumption
for a fairly fixed set of data logging tasks.  I go a bit
finer grain when looking at the cost of individual tasks,
such a writing a block to SD, but I'm mostly concerned about
how many months an instrument will be able to log data with
a particular set of lithium primary cells.

However, I suppose that a high-priority interrupt could
measure power and assign the measured current to the
task which it had preempted.
> 
> I'm wanting to look at the costs of particular activities and
> adjust them dynamically to *manage* power in just the same
> way you would manage "execution time", "memory", "temperature",
> etc. in a device.
> 

OK.  That is a bit different.  I generally work with a fixed
set of tasks that allows little flexibility.  About all I can
decide is whether to use 1, 2 or 4KB of buffer before I write
to SD.

Mark

Hi Mark,

Mark Borgerson wrote:
> In article <ivima6hisvh1i406uabuorc3625lkjg86c@4ax.com>, keinanen@sci.fi 
> says...
>> On Tue, 05 Oct 2010 07:51:04 -0700, D Yuniskis
>> <not.going.to.be@seen.com> wrote:
>>
>>> I have an application that is extremely power conscious
>>> (VERY long uptimes on battery, etc.).  It sees lots of extended
>>> usage -- i.e., can benefit from "watching itself".  The RTOS
>>> and API have special hooks to support power management very
>>> elegantly in a fine-grained manner.  I.e., the application
>>> has the tools it needs to optimize its power consumption
>>> *if* it knows what that is!
>>>
>>> I'm looking for suggestions as to the least invasive means of
>>> monitoring actual power consumption in an equally fine-grained
>>> manner.
>> Assuming the processor has a nearly zero power wait_for_interrupt
>> instruction or state, just monitor, how long each routine is
>> executing.
>>
>> A typical small RTOS will just scan the task list after a significant
>> event (interrupt completed or task state change) to find the highest
>> priority runnable task and execute it. If no runnable tasks have been
>> detected, go to sleep to wait for the next interrupt.
>>  
>> Time stamping at the scheduler should give an estimate, how long a
>> task is executing and how much power it is consumed.
>
> A very low-power processor may expend a significant part of
> its power in peripheral operations.  That can be particularly
> true with high speed clocks to things like SPI-connected

Exactly.  Or, what's the cost of "displaying" information
(vs. the cost of *preserving* it?!)

You also have tasks that can quickly (in terms of CPU cycles)
do things that result (eventually) in big power consumption.
For example, turning on the "vibrator" (e.g., in a phone).
This can probably be done in 10 CPU clock cycles -- yet burn
enough power to run the entire processor for more time than the
annunciator is active!

> peripherals.   Different tasks may have different power drain
> in the same time interval.
> 
> In some applications, I've found it useful to use a high-side
> current monitoring chip (MAX471 or equivalent).   I generally
> filter the output with an RC filter and sample the current
> as part of the internal timer tick chore.   The trick is to
> balance the power drain from the monitoring and record-keeping
> against the need for the data.

But I suspect you are just trying to track your *total* power
consumption -- not "charge" that to a particular "task"?
I.e., you just want to know when you are headed for disaster
and then, perhaps, implement some a priori scheme for conserving
power (?).

I'm wanting to look at the costs of particular activities and
adjust them dynamically to *manage* power in just the same
way you would manage "execution time", "memory", "temperature",
etc. in a device.

Hi Paul,

Paul Keinanen wrote:
> On Tue, 05 Oct 2010 07:51:04 -0700, D Yuniskis
> 
>> I have an application that is extremely power conscious
>> (VERY long uptimes on battery, etc.).  It sees lots of extended
>> usage -- i.e., can benefit from "watching itself".  The RTOS
>> and API have special hooks to support power management very
>> elegantly in a fine-grained manner.  I.e., the application
>> has the tools it needs to optimize its power consumption
>> *if* it knows what that is!
>>
>> I'm looking for suggestions as to the least invasive means of
>> monitoring actual power consumption in an equally fine-grained
>> manner.
> 
> Assuming the processor has a nearly zero power wait_for_interrupt
> instruction or state, just monitor, how long each routine is
> executing.

That doesn't address the power used in I/O devices, etc.
It also doesn't work well in an environment where every/most
task is using it's entire timeslot (i.e., this *looks* like
each task is using an "equal amount" of time/"power").
Finally, it doesn't address the "work" done by each task
and the "cost" of that "work" (e.g., a task that is running
lots of back-to-back multiply-and-accumulates is undoubtedly
putting a bigger strain on resources than one that is twiddling
bits in a register).

> A typical small RTOS will just scan the task list after a significant
> event (interrupt completed or task state change) to find the highest
> priority runnable task and execute it. If no runnable tasks have been
> detected, go to sleep to wait for the next interrupt.

That's not a problem -- assuming you ignore the cost of I/O's
that happen to be running "in the absence" of executing code
(and the cost of their IRQs).

> Time stamping at the scheduler should give an estimate, how long a
> task is executing and how much power it is consumed.

I think that would only work for trivial tasks that use "comparable"
resources.  E.g., a task/process that has wired down 100M of
address space is probably costing you more than one that executes
in 3KB  :-/

Part of the effort is to determine when it makes sense to scale
back algorithms that burn power to gain speed in favor of other
approaches that sacrifice speed to conserve power.  Without those
metrics, you can't even tell the *user* what his choices *might* be!