Giters

vroland / epdiy

EPDiy is a driver board for affordable e-Paper (or E-ink) displays.

Home Page:https://vroland.github.io/epdiy-hardware/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Image is corrupted in demo

mmib opened this issue · comments

commented

Hi and thanks for good project, got the following issue:

Midle 1/3 part of screen is filled using last 1/3 part of image: https://photos.app.goo.gl/NrU67cK5Pw3RJGog6
build board using gerber files from June 04 2020

If change
dev->fifo_conf.tx_fifo_mod = 1;
to
dev->fifo_conf.tx_fifo_mod = 0;
or play with clock dividers i managed to get 2 dragons. But can't get correct image

https://photos.app.goo.gl/JamvfDV5eNeDf52q6

commented

Did you select the correct display type as described in https://epdiy.readthedocs.io/en/latest/getting_started.html#selecting-a-display-type?
Which version of the ESP-IDF are you using?

commented

Hi, yes, selected correct display type (tried all 3 types).
ESP-IDF: tried 4.0.1 and last release version from github
Have ESP32-WROVER board which seems old version and not ESP32-WROVER-B
Cmake is 3.13.0 which comes with ESP-IDF on Windows (also tried 3.18.0)

Always got same results :)

commented

Could you send me the firmware .elf - file so I can test it with my board? This should tell us wether it is a software or hardware issue.

commented

sure, here it is https://drive.google.com/file/d/100nq3WojXUwFnXGf2NzVIdWlf5WL_-Bs
(I changed loop to updated screen just once per 600 seconds)

commented

Hm, your firmware works fine for me. Do you have a list of components you used? What is the revision of your ESP32-WROVER module (should be shown when flashing)?

commented

can it be just wrong gerber files version? - i got it from zip archive in git version from June 04 2020 and it seems it was not tested version

commented

Hmm, the only thing I see here is that you use a shift register which specifies a lower clock speed, but since that's only used for control signals it should not lead to the image being as it is...
The other demos produce similar results, I assume?

commented

Yes, those files are untested, but I don't see how any of the changes would produce this error. It seems very regular, like it has something to do with clock speeds. Did you try to reduce the configured APLL frequency directly instead of the clock divider? And turn it down veery low?

commented

i made 2 boards and got same results. So, it seems it can be issue with gerber files I used. But strange....
Voltages are correct too.
Or maybe It is display issue, but i have 2 displays and same issue on both.

commented

Yes, tried to play with APLL and got 2 dragons, 4 dragons and very slow but corrupted dragon. Can't manage to get correct dragon

commented

at least good to know it is something hardware related. Initially i thought some wire could be broken but when managed to get 2 dragons started to play with clock but without any luck.

commented

The other demos produce similar results?
Hm, I don't quite understand how reducing the frequency would produce 4 dragons, that's strange.
You could try to have a look at the epd_output_row() function in ed097oc4.c, insert some delays and let the display wait until a row is completely written by changing

pulse_ckv_ticks(output_time_dus, 50, false);

to

pulse_ckv_ticks(output_time_dus, 500, true);

It's just hard to diagnose anything remotely...

commented

Yes, i know it is very hard to diagnose it remotely.

Will also get Nexperia 74HC4094, seems avaialble locally. Looks like it is the only part which can make such problems (but still not sure how).

Thank you for help.

commented

If that's available easily it might be worth a try...

commented

Hi, so I solder NXP 74HC4094D and got same results :(
Can it be display related? I have ED097OC4(LF) EMN97A2001(A57)
Any ideas what else to try?

Thank you

commented

Hm, hard to say. Maybe the following things might give us more information:

  • How does the picture look if you choose ED060SC4 as display type?
  • Have you tried cloning the fresh repository and ONLY reducing the i2s APLL frequency?
  • How do partial updates (e.g. in the Demo example) look?
commented 
rtc_clk_apll_enable(1, 0, 0, 2, 3); // 24Mhz
rtc_clk_apll_enable(1, 0, 0, 2, 8); // 12Mhz
rtc_clk_apll_enable(1, 0, 0, 1, 8); // 10Mhz
  • if rectangle fits into 1/3 of screen then it is ok, if it fits only in 2/3 then not visible, if it contain parts in 3/3 of screen then this part is duplicated in 2/3
commented

dev->sample_rate_conf.tx_bck_div_num = 1;
producing this https://photos.app.goo.gl/xHEsLTFxtePeRDV39 (looks better with old code BLACK_ON_WHITE)

commented

getting closer...
rtc_clk_apll_enable(1, 0, 0, 8, 0); //120 Mhz gives correct image with old code, but then verticals lines start to appear https://photos.app.goo.gl/J6Y6tg7gY1Hk1vGJ7
with new code it looks this way https://photos.app.goo.gl/kgyap7JQGsLfvFoR8
reducing frequency by rtc_clk_apll_enable(1, 0, 0, 2, 0); // 60 Mhz makes wrong dragon again

commented

rtc_clk_apll_enable(1, 0, 0, 7, 0); also works, but can't fix bleeding vertical lines
seems this bleedin lines were from prev attempts and just had to let EPD to "relax" a bit :)
but still playing, looks like there is some issue with clock at some stage. Why only this high clock works fine while other not?

With new code i still have issue and it seems it is because not all frames drawed and I got very light or very dark image.

commented

What? According to the data sheet, the absolute maximum frequency should be 50Mhz... Something is really wrong with the clock here... Can you try to use the bit clock instead of the word clock? for the CKH signal? (Replace I2S1O_WS_OUT_IDX by I2S1O_BCK_OUT_IDX)

* ED060SC4: https://photos.app.goo.gl/UEpa2TSdRJ9MYtGv5

And the normal demo with ED060SC4? Since the dragon demo does not adjust to the smaller width, it will look weird no matter what.

And I should really update the timing table for WHITE_ON_BLACK, since that one is not yet calibrated for the ED097OC4, this is why it looks so white.

commented
commented

Well, that seems strange to me. Somehow pretty much any value I set for the frequency works with my display. Maybe I can look at this with an oscilloscope in the next days to see what is going on.

  • ED097OC4 dragon took 418ms rtc_clk_apll_enable(1, 0, 0, 7, 0); and looks good

That sounds like at least you have a workarround for now?

commented

Yep, this is a workaround for time being. But I have big doubts about my board and frequency it produces. Of course will try to investigate it more and find reason of such strange behaviour.
The good news we now have more than 2fps (wuthout screen clearing of course) which is very good for 16bits and such screen. It seems it can do even more than I expected!

commented

btw, I have cheap oscilloscope and can try to mesure signal, just need instructions which pins to check.

commented

The most relevant signal would probably by the horizontal clock (CKH), which is on IO5 of the ESP. You can also find the location of the corresponding pin on the PCB through KiCad ;) You could try to look at STH (IO25) as well.

commented

The V2 gerbers are fine on my two displays (the 9.7inch, OC1 and OC4) i got from AliExpress. However, when i'm plugged into my old Kindle display (9.7 inch OC1) i get similar problems with the thirds. However you could try my voltage mod described in #3 which fixed other issues. Brown-out might be a partial cause.

I'm thinking this to be more of a timing issue than a hardware failure. Maybe some displays are just made a lot more poorly than some others.

commented

By measuring I noticed that dev->clkm_conf.clkm_div_num = 1; is actually out-of spec and is ignored with my ESP, which instead uses a divider of 2. Maybe your ESP behaves differently. Could you try if the most recent commit changes anything?

commented

Same problem with thirds
But works with rtc_clk_apll_enable(1, 0, 0, 8, 0);
dev->clkm_conf.clkm_div_num = 2; and dev->clkm_conf.clkm_div_num = 1; has no difference
clear time is about 980ms, render time is about 480ms for both

commented

Hm, what happens when you scale up dev->clkm_conf.clkm_div_num?

commented

The strapping pins @sebastius mentioned could be read out of the GPIO_STRAPPING register. Maybe there is indeed a problem with those?

commented

the "thirds" problem back with dev->clkm_conf.clkm_div_num = 4;

commented

image
can't get right pic as well. How can I distinguish wether it's hardware problem or software problems?

commented

In addition it can clear the screen normally. But can't display the right picture.

commented

hey @stig3 ,
some things that would help:

  • Which exact display are you using?
  • Have you tried different display types?
  • Does clearing the screen work properly?
  • Do other demos / programs show the same pattern?
commented

Thanks for your replay. I was using ed060sc4, and yes, it can clear the screen properly. I also try the dragon demo which also could not showing the right pic. Since now I only have one 6" EPD so I can't distinguish whether it was my hardware problems or same as this issue. I'm planning to buy a 9.7" screen and I'll let you know when I receive it. Thanks again.

commented

Have you selected the ed060sc4 display type in menuconfig?

commented

Have you selected the ed060sc4 display type in menuconfig?

YES I have . I'll soldering another pcb and try again. Hope it was my drive board cause this issue.

commented

UPDATE:
I've soldered another drive board & it was still the same. I've asked my friend for help and he told me it might be the problem of i2s timing.
After change the

rtc_clk_apll_enable(0, 0, 0, 5, 1);

in file "i2s_data_bus.c" line 167 to

rtc_clk_apll_enable(1, 0, 0, 8, 0);

ed060sc4 show the right image and problem solved.

commented

@stig3 Good to hear. I think I will just make this frequency setting available as a separate option, independent of the display type. Hope that will cover most variants out there :)

commented

@vroland I couldn't resist and bought the cheap $30 ED097OC4 on aliexpress. Only way to have uncorrupted image was to use ED097OC4 LQ profile so thanks for implementing this! It still isn't perfect tho, the display seems very slow compared to TC1 which is probably a feature but I have an issue where I have to wait (delay) at least 5s in between changes. Without the wait, the display is more and more washed out with each refresh. The darks are washed out around left and top corner a bit, but almost unnoticable when using 8s delay between frames. No noticable issue with 10s delay,

commented

I should add that VCOM is properly adjusted according to sticker value.

commented

Hm, since this seems to be a recurring thing this has to be some systematic error. Maybe we're missing something about the timings? Can you take a picture of the display labels to I can compare them with the ones I have?

commented

The label says ED097OC4(LF), I will take a photo tomorrow when I have better lighting conditions :)

commented

@vroland
https://www.dropbox.com/s/fprhz8l1r6r125v/Photo%2006.01.2021%2010%2011%2006.jpg?dl=0
https://www.dropbox.com/s/8ibcokf2pdaj81q/Photo%2006.01.2021%2010%2011%2038.jpg?dl=0

Seems like the same panel you have so I think yours might be little more forgiving than ours are :) I was experiencing exactly same distortion as on @stig3 's photo. ED097OC4 LQ fixed that but the quality is still not good. You can see on my pictures slightly visible fade on top corner, this is much more visible when I'm not using long delays.

commented

Also not sure if it's visible from the picture but it's shifted something like 5 pixels to the right, on the left is 5px white space, on the right is 5px distortion

commented

I can confirm, I've ordered two displays (on separate occasions) from aliexpress and the second shipping only works on low quality profile. But apart from bad contrast it works good. (Unfortunately first one working on normal profile broke, so I can't compare both labels)

IMG_20210106_114022

commented

@kubasienki you don't experience washed out image after several subsequent refreshes? Or faded image on the edge of the display?

commented

Actually there is a slight difference in the label of mine:
IMG_20210106_115311
Notice how the font in you displays (@mcer12 and @kubasienki )? The "C4" is almost connected while the letters are clearly separated on my display. So your displays are probably at least from the same production run...

commented

IMG_20210106_115711
Here is a picture of the glass on the back side. Identical with yours`

commented

The numbers next to the 9.7" EPD are different, other than that it's identical. It's possible it's some low quality run and that's why it's so cheap (it's the $30 one, free shipping aka the cheapest on ali :) ) If you have any ideas what could cause this, I will try it out. I will have to dig into the library some more when I have time, to try different timings, see how that behaves. But comparing OC4 and TC1 side by side, the TC1 is super fast and crisp, OC4 is much slower.

commented

The issues with image fading out with subsequent refreshes lead me to think it might be something with voltages. As this issue disappears when I add 10s delay after each refresh. Maybe it's sensitive to disabling / reenabling power (aka display turn off / on) and takes long to discharge the capacitors or something like that... but I tried it without that and it happend as well.

commented

I'd guess its something about the timings, maybe hold times of some lines. There is also the OE line which is just the source driver enable on the newer displays (e.g. the ED133UT2 or the ED097TC2 have signal diagrams in their datasheet). Maybe the older displays need some driven differently to discharge properly or something?
Problem is, without such a display it is only guesswork for me, but I don't want to spend 30$ on a broken display when I could just get a better one :D

commented

@vroland I looked in the datasheets and one significant difference in timing is that clock cycle time is 50ns min. for OC4 and 16.7ns min. for TC1

commented

Can we archive this old nice conversation? Asking to know if that won’t offend any of you ;)