If it's 5:27 right now and the BART comes at 5:38, I need to update once per minute if I'm showing a "+11m" for that relative time to remain accurate. Since the display takes more than 30s to refresh and isn't readable while it's refreshing, that means it's useless > 50% of the time I try to glance at it.
Whereas with my current setup, I only update it once one of the BART arrival times is no longer in the future. So, right now it's showing arrivals at 6:23, 6:29, and 6:44. Which means the display will update at 6:23, 6:29, and 6:44. There's a little extra optimization added to only show BARTs that are at least 5min in the future, since the BART is a 5min drive from the location where the display is. Depending on the BART schedule, all this works out to roughly ~8min update cycle on average, meaning that the display is only unreadable due to refreshing about 6% of the time, which I find to be very acceptable.
It actually really makes me want to build a Solari board for my local metro station.
So they show the time for 11 minutes instead of spending 30s of every minute refreshing the display.
The problem is not inherent to the eink technology: I can read comics, browse the web in color on the Boox Nova Air C, or even watch youtube.
The problem is waveforms etc trying to provide a picture perfect rendering when rough blobs of color may do the same job.
E-Ink Carta uses an LCD layer for the color filter, so it has standard E-Ink response times. These things seem to have multiple pigments, which have different weights and are separated from each other by quickly pulsing the display back and forth right, which takes a long time.
For this kind of separation waveforms probably matter a lot more, but hobby applications seem to have been doing fine with custom waveforms. They may not perfectly respond to the current temperature or have optimal ghosting prevention, but they do (from all examples I've seen) produce good images. Getting fast updates seems to be mostly a function of daring to drive the device with high power (which can lead to stuck pigments if overdone, but this can often be corrected with some flashing).
But with some waveform hacking (courtesy of the seller, “GoodDisplay”) and some creative use of the controller chip interface spec which differed slightly from the display interface spec…
I’ve managed to get rapid, partial black and white updates working. So you can create a ‘background’ out of three colours, then so long as you update rectangles that only contain black/white pixels, you can do a sub-second update.
Mine is a display that sits inside a PC, it shows the time, CPU and GPU temperatures, updated once a minute, and has a black/red fractal pattern that only updates on a full refresh which I scheduled for every 15 minutes.
Something similar may work with yours?