How to determine the number of packets per connection interval

[Harinben]

Hi,

I am currently working on a project to transfer data from a computer to an embedded device. During the implementation, I encountered problems to achieve the required data throughput. I noticed that the measured 20kB/s did not come close to the expectations as shown under the following link:

Bluetooth 5 speed: How to achieve maximum throughput for your BLE application

I have done some investigations and will explain them here briefly before my actual question comes. Figure below shows an overview of my setup. I use a USB dongle from Nordic to make the laptop BLE capable. On the embedded device, there is an nRF52832 in use. Also shown are the used software components from Nordic and the roles on BLE level.

The used BLE connection parameters:

• Used PHY -> LE 1M (sd_api_v3 not support LE 2M)
• Connection interval of 20ms
• Data Length Extension enabled
• The MTU size 227 bytes

The application procedure is as follows. The PC application checks how many packets can be buffered in the softdevice (in this case six). The six packets (write commands) are transferred to the softdevice. At each TX_COMPLETE event, a new packet is loaded into the softdevice. This approach ensures that there are always enough packets ready for transmission. However, I found that the number of packets per connection interval influences the data throughput (as mentioned in the link above).

The problem is that I cannot find any information about the amount of packets allowed per connection interval. During my research, I have varied the MTU sizes and found that the number of packets per connection interval may depend on this parameter.  I have the following two sniffer recordings.

The first one is taken with an MTU size of 227 bytes. As shown in figure below, two packets are transmitted each connection interval. In the last packet on each connection interval even the “More Data” flag is set.

A second measurement was made with increased MTU size of 247 bytes. The recording of the sniffer shows only one packet per connection interval despite the “More Data” flag being set in the respective packet.

My question is what the number of packets per connection interval depends on? If I look at all the measurements on the Internet, there should definitely be more packets per interval. Did I possibly miss a parameter?

Best regards,

Benjamin

[Sigurd]

Hi,

For SoftDevice v.6.x, as long as packets are queued in the SoftDevice when the connection event starts, the Softdevice will try to send as many packets as it can in the the connection interval, as long as the time set aside for the connection on every connection interval is not exceeded, this limit can be configured with NRF_SDH_BLE_GAP_EVENT_LENGTH (in sdk_config.h), and as long as there is still packets in the queue.

For SoftDevice v.3, you can configure the bandwidth for the central like this (documentation here):

     /*Configure bandwidth */
 ble_opt_t ble_opt;
 ble_common_opt_conn_bw_t conn_bw;
 memset(&conn_bw, 0x00, sizeof(conn_bw));
 memset(&ble_opt, 0x00, sizeof(ble_opt));

 conn_bw.conn_bw.conn_bw_rx = BLE_CONN_BW_HIGH;
 conn_bw.conn_bw.conn_bw_tx = BLE_CONN_BW_HIGH;
 conn_bw.role = BLE_GAP_ROLE_CENTRAL;
 
 ble_opt.common_opt.conn_bw = conn_bw;
 
 uint32_t err_code = sd_ble_opt_set(BLE_COMMON_OPT_CONN_BW, &ble_opt);
 APP_ERROR_CHECK(err_code);

[Harinben]

Hi,

Thank you for the quick response.

If I have understood it correctly, it would be best if I set NRF_SDH_BLE_GAP_EVENT_LENGTH equal to connection interval. Correct?

I have checked these parameters in my test setup. NRF_SDH_BLE_GAP_EVENT_LENGTH is set to 12 (*1.25ms = 15ms) in sdk_config.h. This value should also allow more than one packet with MTU size 247 bytes.

On the PC side, BLE_CONN_BW_HIGH is already set as suggested in your code snippet.

Is it possible that there is a limitation on the USB dongle firmware?

[Sigurd]

Harinben said:

If I have understood it correctly, it would be best if I set NRF_SDH_BLE_GAP_EVENT_LENGTH equal to connection interval. Correct?

It depends. By setting it even higher you should be able to queue more packets.

You might also want to enable extended BLE connection events:

void conn_evt_len_ext_set(bool status)
{
    ret_code_t err_code;
    ble_opt_t  opt;

    memset(&opt, 0x00, sizeof(opt));
    opt.common_opt.conn_evt_ext.enable = status ? 1 : 0;

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

}

Harinben said:

Is it possible that there is a limitation on the USB dongle firmware?

 There could be some added latency, but the MD-bit indicats the the SoftDevice had more data to send. You are sending write commands from the master, and sending notifications from the slave? Could you save and upload the sniffer log ?

[Harinben]

Sorry for the delay. I did some tests yesterday.

I was able to get several packets with MTU size 247 per connection interval sent yesterday. Because of this I achieve higher data throughput

As recommended I have looked at the option extended BLE connection event. It was already set on the firmware side. But I can't make an exact statement on the PC side (sd_api_v3), because the function

sd_ble_opt_get(BLE_COMMON_OPT_CONN_EVT_EXT, &opt);

returns an NRF_ERROR_NOT_SUPPORTED error. But the "Set"-function does not return an error, so I assume that it works. Is it correct that the "Get"-function does not work?

Sigurd said:

You are sending write commands from the master, and sending notifications from the slave?

Right. To maximize the data throughput I decided to acknowledge the data with notifications on application level.

Sigurd said:

Could you save and upload the sniffer log ?

Sure.

7612.MTU_size_227.pcapng

6138.MTU_size_247.pcapng

I noticed something else. In the sniffer data (MTU size 227) you can see that the slave answers with a lower latency (~1ms), but the master sends the next packet with a delay of >2ms. Is this delay of the master fixed or can it be configured by a parameter?

[Sigurd]

Harinben said:

Because of this I achieve higher data throughput

 Great!

Harinben said:

Is it correct that the "Get"-function does not work?

 That is correct. sd_ble_opt_get is not supported for this option.

Harinben said:

Is this delay of the master fixed or can it be configured by a parameter?

You cannot change this, it takes longer time to send a long packet.

[Harinben]

The primary issue has been resolved for me. I will mark the correct answer.

But I have one last question. Are there any known reports that have measured the BLE throughput with the PCA10059 in combination with the pc-ble-driver? Or are there any useful examples?

[Sigurd]

Harinben said:

Are there any known reports that have measured the BLE throughput with the PCA10059 in combination with the pc-ble-driver?

 No, unfortunately not.

Harinben said:

Or are there any useful examples?

 For pc-ble-driver we have the heart_rate_collector and heart_rate_monitor example. For measuring throughput, we have the ble_app_att_mtu_throughput example in the SDK, but nothing on the pc-ble-driver side.