I was recently given a brass calendar frame that normally holds a collection of small cards corresponding to the date. The top lifts off and the cards are re-arranged to display the day’s date. I decided to automate it with the following:

• Arduino Pro Mini, ATmega328P microcontroller board (1x)  Main controller for the system, runs the code integrates everything else.
• DS3231 Realtime Clock module (1x). This keeps track of the time/date. It has its own small battery to stay running while main system power is off.
• 3.7″ Epaper displays(3x).
• Epaper connector board (2x) – mainly just a breakout board for the epaper display’s ribbon cable, but it also handles signal buffering and making a few weird voltages that the epaper display needs.
• Epaper interface board (1x) – same as the connector board, but also has onboard SPI RAM and MicroSD card slot.

I’ve designed many various electronic circuits/devices, but this is the first I can recall where the power budget matters a lot. The power usage would always be low with these devices, but I wanted to avoid a scenario where it’d need a wall wart plug – the goal is for it to run a reasonably long time, a year or so, on a rechargeable battery. The magic of the e-paper displays (other than having the image very close to the surface, looking more like real paper than a display) is that they can be completely powered off and still retain their image; that’s a huge head-start to low power usage. This left the micro-controller as the main risk for power consumption, however with careful use of interrupts I think I’ve optimized this.  The sequence, which happens every night at midnight, is:

• DS3231 asserts its alarm pin
• The alarm pin is connected to an interrupt on the ATmega328P which has been configured to wake the microcontroller and begin code execution.
• The microcontroller communicates with the DS3231 over I2C to read the new date and resets the alarm for the next midnight.
• The microcontroller reads the SD card to lookup graphics corresponding the 1st display based on date, this is read into RAM and then shifted to the epaper display. This repeats for each display. (The controller inside each display goes through its own routine for the physical screen update that causes the screens to flash Black/white several times)
• The microcontroller goes back to sleep mode, no code execution and extremely low (almost no) power usage until next midnight.

With this sequence it’s very nearly off the vast majority of the time, only the small clock battery on the DS3231 module keeps it going; then everything else only wakes up for a few seconds at midnight to update the screens. Time will tell how efficient this is, but it should be as good as theoretically possible. The DS3231 battery is meant to hold the time for ~10yrs, when the main battery is depleted the screens will stop updating but time won’t be lost – proper date will be displayed on the first update after a recharge without any need to set the time/date.

The software for writing to the epaper displays leans heavily on the example provided with the displays, but the example assumed only a single display. Since I had limited IO pins and there was no need to update displays simultaneously I modified the library to accept a display index for each function. With this, I was able to put everything on the same SPI bus and share the SD/RAM between all displays, the library just only asserts the chip select line for the display being updated during the overall update sequence.

Mechanically, each display is mounted to a 3D-printed plate that pads out the display to the right dimensions, the plate also has screw bosses where the connector boards are mounted. Although the display sizes were very close to the right size, it was unavoidable that some non-displayable area of the panels showed through the front of the calendar frame. To make this look better I made some vinyl frames in a metallic brass/gold color to cover these margins.

(Note: Dates don’t necessarily correlate with actual time/progress since the date was adjusted many times during testing. I also tried several different fonts/styles before deciding on the “FRI FEB 16” format.)