NUS Central Write To Peripheral RX Characteristic Very Slow

[DB_ECD]

Hello!

I am currently running into throughput problems while using the Nordic Uart Service (NUS).

I am building a project for a peripheral and wanted to test the possible throughput by using the central_uart example. I modified this example slightly in order to add updates for BLE connection parameters as well as Data Length. I have callbacks for these connection parameters in both my peripheral project as well as in the central project and also added the needed CONFIG_XXX parameters to the respective prj.conf files. After connection, both devices show the following log, so I assume this has worked correctly:

<inf> BLE: MTU exchange successful
<inf> BLE: New MTU: 244 bytes
<inf> BLE: Data length updated. Length 251/251 bytes, time 2120/2120 us
<inf> BLE: Connection parameters updated. interval 320, latency 0, timeout 400

I chose these parameters after trying the BLE Throughput example. With this Throughput example, the config listed as above and 1M PHY, I have a data rate of 783 kbps, which is great.

However, if I try to send BLE messages of 244 bytes with my Central/Peripheral setup, I encounter the following problem:

Calling bt_nus_client_send() on the client side, which in turn calls bt_gatt_write() and  waits for the passed callback function, there is a large delay of ~800msecs between the call of the write function and the execution of the callback function. This slows down the data rate to an unusable 330 bytes/sec..

On the peripheral side I just have my bt_nus_cb receive callback, where I only copy the received data. This should not be a performance limiting factor in my mind.

I know that the Throughput example uses bt_gatt_write_withous_response() while the nus_client uses bt_gatt_write() which, if I'm correct, has an acknowledge in the link layer included. But I don't think that this would cause this huge delay...

So my question is: am I missing something here? Do you have any suggestions as to what I need to change in order to increase the data rate? The throughput example shows me that it should be possible, so I guess with the NUS service it should be possible as well..?

Any help is appreciated!

[Hieu]

I notice some of your configuration differs from that in the Throughput sample. The buffer related ones could explain the issue. Could you please add these configurations and retry?

CONFIG_BT_USER_DATA_LEN_UPDATE=y
CONFIG_BT_USER_PHY_UPDATE=y
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n

CONFIG_BT_BUF_ACL_RX_SIZE=502
CONFIG_BT_ATT_PREPARE_COUNT=2
CONFIG_BT_L2CAP_TX_BUF_COUNT=10
CONFIG_BT_L2CAP_TX_MTU=498
CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y
CONFIG_BT_CONN_TX_MAX=10
CONFIG_BT_BUF_ACL_TX_COUNT=10
CONFIG_BT_BUF_ACL_TX_SIZE=502

CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_PHY_2M=y
CONFIG_BT_CTLR_PHY_CODED=y
CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=4000000

[DB_ECD]

Hello Hieu,

I tried these config values at the very beginning already. I just comiled it again using these values, but it did not significantly improve the result.

However, I kept changing and trying different things and found out that the connection interval value has a huge impact on the througput rate (as to be expected tbh). 

How is this working exactly? Are all the messages as configured in the buffer related configuration values processed and buffered and then sent all at once on every connection event, i.e. channel hop?

As a related question: is there a downside besides increased currend consumption to reducing the connection interval time to a small value of a few ms?

I believe that it's really coming down to chosing just the right connection as well as configuration parameters. If there just weren't so many possibilities.. Anyway, thanks again for all your help so far!

[Simonr]

Hi

Hieu is now out of office, so this case has been assigned to me.

Indeed, the connection interval will impact the throughput rate. This is because the interval will set how long the connection will take, so it will leave more time for the data transmissions and less "down-time". The only real downside will indeed be current consumption increasing, as well as the chance of finding new connectable devices, as it will just keep connecting to the already existing one I believe.

Best regards,

Simon