Hacker News Reader

Comment by malcolmosh | Hacker News Reader

Very cool ! I built a series of scripts to exchange e-ink images through Gmail last year which I baptized DispatchPi (https://github.com/malcolmosh/dispatchPi/blob/main/README.md) and a program like this would definitely have accelerated development. It was a bit fussy to always have to use a terminal to SSH into the Pi, then update the scripts through FileZilla (ftp client) + Vscode.

I've just completed a dashboard project which I'm about to release and I was also thinking of switching my frame drivers to ESP32 to run them on batteries, since they consume far less energy than even a Pi Zero. So +1 for ESP32 compatibility if time allows!

View on HN

How deep are you in the ESP32 dev? I've found image rendering (the display is LCD, not eInk) to be less straightforward than anticipated.

In my case, massaging images into a specific size and format prior to sending them into the ESP32/Display is easier and more reliable than trying to have the ESP libraries display any arbitrary image.

I haven’t actually started coding yet with the ESP chip. In my case the aim is to pick up a preformatted image from an URL, avoiding all of the finicky formatting you describe. I like the idea of the screen controller as a single function machine just for display, with the backend being a simple GitHub repo connected to Cloud Run via CI/CD.

What hardware are you using? I recently finished a project myself and I'd like to do more with e-ink but the hardware "driver" that plugs into the pi costs as much as the e-ink display.

Yes, it can get pricey. I'm using a Raspberry Pi Zero W with a Waveshare 7.5 e-ink panel, which came with its own raspberry Pi driver. I also added a PiSugar2 battery. Waveshare seemed to be the most affordable option out there.

I find the costs to be reasonable, but I just bought a Waveshare e-ink ESP32 controller to try boosting battery life, since I don't need a fully fledged OS. All I'm doing on the frame is pulling an image from an URL or displaying a local image if the connection fails.

This sounds like it could port well to an RP2040-based display. Though I am forever battling against its very constrained RAM for network stuff (not helped by MicroPython needing a chunk for buffers, an GC bitmap for mark/sweep and some other network mystery meat). That said our (Pimoroni) larger Pico W-based Inky has an 8Mbit PSRAM to act as a back buffer for the display. It’s “slow” but when updates take 30s+ anyway that’s kind of redundant. Very little of that 8Mbit is actually used, so with a little tinkering it might be able to cache multiple images for sequential display without having to faff about with SD cards.

Currently I transmute some images (XKCD and NASA APOD) via a scheduled GitHub action into something fit for the various display sizes. An even more extreme approach would be to convert into the packed (4bpp for 7-colour E-ink) framebuffer format server-side. Less network efficient, but more predictable memory usage.

We’ve had JPEG support for a while, but I brought up a PNG decoder (Larry Bank’s PNGdec) recently(ish) and it’s a much better fit than JPEG for palette-based images. It uses a 32K sliding window, however, which can get spicy if you’re not careful.

Thanks for the detailed reply, I'll look into all of this! Very interesting.

LilyGo T5 is a very cheap e-paper and also based on ESP32.

Reply on news.ycombinator.com