I am creating this post to summarize my ongoing project of a ESP32 + eInk powered by solar cell.
The aim of this project is purely recreational, with no real use case other than "a solar powered watch". I am basing this in the "Watchy" project (GitHub - sqfmi/Watchy: Watchy - An Open Source E-Ink Smartwatch), and I would also like to port-back any changes that are compatible with it.
The important components BOM is:
ESP32-Pico-D4
AM-5815 as solar cell -> @1.5mA max -> Expected ~2mAh/day -> 5mAs / minute
1.54 eInk waveshare (GDEH0154D67 or GDEH0154Z90 with hacked LUTs)
Preferably V2, since V1 does not deep sleep, using 0.15mA constantly
Some battery, coin, or LiPo as backup when there is no solar power
TPS63900 voltage converter
Lora / Accelerameter / RTC / .... as long as disabled use almost no power
I have already redesigned the HW schematics of Watchy for the new components, and in the mean time I am working on the Software. (I also need to send it for production once I find time to redo the board).
The main power hungry has so far been the Display+Processor. What I have found so far:
ESP32 remove the hash checks on Deep Sleep resume [~17mAs]
GxEDP2 has active wait (until 1.3.9) [~15mAs]
GxEDP2 waits 200ms (until 1.3.9) [~12mAs]
GxEDP2 154_D67 sends SPI packets one by one (instead of all together) [~6mAs]
GxEDP2 154_D67 SPI is 4MHz (could be 20Mhz) [~4mAs]
GxEDP2 154_D67 has 8ms extra wait [~0.2mAs]
For the time being I managed to reduce a lot the power consumption, and I would like (if possible) to get as many changes ported to the amazing GxEDP2 library from @ZinggJM so that everyone can benefit from those. If @ZinggJM can send me a PM or reply here it would be welcome, since I would like to ask some questions about the library design and wheather those can be changed to work faster for my use case (without hacking the upstream library).
My ongoing branch is here:
I will post the github repo with all the code, schematics, 3D model code and all other things once I can clean up and sort everything to be ready to be released.
Any idea on helping the project would be welcome
(Specially any idea on reducing the power usage as much as possible)
In case @ZinggJM reads this I have some questions for the specific case of 154_D67 screen:
Why is SPI_SETTINGS fixed to 4MHz? (the spec says 20Mhz write and 10Mhz read). It would be nice to default to those or to be changeable after the display device is created (to be changed depending on the user needs).
The demo code waits 10ms before soft reset, and after soft rest. But the spec says that soft resets should be checked using busy pin (and I have measured 2ms only is enough). Also on my experiments the 10ms wait before the soft reset are not necessary and only the HW reset delay is enough to cover the chip reseting (around 5ms).
For each byte a SPI transaction is used (with the CS going high and low). This is extremely inneficient, specially to send the 50000 bytes on a full refresh. I have changed that for a _startTransaction() _endTransaction() and resulted in 2x the transfer speed (without SPI bus speed change). Any drawback of using it that way?
I also implemented a _transferCommand() for the cases when you want to transfer data and commands in the same SPI transaction. Which may be marginably faster in some cases. Would you be happy with that?
I don't like your post! You try to force me to defend my design decisions and implementation.
You can use my library or any of the currently 116 forks. Nobody hinders you to use your own fork. Or you can create your own library instead.
I am willing to help users of my library, and learn from use cases for improvements.
But if questions come in the form of criticisms I just decide to not answer anymore.
Hi ZinggJM! Sry if these questions bother you, that was definitely not the intention!
I am actually very happy for all the work you put in your library.
Is simple, generic and works great.
My only purpose opening this thread is to see if I can contribute back.
Since:
In order to fullfill the project I need to cut most of power usage, and change the code of the Display.
I am lacking the full understanding of why the library is done like it is right now.
I am messing with the code, removing parts that I consider "power hungry", but maybe are required (and I haven't seen the side effects yet).
I think that the best idea is to "ask" and maybe even contribute back to the library.
If you are not happy with this approach, is ok as well.
I will fork out my patches. Feel free to sync them back if you want at any point.
Imagine the number of requests the author gets; the individual dialog can get completely overwhelming.
With Github code, there is a pre-determined procedure for enhancing code and suggesting that positive, universal changes be reviewed and incorporated into the original code.
TLDR
Find a project you want to contribute to.
Fork it.
Clone it to your local system.
Make a new branch.
Make your changes.
Push it back to your repo.
Click the Compare & pull request button.
Click Create pull request to open a new pull request.
