Increasing BLE Throughput

RE: Increasing BLE Throughput

ovrebekk — Thu, 03 Nov 2022 07:14:48 GMT

Hi Ethan

By spec the size of an attribute is limited to 512 bytes maximum, and you shouldn't be able to send more than that in a single write command or request. Then the link layer will split the package into smaller packets for the radio, since the maximum data length is 251 bytes.

Are you able to share the code you use to send 2KB packets using write requests, as well as the configuration parameters you use?

Best regards
Torbjørn

RE: Increasing BLE Throughput

esisk — Wed, 02 Nov 2022 12:58:44 GMT

That's ok, thanks for stepping in Torbjørn. I actually found a decent compromise between scanning discovery and connection throughput, thanks for your suggestion. One more question I have: I noticed that with write commands, the length of the data I can send seems to be limited by the MTU whereas write requests can split a say 2KB packet into the necessary lengths and then some layer in the Bluetooth stack on the peripheral can assemble them all back together to 2KB before giving it to the peripheral's application layer. Is that possible with write commands as well? I'm trying to reduce the number of flash reads and UART transmissions I need to make in order to send this file

RE: Increasing BLE Throughput

ovrebekk — Wed, 02 Nov 2022 09:31:00 GMT

Hi Ethan

Simon is currently unavailable, and I will help you out instead.

Scanning while in a connection is possible, but it will affect the max throughput of your link, yes. What you can do to minimize the impact is to use a long scanning interval and a short scanning window, but this will obviously affect how fast you detect advertise packets so you have to do some testing to find a good compromise between scanning performance and the throughput of the connection.

Best regards
Torbjørn

RE: Increasing BLE Throughput

esisk — Thu, 27 Oct 2022 18:54:24 GMT

Hey Simon, I'm replying here because the reply button won't show up on your most recent post.

[quote userid="72692" url="~/f/nordic-q-a/92683/increasing-ble-throughput/392088"]Feel free to open a new ticket about the sniffer trace, and get back here as soon as you have gotten it working. Then I'll take a look at it.[/quote]

I'll do that sometime soon.

Thanks for the clarification regarding requests vs commands. The last thing I need guidance on is scanning for other advertisements while sending this file. Is that even feasible given how much this file sending process is hogging the radio? If it's feasible, could you give me some advice as to how to go about setting that up or point me towards a good ticket regarding this? Currently haven't found anything.

RE: Increasing BLE Throughput

Simon — Mon, 24 Oct 2022 10:05:42 GMT

I'm happy you were able to increase the throughput to an acceptable level.

[quote user="esisk"]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.[/quote]

If you want to increase the throughput even more, a sniffer trace would be nice.

Feel free to open a new ticket about the sniffer trace, and get back here as soon as you have gotten it working. Then I'll take a look at it.

[quote user="esisk"] 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)?[/quote]

Write requests can be useful in situations where you want to start some time consuming operation on the server side, and you want to restrict the ability to send more data or commands while the current operation is running. The server can send a response to the request once the operation is complete, and is guaranteed not to receive any new commands before this, since you can only have one indication pending at the time.

Indications/notifications are the equivalents of Write request/write command, just in the opposite direction. So the answer above was inspired by RE: Use cases of indications - When is it better to use indications over notifications?

Best regards,

Simon

RE: Increasing BLE Throughput

esisk — Wed, 19 Oct 2022 17:59:32 GMT

Hey Simon,

[quote userid="72692" url="~/f/nordic-q-a/92683/increasing-ble-throughput/391480"]What is your current throughput? Have you managed to get close to the numbers in Bluetooth Low Energy data throughput?[/quote]

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.

[quote userid="72692" url="~/f/nordic-q-a/92683/increasing-ble-throughput/391480"]There are some useful blogs about BLE throughput you might want to check out: [/quote]

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

[quote userid="72692" url="~/f/nordic-q-a/92683/increasing-ble-throughput/391494"]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.[/quote]

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.

[quote userid="72692" url="~/f/nordic-q-a/92683/increasing-ble-throughput/391494"]Could you provide a sniffer trace? Then it will be easier to spot where the issue is.[/quote]

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.

[quote userid="72692" url="~/f/nordic-q-a/92683/increasing-ble-throughput/391480"]Both write commands and write requests should be acked in the link layer, so both are reliable.[/quote]

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

RE: Increasing BLE Throughput

Simon — Wed, 19 Oct 2022 15:18:21 GMT

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.

RE: Increasing BLE Throughput

Simon — Wed, 19 Oct 2022 14:47:17 GMT

[quote user="esisk"]Any other tips Simon? [/quote]

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/

[quote user="esisk"] Another question I have is are write requests commands reliable? [/quote]

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

Best regards,

Simon

RE: Increasing BLE Throughput

esisk — Mon, 17 Oct 2022 13:09:38 GMT

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?

RE: Increasing BLE Throughput

esisk — Tue, 11 Oct 2022 13:49:57 GMT

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

RE: Increasing BLE Throughput

Simon — Tue, 11 Oct 2022 13:43:32 GMT

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