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]

Hard to say;) Are you waiting for "TX_COMPLETE" events (or their newer replacements in latest SDKs) or you just send data as SD call as soon as you have them ready? Also are you sure that time really makes it 10ms? But these things are hard to debug over the forum, that's something you need to find with debugger, logical analyzer, sniffer...

[Hung Bui]

@Nivetha: Note that BLE is a reliable protocol. A packet will be re-transmitted until it's ACKed by the peer. So if you have some interference, packet will be re-transmitted and it can easily take 2 or more connection event to delivery a packet if there are lots of interference , wifi for example. It's not possible to guarantee a hard real time requirement with BLE.

[endnode]

That's why I would expect to see majority of transfers taking 1 connection interval (=10ms) and few being spread over 2/3/... and 0 (once there goes multiple PDUs per interval because interference is gone and stack is flushing all packets from the pipe). Do you agree? Any idea why Nivetha has it shifted on her graph by 1 interval?

[Nivetha]

@Hung Bui: I understand that BLE is a reliable protocol. I'm currently using for a medical application where there should be minimal retransmissions i.e. packets should be received on time for 90-95 percent of the cases. Although this application is not life threatening, it has to trigger other devices such as respiratory support based on the reception of data. Hence, I am looking at how to reduce delays/connection loss etc. @endnode: I got the nrf52 DK to act as a sniffer and trying to debug packet loss, etc. As you said, there could be something wrong with the data packing at the FW level. Looking into it. Thanks for the optimization ideas:)

[Nivetha]

@Hung Bui: I am transmitting samples as Notifications. Are Notifications still Acked by the Link Layer? The BLE specification says that Indications are acknowledged by the GATT layer, while Notifications are not. It also says, that each and every packet is acknowledged and, if necessary, retransmitted by the Link-Layer. Retransmission will persist until either the packet is acknowledged or the link is dropped. This is true regardless of the transport method (Read / Write / Notification / Indication). Please clarify.