1.54 Waveshare Epaper V2 partial refresh with gxepd2

I got some Waveshare 1.54 Epaper v2 displays and try to use them with the gxepd2 library with an esp32-pico-v2-02. The Display works fine with full updates, but i cannot get it to do partial updates. Also I couldnt find which display to select (is it not supported?) So I used GxEPD2_BW<GxEPD2_154_D67, GxEPD2_154_D67::HEIGHT>display(GxEPD2_154_D67(EPD_CS, EPD_DC, EPD_RST, EPD_BUSY));. After a trying lots of examples I switched the display with a GDEH0154D67 and the partial refresh works fine on that one with the same code.

Maybe someone knows what could explain that behavior. If you need some more information please ask. I used display.init(115200, true, 2, false); for the "clever reset" but I dont understand what is meant by that.

Thanks in advance.
epaperPartial.ino (1,2 KB)

Try with:

//#define GxEPD2_DRIVER_CLASS GxEPD2_150_BN  // DEPG0150BN 200x200, SSD1681, (FPC8101), TTGO T5 V2.4.1

Your panel has no waveform table in OTP for differential refresh, most likely.
-jz-

that works perfectly. I altered my code like that:
GxEPD2_BW<GxEPD2_150_BN, GxEPD2_150_BN::HEIGHT> display(
GxEPD2_150_BN(EPD_CS, EPD_DC, EPD_RST, EPD_BUSY)
);

Thanks for the quick help

after further testing I noticed that, the partial refresh works fine, but when I do a full refresh than the white is not perfectly white anymore. Some black comes to the top in the last step of the refresh, but it vanishes after a partial refresh. I think that has somthing to do with the lut as far as I understand, but I could only find the lut for partial refresh in the GxEPD2_150_BN.cpp. If can alter the lut for the full refresh than I guess I could use the one from GxEPD2_154_D67 which worked fine.

Does that make sense? Thanks for your help

@carl2a, it is bad practice to add more issues to a topic that has been declared soved.

Driver class GxEPD2_150_BN.cpp uses wavetable from OTP for full refresh, but wavetable written to registers for differential refresh (partial update).

No other user with this Waveshare display and your original issue has reported your new issue.

Please report the inking you find on the flexible connector of the panel of your display.

Report diagnostic output from GxEPD2_Example from Serial Monitor, in a code window, please.

the inking says: FPC-8101



one picture is from the waveshare display that has the problem, the other one (GDEH0154D67) does not have the problem. I made the pictures with a microscope.
The black dots appear when it seams that the update is over and they vanish when I do a partial update. Unfortunately I can not attach videos. Here is also the output form the gxepd2 example:
output.txt (1,4 KB)
Should I open another topic or is it okay that way?
Thanks for the help

I don't like to have to download code or data to try to help a poster.

No need, as I hope we can close this soon. Its just a nuisance to ad posts to a solved topic.

If you wish further help, then I need the code that produces the effect of your pictures, and the diagnostic output, both in a code window.

And the same when compiled for GDEH0154D67, executed on your DEPG0150BN. And a picture of this test.

DEPG0150BN
FPC-8101

I have worked with panels with this inking on the flex connector, on Heltec branded modules.

The partial refresh wavetable provided by the Heltec dev-team matches the one in GxEPD2 for DEPG0150BN.

I also noticed a similar effect. As I recall, if the panel is left on (ANALOG ON?), the black pigment tends to slowly migrate towards the surface, causing a gradual "snow".

There may be a much smarter way to deal with this, but my workaround was to avoid remaining in "partial refresh" configuration any longer than necessary. When the panel is to standby between operations, I double-wrote the image data, so that the screen image was stored in both the BLACK and RED memory areas, and then soft-reset the panel.

The OP reports this occurs after a full refresh.

GxEPD2 makes sure both buffers are equal after either full or partial update request.
The only exception is when a bitmap is directly drawn through driver class, not through the graphics buffer.
GxEPD2 calls powerOff() after any full refresh through graphics buffer.
There are remarks telling to use powerOff() after partial update, if not followed by more partial updates.

I do suspect a missing powerOff. That's why I ask for the code used, and diagnostics from the code used.
-jz-

Sorry, I should have read closer.

Here is the Code that I used to test the displays. First for the GxEPD2_150_BN

#include <GxEPD2_BW.h>
#include <Fonts/FreeMonoBold9pt7b.h>
#include <SPI.h>

#define misoPin 13
#define mosiPin 12
#define clkPin 14 
#define csPin 15

#define EPD_BUSY 33
#define EPD_RST 25
#define EPD_DC 27
#define EPD_CS 26

/*
GxEPD2_BW<GxEPD2_154_D67, GxEPD2_154_D67::HEIGHT> display( 
  GxEPD2_154_D67(EPD_CS, EPD_DC, EPD_RST, EPD_BUSY)
);
*/

GxEPD2_BW<GxEPD2_150_BN, GxEPD2_150_BN::HEIGHT> display( 
  GxEPD2_150_BN(EPD_CS, EPD_DC, EPD_RST, EPD_BUSY)
);
 


void setup() {
  Serial.begin(115200);
  SPI.begin(clkPin, misoPin, mosiPin, csPin); //CLK, MISO, MOSI, CS
  
  display.init(115200, true, 2, false);


  display.setRotation(1);
  display.setFont(&FreeMonoBold9pt7b);
  display.setTextColor(GxEPD_BLACK);

  display.setFullWindow();
  display.firstPage();
  do
  {
    display.fillScreen(GxEPD_WHITE);
    display.setCursor(20, 20);
    display.print("HelloWorld");
  }
  while (display.nextPage());
}
  


void loop() {
  // put your main code here, to run repeatedly:

}

here is the output:

ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 271414342, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13864
load:0x40080400,len:3608
entry 0x400805f0
_PowerOn : 93999
_Update_Full : 4227000
_PowerOff : 140000

and here for the GxEPD2_154_D67

#include <GxEPD2_BW.h>
#include <Fonts/FreeMonoBold9pt7b.h>
#include <SPI.h>

#define misoPin 13
#define mosiPin 12
#define clkPin 14 
#define csPin 15

#define EPD_BUSY 33
#define EPD_RST 25
#define EPD_DC 27
#define EPD_CS 26


GxEPD2_BW<GxEPD2_154_D67, GxEPD2_154_D67::HEIGHT> display( 
  GxEPD2_154_D67(EPD_CS, EPD_DC, EPD_RST, EPD_BUSY)
);


/*
GxEPD2_BW<GxEPD2_150_BN, GxEPD2_150_BN::HEIGHT> display( 
  GxEPD2_150_BN(EPD_CS, EPD_DC, EPD_RST, EPD_BUSY)
);
*/
 


void setup() {
  Serial.begin(115200);
  SPI.begin(clkPin, misoPin, mosiPin, csPin); //CLK, MISO, MOSI, CS
  
  display.init(115200, true, 2, false);


  display.setRotation(1);
  display.setFont(&FreeMonoBold9pt7b);
  display.setTextColor(GxEPD_BLACK);

  display.setFullWindow();
  display.firstPage();
  do
  {
    display.fillScreen(GxEPD_WHITE);
    display.setCursor(20, 20);
    display.print("HelloWorld");
  }
  while (display.nextPage());
}
  


void loop() {
  // put your main code here, to run repeatedly:

}

and here the output:

ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 271414342, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13864
load:0x40080400,len:3608
entry 0x400805f0
_PowerOn : 95000
_Update_Full : 4227000
_PowerOff : 140000

Both versions of the code result in the display looking the same. Here is a picture of GxEPD2_154_D67 code running on the waveshare display:

And here the same code on the GDEH0154D67

I hope I provided everything you need. Thanks

After some further testing I think that my first statement that the wafeshare display works fine with the code for the GxEPD2_154_D67 is wrong. I get the same issue with the black partical. And partial refresh is not working. I just do a partial refresh after every full refresh and will switch to the GDEH0154D67. If you have any idea please let me now.
Thanks for your help

I tried to reproduce this effect on my DEPG0150BN on TTGO T5 V2.4.1.
It may have the same effect, but very faint.
Therefore I can't be sure if the following change will improve the behavior on your display:

in GxEPD2_150_BN.cpp line 397 ff:

void GxEPD2_150_BN::_Update_Full()
{
  _writeCommand(0x22);
  _writeData(0xf4);
  _writeCommand(0x20);
  _waitWhileBusy("_Update_Full", full_refresh_time);
}

change line 400:

void GxEPD2_150_BN::_Update_Full()
{
  _writeCommand(0x22);
  _writeData(0xf7); // immediate power off
  _writeCommand(0x20);
  _waitWhileBusy("_Update_Full", full_refresh_time);
}

would need further investigation.
Maybe a VCOM value not well matched to the TFT layer may cause this effect.
-jz-

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.