BLE Data Integrity Failures (Out-of-Order Segments)

RE: BLE Data Integrity Failures (Out-of-Order Segments)

Simonr — Thu, 20 Nov 2025 11:50:34 GMT

Noted, I don't really have any further specific suggestions before seeing a sniffer trace to what this could be, but good to know that it's seemingly random. And just to confirm. You don't see this issue when Wi-Fi is not enabled, correct? If so, does your application also support the 5GHz band for Wi-Fi, and is it possible to try this where BLE is alone on the 2.4GHz band while the WI-Fi is still on, but at 5GHz? That way we can see if this is noise on the 2.4GHz band or an issue in the application firmware perhaps.

Best regards,

Simon

RE: BLE Data Integrity Failures (Out-of-Order Segments)

Revanth Mupparaju — Wed, 19 Nov 2025 13:10:47 GMT

Hi Simon,

Regarding the sniffer trace: Unfortunately, we are currently facing a hardware issue with our sniffer setup, so I have not been able to verify the air logs yet. We are arranging for this as soon as possible and will share the traces once available.

Regarding your second question: The issue is not specific to packet A3. It occurs randomly with different packets throughout the transfer. But, 7 out of 10 times we observed for A3 packet.

RE: BLE Data Integrity Failures (Out-of-Order Segments)

Simonr — Mon, 17 Nov 2025 12:29:06 GMT

Hi Revanth

Have you confirmed with a sniffer trace that the data is in fact received correctly, and that this does indeed happen on the client side. If so, can you share how the client handles the received packages?

Does this always happen for packet A3, or is it different every time? I assume that you need some way of ensuring there aren't more than one A2 packet after one another.

Best regards,

Simon

RE: BLE Data Integrity Failures (Out-of-Order Segments)

Revanth Mupparaju — Wed, 12 Nov 2025 04:32:42 GMT

Hi,

I do agree that BLE is fully acked and I am getting NACKS at my node in my case of incorrect data. The issue is at client side. The logs showing the duplicate packet (A1, A2, A2, A4) are not from a BLE sniffer. They are application-level logs printed inside the GATT notification callback on our nRF-based client.

Note that my node is working fine with mobile application. I am facing issue in my client which is also a nrf based device, specifically when the data being transferred is more than 700KB and only few packets will face this issue.
our hypothesis is The controller (we believe) receives A3 correctly. * Due to the heavy Wi-Fi load, the buffer/pointer passed to our GATT callback is corrupted and still points to the old data from A2. * Our application reads this buffer, sees "A2" a second time, and logs the sequence as (A1, A2, A2, ...). * This duplicate packet immediately causes our application-level sfp crc fail (as seen in our log), which breaks our SAR protocol and leads to the SFP Nack Retry and SFP Timeout Retry on the node.

RE: BLE Data Integrity Failures (Out-of-Order Segments)

Susheel Nuguru — Mon, 03 Nov 2025 15:06:21 GMT

Hi,

[quote user=""]if we are expecting packets in sequence of (A1, A2, A3, A4), during error the sequence will be (A1, A2, A2, A4)[/quote]

This is not possible in BLE. BLE is fully acked packets at the controller level so without getting A3, it is not possible to get A4. How are you testing this? Can you show me the BLE air sniffer log to confirm this? Are you relying on serial logs with hardware flow control enabled? if Yes, is it possible you are losing some logs? You can't rely on serial logs if you have not enabled hardware flow control