eink display loses contrast on days with high PoP

[dwuhls]

On days with high PoP throughout the day, there's something about the PoP graph that causes the entire display to lose contrast. I'm using the 7.5" BW display, Waveshare e-Paper Driver HAT rev2.3.

Fully removing the PoP graph or drawing the graph with every third pixel (it's currently every other pixel) seems to resolve the issue.

[lmarzen]

Oh my, that's a crazy bug, woah!

[lmarzen]

I will try and recreate this on my hardware. I'm pretty busy with school so it may be a few weeks before I get a chance to investigate this. Also thanks for looking into the code and finding what is causing the issue. Great work!

[DingoSEAD]

Hello,
Very good work
I have just finished installing the weather station and indeed, after 24 hours, there is a loss of contrast.
I applied the fix, it's working again.
thanks guys

[lmarzen]

Good to know that it isn't a one-off problem. @DingoSEAD did you have the HAT rev2.3 version too?

[DingoSEAD]

Yes, I use HAT rev 2.3
I have wired PWR at D6 of ESP32 E ( cf Waveshare wiki https://www.waveshare.com/wiki/7.5inch_e-Paper_HAT_Manual#Hardware_Connection_2 )

[dwuhls]

I believe this is a rev2.3 hardware issue. I got my hands on the Waveshare rev2.2 hardware and did some tests with 2.2 vs 2.3

Rev 2.3 failed to draw heavily dithered images with lots of individual pixels -- the display would lose contrast and streaks would appear on the display. Rev 2.2 did not have any problems. I also swapped the eink displays but that didn't make any difference; it's the e-Paper HAT that's the issue.

[lmarzen]

Great job! That's interesting. It is possible that there may be modifications needed to the epaper driver for the new HAT to function correctly.

[lmarzen]

@DingoSEAD Your issue may be that you wired the pin to D6, please try connecting PWR to 3V3.
@dwuhls Can you confirm how you have wired the PWR pin?

[dwuhls]

I originally had PWR on D6 like @DingoSEAD. Rewiring PWR to 3V3 did not fix the issue.

As an aside, wiring PWR to D6 was all that was needed to activate the display for me. I didn't need to set high/low state for that pin in software.

[lmarzen]

@ZinggJM Have you seen this issue before?

Here is a summary,

Recently, waveshare has updated their driver HATs to rev2.3, which are shipping with their 7.5" BW display (sometime in late august?).

The revision includes the following changes outlined here. I have translated to English using google translate.

Version changes:

The RST pin now only controls reset and no longer controls power on and off.
Add a PWR pin to control power on and off
Replace the inductor with a smaller, thinner package
PH2.0 8Pin interface replaced with GH1.25 9Pin interface

If you need to upgrade to this version from a previous version, you can choose one of the following methods for compatibility:

Update the program to the latest (Arduino program only supports 7.5inch e-Paper, 7.5inch e-Paper (B), 5.83inch e-Paper, 5.83inch e-Paper (B), 2.9inch e-Paper (D), 2.13 inch e-Paper (D) six screens)
Connect PWR pin to 3.3V
Solder a 47K (or similar) resistor to the empty pad on the back

Our current solution for users receiving the rev2.3 screen has been to Connect PWR pin to 3.3V.

This seemed to work initially until users had rainy days (literally). The esp32-weather-epd project draws a chart using dithering that displays Probability of Precipitation. On days forecasted with lots of rain, there is a significant amount of dithering used which causes a loss of contrast across the entire display (pictured at the start of this thread).

@dwuhls was further able to confirm that the issue occurs only with the rev2.3 HAT by getting a hold of both the rev2.2 and 2.3, and swapping between the two.

[lmarzen]

Since we haven't heard back from Jean-Marc,

I made a post on the Arduino forums, which (I think) is his preferred contact method for GxEPD2 related questions.

Here is a link so you can follow the issue there if you're interested.
https://forum.arduino.cc/t/gxepd2-loss-of-contrast-waveshare-e-paper-driver-hat-rev2-3/1190325

[lmarzen]

Jean-Marc requested the inking on the cable, can someone share a picture of your cable here so I can share it with him?

[dwuhls]

Unfortunately I returned my rev2.3 hardware so I won't be able to share a picture. Maybe @DingoSEAD can help?

[DingoSEAD]

Hello
the perfect wiring is PWR on HAT 2.3 on VCC ESP32.
2 weeks without lose contrast and I even think the contrast is better !

[lmarzen]

@DingoSEAD I am wondering if this is a voltage issue. It will be interesting to see if this issue occurs more with a lower battery voltage.

[lmarzen]

I have reported this issue to Waveshare, and will provide updates here as I receive additional information.

[lmarzen]

Jean-Marc suggested that the Waveshare HAT has a level converter that makes it less ideal for low-power use compared to the DESPI-C02 instead. I have updated the README to suggest users purchase this adapter instead of the waveshare hat.

[lmarzen]

This was Waveshare's response to this issue...

The loss of contrast issue may be caused by several factors, such as:

• The power supply is not sufficient or stable enough to support the display and the driver hat.
• The wiring is incorrect or loose, causing a short circuit or a reverse polarity. You need to make sure that the wiring is correct and secure.
• The firmware or the software may have some issues. What happened when you tried with our demo code?
• If the display is used outdoors may cause this type of issue.

The difference between versions is:

1. RST pin now is for reset control, and not for power on/off.
2. Add a new PWR pin for power on/off.
3. Smaller and thinner package for the inductor.
4. PH2.0 8Pin connector is replaced with GH1.25 9Pin connector.
5. The version silk print is updated with Rev2.3.

The new driver HAT can produce strong enough panel driving voltage and power for a 7.5" display, with its smaller inductor.

[lmarzen]

I am going to close this issue with the solution being to recommend the DESPI-C02 going forward and warning users to avoid the Waveshare rev2.3 hat.

Although I am closing this issue, feel free comment on this more. We can reopen this if anyone thinks that this is the incorrect solution.

[tolmeda]

I just experienced this bug on the first rainy week since completing my build. Since @dwuhls initial comment and recommended workaround, the underlying code has changed slightly. I made the following changes to get it working again.

The result is good enough but I didn't take the time to really comprehend the code. There might be better solution that produces a more aesthetically pleasing graph.

[dwuhls]

@tolmeda the code that I wrote in my original works as a drop in replacement for that section and doesn't have the gaps/overlaps. Just replace your code

with the following code

// graph PoP
for (int y = y1_t - 1; y > y0_t; y -= 3)
{
  for (int x = x0_t; x < x1_t; x += 1)
  {
    if (x % 3 == 0)
    {
      display.drawPixel(x, y, GxEPD_BLACK);
    }
  }
}

[tolmeda]

Ah… I should have realized that. Thank you. I’ll try it.

…

On Fri, Dec 29, 2023 at 12:03 PM dwuhls ***@***.***> wrote: @tolmeda <https://github.com/tolmeda> the code that I wrote in my original works as a drop in replacement for that section and doesn't have the gaps/overlaps. Just replace your code 293386985-54feb240-f598-4ec1-9eeb-f6ef009f9670.png (view on web) <https://github.com/lmarzen/esp32-weather-epd/assets/88133331/eea03638-f4a8-4c60-aade-337df9d0f4e1> with the following code // graph PoP for (int y = y1_t - 1; y > y0_t; y -= 3) { for (int x = x0_t; x < x1_t; x += 1) { if (x % 3 == 0) { display.drawPixel(x, y, GxEPD_BLACK); } } } — Reply to this email directly, view it on GitHub <#62 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3OEHZK4X4SI7OWYCYW47TDYL3ZXPAVCNFSM6AAAAAA6VBWPGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZSGIZDEMRRG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cbslade42]

Experiencing the same issue on the DESPI-C02.

[lmarzen]

Please check that the switch on the DESPI is set correctly.

[cbslade42]

I tried both switch positions, but it's currently set to 0.47. I can post pictures next time I have it running.

In the meantime the code change mentioned previously alleviates the issue. Thanks!

[Radiofreund]

Hello,

I can't quite understand the answers given here about the Hat rev.2.3 voltage converter.
I have no problems with the display with the same hardware and a different project.

But anyway, I would just like to know where I have to make the changes in the code?
I've only worked with Arduino so far and I'm not so fit with vsc, actually I'm already happy to have gotten the code with changes in config.ccp and config.h on the Firebeetle.
Where can I find the program section to be changed in vcs?

thanks for a possible answer.

[lmarzen]

Search renderer.cpp for // graph Precipitation

[Radiofreund]

I changed it and it works.
Many thanks for the quick reply and especially for the great project.

[pivoine31]

First of all lots of thanks to Luke Marzen for this impressive project, and for providing it to us

During these rainy days, I also had the problem on a DESPI-C02
Applied the dwuhls patch with success (thanks to him), but with an improvement : the code compute a "filling" percentage and switch to the low density pattern when greater than 65%

Here is the modification, for those interested in
Tested only with POP, but should work also with PRECIP volume
The 'renderer.cpp' patch :

1. At beginning of drawOutlookGraph() add :

int pop_step = 2;
#ifdef UNITS_PRECIP_POP
float precipValTot = hourly[0].pop * 100;
#else
float precipValTot = hourly[0].rain_1h + hourly[0].snow_1h;
#endif
float precipValTotMax;

2. At the end of the first "for (int i = 1; i < HOURLY_GRAPH_MAX; ++i)" loop, add :

#ifdef UNITS_PRECIP_POP
precipValTot += hourly[i].pop * 100;
#else
precipValTot += hourly[i].rain_1h + hourly[i].snow_1h;
#endif

(so, just before :
"}
int tempBoundMin = static_cast(tempMin - 1)
- modulo(static_cast(tempMin - 1), yTempMajorTicks);" )

3. Before the "Draw y axix loop", add :

precipValTotMax = precipBoundMax * HOURLY_GRAPH_MAX;
Serial.printf("PG: ValToT=%f, ValMax=%f, BoundMax=%f\n", precipValTot, precipValTotMax, precipBoundMax);

Serial.println("Precipitation graph fill ratio = " + String(precipValTot/precipValTotMax));

if ( precipValTot > (precipValTotMax * PRECIP_THRESHOLD) )
pop_step = 3;

Serial.println("Precipitation graph step = " + String(pop_step));

(so, just before :
"// draw y axis
float yInterval = (yPos1 - yPos0) / static_cast(yMajorTicks);" )
(you, may remove the serial.print, helpful for debugging)

4. original patch : replace :

   for (int y = y1_t - 1; y > y0_t; y -= 2)
   {
   for (int x = x0_t + (x0_t % 2); x < x1_t; x += 2)
   {
   display.drawPixel(x, y, GxEPD_BLACK);
   }
   }
   BY
   for (int y = y1_t - 1; y > y0_t; y -= pop_step)
   {
   for (int x = x0_t; x < x1_t; x += 1)
   {
   if ((x % pop_step) == 0)
   {
   display.drawPixel(x, y, GxEPD_BLACK);
   }
   }
   }

5. Define threshold for triggering the density change somewhere
   (preferably in config.h, but works also in renderer.cpp)

// Threshold for generating precipitation graph
// Indicates the percentage of graph filling from which the
// draw pattern density is decreased (default to 65 %)
#define PRECIP_THRESHOLD 0.65f

You may tune according to you particular situation
In my case the contrast loose seems to begin around 70% of graph filling

NB : code indentations are lost, apologise for that

[pivoine31]

I have also made some other modifications :

• Wifi with multiple credential
• Manual wakeup using builtin button in order to start a Web server (for a few minutes) allowing to tune/change locations, add wifi credential, handle the precip threshold ... (in progress)
• Simultaneous display of precipitation probability and precipitation volume
  But such modifications cannot be made available as patch in this discussion ...
  Does someone know the good way to publish them (if L Marzen agree with this) ?

[minigl]

Hallo zusammen,
da ich leider von C++ nur sehr wenig verstehe, habe mich mehr mit Arduino befasst, möchte ich hier nachfragen,
ob jemand bereit wäre die Änderungen von pivoine31 in der renderer.cpp korrekt einzutragen?
Vielleicht hat das schon jemand gemacht und die Anzeige ist nach der Änderung besser abzulesen.
Es wäre schön, wenn mir dann jemand die renderer.cpp per E-Mail schicken würde.
Ich möchte mich im voraus bedanken.

[pivoine31]

Hi,
I have published recently a modification of the L.Marzen software that include this modif as well as an other interesting one named "POP and VOL".
The github site is : https://github.com/pivoine31/esp32-weather-epd-pvmod
The modified software also implements a Web server, but you have the choice of using it or not
Best Regards

Note : it should be a good idea to translate you message to english before sending it (using google translate for instance)

[ltwin8]

#119

i have found the issue of the contrast

[chrisc123]

I'm afraid I recently experienced the partial/faded display issue on a week of high PoP despite using latest GxEPD2 library. This was with a Firebeetle 2 and a DESPI-CO2 on a GooDisplay 7.5" panel. I don't believe the issue is specific to Waveshare drivers. The previously identified fix of reducing graph shading density resolved the issue.

I believe the Firebeetle LDO is rated for 600mA, would it be expected that an EPD could pull more than that on a refresh with lots of dithering?

I have a spare [UnexpectedMaker ProS3 board] (https://esp32s3.com/pros3.html) with slightly higher rated LDOs (2x@700mA) and will try to test this out as an alternative.

[lmarzen]

Well, that's annoying.

The panel's typical refresh power is given as 26.4 mW (typical) at 3.3V (according to the waveshare product page for this panel.

Current required = Power / Voltage = 8mAh.

This is far below the LDO's capability of 600mAh

I am stuggling to find a peak current requirement, though. Even though the panel has a low typical power consumption, maybe transient power spikes during refreshes with heavy dithering might far exceed this?

These higher-rated LDOs could resolve the issue if the problem is indeed caused by the FireBeetle's LDO struggling with transient loads.

Let me know what you find.

[chrisc123]

Oh, I just checked and I'd followed your wiring diagram whereby the driver is powered from a GPIO pin rather than 3.3V supply - so wouldn't that mean current is actually limited to 20mA (66mW @ 3.3V) default that an Esp32 GPIO pin can source? That seems like it's a lot closer to the power consumption of the panel and could be causing issues (esp if battery is low?)

Was there a specific reason to power the driver from GPIO and not to connect to 3.3V out on the esp32 directly? Reading this suggests there shouldn't be any increased idle power drawn from a DESPI-CO2 at least?

[lmarzen]

Good find.
Does powering the DESPI off of one of the 3.3v pins directly fix your issue then?
I will update the documentation and wiring diagrams accordingly to have it powered off the boards 3.3v.

[pivoine31]

Just modified the wiring and done a quick test (Naples is a good area to test this at the moment). Apparently works fine with the standard greyed pattern, so seems to be the solution. Picture before / after at the following link : https://filebin.net/ojx230pw30d4xm15 Best regards.

[chrisc123]

Good find. Does powering the DESPI off of one of the 3.3v pins directly fix your issue then? I will update the documentation and wiring diagrams accordingly to have it powered off the boards 3.3v.

Yes - this seems to have resolved things for me as well and although it's only a short testing window there doesn't seem to have been any impact on battery usage either. Thanks for the project, it's really nice!

[thetwoj]

I happened to assemble this project on a day with virtually 100% PoP over the next 24 hours so I experienced the dim display symptom from the get-go. After finding this discussion I ran the 3.3v pin on the DESPI-CO2 to a 3.3v pin on the ESP32-E and the display became perfectly clear. Thanks!