Estimated Power Profile Visualization Tool

Is there a tool for plotting expected power consumption over time for a simple embedded system? Basically, a program (or more likely a script or a spreadsheet) that creates a plot a la JouleScope/Otii/PPK/Angler/etc., but instead of measuring to get that plot, create that plot from a table of functionality name, active current consumption, idle/sleep consumption, duration, duty cycle, etc.

Every time I make a plot like this I think, “Someone must have already done this - and they very likely did it better than me.” Nice features: names show up as annotations on a line graph, there’s a pie or bar chart with all the items represented, config file for settings, …

I think I’ve got a spreadsheet like that stuck way back in my google docs - let me see if I can dig it out and forward it to you.

I’ve always wanted to build this as a web tool as well but never did… as far as I know, I don’t know anything that exists.

I am not aware of a tool that does this in the time domain. I certainly understand the value of a spreadsheet that models the power consumption in the different modes. A pie chart is great for visualizing where your energy goes. I have used spreadsheets similar to this:


https://download.joulescope.com/conferences/2020/eoc2020/eoc2020_liberty_power.xlsx

I know that Jacob Beningo has something similar:
https://www.beningo.com/7-tricks-for-estimating-battery-life/

I suppose having a time-domain plot could help you for when you measure real hardware with your Joulescope. [disclaimer: I am the creator of Joulescope].

For what you have in mind, do you always have scheduled events at predetermined times/intervals? For asynchronous or external event-driven states, how would you want to specify the timings?

1 Like

It’s a good thing to also have a peak value, so the power supply can be designed for max load

That looks like a handy analysis Matt. I’ve always wondered about time domain features and also factoring in things like the load dependent efficiency of a power converter, ESR of a battery, Discharge curves for a particular battery chemistry, Blocking diode losses.

All of these things become relevant when trying to simulate/ estimate battery life.

1 Like

Sometimes you can find this functionality in vendor tools. Here’s one provided by Nordic. It’s good for stuff like Bluetooth where your power varies so much depending on the use case. Sometimes I feel like it’s a fine line between taking the time to estimate vs. just building it and profiling it yourself to tweak later though.

https://devzone.nordicsemi.com/nordic/power/w/opp

1 Like

These are all good suggestions, thank you!

Here’s one (not very flexible) spreadsheet format I’ve done:

Remember TimingDesigner? Back in the day it cost 5 digits and was node-locked with a parallel port key. The user inserts dynamic timing parameters (rise time, hold time, etc.) for a bunch of ICs, then creates timing diagrams for each type of bus transaction. That kind of tool would be very helpful for me to explain to people what a coulomb’s really worth.

1 Like

I might be interested in developing something like this, assuming that you and/or anyone else who’s interested would be prepared to help with setting requirements and providing critique and advice once I get something going.

(I’m mostly a software engineer trying to learn more electronics, so I’m always looking for “electronics adjacent” software projects.)

1 Like

I was chatting with @ian offline but will add the gist of my comments here. The way that I look at it, there are 4 categories to think about

  1. Power sources (Batteries of different chemistry)
  2. Power Conversion (Bucks, Boosts, etc
    ** Each has different efficiency curves, Iq, etc
  3. Load events (could be time dependent)
  4. States - Determines what loads are active when, what power converters are active, what power sources are present, etc

In theory if each of these is described, they you can run a simulation to balance out the power consumed and generate the analysis.

1 Like

Make sure your battery capacity conforms to your cutoff voltage. Battery manufacturers typically use a low voltage, and mAh capacity to your cutoff may be a lot lower than the data sheet nominal. Also, if designing for something that’s to run for years, you should derate for self-discharge as well.

Great point! That particular design from 2016 had a GSM module directly driven from the LiPo cells, so the MCU will not turn on the GSM module when the batteries are less than about 3.3V.

That would be a great project, and I bet something simple could be put together quickly. There’s lots of potential for yak-shaving: parse source files for, say, FreeRTOS tasks and have the user add timing or power details; parse schematics files or BOMs for parts, and have the user add details…

And of course the batteries’ internal resistance, which increases with discharge, comes into play, too. If you’ve got a load, like an RF module that pulls 140mA when transmitting, your effective cutoff voltage to avoid brownouts/resets may be even higher. Unfortunately battery manufacturers’ specs for these characteristics under very low long-term loads are pretty nonexistent/useless.

I usually put a model inside Pspice. Then I can simulate with slew rates, actual converter average models, actual circuits. And a nice plot program with all the features you need like averaging, power dissipation, peak currents etc

Something scriptable like pspice would be great. Someone always asks, “Hey, what if we put more lights on that board?” Then I could add that line item, rerun the script and say, “Here’s exactly how many operating days you lose with that method.”

The calculated line graphs are meant to easily compare with the measurement devices’ waveforms.

What do you mean by scripting in PSpice? (I usually just draw the schematics, using parametric symbol to feed into the models for easy modification)

Maybe I misunderstood what you’re saying. I’m looking for a plot of expected current draw over time for a small PCB that has, say, an MCU, a couple of sensors, maybe a battery charger, maybe some LEDs - maybe a neo-m8. The graph would be like JouleScope’s output, but would be annotated, somehow (segmented background color?). Integration maps to power usage. Then, when someone says, “How about if we get a GPS fix once an hour instead of once per day?” I can say, “Based on the data, you lose 10 days of battery.”

We are talking about the same thing. I was just not sure what you meant by “scripting”

The plot is indeed a time transient one :slight_smile:

1 Like

I like those ideas, but I think I’ll start with a bald yak as a proof-of-concept!

I’m going to knock together some rough requirements in a shared document some time in the next few days. I’ll share it here and you and anyone else who’s interested can edit it to get a picture of what would be most useful.

1 Like