Timer for UDP Rx using BC66 module

Hi everyone,

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.

Does anyone any suggestions?

Best regards.

what error ( receive ) ?
blocked / nonblocked socket ?

Hi WizIO,

First of all, remember that I am using OpenCPU and UDP.

These are the steps I follow:

  1. The socket is open without errors.
  2. Then, I send an UDP packet to a server X. In this point, I activate a timer called: UDP_RX_TIMER.
  3. The server always receives the UDP packet correctly and answers straightaway with an UDP packet to the module BC66.
  4. 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?

Best regards.

int res = Ql_SOC_Recv( . . . ) will return “error” code

  • SOC_ERROR_WOULDBLOCK < - - is not error, wait response in callback
  • SOC_ERROR_other_error = -X

what return Ql_SOC_Recv() ?

Hi WizIO,

Thank you very much in advance for your help.

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);

Best regards.

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.

HINT: ask from Quectel SDK 1.5 and firmware v10
and use Ql_SOC_xxxx() functions … they follow kernel lwip as is

Hi WizIO,

I am already using SDK v1.5 and FW v10. Do you mean that using ql_socket.h instead of ril_socket.h is much better?

Best regards,

yes is better
API “soket” follow kernel lwip as is

Hi WizIO,

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.

Does anyone any suggestion??

Best regards.

no idea
are you have udp echo server?

udp echo @ “echo.u-blox.com

Leaving the BROM
Arduino Firmware: BC66NBR01A10
4098, 2, 1 ( 1 s )
4098, 3, 2 ( 1 s )
4098, 3, 1 ( 3 s )
SENT ‘Hello World 1582800941’
[RECEIVE] ‘Hello World 1582800941’ ( 1 1 ) 4 sec ( sent count, receive count )

SENT ‘Hello World 1582801518’
[RECEIVE] ‘Hello World 1582801518’ ( 109 109 ) 43 sec

Hi WizIO,

Thank you very much for your help.

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

Hi WizIO,

Thank you very much for your help.

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

direct sending: 100 from 100 without lost packet, interval 1 sec

psm: 180 sec, real 200 sec ( active window ) ( wakeup from RTC: 10 sec )
20 from 20, no lost packet… ( update: 80 from 80 )

the script

and node.js echo server

Thank you very much for your help.

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?

Best regards.

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 )

Hi WizIO,

According to: “my example not capture receive…”

I have problems with the reception(Rx) in the BC66 module. This is the steps I am doing:

  1. Wake up from PSM using the PSM_EINT (I have a raspberry pi with a relay being activated every 400 seconds).
  2. Send a UDP package to a server.
  3. Then, wait for 15 seconds to receive an answer from the server.
  4. If the timer of 15 seconds expires, I assume a fail in Rx (I am getting around 3-4% Rx error rate). If It not fails, I print the data received.
  5. Go to Deep Sleep and PSM.
  6. After 400 seconds, an external relay connected to the PSM_EINT pin activates the BC66 module again and the BC66 module goes to step 1.

Best reagards.