Slow transfer speed to an nRF52

[Stefan]

Hello!

We are doing transfer from an Android app to a device using nRF52. We don't get the transfer speed I have seen other achieve. I get between 8.5-10 kbps. As a reference, if I run DFU I get 16 kbps. But I still want these ~100 kbps I have seen people talk about. We use SD132.

One of the comments on the high speed reached is for instance in this post. Also in the documentation there are higher speeds. Though that is higher connection interval than what is used.

The connection interval is set to 7.5 ms. nRF Connect reports 15 - 200 ms, whatever that means. (the interval I mean). We use "transfer without response". MTU size is 23.

I have gotten tips on "disable advertising". Isn't advertising automatically turned off when a connection is established? Is advertising a known "link hog"? I have tried, but not seen any real difference.

I apologize for these open ended questions, but I have no better way to try to explain this.

[Updated with reference to comments about transfer speed].

Thanks and best regards, /Stefan

[endnode]

Hi Stefan,

Where have you seen higher data rates then 10~16kbps on Android? Once it comes to real applications this is where we all live with BLE... phones typically settle on much higher connection interval (Android = 48.75ms) then what is the minimum allowed (7.5ms), also supporting ATT_MTU extension (you are saying you use default 23B) and PDU extension are not always seamlessly supported, number of MTUs per connection interval is again property of low level BLE stack which you cannot influence. If you really want to achieve something better then what you see then you need to understand what exact parameters are now used (= get RF log by some BLE sniffer) and what you can influence form application layer (typically just MTU size and indirectly = phone will use values it has hardcoded and you get only callback if MTU changed or not). The same on the other side of the link of course (all Nordic stacks on nRF52 now support MTU and PDU extensions, connections intervals down to 7.5ms and multiple MTUs/PDUs per interval for high throughput).

When it comes to advertising:

• It's typically turned off by GAP Peripheral as soon as connection is established (this is not must in BT4.2+ but in BT4.0-4.1 it's even mandatory to not advertise connectable packets once there is one connection ongoing already).
• Even if some device supports multiple GAP peripheral connections and so it restarts advertising immediately after first connection is established the advertising procedure itself has typically very little or now effect on throughput available to already ongoing connection. This would get worse if there are more parallel connections established but otherwise it would not be a major problem.

[Turbo J]

Android supports lower connection intervals beginning in 5.0 (Lollipop): See requestConnectionPriority().

[endnode]

Yes, but that makes the situation even more complicated: you can set this "wish" from Android app layer but how exactly lower BLE stacks react can be highly vendor dependent. Shorter connection interval can mean that stack won't allow certain MTU sizes or multiple packets per interval etc. Or you have good experience with this and you've managed to push throughput over BLE GATT layer beyond 10-20kbps?

[Turbo J]

I get about 4,5 KByte/sec in my app (against NRF52x), that is about 40kBit/sec. The connection interval will be about 15ms.

[endnode]

That's definitely nice! Could you just for the record share PDU/MTU sizes, number of packets per interval and Soft Device version used? Could be great data point for Stefan and all of us...