Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Data bytes dropped in BLE packets

I use an nRF52833 with nRF SDK 16.0.0. Softdevice is S140 (v7.0.1).

Max MTU size on my device is confured to 247. I have enabled Data Length Extension and set PDU payload length to 251 bytes which is getting negotiated to 251 for both rx and tx channels. 251 bytes includes 4 bytes L2CAP header and 3 bytes ATT header. So, the actual data that sent in each packet is 244 bytes.

When my nRF connects to a Mobile, the MTU size is getting negotiated to 185 bytes. Since I am trying to transmit a large block of data, I am splitting it into chunks of 244 bytes each. Now, when I try to Tx this 244-byte packet over BLE after 185 MTU negotiation, I am observing that only 185 bytes is being transmitted in each chunk and remaining 60 bytes are getting dropped. I am sending this message as a notification and calling sd_ble_gatts_hvx() to send the message with param hvx_params.type = BLE_GATT_HVX_NOTIFICATION. And sd_ble_gatts_hvx() is returning 0 for every chunk.

Why is this happening? I am unable to figure out if this is a limitation of softdevice that it can only send 185 bytes (negotiated MTU size) per chunk? Is there a check on length in the softdevice? Does the softdevice not split the data packet into 2 if input data packet length is more than negotiated MTU size? How am I expected to resolve this issue? Is there some configuration I can enable? Right now, the data chunk length is fixed to 244 in my application and I cannot alter it dynamically.

Please help!

Parents
  • Hi Adarsh,

    When my nRF connects to a Mobile, the MTU size is getting negotiated to 185 bytes. Since I am trying to transmit a large block of data, I am splitting it into chunks of 244 bytes each. Now, when I try to Tx this 244-byte packet over BLE after 185 MTU negotiation, I am observing that only 185 bytes is being transmitted in each chunk and remaining 60 bytes are getting dropped. I am sending this message as a notification and calling sd_ble_gatts_hvx() to send the message with param hvx_params.type = BLE_GATT_HVX_NOTIFICATION. And sd_ble_gatts_hvx() is returning 0 for every chunk.

    There seems to be some logical error in the application in the memory buffer in which your data is allocated and send over hvx call. 

    Irrespective of the MTU size negotiated, all of your data should eventually reach the peer. If you data transmit size is bigger than the MTU size, then the data will be transmitted over many multiple connection events. 

    Can you show me some sniffer log that you are infact transmitting the whole data but receiving only part of it? 

    If air sniffer log confirms that full data is transmitted over multiple connection events, and at the receiving end you are seeing some data drop, then we need to dig a big deeper on how your receiver is handling the incoming data.

Reply
  • Hi Adarsh,

    When my nRF connects to a Mobile, the MTU size is getting negotiated to 185 bytes. Since I am trying to transmit a large block of data, I am splitting it into chunks of 244 bytes each. Now, when I try to Tx this 244-byte packet over BLE after 185 MTU negotiation, I am observing that only 185 bytes is being transmitted in each chunk and remaining 60 bytes are getting dropped. I am sending this message as a notification and calling sd_ble_gatts_hvx() to send the message with param hvx_params.type = BLE_GATT_HVX_NOTIFICATION. And sd_ble_gatts_hvx() is returning 0 for every chunk.

    There seems to be some logical error in the application in the memory buffer in which your data is allocated and send over hvx call. 

    Irrespective of the MTU size negotiated, all of your data should eventually reach the peer. If you data transmit size is bigger than the MTU size, then the data will be transmitted over many multiple connection events. 

    Can you show me some sniffer log that you are infact transmitting the whole data but receiving only part of it? 

    If air sniffer log confirms that full data is transmitted over multiple connection events, and at the receiving end you are seeing some data drop, then we need to dig a big deeper on how your receiver is handling the incoming data.

Children
No Data
Related