hardware · lilygo t5 e-paper s3 pro
LilyGo T5 E-Paper S3 Pro, the board we check ourselves against
ExplorInk does not run on this board. Not a supported device, not a download, nothing to install. It is a development board we bought 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, why we picked this one, and what LilyGo told us that their own pages do not.
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 here is our own measurement, because we
have not had the board on the desk yet.
- 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, and not one closer to ours
The reader ExplorInk runs on today is an ESP32-C3 driving a 480×800 four-grey panel through an SSD1677 controller. There are development boards with exactly that controller and exactly that geometry, and buying one would have proved nothing: our map style would have rendered unchanged and we would have concluded we are portable when we are not.
So the rule we set was to buy the most different board we could still run:
| Our reader today | 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 | no controller: the SoC drives the glass itself |
| Position | from the phone over Bluetooth LE | on the board |
| Input | physical buttons | capacitive touch |
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 has no controller at all: the glass carries row and column drivers and nothing else, so the host clocks a parallel source-driver bus and times the waveform in software, with a TPS65185 raising the five high-voltage rails in the right order. That is read off the panel specification, and it is a different job from the one our display layer does now.
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 the whole reason to own 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 that no page of theirs says
We wrote to LilyGo in August 2026 with the questions a port actually needs, and they answered twice. Two of the answers are not in any public document of theirs, which is the main reason this page exists.
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. Their pin definition file gives the pin and says nothing about how to drive it. Their answer also priced the light: about 20 mA on the 3.3 V rail at full current. Against the 1500 mAh cell that is on the order of 80 hours of light, arithmetic off their two numbers rather than a measurement, and it reverses an assumption we had carried for months. On this board the frontlight is not the power problem.
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. A fixed baud rate in a bring-up is a bug that only appears on half the boards, in the field, silently. Their own example firmware already probes for it, which turned this from a design question into a port.
They also corrected their own repository for us: the real time clock is a PCF8563, not the part their README lists.
The one number we have, and whose it is
Their board repository has a sleep power section whose whole content is a photograph of a bench multimeter wired in series with a bare board. The display 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.
That is read off a vendor photograph, not measured by us, and it is the only power figure on this page. We have not confirmed the meter range, the firmware state or the board revision. It is a sanity check to measure against later, not a specification. 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.
What has not happened yet
All of it. To be exact about what “not supported” means here:
- No ExplorInk build for it. Our firmware has never been compiled for this board, let alone flashed to one.
- No renderer output. Nothing on this site was drawn at 960×540, and our map style has never been judged on a 16 grey panel.
- Nothing on this page is our measurement. Vendor page, vendor repository, vendor mail. That is the whole sourcing.
- Open on our side: how even the frontlight actually is, which satellite module our unit carries, what the panel does when direct sun hits it during a refresh, and what the board really draws while riding.
When the port runs, it gets said here, and the install page is where a device appears once you can put our firmware on it. Until then this page is a description of somebody else’s hardware and an honest account of why we bought it.
Where the board and its source live
Both links go to LilyGo, and neither one is an affiliate link.
- 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.