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

145 points by robocollab 4 years ago | 12 comments
  • sdfhbdf 4 years ago
    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.

    • lukehaas 4 years ago
      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.

      • taf2 4 years ago
        Thanks I like the idea of a git pull on boot up.
      • gregod 4 years ago
        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...

        • robocollab 4 years ago
          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.
          • capableweb 4 years ago
            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.
          • Waterluvian 4 years ago
            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?
            • leetbulb 4 years ago
              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.
              • mekkkkkk 4 years ago
                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.
                • robocollab 4 years ago
                  The Waveshare displays do support partial refresh, but I haven't had time to look into exposing it into Node, yet.
                • clnhlzmn 4 years ago
                  Here is a good video on that subject:

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

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