• State Verified Answer
  • Replies 16 replies
  • Subscribers 73 subscribers
  • Views 4388 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 124053
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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: Sample delays Potential Disconnections

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!

  • 0 in reply to endnode

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

  • 0 in reply to endnode

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

  • 0 in reply to 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.

  • 0 in reply to endnode

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

  • 0 in reply to endnode

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

Related
Terms of service