Increasing BLE Throughput

[esisk]

I've been following this blog post to increase BLE throughput for my application: Building a Bluetooth application on nRF Connect SDK - Part 3 Optimizing the connection - Software - nRF Connect SDK guides - Nordic DevZone (nordicsemi.com)

It's very helpful, but I need a little extra guidance. My setup is a Peripheral device with an nRF9160 as Host with a nRF52820 as Controller connecting to a Central device with a nRF52840 all using NCS v1.7.0. I'm attempting to send a large file to the Peripheral (500+ KB). I've gotten all projects configured to where the transfer takes about 5-6 minutes. I'm using a connection interval of around 7.5 ms, 0 latency, and 4 second timeout. Given RAM constraints on the 52820, the largest data length I can negotiate is 147 bytes. The MTU is 247 bytes. The PHY is 2M. These all seem decently optimal given my understanding of BLE. Based on the blog post, a conservative estimate of the throughput should be around 1000 kb/s for their configuration, and since my data length is decently shorter than the project in the blog post, let's just roughly estimate it's more like 700 kb/s. With that throughput, it works out to about 87,500 bytes per second. With a 500 KB file, the transfer would be about 5.7 seconds if all symbols being sent were the file; obviously, there's overhead, so let's be very conservative and triple that number to get around 17 seconds for the entire transfer. Correct me if my reasoning is wrong but given my explanation and how long it is currently taking to transfer the file, it seems that I am setting up something wrong. Are my connection parameters not optimized? I'm also using bt_gatt_write instead of bt_gatt_write_without_response or bt_gatt_notify which I do know is slowing the transfer down since the peripheral needs to respond, but it shouldn't be on the order of minutes right?

Edit: I figured out how to configure the 52820 project to increase the max data length to 251 bytes. I timed the transfer and it took 4 minutes. My goal is to still get the transfer down to under a minute since the Throughput example (Bluetooth: Throughput — nRF Connect SDK 1.7.0 documentation (nordicsemi.com)) shows that it transfers 598 KB in 3.8 seconds

[Simon]

Can you try to increase the connection interval higher than 7.5 ms? A low connection interval doesn't necessarily lead to a high throughput

To understand why, read this answer by Torbjørn:  RE: what is the relation between connection interval and the throughput? 

The throughput example uses a connection interval of 400 ms: https://github.com/nrfconnect/sdk-nrf/blob/0a77f4d53ee9fcc3662a8888c8290dde96da412e/samples/bluetooth/throughput/src/main.c#L32-L33 

Let me know what the throughput is after you've increased the conn. interval. Also try to play around with the throughput example to get an understanding of how the different connection parameters affects the throughput

Best regards,

Simon 

[esisk]

I'll try that out. That would make sense as to why I could be experiencing a bottleneck.

Edit: Increasing to 400ms connection interval really slowed the process down. I'll continue to experiment with different intervals though

Edit 2: After playing around with the parameters some more, I'm definitely seeing faster speeds with the lower connection intervals

[esisk]

Any other tips Simon? My main option may just be switching to write commands instead of write requests. That significantly improved the throughput. Another question I have is are write requests commands reliable? 

[Simon]

esisk said:

Any other tips Simon?

What is your current throughput? Have you managed to get close to the numbers in Bluetooth Low Energy data throughput?

There are some useful blogs about BLE throughput you might want to check out:  

https://interrupt.memfault.com/blog/ble-throughput-primer

https://punchthrough.com/ble-throughput-part-4/

https://novelbits.io/bluetooth-5-speed-maximum-throughput/

esisk said:

Another question I have is are write requests commands reliable? 

Both write commands and write requests should be acked in the link layer, so both are reliable.

Best regards,

Simon

[Simon]

The throughput also depends on how you store the file on the peer device, if you need to erase flash pages and write to flash. This will be a bottleneck.

Could you provide a sniffer trace? Then it will be easier to spot where the issue is.