BLE Fragmentation data loss

[Tbnilsen]

I am using an nRF52840 processor within a Particle Argon IoT module. I am polling a third party BLE peripheral (Shelly relay) for status data once a minute. The data packet that device responds with is 779 bytes long. I am consistently losing 3 bytes of that data.

Using a PC and its BLE, I poll for the exact same data from the peripheral BLE device. I have confirmed that the 3 bytes lost by the Argon device are the 245th, 490th, and 735th bytes. In other words, after the first sent packet, the first byte between each fragment is being lost.

I've reported this to Particle, and they pointed out that the fragmentation is dealt within the Nordic SoftDevice software.

Is this a known Nordic problem? 

The Particle OS does have a BLE software component to it which I believe could potentially be the source to this problem. 

Any insight would be appreciated.

[Vidar Berg]

Thank you for reporting back and providing an explanation to the issue you observed. As you may know, the default att MTU for BLE devices is always 23 bytes. The longer MTU in this case is negotiated between the devices after the connection is established. The payload for a read response can be up to MTU - 1 byte ATT header while for a write or read request it is MTU - 3 bytes.

Softdevice API documentation for future reference

-  sd_ble_gattc_read()

- GATTC Characteristic or Descriptor Value Read

[Tbnilsen]

Hallo Vidar,

any chance I can get a copy of the nRF52840 SoftDevice API doc?

Also, do you have an opinion on how such a discrepancy could arise (other than a direct "it was set wrongly")? Is there something in the fragmentation algorithm that could explain this?

[Vidar Berg]

Hi, 

Unfortunately, we don't have an offline version of the SD API documentation available. I think it's difficult to speculate what the root cause of this issue without some debugging or code review. This is why I initially suggested capturing sniffer trace to analyze the packet exchange on-air. This allows you to verify if the read requests and responses are as expected. If they are, you would know that the bytes are being lost at the application level. 

[Tbnilsen]

Vidar,

When you say the payload for a read response can be up to MTU - 1, does that mean if the negotiated MTU is 247 and the peripheral is sending a response large enough to require fragmentation it's possible to get data fragments (payload) of 246 or less? (I.e. 245,244)? This would certainly explain my problem since the Particle OS layer does not allow packets greater than MTU - 3.