Canonical: https://kleidos.dev/measurements/tdeck-plus/ Updated: 2026-11-04 1. [Measurements](https://kleidos.dev/measurements/) 2. LilyGO T-Deck Plus Measurements # LilyGO T-Deck Plus With Kleidos on the LilyGO T-Deck Plus and the 2,000 mAh cell I measured it with, my estimate is that a charge lasts about 11 to 21 days. Locked and asleep it draws 3.93 mA; on the vault list at the 85 percent brightness it ships at, 85.4 mA. Every current on this page comes from one LilyGO T-Deck Plus with the measurement system in its battery wire, on a development build that runs the logging, the console and the profiler. Each comes from a single run except the sleep figure, the median of three runs that agree with one another. The [times further down](https://kleidos.dev/measurements/tdeck-plus/#timings) I took on the same board with its own clock, on USB power, at three vault sizes from a small one to a full vault. I have not yet measured what typing to a connected computer draws, or what the cell really holds. [Kleidos on the LilyGO T-Deck Plus: its screen, what each control does, what it holds and what it costs](https://kleidos.dev/overview/tdeck-plus/) Updated 4 November 2026 1. [Battery life](https://kleidos.dev/measurements/tdeck-plus/#days) 2. [States](https://kleidos.dev/measurements/tdeck-plus/#states) 3. [Brightness](https://kleidos.dev/measurements/tdeck-plus/#brightness) 4. [Keyboard light](https://kleidos.dev/measurements/tdeck-plus/#keyboard) 5. [Timings](https://kleidos.dev/measurements/tdeck-plus/#timings) 6. [Not measured yet](https://kleidos.dev/measurements/tdeck-plus/#gaps) 7. [Sources](https://kleidos.dev/measurements/tdeck-plus/#sources) ## How long a charge lasts: an estimate My estimate of the days one charge lasts. I worked it out from the states in the [next section](https://kleidos.dev/measurements/tdeck-plus/#states); I have not measured a charge running down. Each session is 15 seconds on the PIN screen, 30 on the vault list and 10 on the Bluetooth typing screen, then the idle timers: 10 seconds lit and 50 dark before the board goes back to sleep, 115 seconds awake in all. I work the days out for four ways of using it, from 0 to 50 sessions a day, with the board asleep for the rest of every day. **Left in a drawer** Sessions a day: 0 Days per charge (estimate): 21 **A few times a day** Sessions a day: 5 Days per charge (estimate): 19 **About once an hour, all day** Sessions a day: 20 Days per charge (estimate): 15 **Heavy use** Sessions a day: 50 Days per charge (estimate): 11 It is the sleep that empties the cell, not the use: asleep it uses 94.2 mAh a day, and by my estimate a session adds 1.9 mAh. What goes into those days, and which way each input moves them: - Capacity: the 2,000 mAh printed on the cell, which I have not measured. A cell rarely gives its whole rating, so this puts the days higher than the board will give. - Cell voltage: I took the currents a session counts with the cell near full, at 4,030 to 4,114 mV, and the sleep figure near full too. The board draws constant power, so as the cell empties it draws more current than these figures, which puts the days higher than the board will give. - Screen: I measured the PIN screen at 100 percent brightness and the typing screen at 100, while the firmware ships at 85, and I count the dimmed last seconds before the screen goes off at the 85 percent they dim from. Both put the days lower than the board will give. - Bluetooth: I count the session's 10 seconds on the typing screen at what it draws advertising, with no computer connected. I have not measured typing to a connected one, and I do not know which way that moves the days. - Unlock and wake: the key derivation runs at a higher clock than the PIN screen I count it at, and I do not count what waking from sleep costs, which I have not measured. Both put the days higher than the board will give. - Build: every figure comes from a development build. On the welcome screen of an earlier build, a static screen, it drew about 0.5 mA more than the release build, which is the least it costs: a busier screen gives its logging more to do. I have not measured it again since, so this puts the days lower than the board will give. - Screen dark: I count the session's 50 dark seconds at the light-sleep figure, 27.0 mA, because the shipped firmware light-sleeps there, so this input does not move the days either way. - Keyboard light: it ships off and I do not count it. Whoever turns it on spends more on every keypress, so for them the days come out higher than the board will give. ## State by state, against the budgets What the board draws in each state it passes through, from asleep with the vault locked to the admin network up, every figure taken with the measurement system. The bar under each figure is on one scale for the whole page. Where the project set itself a budget, it stands beside the figure, and a figure over it says so in words. ### Locked and asleep **Draws** 3.93 mA measurement system Locked and left alone, the way the shipped firmware leaves the board. I took this figure with the USB cable left plugged in and its port switched off at the hub, and I print no margin for it yet. **Declared in the private repository** variants/tdeck/variant.h ### Screen dark, chip in light sleep **Draws** 27.0 mA measurement system Unlocked and idle with the screen off, the chip sleeping between one tick of work and the next: what the shipped firmware does here. **Taken at** 4,114 mV on the cell, screen off **Margin** ±0.31 mA, instrument only, one run **Record** [tdeck/light_sleep_idle_total/2026-10-29-01](https://kleidos.dev/data/power/tdeck/light_sleep_idle_total/2026-10-29-01.json) ### Screen dark, chip held awake: a diagnostic **Draws** 45.8 mA measurement system The same screen with light sleep held off from the development console, which no shipped build has. The shipped firmware light-sleeps here; I keep this figure because it is what the awake chip draws with the screen off. **Taken at** 4,067 mV on the cell, screen off **Margin** ±0.53 mA, instrument only, one run **Record** [tdeck/home_panel_off_total/2026-10-29-09](https://kleidos.dev/data/power/tdeck/home_panel_off_total/2026-10-29-09.json) ### The vault list, at the shipped brightness **Draws** 85.4 mA measurement system The list of credentials on screen at 85 percent, the brightness the firmware ships at. **Taken at** 4,054 mV on the cell, backlight at 85 percent **Margin** ±0.99 mA, instrument only, one run **Record** [tdeck/home_total/2026-10-29-32](https://kleidos.dev/data/power/tdeck/home_total/2026-10-29-32.json) ### The PIN screen **Draws** 92.6 mA measurement system **Budget** 20 mA over budget The unlock screen, waiting for the passphrase to be typed. I measured it at 100 percent brightness and the firmware ships at 85, so as shipped it draws less than this. **Taken at** 4,064 mV on the cell, backlight at 100 percent **Margin** ±1.07 mA, instrument only, one run **Record** [tdeck/pin_entry_total/2026-10-29-05](https://kleidos.dev/data/power/tdeck/pin_entry_total/2026-10-29-05.json) ### The typing screen, waiting for a computer **Draws** 121.1 mA measurement system **Budget** 50 mA The typing screen with the Bluetooth radio up and no computer connected yet. The project's 50 mA budget is for typing to a connected computer, which I have not measured, so I do not judge this figure against it. I measured it at 100 percent brightness and the firmware ships at 85, so as shipped it draws less than this. **Taken at** 4,030 mV on the cell, backlight at 100 percent **Margin** ±1.40 mA, instrument only, one run **Record** [tdeck/ble_typing_wait_total/2026-10-29-02](https://kleidos.dev/data/power/tdeck/ble_typing_wait_total/2026-10-29-02.json) ### The admin Wi-Fi network, nobody joined **Draws** 157.4 mA measurement system **Budget** 130 mA over budget The admin panel's access point up, with no computer joined to it. I measured it at 100 percent brightness and the firmware ships at 85, so as shipped it draws less than this. **Taken at** 4,022 mV on the cell, backlight at 100 percent **Margin** ±1.83 mA, instrument only, one run **Record** [tdeck/wifi_admin_total/2026-10-29-02](https://kleidos.dev/data/power/tdeck/wifi_admin_total/2026-10-29-02.json) Each margin is the measurement system's alone, for the one run behind its figure, with the shunt's tolerance assumed. The store holds repeat runs of some of these states, and I have worked out their spread only for the sleep figure, whose card prints no margin, so no margin here says where a second run would land. Measurement system: an [INA228](https://www.ti.com/lit/ds/symlink/ina228.pdf) in the battery wire, read by an ESP32-S3, with the USB cable left plugged in but its port switched off at the hub, so the cell alone powers the board. ## What the screen's brightness costs The vault list at each brightness level, so the setting can be weighed in milliamps. Each level is a measuring window of its own, taken in a different run from the vault list's figure above and at a slightly lower cell voltage, which is why the two readings at 85 percent differ a little. [Chart of measurement system readings](https://kleidos.dev/measurements/#method) What the board draws on the vault list at each brightness level I measured: one dot per level, on a milliamp scale that starts at zero. The firmware's setting starts at 10 percent, and I measured the levels below it too. The line only joins the dots, because I measured nothing between two levels, and every value is in the table folded under the chart. **0 %** Board draws: 51.5 mA **5 %** Board draws: 53.6 mA **10 %** Board draws: 55.6 mA **15 %** Board draws: 57.7 mA **20 %** Board draws: 59.7 mA **25 %** Board draws: 61.6 mA **30 %** Board draws: 63.6 mA **35 %** Board draws: 65.6 mA **40 %** Board draws: 67.7 mA **45 %** Board draws: 69.5 mA **50 %** Board draws: 71.7 mA **55 %** Board draws: 73.7 mA **60 %** Board draws: 75.7 mA **65 %** Board draws: 77.6 mA **70 %** Board draws: 79.7 mA **75 %** Board draws: 81.7 mA **80 %** Board draws: 83.7 mA **85 %** Board draws: 85.6 mA **90 %** Board draws: 87.6 mA **95 %** Board draws: 89.6 mA **100 %** Board draws: 91.7 mA From 0 to 100 percent brightness, the board draws 51.5 to 91.7 mA, and 85.6 mA at the 85 percent it ships at. At 0 percent the light is off but the panel is still awake; with the panel asleep and the chip kept out of light sleep, the board draws 45.8 mA. ## What the keyboard light costs What lighting the keyboard adds to the board's draw at each of its levels. I measured every level on the PIN screen against the light off just before and just after it, in the same run, so no figure is a difference between two runs. Each is the mean of 2.3 seconds with the light on, and it includes the little extra the rest of the board draws while the light pulls the battery's voltage down. [Chart of measurement system readings](https://kleidos.dev/measurements/#method) What the keyboard light adds to the board's draw at each level I measured: one dot per level, on a milliamp scale that starts at zero. The light ships off, so no level is ringed as the one it ships at. The line only joins the dots, because I measured nothing between two levels, and every value is in the table folded under the chart. The curve is one run; its margin at 100 percent is ±1.6 mA, with the shunt's tolerance assumed, and I have worked out no margin for the other levels. **5 %** Added by the light: 5.9 mA **10 %** Added by the light: 12.0 mA **15 %** Added by the light: 18.4 mA **20 %** Added by the light: 24.8 mA **25 %** Added by the light: 30.7 mA **30 %** Added by the light: 37.2 mA **35 %** Added by the light: 43.8 mA **40 %** Added by the light: 50.3 mA **45 %** Added by the light: 56.5 mA **50 %** Added by the light: 63.2 mA **55 %** Added by the light: 70.0 mA **60 %** Added by the light: 76.7 mA **65 %** Added by the light: 83.2 mA **70 %** Added by the light: 89.9 mA **75 %** Added by the light: 96.9 mA **80 %** Added by the light: 104.1 mA **85 %** Added by the light: 110.4 mA **90 %** Added by the light: 117.5 mA **95 %** Added by the light: 124.8 mA **100 %** Added by the light: 132.5 mA From 5 to 100 percent, the keyboard light adds between 5.9 and 132.5 mA to what the board draws with it off. Turned on, it lights at 50 percent for 8 seconds after each keypress until another level is chosen, and adds 63.2 mA while it is lit. ## How long an unlock and a backup take How long the board keeps a person waiting. I timed it with the board's own clock, not with the measurement system. Each column is the vault it held, in credentials and 2FA codes: the small vault that is the same on every board, then half of what this board holds, then all of it. **Unlock** From the passphrase entered to the vault list on screen 30 / 10: 2,867 ms 250 / 25: 3,446 ms 500 / 50, full: 3,496 ms **Of that, opening the vault** From the derived key to the vault open 30 / 10: 691 ms 250 / 25: 1,186 ms 500 / 50, full: 1,373 ms **Wrong passphrase** From the passphrase entered to its refusal 30 / 10: 1,617 ms 250 / 25: 1,702 ms 500 / 50, full: 1,564 ms **Encrypted backup to microSD** From its key's derivation to the last byte written 30 / 10: 6,201 ms 250 / 25: 13,464 ms 500 / 50, full: 16,413 ms The key derivation alone, at 175,000 iterations, takes 1,423 ms whatever the vault holds, since it opens none. Each figure is the mean of its repeats on the board's own clock, rounded to the millisecond: ten unlocks, four wrong passphrases and three backups at each size, and five derivations. The unlock, the vault's opening and the refusal are each the difference between two of the board's log lines, stamped to the millisecond; the firmware times the backup itself, in whole milliseconds; and the derivation alone is read off the chip's microsecond counter. The board's crystal is not marked, so I take its tolerance as ±10 ppm, the figure [the chip maker's design guidelines](https://docs.espressif.com/projects/esp-hardware-design-guidelines/en/latest/esp32s3/schematic-checklist.html#external-crystal-clock-source-compulsory) give. What the figures include and leave out: - I timed the unlock and the wrong passphrase from the moment the passphrase was complete. I sent its keys from the console, which skips the keyboard's own controller, so how long a person takes to type it is in neither. - The unlock ends when the vault list is first drawn, and includes the 500 ms the screen holds its success message on purpose. - The part of the unlock that grows with the vault is opening it once the key is derived. The rest changes from one vault to another too, as the wrong passphrase does, but not in step with their size. - The backup runs from the derivation of its own file's key, at 600,000 iterations against the unlock's 175,000, to the last byte written to the card. It leaves out the steps around it, among them closing the file and giving it the backup's name, and I have not timed those. - I timed all of it on a development build that keeps the console and the logging running, at the production work factor, with the board on USB power and its charger working: not the release build, and not on its battery alone as a user's board runs. Every span includes that build's logging. - I print the means. The store keeps a margin for each; where the repeats agree exactly, it keeps only the bound the clock sets, one tick and the crystal's tolerance. ## What I have not measured on it yet Each of these is a figure this page would print and does not, because I have not taken it yet. - The charge an unlock costs on this board: what the key derivation adds to the passphrase screen's draw. The test is written down and I have not run it yet. - Typing to a connected computer, which is what the project's 50 mA Bluetooth budget is about. The figure above is the typing screen still waiting for one. - The admin Wi-Fi network with a computer joined to it. The figure above has nobody joined. - The PIN screen and the typing screen at the 85 percent brightness the firmware ships at. I measured both at full brightness. - What the release build draws, on a busy screen. Every figure here comes from a development build, and I have measured what that costs only once, on the welcome screen of an earlier build. - How long an unlock and a backup take on the release build with the board on its battery alone. I timed them on a development build with the board on USB power. - What the cell really holds. The estimate uses the 2,000 mAh printed on it. - Three more sleep runs on this firmware: one with the USB cable unplugged, one with the card slot empty, and one an hour long. I took the three runs behind the figure as 20-minute sleeps, each with the cable left plugged in but its port switched off and a microSD card in the slot. When the sleep drew more, I measured it with the cable plugged in and unplugged, and the two agreed. ## Where these figures come from The first list names files in the repository, which I keep private while I prepare the first release; the second links pages you can open now. - The campaign that took every figure here, row by row: docs/testing/power-campaign-tdeck.md. - Where the current drawn asleep went, and what each fix to it saved: docs/research/peripheral-parking.md. - How a time on the board's own clock is stored, and what its margin is charged with: docs/testing/power-measurement-store.md. - Every figure from the measurement system is a record in qa/measurements/power/, in the private repository, with its margin and the build that ran. - [The LilyGO T-Deck Plus's measured values, one row each (CSV)](https://kleidos.dev/data/power/tdeck.csv) - [How the measurement system is wired, and what its margin covers](https://kleidos.dev/measurements/#method) - [How far this board's oscillator drifts through a sleep](https://kleidos.dev/measurements/#drift) - [This board on video, from its own screen](https://kleidos.dev/recordings/#board-tdeck-plus) The records behind the figures on this page are published as data under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/), byte for byte as the measurement store holds them. The CSV gives every value in them, with the address and the SHA-256 of its record, and each record that a card above names is linked from its name.