BLE is fully reliable for GATT, and notifications are guaranteed to be delivered in sequence.
But what you really want is to configure your GATT MTU to the size of the data you want to send. Then the stack will do all the heavy lifting for you and it should be transparent. Note that the GATT MTU is independent
of the LL MTU and thus of DLE.
Carles
From: <users@...> on behalf of "alok.sethi1+zephyr via lists.zephyrproject.org" <alok.sethi1+zephyr=gmail.com@...> Reply-To: "alok.sethi1+zephyr@..." <alok.sethi1+zephyr@...> Date: Thursday, 28 July 2022 at 02:40 To: "users@..." <users@...> Subject: [Zephyr-users] re-assembling large notification data #ble #bluetooth
Hello,
I am fairly new to bluetooth n BLE and would need advice about how to transfer large amount of data (data larger than the MTU) from a sensor to a central device.
So the sensor is using notifications to send the data in multiple chunks and on the central device, my notification callback is called multiple times with a data pointer and length.
I believe that the notifications are acknowledged at the link layer so the application does not get any marker that there is more data pending. is that true?
Further, are the notifications guaranteed to be delivered in sequence?
Currently the sensor is putting a header on only the first chunk and not on the rest of chunks. I can run a re-assembly timer and just assemble the data from different notification calls, provided that the fragments are guaranteed to be delivered in sequence.
Below is just a snapshot of logs taken from the notification callback handler, showing the length of the fragment and the MTU of the connection.
