A kinda related, but strange question - could you please release the source code for the drivers of the various bits of hardware found in the UIFlow firmware? UIFlow is built upon MicroPython, and I would personally prefer to run a clean MicroPython build on a few devices of mine, however the lack of drivers makes it a bit harder than expected. I'm not interested in the UIFlow-related parts, just the low level Core/Unit/Module support drivers (e.g. for M5Paper, a driver for IT8951, a driver for the PMIC, SHT30, GT911). It would allow the community to build MicroPython images without proprietary code, and possibly result in faster updates as well. Plus, you could merge back community fixes into the official UIFlow firmware easily.

After spending about a month tinkering with the M5Paper, a handful of shortcomings in the design have become apparent. This wishlist is what I would like to see in a future iteration of this otherwise great little device.

The first point I'd like to address is the core being used. While the ESP32 module used is fine for most purposes, Espressif has announced the ESP32-S3, which, among the upgraded cores, brings a few new features, most prominent being the built in USB stack. This would allow dropping the serial adapter chip, and using the MCU directly for USB functionality, including flashing, and even allowing the device to act as a USB peripheral (or host, for e.g. a keyboard, though power supply could be an issue).

The second point is power management. I don't want to 💩 on your work, but the M5Paper clearly received a less favourable treatment than the other M5 cores. Power supply is unnecessarily overcomplicated, and the design results in very little control over the power systems, and down the line, massive power drains unless the developer implements drastic limitations. Even the deep sleep mode of the ESP32 is drawing too much power, due to the choice of eink and touch driver (well, with the touch driver, the main issue is not having a separate power switch). Due to this, I'd like to see the return of the AXP192, which was proven quite capable in the M5Stack Core and M5Stick series. It's managed over I2C, provides better power management of components, better battery support (not to mention proper reporting of charging/discharging state and battery voltage/life reporting), and overall a better option for the overall power management. I believe it also provides drip charging, which would be crucial to extend the battery life when it's mainly mounted to a continuous power supply.

Third point is the eink driver. While the IT8951 is very capable, it was not designed with battery operated systems in mind. I've read multiple reports, not just on the M5Paper, but on various Waveshare units that also use the IT8951, that its low power/hibernate modes are unusable - the chip actually draws more power hibernated than it does in standby, and it's not a negligible amount (around 120-130mA). While this is fine for a mains powered project like a Raspberry Pi, it won't work well in the M5Paper. If I understand it right, the IT8951 basically obfuscates the waveshape messaging part of the eink protocol, providing a more manageable solution, at the price of considerably higher power usage.

The touch driver, that I'm actually happy with. The only negative I can say is that it has no separate power management, and such it cannot be disabled when not needed. With the AXP192, that should be doable, though.

Fourth point is the temperature/humidity sensor. Its unfortunate placement makes it practically useless - the proximity to the battery and the rest of the board makes temperature readings unreliable when the ambient temperature is lower than the internal temperature, unless the device was freshly powered on. The humidity sensor works, but due to the restricted airflow, which opens from the back, makes its use quite limited. Instead, I'd recommend replacing it with a combined 9DoF sensor (accelerometer, gyroscope, and magnetometer), which could provide better everyday usage, for example, for screen rotation. Though the built-in magnet might interfere.

And if we're talking about power, I think a similar POGO pin connector as the one on the M5Stack FIRE's charger base would be beneficial. A four pin connector, with I2C exposed, and the power lines connected to the PMIC, would allow for custom docking bases (e.g. a wall mount with an I2C temperature/humidity sensor, for a tear-away smart home control panel and thermostat, or a desk mount for a ticker style display for e.g. temperature). The M5Paper is clearly meant to be a semi-permanent mounted solution - most of the time it would sit in a dock, but the battery would allow for temporary mobility, such as the previously mentioned tear-away console, which mostly sits in a wall mount, but allows the user to pull it off and use it e.g. as a smart home remote.

Also another power point - a separate coin battery for the RTC. I understand that the current solution uses barely any power, however I'd feel safer if the RTC had a separate power supply in the form of a replaceable coin battery. If designed well, this would provide years of supply for the RTC (a standard CR2032 easily runs a ZigBee motion sensor for 6 to 12 months), and separate the power concerns.

Last, but not the least, the side buttons. The current solution is, honestly, quite bad. I'd rather have either three separate buttons, or a button and a full rotary encoder, or practically any other solution that provides 3-4 inputs (one of them being an interrupt/wake signal for the PMIC and the ESP32).

Otherwise, the form factor and size are perfect. LilyGO came out with a similar board around the time the M5Paper was released, same eink display but different driver, similar touchscreen, and support for both 2-pin Li-Ion, and 18650 batteries (as two "separate" model - the only difference is the connector soldered onto the board). I'll be grabbing one soon, at least to compare it to the M5Paper. The fact that the touchscreen is only available separately, and it isn't packaged as nicely as the M5Paper makes it a harder sell, but I can see the advantage of the different design.

So, to list the overall changes recommended:

• ESP32-S3 instead of the current MCU
• Replace SLM6635 (ideally with AXP912)
• Replace IT8951 with a better option (maybe just a simple shift register, similar to how the LilyGO T5 4.7 solves it)
• Connect external components (eink, touch, each external port separately) to the PMIC for separate control of power
• Replace SHT30 with IMU
• Add a POGO pin connector for power/I2C, similar to M5Go
• Replace side button with a different implementation (either three separate buttons or a rotary dial and a button)
• Replaceable coin battery for BM8563

@sambartle the battery voltage increase is actually because of the charging - the PMIC reports the charging voltage, and without the load of running the M5Paper from battery. Just by using the battery instead of an external power source, voltage can drop by 0.1-0.3V as well. The PMIC in this device is incredibly dumb, and some of the features (e.g. the charging/charged indicators) aren't even hooked up.

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

You could use the EEPROM to store the state in - e.g. last time the device went to sleep, last time NTP sync happened, etc. - and use that to decide which path of logic you need to follow.

For example, this could be the full flow:

setup():

1. Get EEPROM, extract last NTP sync (last_ntp_sync), last boot time (last_boot), and last requested sleep length (sleep_duration)
2. Get RTC time (rtc_time)
3. If last_ntp_sync is empty, go to first_boot()
4. If last_boot is empty, go to first_boot()
5. If rtc_time - last_boot < sleep_duration (maybe add some wiggle room here, 1-2s should be fine), go to manual_wakeup()
6. Otherwise, go to rtc_wakeup()

first_boot():

1. Connect to WiFi
2. Request date and time from NTP = new_rtc_time
3. Update RTC with new_rtc_time
4. Update EEPROM's last_ntp_sync and last_boot_time
5. Proceed to draw_clock()

rtc_wakeup():

1. Check if last_ntp_sync is not too old (e.g. you'd probably want to sync with NTP daily)
2. If last_ntp_sync is too old, go to a method that syncs RTC time
3. Update EEPROM's last_boot_time
4. Proceed to draw_clock()

manual_wakeup():

1. Do the whole NTP check dance again (probably worth organising into a separate method)
2. Do whatever you want to do if the device wakeup happened due to the button press
3. Proceed to draw_clock()

Obviously extend it to your liking, but by storing these values, you can compare the last stored date with the RTC time, and act accordingly. It's not as elegant as e.g. having a proper boot reason, but it works.

@rahulthakurms Are you running the FactoryTest firmware? If yes, go to the test page while charging and watch the battery item - it should show ~4.25V while charging. Then unplug the charger and check what the voltage drops to. Around 3.5-3.6V the battery is basically discharged completely. The percentage calculation of this firmware is quite simplistic (linear relation between voltage and percentage, which is mostly incorrect - you'll see that under the same load, the first 10% drop, i.e. 100% to 90%, will take roughly twice as long as, say, 30% to 20%).

@Zontex I hope all these issue reports are logged for future reference for a V2 of the M5Paper. We definitely need a better charging IC, and a simplified circuit of voltage regulators to reduce power consumption in deep sleep mode. Possibly even a switch to a PMU that supports digital control. And of course better power control of the components (e.g. turning off the touch screen, or at least hooking it up to an interrupt on the ESP32). The current implementation of the M5Paper feels a bit rushed and untested, closer to a v0.4-0.5 than a v1 release.

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

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.