I want to use a RPi 4 in a remote, unattended, battery-powered application. In this application, the RPi 4 will spend most of its time inactive, awakened only by either a Real Time Clock (RTC), or a sensor. Either the RTC or the sensor will wake the RPi from its inactive state, placing it in the active state by pulling down an open-collector/drain switch. Once the RPi has finished its calculations and communicated its results, the software program will return it to the inactive state to await the next signal from the RTC or sensor.

Measurements on the RPi 4 while in poweroff or halt states are in the range of 350mA to 400mA. This is far too much power consumption for a remote, unattended, battery-powered application. In July,2019 I read a post in another forum stating that the power consumption in the RPi 4 could be reduced to "about 3 mA" by invoking the poweroff command. The same post states that this feature is "deliberately undocumented" (at the time it was written), pending reliable scripting to change the EEPROM values required.

As of this writing, more than two years have passed since this information was posted by a presumably reliable source. However, when I place my RPi 4 in poweroff, halt or shutdown it still draws over 370 mA. I am using the default crirical (a.k.a. default) branch of the EEPROM firmware:

$ sudo rpi-eeprom-update -a 
BOOTLOADER: up-to-date
   CURRENT: Thu 29 Apr 16:11:25 UTC 2021 (1619712685) 

There has been much publicity for reducing RPI 4's power consumption in active mode, but that is of limited benefit for system applications that require only an hour or less of processing each day.

My questions are:

1. Is it possible to realize the claimed current draw of "about 3 mA" in any inactive state?
2. If not, what is the minimum power draw for an inactive state & how is that realized?


Q1: Is it possible to realize the claimed current draw of "about 3 mA" in any inactive state?

A1: No - at least not with the tools covered in the "Official Documentation".

To frame this question in the larger context of energy efficiency, let's consider the modes in which the RPi may operate, and the energy requirements of those modes. This has implications for the RPi's suitability for certain classes of applications (e.g. battery-powered, or off-grid applications), and potentially for the ecological/regulatory regime.

Modes of Operation for RPi 4:

In the interest of clarity, let's define some terms:

  • (In)Active mode: In the Active mode, the RPi is running & able to process command inputs. The RPi enters an Inactive mode following a halt, a shutdown or a poweroff command issued under user control while in the Active mode. No processing is done in inactive mode. The power that's consumed in this mode may heat the room a bit, but there's no useful purpose beyond that. So despite the fact that the Red Power LED is illuminated, some oscillators may be running and regulated voltages are being maintained - the RPi is doing zero "computing" - one might say, "the lights are on, but nobody's home." It may also be noted that the Inactive mode for the RPi fails to meet the 1999 One Watt Initiative1, 2. A bit odd since the UK's Enforcement Authority3 was designated by the EU to assess compliance with regulation 1275/20084, and now enforces a similar UK regulation5. I am not a proponent of regulations, per se, but the principle of the One Watt Initiative seems practical and common sense: "Don't waste energy".

  • Sleep mode: No Raspberry Pi, currently designed or built, has any Sleep mode available - at least not one that functions. The situation AIUI is that while various sleep modes are defined and implemented for the Linux kernel, and in systemd, they are not implemented in the RPi. AFAIK, the absence of this mode has never been explained by the RPI's designer/manufacturer. Most commercial computers offer a Sleep mode that: 1.) saves machine state to non-volatile memory for user convenience by avoiding a reboot, and 2.) reduces power consumption through a variety of means.

  • Low Power mode: I'll use this ad hoc term here to cover the available option for reducing power consumption while the RPi is in the Inactive mode. The official documentation states that this (LPM) is the " lowest possible power state" for the RPi 4. Still, it's unclear that this Low Power mode meets the One Watt Initiative. Like most broad-scope initiatives, there are vagaries in the One Watt Initiative, yet the gist of it seems clear enough. For example, "standby power", a.k.a. "leaking electricity" is defined as follows:

    Leaking electricity is often described as the electricity consumed by appliances when not performing their primary purpose.

    Of course partisans can make all sorts of arguments, but it does seem safe to say that incorporation of an autonomous sleep mode could reduce energy consumption in the RPi below current norms. It also seems a stretch to consider any inactive mode - LPM included - as part of the RPi's "primary purpose".

Q2: What is the minimum power draw for an inactive state & how is that realized?

AFAIK, the lowest power consumption in inactive mode you can get from the RPi 4 today is 30-40mA. Getting down to that level requires that the bootloader firmware in the EEPROM be modified - two parameters must be changed, and the EEPROM must be re-flashed. Here's how to do that:

Procedure to Configure RPi 4 to enter LPM after halt/shutdown/poweroff:

The RPi 4B represents a break from previous models in that bootloader code is stored in EEPROM - the boot code is now resident in the hardware instead of in the /boot/bootcode.bin file on the SD card. With this change came a new set of configuration parameters, and new software tools to assist managing the bootloader. Most of the "official documentation" on the EEPROM-based bootloader is in two locations:

The "Low Power Mode (LPM)" is not the default bootloader configuration. However, reviewing the referenced documents above tells us what we need to know to re-configure the system. As you will see below, making this configuration change is fairly simple:

NOTE: Review the "official" documentation to confirm these instructions remain valid.

  1. Open the bootloader configuration file for editing:

    $ sudo -E rpi-eeprom-config --edit 
  2. Change two (2) parameters (WAKE_ON_GPIO and POWER_OFF_ON_HALT) in the editor as follows:

    # WAKE_ON_GPIO:       CHANGE FROM: 1  TO: 0
  3. Save changes & re-boot

    # Save the changes, and exit the editor. 
    # After the editor closes, you'll be prompted to reboot into the new configuration
    $ sudo reboot

Configured in this way, you will see a marked reduction in power consumption (and current draw) the next time you issue a halt, shutdown, or poweroff command - or shut down your system using the desktop. Following are my results:

  • While up and running: approx 2.0 - 2.5 Watts; 400mA - 500mA

  • Inactive mode with default bootloader configuration: approx 1.35 Watts; 270mA

  • Inactive w/ Low Power Mode bootloader configuration: approx 0.15 - 0.20 Watts; 30mA - 40mA

    NOTE 1: busterOS, Lite distro for RPi, no monitor, bootloader ver: 4/29/2021, quiescent/idle compute load, CPU governor: ondemand

    NOTE 2: No differences in power consumption noted between halt, shutdown poweroff

Are there downsides to LPM?

If you are using the "One Button Startup/Shutdown" feature enabled by the gpio-shutdown dtoverlay REF, you will find this no longer works. As The Foundation currently has things jiggered, the only way to reboot the RPi (other than "pulling the plug") is to pull down & release the GLOBAL_EN node (see figure below). For now, this will require adding a separate switch/button tied to GLOBAL_EN, or to retain the convenience of a single button, some additional hardware may be required - as in this example.

global_en location

ALSO: For reasons that are not entirely clear, the "low power configuration" outlined here cannot be used with the dtoverlay=gpio-poweroff in /boot/config.txt. IOW: You may use the "low power configuration" described here, OR the gpio-poweroff overlay BUT NOT BOTH. AIUI, a solution for this issue has been identified, and will be merged in an upcoming release of the bootloader.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.