Posts made by teiafra

Hi @felmue and many thanks: we'll have look.
From our side, good news. M5Stack guys gave us the tip to set ECHO OFF once the module is resumed from the sleep, so soon after PWRKEY sequence, our code checks module status and then set echo off.

In this way we're able to launch the MQTT client (provided with the new IoT Base CAT-M palette) and publish a topic.

We were not able to catch the "EXIT PSM" URC. We noted however that if the code invoked earlier the "network active" brick the URC shows +APP PDP DEACTIVE (we guess that TCP sockets are closed as well as any protocol layer above IP is terminated) while if the code never invoked "network active" before the PSM then we catch "ENTER PSM" URC.

At this stage our investigation around PSM is pretty satisfactory of the results achieved.
We'll keep you updated about any further progress.
Thanks!!

@felmue
I tried to implement a loop that scans the UART until there is some content and in this case decode it and print it out. See screenshot.

Well, I put it soon after the wake up pulse sequence to catch the URC EXIT PSM. Nothing: label0 stamps "Empty UART" all the time and instead the "PSM_State" label never assumes "EXIT PSM" string.
I'm going to give up

@felmue
we found a sequence which is almost working. See picture.

The right toggle is indeed from HiGH to LOW and should last not less than 1s nor longer than 12s ( the latter will force a reset). We used 5s.
According to the SIMCOM 7080G Hardware integration Guide the UART should be active after 1.8s from the first HIGH pulse.
Then the code checks iteratively the module status, which becomes True after 3 more seconds (according to the timer put in between and printed out).
At this stage we are pretty confident the UART is up & running and activate the connection and check IP address. Both UART reading are successful (connection setup and IP address returned).
NOTE: we saw that the very first AT command after wake up is caught with those timings above.

FAILURES:

1. there is not way to catch the unsolicited "EXIT PSM" message from the UART. We are able to catch +CPSMSTATUS: ENTER PSM (URC was enabled in advance with AT+CPSMSTATUS=1) at any try but never ever to get EXIT PSM (UART remains empty)
2. In addition, although the module gained again IP connectivity any attempt to move MQTT or HTTP traffic fails (the MQTT client of the new IoT Base CAT-M palette crashes, while perfectly work with no PSM at all)

Hello @felmue
we confirm that that STATUS led is

• ON when module is active
• OFF when module is either off or during PSM sleeping time

Looking at that led when PIN 12 is toggled to get the module to wake up we noticed

• HIGH then LOW: the led switches from off to on firmly
• LOW then HIGH: the led switches on but then goes off or blinks very slowly

Could you confirm us which of the two sequences is the right order?
Simcom says that the PWRKEY should be pulled low then up again, but we understood there is an inverter in between PWRKEY and GPIO12, so the logic to apply is flipped. Thus we guess the "HIGH then LOW" was good and indeed the led stays on.
If you do the opposite pulses the module would reset and we supposed that the LED bliking means that.
However the last "check module status" instruction return always False, as if the module stays down even if the led light is on. In addtion wherever we put the CPSMS=0 (before or after the two pulses) it seems that the content in the UART is ignored

We're now halted :-(

@felmue
I confirm that iot_base_catm module contains a red led as you said: thanks!
Indeed this is reported in the schematic and the led is connected to the STATUS pin.
BUT it is not visible at all from outside and to see it you need to remove the Guide rail mount base plate and "spy" through the hole close to the antenna's connector: that's not confortable. See photo.
We'll let you know if it behaves with PSM toggle, as you suggested.

@felmue
Thanks, this is teiafra, teammate of Rob.Dor. Please note that we're using this module https://docs.m5stack.com/en/base/iot_base_catm?ref=langship which does not show any kind of LED or light to our eyes

@lukasmaximus I found this interesting article using micropython to implement a local SSID casted by M5Stack acting as AP in conjuction with the embedded web server.

I wonder if it is possible to make the same using Blocky instead, possibly also using Remote+ functions to design the WebGUI. The scenario to be targeted is like having a tablet connected to the local AP and interacting with the local webserver via GUI, everything running on the Core Basic.

I used Remote+ but it leverages on a remote server reached on the UIFLow cloud, while I'd like to make the same running locally.

Hi,
using a M5S Core1 with COM.LTE for mobile data connectivity which an MQTT client, implemented with UIFlow, uses pretty well to send data. Now I need to get a timestamp to be put into MQTT flow.
I thought to use NTP blocks library but apparently it does not work when underlying connection is mobile while it works only with WiFi.
Any tip to overcome such a limitation?

Thanks, indeed the root cause was an old version of M5Burner, which I did not realized there was a newer one. Once updated, then the configuration panel showed also the APN settings and the UIFlow firmware booted successfully with the LTE connectivity

@gaviota I confirm that I found the problem you described also on the on-line version 1.7.0 of UIFlow. Thanks to your trick (click on each block again in Black-Maker will fix the proper rendering once imported into UIFlow) I was able to rescue.

@m5stack:

On the Core display I am a able to select COM.LTE as additional connectivity as shown here.
BUT the next picture (I guess taken from M5Burner configuration, right?) is different in my case because it shows only WiFi, while the APN section is missing .
The final result is that if I select on the Core display COM.LTE and reboot it fails to connect. .
Please note that the modem is working fine, since I'm able to drive it with my UIFlow code (via AT commands) moving data back and forth perfectly.
My ultimate need is to use the UIFlow MQTT client not through the WiFi but natively through the mobile connection.
THANKS!

I'd like to show that the UIFLow 1.7.0 or 1.7.1 configuration mask does not present any panel related to  to be compared with the similar one posted on Twitter

@m5stack thanks but then I'm not able to follow the procedure shown here on Twitter (showing from M5Burner, right?) aimed to pass the APN to the module. Currently I'm on UIFlow 1.7.0.
I posted a topic also here Can you help me?

@m5stack said in UIFlow 1.7.1:

COM.LTE

Is the COM.LTE connectivity supported only in Core2 and not Core (Basic)?
If so, when extended also to Core?

Re: UIFlow 1.7.1
Hi, I need to configure M5Stack-Core to use COM.LTE connectivity as shown here
Currently my Core mounts UIFlow 1.7.0 where that option is available in the device setup menu, but once selected did not work

1. Does it work also with Core or just on Core-2 ? Can I hope also to get it work on Core?
2. The M5Burner configuration of 1.7.0 does not offer that same extended option with COM.X as shown in the link above; Shall I upgrade to 1.7.1?
3. Where can I find the entire step-by-step setup procedure (shall I act on M5Burner as well as on device setup?)

Thanks!

@ciniml could you please explain the new Cellular UIfow blocks and give an example on how to use them in sequential order?

I also saw the Soracom m5f example and I wonder if the flow can start as it did, checking the SIMstate without setting any UART communication in advance?

If I start running just the first two instructions, shall I expect returned True as you?

I'm chasing who can help me in using the COMx.LTE module with those UIflow methods

Thanks

@teiafra said in SORACOM 3G Module support in UI Flow:

@ozbk Thanks a lot for sharing the example.
Could you please provide explanation or point me where each cellular block of UIFlow are described to understand their usage and succeed to manage the COM.LTE module since from its first installation onto M5S-Core?

In what order those blocks are supposed to be called in a more general flow? E.g do I have to start with cellular.init (you did not use it and instead call for restart after SIM is checked)

I complain that that entire palette of blocks is not documented at all :-(

I continue to dig and compared your Soracom flow with the example on SI800 available here.
If I may guess many blocks of module.CELLULAR library, the biggest doubt is about modem initialization and communciation ports setting.

The SIM800 flow clearly set the UART rx/tx channels in the init function while I do not understand in your Soracom example if the cellular.init or cellular.restart block of the library avoid to do this UART setting. Do the Core and the Module communicate each other automatically?

Similarly, Arduino code to drive COMx.LTE also sets up the tx/rx as reflected by the dip switches: does the Cellular UIflow blocks avoid the user to care of it, instead? That would be wonderful!

What difference is between "send" and "sendline" function block?

Any help is really appreciated!!

@ozbk Thanks a lot for sharing the example.
Could you please provide explanation or point me where each cellular block of UIFlow are described to understand their usage and succeed to manage the COM.LTE module since from its first installation onto M5S-Core?

In what order those blocks are supposed to be called in a more general flow? E.g do I have to start with cellular.init (you did not use it and instead call for restart after SIM is checked)

I complain that that entire palette of blocks is not documented at all :-(

More specifically I need to know if the Arduino code downloadable here can be alternatively implemented by means of the UIFlow blocks belonging to the Cellular palette and, if so, I'd be interested to know how.
Thanks

If you change size to the rectangle shape, you do not see any effect on the UI preview.
The dimensions actually change whan you run the UIFlow code, but the "what you see, what you get" of UIFlow is totally faulty