Tinta - low power wireless epaper device

Project Logs

Collapse

Fifteen Months on Three AAA Cells, and Why Not Rechargeables

caspar • a day ago • 0 comments

Tinta's low power consumption relies on switching itself completely off between wake-ups. An easy way to see whether that works in practice is to look at how the lifetime scales with the wake-up interval — or, put differently, whether a set of batteries delivers the same number of wake-ups whether Tinta wakes every two minutes or once an hour. In the very first log of this project I tested exactly that, with intervals of 2 and 30 minutes, and wrote that "battery lifetime is not limited by power consumption in the off-state for these refresh times" and that "lifetimes in the range of years are realistic". That rested on two runs of 15 and 198 days: two points and a straight line through them.

Log # 2

A year later I have much longer runs and more data to check it against. One device has now been on the wall for 468 days on the set of cells it was built with, still going, and another managed 433 days and 5,665 wake-ups before it stopped. That sits nicely on the roughly 5,000 wake-ups per set the 4.2-inch version was designed for, and the 7.5-inch version reaches about 10,000 on its larger AA cells. Note that some of the devices only wake during office hours to save power, which is why the same wake-up budget stretches over more calendar days on some units than on others.

This picture is confirmed by looking at the data of all devices in operation up to now. A set of cells delivers a roughly fixed number of wake-ups, and how often the device wakes barely moves it, as you can see in the figure. The energy goes into waking up, connecting and refreshing the panel, and almost none of it into the time in between.

### Why alkaline?

Rechargeable batteries are the obvious choice for a device like this, and for this one they are the wrong choice. When nothing is drawn between wake-ups, the limit is no longer the electronics but the chemistry: cells lose charge on their own whether the device uses them or not. Alkaline cells are cheap, sold everywhere, and happen to be very good at exactly that.

Cell type	Typical self-discharge	Charge left after 1 year	After 3 years
Lithium, non-rechargeable	~1 % per year	99 %	97 %
Alkaline, non-rechargeable	~2.5 % per year	97 %	93 %
NiMH, low self-discharge	~15 % per year	85 %	61 %
Li-Po / Li-ion	~3 % per month	69 %	33 %
NiMH, ordinary	~12 % per month	22 %	1 %

Typical literature values at room temperature. After a year on the wall an alkaline cell still holds almost all of its charge, while an ordinary NiMH is down to a fifth, having powered nothing at all. Over three years it is empty. Only lithium primaries do better than alkaline, and not by much.

### What is next?

Very long lifetimes should be attainable at very rare wake-up, and in combination with Lithium. Of course, if charging once per year or so is fine, Tinta can also be used with rechargeable batteries. In any case, a small Python script in the repository, `hardware/circuit/power_consumption_estimate.py` can be used to estimate lifetime, backed by in-field data.

Source, schematics and enclosure

**Coming soon on Crowd Supply.**

The Pico That Pulls Its Own Plug — 34,146 Wake-Ups Later

caspar • 08/30/2026 at 16:34 • 0 comments

Unattended, prolonged operation is the central idea behind Tinta. For that, reliability is key.

The technical implementation for this employs something like "electronic suicide": after the circuit has done its job, the Pico is first setting an alarm for the DS3231 realtime clock (RTC) when to wake up next, and is then cutting its own power supply completely off to save power. Well, it is not really suicide, however, it is more disruptive (and saves more power) than going to sleep mode. This better works, otherwise the device never wakes up again, and user interaction is needed (or worse). However, this also comes with conceptual advantages. Tinta always wakes up in the same state, the only things that change are the time (RTC) and the information on the server — making the concept very robust, no memory leakage, locked-in state or so. Only a few seconds of lifetime, always the same day, Groundhog Day for a microcontroller — poor Pico ;)

The first prototypes are now running since more than a year in the field, so I checked how well this works in real life.

Missed scheduled wake-ups over a time of about one year, counted inside each unit's own active window.

The figure shows statistics for five devices. Missed wakes: 48 of 34146 = 0.141 % -> 99.859 % delivered. Probably most of those misses are due to an unsuccessful Wi-Fi connection — devices will timeout after a few attempts. More importantly, also after missed wakes, all devices kept operating on schedule afterwards.

I think this is a very good result and the circuit is working as it should. What else can we learn from this data?

Every time data is queried, Tinta is writing a short log message to the server. The RTC alarm is firing at a known time. So, we can compare the log message time and thus the RTC time with the server's time, and learn if the RTC is accumulating a time error. This is plotted in the figure below as time error. Of course, time needed to connect via Wi-Fi can fluctuate on a scale of several seconds or more. If we average over many Wi-Fi connections, that noise averages down and the slow accumulated error becomes visible over long times. However, this is a "hack of a measurement" and everything below has to be taken with caution.

A clear evolution of the time error is visible, and every device stays inside what the datasheet grants to aging alone — even though our number contains all the effects of the table below at once. The average over the fleet is close to zero, as expected if the server is not drifting at that level, i.e. locked via NTP. Stated the other way round: with eight independent clocks, the fleet average is a better reference than any single one of them.

The DS3231 datasheet specifies several separate contributions, and what we measure is their sum:

Contribution	Datasheet	Over a year
Accuracy, 0 °C to +40 °C	±2 ppm	±63 s
Crystal aging, first year	±1 ppm	±32 s
Supply voltage	1 ppm/V	1.4 V over a battery life → up to 44 s
Temperature sensor	±3 °C	shifts the compensation point
Aging trim register	0.1 ppm per LSB at +25 °C	quantisation of the correction
What we measure	−0.61 … +0.52 ppm	−19 … +16 s

Aging and supply voltage are contributions on the level of the observed time error. The devices all sit in the same building at a temperature around 20 °C. The DS3231 features a temperature compensated oscillator, strongly improving accuracy vs temperature.

The rate — the derivative of the curve above — against outside air temperature, both smoothed over eight weeks. Same time axis as the figure above, so the two can be read against each other....

Tap-to-book with Tinta: NFC-triggered room reservation on ePaper
caspar • 04/29/2026 at 07:28 • 0 comments

Using seatsurfing and Tinta door signs for some time in real life now, one thing that happens quite often to me is that I forget to book. So, it would be nice to be able to book arriving at the office using Tinta directly, instead of having to go to the homepage.

The solution: Using the concept from my NFC2026 Green Power Challenge project https://hackaday.com/2026/04/20/2026-green-power-challenge-nfc-powers-command-write-and-wake-of-mcu/ I now can book by tapping my cell phone to the door sign, and the corresponding seat is booked in our seatsurfing instance https://seatsurfing.io/.

Tap your phone on Tinta to book a desk — the Android app writes your booking request via NFC into the ST25DV chip, which harvests just enough RF energy from your phone to wake the sleeping microcontroller, create the booking on the seatsurfing server over WiFi, and refresh the ePaper display with the updated information.

I also played around with some other stuff one could do with that:
NFC integration — tap to trigger
caspar • 04/05/2026 at 17:22 • 0 comments

Tinta now supports NFC-based command triggering via an ST25 chip. A phone tap provides RF energy to write a command payload and wake the device from power-off — no button needed.

See also https://hackaday.io/project/205461-harvesting-nfc-energy-to-transmit-commands Hackaday Green Powered Challenge: the data transmission runs entirely on energy harvested from the phone's NFC field, with basically no standby power consumption.
improved webinterface
caspar • 02/20/2026 at 22:15 • 0 comments

Improved webinterface, the device status page now shows key information. Now, the temperature of the pico cpu can be read out - and you can check if your microcontroller (or the realtime clock) is running hot, or if the cpu is running out of memory. There is also useful information to use and configure the device.
Updated pcb and reflow soldering
caspar • 11/01/2025 at 22:58 • 0 comments

Since the pcb in the meantime contains quite a number of smd parts, soldering by hand became increasingly tedious. So, I changed the placement of the components so that most of the smd's are on the bottom. And took the opportunity to build a poor man's reflow oven using the approach from here: https://github.com/apollo-ng/picoReflow, something I always wanted to try.

Below you see the results, works nicely with an used oven and a bit of tinkering. And, now I can reflow solder also smaller components and those that cannot be soldered by hand - I have a few ideas for what I can use that for in the future.

Before reflow soldering

After reflow soldering
Home automation display - inki-homematic
caspar • 10/17/2025 at 20:34 • 0 comments
As another example for using inki, I implemented an application for use with the homematic home automation system.

Home automation systems collect a wealth of real-time data from sensors and devices throughout your home. While you can always check this information through web interfaces or mobile apps, there’s something uniquely convenient about having key information automatically displayed on a dedicated “electronic dashboard” that you can glance at during your daily routine. Above you see inki displaying live data from our Homematic system - temperatures from HmIP-STE2-PCB sensors, heating control status from HmIP-WTH-1, and power monitoring from HmIP-PSM-2 devices.

https://makertube.net/w/bWefBKAkkHVg7govr5T3QV

Inki-homematic directly connects to your Homematic CCU via XML-RPC, retrieving and displaying live sensor data and device status information. It integrates seamlessly with existing Homematic installations to provide wireless ePaper visualization of your home automation data. In general any homematic device parameter can be read out by configuring inki via the webinterface, see the examples below.

You can easily configure inki-homematic through the web interface, such as from your smartphone. Here’s what the configuration screens look like:

Setup Process:
1. Connect to the inki setup WiFi network
2. Access the web interface at http://192.168.4.1
3. Configure your home WiFi credentials
4. Enter your Homematic CCU IP address and port
5. Add device IDs and value types from your Homematic system
6. Set display labels and update intervals
More info at Tinta on github
New webpage with applications
caspar • 09/30/2025 at 18:03 • 0 comments

More info at wake-electronics.com
Webinterface for configuration and firmware updates
caspar • 08/17/2025 at 13:39 • 0 comments

The main point of the inki devices it that you can hang them on the wall, no cables needed, and information is automatically retrieved and displayed on the epaper. However, you also might want to change the settings from time to time, when using desk sharing such as seatsurfing, for instance, you might want to change the room or the logo, when using homeautomation such as ccu-historian maybe you want to query a different parameter. Or simply set the realtime clock. It would be nice to be able to change settings and also upgrade the device in place without the need of a dedicated development setup, and without the need to move the device at all.
For this I implemented a wifi access point mode with lw ip: inki can be started in this mode, it will show the display with the access information (see below) and stay on for 15 minutes. You can now simply connect to inki with your cell phone, tablet or pc to the corresponding access point "inki-setup" and go to 192.168.4.1 in your local network. This will bring you to the setup page:
A short walk through the pages:
Set the wifi credentials for the client mode. This will be needed in the usual client mode.
Settings for seatsurfing, this information can be copied and pasted from your seatsurfing webinterface, it is using the service account (thanks to Heiner from seatsurfing https://github.com/seatsurfing/ for adding it!).
Configuration of the device itself (not all shown): refresh times, timeouts, adc conversion factor, etc.
Upload your own logo, will be written into the pico's flash and show up instead of the small octopus.

Device status page.
Firmware update: Choose the new firmware and upload. The file will be written to the pico's flash, crc checked, and, if valid, and more recent than the current firmware, the device will boot from this version after the next power cycle. This is using a small custom bootloader https://github.com/c0de111/pico_bootloader I wrote. No additional hardware needed, only your cell phone / tablet / laptop / pc.
Set inki's realtime clock using the time of your device. This will use the current date of your device (cell phone / tablet / pc) and set inki's clock to that time.
The webinterface thus gives access to the relevant aspects that are organized in the pico's flash as follows:
RP2040 Flash Memory Map (2 MB = 0x200000)
┌──────────────┬──────────────────────┬────────────┬──────────────────────────────────────┐
│ Address │ Region │ Size │ Description │
├──────────────┼──────────────────────┼────────────┼──────────────────────────────────────┤
│ 0x000000 │ Bootloader │ 64 KB │ Custom bootloader │
│ 0x010000 │ Firmware Slot 0 │ 940 KB │ FIRMWARE_FLASH_SIZE = 0xEB800 │
│ 0x0FB800 │ Firmware Slot 1 │ 940 KB │ FIRMWARE_FLASH_SIZE = 0xEB800 │
│ 0x1E7000 │ Config & Reserved │ 100 KB │ Configuration, logos, OTA buffers │
│ 0x200000 │ Flash End │ │ End of 2 MB QSPI flash │
└──────────────┴──────────────────────┴────────────┴──────────────────────────────────────┘

Firmware slots start at XIP_BASE + offset:
- Slot 0: 0x10000000 + 0x010000 = 0x10010000
- Slot 1: 0x10000000 + 0x0FB800 = 0x100FB800

Notes:
- Bootloader includes 256-byte...
Read more »
inki as display for home automation
caspar • 08/14/2025 at 18:20 • 0 comments

inki can be used to display interesting accessible via wifi, as for instance from home automation systems. In this example I implemented a query for ccu-historian (https://github.com/mdzio/ccu-historian) that is based on the "homematic" system. In the image below the large / 7.5" version of inki displays the temperature of the last 24 hours in our garden. Yes, it was a very hot day!

The operation principle, the hardware and most of the firmware are the same as in the desktop sharing application: inki wakes up at user defined intervals, and in this case queries the raspberry pi running ccu-historian. Thanks to the very well documented API of ccu-historian (https://github.com/mdzio/ccu-historian/wiki#autor-und-lizenz) the data is readily available in the form of a JSON container that is interpreted by the pico. At each wake-up interval the data is updated and plotted - in the example above you simply get a plot of the temperature of the last 24 hours. The possibilities extend to all the data logged in the years it is running at our home, and not only the temperature.

This was another example how to use the device - maybe you have ideas for more?