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!

[DB_ECD]

Hello Hieu,

I'm sorry for my late reply, I had some urgent work issues to address.

Now I tried my communication chain again with the same outcome. The attached .zip-file contains the following:

• Logs of both the central as well as the peripheral (where you can see the timestamps with the delay)
•  A screenshot of the uart output of the peripheral, where you can see that all 2440 bytes were received and transmitted in 820 ms
• the wireshark capture of these events

DataRateTest.zip

The only thing I can detect right now is that there is a change in the "Channel index" every time there is this time delay.

I hope, this will give you further information to work with. If you need anything else please let me know.

Thanks!

[DB_ECD]

Hello Hieu,

do you have any updates for me?

[Hieu]

Hello DB_ECD,

I am very sorry for the delay. 

The sniffer log show that the transfer was done over three connection events. 4 chunks in the first connection event at t~=7.49; 5 chunks in the next event, and 1 chunk in the last one. So overall, it matches up with your observation of that the transmission took 800ms.

It mismatches with the log a little, where the chunks are sent in a 4-4-2 spread. Do the log and the sniffer come from the same test? 

This is a little important because I think this might be Connection Event Length Extension at work, where the SoftDevice Controller increase the Connection Event Length if there are more data to send, but only by one TX-RX pair at a time. See Scheduling (nordicsemi.com).

The 4-5-1 spread matches that behavior, but the 4-4-2 one doesn't.

Do you mind repeating this experiment with more chunks?

Also, it might be a little helpful with reading the sniffer log to add some manner of ASCII counter in the payload.

[Hieu]

P.s: You can also try increasing CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT. It is probably a good idea to increase it by just a little bit to experimentally verify it is working first.

[DB_ECD]

Thanks for your reply and sorry for my delay as well, I was on a short vacation the last week.

The log and Sniffer did come from the same test.

I ran the test again, this time using 20 packets (where the first byte of every packet is used as a package counter), the data of which you'll find here:

5340.2024-07-10_DataRateTest2.zip

Here, I encountered basically all the same things as before:

• on the peripheral side: a 4-4-4-5-3 spread
  (as seen in the Log_peripheral, Uart_peripheral and sniffer-pcap files)
• on the central side: a 4-4-4-4-4 spread
  (as seen in the Log_central file)

Hieu said:

P.s: You can also try increasing CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT. It is probably a good idea to increase it by just a little bit to experimentally verify it is working first.

I actually already did that on the central side, increasing this number to the maximum value of 4.000.000. This was used in the test above as well. Changing this value did not seem to improve/worsen the result.

I have to admit that I am kind of lost here.

PS: here are the prj.conf files for peripheral and central, if you need them.

prj_configs.zip