Kleidos
EN ES
Menu

Measurements

Current, in milliamps, read off the board's own power controller while it ran on its own battery. Beside each figure is the budget it was supposed to meet, where the project set one.

I publish the ones that miss, because a power budget nobody checks is decoration, and because these numbers exist nowhere else. No datasheet tells you what a password manager draws with its screen at 85 percent and an access point up.

What it draws awake

One run, two boards, every phase on battery with the USB cable out, on a development build with the logging, the console and the diagnostics all running. The backlight is at 100 percent except where the row says otherwise.

Three of these rows have a budget and all three are over it. The PIN screen draws about four times what it was allowed, typing about one and a half times, the access point just over. The lit panel is most of it: at 100 percent the backlight alone accounts for 53 to 55 mA of the figure, which is why the same board with the screen asleep draws 25.

Two runs of the same phase on one board came out up to 4 mA apart, so a smaller difference between the two columns is not a finding. A comparison inside one run (one board, one charge, minutes apart) is the firm one.

The run itself, phase by phase, is in docs/research/consumption-self-measurement.md.

What the clock costs

The same two boards with the panel dark, at each of the three clocks the firmware uses. The panel is off in all three, so the difference is the chip and nothing else.

The clock Plus SE (mA) Core2 v1.3 (mA)
80 MHz What every screen runs at 22.025.3
160 MHz What a full-screen repaint is composed and sent at 26.130.2
240 MHz What the two-second unlock runs at, and nothing else 34.243.1

This table is why every screen runs at the lowest clock the chip's internal multiplier gives, and only the work that needs speed gets a higher one: holding 240 MHz for a whole session would cost 12 to 18 mA for nothing. The higher clock is set where the work is rather than at a call site, so a new caller inherits it.

The run itself, phase by phase, is in docs/research/consumption-self-measurement.md.

What it draws asleep: I do not know

Nine boards, nine figures, and not one of them is a measurement. Each is the estimate declared in the board's own configuration, and the budget was 20 microamps.

estimate, not a measurement

I have not made the bench measurements that would replace these estimates with readings from a meter. The device cannot do it for me: on a stick with a 120 to 250 mAh cell, estimating from the voltage drop only reaches an accuracy of about ten to twenty-five microamps after three to seven days asleep, and on the bigger boards it only catches leaks in the milliamp range. So the firmware reports a verdict of pass, fail or unknown with error bounds, and never reports a model's figure as a reading.

The two lowest estimates belong to the boards that cut their own supply, and they can afford to because a separate clock chip keeps the time while they are off. The three highest keep a rail powered for the chip's internal clock, because they have no clock chip at all, which is what the next section is about. Six of the nine have no current sensor on the battery rail either, so for those there is no self-measurement path to improve: a meter is the only way these nine numbers stop being estimates.

The run itself, phase by phase, is in docs/testing/production-sleep-checklist.md.

The clock that drifts

The three boards with no clock chip keep time through a sleep on an internal oscillator divided by 256. Across 66 sleeps, measured against a host clock held to NTP, this is how far their clocks moved. The table covers the production deep sleeps begun at rest, and in every one of them the device clock fell behind. In sleeps begun hot, after ten minutes of load, two boards ran ahead instead: the Plus S3 in one of its two hot sleeps and the Cardputer in both. The T-Deck fell behind in every deep sleep it took.

Board Parts per million Seconds per hour asleep
M5StickC Plus S3 -1,768 to -99 0.4 to 6.4
M5Cardputer ADV -2,022 to -538 1.9 to 7.3
LilyGO T-Deck Plus -6,033 to -4,719 17 to 22

The largest errors over the whole run were 6,033 parts per million behind and 2,300 ahead. Each chip carries an offset of its own (the T-Deck about 5,000, the other two about 1,000), and around that offset the die temperature moves the error more than anything else: a sleep begun hot was off by 1,500 to 2,700 parts per million less. A light sleep with the crystal left powered does not keep crystal-class time either.

No correction is applied. None that fits that spread would hold a one-time code inside its one-step tolerance, so on these three boards the codes are off by default, and when switched on they ask for a fresh sync (from a network, from the browser that opened the admin panel, or from a satellite fix) made since the last deep sleep.

The run itself, phase by phase, is in docs/research/slow-clock-sleep-matrix.md.

How these were taken

The three groups above come from three different methods, and mixing them would be the most misleading thing this project could publish.