Black areas not rendering correctly- 5.83" screen

[txoof]

I am using a 5.83" waveshare screen with a pi-hat. The HAT is set to "Display Config: B" and "Interface Config: 0"

When I purchased the screen it worked very well and all of the tests in this library worked appropriately. Over the course of my development cycle (about 2 hours of use per day), the display inconsistently renders black areas.

The boxes produced here from the test script should render 100% black

The text produced here from my own script following the examples should (and have in the past) rendered 100% black, but now render as pale outlines:

This white text on black background should render without any streaks, but renders with vertical streaks:

When the screen is refreshing or initializing, the black appears perfectly solid with no defective or gray areas, so I do not think the screen is damaged:

What can cause this behavior? Can you offer any suggestions of how to fix this?

[txoof]

I've done more investigation.

The panel is not the problem.

I hooked up the panel to a 2.7" B Pi HAT using the ribbon cable and everything worked as expected with proper deep blacks everywhere.

I also hooked up the e-Paper HAT that shipped with the 5.83" display using the wire harness connector as per the instructions on the wiki. The panel worked flawlessly.

For good measure I also hooked up the panel using Female-Male jumper wires from the male headers on the Pi directly to the female sockets on the HAT. I ONLY used the pins specified in the Wiki. Once again, everything works perfectly.

Plugging the HAT directly into the Pi headers is the only situation where this does not work properly.

Is there a schematic for the e-Paper HAT available somewhere? Perhaps there's something weird happening with one of the unused PI pins that's interfering with the HAT.

Can you suggest any other possible troubleshooting steps I might take to figure out what the problem is? I think I'll just order another e-Paper HAT, but I'm afraid I'll have the same issue.

[dev-ng]

I have same problem. Running 7.5" panel with PI Zero/Python. I started my project end of August and it ran fine for about 2 months. Then I noticed left half of the screen renders pale content. And it became worse with every day.

My project (weather + calendar dashboard) updates the screen every 15 mins. Btw, it takes about 40-60 sec just to refresh the screen (I suspect it's whether HAT is too slow or my Zero). So it does full clean up of the screen for 50 sec and then draws my image for another 50 sec - I find it very slow. Can anyone confirm the same?

Back to the topic, I cleaned up the screen, disconnected power from RPI, and let it cool down for about 12 hours. After new start the picture was much better. And now it's getting worse again.

[txoof]

@dev-ng
I haven't let mine run for more than a few hours at a time and over heating does not appear to be an issue. The 5.83" screen takes about 3 seconds to update completely; I find this satisfactory.

I my problem to be with the HAT plugged directly into the 40 pin connector. There's some sort of strange problem when the HAT is plugged directly into the PI's 40 pin header. When the HAT is DIRECTLY plugged into the Pi, I get weird ghosting and terrible quality as documented above.
I suggest trying the molex 8 wire connector and see if you get the same results.

When I connect the HAT using the supplied wire harness (8 wire with molex connector) to the appropriate pins, it works perfectly during testing. When I connect JUST pins 18, 11, 22, 24, 23, 19, 9, 1 using Female->Male connectors to the 40 pin female connector on the bottom, everything works PERFECTLY.

The problem appears ONLY when I plug directly into the Pi. The really odd thing is that if I use a 2.7"B HAT with integrated screen, and plug in the 5.83" via the ribbon cable interface it also works perfectly.

DRIVING ME NUTS.

[hnwangkg-ezio]

Can you take a picture of the positive side of HAT

[dev-ng]

@txoof
I tried the workaround with the wires as you suggested and can confirm the picture is nearly perfect now. I let it run for some time to see if it get worse.

Back to performance issue, what PI do you use? Mine is Zero. I run it headless, connect via VNC, and run script directly in Thonny.

The following code produces the log you can see below:

print("init paper " + str(datetime.datetime.now()))
epd.init()

print("clear " + str(datetime.datetime.now()))
epd.Clear()

print("show " + str(datetime.datetime.now()))
epd.display(epd.getbuffer(Himage))

print("done " + str(datetime.datetime.now()))
epd.sleep()

Log:
init paper 2019-11-27 11:34:03.332435
clear 2019-11-27 11:34:03.875355 -----> 0.5 sec
show 2019-11-27 11:34:51.430846 -----> 48 sec veeeery slow
done 2019-11-27 11:35:28.623154 -----> 38 sec veeeery slow

@hnwangkg-ezio

Can you take a picture of the positive side of HAT

Not sure what you mean.

[txoof]

@hnwangkg-ezio
Here are the images of both sides of the HAT

[txoof]

@dev-ng
Here's my output running on a Pi 4B and a 5.83" screen. I deliberately chose the 5.83 because the refresh rate was the fastest among displays that use SPI:

import datetime
from PIL import Image
epd = epd5in83.EPD()
Himage = Image.new('1', (600, 480))

print("init paper " + str(datetime.datetime.now()))
epd.init()

print("clear " + str(datetime.datetime.now()))
epd.Clear()

print("show " + str(datetime.datetime.now()))
epd.display(epd.getbuffer(Himage))

print("done " + str(datetime.datetime.now()))
epd.sleep()

>>> init paper 2019-11-27 21:27:58.312134
>>> clear 2019-11-27 21:27:58.824718
>>> show 2019-11-27 21:28:08.053502
>>> done 2019-11-27 21:28:14.887148

[dev-ng]

@txoof
Thanks for testing! According to specification difference in the full refresh rate is not that big 3.5 vs 6 sec. I suspect the Zero slows it down.

Three days later the image stays perfect while connected with wires.

[txoof]

@dev-ng
It's very weird. Can you try hooking up your board with Female-Male Jumper wires (Female end on PI GPIO headers -> Male end on HAT GPIO socket)?

I did that and it also worked flawlessly. There's something børked with the HAT only when it's plugged directly into the Pi.

[txoof]

@hnwangkg-ezio
Any support options for this? I'd love to use the ribbon cable, but it appears unusable.

[lukaszgard]

Hello @txoof and @dev-ng, after a while did You still enjoy good quality of the display ? Few days ago I noticed that my display 4.2inch starts behave as @txoof document. In my case I am using for presenting fridge temperature which I am use for beer fermentation control, thus at the beginning I could't use the HAT using 40 pin's header, I use jumper wires the same way as You.

Here is how look like display after refresh:

Thank's for feedback and suggestions.

[txoof]

I've never had any of the ghosting problems you're having. It looks like an incomplete refresh problem. is the screen cold? I understand that ambient temperature has an impact on refresh rate (though how, I don't know).

In the python code I've noticed that there are some parameters that can be adjusted to change how the display refreshes, but I'm not sure where that was.

[lukaszgard]

Well today morning I check the temperature of the screen and it was ok in my opinion (ambient temperature). Indeed, there is possible to pass hex value to Clean() function, but in my case I did not change source code over last month, and for sure at the beginning screen look's much better. The main concern part is that parameters and behave of this screen got worst in period of time. I don't know if this could be the problem but I am updating the screen with date every 60 seconds.

@txoof could You answer after a while You have been moving from 40 header to jumper wires solve You problem with refreshing and display rendering and after all You screen is working ok now ?

@hnwangkg-ezio could You help here somehow ?

[txoof]

@lukaszgard Using the white JST 8-pin connector ==> 40 pin GPIO solved all my problems.

Interestingly, if I used the female 40-pin GPIO connector on the HAT and used male-female jumper wires to connect directly to the male 40-pin GPIO header on the Pi, this also solved the problem.

I also used a different HAT and there was no problem.

I suspect there is a faulty connection somewhere in the female GPIO. If the connection is poor and there's extra resistance, or some weird interference coming in, that could cause the problems.

[txoof]

@lukaszgard Are you by any chance forgetting to put the display to sleep after you write to it? The FAQ mentions something that sounds exactly like your issue.

Question:
Why my e-paper has ghosting problem after working for some days

Answer:
Please set the e-paper to sleep mode or disconnect it if you needn't refresh the e-paper but need to power on your development board or Raspberry Pi for long time.Otherwise, the voltage of panel keeps high and it will damage the panel

[NickAnsy]

Hey guys,
I am having the same issue where the top left portion of my screen has a bit of white wash. I am using the 12.48in waveshare screen and would like to try this alternative to the 40 pin GPIO on the waveshare board to see if it fixes it. I'm not sure how to hook it up with the jumpers though.
Thanks.

[txoof]

@NickAnsy
Attach the JST connector to the waveshare board and then check this pinout

For an overview of the physical pin layout on the raspberry pi see pinout.xyz

[NickAnsy]

This is my board, I know it's different because it's essentially 4 screens in one.

[txoof]

Well. That's new to me.

It looks like you'll need some female-female dupont connectors and use the male headers between the yellow arduino headers and the black ESP32 headers. Check this image on the wiki for reference.

Waveshare has an ok wiki that documents the pinout to the GPIO headers of the pi. Make sure to double check the VCC and GND connections. Swapping those is an outstanding way to toast your Pi or the board.

I found that using Male/Female dupont connectors with the 40 pin female header also yielded better results than plugging the pi directly into the HAT. I suspect there's a high-resistance connection somewhere that's' causing some sort of weird leakage or inductance or ???? that causes the poor image quality.

[NickAnsy]

Yeah i figured it out, still getting the same results. I'm so frustrated. This was supposed to be an anniversary gift for my girlfriend and I can't get it to cooperate. It's doing it on multiple screens as well. So it's either something with the code or I don't know.

[txoof]

@NickAnsy does it work when running the demo code?

Also, did you double check the ribbon cables? I've found that if they are not fully inserted into the zif sockets, I get crappy results.

[NickAnsy]

Yeah it works fine with the demo code, which made me lean towards something in my code being weird. So I haven't checked the ribbon cables, but I will right now.

I keep thinking it's something to do with it not properly putting the screen to sleep.

[txoof]

@NickAnsy
Could be.
I have a library that I wrote specifically for writing to EPD screens. I don't know if it's compatible with this, but you can check it out over at https://github.com/txoof/epdlib

Are you on Discord? https://discord.gg/psDk32uY

[NickAnsy]

Thanks man, I will check it out as soon as i pour my coffee. I am!

[txoof]

@NickAnsy how's it working?

[NickAnsy]

Great! Had it running all day yesterday while monitoring it. Ran overnight and still looks good! I believe its fixed. Thanks for all your help!

[txoof]

For others struggling with the same problem as @NickAnsy, make sure to sleep the driver after each write. Leaving the driver board in the init state can cause the trouble he was experiencing.

[noonasGit]

Hello there fellow e-inkers..
I have a raspi zerow with a hat connecting to an Waveshare epd7in5b_V2 (black and red).
What I see is that if I have minor amount of graphics (black only) it refreshes okay, but the more detailed I add, the more washed out it gets.
If I flip the black and red, the red comes in nice and strong, and the black is washed out.

I initiate it like this.
imageB = Image.new('L', (epd.width, epd.height), 255) # 255: clear the frame
imageR = Image.new('L', (epd.width, epd.height), 255) # 255: clear the frame
draw_black = ImageDraw.Draw(imageB)
draw_red = ImageDraw.Draw(imageR)

I have tried with 1 and L as the flag with no difference.
at the end of the code (python) I do sleep the screen

epd.display(epd.getbuffer(imageB),epd.getbuffer(imageR))
epd.sleep()

here is the black (washed out)

here is the red (basically I just swapped the two buffers in the epd.display command)

What am I doing wrong?

[txoof]

I've tracked this down to noise on the connectors. If the connection isn't perfect, or the cables are cruddy, I get this same effect.

Try using jumper wires from the HAT to the GPIO pins and see if you get a better result.

[noonasGit]

Thanks, I will take a look and try with the cables rather than the ribbon cable.

[noonasGit]

I took a look at the cables, tried it and no change - BUT THEN - I realized one of the switches on the HAT was wrong ;)

It was set to A, and once I flipped it to B - it was all good!