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
  • 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.

Reply
  • 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.

Children
No Data
Related