I am finding some kind of problems with the module BC66 in UDP Rx mode and using OpenCPU.
I have a high error rate in Rx, around 3-5% [I’ve made more than 10k sents with different devices]. I think is very high this error rate.
I am using a timer in Rx of 8 seconds since I send a UDP package to a server called X. The X server answers as soon as he receives the UDP package. When this timer of 8 seconds expires, I am considering an error in Rx.
Do you think this timer is two low? I think this timer is good enough, due to the fact, in the vast mayority of the cases I received the Rx UDP data in less than one second. But I am not sure.
First of all, remember that I am using OpenCPU and UDP.
These are the steps I follow:
The socket is open without errors.
Then, I send an UDP packet to a server X. In this point, I activate a timer called: UDP_RX_TIMER.
The server always receives the UDP packet correctly and answers straightaway with an UDP packet to the module BC66.
I expect to receive the UDP packet in the module BC66, but after 8 seconds the timer UDP_RX_TIMER expires and calls off the waiting for Rx UDP packets.
NOTE: In order to receive the UDP packets, I am using this function with OpenCPU: Ql_Socket_Recv_Register(CallbackSocketRecv);
So, it seems to be that something is wrong. The Rx error rate is around 3-5%. I think this error rate is too high.
I think that the UDP_RX_TIMER = 8 seconds is good enough, when the Rx UDP packet is received correctly, it only takes around 1-2 seconds to receive the Rx packet from the server, since I send the Tx UDP packet.
Do you have any suggestion where I can investigate what is going wrong?
I am not using ql_socket.h. I am using ril_socket.h.
So these are the functions I am using:
1º. For opening the socket: RIL_SOC_QIOPEN
2º. For closing the socket: RIL_SOC_QICLOSE
3º. For sending data: RIL_SOC_QISEND
4º. For receiven data I have to configure the callback: Ql_Socket_Recv_Register(CallbackSocketRecv);
I use the at-client, but from my experience, there can be significant network latency at times (10s or more). We have a permanently powered installation, so I keep the socket open indefinitely and listen for the data received URC. Don’t have an exact number for you, but rx packet loss is very low.
I’ve just change to use the API socket as you told me, but I have the same problems. Some Tx packets fail without reporting any error and I lost a lot of Rx packets from my server, so the behaviour is the same.
Yes, It seems to be that it is working with your app. But I am doing something different to you.
Every time a sent a package I woke up from deep sleep with an interruption from the pin PSM_EINT, then I send the UDP packet and then go th Deep Slep anf the RF part to PSM.
So I think that the problem happens when I woke up from deep sleep. I seems to be that once of 100 times something is wrong.
IF I have time will test sending after deep sleep… ( need to write some test udp echo server )
btw: good practice is … confirm … else retransmit / reconnect
I think another important thing is the PSM configuration:
1º. I am using RAI = 2.
2º. I am using these PSM parameters:
/* Set CPSMS /
PSM Enabled
T3412 (TAU): 00100001 = 1H
T3324: 00000000 = 0 sec
/ Set CEDRXS = 0,5 (Disable eDRX) */
eDRX Disabled
Would you mind telling me how many average time is from you send the UDP package from a server to the BC66 module? That is to say, how many time do I have to wait until I received the packet in the BC66 module?
Right now, I have a timer in the BC66 module that I activate after sending a packet from the BC66 module to the server. If after 10 seconds I don’t received any answer from the server I go to sleep mode. Probably this timer has to be bigger, but I don’t know how many?
my example not capture receive…
The NB speed is 250 kbit… but it depends from operator( latency )
my tests … UDP, TCP, SSL, MQTT I get less 5 sec for small packets
The big time is for SSL hadnshake ( from 5 to ~30 sec ) ( note: OpenCPU not support SSL for now )
