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

l2cap packet fragment

Hi,

I have been testing l2cap.
Why is it fragmented by softdevice.

 
 +---------------------+                     +---------------------+
 |  PCA10040(nRF52832) |....... L2CAP .......|  PCA10040(nRF52832) |
 |                     |                     |                     |
 |   repeat tx_func()  |                     |                     |
 +---------------------+                     +---------------------+

PCA10040(nRF52832)
SDK15.3
Softdevice S132 v6.1.1


tx_func(){
 static uint8_t send_buf[244];
 static ble_data_t obj;

  memset(send_buf, '0', sizeof(send_buf));
  send_buf[0] = 'S';
  send_buf[sizeof(send_buf)-1] = 'E';
  obj.p_data = send_buf;
  obj.len    = sizeof(send_buf);
  while(NRF_SUCCESS == sd_ble_l2cap_ch_tx(m_conn_handle, local_cid, &obj));
}

Parents Reply Children
  • I was able to reproduce this. Seems like this is how the link layer packets are buffered in the softdevice. If the buffer size is not a multiple of the link layer packet, the last packet going into the buffer will be split in order to optimize the buffer usage. Unfortunately I don't think there's much to do about this, it's not really violating the BLE spec. You can try to set the data payload to 122 bytes. At least when I tested it seemed like the packets did not split. Anyways, event though the packets split, they are still sent during the same connection interval, so it shouldn't really make any difference to the total throughput.

  • Thank you for copying

    I was also investigating.
    All I feel is that the context of tx_func () affects it.
    Calling tx_func () in the BLE_L2CAP_EVT_CH_TX handler reduces the likelihood of fragmentation.
    Conversely, calling tx_func () in a timer handler increases the possibility of fragmentation.

Related