nrf52833 BLE Packet Loss Rate High

[soloman]

Hi,

    I use nrf52833 Development board PCA10100 to do loss test as peripheral and speed is 1Mbps, tx power is MAX. It's loss rate is very high, when nrf52833 sends a packet every millisecond to Upper computer. What are the possible reasons for this problem？And the upper computer proved to be fine.

Sincerely!

[Vidar Berg]

Hello,

Data transmission in BLE is reliable. That is, if the packets fails to be sent after x retransmits (number of retransmit attempts are determined by the connection parameters), the connection will be terminated by the BT stack. So, I'm wondering where you are seeing the packet loss?  Do you check the return code from the notification send function?  Also, which SDK are you working with?

Thanks,

Vidar

[soloman]

Hello,

Yes, the return code of sd_ble_gatts_hvx is still SUCCESS when slave nrf52833 transmits packet per millisecond, while the master is a bluetooth module. I find master not receive packet enough, and there is no proper tool to capture the packet to determine whether it was sent from slave. So, you said nrf52833's BLE is reliable, that means slave nrf52833 transmits packet per millisecond is reliable, right? In addition, what configuration may occur the slave machine fails to send even if the packet sending function returns success, when the SDK is nRF5_SDK_17.1.0_ddde560.

Thanks,

Soloman

[Vidar Berg]

Hi Soloman,

Data transmission in the Bluetooth protocol is reliable by design. Therefore, as long as the packet is successfully added to the transmission queue (i.e., when sd_ble_gatts_hvx() returns with SUCCESS), the packet should be received by the gatt client.

soloman said:

and there is no proper tool to capture the packet to determine whether it was sent from slave.

You can capture the on-air traffic with a Bluetooth sniffer such as this one: https://www.nordicsemi.com/Products/Development-tools/nRF-Sniffer-for-Bluetooth-LE 

Have you tried testing this with other centrals, such as an Android or iOS device, to see if you experience the same issue? You can use our nRF connect app to test reception.

Best regards,

Vidar

[soloman]

Hi Vidar,

I did a test with mobile phone Bluetooth debugging app as centeral just now, and the result shows debugging app didn't receive enough packets，that the loss rate is 9/20. 

Best regards,

Soloman

[Vidar Berg]

Hi Soloman,

The fact that you experience the same issue with your phone helps narrow down the problem. I suspect the issue may be with the data or error handling in your application. I can try reproducing this on my end if you are able to share a minimal version project here.

Best regards,

Vidar

[soloman]

Hi Vidar,

This is my mini keil5 project, which the steps of testing as follow:

step 1. compile the project and download to board.

step 2. connect with debug application on mobile phone in 15s.

step 3.After the board is powered on or reset for 15s, timer2 will send 20 packets(1 packet per 10 ms) to the application after power on by characteristic2.

You can observe the statistics of the application, where the first four bytes of the message are the frame number. In addition, the device name is Nordic_UART.

Thanks,

Soloman.

nrf52833dk.rar

[soloman]

Hi,

I found there is no packet lost, when the packet is shorter than 100 bytes. But the MTU is set to 251 successfully, and exchanged mtu with the centeral is successful.

Thansk,

Soloman

[Vidar Berg]

Hi Soloman,

Thanks for sharing the code. The if statement in the code snippet below will never evaluate to true.

    err_code = sd_ble_gatts_hvx(ulConnHandle, &hvx_params);
    if ((err_code == NRF_SUCCESS) && (hvx_len != usLen))
    {
        NRF_LOG_DEBUG("Failed sending notification. Error 0x%x. ", err_code);
    }

So you will not get any error message if the sd_ble_gatts_hvx() function, for instance, returns with NRF_ERROR_RESOURCES.

Please try this instead:

    err_code = sd_ble_gatts_hvx(ulConnHandle, &hvx_params);
    if (err_code != NRF_SUCCESS)
    {
        NRF_LOG_DEBUG("Failed sending notification. Error 0x%x. ", err_code);
    }

Best regards,

Vidar

[soloman]

Hi Vidar,

I'm very awkward for this mistake. I do test again and the return value is NRF_ERROR_TIMEOUT. Why does packet sending time out when the interval is 10ms, but when the interval is larger, such as 50ms, it does not time out?

Thanks,

Soloman