Hello Ha, On Fri, Sep 23, 2016 at 11:00:32PM +0700, hathach wrote: > Hi Everyone, > > I am doing throughput testing specifically with notification characteristics > for sending sensor data from nrf52dk to mobile. I use > ble_gattc_notify_custom(buffer, size) without any issues, except when the > buffer is > 20 bytes, it seems to be truncated > https://github.com/apache/incubator-mynewt-core/blob/master/net/nimble/host/ > src/ble_att_clt.c#L74 and mobile app only receive exactly 20 bytes. It is > not a problem at all for application to manage this (breaking into 20 > bytes/packet) or maybe I haven't used the correct API and/or miss something.
The attribute protocol (ATT) doesn't permit fragmentation. Thus, any ATT packet larger than a connection's ATT MTU will be truncated. The specified default ATT MTU is pitifully low: 23 bytes. This allows up to 20 bytes of data in a notification command. If your application needs to send larger ATT packets, it needs to negotiate a greater MTU with its peer. This is accomplished by calling ble_gattc_exchange_mtu() (http://mynewt.apache.org/develop/network/ble/ble_hs/ble_gattc/functions/ble_gattc_exchange_mtu/) I believe the above is sufficient to solve your problem. I include the following paragraph just for completeness. Before any MTU negotation takes place, your application may need to adjust its preferred ATT MTU. The preferred MTU is the number that the application specifies during the MTU exchange. In NimBLE, the default preferred ATT MTU is 240, which I think is suitable for most purposes. If you want a negotiate a smaller MTU, you can reduce the preferred value by calling ble_att_set_preferred_mtu() (http://mynewt.apache.org/develop/network/ble/ble_hs/ble_att/functions/ble_att_set_preferred_mtu/). Currently, the maximum allowed preferred MTU is 240, but this is an artificial limitation that will be lifted in the future. Thanks, Chris
