I’m working on a BLE demo that requires to transfer large data packets continuously, the solution that I came up was to create a server that provides a single service with a single Read/Write/Notify attribute.
The attribute data is a large byte array up to 8kB, and when a client subscribe to notifications the server start to send the data continuously. The issue that I found is when the client requests a attribute read it receives all data, however when subscribes to notifications the server sends all data but no data is received by the client.
I have tried spliting the data in blocks with size equal to MTU, but this reveal to be losing some blocks and is very slow, increasing MTU size to more than 128 bytes start causing various issues.
The default GATT MTU size is 23 bytes, it can go up to 512 bytes if both connected devices supports that MTU size. If you are in a controlled environment where central and peripheral controllers capabilities then you can build your application around it however if it isn’t the case, it is better to prepare for the worst and don’t assume large MTU will be available.
If the content of a characteristic exceeds the ATT MTU size (minus ATT overhead ) then a client must use the read long characteristic operation to fetch the entire content. Otherwise a regular read will read at most the first ATT_MTU - 1 bytes of the characteristic value. It is similar with notification, a server will send at most the first ATT_MTU - 3 bytes of the content of the characteristic value.
For large packets like you describe (8K), I would suggest having a fragmentation algorithm running on the server and do the reassembly on the client. You can send at most MTU - 3 bytes in a notification. By nature, notification is not reliable, you should have some recovery mechanism in place to send again missing blocks.
Thank you all for your reply, I’m not sure if using attributes this is the best approach for this problem, so far is the only I have found.
Just to add some context the idea is stream compressed audio data from a device to the other using BLE 5.1 in prototyping stage and then migrate to BLE 5.2 isochronous channels.
For now I’ll try packet fragmentation and see what speeds are archived.
Note that Mbed OS 6.2 has been released with the latest version of the Cordio stack which is Bluetooth 5.2 certified. However BT 5.2 support isn’t available yet in mbed as we want to make sure it doesn’t increase binary size for all users.
