Go Down

Topic: Good Dispay ePaper for Arduino (Read 84272 times) previous topic - next topic

flyingbaloon

@ZinggJM thanks , will keep this in mind

woessmich

#376
Jan 26, 2020, 11:16 am Last Edit: Jan 26, 2020, 11:27 am by woessmich
@ZinggJM: First of all: Thank you so much for the fantastic work on this library!

I am working on a board with an ESP32, LoRa and some sensors and started with the old 1.54" display (GDEP015OC1).

Code: [Select]
GxEPD2_BW<GxEPD2_154, GxEPD2_154::HEIGHT> display(GxEPD2_154(/*CS=5*/ 15, /*DC=*/17, /*RST=*/16, /*BUSY=*/4));

This works fine and in standby the whole circuit uses 62 uA of power which is in the expected range.

Now, I am keeping the exact same setup, PCB and code, just changing the driver to use the replacement display (GDEH0154D67):
Code: [Select]
GxEPD2_BW<GxEPD2_154_D67, GxEPD2_154_D67::HEIGHT> display(GxEPD2_154_D67(/*CS=5*/ 15, /*DC=*/17, /*RST=*/16, /*BUSY=*/4));


And suddenly, the standby current "jumps" to 630 uA. This is significant and I am wondering if more modifications in my code are needed than just the initiation line or if some different hardware is needed or the driver is not yet capable of bringing the display into standby correctly?

Anyone else seen this behaviour?

Thank you

ZinggJM

#377
Jan 26, 2020, 03:06 pm Last Edit: Jan 26, 2020, 03:11 pm by ZinggJM
@woessmich,

I don't remember, but I think I forgot to check and measure current drawn.

Code: [Select]
void GxEPD2_154::_PowerOff()
{
  _writeCommand(0x22);
  _writeData(0xc3);
  _writeCommand(0x20);
  _waitWhileBusy("_PowerOff", power_off_time);
  _power_is_on = false;
  _using_partial_mode = false;
}

versus
Code: [Select]
void GxEPD2_154_D67::_PowerOff()
{
  if (_power_is_on)
  {
    _writeCommand(0x22);
    _writeData(0x83);
    _writeCommand(0x20);
    _waitWhileBusy("_PowerOff", power_off_time);
  }
  _power_is_on = false;
  _using_partial_mode = false;
}


Maybe the controller needs be told to first turn on (or keep on) power, to then turn it off.

You can try to change line 314 to 0xC3.

(0x22:activation sequence, 0x20 master activation)

I will check this later, too busy for now.

Jean-Marc
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

woessmich

#378
Jan 26, 2020, 06:13 pm Last Edit: Jan 26, 2020, 06:14 pm by woessmich
OK, Thank you for the quick and really helpful reply.
I tried your suggestion but it did not change anything.

After much more testing, I am convinced the driver is working correct because if I disable hibernate manually, current increases from 630 to 660 uA even.

It seems to be related to the hardware driver I am using.
With the standard Waveshare "1.54 e-Paper Module" (I bought it with the old display initially) both versions of the display show a hibernate current of 57 uA (display only this time, measured on VCC)

With my own driver-board, which is based on the old Waveshare schematics, I measure 29 uA with the old and 630 uA with the V2 display. Something is behaving differently with these new displays from a hardware perspective and I also noticed that the display gets cloudy after some seconds in hibernate like if the high voltage is not disabled properly with my board on the V2 display. I am not sure why, more measuring needed.

This came really unexpected as the old display behaved so well. I guess, I have to do some more research here what I have to change on the hardware side.

Thank you again
Michael





woessmich

I want to add some insights after more testing, in case in helps someone else at some point:
With the old 1.54" display (GDEP015OC1) current draw during deep sleep of the ESP32 makes a huge difference (150 uA) if I use the internal pulldown on the CS-pin while sleeping.
Code: [Select]
gpio_pulldown_en(GPIO_NUM_15);

Unfortunately, with the new display (V2; D67) I never get below about 600 uA with my board, regardless what I do to the pins.
However, although this sounds a bit unscientific: when moving around my finger on the connector pins (Yes, this should be avoided for several reasons!), it sometimes goes below that value, so I am convinced there is something going on that can be avoided somehow. I have just no idea how as neither pulling low any of the pins nor pulling them high had any effect.

If there is somebody out there with experience on designing a board around the ESP32 and this display and likes to share some insights, I would appreciate it.

Michael




ZinggJM

@woessmich,

I didn't check, but I think I saw in the controller specs of the D67 that it activates the BUSY line during hibernate. So, if you have any load on the BUSY line, this could explain the current draw.

Do you only hibernate the display, or do you use deep sleep of the ESP32?
The ESP32 has internal pull-ups or pull-downs on the "strapping pins", for boot mode selection.

Jean-Marc
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

woessmich

Yes, you remember correctly. It is mentioned in the table on page 20.

The same is not mentioned in the datasheet for the old version which does not necessarily mean anything.

Yes, I hibernate (deep sleep) both the ESP32 and the epaper. A lot can be done by code with the ESP32 pins during deep sleep. There are not too many pins involved in the e-paper communication and at least I tried pull-down and pull-up before sleep for all of them with no significant difference. Maybe there is other things I can do.

Do you know why pin 4 (epaper) is listed as NC (keep open) in the datasheet but connected to a decoupling capacitor C1 in the waveshare schematics for the board?
This does not seem to hurt as the waveshare board has it from the looks of it and it works well with both display types. Also the inductor is different: 10uH vs 68uH.

ZinggJM

Quote
Do you know why pin 4 (epaper) is listed as NC (keep open) in the datasheet but connected to a decoupling capacitor C1 in the waveshare schematics for the board?
No.
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

woessmich

... more testing...

What I found is that the RST pin of the display needs to be kept HIGH during hibernate/deep sleep of the display. As soon as it drops to LOW, the display's current draw increases from single digit uA to about 0.6mA. Probably it just wakes up again.

With the standard definition given, GPIO16 is used for the RST pin and I have not been able to keep GPIO16 at a high level during deep sleep of the ESP32.
From what I read in documentation and other pages, it should work with
Code: [Select]
gpio_hold_en(GPIO_NUM_16); but it does not.
Same goes for GPIO17 and maybe all other pins that are not RTC_GPIOs.

However, e.g. GPIO13 is easy to keep HIGH using the command
Code: [Select]
gpio_hold_en(GPIO_NUM_13); just before going to deep sleep of the ESP32.

The Waveshare breakout board, using a level converter, seems to keep the state during sleep of the ESP32 while my own board, with no need for the level converter, does not.

If there really is no way to keep the pin in HIGH state, using GPIO16 for RST might not the best choice when going for low power applications with the ESP32.
Or of course an external pull-up on the pin can be used to solve the issue.


ZinggJM

@woessmich,

I measure the following current drawn through the 3.3V VCC line to the DESPI-C02 with connected GDEH0154D67 e-paper panel:

up to 3mA during full refresh, ~1mA during partial refresh, 20uA during powerOff, 0.6uA during hibernate.

I have not planned to investigate current drawn during processor deep sleep.

Jean-Marc
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

ZinggJM

#385
Feb 15, 2020, 09:40 am Last Edit: Feb 15, 2020, 09:55 am by ZinggJM
News: e-paper displays with DES technology

I just discovered this Power Point presentation from Good Display about (their) new technology:

Display Electronic Slurry(DES) Introduction

1.54 inch DES e-paper display high resolution 200x200 partial refresh GDEW0154M09

Jean-Marc
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

tropic

Hello @ZinggJM,

I have a problem with panel GxGDEH0213B73 from Good Display.

I'm using the partial refresh mode with several refresh as you advise in a previous post. But the screen goes clear after few seconds under the sunlight.

Do you know this problem? Is there a prameter to avoid this?

Thanks for the help

ZinggJM

#387
Feb 15, 2020, 02:40 pm Last Edit: Feb 15, 2020, 02:41 pm by ZinggJM
@tropic,

The only e-paper that claims to be UV-resistant is the GDEP015OC1, as far as I know.
You could try to add a UV filter. But it could also be caused or worsened by temperature.

There is no parameter to avoid differential refresh.
But you could replace line 407 by line 396 in GxEPD2_213_B73.cpp to use only full refresh.

Jean-Marc
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

tropic

Thanks for your fast reply.

It's really weird because after a full refresh the screen remains the same even after several hours under
sunlight.

ZinggJM

@tropic,

try if calling powerOff() after partial update helps.

GxEPD2 calls powerOff() only after full update.

Jean-Marc
No personal message please; any question may be useful for other users. Use code tags for code. Make links clickable with URL tags. Provide links to the product in question.

Go Up