Why can not set MAX_MTU_SIZE to 247?

[rolandash]

On 52832, SDK V14.0.0, SD132-5.0

I tried to set NRF_SDH_BLE_GATT_MAX_MTU_SIZE to 247, as from dev-doc i saw that SD132 supports BLE V4.2 DLE.

However it returns:

ble_gatt: sd_ble_gap_data_length_update() (request) on connection 0x0 returned unexpected value 0x13.

When set MAX_MTU_SIZE to 23 this issue disappear.

[rolandash]

Ah thanks a lot @Petter Myhre, for pointing the problem out. I was not quite sure what gap event length was really about. I will have a test about it.

[Petter Myhre]

In short it defines the time reserved for a connection event. It is often set equal to the connection interval, but if you have two links and you want to share the bandwidth between them you could set the event length to half of the connection interval. Let me know if anything is still unclear.

[rolandash]

@Petter Myhre,

Seems bit confusing result from my tests. I changed gap event length to 5, and i got following log:

ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.

ble_gatt: Requesting to update data length to 251 on connection 0x0.

ble_gatt: Data length updated to 27 on connection 0x0.

ble_gatt: max_rx_octets: 27

ble_gatt: max_tx_octets: 27

ble_gatt: max_rx_time: 328

ble_gatt: max_tx_time: 328

ble_gatt: ATT MTU updated to 185 bytes on connection 0x0 (response).

ATT MTU is still 247, and total link count =1, peripheral link count =1 central link count = 0;

Is there any other mistake?

[rolandash]

One question i would like to clarify: is ATT MTU size defined here identical to physical layer packet length? As from the above log, i can see that though ATT MTU is 185, but (physical) data length is actually 27? Is there anyway that i can check the size of physical layer packet size?

I do successfully transfer a packet of 43 bytes in one call but i am not sure if that is because SD does the auto segmentation / re-assemble work that is transparent to me.

[Petter Myhre]

I'm not sure why you only get 27 bytes. You don't get any errors right? Could you share your complete project with me? So I can test it here?

The ATT MTU will typically be 4 bytes less than LL payload. So 247 and 251 is okay.

If you have an ATT MTU of 185 bytes and and a LL payload of 27 bytes the data will be fragmented, sent in smaller packets over the air, and reassembled on the other side.

I don't think you can check the size of LL payload without monitoring the BLE_GAP_EVT_DATA_LENGTH_UPDATE events, see this MSC.