Stable Battery Power for Single-Board Computers

November 2025

Raspberry Pi boards tolerate load spikes but are unforgiving about supply stability. When 5V sags below the PMIC’s threshold (about 4.63V), firmware throttles and flags undervoltage; if the rail keeps dropping you eventually hit resets with a real chance of storage damage if writes are in flight.^{1 2} The Raspberry Pi 5 also raises or caps USB-port current depending on what the power source advertises, so supply and cable choices affect both uptime and how much power remains for peripherals.²

That behaviour is typical of modern single-board computers. Stable operation on battery power is about the combination of sufficient stored energy, converter efficiency, a power path that does not misbehave during transitions, and storage that does not fall apart on the first bad shutdown. This text walks through those points in order, using a real example of a Raspberry Pi 4B (8 GB) running OpenWrt and several custom services, powered from an Anker 737 Power Bank (PowerCore 24K) that reports about 2W draw with a few idle clients on the AP, and roughly one day of runtime.

The goal is to provide enough background that we can reason about SBC-battery combination, whether it is the Pi 4B on a 24 000mAh pack or another board on a different supply.

Power, energy, and the problem with bare mAh numbers

Before runtime or stability can be meaningfully discussed, some electrical quantities must be pinned down.

Power $P$ is measured in watts and describes how quickly a system consumes energy at a given instant. Energy $E$ is measured in watt-hours and describes how much work a battery can deliver over time. Voltage $V$ and current $I$ relate to power in the usual way:

$$ P = V \cdot I $$

If power is roughly constant, energy over a period $t$ in hours is

$$ E = P \cdot t $$

Batteries and power banks, however, tend to be advertised in milliampere-hours. That number by itself is incomplete. Capacity in ampere-hours is a measure of charge at a particular voltage. To compare devices or calculate runtimes, we need energy, which means combining capacity and voltage.

For lithium-ion cells in consumer power banks, nominal cell voltage is around 3.6-3.7V. The conversion is as follows:

$$ E_{\text{Wh}} = \frac{\text{mAh} \cdot V_{\text{cell}}}{1000} $$

This relation appears in vendor explanations and user discussions alike; a widely shared breakdown for the Anker 737, for example, shows $24,000\ \text{mAh} \times 3.6\ \text{V} = 86.4\ \text{Wh}$, which matches the label on the case.³

A few concrete numbers help. A 10 000mAh pack at 3.7V stores about 37Wh. A 20 000mAh pack at 3.6V stores about 72Wh. The Anker 737 is specified as 24 000mAh and 86.4Wh, with a USB-PD output capability up to 140W across its ports; both Anker’s own product page and independent reviews confirm those figures.^{3 4 5}

Once capacities are converted to watt-hours, mAh can effectively be ignored. All runtime and sizing questions then reduce to “usable Wh divided by average W”.

From label watt-hours to realistic runtime

The watt-hour figure on a power bank is defined at the internal cell voltage. The SBC never sees that voltage. Instead, a DC-DC converter boosts the cell voltage to 5V, 9V, 15V, or 20V at the USB port, and a separate path manages charging. Both processes waste some energy as heat.

Tests of modern USB-C power banks normally include “delivered capacity” measurements at fixed loads and voltages. For the Anker 737, TechRadar and other reviewers report usable capacities between roughly 73 and 77Wh at outputs from 10W to 140W, corresponding to efficiencies in the 81-89% range depending on mode.⁴ A separate detailed review at StorageReview reports the same 24 000mAh / 86.4Wh rating and discusses practical run times with real devices.⁵

For simple reasoning it is enough to roll these effects into a single efficiency factor $\eta$:

$$ E_{\text{usable}} = E_{\text{label}} \cdot \eta $$

For a well-designed bank like the 737, measurements support $\eta \approx 0.8-0.85$ when used as a 5V source for small computers. For unbranded or poorly documented devices, $\eta \approx 0.7$ is a safer planning value.

Once usable watt-hours are estimated, runtime follows directly:

$$ t_{\text{hours}} = \frac{E_{\text{usable}}}{P_{\text{avg}}} $$

where $P_{\text{avg}}$ is the long-term average power consumption of the SBC plus peripherals.

In the concrete case:

• Anker 737 label energy $E_{\text{label}} = 86.4\ \text{Wh}$.
• Taking $\eta = 0.75$ for a conservative estimate gives $E_{\text{usable}} \approx 64.8\ \text{Wh}$.

If a Raspberry Pi 4B draws on average 2.1W in the configured role, expected runtime is

$$ t \approx \frac{64.8}{2.1} \approx 30.85\ \text{hours} $$

The 737’s display, with the Pi 4B drawing around ~ 2W and two clients associated to its OpenWrt access point, reports a remaining runtime nearer 24½ hours from full charge. That implies about 49 Wh still available. Given that the display uses a sliding estimate, that the load is not perfectly constant, and that internal fuel-gauge logic tends to be conservative until it has seen several full cycles, this is consistent with the simple calculation rather than a refutation of it.

For practical sizing it is helpful to derive a mental shortcut. Once a bank’s real usable energy has been measured, we can treat it as a constant. If tests show that a given pack reliably delivers about 60Wh into a 5V SBC, then the approximation

$$ t_{\text{hours}} \approx \frac{60}{P_{\text{watts}}} $$

is usually sufficient. A 2W board then runs about 30 hours, 3W about 20 hours, 5W about 12 hours. Refinement beyond that tends to be limited by workload variability rather than arithmetic.

What single-board computers actually draw

Runtime estimates require a realistic average power. Datasheet maxima and rough guesses are rarely adequate. For the Raspberry Pi 4B specifically, several independent measurements report idle consumption around 2.7-3.0W and CPU stress tests around 6-7W when powered at 5 V, with no heavy USB peripherals attached.^{6 7} A GitHub wiki associated with the “Pi Dramble” cluster documents these measurements in some detail, using USB power meters inline.⁶ Applying these numbers to our earlier equations, we arrive pretty close to reported runtimes.

$$ t \approx \frac{86.4\text{Wh}\times 0.8}{2.7W} \approx 25.6\ \text{h} $$

Those figures assume default firmware clocks, HDMI active, and typical peripheral sets. Many real deployments are simpler. A Pi used as a router or data logger often has no display, limited USB usage, and workloads that do not require maximum CPU frequency.

In such and our case, tuning pays off:

• Disable unused subsystems in firmware, such as HDMI, Bluetooth, or analog audio, so they never power up.
• Select conservative CPU and GPU frequencies in config.txt and confirm that the operating system still meets latency and throughput requirements.¹
• Adjust Linux CPU frequency scaling to favour lower clocks when idle.
• Bring down interfaces such as Ethernet if all traffic uses Wi-Fi, or the reverse.
• Turn on runtime power management for buses like PCIe and USB3 where the kernel supports it.

The OpenWrt configuration mentioned earlier does exactly this. The Pi 4B runs with arm_freq=1000, core_freq=300, and gpu_freq=300 in config.txt, has HDMI, Bluetooth and audio disabled at boot, and uses an ondemand governor with a minimum of 600 MHz and a maximum of 1 GHz. A short shell script in rc.local brings Ethernet down, enables automatic power control for the PCIe USB3 controller, and turns off superfluous LEDs. With two wireless clients attached and light workloads, the Anker 737’s meter then indicates roughly 2W draw from its 5V output.

Other SBCs expose different controls but the structure is the same. SoC documentation describes supported voltage-frequency operating points; board documentation lists jumpers or device-tree overlays that disable subsystems entirely. Once a candidate configuration is chosen, a USB power meter and some long-run measurements provide the real $P_{\text{avg}}$ that feeds back into the runtime equations.

Lower draw helps twice: it increases runtime from the same battery and reduces voltage drop across a given cable and connector path.

Stable voltage and undervoltage detection

Even with plenty of stored energy, a system can be unstable if the supply voltage at the board does not stay within tolerance. Raspberry Pi boards make this particularly visible because they continuously monitor the 5V rail for undervoltage and mark throttling events in a way that is accessible from Linux.

On recent models a supervisor circuit in the power-management IC monitors the 5V input and asserts a signal when the rail drops below a fixed threshold, documented and discussed in community material as roughly 4.63 V.^{1 5} When that signal is active, firmware reduces clocks to limit power draw. The internal status is surfaced through the vcgencmd get_throttled command, whose bitfield indicates whether undervoltage is currently active and whether it has occurred since boot.^{8 9}

Example output:

$ vcgencmd get_throttled
throttled=0x50005

In binary 0101 0000 0000 0000 0101 it indicates active bits 0, 2, 16 and 18 are set.

• 0 - Under-voltage currently detected (live)
• 2 - Currently throttled (live)
• 16 - Under-voltage has occurred (since last reboot)
• 18 - Throttling has occurred (since last reboot)

Note that a short, brittle USB-A to USB-C cable can contribute to under-voltage and throttling events. USB-A ports often provide limited current and cheap or aging cables tend to have high resistance, causing the voltage at the Pi to sag under heavy load. A better approach is to power the Pi with a PSU with good-quality, short USB-C to USB-C cable rated for high current, and avoid USB-A outputs, inline switches, and worn cables. When testing this, the history bits can be cleared with vcgencmd get_throttled 1, stress the system again, and check whether vcgencmd get_throttled stays at 0x0 during load.

Other SBCs use different mechanisms, often buried inside PMICs or regulators, but they face the same physics. There is always a minimum input voltage below which guarantees end. Stable battery operation means choosing converters and cables that keep the operating point comfortably above that limit, including during transients.

Power banks, pass-through, and UPS expectations

Users hope to use a USB-C power bank as a small uninterruptible power supply: plug the bank into an AC adapter, plug the SBC into the bank, and ride through AC outages without reboots. Some devices, including the Anker 737, support pass-through charging, where one port acts as input and another as output.

Internally, such devices juggle at least three concerns: they must manage current into the cells to avoid overcharge, manage current out through boost converters to keep outputs within USB-PD specifications, and arbitrate between direct feed from the adapter and discharge from the cells depending on conditions. When the adapter is plugged or unplugged, the controller often reconfigures its power path and renegotiates USB-PD contracts on active ports.

Reviews that measure behaviour during these mode changes report what one would expect: short output disturbances are common, and even well-implemented banks do not promise “UPS mode” unless marketed explicitly as such.^{4 5} The TechRadar test of the 737, for example, notes that the device can pass through significant power but does not charge itself at the same time and does not act as a UPS in the strict sense.⁴

From the viewpoint of an SBC like the Pi 4B, which declares undervoltage when the 5V rail crosses roughly 4.63V, a short break-before-make interval during mode change can look exactly like pulling the cable. Available capacitance on the SBC smooths very brief glitches, but the required value grows with load current and desired hold-up time. A simple relation for the hold-up capability of a capacitor is

$$ C = \frac{I \cdot \Delta t}{\Delta V} $$

where $I$ is load current, $\Delta t$ is the duration to cover, and $\Delta V$ is the allowable voltage drop. For a 2 A load, 10 ms interval, and a permitted drop of 0.2V, this yields 0.1F. That sits firmly in supercapacitor territory rather than the microfarad range used for local decoupling.

A practical conclusion is that a consumer power bank used in pass-through mode can extend runtime and may ride through short AC interruptions, but it should not be treated as a guaranteed UPS without explicit measurement. When uninterrupted operation across AC faults is a hard requirement, a dedicated DC UPS HAT with well-specified switching behaviour, or a small AC UPS feeding the standard 5V supply, is usually more predictable.

Filesystems, SD cards, and power loss

So far the focus has been on keeping the SBC powered. Even with a stable rail, systems see occasional sudden shutdowns: deliberate power-off when the battery is exhausted, accidental cable pulls, or upstream faults. How the filesystem behaves under these events influences overall robustness.

On Linux, ext4 remains the default filesystem for many SBC distributions. The kernel documentation describes ext4 as a journalling filesystem that focuses on metadata reliability and scalable performance.¹⁰ In its default data=ordered mode, ext4 journals metadata changes and ensures that related data blocks are written before their metadata references are committed. This greatly reduces the likelihood of structural corruption compared to non-journalling filesystems, but it does not promise that the latest user data are present if power fails before an application issues fsync().

Analyses of ext4 behaviour and fast-commit extensions make the same point in different words: journalling offers strong guarantees about consistency of the filesystem’s internal structures, not about arbitrary data that an application may still have in buffers.^{10 11} A widely cited Unix & Linux Stack Exchange answer summarises it bluntly: “There are no guarantees. A journaling file system is more resilient and is less prone to corruption, but not immune.”¹²

F2FS, the Flash-Friendly File System, was designed with flash media in mind. Kernel documentation and the original FAST paper from 2015 describe its log-structured layout: the volume is divided into segments; all writes go to free segments; checkpoints store summaries of recent state; NAT (Node Address Table) and SIT (Segment Information Table) track where metadata and data now reside.^{13 14} To guard against inconsistent metadata, F2FS keeps shadow copies of NAT and SIT and toggles between them at checkpoints.¹⁴ On power loss, the filesystem mounts at the latest valid checkpoint and, if needed, replays fsynced changes.

That design fits the characteristics of raw flash reasonably well and can reduce write amplification on some devices. On commodity SD cards and eMMC, however, there is a sophisticated flash translation layer between filesystem and physical cells. Behaviour under power loss then depends on both F2FS and the controller firmware. In practice, F2FS is a reasonable choice for write-heavy workloads, but it does not remove the need for clean shutdowns.

For an SBC powered by batteries or unstable upstream sources, filesystem robustness is therefore a layered problem:

1. Avoid unnecessary brownouts and hard cuts by designing the power path well.
2. Choose a filesystem that handles crashes reasonably, whether ext4 or F2FS.
3. Reduce the amount of state at risk during a cut by limiting writes to persistent media.

Several guides show how to run Raspberry Pi systems with a read-only root filesystem, using overlayfs to combine a static base on the SD card with a writable tmpfs layer in RAM.^{15 16} Raspberry Pi forums and blogs document similar schemes implemented via init scripts and overlayfs.¹⁵ When set up correctly, most runtime writes (logs, temporary files, caches) land in RAM and vanish on reboot. The SD card sees only occasional updates when explicitly remounted read-write for maintenance.

Combining a stable power path with such filesystem arrangements produces systems that tolerate occasional cuts with far fewer surprises.

Solar as an upstream source

Power banks do not need to be charged from the grid. Small photovoltaic arrays can supply the same DC energy if local conditions are favourable. From the SBC’s point of view the change is upstream: the board still sees a battery and a DC-DC converter.

To reason about solar contributions, daily energy rather than instantaneous power is the natural unit. If an SBC and its peripherals draw an average of 5W, they consume about 120Wh per day. A solar-battery system must, over its averaging window, supply at least that much.

The Global Solar Atlas, provided by the World Bank Group, offers maps and downloadable data of global horizontal irradiation (GHI) in kWh/m² per day.^{17 18} For much of Japan, long-term averages translate to roughly 3-4 kWh per installed kWp per day, depending on exact location and tilt. Studies using these datasets for rooftop solar estimation in Japanese regions arrive at similar figures once real-world factors are considered.^{19 20}

That means a 30-40W panel, operated through a competent MPPT or PWM controller and feeding a battery, can often deliver on the order of 100-150 Wh per day under average conditions. In summer this may exceed demand; in winter and poor weather it may fall short. The basic energy balance, however, is the same as in the power-bank examples: usable Wh in must match or exceed Wh out over the interval of interest.

From a stability standpoint, the important observation is that solar fluctuations are filtered by the battery. As long as the charge controller and battery are sized correctly, the SBC sees a local DC source within specification. The same rules about converter quality, cable resistance, and undervoltage monitoring apply.

Practical approach to designing a battery-backed SBC

Putting all of this together, a methodical process for designing or evaluating a battery-backed SBC looks simple on paper, even if measurement takes some time.

We start by converting any advertised mAh into watt-hours at the rated cell voltage, or use the Wh directly if it is given. For the Anker 737 this is 86.4Wh. Apply a realistic efficiency factor to obtain usable energy; for the 737, tests suggest about 80-85% under moderate loads, so something in the 70-75Wh range is a reasonable expectation.^{4 5}

Then measure the SBC’s average power under its real workload. Inline USB power meters are inexpensive and sufficient if treated carefully. For a Pi 4B running OpenWrt with HDMI off, reduced clocks and no heavy USB devices, we might see 2W with HDMI on and higher clocks, closer to 3W under CPU stress, 6W or more.^{6 7} Use the realistic long-term number.

Divide usable Wh by averageW to get runtime, and decide whether the number matches the deployment goal. If it does not, the options are to reduce load, increase battery capacity, improve converter efficiency, or some combination.

In parallel, verify stability. On Raspberry Pi, vcgencmd get_throttled and power-supply logging scripts provide a view into whether undervoltage events are occurring.^{8 9} If they are, improve the power path: shorten and thicken cables, use supplies with better voltage regulation, remove unnecessary adapters and hubs, or reduce peak load. On other SBCs, check documentation for equivalent status registers or logs.

Finally, consider storage. A system intended to operate unattended and occasionally exhaust its battery benefits from a filesystem and layout that treat power loss as routine, not exceptional. A read-only root filesystem with overlayfs on top, ext4 or F2FS configured thoughtfully, and logs directed to RAM rather than SD card are all standard techniques with ample documentation.^{10 12} [^16] ^{15 16}

The Raspberry Pi 4B on an Anker 737, trimmed to draw about 2W and monitored for undervoltage, is just one instance of this general design. Once the core relations between watt-hours, watts, efficiency and voltage stability are clear, the same analysis applies to other single-board computers, different power banks, and solar-charged systems with few surprises.