BLE Throughput

[kai19960504]

Hi All,

As far as I know , BLE Thrughput is basically set around a few parameters => 1. NRF_SDH_BLE_GAP_DATA_LENGTH

                                                                                                                            2. NRF_SDH_BLE_GATT_MAX_MTU_SIZE

                                                                                                                            3. NRF_SDH_BLE_GAP_EVENT_LENGTH

My question is => Does the value of NRF_SDH_BLE_GAP_EVENT_LENGTH represent the packets that can be sent in each connection interval?

According to this table : 

If the event length equal 7.5ms,does it mean that it can transmit 6 packets?

Best regards,

Kai

[Einar Thorsrud]

Hi,

The event length is a Bluetooth concept. A connection event occurs every connection interval, and the duration of it is defined by the event length. During the event length, packets can be exchanged. If the event length is as long as the connection interval, packets can be exchanged more or less continuously. This maximises throughput.

If the event length equal 7.5ms,does it mean that it can transmit 6 packets?

Yes and no. If you cant fit 6 packets, then yes. If you can fit more, then you can send more. There is no defined maximum. Note that the documentation you refer to is for an old SoftDevice. More recent SoftDevice versions does not have this bandwidth configuration, but instead just allows you to configure the event length, using NRF_SDH_BLE_GAP_EVENT_LENGTH  as you have found.

[kai19960504]

Hi Einar,

Here is my sdk_config.h setting

Now NRF_SDH_BLE_GAP_EVENT_LENGTH  is 6,so my packet will transfer total 6ms?

[Einar Thorsrud]

There is no hard limit of 6 packets per connection event. If there is more data to send, there is time left in the event, and there are no retransmissions, you can send even more packets than that per event.

[kai19960504]

So,how to interpret this picture?

[Einar Thorsrud]

Different devices may have different limitations. this shows that some different phone models have a limit of packets per connection event. This is entirely implementation specific though, and there is no such limitation in the Bluetooth specification. And for nRF devices there is no limit.

[kai19960504]

Hi Einar,

Einar Thorsrud said:

This is entirely implementation specific though, and there is no such limitation in the Bluetooth specification. And for nRF devices there is no limit.

I'm not very sure what you mean?

[Einar Thorsrud]

You were asking how to interpret the picture which shows that different phone models support a different set of packets per connection event. This does shows exactly that, but nothing else. This is implementation specific limitations in those devices, and not a general limitation. There is no defined maximum number of packets per connection event in the Bluetooth specification, nor in Nordic's BLE stacks.

In a nutshell: The picture tells you what those phones are capable of with regards to packets per connection, and nothing more.

[kai19960504]

Hi Einar,

So through Sniffer, I can confirm the maximum Packet that a Connection Interval can transmit, right?

[Einar Thorsrud]

With a sniffer you can see how many packets are exchanged per connection event. That does not necessarily tell you what the maximum for a specific device is, as this is not a parameter in BLE as such, and that is exchanged on air. There could be other reasons for the number of packets not being as high as you expected (for instance, that you do not have enough data to send fast enough, of that one of the devices also needs to do other things like have time for other Bluetooth connections or WiFi, etc.)

[kai19960504]

Hi Einar,

I roughly understand what you mean, but I don't have a clue how to draw a conclusion at the moment, so I won't close this discussion at this time

[kai19960504]

Hi Einar,

static ret_code_t error_messages_send(ble_gatts_hvx_params_t * const p_hvx_params,  uint16_t conn_handle)
{
    ret_code_t err_code = sd_ble_gatts_hvx(conn_handle, p_hvx_params);
    if (err_code == NRF_SUCCESS)
    {
        //NRF_LOG_INFO("Error notification has been sent using conn_handle: 0x%04X", conn_handle);
         NRF_LOG_INFO("OK   : %x",AppData_CNT++);
    }
    else
    {
        //NRF_LOG_DEBUG("Error: 0x%08X while sending notification with conn_handle: 0x%04X",
        //              err_code,
        //              conn_handle);
        NRF_LOG_INFO("Fail : %x",AppData_CNT++);
    }
    return err_code;
    
}

I checked some stuff about sd_ble_gatts_hvx().

If it does not return successfully, it means the buffer is full.

I have also increased the length of NRF_SDH_BLE_GAP_EVENT_LENGTH but it still drops packets.

[Einar Thorsrud]

kai19960504 said:

If it does not return successfully, it means the buffer is full.

Yes, if sd_ble_gatts_hvx() returns NRF_ERROR_RESOURCES it means the buffer is full. It can also return other error codes though, so you should not assume that all errors indicate that the queue is full.

kai19960504 said:

I have also increased the length of NRF_SDH_BLE_GAP_EVENT_LENGTH but it still drops packets.

OK. There are things you can do (like ensure the event length is equal the connection interval, and that it is of sensible length). But there will be a limit to the throughput. And if you try to send more then the link can handle, you will get NRF_ERROR_RESOURCES returned from sd_ble_gatts_hvx(). That is expected.