Ever since the release of the original M5Paper, the community has been pointing out certain issues with the approach and components used. A really good counter-example was LilyGo's T5-4.7, which presumably used the same (or very similar) EPD, with touch and BMS in tow, plus a number of extra features. It also had some downsides (e.g. using a port multiplexer to communicate with the EPD directly, taking away processing power from the ESP32).

Since, LilyGo has updated their model with the ESP32-S3, with a slightly revamped design, and a similar price point (albeit without touch built in or a case).

I would love to see a next-gen model by M5Stack to be frank. M5 products feel more finished, ready-to-use for tinkerers and DIYers, and the support tends to be better as well. Simply said, I could take an M5Paper and slap it on my wall, and with some minimal coding I'd have a home control panel. With LilyGo products, I'd need to work around their odd design choices (e.g. USB port location), 3D print a case, and so on.

So to summarise, here's my "wish"list of what I'd love to see in an upgraded version of the M5Paper:

• ESP32-S3 module as core
• Direct USB connection (incredibly useful for e.g. CircuitPython!)
• A better EPD controller, preferably open source, and flashable from the ESP core (an RP2040 would work quite well for this purpose I think)
• A better BMS/fuel gauge (voltage based calculations are incredibly rudimentary)
• Proper deep sleep on the ESP cores
• USB-C port moved to the center of the side it resides in
• The three-direction side button replaced with a potentiometer wheel, with an optional click (or alternatively, an "A Button" on the side

Optional upgrades that would be welcome:

• Extra sensors built-in (e.g. brightness sensor)
• Front light on the EPD
• Second USB-C port for host mode
• POGO pins and magnetic mounting, similar to the "base" unit of a Core, or rather, the magnetic adapter, where the extra ports (Ports A, B and C) can be moved to (would be perfect for a wall mounted unit that can be pulled off for controls, and when reinserted, would charge and provide extra sensors).

There's been rumours that you guys are working on it, but it's been nearly three years since the release of the OG M5Paper, and aside from two very minor iterations, we've seen no updates...

@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.