# 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. On this page 1. [Awake](https://kleidos.dev/#awake) 2. [The clock](https://kleidos.dev/#clock) 3. [Asleep](https://kleidos.dev/#asleep) 4. [Drift](https://kleidos.dev/#drift) 5. [Method](https://kleidos.dev/#method) ## 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. ### PIN screen **Plus SE** 77.5 mA **Core2 v1.3** 81.4 mA **Budget** 20 mA over budget The unlock dial, waiting for a digit. ### Vault list **Plus SE** 77.4 mA **Core2 v1.3** 80.9 mA The list of credentials on screen. ### Vault list at the shipped brightness **Plus SE** 69.0 mA **Core2 v1.3** 70.4 mA The same screen at 85 percent, which is what the firmware ships at. At 100 percent it draws eight to ten milliamps more, for a backlight nobody asked to be brighter. ### Typing over Bluetooth **Plus SE** 85.4 mA **Core2 v1.3** 91.9 mA **Budget** 50 mA over budget The send screen with the radio up, waiting for the host to take the keystrokes. ### Admin access point **Plus SE** 153.5 mA **Core2 v1.3** 153.4 mA **Budget** 130 mA over budget The panel's network up with no client joined. The access point's own share of this is 72 to 76 mA. ### Screen asleep **Plus SE** 24.7 mA **Core2 v1.3** 25.6 mA The vault list with the panel off, at the base clock. This is the awake chip and almost nothing else, and it is already above the 20 mA the PIN screen was budgeted. 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. **80 MHz** What every screen runs at Plus SE: 22.0 mA Core2 v1.3: 25.3 mA **160 MHz** What a full-screen repaint is composed and sent at Plus SE: 26.1 mA Core2 v1.3: 30.2 mA **240 MHz** What the two-second unlock runs at, and nothing else Plus SE: 34.2 mA Core2 v1.3: 43.1 mA 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 ### M5StickC Plus2 **Estimate** 10 µA **Budget** 20 µA Drops its own power hold: the board cuts its supply. ### M5Stack CoreInk **Estimate** 10 µA **Budget** 20 µA Drops its own power hold: the board cuts its supply. ### M5StickC Plus 1.1 **Estimate** 30 µA **Budget** 20 µA over budget Switches off at its power controller, which stays awake to switch it back on, and draws while it waits. ### M5StickC Plus SE **Estimate** 30 µA **Budget** 20 µA over budget Switches off at its power controller, which stays awake to switch it back on, and draws while it waits. ### M5Stack Core2 v1.3 **Estimate** 30 µA **Budget** 20 µA over budget Switches off at its power controller, which stays awake to switch it back on, and draws while it waits. ### M5Stack CoreS3 SE **Estimate** 105 µA **Budget** 20 µA over budget Switches off at its power controller, which stays awake to switch it back on, and draws while it waits. ### M5StickC Plus S3 **Estimate** 110 µA **Budget** 20 µA over budget Deep-sleeps with a rail still powered, to keep the chip's internal clock running. ### M5Cardputer ADV **Estimate** 150 µA **Budget** 20 µA over budget Deep-sleeps with a rail still powered, to keep the chip's internal clock running. ### LilyGO T-Deck Plus **Estimate** 200 µA **Budget** 20 µA over budget Deep-sleeps with a rail still powered, to keep the chip's internal clock running. 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. **M5StickC Plus S3** Parts per million: -1,768 to -99 Seconds per hour asleep: 0.4 to 6.4 **M5Cardputer ADV** Parts per million: -2,022 to -538 Seconds per hour asleep: 1.9 to 7.3 **LilyGO T-Deck Plus** Parts per million: -6,033 to -4,719 Seconds per hour asleep: 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. - The awake figures come from the board's own power controller. Three of the nine boards have a current sensor on the battery rail, and the two in the table are two of those three; the other six can only be modeled. Each figure is the mean of a measuring window taken after the screen had settled. - The run was on battery with the USB cable out, driven over the serial console by a script in the repository and read back with another one. The build had the logging task, the console and the diagnostics running, so if anything these figures are a little pessimistic. - The sleep figures are not measurements and are labeled as estimates wherever they appear. The checklist that would replace them needs an external meter and a person pressing keys, and I have not run it on any board. - The drift figures are a different method again: the device's own clock against a host clock checked against NTP, before and after each sleep, with the oscillator's tick count read at both ends so the period it actually kept can be worked out rather than assumed. - Nothing re-reads the firmware to check that these numbers are still the ones it produces. There is no checker; I keep them true by hand, and each section says which document holds the run its numbers came from.