Show HN: ePaper.js – Easily create an ePaper display using JavaScript and HTML | Hacker News Reader

Show HN: ePaper.js – Easily create an ePaper display using JavaScript and HTML

github.com

145 pointsrobocollab12 comments

Looks very cool and promising.

I'm wondering what's the power draw for the Pi with this one since it "Loads index.html in a headless instance of Chromium, using Puppeteer". Isn't Puppeteer quite a power hungry process?

Would it run on Pi Zero with a battery attached and how long would it last with updates once a minute or once every 5 minutes?

I'm thinking about possible projects that would not have AC power all the time, maybe something solar powered for a dashboard outside.

I built something that's similar to what you're describing, here's an article about it: https://www.hackster.io/lukehaas/e-ink-display-for-daily-new...

It combines a Pi Zero with a 2000mAh lipo, updates every 6 hours and lasts for around 90 days per charge.

Thanks I like the idea of a git pull on boot up.

Quick idea: even though Chromium (not Puppeteer) is quite power hungry, you only need to run it once every update period and then take a archive/dump of the output that gets fed to the screen, then use this cache copy while shutting down Chromium.

It would be pretty easy to modify the chain of command to have the backend start and stop the Chromium process. I haven't taken any detailed measurements, yet, but I'm guessing simple web pages like the example weather dashboard aren't too CPU intensive to render.

I have used an low-power ESP8266 together with a native drawing library for this use case. As getting the drawing perfect is quite cumbersome i have mocked the graphics library in javascript using the canvas api [1].

The syntax is so similar that you can mostly copy and paste the drawing code between js and the arduino project with only a few adjustments. This has the huge advantage that you can use modern JS dev tools including livereload to get the drawing right while still ending up with native code.

[1] https://www.godberit.de/2019/11/08/Mock-for-ESP8266-graphics...

When using my reader, sometimes mutations require a full screen invert. Sometimes stuff just seems to change trivially. What governs that? Is that done by the display or driver or higher level code?

The problem with e-ink is that redrawing pixels without cycling leads to ghosting after a few draws. Most displays automatically cycles the entire screen now and then to mitigate this. I guess it's up to software or firmware to detect when to do it.

The Waveshare displays do support partial refresh, but I haven't had time to look into exposing it into Node, yet.

In my experience with Waveshare e-ink displays, it's up to the application when to perform a full or partial refresh. Generally after so many draws, ghosting begins to appear and so you perform a refresh.

Application driven. KOReader (which I use on my Kindle) lets you even configure this to every X pages.

Here is a good video on that subject:

https://www.youtube.com/watch?v=MsbiO8EAsGw

Reply on news.ycombinator.com