BLE Notifications and MTU Negotiation on Bluetooth 4.0

[clell]

I've managed to successfully increase BLE MTU Size and Data Length on a 52840 to 247 and 251 respectively.

This works fine  with BLE Notifications on a recent MacBook Pro with Bluetooth 4.2 (it negotiates to 247 and 251) and I can transfer 244 bytes at a time

However on an Mac Pro (late 2013) which is Bluetooth 4.2, mtu and data length negotiation, negotiate to 247 and 27 respectively.

When I then try to send a notification of 244 bytes in length, it's truncated to 101 bytes (i.e. an MTU of 104 bytes).

However equally confusing, Bluetooth 4.0 suggests that the MTU size is 23 bytes.

So why:

a) Is Bluetooth 4.0 capable of a large MTU size than expected?

b) Why is data getting truncated at 101 bytes when 244 has been negotiated successfully?

c) How can I get the mtu negotiation in the erf sdk to negotiate the correct size or identify it's a Bluetooth 4.0 device?

Thanks

[clell]

it does appear that changing BLE_GATT_ATT_MTU_DEFAULT to a value other than 23, causes issues with MTU negotiation if the client cannot handle the maximum MTU size requested and replies with a smaller value, this can be found in "on_exchange_mtu_request_evt" in "nrf_ble_gatt.c":

client_mtu = MAX(client_mtu, BLE_GATT_ATT_MTU_DEFAULT);

This can be changed from MAX to MIN for a workaround to solve this.

But I suspect that maybe BLE_GATT_ATT_MTU_DEFAULT should be left at 23 when increasing MTU size (however in my case that causes this  hard fault on negotiation).

Q. So when changing NRF_SDH_BLE_GATT_MAX_MTU_SIZE to 247, should BLE_GATT_ATT_MTU_DEFAULT be changed to match ?

And if not, then any ideas why if NRF_SDH_BLE_GATT_MAX_MTU_SIZE is raised, and BLE_GATT_ATT_MTU_DEFAULT is kept at 23, this happens in "sd_ble_gattc_exchange_mtu_request" in "nrf_ble_gatt.c" with all bluetooth clients (including 4.2) ?

Thanks

[Vidar Berg]

It's interesting that the hardfault appears occur inside the Softdevice, not sure if actually I've seen it before (except for internal SD assertions that makes it trigger it on purpose). Anyway. As you suspected, BLE_GATT_ATT_MTU_DEFAULT is not supposed to be modified.

Would it be possible for you to test the same with the SDK ble_app_uart example? This is one of the SDK examples which is set up to request 247 bytes for the MTU and 251 for data length by default.