hardware · lilygo t5 e-paper s3 pro
LilyGo T5 E-Paper S3 Pro, the board we check ourselves against
ExplorInk boots on this board as of 31 August 2026, and an alpha build,
explorink-t5s3pro-v0.2.1-alpha, has been on it since 10 September 2026.
It is also the only board here that shows the satellite screen, because it is the
only one with a receiver: on the others the position comes from the phone.
It is a development board rather than a consumer product, and our build for it is an
alpha off a branch of its own, so treat it as such. We bought it to find out how much
of our firmware is really portable and how much of it quietly assumes the reader it
grew up on. This page says what the board is, what happened on the first day, what we
have measured on it since, and what LilyGo's engineers told us when we asked.
The alpha build is on the browser flasher, the fourth card
there next to the X4, the X3 and the X4 Pro. It is hardware-verified: four images
written with every hash confirmed, the board boots, and the double-tap touch lock works.
It comes off the board's own branch, release/lilygo-t5-s3-pro, which carries
input and panel work no other branch has yet, so it is a snapshot of that branch, not of
whatever develop looks like today. This is a touch-first board: two of its switches are readable from
firmware and both already have a job, so the map is driven from the glass here rather
than from keys. The development log is where a new build gets
announced the day one exists.
What the board is
The T5 E-Paper S3 Pro is LilyGo’s 4.7″ e-paper development board: an
ESP32-S3 with a big panel, a frontlight, a battery, a satellite receiver and a LoRa
radio on one PCB. Two of those parts are the interesting ones for us, and no reader we
own has either. Everything below is off
LilyGo’s
product page, their
board
repository (branch H752-01, which carries the schematic and the pin
map), or a mail from their engineers. Nothing in this section is our own measurement:
ours start further down, under the runtime and the first day.
- Panel
- ED047TC1, 4.7″, 960×540, 16 grey levels
- Glass
- anti-glare treatment, per the product page
- Frontlight
- warm-toned, one pin, PWM brightness only
- SoC
- ESP32-S3-WROOM-1, 16 MB flash, 8 MB PSRAM
- Satellite
- u-blox MIA-M10Q or Quectel L76K, depending on the unit. Sold with and without it
- Radio
- Semtech SX1262 LoRa, four band options: 433, 868, 915 and 920 MHz
- Battery
- 1500 mAh, with a BQ25896 charger and a BQ27220 fuel gauge
- Other
- GT911 touch, PCF8563 real time clock, TPS65185 panel supply, PCA9535 IO expander, microSD
- Recovery
- BOOT on GPIO 0, reset on the
ENpin, documented in their repo
Current pricing and stock are on LilyGo’s own shop page, and we are not going to restate a number that moves. They ship from a German warehouse, which is what made the board easy to get from here.
Why this board
The reader ExplorInk grew up on is an ESP32-C3 driving a 480×800 four-grey panel through an SSD1677 controller. There are development boards with that same controller and that same geometry, and buying one would have proved nothing about our code: the map style would have rendered unchanged and we would have concluded we are portable when we are not.
The T5 E-Paper S3 Pro shares almost nothing with it, and that is the whole point:
| Xteink X4, the reader we started on | LilyGo T5 E-Paper S3 Pro | |
|---|---|---|
| SoC | ESP32-C3, RISC-V, no PSRAM | ESP32-S3, 8 MB PSRAM |
| Panel | 4.3″, 480×800 | 4.7″, 960×540 |
| Grey levels | 4 | 16 |
| Panel driver | SSD1677 controller on the panel flex | controllerless glass, clocked straight from the SoC |
| Position | from the phone over Bluetooth LE | a receiver on the board |
| Input | physical buttons | capacitive touch |
| Frontlight | none | warm-toned, PWM dimmable |
The panel row is the one that costs work. Our reader has a controller chip on the panel flex that takes a framebuffer and runs the waveform itself. The ED047TC1 puts that job on the host: the glass carries row and column drivers, the SoC clocks a parallel source-driver bus and times the waveform in software, and a TPS65185 raises the five high-voltage rails in the right order. That is read off the panel specification. It buys a much larger, much faster panel than a controller could feed, and it is a different job from the one our display layer was written for.
Different resolution, different aspect, four times the grey levels, a different panel driver arrangement, a different power architecture. Nothing carries over by accident, which is exactly what we wanted from it. Anything in our map style that is secretly a pixel count for one specific screen will show up on this board as a hairline that disappeared or a label that no longer fits.
One part of it is not a test at all. The board carries its own satellite receiver, and a device that knows where it is without a phone in the loop is where this project is going. Today the fix arrives over a Bluetooth LE link from the phone, and that is a state we want to remove rather than a design we are proud of.
What their engineers told us
We wrote to LilyGo with the questions a port actually needs, and their engineering team has answered every one of them. The correspondence has stayed open and active ever since: the answers come back specific, with part numbers and figures, and several of them are the kind of detail that no product page carries for any board. That is the main reason this page exists, and it is a large part of why the port took days instead of weeks.
The frontlight is PWM on one pin, and there is a ceiling on the frequency. GPIO 11 drives a PT4103B23F LED boost driver, brightness is the duty cycle, 0 % is off and 100 % is full current, and the recommended PWM frequency is not above roughly 1 kHz. The pin is in their published pin definitions; the frequency ceiling is the part we would have had to find by breaking something, and they simply told us. Their answer also priced the light: about 20 mA on the 3.3 V rail at full current. Our own figure is larger, and the two are not measuring the same thing. Theirs is the LED driver at full current on the 3.3 V rail. Ours is the whole device off the cell: two rides on our firmware, 3 to 5 hours each, read 91.3 mA with the light off and 134.8 mA at 40 % brightness, so the light costs roughly 18 to 43 mA at the battery and takes the map from about 16 hours to about 11. An earlier version of this page concluded from their number that the frontlight is not the power problem on this board. That conclusion was ours and it was wrong: their figure was for the rail, we applied it to the cell. The light is worth about a third of the runtime.
Two different satellite modules ship on this board and you cannot tell which one you have by looking. Some units carry a u-blox MIA-M10Q, some a Quectel L76K, they look the same on the PCB, and they come up at different baud rates: 9600 for the L76K, 38400 for the M10Q. Hardcoding one of those in our bring-up would have been a bug that only appears on half the boards, in the field, silently, and we were about to do exactly that. Their example firmware already probes for it, so the fix was a port of code they had published rather than a design of ours.
The baud rate is the small half of it. The power is the large half. The L76K tracks at 29 mA and has nothing slower: its datasheet gives the same 29 mA for acquisition, its slowest fix rate is one a second, and its two low power modes are entered over pins that are not brought out here, so on this board a duty cycle has to come from the shared supply rail instead. The MIA-M10Q tracks at about 13 mA on the same supply, about 8 mA in its power save mode, and about 46 µA in a software standby it enters over the two wires the board already has. For a device carried all day that is the difference between a receiver you can leave running and one you have to switch off. Both sets of figures are datasheet typicals, neither is ours.
They also fixed their own repository on the strength of one of our questions. The real time clock is a PCF8563, their README named a different part, and the commit landing the correction is dated the same day we asked. That is a fast turnaround for a documentation report from a stranger, and it is the reason we sent them a pull request with the rest of what we had learned rather than only writing it up here.
Their sleep number, and why we have not made it ours
Their board repository documents sleep power the honest way: a photograph of a bench multimeter in series with the board. It reads about 873 µA in deep sleep, with the radios’ shared rail down, the light off and the panel powered off. Against 1500 mAh that is roughly 70 days idle, and it is a good number for a board with this much on it.
It is theirs, not ours. We have not reproduced it: we do not know the meter range, the firmware state or the board revision behind that photograph, and none of those is a criticism, they are simply things a reader of ours cannot check. So it stays credited to them and it is a target to measure against, not a figure we restate as our own. Every power number on the rest of this site came off our own device with our own firmware running, and the X4 findings page keeps them separate for the same reason.
Our own runtime number
A day of walking across Barcelona with the map open and the onboard receiver running gave us the first runtime figure off our own firmware. Two separate runs on the same day, one of 4.6 hours and one of 3.0 hours, both with the receiver on and the phone radio not started at all:
| Run | Length | Battery | Rate |
|---|---|---|---|
| Morning | 4.6 h | 4103 to 3922 mV, 100 to 75 per cent | 5.4 per cent an hour |
| Afternoon | 3.0 h | 4102 to 3974 mV, 99 to 83 per cent | 5.3 per cent an hour |
Two runs hours apart agreeing to within a tenth of a per cent an hour is what makes this worth writing down. On a full 1500 mAh cell that extrapolates to roughly 18 hours of map and satellite navigation. A later pair of rides read the same board a second way, off the fuel gauge’s own charge counter rather than off percentage slope, and came out at about 16 hours with the light off. Two instruments, two hours apart in the answer, and neither run was taken to empty.
What that number is not. Neither run was taken to an empty battery, so 18 hours is arithmetic on a discharge rate, not a measured endurance, and the last stretch of a lithium cell never behaves like the middle. The percentage comes from the board’s own BQ27220 fuel gauge, which we have never checked against a bench reference. The frontlight was off for both runs. And the panel was busy: the morning run spent about 49 minutes of its 4.6 hours redrawing, at about 1.08 seconds a refresh whatever the area redrawn. That cost is ours, not the panel’s. Our display layer never overrode the windowed-refresh call for this board, so every request to redraw a corner of the map pushed a whole frame, and most of what it spends is processor and memory traffic rather than time on the glass. Fixing that is our work and it is open. Until it is done, a quieter map lasts longer than this and a busier one less.
And it belongs to one of the two variants. Our board carries the L76K, which its boot log names outright. The same firmware on a board with the MIA-M10Q would run a receiver drawing around 16 mA less, and against this run’s 83 mA average that is about a fifth more runtime. That last step is datasheet arithmetic, not a second walk: nobody has run this firmware on an M10Q board. Until somebody does, the 18 hours is the L76K number.
We are publishing it anyway, with those caveats attached, because it is the first figure for this board that came from our device doing the thing the product is for, rather than from a photograph of somebody else’s multimeter.
The first day
The board arrived in the morning and ran our firmware the same day. What worked straight away:
- It boots and draws. Home screen, touch, the SD card, Bluetooth, and the CPU dropping to 80 MHz when idle.
- The frontlight is even. Bright across the whole panel, not a strip down one edge, which was an open question until the board was in a hand.
- The map draws. 960×540, with the tiles under it arriving over Bluetooth from the phone with nobody driving it: the app woke on the advertisement and a 461 kB tile transferred and verified.
What is not there yet, and this is the part that matters:
- The map could not be driven fully. On the first day a finger opened the map menu from the top edge, Zoom in and Zoom out lived in that menu, and panning and the look-ahead were out of reach: the one readable user button was already the map's down control and every other switch had a job. That is no longer where it stands, see the buttons table below.
- The chrome is the wrong size. Header, compass and scale bar are drawn at the pixel sizes of a smaller, coarser panel, so they come out small here.
- A full map redraw took about 2.7 seconds on the first day, against a few tens of milliseconds for the plain screens. Most of that is our renderer drawing four times the pixels it was written for, not the panel.
- Open: what the panel does when direct sun hits it during a refresh, and what the board really draws while riding.
So it is first light, not a port. What has since changed: the flasher now carries a build for this board, see above.
The next morning, in the sun
This answers half of the open question above, and only half. Reading the panel in direct sun is fine: the map holds its contrast with no light of its own, which is the whole reason the project is on e-paper. Refreshing it in direct sun is the part still open, and we have seen a refresh come back blank in strong daylight on another panel. That is measured separately and it is not settled by a photograph.
The glass is part of that reading: a windscreen cuts most of the ultraviolet and some of the infrared, so this is one morning, one sun angle, behind laminated glass. Open air is shot now, in the section below. Direct sun with no glass in front of it still is not.
The mount is a car dashboard because that is what was to hand. It shows where you are and what is around you, which is what the device does. It is not turn by turn, and there is no route in it.
On a tank, in open air
This is the same board and the same firmware, outdoors, with the panel facing the open sky instead of a windscreen. Everything on it is real: the place name in the header, the battery at 64 per cent, the 100 metre scale bar, a position marker, the north indicator turned off vertical because the map is drawn track up, and two pins that are off the edge of the map and so are drawn at the edge with their distance beside them, one of them 1,418 km away. The four labels along the bottom edge are the physical buttons under them, which is how the whole device is operated. There is no touchscreen and there is nothing to swipe.
The Bluetooth indicator in the top corner is crossed through, so no phone was connected while the panel held this frame. What the photograph does not say is where the fix came from. This board has its own GNSS receiver, and the map can also draw the last position it was given, restored from the card at startup. One picture cannot tell those two apart, so we are not claiming which one it was.
The mount is worth a sentence because it is not ours. It is a clamp sold for phones, with a wrist strap through it, bought off a shelf. Nothing here is 3D printed and nothing was fitted to the bike.
A motorcycle is a place where a map gets read, not what this device is for. The frame is the point: a still map, a dot on it, and a rider working out where they are. No route line, no next turn, no voice.
The hardware test matrix
The same discipline as the X4 findings page, applied to a board that has had a fortnight of bring-up instead of months. Done means run on this real board with our own firmware, even if the review that followed found bugs in it. Open says what is missing, sometimes with a note on how close it is. Blocked means the test needs something this project has ruled out on purpose. A vendor’s own number, on their own firmware, is never marked done here: it is stated as theirs, separately.
Boot and bring-up
| Test | What it proves | Status |
|---|---|---|
| Cold boot to the home screen | the firmware starts on a chip family it has never run on before | done, the day it arrived |
| Touch input reaches the firmware | the touch layer, new to this codebase, is wired correctly | done, works |
| SD card read | tiles can load on this board at all | done, works |
| Bluetooth advertises and a phone connects | the radio stack survives the port to an S3 | done, works |
| CPU drops to 80 MHz when idle | the low-power floor engages here too | done, works |
| The board restarted once while the map menu was opened and closed repeatedly | a stability question a new port has to answer before it is a real target | explained, and not the board. A second restart the next day, on the same code path, was traced from a coredump to a null callback in the Bluetooth stack’s own shutdown. It is an upstream defect in NimBLE-Arduino that our firmware triggers on every map exit, reported upstream with a one-line fix, which upstream merged. The 31 August dump had already been overwritten, so the two cannot be proven identical, but the signature matches. |
| A published, installable build | a stranger could put this on their own board | done: explorink-t5s3pro-v0.2.1-alpha published, hardware-verified, live on /flash/ |
Buttons and input
| Test | What it proves | Status |
|---|---|---|
| Every physical switch, read one by one against the schematic | which switches the map screen can actually use | done: BOOT is power, RST is a hardware reset the firmware never sees, PWR sits on the charger’s ship-mode pin (several presses tripped full shutdown), and the one real user button is already wired into the map’s down control |
A fifth, silkscreened switch (IO48) | whether a spare button exists for a frontlight toggle or similar | done, ruled out: it is the panel’s own clock line, not a button; wiring it in misfired on every touchscreen swipe and was reverted the same day |
| Pan and look-ahead, reachable without a spare button | whether the map can be fully driven at all on this board | done, checked by hand on this panel 10 September 2026: a buttons-only touch mode draws the six labelled boxes and each one acts as the physical key it names, so every map control has somewhere to tap. Panning, the look-ahead, the zoom ladder and the menu were all used by finger on the board |
| The two readable switches, each doing something useful | whether a gloved thumb can leave a screen and reach the light without the glass | done: a short press on the power button steps back and a long hold sleeps, so the two are told apart by feel. The other button walks the frontlight through its levels while held, one step every half second, and stops where the thumb lets go |
| Zoom from the touch menu | the navigation control the board had before the buttons-only mode existed | done, works |
Onboard GNSS
| Test | What it proves | Status |
|---|---|---|
| A 3D fix, satellites in view and used, indoors | the receiver and the NMEA parser work at all | done, first afternoon: 8 satellites used, 19 in view, best signal 32 dB-Hz |
| Wall-clock time delivered before a position fix | the receiver is useful even mid-acquisition | done, works |
| A UTC date rollover at midnight, a 32-bit time overflow in 2038, a satellite-count double-count, a rail left powered on a failed enable | the driver survives review, not just a first fix | done: all four found by an adversarial review and fixed on the branch, ahead of any merge |
| Cold-start current and duration, cleared almanac | the worst case a duty-cycled design pays on every wake | open: needs a meter in series with the receiver |
| Warm-start current and duration, fresh ephemeris | the number a low-duty background fix actually costs | open: same rig as above |
| Continuous tracking, steady state | the standalone-only floor, no phone in the loop | open: same rig |
| Whether the receiver keeps ephemeris across a full power-off | whether duty-cycled GNSS gets the cheap warm-start price or the expensive cold-start one on every wake | open, and it has to be answered before the duty-cycle design, not just measured after it |
| Merge the driver branch and ship it | the feature stops being a demo | done: merged into release/lilygo-t5-s3-pro and published in explorink-t5s3pro-v0.2.1-alpha, so a stranger flashing this board gets the receiver |
| Time to a first fix, measured rather than quoted | whether a rider can open the map and expect a position | done, measured, and the answer is bad: 526 s from boot on one ride. That is our test setup, not the board. The device sat on a car dashboard behind a windscreen, which is close to the worst place to put any receiver, and the same unit sees 8 to 9 satellites on a desk indoors. It needs re-running in open air before anything is concluded about the module |
| A screen that says why there is no position yet | the rider can tell "wait" apart from "go and stand somewhere with sky" | done: the satellite wait screen draws the sky the receiver hears, azimuth across and elevation up, over a horizon line. Judged against a synthetic sky on the bench because five outdoor passes produced no usable acquisition; the drawing is verified, a real acquisition behind it is not |
Display and power
| Test | What it proves | Status |
|---|---|---|
| Map draws at this panel’s native 960×540 | the renderer’s portability claim, on a second panel | done, works |
| Frontlight, evenness across the panel | no dark strip down one edge, an open question until the board was in hand | done, even |
| Header, compass and scale bar sized correctly for this panel | the chrome is legible, not shrunk to a smaller screen’s pixel count | open: currently drawn at the X4’s pixel sizes |
| Full map redraw timing | whether this panel’s size and driver cost more per frame | done, measured: about 2.7 seconds on the first day, and about 1.08 seconds a refresh over a long walk since. Both are our renderer and our display layer, which pushes a whole frame even when the map asks for a corner. Reducing it is our work, and it is open |
| Panel behaviour in direct sun during a refresh | the X4 has a known daylight-refresh failure; whether this panel shares it | partly answered: several days of use in daylight and it has not happened here. Observed, not measured, and no stencil test has been run on this panel, so the X4 result is not yet ruled out as a panel-specific fault |
| Deep sleep, radios and panel off, on our own firmware | the idle floor for this board, from us rather than the vendor | open for us: the only number that exists is LilyGo’s own bench reading on their factory firmware, not ours, ~873 µA (see above) |
| Any runtime number on our own firmware, any mode | a number this project can actually stand behind | done, measured: 5.3 to 5.4 per cent an hour across two runs, map open and receiver on (see above) |
| A run taken to an empty battery | endurance measured rather than extrapolated from a discharge rate | open |
What we have sent back
A vendor answering a stranger’s questions in this much detail is doing unpaid work, so the exchange only stays fair if it runs both ways. What has gone back to them so far:
- A documentation pull request, merged. #29 writes the two GNSS baud rates, the two receiver variants and the frontlight PWM ceiling into their own repository, so the next person on this board finds them without having to write a mail. They merged it.
- The baud-rate probe, published. Our port of their detection code is open source in our firmware, on the branch this board’s build comes off.
- A fix to a third party, not just a report. The Bluetooth crash in the boot table turned out to be in the NimBLE host stack rather than in anything on this board. We traced it from a coredump, filed the report and sent a one-line pull request, and upstream merged it. Anyone running Bluetooth on an ESP32-S3 gets that fix, this board included. It is not in a tagged release yet, so our own builds still carry it as a pinned fork.
- Measurements, still owed. Frontlight uniformity, partial-refresh timings on the ED047TC1, and how the panel behaves in the cold. Each one is a number we have promised them before we publish it, and each one needs an instrument or a second board we do not have yet. They are the next thing on this list, not a vague intention.
LilyGo supports our development. Their engineering team answers our questions, and they are putting a board of their own behind it. We are not paid to write about them, no link on this page is an affiliate link, and every finding of ours goes to them first with a fair window to respond before it appears here. Nothing gets suppressed and nothing waits indefinitely. We would rather have this board and this correspondence than a board that told us nothing, and we intend to keep both going.
Where the board and its source live
Both of the first two links go to LilyGo.
- The product page and shop: lilygo.cc, T5 E-Paper S3 Pro. Variants with and without the satellite receiver, and four LoRa bands.
-
Schematic, pin map and example firmware:
github.com/Xinyuan-LilyGO/T5S3-4.7-e-paper-PRO.
The
H752-01branch is the one carrying the schematic PDF and the pin definitions we read. - Our own alpha release for this board: explorink-t5s3pro-v0.2.1-alpha on GitHub, or use the browser flasher, which always carries the current build.