@amedee I think you are right. I think that fix has already been pushed, and the exception is on the readfrom_mem() now, like you say.

It seems like the same approach would work for that line as well.

@ajb2k3

When I add the ENVIII unit to my CoreS3 on port A, and start it, I get the exception at line 98 of qmp6988.py (the call of reset() )

The issue seems to have been noticed and fixed 8 months ago though, by some guy named Gandro:

https://github.com/gandro/micropython-m5stamp-c3u/commit/fe3ddc3d0c09cca4096dcfc37bbbf57e7b4a1271

It was (seemingly) caused by the QMP6988 chip in the ENVIII resetting in the middle of an I2c transaction during a requested reset (from line 97 of drivers/qmp6988.py), and the driver file not handling the timeout exception causing the exception/crash.

The fix was to just put a try/except around the transaction in reset(), and if the timeout is generated, ignore/handle it.

I found this with 5 minutes of googling. Not sure why M5Stack hasnt fixed it yet for all products that use the QMP6988

@alan-zhang said in SIM7080G Module speed and stability:

I've tested the SIM card from a phone and it's 1MB/s download and upload.

Your phone might be using 3g/4g/5g/LTE and not NB-Iot or Cat-M. In fact Ive never seen a phone that uses NB-Iot or Cat-M (Doesn't mean they might not exist though)

M5Stack does sell an LTE module if you want LTE speeds though.

Module/product idea...

Combine the core display module with the usb module, add a minimal HID driver processing for a usb mouse, a config option to use the external hdmi as the "default screen" and if used, have the background task or the module itself process Hid events like mouse movements and clicks, and update a visible mouse cursor on the selected screen, and have a config option to process mouse clicks as touch events for apps.

If present and configured, you could boot up and drive any program or even the Uiflow demo/setup, using a mouse, on the hdmi monitor. might as well add keyboard support to add keypress events.

@gavin67890 said in Display Module 13.2 issues:

I'm actually a little curious to see what this module does. There appears to be a separate UI, which maybe needs to be directly specified, rather than a mirror of the Core2 screen.

I think this may be the disconnect here. My understanding is the same, that the display module isnt something that just mirrors the device's screen to an external hdmi monitor.

It is (I am fairly sure) like the LCD unit, it just provides another, external screen space for you to draw in. You have to manually (via code) draw whatever you want on -that- screen/display, in code. It doesnt automatically duplicate what is on the main core lcd screen. the UIFlow demo app / setup menus arent going to appear on the HDMI display just because they appeared on the main LCD.

Although it -would- be a cool "requested feature" to have some sort of config/setup toggle to choose a display module as the "default screen" at boot - but then you would run into other issues, like.. how would you interact with the UIflow startup menus/network config/demos etc? There is no default "mouse driver" - even if you had the USB module as well. You would lose the touch interface unless you wrote your own.

And there you go, a new m5stack product request! - A combo HDMI display + USB mouse module with minimal driver to handle mouse movements and button clicks, a background task to continually update the position of a visibile mouse cursor, and if all present at boot time, just default to that display, and process those mouseclicks the same as touch input events. Assuming the USB module can handle HID devices, and not just filesystem devices/thumb drives, that should be an easy peasy piece of code-cake even with existing HW. Get on it, M5stack!

And clearly Ive had too much caffeine and should stop babbling.

@karlrs What are you trying to draw on the monitor?

@robot_alf "need to connect sensors to 1,2,3 ports of pahub, not to 0,1,2"

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors :D

This came up on a facebook group discussion on the RTC in the Core2 and Core3

There is a bit in the "seconds" register in the RTC's BM8563 chip that indicates that the chip has had low voltage at some point and that the internal timestamp information may be corrupted.

However, it looks like the m5stack library (on github) for this RTC chip specifically masks out this bit when reading the timestamp information. This is sensible for getting the correct number of seconds, but it means this status bit is not visible to users.

If the library could provide a way to read this status, and even provide it via UIFlow2, then users could check the integrity of the timestamp info of the RTC.

Maybe a "Get System Time Integrity Flag" or "Get RTC Low Voltage Flag" or something? Then if this flag is set, the user could refresh the RTC's time to maintain accuracy.

Just an idea.

@dank said in Power Supply of COM.LTE (SIM7600):

. On the shop site, it's mine...

Do you have a link to the shop site that shows the board that looks like yours?

Is the new product tomorrow going to be the new M5StickPlusS3?