BLE Fragmentation data loss

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.

Parents
  • Hello,

    The easiest way to troubleshoot this would likely be by capturing a bluetooth sniffer trace and compare the packet exchange when it works and when it doesn't. Our nRF Sniffer for Bluetooth LE is a low cost option, but it requires that you have a nRF52840 Dongle or one of the other supported boards laying around. Is the code to poll the sensor provided by Particle or is it something you have written. Either way, it would be nice to see the code showing how it is implemented if possible. I'm not aware of any known bugs in the stack that could explain the data loss.

    Best regards,

    Vidar

  • Hi Vidar,

    I've actually done that - the data is moving across BLE correctly. As stated, I used a PC to verify that. I'm now leaning towards the Particle OS layer that interacts with your stack. Their source is open and see that they call hal_ble_gatt_client_read() which I believe is your stack. They limit each call to that to 244 byte buffer. I think they didn't implement the requirements on their end for receiving fragmented packets.

    Do you have any documentation for me where I can read up on how to use your stack and specifically on fragmentation? 

Reply
  • Hi Vidar,

    I've actually done that - the data is moving across BLE correctly. As stated, I used a PC to verify that. I'm now leaning towards the Particle OS layer that interacts with your stack. Their source is open and see that they call hal_ble_gatt_client_read() which I believe is your stack. They limit each call to that to 244 byte buffer. I think they didn't implement the requirements on their end for receiving fragmented packets.

    Do you have any documentation for me where I can read up on how to use your stack and specifically on fragmentation? 

Children
No Data
Related