Even an "Imprecise and Over-Engineered" Digital ePaper Clock Is Right At Least Once a Day!

Let me start by explaining that the wording of the title is taken directly from the project owner! I'll never throw shade at any clock project, as I've said before — and will say many times again — a clock really is a rite of passage for any engineer, in any field!

Machinists will learn to cut their teeth with highly toleranced measurements required for the mechanics of a clock mechanism, and electronic engineers will learn the ins-and-outs of timing, HMI elements, and even the often-overlooked "gotchas" associated with carefully routed connections to the crystal that keeps a careful count of the time.

So while all of these skills are requisite, and worth of writing about, unfortunately, we can't cover every clock project that we come across. Indeed, we are tasked with reporting on the irregular projects — ones that show us something different, such that we are able to show you some potentially new tips and tricks for you to try out in your time tracking devices.

With this in mind, let's take a look at this project build, from @martinfasani (AKA Martin The Creator) over on Twitter, which is a digital, electronic paper display, with some low-power optimization targeted at its core, the ESP32.

The ESP32 is a hugely popular device. With its formidable specification sheet — including its dual cores clocked at 240MHz! — there isn't a lot it can't do.

With ultimate power, comes ultimate power consumption however, and although we are subject to a bevy of projects that make use of this pint-sized powerhouse of a part, we haven't (so far) seen many projects that aim to wrangle as much battery life as is possible from this part.

Martin is out to change that for us, though, with his efforts to target the lowest possible power operation for his ePaper devices, based around the CALE.es web-service and the ESP-IDF.

ESP-whatnow?

If your only experience to the ESP chips so far is from the Arduino framework, the ESP-IDF might not sound so familiar. IDF stands for "Integrated Development Framework," and it's the low-level path to wrangling the ESP silicon into doing your bidding, offered by Espressif themselves.

If you want a bit of a finer-grained control of the operation of your ESP device, the IDF is the obvious place to look. With a wealth of "components" to choose to integrate into your project, its modular approach to building the firmware can be a bit daunting to those who haven't yet used it.

While it looks somewhat imposing when compared to the warm and friendly Arduino GUI, the framework is supplied with a wealth of examples that can be compiled "out of the box", along with a — prompt-based menu system for configuring your build — allowing you to pick and choose the desired functionality for your project as required.

CALE.es is aimed as scaling back your power consumption. Touting itself as an "API Mashup creator for your WiFi displays," it is a service that acts almost as a virtual screen buffer for your WiFi display. You set up an instance of your device on the web service, and configure your data and feeds as required, as you wish them to be displayed on the end node.

With an associated firmware image for the ESP32, plus an accompanying android app, the end node is configured to connect to CALE.es, and pull down the generated screen image.

After this, the node will sleep for a specified period, before springing into life to grab the next image generated by CALE — a technique that means the device consumes virtually no power in-between the times when the display is refreshed!

Cop yourself some CALE components!

Martin has wrapped all of this functionality up into cale-idf, a component that integrates directly into the ESP-IDF build system.

Further to this, in order to properly integrate the EPD functionality into the ESP-IDF build system, he has also released CalEPD, which enables you to specify the parameters of the EPD used, such that cale-idf can properly display the data it's pulling down.

So, what can we do with this low-power approach to pulling down parametric and pushing them up to our electrophoretic pixels?

Well, calendars, and even low data rate status panel displays are two obvious choices that match the design ideology of low-power, low-frequency updates.

There's a wonderful example of a CALE enabled calendar shown here, and it really does demonstrate the idea very nicely!

However, Martin is pushing things a bit further in his aim to squeeze as much as possible out of the concept of pulling data from a remote source, with his attempt at a low-power, ESP32-based EPD clock.

Instead of pulling down a bitmap image from CALE.es, instead, this clock is able to query a "super fast" API endpoint, up on a remote server. In doing so, on-air time is minimised, with only the data that is needed being transmitted.

With the active Wi-Fi being responsible for a significant amount of the current consumption of the device, the idea behind minimising on-air time is a solid one - keeping the radio powered up for only the time which is absolutely necessary makes a huge amount of sense.

It's worth noting that there is a little scope for improvement. As Martin points out over on the HaD project page for the clock, the ESP32 is not a hugely accurate device when it comes to timekeeping, and with the ability to sync it's timekeeping to NTP or similar (it is a web-connected device, after all!), having a hugely accurate RTC wasn't within the ESP32 design spec.

The "RTC" within the ESP32 isn't really comparable to a specific, dedicated device, like the DS3231 for example. With its timing derived from an external crystal, there is a "bit" of drift that can make its way through from the heavily cost-optimized design of the espressif development boards.

As such, Martin notes that his clock can drift by up to five or more minutes over the course of a day! This might not be such an issue if you are able to keep the frames from CALE.es frequent enough (at the cost of increased power consumption), or perhaps, if you can't live with that power budget, perhaps you can live with a clock that counts in 5 minute intervals?

For designs that require sub-second accuracy, well maybe a different approach is required, one based around a local, high-precision RTC, such as the aforementioned DS3231.

That's a different project entirely though, and one for another day. For now, Martins clock serves as a worthy introduction to the nifty CALE.es web service! I can already think of more than a few projects in mind that would benefit from this low-power approach to displaying data, and I think I might have to go and fork his repositories so I can have a play about myself!