BC660K-GL long reception time for UDP messages

Hello,

I am experiencing very long time periods between sending a UDP message from a server to a BC660K-GL module. I have measured multiple occasions where it took ~20 seconds from sending to receiving. If multiple messages are sent right after another, the reception time can be faster sometimes (~3 seconds), but not always; sometimes it takes ~20 seconds for messages sent right after another.
Test messages are only one byte long, and power saving is completely disabled on the module.

Is there any way to increase the reception time?

Quectel_EPAT操作指导与参考(CN&EN)_BC260Y&BC660K&BC28F&BC95GF&BC300Y.pdf (2.1 MB)
EPAT_V1.2.86.122.zip
You need to provide debug log for analysis

Hello @herbert.pan-Q,
thank you for the manual. I conducted the test with logging today.
Regarding your manual: You did not provide the comdb.txt file for BC660K, so the output showed a lot of hex data. Also the button Log->Log control did not exist for me.
grafik
Otherwise it worked fine.
I measured the time from sending a udp message until receiving the +QIURC message on the main UART. It took 16 seconds.

I cannot upload the file in the forum here because i am a new user. I uploaded the file to wetransfer instead: WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free
I hope this is fine for you.

Best regards

hi,comdb file is in the firmware package, I have sent you a new firmware, please check, or you can provide your current firmware version

ATI

Unfortunately i cannot access the sharepoint link you provided. (Page not found error)

comdb.zip (261.4 KB)

Hello,
i re-run the test today.
I updated the comdb file, however there was no green indicator, as in your manual:


This picture is after i updated the file.

I did the test again. This time the message was received 3 seconds after sending, which is fine.

But i could observe another problem, which happens very often. The device takes a very long time (2 minutes and 50 seconds) to connect to the network. Could you take a look whats wrong in the logs?

https://we.tl/t-N57zeMBwuK

Thank you, BR

By Log analysis, the module can enter the eDRX state, but cannot enter the PSM state. You are advised to execute the following Command

power on
AT+CEDRXS=0,5
AT+CPSMS=1,“01011111”,“00000001”
AT+QSCLK=1
AT+QNBIOTEVENT=1,1
AT+QCFG=“dsevent”,1

Since our product moves a lot (multiple cells), and NBIoT does not support cell handover, we are not using any powersaving at all. We completely disable the NBIoT module and restart it once we need to communicate. It will only be active for a very short time to send a single message, then be disabled for multiple hours/days.

Does eDRX enable cause long connection time? This seems unlikely. Does it cause long message reception time? If so, how can it be completely disabled?

Can your terminal send a packet to the UDP server after registering with the network, and then the server responds to the downlink packet?

Yes, that is the case. Communication is always initaited by the mobile device, never by the server.

I guess maybe because the UDP ports the terminal connects to are random, the server needs to try a different port

I dont think so, server always responds to the port the terminal sent its query on.

However, do you have an idea why it takes ~3 minutes to connect to the NBIoT network? This is also in the log files i last sent you

When does the UDP server send data?

In this test the terminal did not start the communication process. I simply send a UDP messge from server to terminal.

I disabled eDRX now, and i guess this fixes the problem.

Do you have an idea why it takes ~3 minutes to connect to the NBIoT network?

Local radio station support for multiple frequency bands, the module search took a long time, but finally choose BAND8, you can directly lock in BAND8



Why does it do PLMN search on Band 8 and 14, when band 8 and 20 were selected before?

This is determined by the PLMN

So can i assume the bands are set correclty?

you can run:

power on
AT+CFUN=0
AT+QBAND=2,20,8
AT+CFUN=1
AT+CEREG?
AT+CEREG?