Posts made by felmue

Hello again

Update: in the above experiment my M5Paper successfully came out of deep sleep for the last time at about 3.31V (multimeter value) / 3.284 (ADC value). Next time I checked it died during boot.

Thanks
Felix

Hello @pipy71

looking at the GSM SIM800L pin map or schematic I can see that GPIO5 is used as reset (RST). On M5Core2 GPIO5 was replaced with GPIO33 which is also used for SCL (I2C) on M5Core2 Red Port A. That is why it stopped working.

In other words the GSM SIM800L module is not fully compatible with M5Core2. It can only be used if you disable the external I2C on the Red Port A.

I've made a comparison list of all the GPIO changes between M5Stack and M5Core2. You can find it here.

Thanks
Felix

Hello @mad23

have you considered using the 4 relay unit?

Thanks
Felix

Hello @mad23

I'd say so, yes, but I don't have a Pb.Hub so I cannot say for sure, sorry.

@all: maybe somebody who owns a Pb.Hub can help out here?

Thanks
Felix

Hello @paul-k

how far did you get? Is the M5Core2 talking to the LoRa module?

Keep in mind that the LoRa module was designed for M5Stack (Fire, Gray, etc.) and some GPIOs have changed from M5Stack to M5Core2. You can find a comparison here.

I don't have the LoRa module, but from looking at the schematic this should be the GPIO mapping:

LoRa      <-> M5Core2 <-> Name

GPIO18  <-> GPIO18   <-> SCK
GPIO23  <-> GPIO23   <-> MOSI
GPIO19  <-> GPIO38   <-> MISO
GPIO5    <-> GPIO33   <-> CS
GPIO26  <-> GPIO26   <-> RST
GPIO36  <-> GPIO36   <-> DIO0 / INT

Note: on M5Core2 by default GPIO33 is used as external I2C (SCL) on the Groove port A. Luckily external I2C is not enabled by default so that should not interfere. Just keep in mind that you cannot use the LoRa module and external I2C.

Thanks
Felix

Hello @teastain

getting it to compile is probably as easy as replacing #include <M5StickC.h> with #include <M5StickCPlus.h>. The bigger issue is the larger screen size which will need to be adapted properly. If and when M5Stack engineers will fix that I have no idea. Sorry.

Thanks
Felix

Hello @uppermill

try to set var1 to 0 before setting the bit.

var1 = 0
var2 = (var1 | (0x01 << 0))

Thanks
Felix

Hello @mad23

Pa.Hub is an I2C extension hub so unless your relays use I2C (which I doubt) you cannot use a Pa.Hub to connect and switch two relays.

Did you mean Pb.Hub?

Thanks
Felix

Hello @pipy71

On M5Stack (Fire, Gray, Basic) the red Groove port A is only usable for I2C communication. The reason is that the same GPIOs (21, 22) are used internally for I2C communication with the IP5306 and therefore cannot be reprogrammed to be used as serial port.

Please also check out Pin Map for red Groove Port A here.

For serial communication you'd need a M5GO Bottom (or Bottom2) which provides you with the blue Groove port C.

Thanks
Felix

Hello @sj3fk3

I am currently running a discharge experiment where I measure the battery voltage with a multimeter and compare the value to what M5.getBatteryVoltage() returns.

M5Paper is in deep sleep and I wake it from time to time and check the values.
So far the values are quite comparable. You can find the data here.

The battery in my M5Paper is a 3.7V type with an end charging voltage of 4.35V. You'll find some additional information in the above link.

Thanks
Felix

Hello @Carles-B

yeah, I cannot say for sure if the LoRa module would actually fit as I don't have one to try.

Good luck with your experiments and thank you very much for your donation. I appreciate it.

Thanks
Felix

Hello @koichirose

here is how I managed to get M5StickC Plus into deep sleep using MicroPython:

p37 = machine.Pin(37, mode = machine.Pin.IN, pull = machine.Pin.PULL_UP)
p37.irq(trigger = machine.Pin.WAKE_LOW, wake = machine.DEEPSLEEP)
machine.deepsleep(20000)

It wakes up from deep sleep either after 20 seconds or when button A is pressed.

Thanks
Felix

Hello again

ok, I've tried out my proposed solution using an M5Atom Lite with a M5Power C Hat (which is similar to the M5Atom TailBat as it turns off if the load is below 45 mA).

When the M5Atom Lite is running it consumes about 50 to 90 mA which keeps the power on as it is above the cutoff current of 45 mA.

When the M5Atom Lite is in deep sleep it consumes about 11 mA which doesn't keep the power on, but waking up M5Atom Lite every 30 seconds from deep sleep solves that.

However with the M5Atom TailBat battery of 190mAh that still only gives about 17 hours of operation.

Thanks
Felix

Hello @Carles-B

I understand you not only have to remove the small white board, but also unscrew and remove the gray bottom plate from M5Core2 in order to attach the module.

Note: Be careful when removing the gray bottom plate as it holds the battery which is connected to the M5Core2 main board.

Thanks
Felix

Hello @findmyname

the Atom TailBat uses an IP5303 which according to its datasheet turns off automatically after 32s if the load is less than 45 mA. From what I can tell this 'feature' cannot be disabled.

Google translated from IP5303 datasheet:
Automatic load detection time | TloadD | The load current is continuously less than 45mA | 32s

So in order to keep the Atom TailBat from shutting off, the M5Atom needs to consume at least 45mA. With the 190mAh battery that only gives about 4 hours.

ESP32 deep sleep (or light sleep) only works as long as ESP32 is powered. And while the sleep modes would conserve energy (longer battery life) they at the same time will not keep the Atom TailBat from shutting off (too little current).

One way (untested) I could see is to put the ESP32 into deep sleep for less than 32 seconds, then briefly wake up (and consume more than 45 mA) to re-trigger the 32 seconds timeout in IP5303, then go back to sleep.

Thanks
Felix

Hello Dean

according to the description the M5Atom requires an FTDI driver.

Note: I don't have a Big Sur installation, so I cannot tell if that will actually help.

Cheers
Felix

Hello @Alban_T

the sketch you linked is for M5Stack devices. M5Atom Lite is a bit different. For instance:

• I assume you modified #include <M5Stack.h> to #include <M5Atom.h>.
• did you also adapt the M5.begin() call to enable I2C? E.g. M5.begin(true, true, true) - the second true enables I2C on Atom Lite.
• is your sensor connected to the proper GPIOs? E.g. SDL - GPIO25 and SCL - GPIO21.

excerpt from M5Atom.cpp as reference:

void M5Atom::begin(bool SerialEnable , bool I2CEnable , bool DisplayEnable )
{
	if( _isInited ) return;

	_isInited = true;

	if( I2CEnable )
	{
		Wire.begin(25,21,10000);
	}

Hope this helps. If not, feel free to post the full sketch.

Good luck.
Felix

Hello @Pensive

ah, ok. There is an electrical / electrostatic issue with the three touch buttons as well. Maybe that is what you experience?

If M5Core2 is not plugged into USB, not sitting on a conductive surface or not hold in one hand and touched with the other the three touch buttons hardly work.

Unfortunately the M5Stack engineers did not implement real touch buttons (which ESP32 provides) but kind of use the edge of the touch screen.

I've managed to improve them a bit by adding some additional copper below - see here.

Thanks
Felix

Hello again

I just noticed that the source code for a couple of Modules and Units have been adapted to M5Core2.

Cheers
Felix

Hello @Pensive

just to make sure - are you calling M5.update() in your loop()? As far as I recall that is required to update button states.

Maybe try this M5Core2 example to verify the buttons work ok?

Thanks
Felix