Topics created by HappyUser

Hello @HappyUser

the code works for me using M5Core2v1.1 and the following modifications:

//#include <M5Core2.h> <-- replace this with below lines #include <M5Unified.h> #include <Wire.h> M5.begin(); Wire.begin(); <--- add this after above line

Thanks
Felix

@kuriko
Indeed a strange situation.
It occurs if I use TX=26 and RX=32 and also TX=22 and RX=19 to initiate the can BUS on a M5Atom
ESP32Can.CANInit(); // Init CAN Module. 初始化Can

If i dont initiate WifI I can send data through the CAN BUS. The moment I initiate WiFi, no data come through in the CAN BUS.

I will do some other trials with other devices (M5Core 2 and M5Atom S3) to check if it is a hardware problem.

I do hope to get this solved because if this problem is definite it means the Communication abilites of the CAN bus are limited.
Regards

(* Oh, important : When using WiFi i do receive CAN BUS messages , so that is weird, i really need to dive into this*)

@felmue said in M5stack GPS, use Serial2 and Serial1:

Well, now i need to recheck what i have been doing.
Your example works both on M5Stick (using ports 0 and 26) and M5Atom (ports 26 and 32).

Thank you, i have some work to do, Ha Ha

@HappyUser First tests seem to indication that in order to switch from data mode to GNSS mode, you need to power off the GNSS module. As a result, the GNSS forgets its position and it takes another 5 to 10 seconds to get updated position data again. Btw, during the whole operation the module is powered. we are open to smarter solutions for this problem.

@felmue Thank you. Makes powering some mobile SIM7080 based projects a little easier. We will start some duration tests. Regards

Hello @HappyUser

you are very welcome. I am glad to hear you got it working to your liking. And thank you for reporting back.

Thanks
Felix

Cheers, I'll be interested in your findings!

As you might have seen in this small "saga" here, I have a similar problem with some (but not all) of my 30+ CoreINK devices which have a similar power control circuit.

@happyuser said in M5Dial generate interrupt from RTC?:

I assume your conclusion is then also : no wake-up with RTC interrupt?

Uhm no, or yes.... maybe.... depending of how you define "wake-up"🤔 ☺️

When Q3 goes on the hole board including the ESP32 is switched on so in my book the RTC can "wake up" the hole board. Of course you could say that this is more like "switching on" than "waking up".

But in fact, when ESP32 is in its "native" deep-sleep the main CPU is also effectively switched off which means it needs to boot completely from scratch when it "wakes up" from that state. Now, it is correct that there are some build in features to test for the reason of the boot and then have the program act on that, but that is actually also possible with the circuit M5Stack built. There is a signal called "wake" connected to GPIO42 which will indicate for the ESP32 whether it was started by the push button (S1) or by the INT signal from the RTC chip.

I can only speculate in why M5Stack has chosen not to use the build in ESP32 RTC/deep sleep functionality but here is two reasons:

If the board as a hole needs to have a very low power consumption in (deep)sleep mode it is not enough to just have ESP sleep there are other chips or circuits that may still consume "a lot" just by having Vcc applied. So you need the MOSFET switches any way for a "good sleeping" board and the BM8563 seems to consume less than the ESP32 built-in RTC about ~2-3µA vs 10µA

It is possible as the stamp IO is a reprogrammable STM32f03

Here : https://github.com/m5stack/M5DinMeter

Thank you, but the is too much off a hassle, will come up with another solution.
Regards

In this testing environment I wired it to the 3.3 volt output of the Stamp. Not the best solution, ha ha, given the power the SIM7080 module needs. I am now converting it to powering the SIM7080 module with separate 5 volt line.
That should do the trick.

Hello @HappyUser

it is correct that M5StampC3 is supported by M5Unified library, but I can confirm that the library currently doesn't compile due to errors in Mic_Class.cpp and Power_Class.cpp.

I suspect that since there isn't much to gain from using a library like M5Unified for a stamp product (as @teastain already mentioned), M5Stack engineers aren't that alert in keeping the library updated.

Thanks
Felix

Solved
I don't why I have been klinging on to Serial2, it got me in all kind of testing out, but the solution is to use Serial 1.

I'm not exactly sure but I think it could be around 500mA but the data sheet is in Chinese and I just woke up.

@felmue And indeed, I needed to add a delay before sending the payload. I had hoped that it would be necessary (in order to speed up he process of waking up, sending and going to sleep).
Regards