A deep dive into Raspberry Pi Zero 2 W’s power consumption

When I completed my review of Raspberry Pi Zero 2 W, I mentioned I would test the power consumption of the board later. It took a while, but I’ve finally come around it using Otii Arc from Qoitech and Otii software to provide some pretty power consumption charts, and even energy consumption. Since the Raspberry Pi Foundation recommends a 5V/2.5A power supply, I’ll first try to get as close as possible as 2.5A, then I’ll go through tricks to reduce idle power consumption to less than 75 mA / 375 mW, and finally check the energy consumption under various CPU core count and frequency.

Raspberry Pi Zero 2 W Power consumption under load, with accessories

I started with the latest Raspberry Pi OS Lite “Bullseye” image and connected my Raspberry Pi Zero 2 W board to Qoitech Otii Arc tools as shown below. It used to cost around $500, but now pricing starts at $699, and it’s a great tool for people developing battery-powered devices, and I admit it’s a bit over the top, but the purpose of this post, but it still does the job.

Let’s turn on the Raspberry Pi, and check the idle power consumption using the image we’ve just flashed without any modifications.

That’s about 120 mA @ 5V, or 600 mW. If you’ve seen lower numbers with earlier reviews of the Raspberry Pi Zero 2 W that’s because we’re using the Raspberry Pi OS Bullseye image instead of the Buster image, and we’ll explain the reason why that is later in this post.

I also own a Raspberry Pi Zero (without WiFi), and it consumes 108 mA with the same image.

Another neat feature of the Otii Arc is synchronization of the power measurement data with the serial console, so I connected the wires to access the serial console in Otii program.

I also enabled UART in config.txt:

and SSH by creating an empty /boot/ssh file on the microSD card. That’s because the serial console in Otii is not super convenient to use, there’s no history, programs like vim or raspbi-config can be run and so on, so I’ll still do a lot of work over SSH unless I need to match the serial console output with V/A data. The power consumption went up to 125 mA after that.

I’ve tested USB Ethernet, WiFi, a USB hard drive and connecting an HDMI cable to see how each accessory/feature would impact power consumption. The numbers show the approximate additional mA per item compared to idle.

	Delta	Remark
USB Ethernet dongle	+104 mA	No network connection, only a USB Ethernet dongle inserted into the USB OTG port.
USB Ethernet dongle + link	+180 mA	After inserting an Ethernet cable.
USB Ethernet dongle + iperf	+244 mA	Average. See chart below for details.
2.4 GHz WiFi	+11 mA	Connected to 2.4 GHz access point.
2.4 GHz WiFi + iperf	+187 mA	Average. See chart below for details.
Logitech RF dongle for keyboard/mouse	+29 mA
Seagate USB HDD (idle)	+255 mA	Stable current after initial insertion that peaked at 1.06A. See chart below for details.
Seagate USB HDD (iozone)	+554 mA	Average. See chart below for details
HDMI cable	+7 mA	This is only after inserting the cable, not about enabling/disabling HDMI. More on that below.

WiFi is much more efficient than Ethernet especially when idle, hard drives draw a lot of power when initially connected, and connecting an HDMI cable only marginally impacts power consumption.

The iperf Ethernet chart shows both the voltage and current were stable at the beginning, and somehow fluctuate a bit more after around 20 seconds, maybe packet collisions occur after a while?  There’s also a short spike to 516 mA, but it could be related to another process.

WiFi is a lot more “noisy” with the current quickly oscillating between about 160 to 480 mA during the data transfer. The total energy is slightly lower than Ethernet, but less data was transferred.

Connecting a USB hard drive makes for a pretty chart with a high current draw at the beginning up to 1.06A, follows by peaks while mounting the partition(s). After a while, the system stabilizes to 386 mA on average.

iozone can not be installed with apt on Raspberry Pi OS, so I built iozone 3.492 with the same instructions as in my Raspberry Pi 4 review.

It’s difficult to look into the details the way the console is written too, but it appears writes consume more than reads.

To check the power and energy consumption under load I used Thomas Kaiser’s SBC Bench script launched from Otii serial console.

We can clearly see the multi-threaded 7-zip compression/decompression test on the right with the much higher power consumption with peaks to close 600 mA.

If we select the text between “tinybench” and “cpufreq OPP” in the serial console, we can see the actual benchmark (excluding installing and post-execution) used 328 mWh of energy, with a peak of 624 mA, and a runtime of 14 minutes and 17 seconds. Let’s keep those numbers in mind, as we’ll use them later on.

We’re still far from our 2.5A target with a 1.06 A peak so far. So let’s try Raspberry Pi OS Desktop instead.

The average is 124 mA which is about the same as the Lite image, but there are many spikes to around 300 mA.

If I connect an HDMI monitor the average goes up to just 131 mA. The idea was to connect USB Ethernet, USB hardware, keyboard and mouse through a USB hub to stress test the system, but none of my USB hubs will work with the Raspberry Pi Zero 2 W:

So I gave up that part and simply connected the USB drive to the USB OTG port and WiFi.

I planned to play YouTube videos and run some 3D graphics benchmarks like OpenArena, but with just 512MB RAM that’s asking too much… OpenArena could launch, and I could select “Demo”, but it crashed without fail while loading the demo. So I ran es2gears instead (which really appears to run a software renderer),  inserted the HDD, ran iozone, and then stress-ng. That means es2gears, iozone and stress-ng were all running at the same time.

This peaked to a maximum of 1.35A, with still plenty of headroom using the recommended 5V/2.5A power supply. Although I had it longer than the screenshot above and I had at least one peak at 1.46A. If I had run stress-ng first, and then inserted the USB drive, we would probably have a slightly higher peak, which I would estimate to 1.7 or 1.8A. I’m sure I could have reached closer to 2.5A if I had been able to play a video from the hard drive, run a 3D graphics demo, while stress-ng is running. But without a working USB hub, nor Bluetooth keyboard that’s challenging. Anyway, that means in most cases, a weaker power supply, even 5V/1A would be sufficient with Raspberry Pi Zero 2 W. I haven’t been able to test a MIPI CSI camera since I don’t have any.

Lowering Raspberry Pi Zero 2 W power consumption

Let go back to the Raspberry Pi OS Lite image with only UART and SSH enabled and nothing else at 125 mA idled. We’ll make some modifications to try to lower the power consumption mostly via raspi-config utility and editing config.txt.

Let’s force Raspberry Pi RP3A0 to 600 MHz.

I don’t expect improvements here while idle… and indeed we’ve got 127 mA somehow. Let’s disable the GPU completely by setting the memory to 16:

Still 127 mA on average at idle….

We can disable LED in theory by adding the following lines in config.txt:

But it’s not working for me whether I set the second line to off or on. But I can turn off the LED manually from the command line:

It shaves 1mA to 126 mA, or about 5mW. What’s very odd is that sometimes I have to run the following instead to turn the LED off:

Let’s now disable audio, WiFi and Bluetooth, and camera/display auto detects in config.txt:

We are down to 114 mA, instead of 125 mA when we first ran the image without modifications, i.e. default settings including no WiFi, but SSH and UART enabled. That’s a small saving of 9 mA.

Another trick is to disable HDMI with the following command:

But it’s not working apparently because of the new standard KMS video driver for 3D graphics in Raspberry Pi OS Bullseye:

We can go to raspi-config to change that, namely in “Advanced options->GL driver“, where it will install some packages, and then we can select “G1 Legacy“.

It will change config.txt from:

to

Now we are talking! The power consumption went down to 92.7mA, or about 21mA less, and we’ve yet to disable HDMI output:

That’s down to 75.5 mA, another ~17 mA. If you want to disable HDMI automatically at boot time add the line to /etc/rc.local file. That’s also where I ended up turning off the LED (just don’t ask me why I don’t need to run the line to set it to 0 or 1):

We’ve got one more trick that will probably not lower idle power consumption much, but Jeff Geerlink provided instructions to disable cores, so let’s modify /boot/cmdline.txt to limit the number of cores to one with maxcpus=1:

It works as we can only see one core in /proc/cpuinfo:

But what about the power consumption? 74.6 mA, so there may be some limited benefit going to one core only with regards to idle power consumption. Now let’s disable SSH:

as well as UART to see if we can get to 70 mA.

Sadly it did not help that much, as I could only achieve 74.5 mA at idle. There may be some other optimizations as we can see spikes to 100 mA from time to time. Some processors have some low power modes where all application cores and some blocks can be turned off and on as needed or/and various sleep modes, but I could not find anything for Broadcom BCM2837 / BCM2710A processor.

Energy usage

Now let’s see if it is possible to lower the energy usage by adjusting the frequency and the number of cores used. That’s useful for battery operation. I’ll rerun SBC bench with four cores at the default frequency (1.0 GHz) with WiFi, SSH, and some of the optimization we’ve enabled to check how it affects energy usage. For reference, the idle power consumption is just under 80mA in this configuration.

The full results can be found at http://ix.io/3HrM. That’s odd, because slightly more energy was used with 338mWh than in our first run without optimization (328 mWh), and the test took 16 minutes and 49 seconds to complete (vs 14:17), while the maximum current draw was 635 mA. I thought I had not saved the first results, but luckily, I saved the power measurements, and Otii will keep the serial output, so I could recover the first results @ http://ix.io/3H54.

A quick check at 7-Zip to compare the first run:

with the second:

reveals some minimal performance differences.

I compared both outputs in Meld, and I could not see much difference, apart from the KMS driver being enabled, and the higher idle percentage in the first run, slightly higher iowait percentages in the second.

Anyway, let’s switch to using four cores @ 600 Mhz to see if we can save energy and extend battery life while running the same tasks.

Full output: http://ix.io/3HrU. Interestingly almost the same amount of energy was used with 331mWh (still 7 mWh less, but similar to the first run @ 1.0 GHz), and the test took long as expected at 23 minutes and 18 seconds. The maximum power draw was only 449 mA, which means the board can be safely powered by a USB port from a router or computer with this workload.

Let’s do a final run with a single-core configuration @ 600 MHz.

Full results: http://ix.io/3Hsg. The energy consumption is much higher at 483 mWh, maybe that’s because of the way 7-zip handles “multi-core” compression/decompression on a single core system, I don’t know, maybe somebody will have an idea in the comments section. Unsurprisingly, It also took much longer to complete everything: 43 minutes and 50 seconds. The only potential advantage is that the maximal current draw was only 349 mA, but again this is exactly as it should be since three cores were turned off.

[Update: After discussion in the comment, I realized I should have taken measurements for the same amount of time because of the idle current draw, so I’ll adjust the results to 43m50s using 80 mA idle power consumption for the first two scenarios to get a better idea of the differences:

• 4x cores @ 1,000 MHz: 338 mWh (16:49)  + 180 mWh (27:01) = 518 mWh
• 4x cores @ 600 MHz: 331 mWh (23:18) + 137 mWh (20:32) = 468 mWh
• 1x core @ 600 MHz: 483 mWh

That means here we simulate a workload where sbc-bench runs on the board every ~44 minutes, excluding installation and post-benchmark activity. The actual result will obviously depend on your specific application/workload.

]

That will be all for now. Feel free to ask if you need me to test something else while I still have the testbed on my desk.

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress