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.
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.)
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
In theory if each of these is described, they you can run a simulation to balance out the power consumed and generate the analysis.
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 
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.
You could also do it in LTspice. It’s free, and ASCII input in the design files, so you could add a script if needed to insert values into the LTSpice design file from another program (like Excel)
You could just add a lot of current pulse generators and fill in to those generators from the external files. A lot, since then you do not need to alter the schematics, just fill 0 in those not used
I’m pretty sure that ST’s STM32CubeMX has a tool like this built into its IDE. I played around with it recently when I setup a project but I didnt have any low power requirements, so I didn’t dive too deep. Obviously only useful for STM32 devices.
I could only find this video online which looks like an older version.
Like piecewise linear? That’s an interesting idea. That could handle more complicated sequences for a single sensor:
Yes, that kind of thing, but with a configuration language that allows for adding more devices.
Better to use a VSRC and Vpulse, that way you get infinite pulses and steady state contributions. Actually the VSRC could be piecewise liniear, so you can take account for very slowly moving values (like wearout, increased leakage over time)
I’ve started a requirements gathering document for this idea. Anyone who’s interested or has ideas they want to share, please feel free to edit (it should be open for anyone to edit). I’ve tried to summarise what’s been mentioned in the thread here, and I have some ideas for how to do the software side of things, but it’s quite rough.
I wonder too:
Time related cadences:
Many devices are used by people, this means they don’t run at steady duty cycles, instead the run at different prescribed duty cycles at different times of the day and days of the week.
Example:
A soap dispenser in an office building
Mon-Friday
12am-8am - 10 load events per hour
8am-11am - 30 Load events per hour
11am - 1pm - 100 load events per hour
1pm-5pm - 30 load events per hour
5pm-12am - 5 load events per hour
Sat & Sunday:
All day - 5 load events per hour
Yes you could integrate this into a single number but I like the idea of a tool doing it for me, makes it easier for revision control.
Another aspect is potentially adding randomness/tolerence to the sim, yes it reverts to the mean in a nominal sense but how to calculate the min/max battery life?
