52840 Bluetooth packet sending Indicates that the length of the packet sending data is much smaller than the actual length to be sent.https://devzone.nordicsemi.com/f/nordic-q-a/111239/52840-bluetooth-packet-sending-indicates-that-the-length-of-the-packet-sending-data-is-much-smaller-than-the-actual-length-to-be-sentNow using 52840(S140_nrf52_7.2.0 protocol stack, SDK:17.1.0) Bluetooth packet sending found that the packet sending data length is far less than the actual length to be sent, I do not know the reason. On the left is the dongle packet capture, anden-USTelligent Community 13Thu, 16 May 2024 11:48:34 GMTRE: 52840 Bluetooth packet sending Indicates that the length of the packet sending data is much smaller than the actual length to be sent.https://devzone.nordicsemi.com/thread/484661?ContentTypeID=1Thu, 16 May 2024 11:48:34 GMT137ad170-7792-4731-bb38-c0d22fbe4515:8516c8c0-a743-47ec-9ae2-5de40931440bEinar Thorsrud<p>Hi,</p> <p>Can you show the code where you send the data so that I can see how you send and the length? Also, can you upload the sniffer trace and not just the screenshot so that we can inspect more packets?</p> <p>Without knowing more, I have some thoughts:</p> <ul> <li>What is the ATT MTU and GAP data length config in your sdk_config.h ? For long noticiations, the ATT MTU needs to be long enough, so try setting&nbsp;NRF_SDH_BLE_GATT_MAX_MTU_SIZE to 247 in your sdk_config.h. To avoid fragmentation (and get better efficiency), you can also use GAP data length externsion by setting&nbsp;NRF_SDH_BLE_GAP_DATA_LENGTH to 251. Lower numbers are also possible.</li> <li>Do you see that only the first part of the data is received by the peer? If so, there is likely an SW issue where you don&#39;t send everyting.</li> <li>Or does this just look strange in the sniffer trace? If so, is there fragmentation going on (it does not look like it, but it would be easier to see with the full trace file).</li> </ul><div style="clear:both;"></div>