Inkplate 10 screen corruption after weeks of use with partial updates

TECHNICAL SUPPORT Inkplate
1

Customer:

I’ve been using an Inkplate 10 with enclosure as a wall panel in 3bit mode, updating every 10 minutes. After a few weeks, I noticed screen corruption affecting about 1/4th of the screen. I ran the Diagnostics/Inkplate10_Burn_In_Clean sample to try refreshing the screen, but the corruption persists even during that operation. Is this repairable on my side or has the screen failed? What’s the best way to fix it?

Originally submitted via email support on 22 April 2024. Migrated to the forum for community visibility.

2

Soldered Support:

Could you please send a photo of the back of the board? We suspect it may be the TPS ePaper power supply chip causing the problems. Once we see the picture, we can determine if it’s something that can be fixed via software.

3

Customer:

Here are photos of the back and front of the board.

4

Soldered Support:

Are you using eInkOn and eInkOff functions in your personal code? This could have damaged the panel. We suspect a hardware failure of the TPS ePaper power supply chip. Can you share your code?

5

Customer:

I haven’t used eInkOn/eInkOff, but I have used deep sleep according to examples. Here’s the code I’ve been running - it downloads a PNG from an HTTP endpoint every 10 minutes and goes back to sleep: inkplate10-hass-dashboard/inkplate10_pic.ino at master · izacus/inkplate10-hass-dashboard · GitHub

If the power supply has failed, can it be replaced or is it integrated into the display itself?

6

Soldered Support:

I noticed in your code that partialUpdate(false, true) is used, which leaves the ePaper on for faster refreshes. There doesn’t appear to be an eInkOff before going to sleep to turn off the ePaper, so it may have been powered on the whole time.

See this example: https://github.com/SolderedElectronics/Inkplate-Arduino-library/blob/master/examples/Inkplate10/Advanced/Other/Inkplate10_Faster_Display_Refreshes/Inkplate10_Faster_Display_Refreshes.ino

This example demonstrates that eInkOn should be used with faster refreshes. It appears your sketch doesn’t do this, so the ePaper may have been left on. We’ll open a GitHub issue about this.

The ePaper display can potentially be replaced. Compatible ePaper models for Inkplate 10 are:

  • ED097OC1
  • ED097OC4
  • ED097TC2
7

Customer:

I’ve checked the code again - the screen was never actually left powered on for more than a few minutes after partialUpdate. The normal code path uses display.display() and that’s what runs most of the time.

Also, I haven’t found any mention in Welcome to Inkplate’s documentation! — Inkplate docs documentation that using partialUpdate with leaveOn could cause damage. The fact that the screen can be damaged by following instructions in the official SDK docs is a serious problem. The documentation should include a clear warning that the screen must be shut off to prevent damage. Nothing around partialUpdate() or eInkOn/eInkOff implies anything dangerous.

I’ll look for a replacement display. Thanks for the help.

8

Soldered Support:

Using leaveOn for a prolonged amount of time could potentially be what caused this issue, but we can’t be 100% certain. ePaper wasn’t designed to be on all the time, so leaving it powered on enters undefined and unpredictable behavior territory.

You’re right about the documentation - we’ll be adding warnings to the readthedocs and the Inkplate examples in the code comments. Thanks for pointing this out.