EG21 Responding with "702" error even though data is sent successfully

IoT Modules LTE-A Module
1

I am sending data to a server via an EG21 using AT+QHTTPPOST. Everything is successful - activating PDP, opening socket, setting URL destination etc, but when I attempt to send data with the command “AT+QHTTPPOST=631,15,15” and follow with a data block of the correct size, the EG21 responds with “+QHTTPPOST: 702”. I retry again until a successful response of “+QHTTPPOST: 0,200”.

What this results in is:
EG21
Data Packet 1
+QHTTPPOST: 702
+QHTTPPOST: 702
+QHTTPPOST: 0,200
Data Packet 2
+QHTTPPOST: 702
+QHTTPPOST: 702
+QHTTPPOST: 0,200

Server
Data Packet 1
Received x 3
Data Packet 2
Received x 3

Without fail there will be 2 timeouts and 1 successful.

I’ve tried re-activating the PDP context each time, resetting the GSM module each time, adding in a delay between each HTTPPOST, all with no success.

Is there anything I can do to fix this other than ignoring a 702 error and hoping for the best?

2

Please add the DNS configuration before QHTTPURL

AT+QIDNSCFG=1,“8.8.8.8”,“8.8.4.4”

3

Hi, thanks for the reply.

I have already included that command in the setup. Apart from reading the SIM and IMEI etc, this is the list of commands in order used.

AT+CREG?
AT+CGDCONT=1,<PDP_type>,<APN>
AT+QICSGP=1,1,<APN>,<USERNAME>,<PASSWORD>,1
AT+QIACT=1
AT+QIDNSCFG=1,"8.8.8.8","8.8.4.4"
AT+QIDNSGIP=1,<URL>
AT+QHTTPCFG="contextid",1
AT+QHTTPCFG="requestheader",0
AT+QHTTPURL=<URL_LENGTH>
<URL>
AT+QICLOSE=0
AT+QIOPEN=1,0,"TCP",<URL>,80,0,0
AT+QISTATE=1,0
AT+QHTTPPOST=<DATA_LENGTH>,15,15
<DATA>

4

Could you provide the execution result log of the above-mentioned AT commands?

5

Here is a snippet of the log printed out from my embedded device (“<” denotes sent to GSM module). The time between sending the data packet and the 702 error is the same time as sending the data packet and a 0,200 reply.

< AT+QICLOSE=0
AT+QICLOSE=0
OK

< AT+QIACT?
AT+QIACT?
+QIACT: 1,1,1,“[IP ADDR]”
OK

< AT+QIDNSCFG=1,“8.8.8.8”,“8.8.4.4”
AT+QIDNSCFG=1,“8.8.8.8”,“8.8.4.4”
OK

< AT+QIDNSGIP=1,“[URL]”
AT+QIDNSGIP=1,“[URL]”
OK

< AT+QHTTPCFG=“contextid”,1
AT+QHTTPCFG=“contextid”,1
OK

< AT+QHTTPCFG=“requestheader”,0
AT+QHTTPCFG=“requestheader”,0
OK

< AT+QHTTPURL=58
AT+QHTTPURL=58
CONNECT
< [URL]
OK

< AT+QICLOSE=0
AT+QICLOSE=0
OK

< AT+QICLOSE=0
AT+QICLOSE=0
OK

< AT+QHTTPPOST=638,15,15
AT+QHTTPPOST=638,15,15
CONNECT
< [DATA PACKET 273]
OK
+QHTTPPOST: 702

< AT+QHTTPPOST=638,15,15
AT+QHTTPPOST=638,15,15
CONNECT
< [DATA PACKET 273]
OK
+QHTTPPOST: 702

< AT+QHTTPPOST=638,15,15
AT+QHTTPPOST=638,15,15
CONNECT
< [DATA PACKET 273]
OK
+QHTTPPOST: 0,200

< AT+QHTTPPOST=638,15,15
AT+QHTTPPOST=638,15,15
CONNECT
< [DATA PACKET 274]
OK
+QHTTPPOST: 702

< AT+QHTTPPOST=638,15,15
AT+QHTTPPOST=638,15,15
CONNECT
< [DATA PACKET 274]
OK
+QHTTPPOST: 702

< AT+QHTTPPOST=638,15,15
AT+QHTTPPOST=638,15,15
CONNECT
< [DATA PACKET 274]
OK
+QHTTPPOST: 0,200

6

Based on the log you provided, this error702 is probabilistic. I think it might be caused by an anomaly in the data packets responded by the server to the UE. First of all, I suggest that you can add QPING[URL] before the POST request to check the latency of the server

7

Why would using Google’s DNS solve his issue?
I have similar problem on the EC200UEU. Works most of the time but sporadically return 702.

1 Like
8

The default DNS of the modem is provided by EPC, which may be unable to resolve special urls, especially when the server is deployed in the cloud

9

I got my issue fixed after updating the firmware to the latest. It seems the module is dropping packets when data is larger in size.