@volker EPD and GT911 should save you 130-160mA power draw. The IT8951 itself alone would be pulling most of that, the GT911 should be below 20mA even when actively used. It's a bummer M5 decided to use that crappy PMIC instead of the AXP192, which would've had the pins required to control those elements separately (also bummer that the e-ink display uses a separate, power-hungry controller...).

@m5stack I'd gladly consult with your engineering team in my free time, to at least try to give a customer/consumer oriented viewpoint. I believe that a company works best if they listen to their customers and work together to get the best possible product out to the market.

Also, in the meantime, could you please confirm/answer the so far unanswered question from the thread linked above? About the IT8951E sources, if you'd be able to publish them, and if it's possible to flash the chip through the existing SPI interface. I'm pretty sure the community would be able to find the reason why it's sucking so much power unnecessarily, and we could possibly even fix it, so that future batches can ship with better performing components.

@m5stack I've tagged you multiple times in the thread that detailed the issues with the M5Paper. Please check it under the Feature Wishlist category.

But to summarize:

• the switch to the SLM6635 from the previously used AXP192 is a downgrade - less channels to control, worse battery life control, and faulty voltage reporting during charging (basically it reports the charging voltage instead of the actual cell voltage, and also fails to charge above 4.2V while the cell in the M5Paper is 4.35V)
• the IT8951 is a massive power hog due to issues in its firmware. It's obvious from the schematics that you planned to hook that up to a USB port as well (which never happened and makes firmware updates impossible without HW mod), but the point is... This damn driver eats 80-100mA in idle. Which is unacceptable. There were suggestions to use a secondary MCU that would take care of the eink waveform generation with a similar API the IT8951 uses (but open source), or a shift register.
• the SHT30 is a bit useless because the internal heat of the unit skews temperature, and humidity can't be reliably detected with the limited airflow. An MMU would be much more beneficial
• I would also like to see a newer ESP32 (preferably the S3, when it becomes available), due to those having built in USB stack, making the M5Paper a great handheld hacking tool - e.g. one could program it to act as a USB keyboard, or a hard disk (exposing the SD card), or even a hardware crypto wallet similar to Trezor.

Overall the display and form factor are great, but there's a lot more potential that could be brought to your users with just a little more attention. The current M5Paper just feels like you guys got a bunch of new engineers that brought some relevant experience, and wanted to use parts that they knew how to work with, instead of picking parts that actually work well together. LilyGO brought out a very similar board with the (almost) same display, but better battery management, no power sucking eink controller, or unnecessary sensors.

Edit: here's the link for the topic I've mentioned https://community.m5stack.com/topic/3007/m5paper-ideas-recommendations-for-a-revision-or-v2-model/21

@ajb2k3 that tweet from 29 May is showing the same board as the current M5Paper. Even the same display driver chip - which seems to be in short supply.

@m5stack I wonder if the issues with v1.0 that have been pointed out by multiple people have been fixed - especially the power management part.

@lypanov the main power hog on the M5Paper is the secondary MCU in control of the e-ink display. The IT8951, while a great chip that simplifies e-ink management, has a massive issue that has been pointed out multiple times - it's idle power use is around 100-130mA, which is not really acceptable for a low power solution. You could counter this by manually disabling power to it after a certain period of inactivity, but that's extra hassle.

If you want a slightly better power managed board with similar specs, I'd recommend looking into the LilyGO TTGO T5 4.7 - it uses pretty much the same display module, same ESP32, same RAM and flash, but no wonky e-ink controller (instead it's handled by the ESP32), and much better power management.

@m5stack it's been 3 weeks, without even a confirmation that you've read the issue. Could we please get an update? Or maybe @Zontex, you could bug someone at M5 HQ, since you seem to be more active.

This does not need a "revision" or "V2" model, it's a simple software addition. And you can already load your own fonts if needed.

A reset will trigger a power cycle, which in turn resets the SPI connection to the e-ink display. The display has a controller built-in, which at this point is also power cycled, and most likely runs the initialisation of the screen. So when you press the reset button, the display thinks it needs to get into a "ready for new data" state, which is why it "fades".

If you want to work this around, I'd recommend storing the screen contents every time you write to the screen, to storage that is preserved during a power cycle (basically, dump that 200x200 4b array onto the flash), and make sure that your startup handling "updates" the screen with that content immediately after the device is initialised.

Recommendation: use GitHub (or similar) to host your code, not Google Drive :) It makes things easier to read through quickly, plus people can make pull requests to improve the code.

Okay, so ITE came back to me regarding the IT8951 things. Unfortunately they do not offer the source code directly to developers, only to business partners - and that's M5Stack themselves. @m5stack could you please give us some details, or if the NDA allows, release parts of the IT8951 firmware?