The hardware: an off-the-shelf reader, not a dev board

The devices we work with

What the builds cover today

Three binaries. One covers the X4 and the X3, which are ESP32-C3. The second covers the X4 Pro, which is an ESP32-S3 with touch, a frontlight and eight megabytes of PSRAM, so it is a second build, a second install and a second test pass rather than a flag on the first. What we measured on it. The third is the alpha for the LilyGo T5 E-Paper S3 Pro, a development board rather than a product target, and it comes off a branch of its own.

Xteink X4 and X3, from the same build. Both are ESP32-C3 and share a pinout. They differ in panel controller (X4 is an SSD1677 at 800×480, X3 a UC8253 at 792×528) and in battery backend. The running firmware picks its own profile by probing the X3-only I2C chips (fuel gauge, RTC, IMU) twice and scoring the hits, so there is one binary, one flash path and one test pass for two devices.

The X3 half of that stopped being theory on 9 September 2026. A real X3 took the build, booted, named itself off the probe with nobody telling it which model it was, mounted its card and drew a city at 528×792. What that pass did not settle: which panel controller this unit carries, whether its fuel gauge reads, and how the panel behaves in sun. It also found three layout faults that never show on an X4, because the chrome is tuned to a screen 48 pixels narrower and 8 taller: the button hints run off the bottom and both sides, the scale bar and the place name share pixels, and the north arrow sits on a hint box. The X3 page has that session’s numbers, a frame off the panel with both faults in it, and why the device is not called supported yet. The install page keeps that list honest per device.

The X4 is the device every measurement on this site was taken on. The X4 findings page has the numbers: refresh timings, heap, what the panel does with grey.

The X4 specification we designed against

Panel

4.3″ e-ink, 480×800 as the renderer sees it, 220 PPI, no touch

Refresh

500 ms fast (differential), 1,684 ms clean whole-panel, measured, waveform only

Grey

4 levels: black, dark grey, light grey, white. The map does not use them

SoC

ESP32-C3, RISC-V, WiFi and Bluetooth 5 LE, one radio at a time

Heap

247,156 bytes total; 58,540 free with the map screen and BLE up, measured

Storage

16 MB internal flash; map tiles live on a separate SD card

Input

Physical buttons only. A design premise, not a limitation: gloves

Recovery

USB serial, esptool, full flash backup and restore

Every one of those numbers pushes back on the software. A quarter of a megabyte of heap is why the BLE stack is torn down when you leave the map screen: bringing it up costs 57 KB of it. The four-grey panel is why the map is dithered instead of shaded. The buttons are why there is no touch UI to design. And the 1,684 ms refresh is why the map is a still picture with a moving marker: how it works follows that decision through the whole chain.

WiFi or the map, never both

The device runs one radio at a time. WiFi and the map screen are mutually exclusive in practice, so everything that has to work while riding goes over Bluetooth LE: position packets, the command console, and map files pushed onto the SD card. The BLE bridge is the whole wireless story on the trail.

Buttons, not a touchscreen

Four physical buttons drive everything on the map: zoom in and out, marker height, a menu behind the middle button, and a long press for zoom while panning in observation mode. This is deliberate. Wet or gloved hands cannot use a capacitive panel reliably, hiking in the rain or riding in the cold both included, and a display you have to look at closely to operate is the wrong display to check at a glance.

What a second device actually costs

Adding X3 alongside X4 was nearly free, because the two are the same machine with a different panel. The next device is not that cheap:

• X4 Pro. An ESP32-S3 with its own panel bus, a capacitive digitizer and 8 MB of PSRAM. That is a second binary, a second test matrix and a UI premise (buttons) to revisit. Released and run on a real unit on 9 Sep 2026: it boots, the panel draws, the SD card mounts, touch and the home key and the frontlight all answered, and one map frame rendered in 1,183 ms. Still open on that pass: the frontlight at boot, its PWM frequency on this board, switching touch off from the menu, and what the heap does over a long session.
• A board that shares nothing with ours. We bought a LilyGo T5 E-Paper S3 Pro for exactly that reason: another SoC, another panel, sixteen greys instead of four, and a satellite receiver on the board. It is a validation board and not a product target. Our firmware booted on it and drew a map on 31 August 2026, and there is an alpha build for it on the flasher since 10 September 2026, hardware-verified, with the board’s own GNSS receiver feeding the map. It is still a development board and we do not support it the way we support a reader you can buy: it comes off its own branch, and only two of its switches are readable at all, so most of the map is driven from the glass.
• Anything without our refresh control. The value here is a panel driven deliberately: partial refresh, chosen waveform, a redraw only when the map has to change. A device that does not let us choose those is a worse product than the C3, whatever else it can do.

The real cost of a second target is not writing the code once. It is that every release from then on needs two builds, two flashes and two passes on real hardware, forever. That bill is now being paid: since 9 September 2026 a release means a C3 build for the X4 and the X3 and an S3 build for the X4 Pro, each flashed and each run on its own device before it ships. A third target waits until it is on the desk and until a stranger can install the two that exist.

What is not tied to any device

The map renderer is not ESP32 code. The same MapRenderer sources build as a host binary with CMake and g++ through a canvas seam. The device passes its real GfxRenderer, the laptop passes a PPM writer. That binary runs every time somebody edits the map style, so the portability is exercised daily rather than claimed. The .tib tile format, the index, the freshness rule and the route file are format-level too, with no device in them.