This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

S132 v3 Exchange MTU (LE Data Packet Length Extension does't work)

Hi, I encountered some problem using the S132v3.

With the s132 v3 and sdk12, I want to extend the ble transfer size.

Now I can change the att_mtu to 100, and iphone can write more than 20bytes to the characteristic.

But!!! I found that the LL Data PDU is fragmented by 27bytes, so the pdu length is still not extended.

When I dig deeper with the sniffer, I found that nRF52 response the LL_LENGTH_REQ cmd with LL_UNKNOWN_RSP. It should be LL_LENGTH_RSP with a BLE_EVT_DATA_LENGTH_CHANGED event to the app layer.

I also use sd_ble_opt_set(BLE_GAP_OPT_EXT_LEN, &option), but no effect.

There must be something wrong with the S132 or me... I need you help or a S132 bugfix.

image description

After using the examples from Petter Myhre

GATT Client: nRF52 DK GATT Server: nRF52 DK LL_LENGTH_REQ ---- LL_LENGTH_RSP image description

GATT Client: iPhone6 iOS10 GATT Server: nRF52 DK LL_LENGTH_REQ ---- LL_UNKNOWN_RSP image description

Both the LL_LENGTH_REQ packet are the same, but the s132 doesn't response to iphone.

Parents
  • If your Nordic device is a peripheral you have to ask central for MTU extension via sd_ble_gattc_exchange_mtu_request.

    Be aware that the central device is in complete control of MTU size so it can decline increasing the mtu or can reply with other MTU value.

    So maybe iPhone declines mtu extension request? In case of Android not many phones are compatible and it depends both on hardware and ROM version. That's why you need to implement at least barebones MTU exchange as described in S132v3 migration guidelines.

    I'd suggest using nRF52-DK with nRFConnect software as a test central device as it supports this feature.

Reply
  • If your Nordic device is a peripheral you have to ask central for MTU extension via sd_ble_gattc_exchange_mtu_request.

    Be aware that the central device is in complete control of MTU size so it can decline increasing the mtu or can reply with other MTU value.

    So maybe iPhone declines mtu extension request? In case of Android not many phones are compatible and it depends both on hardware and ROM version. That's why you need to implement at least barebones MTU exchange as described in S132v3 migration guidelines.

    I'd suggest using nRF52-DK with nRFConnect software as a test central device as it supports this feature.

Children
No Data
Related