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.

[jackbauerctu]

I was also thinking about how to do implement this.

Perhaps I can try to mimic the windowing mechanism from TCP/IP? Maybe the initial window will be 10 items. Then you would get DATA OK for each of those items. Once you get the DATA OK for item 0, then move the window up.

You can even go further and dynamically adjust the window size when the BLE connection isn't that stable too.

Am I over thinking this? Or maybe the simple send one item and expect DATA OK; then send the next item?

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

[endnode]

(continuation...) define some "ACK" messages (they can even contain number of bytes received or hash - but that would be probably too heavy). In the end pretty anything will do the job, it's just a question how difficult for implementation you make it, how efficient you want it (in terms of computation power/time and overhead inside GATT data which lowers your effective bandwidth) and what error/recovery mechanisms you need for session management...

[kmorris]

I just implemented mine following this example devzone.nordicsemi.com/.../ Jack - have you tried this one?

I don't update my 'last synchronized' pointer until it all goes through, that way it ends up starting over if it gets interrupted. (I may change that and have it start where it left off, idk yet) I will probably also implement a way for the app/client to ask for prior data, just in case something goes awry on the app side.

[endnode]

Well there is this "Nordic UART Service" aka "NUS" available in nRF5 SDK examples and it is one example how to solve "ATT MTU fragmentation and reassembly" problem. You probably can just use it out of the box without big investigation of details.