BG95-XX - First UDP packet Lost after power-up

IoT Modules LPWA Module
1

Hello

I am preparing a demo for BG95-S5 and I am facing a bug.
First UDP frame after AT+CUN=1 is not being sent.
I have the same behavior with BG95-M3 (01.005 firmware)

This bug can be observed after boot and after each wake-up out of CFUN=4 on both BG95-M3 and BG95-S5

May I ask you to help me

Thank you

STH

GT GSM available 4 : 0
s command : AT+CREG? +CREG: OK
s read 29 24: AT+CREG? +CREG: 0,1 OK
s answer 3: 0,1
s success
s command : AT+CFUN=1 OK null
s read 16 13: AT+CFUN=1 OK
s success
s command : AT+CSQ OK +CSQ:
s read 28 23: AT+CSQ +CSQ: 31,99 OK
s answer 5: 31,99
s success
s command : AT+CREG? OK +CREG:
s read 29 24: AT+CREG? +CREG: 0,1 OK
s answer 3: 0,1
s success
s command : AT+CGATT? OK +CGATT:
s read 29 24: AT+CGATT? +CGATT: 1 OK
s answer 1: 1
s success
s command : AT+CGACT? OK +CGACT:
s read 31 26: AT+CGACT? +CGACT: 1,1 OK
s answer 3: 1,1
s success
GT GSM available 3 : 1
pm_set_sleep_mode(pm_mode_extended_sleep);
pm_set_sleep_mode(pm_mode_idle);
MT CIP send 96 bytes
s command : AT+QIACT=1 OK null
s read 17 14: AT+QIACT=1 OK
s success
s command : AT+QIACT? OK +QIACT
s read 49 44: AT+QIACT? +QIACT: 1,1,1,“XXXXX” OK
s success
s command : AT+QISTATE=0,1 OK null
s read 21 18: AT+QISTATE=0,1 OK
TP Loop
TT Loop
TT Receive : XXXXXXX
TT GNSS asked 2
s read null
s read null
s read null
s success
s command : AT+QIOPEN=1,0,“UDP”,“XXXXXXXX”,XXXXX,XXXXX,0 OK +QIOPEN:
s read 74 69: AT+QIOPEN=1,0,“UDP”,“XXXXXXXX”,XXXXX,XXXXX,0 OK +QIOPEN: 0,0
s answer 3: 0,0
s success
s command : ATE0 OK null
s read 11 8: ATE0 OK
s success
s cipsnd 4: >
s cipsnD 11: SENDOK
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s read null
s command : ATE1 OK null
s read 6 4: OK
s success
s command : AT+QIRD=0,0 OK +QIRD:
s read 34 29: AT+QIRD=0,0 +QIRD: 0,0,0 OK
s answer 5: 0,0,0
s success
s command : AT+QICLOSE=0 OK null
s read 19 16: AT+QICLOSE=0 OK
s success
MT ACK OK
MT HMAC wrong size.
s command : AT+QIDEACT=1 OK null
s read 19 16: AT+QIDEACT=1 OK
s success
MT CIP send 96 bytes
s command : AT+QIACT=1 OK null
s read 17 14: AT+QIACT=1 OK
s success
s command : AT+QIACT? OK +QIACT
s read 49 44: AT+QIACT? +QIACT: 1,1,1,“XXXXX” OK
s success
s command : AT+QISTATE=0,1 OK null
s read 21 18: AT+QISTATE=0,1 OK
s read null
s read null
s read null
s success
s command : AT+QIOPEN=1,0,“UDP”,“XXXXXXXX”,XXXXX,XXXXX,0 OK +QIOPEN:
s read 74 69: AT+QIOPEN=1,0,“UDP”,“XXXXXXXX”,XXXXX,XXXXX,0 OK +QIOPEN: 0,0
s answer 3: 0,0
s success
s command : ATE0 OK null
s read 11 8: ATE0 OK
s success
s cipsnd 4: >
s cipsnD 11: SENDOK
s cipsnD 20: +QIURC:“recv”,0
s command : ATE1 OK null
s read 6 4: OK
s success
s command : AT+QIRD=0,0 OK +QIRD:
s read 36 31: AT+QIRD=0,0 +QIRD: 32,0,32 OK
s answer 7: 32,0,32
s success
s ciprcv 14: AT+QIRD=0,32
s command : AT+CCLK? OK +CCLK:
s read 48 43: AT+CCLK? +CCLK: “24/12/02,16:40:09+04” OK
s answer 22: “24/12/02,16:40:09+04”
s success
s command : AT+CSQ OK +CSQ:
s read 28 23: AT+CSQ +CSQ: 31,99 OK
s answer 5: 31,99
s success
TTb XXXXXXX
TT Sending a : XXXXXXX encoded using 31 bytes.
TT mq_curmsgs : 0
TT GNSS obviated 1
s ciprcv 65: +QIRD: 32,XXXXXXXXOK
s command : AT+QICLOSE=0 OK null
s read 19 16: AT+QICLOSE=0 OK
s success
MT ACK OK
MT HMAC OK
MT GSM obviated 0
s command : AT+QIDEACT=1 OK null
GT GSM sleep
s read 19 16: AT+QIDEACT=1 OK
s success
s command : AT+CFUN=4 OK null
s read 16 13: AT+CFUN=4 OK
s success

2

Could you please tell me your BG95-S5 firmware version?

3

AT+QGMR
BG95S5LAR08A01_A0.203.A0.203

and

AT+QGMR
BG95M3LAR02A03_A0.206.A0.206

Both behave in the same way. First udp packet is lost when device is out of AT+CFUN=4 by using AT+CFUN=1

Software is multi-thread and is coming from another device that used to allow GPS and GNSS use at the same time. I am using GSM priority mode until I manage to have threads share a mutex.

Thank you

4

Maybe when you out of AT+CFUN=4, it may take some time for the device to re-search the network and establish a stable connection.Wait a while for the device to fully synchronize the network signal. If the problem persists, try restarting the device.

5

Hello

If you look at my logs, I have one dedicated thread that perform a complete cycle to check that network is up and running and concludes to GSM availability. That threads hold a condition variable that actually lock all others activities until a signal is sent to others “GT GSM available N : 1”

Then I launch IP stack with QIACT and get actual IP of that particular session to finally check by looking if QISTATE is OK. I have a dozen of intricated loops at the forefront of the actual QIOPEN sequence to check that the modem is ready.

Despite all this, first frame is lost and the device need to repeat the entire sequence until it finally sends its message and get an answer from the server. I could use tcpdump on server side and I am pretty sure it does not receive the first frame. It actually does receive the second one and deliver proper answer.

May I ask you to double check that one ? I plan to use that device on a battery powered device and energy management is critical. Wasting energy that way is not good.

Thank you

6

You can use this tool for cross-validation
https://netlab.luatos.com/

7

I am sorry I do not speak chinese. Does this tool exist in English ?

8

Sorry, I can’t find any other free server in English