If you’ve ever designed a battery-powered device with a Pi Zero, you have no doubt looked into decreasing its power consumption. Generic advice, like disabling the HDMI interface and the onboard LED, is omnipresent, but [Manawyrm] from [Kittenlabs] goes beyond the surface-level, and gifts us an extensive write-up where every recommendation is backed with measurements. Armed with the Nordic Power Profiler kit and an SD card mux for quick experimentation, she aimed at two factors, boot time and power consumed while booting, and made sure to get all the debug information we could use.
Thanks to fast experimentation cycles and immediate feedback, we learn plenty of new things about what a Pi Zero does and when, and how we can tame various power-hungry aspects of its behavior. Disabling the GPU or its aspects like HDMI output, tweaking features like HAT and other peripheral probing, and even tactical overclocking during boot – it’s an extensive look at what makes a Pi Zero tick, and no chance for spreading baseless advice or myths.
All in all, this write-up helps you decrease the boot time from twelve seconds to just three seconds, and slash the power budget of the boot process by 80%. Some recommendations are as simple as config.txt entries, while others require you to recompile the kernel. No matter the amount of effort you can put into power optimization, you’ll certainly find things worth learning while following along, and [Manawyrm]’s effort in building her solar-powered Pi setup will help us all build better Pi-Zero-powered solar devices and handhelds.
9.5J to 1.438J is almost 85% energy reduction!
A Raspberry pi is overkill for a device that takes pictures and sends them over WiFi. I guess an ESP32 might consume less energy per picture.
Can you pair a decent sensor with an ESP32? The image quality of those cheap camera modules is terrible.
OV5640, 5MP. Or any camera peripheral that can communicate on SPI, I2C, UART, etc.
~100 mA seems pretty decent for an SoC, but that’s way too much to run 24/7 without solar.
ESP32 will pull 3-20 mA in modem sleep, 0.8 mA in light sleep (clock gated), 10 microamp in deep sleep (ULP co-processor only), and 2.5 microamp while hibernating listening to RTC GPIOs.
This is the kind of power optimization that enables multi-year battery life.
As always the question is what are the end goals and future projects this may be a building block for. Far as I know none of the common serial cameras can actually manage even close to the frame rate of the Pi at similar quality for instance. Then there is quality of sensors available for each method – which shutter type, low light performance, control of exposure times etc. No point using an ESP32 for its lower power draw if the images it can gather are useless.
Also the power draw of the ‘brain’ behind these camera modules has to be accounted for too if low power draw is the only thing that really matters – that chip that does the initial signal processing from the CCD probably has quite a bit of RAM and processing for autofocus, etc – wouldn’t surprise me if the power saved by a more direct to end to user high bandwidth connection from the camera module and the potential for shorter required wake periods exceeds the saving from using the micro with lower sleep power draw in some use cases.
The full Linux computer also just flat out comes with huge advantages in most ways, only really being potentially problematic from a functionality point of view when ‘realtime’ is important. And as the cost of small SOM vs Microprocessor in a similarly ready to use format is often tiny…
Good insight, definitely different tools for different applications.
Well done. Not enough people care about optimisation (of any sort) these days, and you’ve got some impressive results!
That’s why I love low power design, it’s all about obsessing about every single small aspect of the circuit.
Let me tell you about the most recent factor I’m having to consider about a design, it’s something very exciting but few get to work on it directly – the derating of Lithium Thionyl Chloride cells (from China). The cells are very cheap but they come without a datasheet (the datasheet they give is a random western vendor’s datasheet with their logo stuck on top).
Sorry forgot to complete
* derating of Lithium Thionyl Chloride cells depending on the current draw
It’s not a complex or new problem, but the fact i cannot trust a datasheet and need to perform testing on my own, within a short timescale is the cool part 😁
Ah, the fun of trying to accurately characterise a cell when the use case is 1mA continuous over 15 years and any increase in current draw absolutely tanks the total capacity in a highly nonlinear manner… without waiting 15 years for the results!
Yep! That’s really fun! Batteries are very cool. Devices which survive on low power are amazing. At work I am trying to figure out an issue that not many people seem to talk about on the internet.
Cells with low capacities and high internal resistance (most common in coin cells, think CR2032, etc) have an issue where you have to give their electrolyte some time to “recover” if you plan on doing anything with heavy current transients (think a few mA), even if the avg current is tens of uA.
When you have a lot of high current transients, after a certain point, their internal resistance increases to the point where the voltage may show a stable 3V with minimal load, but you’ll be lucky to get more than a few hundred or so uA without the voltage dropping fast. A “rest” period must be given to the cell if the previous internal resistance is to be recovered.
I’ve had the idea to make a small device with a LoRa transreceiver chip + MCU + camera with a small solar panel and battery, and program the device to wake up every few hours to take and transmit a picture and go back to sleep.
I’d then proceed to set up the device in the wilderness near my house and let it run for years to come (I hope?). The real fun would be in seeing how long it can keep running!
this is an impressive bit of work but i’m specifically going to call “bull!” on the claim of no stone unturned.
the specific problem with pi, from my perspective, is that there are stones you can’t see under. and boy did they bump into them here!
and it shows! when they get into the nitty gritty, they immediately start pasting snippets from raspberry’s proprietary config.txt. as an embedded developer, i find this process infuriating, because i don’t know what genuine effect i’m having on the hardware. there’s no way to know what the hardware is capable of (the SoC isn’t documented), and there’s no way to know if the firmware is really doing what you want it to. you’re left with the — again, impressive — imperical measurements of current draw to try to guess whether it had any effect at all!
but a lot of people are more pragmatic than i am. they don’t mind if they can inspect the bottom of the stone or not, so long as they are able to ensure that not too much current is leaking into that dark recess. i respect that viewpoint. unfortunately, raspberry does not! all of these config.txt settings will be obsoleted in short order. if you go googling for people performing these sorts experiments, the results are full of people commenting on 5-10 year old forum posts saying the recommended hack to config.txt no longer works. sometimes you are lucky enough to see a back and forth discussion where people detail the behavior over time…nowhere near as useful as comprehensive up-to-date reference documentation with back-versions or changelogs…but at least it’s often possible to puzzle out when it stopped working. if that’s useful information to you.
and then if you want to mix and match your own custom kernel with an old version of their firmware, my god are you in for it now!
if it was all open source, i could live with the poor documentation, frequent changes, bugs, awkward technical choices (doing all this in the bootloader instead of in the kernel), and genuine technical limitations. but for a closed source piece of firmware, those infelicities really start to sting a little bit more deeply.
If your using a PI for a battery powered device you’ve already barked up the wrong tree.
absolutely not. different devices for different applications, different meanings of “low power”, and different money/time/capability budgets.
you just wrote up the herculean effort to work around the fact that the pi literally doesn’t have power management. someone successfully using pi on battery is genuinely newsworthy.
this site posts about one article a week of someone putting a pi on a battery for a ‘cyberdeck’ that they clearly never use outside of show-and-tell hour. this is the first bona fide battery-powered success story i’ve seen, out of well over a hundred failures since this site started evangelizing pi’s closed source ecosystem to us.
So what better SBC or SOM would you use? Far as I can tell there is nothing out there even remotely as good at all the stuff a Pi is ideal for, only some tiny overlaps when a larger computer or smaller microprocessor could have been used and is debatably a better choice. Or an SBC that is good only on paper, but next to impossible to actually use, with the terrible documentation, available for only a year or two at best, can’t even get it to boot a kernel that isn’t qualifying for its pension with lots of work and accepting half the hardware won’t work anymore…
The Pi family is darn impressive in cost, function, support, degree of openness, outside the pandemic crunch availability is usually good, with years of availability for each model as well. And they are as a family darn low power for a full computer, with a variety of power points you can select from in the different models so very suitable for battery applications even with the limited power management…
They are an entirely different beast to the ’35w’ tdp low power CPU from AMD/Intel that probably wants a power supply able to drop 125w still, which all that closed BIOS, microcode (etc) that changes performance in some cases drastically when its updated. And those whole system still likely idles in the same handful of watts range as a Pi with nothing to do, and might well fry a battery in the spike of current they want…
And while a laptop board may work out better power efficiency wise than a Pi, it is still full of closed crap and only might have had enough effort put in to really have lower power performance… Hopefully its built in battery management is actually capable of dealing with the needs of the system in question (though that is hugely variable as well, so many laptops now don’t have the power or thermal envelope to actually make it worth having the CPU/GPU they do)… But even the best laptop type board is in nearly all cases a terrible choice for a project as you’ll never get another actually compatible one with all the silent revisions that moves mounting holes etc. So you can never make a second of your project, and if anything ever breaks the whole project is now waste. And usually being vastly larger and very specifically shaped to fit around the other components in its original format you had to really work hard to find a space to fit it…
If you want to bitch at least point out a valid and remotely comparable alternative we should all be using instead…
I’m too frustrated with Pi’s lack of proprietary firmware and closed source bootloader, and I appreciate your rant being up there in the comment section, because you mention some things people ought to remember.
also, it is jarring to me that you aim it at me. I know the platform is fundamentally flawed as far as power management goes, and so do a large amount of other hackers. People use it because it’s still a board that’s cheap, easily accessible, and with a hundred other cool features. We cover the positive aspects of a hack, not side topics that are related. For what this hack works with, it gets wonderful results.
your definition of “success story” is pretty one-sided. the key is simply, a lot of projects are able to just increase the battery capacity to get to a point where the device lasts long enough between charges, because there’s more than just battery life at play. judging these projects by “a board with proper power management” misses the point, because it’s not the only variable – there’s the community, low price, all the other features you get, ease of access, and a bunch of other factors. Foldi-One’s comment is good at describing what’s up.
I can resonate with “cyberdecks built just for show”, IMO it’d be damn cool if people built devices they intended to actually use, and I too have a hunch that quite a few go on the shelf. At the same time, I wouldn’t be surprised if there’s more of those than we might expect! And, the not-in-use cyberdecks might be people’s stepping stones towards building things they can actually use – after all, building daily-driveable devices is tricky! Maybe, something like a poll or a discussion topic on the Cyberdeck discord would be in order.