search

G6EJD / ESP32-e-Paper-Weather-Display

An ESP32 and 2.9", 4.2" or 7.5" ePaper Display reads Weather Underground data via their API and then displays the weather
Other
946 stars 206 forks source link

RFC: plan to support Pi Pico 3.7" display #181

Closed grahamwhaley closed 2 years ago

grahamwhaley commented 2 years ago

Hi, not really an 'issue', more a heads up that I'm working on adding support for the Waveshare Pi Pico 3.7" display support.

I've just opened a PR from my branch on the GxEPD2 library to show how to support this display directly from the Pico. But, as the Pico does not natively have wifi, or a battery charger, and afaik is not particularly low power, I'm planning to do the weather port using an ESP32 firebeetle

I also have a simple example to drive the screen from the Pico Arudino mbed code over at https://github.com/grahamwhaley/pico_waveshare_3.7. That was the first step to figure out how to drive the screen before getting to GxEPD2.

Ultimately, I might end up adding 4-colour support for this display to GxEPD2_4G - if I think 4 levels of gray might improve the weather display at all.

In theory the firebeetle can hibernate at 10uA, and the display says it can go to 10uA. That will hopefully beat by some margin my current 2_13_T5 code that gets down to about 240uA hibernate iirc.

Note, I did a few extra power saving things in my 2_13_T5 code that are not pushed up here, as I was not sure how they would scale across all the examples. I'll see if I can get some PRs or at least notes made about them - iirc it was things like turning off the ADC early and turning down the CPU clock once the network work is done and we are just waiting for the slow epaper to update.

G6EJD commented 2 years ago

Good luck with the GxEPD author!

I have tried turning down the CPU speed much as you describe, but I concluded transferring the data was paramount to the display and then turn it down, but after the transfer there wasn’t much left to do other than wait for the display, so that’s when the saving comes into its own.

The json could be optimised by only decoding the bare minimum, I included all of the data to help those who want to experiment or can’t work out how to structure the decode.

I’ve been through most energy saving trials, incidentally the worst change I made was trialling out weather images instead of drawn vector like icons, it was so slow and consumed a lot of energy, so vector drawing is the solution. On the 16-grey scale 4.7” display I used the grey scale but found the contrast difference was not easily visible and only on the moon image did it show but marginally, then given the image size increase and therefore drawing time, I went back to b/w.

The latest Firebeetle has some really neat design tricks, the main one being a decent isolation link between 5v usb power feed and the 3.3v regulator which enabled them to isolate the usb transceiver completely and hence get down to a true 11uA sleep current with the regulator consuming a mere 2uA of that, leaving ESP32 device variability of sleep current of around 7uA.

Good luck with your mods.

grahamwhaley commented 2 years ago

Yeah. I put out the GxEPD2 PR mostly to ensure there was some searchable historic data out there in case somebody else is trying to figure out how to drive these using the Arduino/pico/mbed/GxEPD2 combination.

Good to hear what didn't work for power saving :-) My 'power patch' is over at https://github.com/grahamwhaley/ESP32-e-Paper-Weather-Display/commit/e4c70a42893f41a1dd643f9893fe8ee956a342d7 . As the document there (oops, didn't realise I'd pushed those notes...) says, the biggest drain is the idle current, but every saving helps!

Yes, the firebeetle schematic looks good. The dual low idle current regulators and the FET switch look like a great design.

I found a comment in the notes section of https://www.instructables.com/ESP32-Deep-Sleep-Tutorial/ where somebody notes the level shifters on a 4.2" display board were not powered down in sleep, so they connected the GND of the display (and the battery voltage divider) to GPIO pins which they then 'released' (tri-stated ?) before sleep. I thought that was an interesting idea. I'll see how the 3.7" display performs when hibernating. I'd also have concerns that I'm not sure a GPIO can sink the current required for a display board - might have to throw a FET in there. We'll see.

First, I need to lash up the firebeetle/pico-3.7" boards for a play ;-)