How to avoid delays and retrieve the samples on time ?

RE: How to avoid delays and retrieve the samples on time ?

endnode — Mon, 07 Aug 2017 18:16:04 GMT

This is great news and wise decision. That's also the reason why I would be never afraid to use Write or Notify GATT methods on nRF5x with your stack. However there are other products and architectures which make this difficult (e.g. by splitting BLE stack lower then ATT between two microcontrolers with HCI or something similar) or simply are buggy/not so well implemented. So if we speak about (G)ATT data transfer in general we need to be (theoretically) careful...

RE: How to avoid delays and retrieve the samples on time ?

Hung Bui — Mon, 07 Aug 2017 15:12:27 GMT

@Endnode: If the RX buffer on ATT layer is full, the softdevice will NACK the packet on LL. (this happens when you don't fetch the events out of the stack and let them being collected there ) So, no, there will be no situation when your packet is missing on upper layer when on lower layer it's ACKed.

RE: How to avoid delays and retrieve the samples on time ?

Nivetha — Mon, 07 Aug 2017 11:37:30 GMT

Okay. @endnode that's a big explanation. Thank you:)

RE: How to avoid delays and retrieve the samples on time ?

endnode — Mon, 07 Aug 2017 11:29:24 GMT

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.

RE: How to avoid delays and retrieve the samples on time ?

Nivetha — Mon, 07 Aug 2017 11:09:23 GMT

So, when packets are lost in notifications, it will still be retransmitted right?

RE: How to avoid delays and retrieve the samples on time ?

endnode — Mon, 07 Aug 2017 09:53:56 GMT

Yes, every LL packet on BT LE has 1-packet window ack. mechanism meaning that Link Layer doesn't send next packet before indication in opposite direction shows it has received the packet. See how BT LE LL works in any BLE presentation/overview. On GATT layer Notifications are unacknowledged so what can happen is that LL layer in the controller receives it (so signals to the counterpart that all goes fine) but higher ATT/GATT layers are busy or running out of buffers or whatever and packet is lost there. This is real scenario and if you are afraid of it you must use Indications (and Write with Response in opposite direction). However there are no reports that this would ever happen with the stacks out there in the wild so that's why everyone uses Notifications (because it gives you double the bandwidth against "double acked" Indication).

RE: How to avoid delays and retrieve the samples on time ?

Nivetha — Mon, 07 Aug 2017 08:55:06 GMT

@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.

RE: How to avoid delays and retrieve the samples on time ?

Nivetha — Fri, 04 Aug 2017 11:40:50 GMT

@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:)

RE: How to avoid delays and retrieve the samples on time ?

endnode — Fri, 04 Aug 2017 10:28:45 GMT

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?

RE: How to avoid delays and retrieve the samples on time ?

Hung Bui — Fri, 04 Aug 2017 10:09:46 GMT

@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.

RE: How to avoid delays and retrieve the samples on time ?

endnode — Fri, 04 Aug 2017 09:50:30 GMT

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...

RE: How to avoid delays and retrieve the samples on time ?

Nivetha — Fri, 04 Aug 2017 09:45:36 GMT

okay, Thanks! Queuing wrongly is more likely to be the central or the peripheral?

RE: How to avoid delays and retrieve the samples on time ?

endnode — Fri, 04 Aug 2017 09:41:12 GMT

The thing running on top of S140 which you compile into HEX:) It uses GAP&GATT API of the Soft Device and there shouldn't be big space for big mistakes but still you can be queuing the packets wrongly and losing one connection interval... sniffer trace and/or some low-level RTT/UART debug trace showing timer ticks vs. GATT packet calls vs. GATT events' flow should be the way to debug and optimize.

RE: How to avoid delays and retrieve the samples on time ?

Nivetha — Fri, 04 Aug 2017 09:36:02 GMT

What did you refer as FW here?

RE: How to avoid delays and retrieve the samples on time ?

Nivetha — Thu, 03 Aug 2017 17:12:22 GMT

Thanks a lot Jan for clarifying my doubts. At the central device, I used Realterm to connect to the port and logged the data. Then later used some scripts to analyse it.

RE: How to avoid delays and retrieve the samples on time ?

endnode — Thu, 03 Aug 2017 16:19:47 GMT

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