How to avoid delays and retrieve the samples on time ?

[Nivetha]

Sorry if these questions are discussed already. I'm a newbie to Bluetooth project. Let me explain in brief. I have a central and peripheral device. I am transmitting 10samples/10ms (dummy data) through BLE and the central device is receiving those samples and logging it via UART. The connection interval is 10ms(on both sides) and the range is tested for 2metres. I would like to know about how to reduce /avoid delays and receive samples within the interval(same way as transmitted). I logged the data and analysed the following:

Although the disconnections are close to zero, I am observing the delays in the samples.

Platform specifications nrf52840

soft device: s140

Data logged for 15 mins

Where could be the bottleneck? Is it the central device or the UART? How to solve this and reduce the delays. Please help me.

Thanks in advance!

[endnode]

Hi Nivetha,

Your graph looks maybe strange on the first sight but in general you are almost there from my perspective:

• If you use Notifications to send data every 10ms then you should see major load on 10ms line with (possibly as few as possible) dots on 20ms (or even higher in case of some longer disturbance) and 0ms (this one compensates the loss when several packets waits in the stack and get finally transported within single connection interval) lines.
• The fact that you see very similar effect (maybe with too many re-transmissions on +10ms line) but with +10ms offset signals that you either use wrong GATT methods or that some part of the system waste all that.
• It can be inside your FW or it could simply be only by using UART output (how are the data linked between receiving event in your FW and UART driver?) or just simply systematic error on the PC host where you analyze UART serial data.

BLE trace from (e.g. Nordic) sniffer will definitely help to understand if your BLE GATT protocol is optimal, then you can move forward in debugging.

Cheers Jan

[endnode]

If the packet is "lost in radio ether" (meaning that receiving entity doesn't hear it - either because there is some interference and part of the packet looks corrupted, or because it was out of reach end receiver's sensitivity didn't trigger the stack at all or for whatever else reason) then yes, LL will take care about re-transmitting it as long as it gets received by peer or connection time-outs completely. But if ATT/GATT data of Notify method get somehow lost in lower stack and don't reach your app (being that embedded FW on Nordic nRF5x SoC on top of Nordic stack or some other stack like Zephyr or Mynewt or if your app is mobile app sitting on top of Android or iOS API sitting on top of BLE HCI and that sitting on top of low layer BLE stack in the chipset of your phone/tablet etc.) then you have problem. Luckily it seems this is not happening in the wild.