the phone side · android and ios
The phone app: Android today, iOS planned
The reader has no GPS receiver, so the phone supplies the fix. That is the whole job. The phone goes in a pocket or a tank bag with its screen off, the reader on the bars is the screen, and the app does three things over one Bluetooth LE link: send the position, bring the map squares the reader is missing, and record the ride.
Your phone stops being the display
This is the point of the app, and it is worth saying plainly. A phone on the handlebars is a screen that washes out in overhead sun, heats up in a dark mount, drains the one battery you also need for photos and a phone call, and takes engine vibration all day. None of that changes because the map got better.
ExplorInk does not remove the phone. It needs it, for the GPS fix and for map data. It moves the phone off the bars. Screen off, in a pocket, one Bluetooth link open. What you look at is a reflective e-ink panel that gets easier to read the brighter the day gets.
Three jobs, one link
| Job | What the app does |
|---|---|
| Position | writes 21 bytes (latitude, longitude, UTC, time-zone offset, heading, sequence, flags, altitude) to the reader when the fix has actually moved |
| Map squares | answers the reader when it lists the tiles it does not have, and pushes them over the same link |
| Ride record | writes every raw fix, every packet (failures included) and every link event to one JSON Lines file per recording |
The send policy is deliberately lazy, because a packet the reader cannot use costs the phone's battery for nothing: at least 7 s between packets, a 50 m movement threshold, a slower 30 s cadence at walking speed, and one keep-alive an hour when nothing moves at all. The reader redraws in seconds, so sending at 1 Hz would only buy heat.
How the link is put together, and what it took to stop it wasting the phone’s battery.
It starts itself when you open the map
Once per phone you pair with one reader through Android’s own companion-device dialog. After that the operating system watches for that reader. Open the map screen on the bars and the OS wakes the app: app swiped away, phone locked, nothing tapped, and the bridge starts.
Verified end to end on real hardware, and again after a phone restart, which is the case that usually breaks this kind of thing. One thing it cannot survive: a force-stop from Android’s app settings. Nothing can.
Pairing pins one address, too. Every reader running this firmware advertises the same name and the same service, so an unpaired app talks to whichever answers first, and in a car park with two of them, the loser gets a stranger’s position on the map.
What it spends, and when
One switch decides everything: is the reader connected, or is a recording running? If yes, GPS updates, the wake lock and the send timer go up together. If no, all three go down together, and the service stops itself after five minutes with no link. Scanning drops to low power after the first 20 s.
Those rules are read off the code, not off a battery bench. A measured drain figure for a full ride is still missing, and it is written down as missing rather than estimated.
No account, no cloud, and the data stays yours
- No login, no account, no sync service. The app talks to one reader and to the tile server.
- A tile transfer is always started on the reader, never by the phone. It is your mobile data, so you say when.
- The check for out-of-date map squares is off by default for the same reason.
- Recordings are files on your phone. Nothing is uploaded.
iOS
iOS is planned. It is not started, and there is no date on this page because an invented one would be worth less than the honesty.
What is already settled is the part that usually blocks a second platform: the reader side is not Android-specific. The link is one plain Bluetooth LE GATT service with published UUIDs and a fixed 21-byte position packet, with no pairing, no bonding and no vendor SDK. An iOS client is app work. It needs no firmware change, and the protocol it has to speak is documented on this site.
One part does not port: the auto-start. Waking the app when the reader appears uses Android’s companion-device association, and iOS has no equivalent of that mechanism, so the “open the map and it just starts” behaviour has to be designed again rather than translated. Expect the first iOS build to be a manual start.
Installing it today
The Android app is sideloaded, not on Google Play: Android 12 or newer, one debug-signed APK, and the source is public. A signed release build and a proper listing are on the list, together with the one-click firmware flasher. Installation is the next milestone after map coverage, not an afterthought.
The Android app source is a standalone mirror: source only, no APK. The firmware lives in the ExplorInk repository.
What works today, dated, with the measurement behind each line.