An eInk device is persistent: visible even after your embedded, energy harvested system exhausts power. This reports my experience using an eInk bar gauge instead of LEDs. Software is included.
I build systems that are solar powered, without batteries, with only super capacitors. They can exhaust power when they don’t get enough ambient energy, say during a few days of cloudy weather. I want to indicate or show software faults and system state. The indicator must use little power to set, and zero power to maintain. eInk does that.
An alternative is to write to persistent memory, then read it after plugging in a debug probe. An indicator lets you simply walk up and look at it.
Another alternative is to use wireless. But that adds complication, and requires the system to have more power when relaying the indication.
The eInk bargraph
eInk sells a 5 segment bar gauge, part number SCD722002. It is available on Digikey.
The datasheet says it requires 5V. But I found that you can drive it with only 3.3V.
It has an invisible, top electrode (pin 1) that covers all the visible segments. It has six segments: the background and five bars of a bar graph.
The datasheet says a segment must be driven for a half to two seconds. But I found that a half second is adequate, if you can accept gray rather than black. You can drive from white to gray and back again.
The datasheet says the device uses 0.5uA per cm squared. This device is about a centimeter squared. Thus it takes 0.5uA for a half second to drive the device, which is not much energy.
To drive a segment white, you drive the top electrode high, and the segment low (grounded.) Wait a while, then remove the drive: all segments to the same potential (voltage) or all segments inputs (floating.)
You don’t need a negative voltage rail (with respect to ground.)
I found that you also must drive all non-changing segments to the voltage of the top electrode (you can’t leave them floating), otherwise nearby segments can also change. In other words, the field for the changing segment bleeds to floating segments, and the ink appears to bleed.
You can drive any segment to any voltage for a short duration without changing the segment. This can simplify the code. A segment only changes color during a relatively long (seconds) delay.
Some documents say the driving must be “balanced”. Apparently this just means you must drive a segment to the same voltage, for the same duration, in both directions, whether changing white to black, or vice versa. I don’t think it means that the device “burns in” if you drive it too long in one direction.
The code is in my msp430Drivers repository, in the src/eInk directory. The high level code should be portable. The high level code abstracts what you must do to drive eInk.
The low level code uses the Texas Instruments MSP430 DriverLib. You can change it to use for example, Arduino. The low level code deals with GPIO pins.
The code is C++, object oriented.
The code sleeps the MCU in low power mode while delaying for the eInk to change color. (If you just spin delay, a typical, active MCU takes 1000 times more power then does the driven eInk device .)
The code keeps state variables for indicator state in persistent memory.
The code does not implement a bar graph, it implements a set of five separate indicators.
The word “indicator” is apropos. You can search for electronic parts using that word, or “indicator lamp.” Usually they are LED’s. But an LED does not indicate unless it is powered. Usually indicators are binary, on or off.
Here, the eInk is like a mailbox flag. It takes power to set it, then requires no more power, forever.
Here, I use different segments of a bar gauge, each as in indicator. The code doesn’t implement a BarGauge object, it implements a set of five indicators. eInk does not sell a single indicator device.
I fear they might not sell their five segment bar gauge very long, their large displays are probably more in demand.
You need a GPIO pin for each segment, and one for the top plate. The device does not have a power and ground pin. Thus you need seven GPIO pins for this device, if you use all segments. You don’t have to use all segments, you can leave them unconnected, but then their color is not determined, they might not stay white.
Persistent state variables
I use the MSP430, and use it’s LPM4.5 low power mode. In that mode, the CPU is powered off and all registers, stack, and RAM contents are lost. You should put a state variable for an eInk indicator in persistent memory (FRAM in this case), otherwise you won’t know the state of the indicator when you wake up.
Indicating the browned out condition
Can you use a single eInk indicator to tell the power state, specifically whether an energy harvesting system is or has browned out?
The MSP430 does not have a hardware monitor that detects imminent brownout. The MSP430 does have hardware to reset the system when brownout occurs, so there is never a time when the system is executing in undefined manner, yet there is never time to execute code before going into reset. You must implement brownout detection in software, using an ADC to read the system’s own voltage.
Suppose you detect system voltage (Vcc) near brownout (say less than 1.9V) and set an eInk indicator. You probably have enough power left to set the indicator. But ambient energy could be enough to keep voltage near brownout, without actually browning out. The set indicator only means the system might have browned out and is again near brownout, or never browned out and is still near brownout.
Suppose you have a persistent variable didBrownout. The variable is loaded at program load time with false. You detect voltage near brownout (say less than 1.9V) and set the variable to true. Then the system browns out (say less then 1.8V). Then ambient power comes back and the system does a POR (power on reset) boot (which does not initialize variable didBrownout to false), and checks the variable didBrownout. Finding it true, the code sets an eInk indicator. The set indicator means the system browned out at least once in the past.
Whether the system has ever browned out is relevant if your system is keeping a clock without battery backup. If you brownout, the clock becomes wrong.
In this example, you have already used two of five indicators.
In the image, the background and top segment were driven white, the next two segments black, and the bottom two segments were unconnected, floating always. Driving at 3.3V, for a half second.
The system (with an external AB0815RTC, not shown) can sleep at about 60nA. None of that current is used to keep the indicator visible.
A TI Lauchpad MSP430FR2433 at 3.3V and an eInk bar gauge.