ESP32 Forum

Hi,

this is maybe not the right to place to ask about nimBLE, but the following behaviour on ESP32 doesn't seem me logical.
I try to send data over the function, where I fill before this the buffer with the function. In my case the buffer length is 40 B, the preferred MTU size in octets=256.

After calling the always only the first 20B are send out, but I would expect it would send all 40B with 2 notifications automatically. Did I miss something?

thank you,
Danijel

I would expect it would send all 40B with 2 notifications automatically

Well, that doesn't happen. Notifications/indications are not meant for this. A single notification you trigger may contain as much (attribute) data as fits into the packet, but fragmentation into multiple notification/indication packets is not part of the BLE specification. - In general, a notification is primarily intended to notify the peer that an attribute value has changed, so the peer knows that it should re-read the value.

This sound logical yes, but for what purpose then even the function ble_hs_mbuf_from_flat(const void *buf, uint16_t len) accepts the len > 20? Also when I have tried the bleprph_throughput / blecent_throughput example I would expect that the the whole buffer (which is defined there as 500 B) is send, not only the first 20 B.

So the right way should be to cycle through the buffer and take always only max. 20B, call the ble_gattc_notify_custom and repeat until all data is send?

Notifications/indications are not the only way to transfer data via BLE
As per BLE spec, an attribute value may have a size of up to 512 bytes, and the "mbuf"s are just generic memory blocks you use to transfer data between the application and the BLE stack; hence, the mbuf API has no idea what the memory is going to be used for and how much data would be valid to allow in a given instance.
Additionally, any negotiated MTU size also applies to notifications/indications, so in theory it is possible to send more than 20 bytes in a notification/indication if and while a larger MTU has been established between the peers; this seems to not be used a lot however, which makes sense because you cannot rely on any MTU size being available for a connection, except for the minimum allowed MTU.

cycle through the buffer and take always only max. 20B, call the ble_gattc_notify_custom and repeat until all data is sent?

Yes, that's an approach that can be taken. - But you may run into problems because notifications may be "lost", so the receiver needs a way to detect that one or more data packets are missing, and a way to request re-transmission of the missing data. Indications are acknowledged, so you know if any data sent has reached the receiver; this, however, incurs a heavy "penalty" in bandwidth because after every packet sent, the sender must wait for the acknowledge to arrive before it can send the next packet.

Besides providing the data as an attribute value to be read by the master (up to 512 bytes, see above), "connection oriented channels" (CoC) may be an option to explore: https://gitlab2.cip.ifi.lmu.de/riedlbe/ ... ver/main.c