LightInk: an ESP32 e-ink watch designed to run on a solar cell

A personal project that needs a soldering iron

LightInk is an ESP32 powered e-ink watch that the project describes as able to run solely on solar power. The stated purpose is blunt about its own nature: have fun optimising the hell out of this ESP32 to make it low power enough for a solar cell. The README says it started as a challenge and is starting to look like a real thing after many years.

The author is equally blunt about the commercial question. The plan is to keep developing features and fixes for personal use, and the author doubts it will become a commercial product since building a unit requires a lot of soldering, while being open to being shown otherwise if someone can make it mass producible.

So the audience is a specific one: someone who can build an ESP32 board, order a PCB, source an e-ink panel and a TPS63900 power source, and print or fabricate a case. There is no store listing and no release to download. What there is, is a complete design record with the firmware, the hardware files and the documentation in one repository, which is worth more to a builder than a binary would be.

Where the current budget goes: 2 microamps and a TPS63900

The headline figure is that the power consumption is around 2uA just updating time, so a 200mAh battery of the kind used in a Watchy can last around 400 days, or the watch can be powered by a small solar cell. The project goal is stated as ultra low consumption below 0.5 mAh per day.

The hardware differs from the Watchy idea it is based around in specific ways, and the first is the power source. It uses a TPS63900 with two configurable output voltages at 2.6 and 2.9V, described as a DC-DC with 75nA quiescent current, 1A capability and 1.8 to 5V regulation, and the claim is that this is enough to power the ESP32, the RTC, the e-ink and WiFi under all conditions. That last point is the design tension in the whole project, because radio and display refresh are the two things that normally ruin an e-ink watch budget.

The second difference is what was removed. There is no accelerometer, described as too much power even when disabled at 1uA, and no solar cell regulation, since the panel is connected directly to the battery. What was added is a piezo speaker, an LED light to see the display in the dark, capacitive touch instead of buttons, and support for LoRa and GPS, with the explicit caveat that they use too much power and are only turned on to send a signal.

The project goals double as the feature status list

The README keeps a checklist of the project goals, and reading it as a status board tells you more about the state of the firmware than any changelog would.

Several optimisation items are marked done, including a custom display driver that reduces booster times and LUT use, and an implementation of uSPI with display update from a wake sleep stub taking less than 1ms, which the note says is enough to bring the ESP32 on time. The feature list is also largely ticked: LED light, vibration, speaker, GPS, and LoRa receive with BPSK send for signals. Basic UI functionality and widgets are done too.

Time keeping is marked accurate, with manual drift calibration and adjustment, an NTP sync over WiFi with automatic timezone, and a note that the target was 1ppm and is now 10ppm. Battery support is done, including auto power save and a night time saving feature, while tracking the battery and estimating it in the ULP is still open.

The unchecked items are equally informative. Watchface configuration is open, including a refactor to make the watchface modular with uSPI update, and the moon indicator, sunset and sunrise widgets are done while tides and pictures are not. Configurable alarms, the Bluetooth companion app and support for other boards are all still to do, and the Watchy 1.0 board is handled in a separate branch rather than in main.

Building the firmware: submodules, setup.sh and idf.py

The build instructions are short, which is what you would expect from a project whose toolchain is already pinned in the tree. The README says to clone every submodule, use setup.sh and then idf.py to build, and gives the exact commands:

git submodule update --init --recursive
cd firmware && ./setup.sh && idf.py build flash monitor

Two things about that sequence matter. The first command is recursive because the firmware depends on more than one submodule, including the ESP-IDF version itself. The second is that the repository carries its own ESP-IDF under firmware/esp-idf, and the repo structure comment states that this version has changes compared to upstream, so the pinned toolchain is not interchangeable with a stock installation of the same release.

The idf.py invocation chains three steps: build, flash and monitor. Flash and monitor talk to the board over USB, so a first build needs the hardware connected, and the monitor step is what gives you the serial console. The setup.sh script is where the environment is prepared, and running it from the firmware directory is what the README requires.

The project also states that contributions are made by pushing to a non protected branch and asking for a pull request, and it invites help from anyone who wants to build a unit for themselves or add support for existing ESP32 hardware such as Watchy.

The repository holds firmware, PCB, case and documentation

The repo structure block in the README is the clearest statement of what this project is, and it is worth reading as the documentation index:

lightink/
├── firmware/
│   ├── main/         # The LightInk firmware code
│   ├── components/   # Other components & subprojects used in the builds
│   └── esp-idf/      # The ESP-IDF version used to build (it has changes compared to upstream)
│   ...               # Other misc files like partitions / sdkconfig / ...
│
├── hardware/
│   ├── pcb/          # Schematics, BOM and diagrams
│   └── case/         # STL files for from and back
│
├── docs/
│   ├── images/       # images of the project
│   ...               # Hisotory and important docs
│
├── README.md
└── LICENSE

Having the hardware next to the firmware is the deciding feature for anyone who wants to build one. The pcb directory holds the schematics, the BOM and the diagrams, and the case directory holds the STL files for the front and back of the enclosure, so you can print a case rather than design one. A project that only shipped firmware would leave you reverse engineering a board.

The docs directory carries the images plus a history document, and the README links separately to the history file, the hardware documentation, the case documentation and the PCB documentation. The top level entries confirm the shape of the tree, with .gitmodules for the submodule wiring, the LICENSE file, docs, firmware, hardware and a main directory.

Outside the repository, the project is documented on Hackaday, with a project page, a YouTube channel, videos demonstrating the solar behaviour and the feature set, and a write-up on Hackster.

GPL-3.0, no releases, and one maintainer

The licence file sits at the root and the project is under GPL-3.0, which for hardware means the firmware source and, by the usual reasoning, the corresponding modifications to it are covered, while the board design files are also published in the repository. If you want to build a commercial unit from these files, the licence is the first thing to read.

There are no GitHub releases, and that is a deliberate choice for a project whose artefacts are hardware rather than software downloads. The last push to the repository was on 2026-10-07, so the work is current, but you get the design from the tree rather than a tagged archive, and there is no packaged firmware artefact to flash without building it.

The shape of the project also has a human dimension. The README states that the plan is to continue developing and adding features and fixes for personal use, that it began as a challenge, and that the author is happy to be shown how to mass produce it. The feature list reflects a single maintainer prioritising: solar operation, display efficiency, time accuracy and touch are all complete, while the consumer facing extras, the companion app and multi board support are not.

The realistic adoption path is therefore to read the design, rebuild it on your own board or on the Watchy branch, and contribute back improvements. The documentation structure supports that, and the open question of mass production is one the project itself has left on the table.

Editorial conclusion

Adopt LightInk if you build hardware, enjoy firmware power tuning on an ESP32, and want a solar e-ink watch design you can read end to end, from the TPS63900 power path to the uSPI display update stub. Do not adopt it if you need a purchasable device, a printed enclosure, or a supported product, because the author states that building a unit requires a lot of soldering and that a commercial product is doubtful. Verify first that the ESP-IDF version under firmware/esp-idf matches the toolchain you have, since the README says that bundled version carries changes compared to upstream, and check the open items in the project goals, since watchface configuration, configurable alarms, the battery estimate in ULP and the Bluetooth companion app are all still unchecked.

Frequently asked questions

Official sources

1. DarkZeros/LightInk on GitHub
2. Issues
3. License: GPL-3.0
4. README