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.

[esisk]

Hey Simon,

Simon said:

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

After performing write commands instead of write requests drastically improved the throughput. I've demonstrated sending the 500 KB file in about 1 min. That link is helpful for setting expectations on the speed.

Simon said:

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

I've read 2/3 of those blogs and they helped me get to where I am now. 

Simon said:

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.

This paired with my first response regarding write commands and that link you sent me gives me some better context on my situation. My current setup is the file is stored on flash on another MCU (ESP32) that is the Internet link. That MCU downloads the file. The nRF52840 is scanning for peripherals that need to update. Once it finds one to update, the 840 connects to the peripheral and starts sending it the file. That whole process though consists of the 840 asking the ESP32 for a chunk of the file at a certain offset over UART, chunk gets sent over UART to 840 after it reads that chunk from flash at the specified offset, 840 sends chunk to peripheral via write command, and the whole process repeats itself.

Based off the throughput link you sent me, it says that over 2M PHY, conn interval 7.5ms, and using write commands the throughput could reach up to 256 kbps with just straight data to peripheral, no other operations involved. That comes out to about 15 seconds for the transfer of a 500 KB file. Since I'm doing all these other transactions, the ~1 min transfer sounds right to me. Maybe it could be slightly improved.

Simon said:

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

I set it up on a dev kit that I have but once I had Wireshark open it was a little tough for me to discern how to sniff a connection based off of the instructions I found on Infocenter.

Simon said:

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

That is good to know, I feel much better about using the commands instead of requests since they're both reliable. Just to clarify my understanding, what's the benefit of using the requests then? Is it just acked higher up in the BLE stack (GATT, application)?

Thanks so much for all of your help so far

Ethan