Slow transfer speed to an nRF52

RE: Slow transfer speed to an nRF52

Stefan — Fri, 30 Jun 2017 10:44:42 GMT

Thank endnode. I looked into bandwidth and it says if S132 is peripheral (as my nRF52 device is) high BW is default. I hope I have read the documentation properly and also interpreted "BLE peripheral" properly.

RE: Slow transfer speed to an nRF52

endnode — Thu, 29 Jun 2017 20:25:15 GMT

Also make sure you use proper bandwidth settings when enabling SD on nRF5x side.

RE: Slow transfer speed to an nRF52

endnode — Thu, 29 Jun 2017 20:23:08 GMT

Thanks for update Stefan. I'm really skeptical about achieving 100kbps with just any android phone (which is BT SIG 4.x) especially on higher layer like GATT. Nordic specifications and examples are typically speaking about link where you control lower layers e.g. two nRF5x devices against each other, which is quire different from Android phone. Anyway if we would assume it's applicable your and TurboJ numbers are pretty in-line with the last lines of first table: ~10kbps for Write with Response and ~40kbps for Write command or Notification. I would take the RF trace and see what exact parameters are on the link. Then if you are sure you use optimal GATT methods you can try:

Getting shorter connection interval through Android API as suggested below.
Using PDU length extension and MTU length extensions as suggested on blog zone.

RE: Slow transfer speed to an nRF52

endnode — Thu, 29 Jun 2017 17:51:55 GMT

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...

RE: Slow transfer speed to an nRF52

Turbo J — Thu, 29 Jun 2017 17:49:03 GMT

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

RE: Slow transfer speed to an nRF52

endnode — Thu, 29 Jun 2017 15:08:32 GMT

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?

RE: Slow transfer speed to an nRF52

Turbo J — Thu, 29 Jun 2017 14:55:04 GMT

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

RE: Slow transfer speed to an nRF52

endnode — Thu, 29 Jun 2017 11:48:35 GMT

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.