Hello @FlooidOps
yes, that pretty sure is your issue. Have you tried to switch to the alternate GPIO for Ethernet CS, e.g. GPIO2 (instead of GPIO 33)?
Thanks
Felix
Hello @FlooidOps
yes, that pretty sure is your issue. Have you tried to switch to the alternate GPIO for Ethernet CS, e.g. GPIO2 (instead of GPIO 33)?
Thanks
Felix
Hello @Raed-Alnuaimi
the example is in the Project Zone (by mistake I wrote Play Zone, sorry about that). Fixed in my post.
Thanks
Felix
Hello @phantompants
well, from what I can tell AI didn't catch that you wanted to use an M5Stack ATOM GPS Kit and failed to setup the correct GPIOs etc.
Please find a GPS example using an Atomic GPS Kit here.
Please note: It only reads and prints GPS data. I'll leave the rest for you to figure out.
Thanks
Felix
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
Hello @nyoromo60
こんにちは
SIMCOM には、support@simcom.com というサポート用の電子メール アドレスもあります。
ありがとう
フェリックス
追伸Googleで翻訳した
Hello @wouter
that is strange indeed. I have no idea as to why after as successful burning of V2.0.5-Tough your device would still boot up with the previous factory installed firmware. Maybe try to erase first?
Thanks
Felix
Hello @UP_BIM
yes, I noticed that error too. Try adding an Init pahub_0
block manually.
See Project Zone example: M5Tough_PaHub_Multiple_Units_UIFlow2.0.5
Thanks
Felix
Hello @UP_BIM
it just occurred to me; except for the 7th ENV IV unit you could get away with only one PaHub like this:
Core I2C Master --- PaHub
|
[0]- ENV IV - DLight - VMeter - CO2
[1]- ENV IV - DLight - VMeter - CO2
[2]- ENV IV - DLight - VMeter
[3]- ENV IV - DLight
[4]- ENV IV
[5]- ENV IV
Thanks
Felix
Hello @wouter
I don't think your M5Tough is actually running UIFlow2 since you are writing that you're seeing "Tough Tools" and several menu-items on the bottom. I think it is still running the Tough Tools firmware it came with (which is different from UIFlow2 firmware).
When UIFlow2 is running on your M5Tough it does say so on the screen. On screen at the top from left to right you should see: UIFlow2 / Time / WiFi signal / Cloud connection state / Battery state.
Thanks
Felix
Hello @Senspix
I just tried with my SIM7600G (non -H; 3 years old) and M5CoreS3 using aforementioned test program and the modem does react to AT
commands just fine after about 14 seconds.
Recently I purchased a separate green board with a SIM7600G-H on it which I use in the same COM.X module. Initially it did not work. Turns out the green board had a layout error - RX and TX needed to be swapped electrically in order to work in the COM.X module.
In conclusion: I can use either SIM7600G or SIM7600G-H with M5CoreS3 just fine.
Thanks
Felix
Hello @Senspix
I don't think the PCBs are different - to me it looks more like a sticker has been added to the same PCB. But I could be wrong.
Maybe try swapping a SIM7600G (non -H) into a PCB with sticker to see if that works? Also make sure you firmly stack the COM.X to your M5CoreS3. It could be a simple connection issue.
Maybe this simple test program might help evaluating the hardware? It sends an AT
command repeatedly. Edit: I just re-read your post. You already tried simpler programs.
Edit: Well, it could also be a power issue. How are you powering your LTE modems? Through the DC jack or from the M5CoreS3?
BTW: I noticed the incorrect antenna connection about 3 years ago. See here.
Same with the SIM7600G vs SIM7600G-H version. At the time (3 years ago) the M5Stack shop talked about CAT4, but was selling the non -H version (which is only CAT1). See here.
Thanks
Felix
Hello @UP_BIM
from the syntax I gather you are using UIFlow1 (and not UIFlow2), correct?
I already tried in the past to use a PaHub with non default I2C address in UIFlow1, but I wasn't successful. I don't think it is possible - but I could be wrong. In UIFlow2 I found a solution. Please see here.
Thanks
Felix
Hello @UP_BIM
ok, I see, thanks for posting the example.
How many of the sensors have a unique I2C address? All of those can be connected directly to the core (i2c master) in paralell. Only the sensors which share the same i2c address need to go behind a PaHub (unless there is a way to change the i2c address of those sensors). For instance like this:
Core I2C master ----|----------|----------|---~ ~----|
PaHub(0x70) S1(addr1) S2(addr2) S6(addr6)
|
| -- 1: S10 (addr10)
| -- 2: S10 (addr10)
~
| -- 5: S10 (addr10)
| -- 6: S10 (addr10)
Thanks
Felix
Hello @UP_BIM
are you sure the examples you found are talking about nested PaHubs?
Could it be that they mean connecting multiple PaHubs (with different I2C addresses) in parallel? E.g.
Core I2C master ----------|------------|------------|------------|----~
PaHub(0x70) PaHub(0x71) PaHub(0x72) PaHub(0x73)
BTW: I don't think UIFlow supports nested PaHubs.
Thanks
Felix
Hello @Cognitive5525
above measurements have been done via battery connector @ 4.2 V.
If I use the green connector (and with aforementioned hardware modification) then in shutdown mode I measure about: ~ 1.5 mA @ 6 V
I guess the higher shutdown current (compared to when powered via battery connector) is due to the DC/DC converter converting +VIN into +5VIN and the battery charger IC which both stay powered even in shutdown mode.
Thanks
Felix
Hello @Cognitive5525
please find my measurements here.
M5Dial.h
includes M5Unified.h
. See here.
Thanks
Felix
Hello guys
@Cognitive5525 : I think I know the reason for that 5 V connection between M5Stamp and the M5Dial board. It is required for battery charging when powered from USB. But M5Stack probably should have used a diode there to make sure power can only flow from USB to the battery charger, but not the other way round.
BTW: as an experiment to prove the above I removed the 5 V connection between M5Stamp and M5Dial board and now I can power M5Dial from the green connector and it does a proper shutdown (same as when powered from battery) and can be woken by the wake button.
Please note: If you go that route yourself, please be aware that I cannot be held responsible for any damage that might occur and you most likely void the warranty of your M5Dial.
Thanks
Felix
Hello @Cognitive5525
you are correct, M5Stack is not consistent and the function M5Dial.Power.timerSleep(10);
, when followed down the rabbit hole, does all of the above (deep / light sleep or shutdown) depending on the core and possibilities.
Good find. M5V is the 5V of the M5Stamp. Now we know why M5Dial stays powered on when powered from the green connector. I wonder why M5Stack thought this connection is needed as M5Stamp is already powered through 3.3V. Strange.
Thanks
Felix