Measure the complete device rather than inferring its consumption from a retained image.
An industrial e-paper prototype looks economical on the bench: its image stays visible after power is disconnected. Then the connected version wakes frequently, retries unsuccessful transmissions, and runs its controller longer than expected. The display still does its job, but the battery estimate no longer matches the device.
An e-paper display power budget should describe the complete operating cycle. For an OEM building an industrial sensor terminal or information device, the useful unit is energy consumed during a representative day, not a single current reading taken while the screen is idle. Start by listing what the product does between two successful updates.
Separate the retained image from the powered electronics
Bistable electrophoretic displays can retain a completed image without continuous display power. That characteristic can reduce the energy required to keep information visible. It does not mean that the controller, radio, sensors, regulators, or peripheral circuits consume nothing while the image is unchanged.
Draw a boundary around the measurement. A panel-only result and a battery-input result answer different questions. Record where the instrument is connected and whether the measured assembly includes the display driver, host processor, communication hardware, and production power supply. Otherwise two impressive-looking figures may describe entirely different systems.
When reviewing Sunshine Display's module catalogue, establish which electronics are included in the proposed deliverable. A bare panel and a module with supporting circuitry should not be treated as equivalent loads. Ask for the exact module documentation and identify what the OEM still needs to provide.
Build the budget from events and quiet periods
List the events that consume energy: waking the processor, reading a sensor, receiving a message, preparing an image, refreshing the panel, sending an acknowledgment, and returning to sleep. Add commissioning and recovery behavior separately. Those events may be rare in normal operation but expensive during installation or a connection problem.
A practical daily estimate adds the energy of each event multiplied by its expected count, then adds standby energy over the remaining time. Keep the units consistent. If measurements come from different supply voltages, compare energy rather than simply adding current figures. Include conversion losses where the measurement boundary does not already capture them.
Avoid double-counting overlapping activity. The radio and processor may operate together, while a full-device current trace already includes both. Use either measured operating states or separate component estimates with a clearly defined time model. Label assumptions so they can be replaced with measurements as the prototype develops.
Capture the full update event and the return to the intended idle state.
Measure a refresh with the intended content
Use the selected panel, controller implementation, and approved driving procedure. Record the starting image, destination image, refresh mode, temperature, supply conditions, and completion signal. A result without those details is difficult to reproduce or apply to another product revision.
Do not assume that every module supports the same partial-update behavior or that a faster mode will meet the product's visual requirements. Confirm supported modes in the module documentation and inspect the resulting image. An energy saving is not useful if the chosen update pattern leaves unacceptable artifacts or makes important information difficult to read.
Measure the complete event through the return to the intended idle state. Stopping the trace when the visible image changes can miss a controller that remains awake afterward. Likewise, confirm that the application does not repeatedly redraw identical information merely because a background task runs on a fixed schedule.
Give communication failures their own scenario
A demonstration with a nearby gateway describes favorable conditions. An installed device may wait for a response, repeat a transmission, or search for a connection. Ask the firmware team to define retry limits, waiting intervals, and behavior after repeated failure before assigning a battery-life figure.
Keep communication frequency separate from display refresh frequency. A device can check for messages without changing the screen, or collect several changes before updating its visible page. Decide those policies from the information's required freshness. Reducing updates is not an improvement if staff can no longer tell whether the displayed record is current.
Test an unavailable gateway and recovery after an outage. Check both the energy consumed and the final screen. The device should not spend an unbounded period attempting to reconnect, nor should its retained image silently imply a successful recent update. Define what evidence the application can provide about the last completed transaction.
Compare prototypes using a common workload and supply conditions.
Turn an energy estimate into a service plan
Battery capacity alone is not a finished runtime prediction. Review the battery supplier's discharge conditions, usable voltage range, temperature behavior, and pulse-load capability alongside the device's requirements. Include storage time and the planned service interval. Use measured operating scenarios rather than a nominal capacity divided by one optimistic current value.
Check supply behavior during active events as well as the average load. A low average demand does not establish that the supply remains within the required range throughout an update. Evaluate the battery, contacts, regulator, wiring, and display assembly together, particularly near the intended end-of-service condition.
Define how low energy is handled. Decide when the product reports a service need and what happens if it cannot complete another refresh. Because a retained image can remain visible, document how service staff distinguish readable information from a healthy powered device. Keep this behavior consistent with the product's actual capabilities.
Compare candidates using the same workload
Give suppliers and internal teams one common workload: page examples, expected update counts, communication activity, installation conditions, and service expectations. Evaluate samples with the same measurement boundary and acceptance criteria. Record firmware and hardware revisions with the results so a later change can be assessed meaningfully.
If the application requires continuous animated information or frequent operator interaction, compare the requirement with standard TFT LCD modules rather than selecting e-paper from an idle-power claim alone. The right comparison includes how the complete product is used and powered.
For an industrial e-paper project, send the workload, screen artwork, power arrangement, and enclosure drawing to Sunshine Display's OEM enquiry team. Those inputs make sample selection and power evaluation concrete, and help turn a preliminary estimate into a testable product requirement.
