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

[endnode]

TCP/IP, like srsly???:) I assume you will be using some "self-consistent" protocol on top of GATT anyway (e.g. there will be some length indicators or even integrity checks based on some CRC/hash/crypto signature scheme). But if you are sure that data formatting is completely free and up to you, then simply use some light-weight protocol used in other embedded systems. E.g. Host Control Protocol (HCP) or something even simpler: dedicate part of each "fragment" to "header" and indicate if this is last fragment or not. If there will be any issue it will anyway break the link so you don't need to care about anything else then case where receiver would be processing incomplete data. If your use case has no natural "session" management (e.g. that one side would be sending commands and then waiting for response) then you can (to be continued...)