BLE data packet drop during transmission

[Xander To]

.Hi Nordic Support team,

I'm using NRF52832, SoftDevice S132, SDK version is nRF5_SDK_17.1.0_ddde560.

I want to transmit 9 bytes of data collected from an I2C sensor every 2.5ms via BLE. The sensor has an internal buffer so I can queue up to 288 bytes (80ms from empty to full sensor buffer). However, I2C can only receive 255 bytes per queue, so I only collect data from the sensor every 60ms, because for 60ms, the sensor produces 216 bytes of data and it is within 1 MTU packet ( configure it to be 247 bytes per MTU). That means I will send 1 MTU every 60ms. That means I only need a connection interval of 60ms. Am I correct?

In my BLE structure, I also have another different characteristic that reports the device temperature (takes only 2 bytes) every 10 seconds (yes, second not milliseconds). However, from my experiment, 60ms cannot keep up with this data rate from both characteristics. Do I misunderstand anything? Should I use the connection event extension length? 

Here are my BLE parameters: NRF_SDH_BLE_GAP_EVENT_LENGTH is 6. TX queue length is 1. Min connection interval = Max connection interval = 60ms. Save lantecy is 4.

I also have tried to increase the TX queue length to 18. Set Min connection interval = 30ms, Max connection interval = 120ms, enable Connection Event Length Extension by the following code right after ble_advertising_init. However, I still occasionally get NRF_ERROR_RESOURCES from sd_ble_gatts_value_set(p_cus->conn_handle, p_cus->data_char_handles.value_handle, &gatts_value);

What I am trying to do is optimize power consumption while also ensuring absolutely NO data loss via BLE transfer.

// Connection Event Length Extension
ble_opt_t  opt;

memset(&opt, 0x00, sizeof(opt));
opt.common_opt.conn_evt_ext.enable = true;

err_code = sd_ble_opt_set(BLE_COMMON_OPT_CONN_EVT_EXT, &opt);
APP_ERROR_CHECK(err_code);

Please let me know if I do anything wrong. 

Best regards,

Xander

[Xander To]

Hi Hieu,

Sorry for my mistake. It should be the function sd_ble_gatts_hvx, which means I cannot queue more in TX queue right?

Best regards,

Xander

[Hieu]

Hi Xander,

Yes, sd_ble_gatts_hvx() returning NRF_ERROR_RESOURCES means that the queue is full.

The documentation of the function contains some note on this exact error. It might give more insight it to check the relevant Message Sequence Charts as well.

With such information in mind, please try to analyze the code and run some testing to see if there are anything unexpected.

Our colleague Hung discussed a little about handling the notification queue in this DevZone case as well:  sd_ble_gatts_hvx returns NRF ERROR RESOURCES while transferring bytes .

Best regards,

Hieu

[Xander To]

Hi Hieu,

I have checked Hung's suggestion. However, it still doesn't explain why I have a queue-being-full issue.

TX queue size is 18, which still causes this error, meaning the BLE cannot keep up with the data rate I require. So I think it's something in BLE parameters I need to reconfigure, instead of keep tracking the remaining slots in the queue. So I want to understand the mismatch between my calculation and the actual behaviour of BLE. Because I thought NRF_SDH_BLE_GAP_EVENT_LENGTH is 6, MTU size = 247 bytes, min connection interval = max connection interval = 60ms and slave latency is 4 should be adequate for 216 bytes every 60ms + 2 bytes every 10 seconds.

Best regards,

Xander

[hmolesworth]

Maybe try testing in a clean BLE- WiFi- etc- free environment and see if the problem goes away; Radio congestion leads to multiple attempts to send BLE packets until they succeed, which means some transmission effective rates are much slower than expected (in periodic intervals) and hence NRF_ERROR_RESOURCES error follows. Typically fix by using much larger intermediate buffers for packets than expected.

NRF_ERROR_BUSY For @ref BLE_GATT_HVX_INDICATION Procedure already in progress. Wait for a @ref BLE_GATTS_EVT_HVC event and retry.

[Xander To]

Hi Hmolesworth,

Should I increase NRF_SDH_BLE_GAP_EVENT_LENGTH  first or should I lower the connection interval first? Which one is better for low-power consumption applications?

Best regards,

Xander