Designing a Low-Power Wireless E-Paper Display That Runs for Months on a Coin Cell
Why this project existed in the first place 🔍
Hospitals and retailers track thousands of controlled items. The job is simple and hard: show what it is, how many remain, and make updates effortless. So our client asked for a thumb-sized wireless tag that updates from a central system and sips power so batteries are an afterthought. Because an LCD draws power to hold an image, it was a non-starter. Instead, e-paper holds an image without power, so the radio and MCU sleep most of the time while the screen stays crisp.
System at a glance: building a low-power wireless e-paper display 🧭
We built a palm-sized module around a ZigBee IEEE 802.15.4 SoC with an integrated 2.4 GHz radio, on-chip flash, and peripherals. In this design, the e-paper panel connects via a 40-pin FPC and two CR2032 cells power the board, while a small SPI flash stores fonts and bitmaps. Additionally, NFC supports tap-to-identify and quick field setup.
Meanwhile, three buttons—Admin, Take, Return—drive a simple workflow with one LED and a beeper for feedback. The tag wakes, joins the mesh, updates, and goes back to sleep. As a result, the display stays readable while everything else sleeps and power usage is minimized.
Hardware decisions that actually mattered 🧩
Radio and MCU selection
We chose a ZigBee-class MCU with an integrated transceiver to keep transmit and receive currents in the tens of milliamps. Deep sleep was in the microamps and on-chip timers, ADC, UARTs, I²C, SPI, and ample GPIO reduced glue logic and surprises.
Driving an e-paper panel without wasting energy
E-paper needs high-voltage rails only during updates. We gated the ±15 V and ±20 V supplies with MOSFETs, then shut them off between updates. The FPC carried chip select, reset, busy, and the boosted rails. To avoid brownouts, we sized capacitors by measurement during inrush when waking the panel.
Power and sensing
Two CR2032 cells kept the enclosure thin yet ready for short bursts. Connected to those, the ADC monitored battery voltage and temperature. SPI flash held fonts and precomposed images to avoid on-device rendering and NFC supported quick identification and setup. When speed mattered, we pushed builds through prototyping so testable hardware wasn’t the bottleneck.
Human interface, kept boring on purpose
Three tactile switches. One LED. One beeper. Press a button, the tag wakes, shows what is happening, and goes back to sleep. No menus. No training.
Firmware architecture that refuses to fight itself 🧠
We shipped the first version in 2017–2018 and revisited it in 2022. The core stayed the same: a small RTOS, separate tasks for networking and the display, and a clear split between what should happen and how hardware behaves. By maintaining that split, it kept the device responsive without wasting energy. On similar programs we lock down scheduling in firmware development first, then add features once the power budget is stable.
States that map to reality
Two state families drove behavior.
Application states: idle, taking, returning.
LED states: off, on, flashing.
On startup we loaded parameters for debounce, LED timing, display coordinates, poll intervals, and typomatic delays. A network-bring-up task joined the mesh. A display-update task owned the panel. Button-handling tasks processed interrupts, counted presses, and scheduled work through queues and timers.
Sleep first, ask questions later
Default posture was deep sleep. Wake sources were GPIO edges and timers. Between polls the radio and high-voltage rails were off. We read temperature and battery about hourly, then went back down. To reduce wear, we wrote to non-volatile memory only when about to sleep.
Reentrant screen updates without flicker
E-paper updates are slow. If two requests arrive back-to-back, you either waste power or show stale content. We used a reentrant state machine for screen updates: idle, startup, updating, shutdown. New requests collapsed to “only render the last one.” A shutdown routine always powered down rails cleanly, even if a fresh request arrived mid-flight.
Feedback that matches user intent
During a transaction, the LED turned solid while connecting. Once ready, it switched to a flash pattern that invited another press. Timing lived in small LED tasks, which made behavior predictable and testable.
What we measured, not what we hoped 📈
Current profile
We instrumented the device in sleep and active phases using bench supplies and loggers. Sleep was in the microamps. Active radio and panel windows were short and intentional. As a result, we met the months-on-two-CR2032s goal by sizing intervals to that budget. On other programs we extend life further with firmware optimization.
Manufacturing test that catches real failures
We used a programming rig and a ZigBee bridge to flash and exercise devices. Factory steps covered power-on checks, e-paper write and busy timing, buttons, LED, beeper, and RF join. A desktop tool opened a join window, paired a tag, and verified that button-driven messages matched screen updates. If a unit struggled to join, it stayed on the bench.
Field changes without regret
In 2022 we trimmed radio polling, removed always-visible quantities from the idle screen, and improved button feedback. Fonts and margins were tuned for legibility. None of that touched the core state machine or the power drivers. The split between “when” and “how” paid off.
Challenges that taught us something 🧪
Concurrency on a tight budget
A button press might wake the MCU as a delayed poll fires. Without careful ordering, you risk tearing the panel or waking the radio twice. Timers, small queues, and strict ownership rules kept these paths sane.
The e-paper personality
Panels differ on waveform timing and temperature. We profiled updates at cold and room temperatures, then chose waveform tables accordingly. If the display signaled busy, we waited.
RF in the real world
Metal storage cabinets block 2.4 GHz. Mesh helps, but topology still matters. We tuned join and rejoin timing to avoid thrash and kept payloads small. When possible, the tag sent one good message rather than several speculative ones.
Results that mattered to the client ✅
Months-long life on coin cells, validated by current profiling and soak tests.
Simple workflow with clear feedback (Take, Return, Admin, LED, beeper).
Mesh networking that handled thousands of nodes and survived cabinet mazes.
Field-tunable behavior through parameters and NFC without opening the device.
A factory test flow that caught display, RF, and power issues before shipment.
Lessons you can reuse on your next low-power build 🎓
Start with a power budget and defend it. E-paper holds an image without power, so gate every rail that is not needed between updates.
Design state machines that tolerate change. Reentrant updates and queued intent let you adapt behavior later with minimal work.
Defer work until it is necessary. Do not wake the radio unless you must. Skip flash writes unless you are about to sleep. Repaint only when the final image is ready.
Make factory test feel like a user. Join a network, press buttons, and watch the display. Otherwise you will ship intermittent failures.
Choose the right stack for the job. Whole-product thinking in embedded systems design makes the tradeoffs explicit.
If you are building something similar 🤝
If you want to talk through a power budget, sleep strategy, or reentrant UI paths, get in touch and we will map options on a quick call.
