ML302 4G Cat1 module TCP/UDP implementation process

Note: the following type of □ means “\r\n”

First, AT

[00:57:34. 794] to derive the AT – [00:57:35. 756] to derive the AT/pieces [00:57:35. 760] please receive the AT

OK

Second, query card CIMI and ICCID

[00:57:57. 834] to derive the AT + CIMI – [00:57:57. 838] pieces please AT + CIMI

460081237003326

OK

[11:59:17. 096] to derive the AT + ICCID in pieces – [11:59:17. 101] please receive AT + ICCID

+ICCID: 89860492192070603326

OK

Third, query the signal value

[00:58:15.770] Send →◇AT+CSQ □ [00:58:15.774] Receive ←◆AT+CSQ

13 + CSQ: 20

OK

Four, query whether attached network (GPRS?)

[00:58:29. 236] to derive the AT + CGATT? / [00:58:29. 242] accept pieces please AT + CGATT?

+CGATT:1

OK

Activate PDP context (first ‘1’ indicates active, last ‘1’ indicates CID =1)

[01:00:15. 810] to derive the AT + CGACT = 1, 1 – [01:00:15. 814] pieces please AT + CGACT = 1, 1

[01:00:16.115] b: ←◆ +CGACT: 1,1

OK

Establish TCP/UDP connection (the second to last parameter ‘1’ corresponds to the last ‘1’ of CGACT, i.e. cid)

TCP:

[01:01:21. 248] to derive the AT + MIPOPEN = 1, “TCP”, “47.92.146.210,0,0,1,11002-8888100 [01:01:21. 257] pieces please AT + MIPOPEN = 1, “TCP”, “47.92.146.210”, 8888100,0,0,1,11002

OK if the TCP connection fails or times out, the following message is returned: +MIPURC: “STATE”,1,2

1,CONNECT FAIL

1, CLOSED AT + MIPOPEN = 1, “TCP”, “48.92.146.210”, 8888100,0,0,1,11002

OK If the TCP connection is successful, the following message is returned: [01:01:21.421] Accept ←◆ 1,CONNECT OK

UDP:

[01:08:14. 976] to derive the AT + MIPOPEN = 1, “UDP”, “47.92.146.210”,,0,0,1,11002-9999100 [01:08:14. 984] pieces please AT + MIPOPEN = 1, “UDP”, “47.92.146.210”, 9999100,0,0,1,11002

OK

1,CONNECT OK

Seven, send data and receive data

[01:04:05. 291] to derive the AT + MIPSEND = 1, 10 – [01:04:05. 297] pieces please AT + MIPSEND = 1, 10

[01:04:07.687] Send →◇1234567890 □ [01:04:07.691] Receive ←◆1234567890

[01:04:07.877] Accept ←◆ 1,SEND OK

[01:04:07.968] collect ←◆ +MIPURC: recv,1,10 1234567890

Sometimes the received data may be as follows: [00:54:51.322] receive ←◆ +MIPURC: “recv”,1,10 12345678 [00:54:51.346] receive ←◆90

Eight, attention!!

In some cases, when we receive TCP/UDP data, we send the command to obtain GPS data, which will result in the failure to receive the data from the server, for example: [02:01:10. 290] to derive the AT + MIPSEND = 1, 10 – [02:01:10. 296] pieces please AT + MIPSEND = 1, 10

[02:01:10.811] Send →◇AT+MGNSSLOC □ [02:01:10.821] Receive ←◆AT+MGNSSLOC

[02:01:10.946] Send →◇1234567890 □ [02:01:10.950] Receive ←◆1234567890

1,SEND OK

[02:01:11. 034] please receive + MIPURC: “recv”, 1, 10 + MGNSSLO AT / / — — — — — — — — — — — — — — — — — — — – the key here, “1234567890” is replaced with “AT + MGNSSLO” of the same length

——- may have overwritten “1234567890” by sending “AT+MGNSSLOC” too early

[02:01:11.811] Send →◇AT+MGNSSLOC □ [02:01:11.821] Receive ←◆AT+MGNSSLOC

+ MGNSSLOC: 180111.00, 2242.8158 N, 11431.8045 E, 1.70, 96.8, 3,2.582, 1.394, 190421, 11

OK

9. TCP connection status (the first ‘1’ indicates the existing connect_id)

When a module suddenly returns +MIPURC: “STATE”,1,1, server closed the connection when a module suddenly returns +MIPURC: “STATE”,1,2, server closed the connection