• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 14 replies
  • Subscribers 63 subscribers
  • Views 11443 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 116497
Options
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)

eyeye

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.

  • 0

    In other word, the LE Data Packet Length Extension does't work.

  • 0

    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.

  • 0

    @Keton, Thanks for your reply! I have successful exchanged the mtu, and the att size is extended.

    Only the PDU Length in Link layer didn't extended.

    In l2cap layer, the long ATT pdu was fragmented into short Link layer pdu.

    That was not the LE Data Packet Length Extension behavior in BLE4.2.

  • 0

    I've assumed that we are talking about ATT MTU because of diagram you've attached.

    Setting BLE_GAP_OPT_EXT_LEN doesn't seem to work but I haven't seen a consumer device with Link Layer packet extension implemented.

    I also checked what setting both BLE_GAP_OPT_EXT_LEN and increasing ATT_MTU will do but only thing I've noticed was additional packet fragmentation if BLE_GAP_OPT_EXT_LEN < ATT_MTU+5. It would be interesting to check how nRF52 central + nrf52 peripheral behaves in such configuration but I have only one nRF52 board at home.

    If you look at the packet timings you are able to send up to ATT_MTU-3 bytes in single connection interval using write request. Compare this to queued writes where it's only possible to send 1 chunk of data per interval because peer ack is needed.

Related