E-Paper Weather Display Is A Great Base To Build From

As e-paper modules have become more affordable, we’ve started to see them pop up more and more in hacker projects. It used to be that you had to force a second-hand Kindle to do your bidding, but now you can buy just the screen itself complete with a header to plug right into your Raspberry Pi. It will still cost you as much as a used Kindle…but at least it comes with some documentation and there are Python libraries to talk to it.

But where to start? If you need some inspiration, and perhaps a little source code, this very slick weather display put together by [James Howard] is a great as baseline. Not that it really needs any additional refinement, as we think it already looks gorgeous. But rather than starting from scratch for your own project, it would be much easier to graft some additional functionality onto his code.

A lot of that has to do with how concise and well commented his code is. We’ve seen enough of these projects to know the kind of spaghetti that’s often running on the backend, but there’s none of that here. [James] assembles the display using the powerful Pillow graphics library, which lets you draw primitives and drop in text and icons with just a couple lines of code.

Once all the data is plugged in, the entire screen is saved as an image file which is then opened up on the e-paper display. Even if you aren’t a Python expert, you should be able to understand what’s happening and how to bend it to your will.

We’ve always had high hopes for electronic paper, and it seems the technology might finally be hitting critical mass. While it’s still a bit expensive, we’ve started seeing it pop up in unexpected places to great effect. Hopefully projects like this one will inspire others to take the B&W plunge.

26 thoughts on “E-Paper Weather Display Is A Great Base To Build From

  1. Looks great. I have considered using e-paper for a weather project but the slow refresh rate and possible burn in problem (as I have read) has made me avoid it at this time.

        1. Spit balling here: If certain pixels are selectively refreshed over and over again? I know that the lifespan of e-ink is measured by refreshes, but it’s in the millions, if not tens of millions. One would have to intentionally be trying to ruin it this way, and even then it would take a very, very long time. Admittedly, I’m hopelessly behind on my e-ink knowledge, school me if I’m way off base.

          1. The “burn in” described in the sparkfun-topic below is probably a software issue. The image will “bleed out” if the display is not properly shut down before power off.

            I have seen “burn in” in displays, but these can be fixed by refreshing the image a few times (like a “degauss” on old CRT monitors). I don’t know if this gets worse over time, but a refreshing the same image more than once definitely removes ghosts on the displays I’ve been working on (3-color).

        2. By some mechanism of charge build-up. When using a custom driver, I’ve seen burn-in like behavior after just ~50 partial refreshes. When the display is drawn white, the burnt-in image will slowly reappear.

          But in my experience it has been only temporary and leaving the display off for a day or two has removed the problem. Well balanced driving waveforms and periodic full refresh also minimize the problem.

    1. I have one connected to pi zero, almost three years. It’s refreshing around 40 times per day and no issue, still perfect and clear display. The issue can be if somebody keeps this screen in power on in the script. I suggest to follow producer script, especially what is on the end of it. The procedure is: wake up, refresh and next sleep mode.

    2. I wanted to build a small humidity display for my living room and thought e-paper looked interesting until I read the datasheet and saw you can only refresh it once every 180 seconds!

      1. What epaper was that the datasheet for? I’ve certainly not met such a limitation. The only kinds of ‘limitations’ I’ve seen have been in order to get a certain battery life, because epaper generally only uses power when it’s changing what’s on screen. So maybe a period of 180 seconds is what’s needed to give a month or a year of continuous operation with some specified power source?

    3. I built an alarm clock based on one of the PervasiveDisplays modules 3 years ago, and it’s remained “burn-in” free thus far.

      (Unfortunately I based it on C.H.I.P. https://github.com/jbaboval/eink-alarm-clock)

      You can end up with ghosting, but it is manageable. There’s a tradeoff between refresh rate and the amount of ghosting you end up with. You have to be willing to dig in and tweak whatever example drivers are provided for your display to tune the refresh timings to your application. Even then you still have to do periodic Kindle-style whole screen refreshes. But it’s completely manageable. Especially in an application like a clock where you can tie them into the UX anyway.

      They’re a fun device to hack on, because they’re a unique display technology, and the fact that not many people are using them yet leaves plenty of opportunity to explore novel solutions to their inherent limitations. Also, because they’re pretty slow you can interface to them easily at the lowest level.

  2. I wish I had an e-paper cabinet door in the kitchen to hold the recipe that i’m cooking. Refreshing my phone constantly to check ingredients when my hands are messy is annoying. As are the 1000s of ads and videos that obscure even the simplest recipe.

    1. They’re not just good as low-power devices. They’re also good because they’re reflective rather than emissive displays. They’re perfect when you want to display information without emitting any light.

    1. I agree, I looked at his code for a project (which I need to get back to), and while I might end up simplifying a lot of it, his code was the original inspiration.

      (One part stumped me for ages though; when sizing text he used “font.getsize(‘hg’)” for the height, and I couldn’t work out what ‘hg’ was supposed to be, is it a variable somewhere?
      No, of course, he was checking the vertical height of the letter ‘h’ next to the letter ‘g’, which between them extend furthest above and below the line.)

  3. Have a look at the Startup UZE-Mobility from germany (i am the data analyst at this company) :)
    They are using Color E-Ink Displays on cars, outdoor for geo-targetted ads – had to use e-ink to get approval in germany as light-emitting displays are not allowed in traffic (soon to come are LCD on international devices)

    (i do not own the company and dont get any money or want to make an ad here, just to show that e-paper gets used more and more and i am a big fan of the technology :D )

Leave a Reply to OstracusCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.