Vertical lines on the display

Hi,

I’m using a Inkplate 5v2. The other day (when playing around with black objects on the display) I noticed there were several persistent vertical lines/streaks visible on the right side of the display. I found the FAQ about artifacts on the screen and tried performing around 30 full black/white refresh cycles (the code example from the FAQ). I also tried disconnecting and reconnecting the e-paper display connector on the PCB side but unfortunately the lines remain unchanged. The lines are not visible when the display is white.

Could you please advise what else I can try, or whether the display/board may need to be replaced?

Hi @Ozwald

What platform is it running on? I assume ESPHome from your earlier posts? When you tried Arduino code did you also see the lines? If you didn’t check it there, could you try using a simple Arduino example such as:

#include "Inkplate.h"
Inkplate display(INKPLATE_1BIT); // or INKPLATE_3BIT for 3-bit grayscale mode

void setup() {
display.begin();
display.clearDisplay();
display.fillScreen(BLACK);
display.display();
}

void loop() {
    // Nothing needed here
}

Also, do the artifacts appear regardless of the display mode (black&white/grayscale)? You can also check that using the example, just replace INKPLATE_1BIT with INKPLATE_3BIT.

Yeah you are right, i’m running ESPHome. The lines were also visible when i ran the 30 cycle full-refresh Arduino code, i didn’t notice any difference there from ESPHome.

I tried the test you suggested and the artifacts appear both in black&white and in grayscale mode. It’s hard to tell but the lines might be a bit more appearing in grayscale-mode but just slightly.

I’m guessing you cant access the display connector on the “display-side” (if there is one) to try to reconnect that too?

Yeah, it looks to be damaged. For a replacement/return, contact us via hello@soldered.com email with your order number and either a link to this forum thread or explaining the issue.

Also, do you happen to know what might have caused it? or did it just show artifacts out of nowhere? Any detail helps us figure out what went wrong when we get the board back and maybe prevent it from happening in the future.

Okay, I’ll send you a email. Thank you!

When I first got the display I only used it with white background and small black text. It wasn’t until recently when I tried using black backgrounds I saw it. It might have been artifacts all along since you can’t see them when the display is white. I first took the board out from it’s case when I tried reconnecting the display, so it should have been fairly protected from physical damage.

Not much help, sorry!

I have noticed a similar thing on my display (Inkplate 6Motion). I did not notice it a first, but it became more evident after the heat wave of this summer.

Here is a snapshot of the appearance of the display.

Could the high temperatures produce this?

Hello Jean,
Does this happen when the panel is at room temperature aswell?

Yes, this is permanent and this picture has been taken yesterday with a temperature of 20°C.

One more question: Does it happen only when powered by a battery or also when it is powered via USB?

It happens in both cases.

Moreover, today the behaviour has suddenly degraded.

I use the partial update mode with a threshold of 50, with no gray scale (only black and white).

Today, it seems that the cleardisplay function does not work properly. At each display clearing, the display does not go blank, but instead the previous image is a little fainter than before, and a huge ghosting effect covers the screen. Here is a picture:

You see a superimposition of three different screen layouts that belong to my application. I tried to switch the board off then on, and though I did it three times, it got no better.

Of course, I have not changed the software that I have been testing for two months now.

Is this a hardware failure?

Hello Jean,

There is still one more thing to try, could you please try disconnecting and reconnecting the panel connector on the back? It may have gotten loose during development and is causing the artifacts you are seeing.

The black plastic part acts as a flap mechanism, lift it up and take the ribbon cable out.

Also, has the cleaning of the display also stopped working when in grayscale mode. Does it also clean badly in 1 bit mode when a simple partial update sketch is uploaded to it?

I took the ribbon cable out, then re-inserted it. Then the display was dead: the application ran normally, but without any change on the display.

I then removed the ribbon cable again, and thouroughly and firmly inserted back in, then closed the flap, and this time the display worked again, but with no improvement.

But I carried on, to improve the contact between the ribbon and the connector by gently pulling and pushing the ribbon while half-closing the lid to sort of clean the mating surfaces. This time, the clearscreen had some effect, that is, the previous black areas were not erased, but faded somewhat.

I then displayed a layout where some numeric value change continuously, and at each full write, the previous black areas faded so as to disappear almost completely after about ten full writes.

My application is strictly 1-bit, with no gray shades. The gray shades you see on the picture is only due to ghosting.

I remind you that this happened this morning while using it. I started to observe ghosting suddenly, and this got obvious when switching one display layout for another: then I got two superimposed images. But again, this morning when I started it, the display was ok.

+++++++++++++++++++++

I must also tell that I observed another problem, which occurred several times.

I have a configuration parameter that is stored in simulated EEPROM. Each time I switch the device on, this value is read back from EEPROM.

However, most of the time, I do not switch it off at night. I just connect the charger to be ready for the next morning. This morning I routinely checked the configuration, and noticed the value had changed. This happened a few times already, and I have no idea of the cause.

This did not bother me too much as recalibrating is easy, but if a RAM value changes unexpectedly, how many other RAM values can do the same?

Unfortuately it does seem that the panel itself has been damaged. For a replacement/return, contact us via hello@soldered.com email with your order number and either a link to this forum thread or explaining the issue.

Regarding the simulated EEPROM, that seems like a problem regarding the STM32H7 chip itself (if it is being allocated within its SRAM), thus it may be better to report the issue to the ST forums in regards to that. No memory is being rewritten by our library at any point (at least not to the point where it would interfere in already allocated space).