EPDiy: 9.7"/6" E-Paper controller

I always wanted a large, affordable E-Ink screen to play around with. This board talks to cheap E-Reader replacement screens with an ESP32.

Similar projects worth following
EPDiy is a driver board which talks to affordable E-Paper (or E-Ink) screens, which are usually sold as replacement screens for E-Book readers. Why are they interesting?
* Easy on the eyes and paper-like aesthetics
* No power consumption when not updating
* Sunlight-readable
Ready-made DIY modules for this size and with 4bpp (16 Grayscale) color support are currently quite expensive. This project uses Kindle replacement screens, which are available for 20$ (small) / 30$ (large) on ebay!
The EPDiy driver board targets multiple E-Paper displays. As the driving method for all matrix-based E-ink displays seems to be more or less the same, only the right connector and timings are needed. The EPDiy PCB features a 33pin and a 39pin connector, which allow to drive the following display types: ED097OC4, ED060SC4, ED097TC2For more information and a full documentation, visit the documentation!


Want to know how to use the board? Check out the ESP-IDF component API.

Want to know more about the supported boards? Have a look at the documentation.

Build It!

KiCad-Project, Gerber files and firmware can be found on github:


  • 4bpp (16 color) output in ~500ms (at 1200x825 resolution, faster for partial updates)
  • Simple, 2 layer PCB with all components on front (Optional connector for 6" EPDs on the back)
  • Small form Factor
  • Onboard temperature sensor
  • Broken out SPI and sensor pins
  • High-level library for own software ( This is still work in progress!)

Thanks to:

Thanks to the work of some awesome people, the hard stuff was already done:


Demo of a terminal application on an ED097TC2.

MPEG-4 Video - 14.50 MB - 11/18/2020 at 14:44


MPEG-4 Video - 15.92 MB - 06/02/2020 at 18:06



A short demo video.

MPEG-4 Video - 2.35 MB - 04/21/2020 at 17:00


  • Further Development

    Valentin03/27/2021 at 21:12 0 comments

    Although I haven't been posting updates here lately, that does not mean that I was inactive. Since the last project log, a lot of improvements landed:

    •  A new hardware revision (V5) that adds connectors for additional display types, LiPo battery charging and very low deep sleep current.
    • The driver library can now use the vendor wavefrom files (.wbf waveforms). Unfortunately, these are not easy to find, but some are scattered around the web. It would be nice to analyze them and build our own waveform files one day, which can be freely distributed.
    • The board can now be programmed with the Arduino IDE.
    • An improved API and other minor changes.

    So, If you want to keep up with the development of this project, I suggest to keep an eye on the GitHub repository. Or even better yet: Join or Matrix / Slack channels where we discuss further development, show projects and exchange ideas.

  • A New Revision

    Valentin10/29/2020 at 11:59 0 comments

    First, let me say thank you for all the contributions and suggestions which where contributed to the project GitHub Repository. It is great to see that this project sparks your interest and to learn about ways to improve it even further!

    Based on this, a new revision of the board where developed (Actually there where two "Revisions" since the last project log, so this latest one is called "V4"). The main focus here was to be more power-efficient to enable battery-powered applications. To achieve that, two LT1945 converters are used to derive the necessary voltages instead of using additional linear regulators. This comes at the cost of more parts overall, however, the LT1945 chips are available cheaply from AliExpress and most additional parts are basic parts which should be available at many chap SMT assembly services. Additionally, a less power-hungry LDO is used to power the ESP32.

    So overall, the improvements over revision V2 include:

    • Deep sleep current of ~80uA if powered with 3.7V and the display attached. If the display is attached, deep sleep current rises to ~440uA and I am not quite sure why, yet. Any suggestions are welcome :)  

      If powered via 5V, unfortunately the p-channel mosfet which is used to gate the booster power might still turn on, which increases sleep current to ~340uA without display. This could be fixed in a future revision, but for most battery powered applications a lower voltage is used anyway.
    • Slightly faster drawing (-80ms for a full 16bpp frame, -100ms for a clear cycle) at the expense of one broken-out output pin.

    The PCB and updated firmware library are now available on GitHub!

  • Bigger is better?

    Valentin07/17/2020 at 21:24 2 comments

    When it comes to E-Ink screens, bigger is better, right? One of the goals of this project was to be able to step up from the 6" screens of previous designs to 9.7" Kindle screens. But why stop there?

    E-Ink makes even larger screens, with the next size being 13.3" panels. So compared to 9.7" panels, they have about double the surface area and are roughly A4-sized. These would be very nice for E-Paper dashboards and the like. I also want to build a portable E-Ink terminal, so this would be perfect, right? Well, it depends. But I'll go into that later.

    First: How do you get such a thing? This was actually quite difficult. Yes, E-Ink offers these Modules on their Website as samples, but 500$ was just not worth it for me. When you request quotes from some big suppliers, they usually ask how many thousand pieces you want.

    But then, I stumbled upon a listing for a 13.3" E-Ink screen on AliExpress, with the model number PENG133D. Of course, there is absolutely no information available under that name, but the picture looked awfully like the E-Ink ED133UT2. Additionally, since E-Ink still holds some Patents and is afaik the only manufacturer currently capable of producing these screens, there is not much else it could be. So, a friend and I decided to spend the 200$ on an experiment. Still not cheap, but this is probably as cheap as these screens go, considering they are not mass-produced in an order of magnitude the Kindle screens are.

    When I received the display, aside from the label, it seemed to be indistinguishable from the ED133UT2. It features the same connector as the 6" screens, however some pins are wired differently, so just connecting it directly to the V2 board will create a short through the display! So, I had to design an adapter board first, which is then bridged to the control board. If the setup in the picture looks hacky, that's because it is:

    The current revision of my adapter board has the connector facing the wrong way, requiring the cable to be connected to the rotated adapter board. Furthermore, 33pin FFC cables are not available at any local electronics shop, so I used a cable from an old laptop and cut it down to 33 pins. Then, just to be sure, I hacked my prototype board to use 5V for the boost converter (In the current gerbers, there is a jumper for that).

    Adapting the firmware to get a first picture was actually quite simple, though I have not yet calibrated the grayscale timings.

    But: Is it worth it?

    Well, it depends. 200$ is a lot of money for a screen. Well, compared to a Dasung Paperlike E-Ink monitor which uses the same screen and costs 1000$, this is way better, but nevertheless. And for that price, it suffers from some problems:

    • It's on a glass substrate. So if you want to build a mobile application,
      you'll need a tough case to support that thin, A4-sized glass panel.
    • It has a glossy surface finish, somewhat invalidating the sunlight-readability we expect from E-Ink.
    • Those flimsy flex PCBs have to be mounted somehow.

    There actually is a version on Plastic substrate and with anti-glare surface finish, the ES133UT2. If someone knows a reasonable way to get by these, please let me know :)

    Firmware support and the KiCad project for the adapter will be published after some more fixing and testing.

  • Terminal Example and other Improvements

    Valentin06/02/2020 at 18:19 5 comments

    During the last weeks, various improvements to the software and hardware where made, in part thanks to contributions from the Hackaday community. The highlights include:

    • Further drawing speed improvements: A full screen draw is now just under 500ms, partial draws can be much faster!
    • @Sebastius made the PCB more robust and versatile by adding the option to run the power supply on 5V or 3.3V via a jumper, adding a test pad for VCOM and improving the ground plane connections.
    • Fonts can now be rendered in any (4 bit grayscale) color and can be drawn on a background. This was essential for the terminal example.

    The Terminal Example:

    What you see here is a (almost) complete terminal (actually a port of the simple terminal from, running on the ESP32! Currently, I'm using it to mirror a terminal emulator through `script -f /dev/ttyUSB0`, but I'm working on hooking up a laptop keyboard to make it fully stand-alone!

  • Software at last...

    Valentin04/22/2020 at 12:08 0 comments

    Now that my v2 PCBs have arrived and I have assembled a test board, it turns out most of the work is actually software. But first: This is how the new version looks like:

    As you can see, the new version is much more compact. Additionally, there is now one component on the back side: The connector for the ED060SC4 is optional, to be populated if needed. Currently there is no software support for it, but I'll fix that in the following days.

    Actually, writing the software driver is taking a lot more time than I anticipated. Part really was just experimenting, figuring out the functional details of the ePaper screen and familiarizing with the ESP32.
    Another one was rewriting all my display routines to use buffers with 4bit per pixel (instead of 8), for better memory efficiency and faster display (which is still somewhat bound by memory speed).

    But I also wanted to make sure the board is actually usable by others, which is why I am currently working on re-structuring and documenting the driver. You can get a preview of the displays' capabilities here: Or watch the updated demo video :)

  • v2 underway!

    Valentin03/21/2020 at 10:31 1 comment

    Over the past few days, I've been working on a revised PCB. It is now in production, so given international shipping will continue in the following weeks I'll soon be able to test it!
    The following improvements over the original version where made:

    • Switched to the ESP32-Wrover Module, which features 8MB PSRAM. This allows to hold full frame buffers in memory.
    • A footprint for an optional connector for the ED060SC4 6" E-Paper display was added. This should allow for driving either a 9.7" or 6" display with the same board!
    • As some ESP pins are now needed for the PSRAM module, some configuration pins where moved to a shift register.
    • A temperature sensor was added to be able to (in theory) adjust the driving waveform to the environmental temperature.
    • Smaller PCB outline of ~100mm x 32mm.
    • The board can be powered directly through 3.3V (without USB) for lower power consumption.
    • Instead of I2C, a full SPI port is broken out.

    Meanwhile, there are still some things to improve software-side: Currently, the refresh time of about 1100ms is mainly bounded by the ESPs flash bandwidth. With better data encoding / compression, it could be lowered even further.

  • Font Rendering and Partial Drawing

    Valentin11/18/2019 at 21:44 0 comments

    Now, finally I implemented what these displays where originally designed for: displaying text. Unfortunately, the ESP32 does not have enough RAM for a real frame buffer (maybe a version 2 will use a module with PSRAM). So, I have to resort to partial refresh / drawing. 

    For the image shown above, I first displayed a full-screen grayscale image as usual. Then, I cleared the middle area and proceeded to draw the text line-by-line. If you screen content does not need to be updated often, this should suffice. Otherwise, you can always stream frames via wifi.

    For my tests I used the latin1 character set and the Fira Sans font, however, this is completely customizable.

  • ESP32 timing

    Valentin11/01/2019 at 11:32 0 comments

    Hello World! Finally, the project is ready to go public. If you have any ideas, improvements or comments to share, feel free!

    During the last days, I struggled a bit with getting the timing for the gray scale output right. Each row has to be activated for a only a few microseconds to only dim it slightly. While this worked most of the time, sometimes, the code took much longer, resulting in dark horizontal stripes. Debugging this was quite a journey, since I was new to the ESP32:

    • Coming from the world of Arduino, having a real-time OS running on the chip was new. Disabling interrupts during the critical sections helped, the fact that the noInterrupts() function of the Arduino framework for the ESP32 is just a dummy did not.
    • At this point, most bad stipes where gone, but timing was still somewhat irregular, even when using the hardware timer. I thought using hardware timer interrupts is as good as it gets when trying to do exact timing, but apparently I was wrong. If someone has an idea why this could be, please tell me!
    • Finally, tagging the critical function with IRAM_ATTR and busy waiting for a set number of CPU cycles did the trick.

    Busy waiting does not seem like the most elegant solution, but it works. Refresh times are now at about 2 seconds for a gull grayscale image of 1200x825 pixels. If I could manage to already shift in new data while waiting for the current row to fade, this could be even faster. I'll have to try some things :) 

View all 8 project logs

Enjoy this project?



rubokahd wrote 01/05/2023 at 17:45 point

I play in a little orchestra and others are using a big ipad, or a usb c external monitor for displaying their music sheets. I always have thought maybe an e-ink display would be nice for this usecase. 13" are perfect .
But it seems those model numbers are not being sold anymore.
Do you have any information where I could look for alternatives?

  Are you sure? yes | no

Lanistor wrote 01/08/2022 at 16:56 point

Will this project support lvgl?

  Are you sure? yes | no

Martin Fasani wrote 12/09/2021 at 07:47 point

Started trying this with version V5 and now I have one last V6 at home, both work very nice.
If someone is interested in reading books with this, I'm collaborating with an ESP32 Epub reader project that uses EPDiy:
Other than that I collaborated with the codebase adding software rotation a while ago and I must say is one of the ESP32 Firmware's that I most admire. Keep it up!
I would be interested in making a new PCB in 2022 that uses ESP32-S2 with more GPIOS. Will be slower since it has only one CPU, but maybe with some good luck, we could drive also 16-bus epaper displays. If someone is interested to help just get in touch!

  Are you sure? yes | no

Sani300 wrote 09/28/2021 at 15:00 point


Did you think that it will be possible to modify software to support ED078KC1 e-ink Display? 7.8" 16 bit parallel vs 8 bit parallel with 6" display. 

  Are you sure? yes | no

Valentin wrote 10/04/2021 at 21:20 point

This would definitely require changes to the hardware, not only software. Unfortunately, the ESP32 does not have enough pins left for a 16 bit bus. But maybe one of the newer ESP chips could work. You would need to design a new board though.

  Are you sure? yes | no

halverson.peter wrote 02/07/2021 at 06:04 point

Thanks for this project. Have you had much interest in preassembled boards? I would love to purchase one. 

  Are you sure? yes | no

Valentin wrote 02/24/2021 at 09:44 point

Sorry, I'm not currently selling boards. But you can have a look at the documentation on how to order boards. Or you can ask around in the matrix/slack channel if someone wants to order with you or can help you :)

  Are you sure? yes | no

Sani300 wrote 01/06/2021 at 12:59 point


Thanks a lot for this project, this is very impressive ! Do you have make retro-engineering or you have acces to datasheet/protocol e-ink? 

Did you use LCD peripheral controller on esp32 or we can drive a e-ink display with simple GPIO ?

  Are you sure? yes | no

Valentin wrote 01/28/2021 at 10:44 point

Sorry for the late reply, hackaday didn't notify me.
If you search around for data sheets you can find some information on the signals. The resources under "Thanks To" are also quite helpful.
For sending out the data I use the I2S peripheral in LCD mode. If you're interested in the details it's all in the code on github ;)

  Are you sure? yes | no

frederic.confidentiel wrote 07/29/2020 at 06:16 point


So great project ! I'm very interesting with your work.

Before starting, would you please tell me :

* could it be possible to use the controller board with more than one display ? for example to make a bigger display with 2, 3 or more "little" displays

* could it be possible to drive the controller board with a rpi and without esp32 ?

Thanks for your answers :)


  Are you sure? yes | no

Valentin wrote 07/29/2020 at 09:43 point

The controller board is currently designed to only drive one display at a time. However, you could use multiple controller boards and program them to receive data over SPI or Wifi and have a Raspberry Pi split the images and send them to the controller.

The ESP32 is needed as a controller, as the display needs some precise timings, which are not possible to achieve with a raspberry pi running an OS.

  Are you sure? yes | no

Valentin wrote 07/29/2020 at 09:45 point

On driving multiple displays: You could design a multiplexer board, which simply switches from one display to another. This might be less expensive, but you might need to put in more work and you cannot update the displays in parallel.

  Are you sure? yes | no

frederic.confidentiel wrote 07/29/2020 at 15:41 point

Thanks for your quick answer :)
No need for speed nor for parallel update for my project, so a multiplexer board seems to be a very nice solution.
Is it difficult to switch from ESP32 wifi mode to SPI mode to send/receive data with RPi ?
The multiplexer board could be a simple SPI interface cable with direct connection up to 2 or 3 displays (RPi limitation) or with daisy chained connection for more displays. Couldn't it ?

  Are you sure? yes | no

Valentin wrote 07/30/2020 at 09:18 point

@frederic.confidentiel Just to clarify: The displays don't speak SPI, to the controller they basically look like some shift registers and control signals.
So, such a multiplexer would connect the 33 output pins to the display to 4 connectors in parallel and  add some logic to gate clocks, enable signals and driving voltages to only affect the connected device.

How you get the image data to the ESP is up to you, SPI and WIFI are just examples. You would need to implement a simple firmware based on the provided library to receive and display the data.

  Are you sure? yes | no

Sergei Semenov wrote 07/09/2020 at 07:26 point

Great project! I really want to give a try, but i've never played with soldering. Time to start =)

  Are you sure? yes | no

Mike wrote 06/23/2020 at 10:09 point

Hi, can someone help me and tell what i did wrong? :)

Same issue with dragon demo, middle part of image is taken from right 1/3 of screen

  Are you sure? yes | no

Mike wrote 06/24/2020 at 07:00 point

Can it be hardware issue? Not sure, seems we send data to display row by row and this row just got corrupted. Played with software but with no luck. Maybe @Valentin  have some idea... looks like some memory issue with my ESP (it has rev 0).

  Are you sure? yes | no

Mike wrote 06/25/2020 at 10:25 point

So, I'v made second board to make sure it is not some soldering issue. And got the same problem. Poor dragon with 2 tails :( Now I think about 3 possible reasons:
1) wrong gerber files from June 04 2020 (seems very unlikely)

2) I got wrong ESP module (ESP32-WROVER - also very unlikely)

3) ESP-IDF issues on Windows (tried Cmake 0.13 which comes with it by default and 0.18 -same result)

4) my hands - very likely :)

Will keep you posted and thanks for good and interesting project!

  Are you sure? yes | no

Mike wrote 06/25/2020 at 14:30 point

Now I'm surre there is software bug.

Here is poor dragon with default EPD driver 

dev->fifo_conf.tx_fifo_mod = 1;

Changed this to

dev->fifo_conf.tx_fifo_mod = 0;


I now have 2 dragons but without missed parts

Unfortunately I'm not good ESP32 developer yet, but there is something for sure with I2S and DMA in driver

  Are you sure? yes | no

Mike wrote 06/25/2020 at 15:38 point

or maube i have ESP32-WROVER instead of ESP32-WROVER-B.. ?

  Are you sure? yes | no

Valentin wrote 06/26/2020 at 15:01 point

Sorry, somehow hackaday does not send me notifications sometimes... Let's try and resolve this via Github ;)

  Are you sure? yes | no

Sebastius wrote 05/24/2020 at 22:21 point

Spent the weekend building two boards according to the latest files, and they both work! My compliments to your work so far. I'll try and contribute a nice complete BOM soon, and make it nice and LCSC compatible. Sadly they lack the LT1945 chip and i haven't found the ED060 displayconnector AXT334124 equivalent yet.

Have you looked into dedicated PMICs for eink, like the TI TPS65186 ? I've made a board with it but i can't get it to run yet.

  Are you sure? yes | no

Valentin wrote 05/25/2020 at 09:08 point

Nice to hear that :)
I have, briefly. But they seem fairly expensive, only come in unwieldly packages. They could be nice for energy efficiency though.
For the ED060 connector I used the Hirose FH26W-39S-0.3SHW, which seems to be widely available.

  Are you sure? yes | no

Sebastius wrote 05/25/2020 at 09:17 point

unwieldy is relative, with a bit of paste and hot-air its pretty straight-forward soldering. Cost is a factor, but the reduction in the number of parts and the improvement in efficiency might be interesting. 

The Hirose connector you mention seems to be a different pitch compared to the panasonic one. But hey, if they work :D

  Are you sure? yes | no

Simon Merrett wrote 06/17/2020 at 21:02 point

@Sebastius would you be able to measure how low the current can be in various modes? If so, please could you share some readings? @Valentin said he wasn't able to make decent measurements with his equipment. 

  Are you sure? yes | no

Sebastius wrote 06/17/2020 at 21:20 point

I probaly have all the tools, but no idea where to begin to do current peak measurements using my oscilloscope. Will look into it.

  Are you sure? yes | no

Simon Merrett wrote 06/17/2020 at 21:27 point

@Sebastius that would be great, thank you. Do you have a multimeter with current measurement? Personally I'm more interested in sleep current with RTC running for periodic wakeup and refresh, so if you had it in permanent sleep or long duration sleep you wouldn't need the time resolution of the oscilloscope (for my request).

  Are you sure? yes | no

Max M Fuhlendorf wrote 05/24/2020 at 08:52 point

Im a biology graduate with an undergraduate degree in computer sciences but the electronics go way over my head... I LOVED your project though, but while I'm very comfortable with its software side, the hardware is intimidating. 

Could you point us in the right direction on where to start learning how to actually order and build this esp32 board version?

  Are you sure? yes | no

Valentin wrote 06/12/2020 at 09:44 point

Sorry for the late reply... You should be able to just upload the zipped Gerber files to a manufacturer, then order the components and solder them on. Or you find someone else who is interested and you order together? I also thought of maybe setting up a tindie store in the future, but I don't want to promise anything here.

  Are you sure? yes | no

Paul wrote 05/23/2020 at 23:56 point

Awesome project! I've been eyeing it for a while.

Are you planning to sell pre-made boards? That would make acquiring one considerably easier for me.

  Are you sure? yes | no

Valentin wrote 05/24/2020 at 19:42 point

I'm thinking about doing that in the future, seems like the requests for boards keep coming...

  Are you sure? yes | no

Camilo Alvarez wrote 05/21/2020 at 15:12 point

Love the project, been trying to work myself with recycled e-paper displays for a while. 

May i suggest something. Separating the interface part of the design with the control part. That way it could be a cheap / easy to manufacture connector  with  through hole and connect it to an  already mass produced esp-32 module like the NodeMCU

  Are you sure? yes | no

Valentin wrote 05/24/2020 at 19:41 point

PaperBack has done something like that for a smaller display. However, the integrated design was deliberately chosen to obtain a smaller form factor. Furthermore, most of the pins of the ESP32 are in use and the software requires the SPRAM on the wrover module (not the wroom module as on the NodeMCU).

But feel free to modify the design to suit your needs ;)

  Are you sure? yes | no

Szymon Masternak wrote 04/27/2020 at 12:46 point

Whats the power consumption when in deep sleep and when updating the display?

  Are you sure? yes | no

Valentin wrote 05/02/2020 at 10:29 point

That's a good question I hope to investigate when I have the time. However, I don't know if I can make reliable measurements with my equipment...

  Are you sure? yes | no

Jürgen Skrotzky wrote 04/13/2020 at 13:43 point

Wow V2 sounds great. Looking forward to the progress. Really want to use this for my kitchen to display some info.

  Are you sure? yes | no

Boa wrote 04/03/2020 at 21:30 point

Hi, I'm kind of new to low level stuff so sorry if I ask stupid questions. Would it be possible to use a arduino uno or rpi zero instead of the custom pcb? If so what hardware and software modifications would I need to do?

  Are you sure? yes | no

Valentin wrote 04/10/2020 at 16:02 point

The Arduino Uno does neither provide enough IO nor has the resources to drive a display like this (Maybe, if you stream in the data, you could do it veeery slowly).
An RPI on the other hand has a full operating system running, which makes it hard to drive signals which require exact timing.
So, what you would normally do is use a controller board (such as this one ;)) and use a RPI oder Arduino to interface with it.

  Are you sure? yes | no

Jürgen Skrotzky wrote 02/20/2020 at 19:49 point

Congratulations for this awesome project!

I would like to have something similar - but using the 6" Kindle display - I think it is the ED060SC7.
Is it possible to connect it to your board?
Thx and best regards,


  Are you sure? yes | no

Valentin wrote 02/20/2020 at 21:23 point

Hi, glad you like it. Unfortunately, the SC7 uses a different connector than the OC4 (34 vs 33 pin FPC with different pitch). However, as far as I know the driving mechanism for these displays is nearly identical for all models, so you might be able to just swap out the connector. I don't have a SC7 to verify though.

  Are you sure? yes | no

Jürgen Skrotzky wrote 02/22/2020 at 21:09 point

Thx for fast reply. I will dig into google to find more about it. Maybe I found an used and cheap 9inch screen 😅

  Are you sure? yes | no

Vadim Radu wrote 01/07/2020 at 13:53 point


Congratulations for your project, it's very nice.

I'm working on something similar. Can you share some info regarding the MODE1 and MODE2 pins? what are they used for and why did you tied them to a GPIO?



  Are you sure? yes | no

Valentin wrote 01/10/2020 at 21:36 point

Hi Vadim,

Sure, but may I known which display you are using? As far as I know, only the ED60SC4-Displays have MODE1 and MODE2 lines. The display I'm using is a 9.7 inch one and has only one MODE line, which is just wired to a GPIO, as drawn on the schematic ;)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates