ExplorInk: e-ink maps for exploration, online or offline

in the world

Photographs of it in use, not renderings.

A hand in a city square, a cafe table, a bar, a fuel tank, a dashboard, a desk, morning sun through a windscreen. Every one of these is a camera pointed at the panel while somebody was reading it, and what is on the screen is whatever the device was drawing at that moment. Click one for the full photograph.

An e-ink reader held flat in one hand in a sunlit Barcelona square, its panel showing an ExplorInk street map of Ciutat Vella with a position dot, a pin at 12 km and a 500 m scale bar, the arcade and palm trees of the square out of focus behind it — In a hand, in a city, in full sun. Carried on a strap, not mounted to anything.

The same e-ink reader lying on a dark wooden cafe table beside a camera bag, its panel filling the frame with an ExplorInk map of central Barcelona in which every street of the Eixample grid is legible — On a cafe table between two walks. Every street of the grid resolves.

The LilyGo T5 E-Paper S3 Pro held by a black clamp mount on the fuel tank of a parked cruiser, its panel showing an ExplorInk street map with a position marker, pins at the edge and the button labels along the bottom — On a fuel tank, open air. Nothing 3D printed, nothing fitted to the bike.

Xteink X4 in a bar mount on a motorcycle handlebar, chrome headlight and speedometer beside it, the panel showing a city map with the place name and clock along the top — A motorcycle bar, an overcast morning. No backlight and no sun shade.

The LilyGo T5 E-Paper S3 Pro clipped to a car dashboard mount in direct morning sunlight, its panel showing an ExplorInk map with every line legible and no backlight — Sun straight on the glass, frontlight off. Nothing on the screen washes out.

Xteink X4 held on a magnetic car dashboard mount next to the car's own navigation screen, showing a schematic map with a position marker and the button labels — A car dashboard, beside the car’s own navigation screen.

The LilyGo T5 E-Paper S3 Pro standing on a desk with its frontlight on, showing an ExplorInk map of central Bratislava with the Danube across the middle, a position marker, a compass and a scale bar — Our firmware on somebody else’s board. The panel reads warm because the frontlight is on.

The freedom of a paper map, plus a dot that knows where you are. Drop a Camp pin and when it goes off the screen you get an arrow at the edge pointing at it, with 23 km under it.

It does not give directions. No routing, no voice, no rerouting: miss a turn and you notice it the way you would on paper, by looking. What it replaces is the phone as your screen. The phone stays in your pocket, sending its GPS fix over Bluetooth, and stops being the thing you look at.

The map has no edge. No region packs to pick and manage. Switch auto-sync on and moving onto a square nobody has built is the request: the reader asks the phone, the public tile server builds it inside five minutes, and it draws while you keep moving. New ground needs the phone to have signal at that moment. Everything already on the card stays readable with no signal at all, and the reader’s sync screen fills in the squares it noticed were missing while you were out, at home, over a real connection. Both, not one or the other.

It runs today, on real hardware: firmware on three readers now, the app on the phone in your pocket. Every screen on this page came off a real panel, except the one tagged preview, which says so.

Built on CrossPoint Reader. Map data © OpenStreetMap contributors.

01 · why e-ink

A phone is a bad map when you need it open all day.

The screen washes out in direct sun. It cooks in a mount. The battery you also need for photographs and a phone call is the one running the screen. A motorbike makes every one of those worse and adds vibration, gloves and rain, which is why this started there, and a phone strapped to a bar bag on a long walk fails the same way. E-ink has the opposite properties, and one hard cost you have to design around.

What a day in a mount does to a phone	The detail
Heat. Apple’s own spec says an iPhone is made for 0 to 35 °C ambient	a dark mount in full sun sits above that, and the phone throttles to protect itself (Apple’s note)
Vibration. Apple says it plainly about its own hardware	engine vibration can permanently damage the camera’s stabilisation, and the repair is a few hundred euro (Apple’s second note)
Gloves. Capacitive glass does not answer through winter gloves	you stop, or you take a hand off the bars
Water. The mount is fine until the charging port is not	an adventure riding school names water in the USB charging port as the first thing to die
Battery. The phone is also your camera, wallet and emergency call	screen-on navigation is what empties it

Readable in daylight

Reflective panel, no backlight to wash out: it reads by the light already falling on it, the way paper does. Glance, done.

All day, and then some

The panel needs no power to hold a picture: current goes into changing it. The electronics still cost something, so with the map open and a phone linked the battery drains 3.9 % an hour, which is about 25 hours on a charge. We quote 10 h+ publicly, because that comes off days out rather than a bench test. Tens of hours, not a phone-screen afternoon.

Slow, and grey

A clean refresh takes 1,684 ms, a fast one 500 ms, both measured on the panel. Four grey levels cost an extra waveform pass. That rules out a moving map.

So: a still picture

Position, route, surroundings: redrawn rarely, readable at a glance at speed. No rerouting, no voice, no traffic. The route is planned before you leave.

Free, and yours to install today

Firmware for the reader, the app for your phone. Both open source, both a real download, no account.

Download and install

Side by side with a phone, a Beeline and a Garmin, our own gaps included: how it compares. Rain, a dropped link, no phone at all: the FAQ answers those.

The panel numbers, and what they force on the renderer, are on drawing a map on e-ink; the hardware they were measured on is on the hardware page.

who it is for

Made for exploring, honest about each use.

One device, many ways to travel. What they share is the reason for carrying it: you are exploring, not following a line. The status of each use is different, so here it is without the sales gloss.

A city, on foot

The use this is built for now. You walk, you turn on what you see, and the reader says which quarter you are in and where the hotel is. Town, village and quarter names draw on the panel today. Street names and the practical places, a toilet or a drinking fountain, are built in the map data but have never run on a device, so they are a plan and not a feature.

Hiking, and the terrain half is new

Tens of hours on a charge and light in a pocket suit walking well. Contour lines with height numbers, rock faces, path difficulty and waymarked routes are built and in the map data as of this week. They have not been looked at on a panel yet, so how well terrain reads in the hand is still an open question rather than a claim.

Travelling by car, bus or overland

A second screen that does not steal the phone: the map stays open for hours while the phone keeps its charge for the camera and the calls. Abroad it draws from the card with no roaming, and the country you are crossing gets built as you reach it, whenever the phone has signal. Both halves have been run on the road: a thirteen hour day that ended with a Prague to Bratislava drive, and a drive across ground the map did not cover, where two of the four missing squares were built because the reader asked for them and drew a minute later, while it kept moving.

Motorcycle adventure and trail riding

Where the project started, and the mount is solved: dash or bar cradle, gloves on the buttons, ride and hike and cycle road filters, a route framed whole before you set off, pins for camp and fuel. Tested on a real bike.

Bikepacking and gravel

Same needs, a different mount. An ordinary phone bar cradle holds it, which is what the motorcycle shots use, but nothing has been ridden far enough on gravel to say what shakes loose. Everything on the screen already suits a long day at 20 km/h.

02 · the screen

Real framebuffers, not mockups.

The ones tagged device came off the panel over USB: send a coordinate and the device draws what is around it from tiles on its SD card. The one tagged preview is the same renderer running on a laptop against the same tiles, which is how styling gets tuned without reflashing. We keep the two labelled apart on purpose.

device home screen

X4 panel drawing a town: outlined buildings with dithered interiors, hatched forest, roads of different widths — device buildings, 960 ms

X4 panel at wider zoom: the village as a single stippled built-up area with hatched forest around it — device built-up, 611 ms

X4 panel showing a planned route as a thick black line winding through the Male Karpaty hills, past Malacky, Stupava, Marianka and Svaty Jur — device whole route, 3981 ms

X4 panel showing a list titled Load a route: four saved routes with their point counts, and a highlighted one selected — device route list, 4 on the card

X4 panel over a dense city of individually drawn buildings: a meet pin, a numbered landmark pin marked 1, a parking pin near the position marker, and a far-off favorite pin shown at the edge as a heart icon reading 1254 km — device pins, near and far

X4 panel drawn track-up over a motorway interchange: the north indicator rotated to the upper right, the position marker's arrow pointing up — device track-up, 558 ms

X4 panel at 45 metres per pixel: a road network winding through a large hatched forest area, dots marking villages along the roads, a small position marker near the centre, scale bar showing 5 km — device whole range, 45 m/px

X4 panel at 45 metres per pixel with ten place names on it: the nearest town in bold, villages lighter, each name outlined in white over the hatched forest and the road network — device place names, 45 m/px

X4 panel showing a city map with a status row along the top: the place name Smíchov on the left, then the time, a Bluetooth icon with signal bars, and the battery percentage — device clock + battery, once a minute

Preview render with landuse and water areas — preview landuse + water

Development board panel showing the Finding the sky screen: satellite marks spread across an open sky above hand-drawn mountains, a compass row reading S W N E S under the horizon, and satellite counts with a signal meter below — device finding the sky

Honest caveat: the device renderer follows most of the style spec now: road widths and casings, buildings, forest, built-up, filled water with waves, and railways as a blocked line all draw on the panel, and the route draws with them, and so do place names. Junction dots exist in the spec, not yet on the glass, and neither do the edge markers for a village just off the screen. The laptop preview is the other way round for the route: it renders everything here except the route line, so that one is judged on the device only.

How the names get on the glass without blanking out the map: place labels on a one-bit panel. Why the map stands still while the marker moves: the track-up map.

03 · how it is built

Four parts. All four exist.

01

Map builder laptop

Fetches an area from OpenStreetMap, projects and clips it, routes along real roads, and writes binary .tib tiles at three levels of detail. A browser tuning tool renders a pixel-exact 480×800 preview, so the styling gets judged as e-ink instead of as a pretty vector map. How the tiles are built.
02

Tile server tiles.explorink.com

The built maps are on a public server, so nobody has to run the map builder to go riding: the phone downloads the squares the reader is missing, one plain file per square, and reads a small index to tell an empty square from one nobody has built, and a square that has gone out of date from a current one.

It also builds what it does not have. A square that comes back missing is written to the server’s own log, and a builder on the host takes the ten most-asked-for squares of the last day and builds them from OpenStreetMap straight into what it serves, usually inside five minutes for a 13 by 13 km area. Nothing already published is ever rewritten, and the day is capped, so an unattended builder cannot run away with the disk.
03

Firmware ExplorInk, on the reader

A fork of CrossPoint Reader, MIT licensed and public. Map screen, BLE position receiver, tiles off the SD card, zoom and marker height on the physical buttons, ride / hike / cycle filter, pins, and a command console over USB serial and BLE. The e-reader stack comes out; maps go in. Source on GitHub.
04

Phone app Android · iOS planned

Sends the phone's GPS fix to the device over BLE every few seconds and records every fix and packet for replay. One window, no settings screen, foreground service: it keeps sending with the phone locked in a bag. It touches GPS only while the reader is actually connected, and shuts itself down a few minutes after the reader goes away. The reader opening its map starts it again. It is also the reader’s way to the tile server. What the phone app does, and where iOS stands, how the BLE bridge works, or the app source.

OpenStreetMap map builder laptop, or the server itself tile server tiles.explorink.com phone over BLE SD card .tib tiles e-ink panel phone GPS over BLE

The whole chain, part by part: what each piece hands the next one, and why it is split this way.

what it costs

You will never pay to read a map.

Outdoor mapping is a subscription business. Offline maps, the one feature that matters when there is no signal, usually sit behind the paid tier: onX Backcountry lists $30 to $100 a year across its two tiers, and that is one app, forever. Abroad without downloaded maps you pay again in roaming.

The software is free and open

Firmware and phone app, MIT licensed, source public. No account, no login, no trial.

The maps are OpenStreetMap

No licence to buy, no region to unlock. A square on your card is yours, offline, forever.

If we ever charge, we will tell you what for

Building and hosting tiles on our servers costs money every month. A paid tier, if it comes, covers that: priority builds and hosted access. Never the firmware, never the app, never a map already on your card.

04 · status

What works today.

A working prototype, in active development. Formats, the render spec and the BLE protocol still change without notice, so do not build on them yet. The short list of what is on the device now:

Firmware: map screen drawing OSM tiles off the SD card, on real hardwareworks
Firmware: BLE position receiver; the phone app sends the fix and records the rideworks
The marker follows the fix; the map only redraws when it has toworks
Seven zoom rungs, 1 to 45 m/px, on the physical buttonsworks
Track-up or north-up map, with the north indicator turning with itworks
Town and village names on the map, outlined in white, kept off the routeworks
Routes: build one from waypoints, a GPX file or a recorded ride, and see all of it at onceworks
Public tile server, live: maps served square by square, so nobody has to build oneworks
Missing squares fetched mid-ride: the device asks, the phone brings them over BLEworks
The tile server builds what riders ask for, unattended, and the square is usually on the server inside five minutesworks
Pins (park here, camp here) saved at your position and still there after a rebootworks
Phone app: read, save and delete the reader's pins from a coordinate, a geo: link or a shared map linkworks
Open the map and the phone starts sending on its own, app closed, nothing tappedworks
Downloads: firmware images and the Android APK, with an install guideworks
Tile server: builds the version-4 tile format, and keeps serving version 3 for readers still on the older firmwareworks
Nearby: water, shelter, huts, fuel, medical and a way out, searched 25 km around you and drawn on the mapworks
A pin off the edge of the screen still says which way it is and how farworks
Phone app: queue a whole area before you go, resumable if the link dropsworks
Contour lines, height numbers and rock faces on the hike map, built and not yet seen on a panelon the bench
Route following and off-route warning on the deviceplanned
Renderer: junction dots and off-screen place markersplanned
A packaged release: one-click installer and a signed appplanned

That is the short list. The full status list is on the development page, item by item, next to the dated log of when each one landed. Everything marked works is on a reader you flash yourself today.

05 · development log

Recent work, newest first.

9 Sep 2026
A download for a third reader, and the first one on a different chip

The Xteink X4 Pro has a firmware build of its own now, next to the one for the X4 and the X3. It is a second binary rather than a wider one, because that reader is an ESP32-S3: a separate download, four files instead of three, and a cable most people have not thought about, since the device has no USB socket and puts its data on the pogo pins. What is published is the exact image that ran on a real X4 Pro that morning: panel, card, touch, home key, frontlight, and a map frame in 1,183 ms.

The install page, per reader
9 Sep 2026
A second reader runs our firmware, and the map drew a city on it

An Xteink X3 took the build for the first time. It boots, works out which model it is with nobody telling it, mounts its card and renders at 528 by 792. Tiles arrived over Bluetooth at about 6 kB a second, which is slow enough to say out loud: a detailed square is half a megabyte. Three pieces of the chrome sit wrong on that narrower screen, and none of it shows on an X4.

What the first X3 flash settled
9 Sep 2026
The map on the device got smaller and nothing about it looks different

A road in map data arrives in pieces, split wherever the people who mapped it stopped and started, and every piece used to be its own record. The pieces are joined back into whole lines before the map is thinned now. The square the device reads when you pull back to see where you are lost a third of its size, and of the 384,000 pixels on the screen, 1,142 changed.

Why a third less data draws the same picture

The full dated log: every entry, newest first, next to the status list. The repo carries one topic document per hardware finding: how the panel actually behaves, and why the obvious approach fails.

06 · the hardware

A reader off the shelf, not a dev board

A pocket e-ink reader, bought off the shelf. Not a dev board, not Android, no ADB: a microcontroller with a display driver and physical buttons. Everything ExplorInk does has to fit in that. Two builds cover three readers. One is for the Xteink X4 and X3, both ESP32-C3, and it probes which panel it woke up on. The other is for the X4 Pro, an ESP32-S3 with touch, a frontlight and far more room: 172 kB free with the map up, against 58 kB on the X4.

The figures below are the X4’s, measured on one.

Panel: 4.3″ e-ink, 480×800, 220 PPI, no touch
Grey: 4 levels; 500 ms fast refresh, 1,684 ms clean, measured; map fills use 2×2 dither
SoC: ESP32-C3, WiFi + Bluetooth 5 LE
Heap: 247 KB total; 58.5 KB free with the map and BLE up, measured
Storage: 16 MB internal flash, maps on a separate SD card
Input: Physical buttons only, usable with gloves
Mount: Magnetic back: any MagSafe phone mount, bars, stem or dash

What hardware ExplorInk runs on, and everything we measured on the Xteink X4.

Xteink X4 held on a magnetic car dashboard mount next to the car's own navigation screen, showing a real schematic map with a position marker, zoom controls and Exit/Select/Up/Down button labels — Real test drive, real panel: ride time, tiles read and draw time in the debug line up top. The position numbers on that line are blurred out.

07 · early access

Installs today from a download. Get the one-click build when it lands.

You can put ExplorInk on a reader right now, and there is nothing to build: a firmware download per reader and the Android APK are published files, the maps come off the public tile server with nothing to set up, and the install page has the commands next to the downloads. It takes a USB cable, one command line tool and about half an hour. What does not exist yet is a one-click installer and a signed app in a store. That is what comes next. Leave an address and you hear from me once, when there is something to put on a device without a command line.

08 · get in touch

Built at Comsultia, in the open.

ExplorInk is developed by Comsultia, s.r.o., a software company in Slovakia. It started because I ride, and I wanted a display that survives a sunny day on a handlebar. The firmware and the phone app are public and MIT licensed, and every hardware finding is written down in the firmware repo. If you are doing something similar on e-ink reader hardware, or you want to try it, or you just want to tell me the map style is wrong, write to us.

Email

info@explorink.com

Company

comsultia.com

Comsultia, s.r.o., the company behind ExplorInk.

Code

github.com/rfordinal/explorink

Firmware, docs and every hardware finding. MIT licensed. The phone app is at explorink-android.

A paper map that knows where you are.