BC66 problems with RIL_SOC_QISEND function

Hi everyone,

I am using BC66 with OpenCPU and sometimes I have problems with Tx.

After starting the application I have to do some tasks, so after these tasks, I send data by UDP to my server. It seems to be, that sometimes, when I try to send the UDP data with the function RIL_SOC_QISEND (By OpenCPU: ril_socket.h [SDK v1.5]), the Tx fails and I think is due to the module is in RCC_IDLE state.

So, What can I do to force the module to be in RCC_CONNECTED before to execute the function RIL_SOC_QISEND to make sure that the TX is going to be ok?

Best regards.

Hi Oscargomezf
Provide the error code returned by the failed interface. Thank you!

1 Like

Hi Abner,

The function returns the error number -1. Remember that I am using OpenCPU.

ret = RIL_SOC_QISEND(CONNECT_ID, data_length, send_data);
if (ret != RIL_AT_SUCCESS) {
     APP_DEBUG(prt_debug, "[ERROR] Send data: %d\r\n", ret);
}

It seems to be the device at that moment is in the status RCC_IDLE. So this is the reason I would like to force the device to be in RCC_CONNECTED mode before to try a UDP sent.

Best regards.

Hi Oscargomezf
Can you determine if the module is in idle or deepsleep?

1 Like

Hi Abner,

  1. When the application starts, I execute: Ql_SleepDisable().
  2. After executing the function: RIL_SOC_QISEND() correctly, I finished my application an execute: Ql_SleepEnable() in order to go to deep sleep and PSM.

So during the execution of the function RIL_SOC_QISEND, the module can’t go to idle or deep sleep, but I think somehow the module (the RF part) is not in the status RCC_CONNECTED:

I am a bit stuck with this error. I appreciate any help.

Best regards.

Hi Oscargomezf
Your process is correct. Will you get an error every time you execute RIL_SOC_QISEND ()?

1 Like

Hi Abner,

Not Always. Only from time to time, so it’s very difficult to get the error. When I get this error I wait for 2.5 seconds, and close de socket [1] and open the socket [1] and send the UDP package again… Some times works to retry and sometimes it doesn’t work. I try this process only 3 times. If it fails, I cancel sending the UDP package.

[1] I know that with UDP it is not necessary to open and close the socket, due to the fact it is a protocol not oriented to connection, but I try to have everything compatible with TCP/IP, in case I need to move from UPD to TCP/IP.

Best regards.

Hi Oscargomezf
Confirm whether you execute the RIL SOC_SEND () function, whether there are other AT instructions in the RIL library being executed, if there are, your current problem will occur.

1 Like

Hi Abner,

Thanks in advanced for your help. I appreciate your effort with all my issues.

  1. Is there anyway to check this:Confirm whether you execute the RIL SOC_SEND () function, whether there are other AT instructions in the RIL library being executed?
    I have several task, so this issue could be happening.

  2. I thought, if someone gets the control of the RIL (UART), there is a semaphore or other mechanism to block others… Do you know if this mechanism exists?

Best regards.

Hi Oscargomezf
Do you know if this mechanism exists?
【Abner】The module indicates this behavior with an error -1.

1 Like

There is a mutex

1 Like

Hi Oscargomezf
This is the module kernel code, there is no problem.
Please also confirm your code logic, the calls to the ril interface must not conflict.
You cannot send AT commands to the kernel at the same time.

1 Like

Hi Abner,

I don’t understand what you mean with this: “the calls to the ril interface must not conflict.
You cannot send AT commands to the kernel at the same time.”

In all the functions I am using related to AT commands, this function is involved: Ql_RIL_SendATCmd, so due to the semaphore: “m_nAtMutexId”, I am not going to access to the UART port at the same time, aren’t I?

The point is, if I try to access the UART port in two different tasks at the same task, this semaphore is going to deal with the potential problem. Am I right?

Best regards.

Best regards.

The Ql_UART is “physically” interface to the module uart
Ql_RIL use logical “uart”… pipe

BTW: UDP have issues in firmwares BC66NBR01A07 and 10

1 Like

Hi WizIO,

1º. Then you mean, not to access to the Ql_RIL functions at the same time you are using the UART. In my case, I am only using the uart port for printing messages, that is to say:

[Module Tx] ----> [Rx Console PC]

Therefore, I am not accessing at the same time to the physical UART and the logical UART.

2º. I am very concerned about this: " UDP have issues in firmwares BC66NBR01A07 and 10":

Are there any UDP errors in FW BC66NBR01A10? Do you know what kind of errors or what they are related to? We are thinking to launch a product with this FW.

Best regards.

1.NO… you will have access to Ql_UART(used kernel serial driver) and Ql_RIL (VIRTUAL_PORTx… is a pipe to modem)
example: you can “print/debug” lines from AT_RIL_CALLBACK

  1. I have problems with dns_resolve_address ( is UDP protocol ) sometimes it works, sometimes it doesn’t… timeout…
1 Like

Hi WizIO,

1º. According to 1: Ok, Yes I am using Ql_UART_Write for printing debug messages and Ql_RIL_SendATCmd for sending commands to the module (through a pipe). So, you mean that the mutex in the function Ql_RIL_SendATCmd:

Ql_OS_TakeMutex(m_nAtMutexId, 0xffffffff);

It is not enough and I have to make sure not to execute this function: Ql_RIL_SendATCmd twice at the same time, don’t I?

2º. According to: "I have problems with dns_resolve_address ( is UDP protocol ) sometimes it works, sometimes it doesn’t… timeout…"

The task I execute in the module usually lasts only 15 seconds, but sometimes I’ve noticed that it lasts much more, between 80-130 seconds, Could it be related this issue to the problem with dns_resolve_address?

Best regards.

  1. Don`t worry for this point, this internal mutex protect ( thread safe ) Ql_RIL_Send… from call from other user thread
  2. Queclel must test this issue…
1 Like

The problem is not UDP
[APP] Quectel BC66NBR01A10
[APP] Ril Ready
[AT]
+QIDNSCFG: 1,“8.8.8.8”,“8.8.4.4”,"",""
[MSG] 4098, 101, 0 ( 1 sec )
[MSG] 4098, 2, 1 ( 1 sec )
[MSG] 4098, 3, 2 ( 1 sec )
[MSG] 4098, 3, 1 ( 4 sec ) … CEREG Ready
[MSG] 4098, 3, 2 ( 6 sec ) … searching cell ?!?

1 Like

Ok, understood.

  1. I am using the default DNS IP, so this bug doesn’t effect to me, does it?
  2. By the way, Do you know the default DNS IP for the FW: BC66NBR01A10?

Best regards.