Atom DTU NB-IoT2 issues.
-
@felmue Hi, thanks for the indications, I'll check and let you know.
Do you know how it is possible to reset or reboot the SIM7028 from the S3 Lite atom?
If the Atom DTU modem is stuck and isn't possible to switch power off and on (typical scenario of every IoT device that is placed in remote zones or that cannot be accessed) in which way Atom DTU can be back to an operating condition?
I ask these questions because I don't understand why the modem control pin was not connected to an Atom I/O.
Thank you.
-
Hello @cocoa
no, it is not possible to reset/reboot SIM7028 from M5AtomS3 due to the fact that RESET pin is not connected.
There is an AT command to reset SIM7028, but if it is stuck that probably doesn't work. The other way is pulling RESET pin low, but that doesn't help as long as RESET pin isn't connected.
If you don't need the built-in RS485 or the built-in Groove port you could rewire one of those GPIOs via transistor to the RESET pin. (But make sure you use the appropriate circuit / level shifter.)
From SIM7028 Hardware Design document:
"3.2.1 Power on
The module is automatically turned on after power on, without a power button. Under the condition that the RESET pin is not pulled low by the outside, the module will automatically power on after supplying a voltage of 2.2V to 4.3V to the VBAT pin.""3.2.2 Power off
The module can be shut down by disconnecting the VBAT power supply.""3.2.3 Reset Function
SIM7028 can reset the module by keeping the RESET pin low for at least 50ms. The module can also be reset by the AT command "AT+NRB".
The RESET signal has been pulled up inside the chip, and the RESET signal will immediately change to a high level after the module is powered on."Edit: I just tried the AT command to reset the module, but all I get back is
ERROR
and nothing happens.Thanks
Felix -
Hello @felmue ,
Thank you for informations and suggestions.
For me it is clear that the module must be used as a product and sold, so I hope that the AT reset command will solve any stuck of the modem.
M5stack has not yet released the examples in UIFLOW2 for this module, so the module is useless for those who want to use UIFlow2. The ones for Atom DTU UIFlow1 obviously don't work.
I just can't use it with Arduino / Platformio too.
Could you share your source code to make a http connection? It would be of great help to me to get out of this impasse.
Thx.
-
Hello @cocoa
the
http
example from here is working for me with the one modification in TinyGSM I mentioned.You haven't shared the log with
#define DUMP_AT_COMMANDS
enabled - this might shed some light onto what going on at your end.I guess you haven't noticed my edited note above about the AT reset command
AT+NRB
which did not work for me. All I got was anERROR
.Here you can find my modification to reset SIM7028 via GPIO.
BTW: have you ever tried to check the firmware version currently installed on your SIM7028? E.g.
AT+CGMR
? Maybe it needs an upgrade?Thanks
Felix -
Hi @felmue, sorry for delay.
Here is the log with
#define DUMP_AT_COMMANDS
enabled .Connected! 14:23:54.308 > >>ATOM DTU NB MQTT TEST 14:23:54.308 > AT+CICCID 14:23:54.308 > 14:23:54.308 > ERROR 14:23:54.308 > CCID: ERROR 14:23:54.308 > AT+CSQ 14:23:54.314 > 14:23:54.314 > +CSQ: 21,0 14:23:54.314 > 14:23:54.315 > OK 14:23:54.315 > Signal quality: 21 14:23:54.315 > Initializing modem... 14:23:54.315 > [ 1689][E][esp32-hal-gpio.c:102] __pinMode(): Invalid pin selected 14:23:54.321 > E (1581) gpio: gpio_set_level(227): GPIO output gpio_num error 14:23:54.621 > E (1881) gpio: gpio_set_level(227): GPIO output gpio_num error 14:23:59.621 > AT 14:23:59.624 > 14:23:59.624 > OK 14:23:59.624 > ATE0 14:23:59.628 > 14:23:59.629 > OK 14:23:59.629 > AT+CFUN=1 14:23:59.636 > 14:23:59.636 > OK 14:23:59.636 > AT+QCLEDMODE=1 14:23:59.641 > 14:23:59.641 > OK 14:23:59.641 > AT+CMEE=0 14:23:59.645 > 14:23:59.645 > OK 14:23:59.645 > AT+CTZR=0 14:23:59.649 > 14:23:59.649 > OK 14:23:59.649 > AT+CTZU=1 14:23:59.653 > 14:23:59.653 > OK 14:23:59.653 > AT+CPIN? 14:23:59.660 > 14:23:59.660 > +CPIN: READY 14:23:59.661 > 14:23:59.661 > OK 14:23:59.661 > Waiting for network... 14:23:59.661 > AT+CREG? 14:23:59.667 > 14:23:59.667 > +CREG: 0,0 14:23:59.668 > 14:23:59.668 > OK 14:23:59.918 > AT+CREG? 14:23:59.924 > 14:23:59.925 > +CREG: 0,0 14:23:59.925 > 14:23:59.925 > OK 14:24:00.175 > AT+CREG? 14:24:00.181 > 14:24:00.181 > +CREG: 0,0 14:24:00.182 > 14:24:00.182 > OK 14:24:00.432 > AT+CREG? 14:24:00.438 > 14:24:00.439 > +CREG: 0,0 14:24:00.439 > 14:24:00.439 > OK 14:24:00.689 > AT+CREG? 14:24:00.694 > 14:24:00.695 > +CREG: 0,0 14:24:00.695 > 14:24:00.695 > OK 14:24:00.946 > AT+CREG? 14:24:00.952 > 14:24:00.952 > +CREG: 0,0 14:24:00.952 > 14:24:00.952 > OK 14:24:01.203 > AT+CREG? 14:24:01.209 > 14:24:01.209 > +CREG: 0,0 14:24:01.209 > 14:24:01.210 > OK 14:24:01.460 > AT+CREG? 14:24:01.466 > 14:24:01.466 > +CREG: 0,0 14:24:01.467 > 14:24:01.467 > OK 14:24:01.717 > AT+CREG? 14:24:01.723 > 14:24:01.724 > +CREG: 0,0 14:24:01.724 > 14:24:01.724 > OK 14:24:01.974 > AT+CREG? 14:24:01.980 > 14:24:01.980 > +CREG: 0,0 14:24:01.981 > 14:24:01.981 > OK 14:24:02.231 > AT+CREG? 14:24:02.237 > 14:24:02.238 > +CREG: 0,0 14:24:02.238 > 14:24:02.238 > OK 14:24:02.488 > AT+CREG? 14:24:02.494 > 14:24:02.494 > +CREG: 0,0 14:24:02.494 > 14:24:02.495 > OK 14:24:02.745 > AT+CREG? 14:24:02.751 > 14:24:02.751 > +CREG: 0,0 14:24:02.751 > 14:24:02.751 > OK 14:24:03.002 > AT+CREG? 14:24:03.008 > 14:24:03.008 > +CREG: 0,0 14:24:03.009 > 14:24:03.009 > OK 14:24:03.259 > AT+CREG? 14:24:03.264 > 14:24:03.265 > +CREG: 0,0 14:24:03.265 > 14:24:03.265 > OK 14:24:03.516 > AT+CREG? 14:24:03.521 > 14:24:03.521 > +CREG: 0,0 14:24:03.522 > 14:24:03.522 > OK 14:24:03.773 > AT+CREG? 14:24:03.779 > 14:24:03.779 > +CREG: 0,0 14:24:03.779 > 14:24:03.779 > OK 14:24:04.030 > AT+CREG? 14:24:04.036 > 14:24:04.036 > +CREG: 0,0 14:24:04.036 > 14:24:04.036 > OK 14:24:04.287 > AT+CREG? 14:24:04.293 > 14:24:04.293 > +CREG: 0,0 14:24:04.293 > 14:24:04.293 > OK 14:24:04.544 > AT+CREG? 14:24:04.549 > 14:24:04.549 > +CREG: 0,0 14:24:04.550 > 14:24:04.550 > OK 14:24:04.801 > AT+CREG? 14:24:04.806 > 14:24:04.806 > +CREG: 0,0 14:24:04.807 > 14:24:04.807 > OK 14:24:05.058 > AT+CREG? 14:24:05.064 > 14:24:05.064 > +CREG: 0,0 14:24:05.064 > 14:24:05.065 > OK 14:24:05.315 > AT+CREG? 14:24:05.321 > 14:24:05.322 > +CREG: 0,0 14:24:05.322 > 14:24:05.322 > OK 14:24:05.572 > AT+CREG? 14:24:05.578 > 14:24:05.578 > +CREG: 0,0 14:24:05.580 > 14:24:05.580 > OK 14:24:05.829 > AT+CREG? 14:24:05.835 > 14:24:05.835 > +CREG: 0,0 14:24:05.835 > 14:24:05.836 > OK 14:24:06.086 > AT+CREG? 14:24:06.091 > 14:24:06.092 > +CREG: 0,0 14:24:06.092 > 14:24:06.092 > OK 14:24:06.343 > AT+CREG? 14:24:06.349 > 14:24:06.349 > +CREG: 0,0 14:24:06.349 > 14:24:06.350 > OK 14:24:06.600 > AT+CREG? 14:24:06.606 > 14:24:06.606 > +CREG: 0,0 14:24:06.607 > 14:24:06.607 > OK 14:24:06.857 > AT+CREG? 14:24:06.863 > 14:24:06.863 > +CREG: 0,0 14:24:06.864 > 14:24:06.864 > OK 14:24:07.114 > AT+CREG? 14:24:07.120 > 14:24:07.121 > +CREG: 0,0 14:24:07.121 > 14:24:07.121 > OK 14:24:07.371 > AT+CREG? 14:24:07.377 > 14:24:07.377 > +CREG: 0,0 14:24:07.378 > 14:24:07.378 > OK 14:24:07.628 > AT+CREG? 14:24:07.634 > 14:24:07.634 > +CREG: 0,0 14:24:07.635 > 14:24:07.635 > OK 14:24:07.885 > AT+CREG? 14:24:07.890 > 14:24:07.891 > +CREG: 0,0 14:24:07.891 > 14:24:07.892 > OK 14:24:08.142 > AT+CREG? 14:24:08.147 > 14:24:08.147 > +CREG: 0,0 14:24:08.148 > 14:24:08.148 > OK 14:24:08.399 > AT+CREG? 14:24:08.404 > 14:24:08.404 > +CREG: 0,0
-
Hello @cocoa
from the output
+CREG: 0,0
it looks like your modem is not registered to the network. According to the AT commands documentation, the second0
in that answer means:0 not registered, MT is not currently searching for an operator to register to
You could try to manually issue a 'AT+CEREG?' command to see if that yields any better result. Like I mentioned above, 'AT+CREG' didn't work for me either.
The other AT command to see if the modem is actually connected or not is
AT+COPS?
.If you get something like this:
+COPS: 1,2,"22801",9
it means your modem is connected. If you get:+COPS: 0
it is not connected.Thanks
Felix -
Hello @felmue,
An interesting fact:
-
If I load the sample code you indicated the led of the modem continues to flash quickly without ever stopping , so it is correct to say that the modem is not connected .
-
If I erase the flash with the executable and restart the Atom DTU the modem after a few seconds connects autonomously with the cellular network.
Therefore there is something in the source code of the http example that prevents the modem from connecting.
-
-
Hello @felmue,
I think use
AT+CREG?
maybe it's not correct for NB-IoT connection on LTE technology.Should the modem probably use
AT+CEREG?
.What do you think? Should something be changed in TinyGSM?
Thx.
-
Hello @cocoa
actually I changed my fix to include
sms only roaming
state e.g.7
like this:// return (s == REG_OK_HOME || s == REG_OK_ROAMING || s == REG_OK_SMS); return (s == REG_OK_HOME || s == REG_OK_ROAMING || s == REG_OK_SMS || s == REG_OK_SMS_ROAMING);
The reason for that is that it seems to be a valid state for NB-IoT.
"7 Registered for "SMS only", roaming (applicable only when <Act>
indicates NB-IOT"BTW: I've created a PR to that effect.
Thanks
Felix -
Hello @felmue ,
I changed the header by inserting your change, but behavior uk the same of the previous on.
I edited the file using CEREG instead of CREG.
Something has changed but it is not yet possible to run the http example.
11:51:23.983 > AT+CICCID 11:51:23.983 > 11:51:23.983 > ERROR 11:51:23.983 > CCID: ERROR 11:51:23.983 > AT+CSQ 11:51:23.988 > 11:51:23.989 > +CSQ: 24,0 11:51:23.989 > 11:51:23.989 > OK 11:51:23.989 > Signal quality: 24 11:51:23.990 > Initializing modem... 11:51:23.990 > [ 1689][E][esp32-hal-gpio.c:102] __pinMode(): Invalid pin selected 11:51:23.996 > E (1581) gpio: gpio_set_level(227): GPIO output gpio_num error 11:51:24.297 > E (1882) gpio: gpio_set_level(227): GPIO output gpio_num error 11:51:29.297 > AT 11:51:29.300 > 11:51:29.300 > OK 11:51:29.300 > ATE0 11:51:29.304 > 11:51:29.304 > OK 11:51:29.304 > AT+CFUN=1 11:51:29.311 > 11:51:29.312 > OK 11:51:29.312 > AT+QCLEDMODE=1 11:51:29.316 > 11:51:29.316 > OK 11:51:29.317 > AT+CMEE=0 11:51:29.320 > 11:51:29.321 > OK 11:51:29.321 > AT+CTZR=0 11:51:29.325 > 11:51:29.325 > OK 11:51:29.325 > AT+CTZU=1 11:51:29.329 > 11:51:29.329 > OK 11:51:29.329 > AT+CPIN? 11:51:29.335 > 11:51:29.335 > +CPIN: READY 11:51:29.336 > 11:51:29.337 > OK 11:51:29.337 > Waiting for network... 11:51:29.337 > AT+CEREG? 11:51:29.343 > 11:51:29.343 > +CEREG: 0,5 11:51:29.344 > 11:51:29.344 > OK 11:51:29.344 > success 11:51:29.344 > AT+IPADDR 11:51:29.352 > 11:51:29.352 > +IP ERROR: Network not opened 11:51:29.355 > 11:51:29.355 > ERROR 11:51:29.355 > Device IP address: 11:51:29.355 > success 11:51:29.356 > Performing HTTP GET request... AT+CIPCLOSE=0 11:51:29.363 > 11:51:29.364 > +CIPCLOSE: 0,4 11:51:29.365 > 11:51:29.365 > ERROR 11:51:29.365 > AT+CIPRXGET=1 11:51:29.371 > 11:51:29.371 > OK 11:51:29.371 > AT+CIPOPEN=0,"TCP","api.m5stack.com",80 11:51:29.382 > 11:51:29.382 > +CIPOPEN: 0,2 11:51:29.383 > failed to connect 11:51:39.383 > Performing HTTP GET request... 11:51:39.383 > ERROR 11:51:39.433 > AT+CIPCLOSE=0 11:51:39.440 > 11:51:39.440 > +CIPCLOSE: 0,4 11:51:39.441 > 11:51:39.441 > ERROR 11:51:39.442 > AT+CIPRXGET=1 11:51:39.447 > 11:51:39.448 > OK 11:51:39.448 > AT+CIPOPEN=0,"TCP","api.m5stack.com",80 11:51:39.458 > 11:51:39.458 > +CIPOPEN: 0,2 11:51:39.459 > failed to connect 11:51:49.460 > Performing HTTP GET request... 11:51:49.461 > ERROR 11:51:49.510 > AT+CIPCLOSE=0 11:51:49.517 > 11:51:49.518 > +CIPCLOSE: 0,4 11:51:49.518 > 11:51:49.519 > ERROR 11:51:49.519 > AT+CIPRXGET=1 11:51:49.524 > 11:51:49.524 > OK 11:51:49.525 > AT+CIPOPEN=0,"TCP","api.m5stack.com",80 11:51:49.535 > 11:51:49.535 > +CIPOPEN: 0,2 11:51:49.536 > failed to connect 11:51:59.537 > Performing HTTP GET request...
-
Hello @cocoa
if you want to use NB-IoT mode I found you'll need to un-comment the define in
TinyGsmClientSIM7028.h
line 32 as well.#define MODE_NB_IOT //Comment this macro definition when using CAT mode
BTW: CAT mode (e.g. not NB-IoT mode) works for me too.
Thanks
Felix -
@felmue It works in a totally random way, sometimes it gets the answer to the 'GET' and then it enters an infinite loop:
AT+CIPRXGET=4,0 07:25:49.725 > 07:25:49.727 > +CIPRXGET: 4,0,0 07:25:49.727 > 07:25:49.727 > OK 07:25:49.727 > AT+CIPCLOSE? 07:25:49.734 > 07:25:49.735 > +CIPCLOSE: 0,0 07:25:49.735 > 07:25:49.735 > OK 07:25:50.219 > AT+CIPRXGET=4,0 07:25:50.226 > 07:25:50.226 > +CIPRXGET: 4,0,0 07:25:50.227 > 07:25:50.227 > OK 07:25:50.228 > AT+CIPCLOSE? 07:25:50.234 > 07:25:50.234 > +CIPCLOSE: 0,0 07:25:50.236 > 07:25:50.236 > OK 07:25:50.720 > AT+CIPRXGET=4,0 07:25:50.727 > 07:25:50.728 > +CIPRXGET: 4,0,0 07:25:50.728 > 07:25:50.728 > OK 07:25:50.728 > AT+CIPCLOSE? 07:25:50.736 > 07:25:50.736 > +CIPCLOSE: 0,0 07:25:50.736 > 07:25:50.737 > OK 07:25:51.221 > AT+CIPRXGET=4,0 07:25:51.229 > 07:25:51.230 > +CIPRXGET: 4,0,0 07:25:51.230 > 07:25:51.230 > OK 07:25:51.230 > AT+CIPCLOSE? 07:25:51.237 > 07:25:51.237 > +CIPCLOSE: 0,0 07:25:51.238 > 07:25:51.238 > OK 07:25:51.722 > AT+CIPRXGET=4,0 07:25:51.730 > 07:25:51.731 > +CIPRXGET: 4,0,0
However, the library must be modified to be able to obtain a communication as it does not connect with the original commands.
I think the nb-iot command set in LTE is wrong.It is also my opinion that an nb-iot device without a hardware reset cannot be used seriously.
Thanks for the helping.