Would lengthening the operation require adjusting the LUT? I checked the library yesterday, and believe this panel uses LUT from the OTP memory, so wouldn't be realistic to adjust anyway (?)
Do you think testing the panel with a driver board like DESPI-C02 would be a good idea?
I would start to test it with my 100 MHz Saleae clone. But i do not trust these measly jumper wires at that high frequency and i myself lack of time. They already start to be troublesome at much lower frequencies. I guess JM has checked the timing, else no driver. LA´ s get more and more in the reach of everybody. But good probes and connections are a whole different story.
200 Ms/s:
Seems you misunderstood. I am (too) busy, that's why my answers are short.
A RESE of 3 ohms instead of 0.47 ohms may result in driving voltages rising to slowly, or even not enough. If the controller doesn't check, the result may be "dirty". If it does, the result may be BUSY timeouts.
A RESE of 0.47 ohms instead of 3 ohms may result in overshoot or even swinging voltages.
You would never adjust the LUT for this. And you can't write LUTs to registers, if you don't have example LUTs matched for the display. Not usual for color displays.
DESPI-C02 is a good idea, as it has a RESE switch.
Some module manufacturers may forget to change the RESE resistor value for use with a replacement display panel, when the original is no longer available.
@Podkletnov a logic analyzer may help if you suspect SPI communication issues.
The DESPI-C02 has test-points for the panel driving voltages. But these are analog values, +-15V and +-20V typical, lower values for red particles.
Thank you for your time and your input
In the sense that, theoretically, it might be able to compensate, but would be a completely ridiculous and inappropriate thing to consider?
I think I didn't express myself well, sorry. I wanted to point out that the question of "theoretically modifying the LUT" was largely irrelevant, because the LUT was loaded from OTP, and not readily available in the library, for "theoretical adjustment".
This reads as if you are suggesting that Podkletnov's issue be a manufacturing error, where the driver board was repurposed.
I wonder slightly, did you catch that the driver board currently in use has been "repurposed" from a "WeAct 2.9 Inch BW module", supposedly compatible with GxEPD2_290_T94 (actual model ZJY128296-029EAAMFGN)?
I just checked the initialization parameters of this panel.
It is strange that one parameter for POWER SETTINGS is missing
VDHR_LVL[5:0]
It selects the reduced voltage for moving the color particles.
Usually either all parameters are set, or none. Mixing OTP or default values with explicit values is uncommon. You could experiment with this. I don't have time for it. You could also check the demo example from Good Display.
No. Sorry, this topic is becoming too complicated to be able to answer efficiently.
I try to answer if mentioned. But now I am out.
Yes, what i use is from WeAct 2.9" BW. I tried the Gooddisplay Example after adapting its wiring (see zip). It does...not seem to do anything at all. Loading GxEPD code does. Uploading this: Nada. No idea why.
Not_so_GoodDisplay.zip (5.2 KB)
Ok. I checked it. This GoodDisplay Arduino Example fresh from their Website is incomplete. Lacking of some libs. But it compiles! And the ESP32 Example is not for Arduino. Waveshare examples seem to be a lot better for beginners like me. Looks like after mentioning WeAct, support has stopped immediately. Hmm. I assume opening another thread will be futile. Borg vessel approaching...
I found the manual. It is openly available on "Good"-Displays Website, but has a huge red CONFIDENTIAL marker across each page. Looks like they do not own a Acrobat Pro license to remove the marker. As the format of the 2x4bit image.h format from some of the "examples" is hardware dependent and therefore differs from product to product, they do not bother to explain it. They just tell you to use Image2LCD without explaining the essentials, namely the format. Or in short, they do not want to admit the HW-dependency of the format. Looks like this is too much secrecy for my OPEN SOURCE soul. I think i will sell all the EPD-HW and put my effort in another field. The entire market is dominated by a few (or is it just one and the same) manufacturer and a handful of resellers and the hobby market is only served in small doses at pharmacy prices.
I have to sleep sometime!
In the diagnostic serial from GxEPD(2), are you seeing "busy timeout"? The GoodDisplay sketch seems to block until BUSY is low, whereas GxEPD eventually gives up and continues(?), even if the display does not appear ready.
You are troubleshooting a tricky issue.
ZinggJM checked the initialization parameters of the panel
It is strange that one parameter for POWER SETTINGS is missing:
VDHR_LVL[5:0]It selects the reduced voltage for moving the color particles.
Usually either all parameters are set, or none. Mixing OTP or default values with explicit values is uncommon. You could experiment with this. I don't have time for it
I may have misunderstood, but I believe the suggestion here would be to add a new line below L380, in GxEPI2_750c_Z08.cpp, to specify a missing value for VDHR (Positive source driver voltage for Red).
I believe that to set VDHR to the value shown in the "Reference Program Code" of the GDEW075Z08 datasheet, the new line should be: _writeData (0x12); // VDHR=6V
This level of 6V is different than the controller IC's default of 3V. It is unknown what value is stored in OTP, but:
Usually either all parameters are set, or none. Mixing OTP or default values with explicit values is uncommon.
So it's definitely worth a try.
If it was my panel which was having issues, I know that I would absolutely be testing it with a known working model of driver board. The assumptions you make about repurposing the WeAct hardware introduce another layer of uncertainty, making it much more difficult to pinpoint the source of the issue.
Thank you so much. I was trying too vary the voltage value, but the results were hardly visible and did not make sense to me. Maybe i already destroyed the reds on my display. I will wait until the BWR WeAct 2.9 board arrives and will connect the 7.5 inch to that and try again. If that does not work i will shell out the dough for the DESPI-C02. I am desperate to get this solved. I promised it to a friend. And i am obsessed with keeping my promises. Guess what i think of politicians 
I checked on this RESE resistor which should be .5 instead of 3 Ohms, but they are too tiny for me to solder. So i ordered four DESPI-C02 boards. One of the reviews there showed a perfectly fine light-red color, so i hope this will solve the problem
Solved it in the meantime. See my comment on Github. I added a so called Booster routine from the original GooDisplay code to this libraries Init Routine. See attachment or Github. Now red is RED. Yeah! Using WeAct board. Just replace the file in the Arduino libraries GxEPD2 folder with the attached one.
GxEPD2_750c_Z08.cpp (12.7 KB)
The display supported by GxEPD2 is GDEW075Z08.
//#define GxEPD2_DRIVER_CLASS GxEPD2_750c_Z08 // GDEW075Z08 800x480, EK79655 (GD7965), (WFT0583CZ61)
The display you have is GDEY075Z08.
I don't have this display, so it isn't supported in GxEPD2.
-jz-
Because the driver class in GxEPD2 is based on the Good Display example, initialize code taken from the version as it was at that time. I will check. It is not the only case that Good Display replaced a panel and updated the demo code, without changing the name of the panel.
-jz-
You could report from where you downloaded the demo code.
Thank you for the answer!
As I expected. It is for GDEY075Z08, not for the GDEW075Z08 I have and support in GxEPD2.
I am surprised by the inking on your display. The website shows a different inking.
Donation is welcome, if someone wants support for GDEY075Z08 in the official version of GxEPD2.
The link in the driver code still works:
The inking is the same on the flex ribbon. How should i have known? Until you come up with support, people are welcome to use my code. I always thought its the inking which tells the type of display, as the different vendors have different designations. You just tell me its the other way round? Something does not quite fit here.
