Epaper Project

[Marketta Filipovich]

Inthis post, I'll tell you all about how it's built, and how you can do it too. I won't describe everything, but point you to relevant documentations I followed. I'll also share tips and tricks.

I am using this 7.5 inch 2 colors screen from Waveshare. My initial plan was to go for a 9.7inch with gray levels, but I had no experience at all with that hardware so I went for the safer, 50$, solution.

Once you've done that, you're pretty much good to go! Find a 5V adapter and power up your Raspberry Pi! The nice thing is that your screen will feed off the Raspberry so you need only one alimentation. We're ready to move to phase 2!

I've decided to keep this in the hardware part, because I don't have much to say. What we will want to do on our Raspberry Pi is install a default OS that is not too old. You can create and flash one here by following the instructions.

The next thing you want to do is follow all the instructions described in the default Waveshare setup. Again, they are very well done so I don't have much to add but if you have any issue feel free to drop me a message.

This has a huge advantage : you only have to create a website and then deploy it on the device! You can find the complete code for the front and back end of the project here on Github. And the website is available at any time on Netlify.

Epaper.js can only be run on the raspberry. Indeed, it depends on native libraries (the GPIO drivers) that do not exist on your computer :). Not a problem, just something to be aware of (For example, don't set a CI on your project on Github).

Conversely, the latest version of Node that I could run on my raspberry is version 10.x, which means that I could not run the frontend code on it. Again, not a problem; just something to be aware of.

This part is the easiest to talk about. Keep in mind that for your own project, you can use any technology that suits you. The only requirement you have is that the result of your build lands in the static folder of the repository to be picked up by the backend.

I decided to use Web Components, and my website is based on top of LitElement and TailwindCSS. I used the excellent open-wc library to generate my project skeleton in Typescript. Those are personal choices, you may well choose anything you like.

I picked these because by using Web Components I had very little to learn on top of the basic capabilities of HTML. Thanks to tailwind I also didn't have to learn much CSS :). My knowledge is limited in the front-end, having a simple syntax, a boring technological choice and no build-chain seemed like a perfect deal. No need to screw around with Webpack

I created my whole dashboard by using $ npm start in the epaper-ui folder, running $npm build every time I was happy with the result. That pushed the built version in the static folder of my project and sent it over to Github. By pulling the repository on my raspberry, I can make sure to always have the latest version of the dashboard.

One last thing I want to mention before moving on is the way I refresh my dashboard :). The epaper.js examples has an example with data that updates. However, that data updates from the backend to the frontend. In my application, all the data is pulled from the internet via the frontend, which means that I cannot use the same mechanism.

However, it is not directly possible, because epaper.js supports stdin inputs (for buttons or keyboards). I looked around and decided to comment out the lines of code that handle stdin :). To do this, you can go on your clone of the project on the raspberry and in node_modules/epaperjs/index.js. You want to comment out the following line in the init function:

Overall, I'm extremely happy about the result of this side project and the choices I've made. Picking epaper.js, open-wc and tailwind has helped tremendously to iterate fast and be productive. Having a simple website that I can work with and deploy on Netlify at any time has been a tremendous help.

Because I don't need the interactions capabilities of epaper.js, I probably could get rid of the websockets altogether in the project and pull the website directly from the web instead of running it locally. That would be very interesting, because then I would automatically get the latest version of the dashboard every time I push a new version to Netlify. To be continued....

First blocker is: That LVGL does not provide a way to natively handle the 4 bit framebuffer that this epaper uses (16 levels of gray) But that is of course possible by using the set_px_cb callback (Of course paying a performance cost)

I tried this also. On the first refresh the touch area seems placed correctly over the button. I can see it also in Serial when outputting x and y from the Touch driver I2C. On next refreshes, as you can see in the video, there is some kind of offset happening. In that case the touch is displaced and below the button some millimiters.

More than an issue with the touch for me it seems the partial update that is not happening correctly. The first rendering is always fine and when there is full refresh usually too, the widgets demo in slide mode, works great and I can see all including Charts being rendered properly on this fast parallel epaper. The problem seems to be when I use partial update.

Please try this too: Create a button and in its click event place the button to a different position. It should also trigger partial refresh but a more simple and easier to debug one. Does it work this way?

Hello tried this and made a short video:

Updating the width is fine. Now if I try to change position it already messes up the framebuffer. That seems to be the issue. Initial drawing is fine.

Touch is working correctly. But redrawing elements that change position is a problem.

You use framebuffer but you should use the buf parameter. buf is relative to the current are being redrawn. So y = 0 means the first line of buf in flush_cb y will be 10 meaning to copy the buffer to y = 10 of framebuffer.

I have startet working with the Arduino Nano to create one of my ideas for a low power GPS receiver with e-paper display. The unit will be put into a waterproof case and used when kayaking. I want to see my location, heading, speed and the time of the last data received. Later on I am planning to add a radio transmitter which will open several exciting oportunities.

I have managed to create the receiver and put the location info on screen, but as the Nano has limited space i need some help shaving off a few Kb to make room for the next step. I'm trying to build the code modular in case i will change one of the units later.

As for the e-paper I got it working but I'm not sure that I'm using the most efficient code. Also I'm not sure if I really need to include all the items from the library; GxEPD2. I feel the display is blinking and refreshing more than needed. Not sure if I need the "do, while" combination in this code?

For the GPS I'm sure my code can be improved and will appreciate any ideas. I haven't managed to get the timestamp from the latest data. I tried taking code from the example, but I must be missing some understanding because I only got an error about to few arguments.

The ePaper displays do take a lot of memory as I recall, I did a project using one, and it was obvious (to me) at the start that the project was going to need more program space than a ProMini\Nano could manage.

Is the difference between an epaper program and an Oled program that big? I was hoping to use the epaper due to the low power consumption and visibility in the sun. For my application i don't need frequent updates.. maybe once a minute, and I find it nice that the text stays on screen even if the arduino sleeps for a while.

Thank you. I was not aware of that macro.

I've just read a little bit about it and as far as i understand it can only be used for things that will not change. Does that mean I can us it for static text, but not for any variables?

KnutMagne:

Is the difference between an epaper program and an Oled program that big? I was hoping to use the epaper due to the low power consumption and visibility in the sun. For my application i don't need frequent updates.. maybe once a minute, and I find it nice that the text stays on screen even if the arduino sleeps for a while.

As you can see, we have a large, 6-inch E-Paper display that can display 7 colors combined with an ESP32 microprocessor. Among all the e-paper boards I've used in the past six years, this is the best.

On the display, we show the temperature, humidity, barometric pressure, and weather forecast. We get the temperature, humidity, and barometric pressure from two sensors, and the weather forecast from the internet.

We also display some graphs here. A line graph that shows the temperature readings of the last 24 hours, a bar graph that shows the humidity readings of the last 24 hours, and a bar graph that shows the barometric pressure readings of the last 24 hours.

The last bar graph is the most useful of them all, in my opinion. We can take these values and, using a specific algorithm, the Zambretti algorithm, generate our own weather forecast. But that's a topic for another Instructable.

The board also features an ESP32 microcontroller with integrated Wi-Fi and Bluetooth connectivity. We can also find an SD card slot where we can store files and images to display on the screen. The board can be programmed and powered by a USB-C connector, and it features a battery charger and a Lipo Battery. Also, the board comes with a RTC clock module to keep track of time and reduce power consumption. As you can see, the board also gives us many gpio pins to connect our sensors and devices. The board also comes with a 3D printed enclosure, and the files are also available online if you want to modify them. What else could a maker ask for? Everything we want from hardware is here.

3a8082e126