Increasing the communication rate using GATT-READ above 10kB/s (K Bytes/Seconds) ?

[Omid]

Hello my friends,

I am trying to convey a large system file data using my own developed GATT Service where I am using a read characteristic to read the file system.

Specifically, I have a central which does gat read on the discovered attribute handle exposed by the peripheral. (The read characteristic included in the GATT service).

After doing MTU update, I can achieve almost 2.55 KB/s where I have the following related configurations:

CONFIG_BT=y
CONFIG_BT_SMP=y
CONFIG_BT_TINYCRYPT_ECC=y
CONFIG_BT_MAX_PAIRED=2
CONFIG_BT_HOST_CCM=y
CONFIG_SETTINGS=y

CONFIG_BT_HCI_ACL_FLOW_CONTROL=y
CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y
CONFIG_BT_L2CAP_TX_MTU=251
CONFIG_BT_BUF_ACL_RX_SIZE=255
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_BUF_CMD_TX_SIZE=255
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

Also, here is the connection parameters I am using:

    struct bt_le_conn_param param = {
                            .interval_min = 0x0008,
                            .interval_max = 0x0008,
                            .latency = (0x00008 * 1.25)*1,
                            .timeout = 400,
                            };

However, I have seen posts in devzone like THIS ANSWER or THIS POST where people are talking about transmission rates around 14 KB/s or at least above 10KB/s.

I was wondering how I can increase the download rate of my application to such ranges?


Thanks,
Omid

[Omid]

I found out what was causing the issue.
Apparently, the connection parameter update did not work out the way I intended to.
For some reason, the connection parameters reverted back to some random value.
I moved the param update after MTU exchange phase, and then, it got solved.
As a matter of fact, I can get a reading rate of 12.7 KBytes/seconds with a connection interval of 8 ms.

I am going to keep the question open to see if there is any other suggestions that I can use to improve the rate further. 

[Vidar Berg]

Hi Omid.

If you want to further improve throughput, I recommend considering having the GATT server send the file system data as notifications, instead of having the client send a read request for every packet.This enables the server to push out the data as quickly as the link permits without waiting for requests from the client. You can add another writable characteristic to serve as a data control point, which can control when the server should start sending notifications.

We currently don't document throughput numbers for the nRF Connect SDK, but you can have a look at the Bluetooth Low Energy data throughput  section of the SoftDevice specification to get an idea of the theoretical limit for notifications.

Best regards,

Vidar

[Omid]

Great suggestion, thank you.
I did realize that the SMP-service module in zephyr is using the notification for data transfer and was wondering if that can have something to do with the communication delay.