nRF52 sending large bulk data

[jackbauerctu]

I have read these the following posts:

devzone.nordicsemi.com/.../ devzone.nordicsemi.com/.../

But, most of the answers are quite old. I am wondering if the solution to send multiple notifications is still an valid answer.

Thank you.

[endnode]

Hi Jack,

Short answer is YES.

Long answer follows:

• If you want to use BT LE and at the same time being interoperable with platforms such as Android, iOS, Windows etc. then you have almost no other choice then to deploy application on top of GATT layer (so it will be using GATT Server or GATT Client role).
• Then to optimize throughput you want to use WRITE without response method from GATT Client side and VALUE NOTIFICATION (HVX) from GATT Server side.
• And in case that your data could be in principal larger then (ATT_MTU - 3) size you will need to develop some kind of fragmentation/reassembly protocol on top of these GATT methods (note that default ATT_MTU size is 23 bytes).
• If you want to see some practical examples and throughput numbers then please download latest S13x SoftDevice Specification v3.0 and refer to chapter 18 (there aren't all possible combinations but these values illustrate both "theoretical" and "practical" limits very well).

Cheers Jan

[kmorris]

Hi Jack & Jan -

As a follow-up, I understand when transferring large amounts of data it has always been recommended to use notifications to optimize throughput - because you don't have to get a response. However, what if you DO care that all the data gets received? Is it still better to send it all quickly through notifications and then have the client request a re-send of any missing data? Say I have a 20-byte datapoint for every minute and I've been storing them for the last 30 minutes or so, and I send all 30 of them as notifications, if the client doesn't receive datapoints 11-15, I could request a re-send? Or, is there an example where the acknowledgement is received per packet sent? And would you be able to point me to it, since most examples (and what I have used previously) was the notifications?

[Petter Myhre]

Notifications are acknowledged at the link layer, so you will not lose any.

[endnode]

Hi kmorris,

I guess there is slight misunderstanding of how BT LE Logical Link layer works (and why we all love BLE - including you;): LL makes sure that there is automatic packet re-transmission so a) you don't have any problem with missing packets in the middle and b) if connection fails then you know (at least on LL level) which was the last packet transferred. If you read BT SIG Core specification then unacknowledged or acknowledged WRITE/READ/NOTIFY/INDICATE methods are simply because implementation specifics can cause overflow or other issues on GATT and APP layers so even some PDUs are delivered by LL layer the data might be discarded (and the way to ensure 100% certainty is to use proper "with Response" types of ATT/GATT methods). However in reality this is very unlikely and it's much easier to implement final ACK on top of GATT/APP protocol (your app will just say "DATA OK").

[kmorris]

Thanks. That makes sense.