Hi,
We have found several situations where URC “+IP…” is received when not expected and this causes a lot of trouble while connecting and sending data.
Currently we are checking connectivity via “AT+CEREG?” and “AT+CGPADDR” and still the URC pops unexpectedly and causes trouble.
Is there any way to disable such URC?
Regards, Ramon.
No, these URC messages mainly automatically output the registration network status. It is suggested that you can add a certain delay after querying AT+CEREG and wait for URC to return
OK, thanks the answer.
We have detected another more tricky scenario when +IP pops up unexpectedly. It is just right after the “SEND OK” response. This sent message never reaches the endpoint, so the DL message never reaches device. See log below.
See full log here where this happens 2 times in a row:
[11/8 11:47:55.5]F1: 0000 0000
[11/8 11:47:55.5]V0: 0000 0000 [0001]
[11/8 11:47:55.5]00: 0000 0000
[11/8 11:47:55.5]U0: 0000 0001 [0000]
[11/8 11:47:55.5]T0: 0000 001E
[11/8 11:47:55.5]Leaving the BROM
[11/8 11:47:55.5]
[11/8 11:47:55.7]
[11/8 11:47:55.7]+CPIN: READY
[11/8 11:47:56.7]AT
[11/8 11:47:56.7]OK
[11/8 11:47:56.7]AT+QNBIOTEVENT=0,1
[11/8 11:47:56.7]OK
[11/8 11:47:56.7]AT+QISTATE?
[11/8 11:47:56.7]+QISTATE: 0,"UDP","52.178.xxx.yyy",xxxx,,1000,2,1,1
[11/8 11:47:56.7]
[11/8 11:47:56.7]OK
[11/8 11:47:56.7]AT+CEREG=2
[11/8 11:47:56.7]OK
[11/8 11:47:56.7]AT+CEREG?
[11/8 11:47:56.7]+CEREG: 2,5,"0502","0602543D",9
[11/8 11:47:56.7]
[11/8 11:47:56.7]OK
[11/8 11:47:56.7]AT+CEREG=0
[11/8 11:47:56.7]OK
[11/8 11:47:56.7]AT+CSQ
[11/8 11:47:56.7]+CSQ: 22,0
[11/8 11:47:56.7]
[11/8 11:47:56.7]OK
[11/8 11:47:56.8]AT+QISENDEX=0,221,12086799703118150521400105020602543D22C1FF058A06C40FE004010085DD9DC7FF63690B8AE004010085DD9DC7FF636A20BFE004010085DD9DC7FF636A20C8E004010085DD9DC7FF636A2779E004010085DD9DC7FF636A2780E004010085DD9DC7FF636A2787E004010085DD9DC7FF636A278EE004010085DD9DC7FF636A2795E004010085DD9DC7FF636A279BE004010085DD9DC7FF636A27A3E004010085DD9DC7FF636A27AAE004010085DD9DC7FF636A27B1E004010085DD9DC7FF636A27B8E004010085DD9DC7FF636A27BFE004010085DD9DC7FF636A27D1
[11/8 11:47:56.8]OK
[11/8 11:47:56.8]
[11/8 11:47:56.8]SEND OK
[11/8 11:48:03.1]
[11/8 11:48:03.1]+IP: 10.14.86.102
[11/8 11:48:29.1]+QNBIOTEVENT: "ENTER DEEPSLEEP"
[11/8 11:48:33.2]
[11/8 11:48:33.2]F1: 0000 0000
[11/8 11:48:33.2]V0: 0000 0000 [0001]
[11/8 11:48:33.2]00: 0000 0000
[11/8 11:48:33.2]U0: 0000 0001 [0000]
[11/8 11:48:33.2]T0: 0000 001E
[11/8 11:48:33.2]Leaving the BROM
[11/8 11:48:33.2]
[11/8 11:48:33.4]
[11/8 11:48:33.4]+CPIN: READY
[11/8 11:48:34.3]AT
[11/8 11:48:34.3]OK
[11/8 11:48:34.3]AT+QNBIOTEVENT=0,1
[11/8 11:48:34.3]OK
[11/8 11:48:34.3]AT+QISTATE?
[11/8 11:48:34.3]+QISTATE: 0,"UDP","52.178.xxx.yyy",xxxx,1000,2,1,1
[11/8 11:48:34.3]
[11/8 11:48:34.3]OK
[11/8 11:48:34.4]AT+CEREG=2
[11/8 11:48:34.4]OK
[11/8 11:48:34.4]AT+CEREG?
[11/8 11:48:34.4]+CEREG: 2,5,"0502","0602543D",9
[11/8 11:48:34.4]
[11/8 11:48:34.4]OK
[11/8 11:48:34.4]AT+CEREG=0
[11/8 11:48:34.4]OK
[11/8 11:48:34.4]AT+CSQ
[11/8 11:48:34.4]+CSQ: 22,0
[11/8 11:48:34.4]
[11/8 11:48:34.4]OK
[11/8 11:48:34.5]AT+QISENDEX=0,221,12086799703118150521400105020602543D22C1FF058A06C40FE004010085DD9DC7FF63690B8AE004010085DD9DC7FF636A20BFE004010085DD9DC7FF636A20C8E004010085DD9DC7FF636A2779E004010085DD9DC7FF636A2780E004010085DD9DC7FF636A2787E004010085DD9DC7FF636A278EE004010085DD9DC7FF636A2795E004010085DD9DC7FF636A279BE004010085DD9DC7FF636A27A3E004010085DD9DC7FF636A27AAE004010085DD9DC7FF636A27B1E004010085DD9DC7FF636A27B8E004010085DD9DC7FF636A27BFE004010085DD9DC7FF636A27D1
[11/8 11:48:34.5]OK
[11/8 11:48:34.5]
[11/8 11:48:34.6]SEND OK
[11/8 11:48:43.3]
[11/8 11:48:43.3]+IP: 10.14.89.75
[11/8 11:49:07.7]+QNBIOTEVENT: "ENTER DEEPSLEEP"
Any idea why does this happen?
Regards, Ramon.
Not sure what you suggest will success. See how +IP arrives before while polling with AT+CEREG.
I think this can be solved by polling with “AT+CGPADDR=1” after “AT+CEREG”
What do you think?
Regards, Ramon.
There is no problem in the log display you provided, and the URC message of output IP is normal; When the network registration is completed, the module automatically outputs the IP provided by the network. If you check the state of the network the moment by AT+CEREG? you only can get is the network status URC
Ok. But it is problematic for us beause if I get “SEND OK” I think eveything went ok with the sending (actually failed) and start waitintg for the URC [+QIURC: “recv”]. I am not expecting “+IP” at this stage.
Is there any recommendation related to the URC for the driver implementation?
Regards, Ramon.
SEND OK indicates that the command is executed successfully but the data is sent successfully. Note Data can be successfully transmitted only after the module obtains the IP address
Hi,
I understand you need IP for sending successfully. But not sure I understood your first sentences about SEND OK.
Note the message never reaches the endpoint despite of receiving the SEND OK from BC66.
Regards, Ramon.
