This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE relay indication

I have four wearable devices.

Each of them have 50HZ sample rate, and data length is 20Byte. I don't want to lost any data, so I want to use indication instead of notification.

Then I want to know is this possible implement in nRF52832 wiht BLE4.2 without lost any data.

image description

Thanks!

Parents
  • I am not sure if you can handle 4 concurrent connections with that throughput - it is worth checking. If even increasing number of packets per connection interval does not help, i would try using DLE so packet overhead is decreased. Also, you may try lowering connection interval (for nRFs, for android you probably cannot go 7.5ms, not even 10ms...)

    Also, I would stick to notifications. What indication gives you is the application level confirmation that peer received the packet. You don't need that - just check if the transmission buffer is emptied, before sending next packets (search for high throughput examples available here on forum, there are lots of them). Retransmission and low lewel acking is done anyway - after succesfull transmission, packet is deleted from transmission buffer. Using indications will create such an overhead and transmission of useless data, that it will kill that streams anyway.

    Also, be aware that you probably WILL loose (not able to send, so application will know that) data when there are any obstacles that could lower radio performance/range... You may buffer the data in RAM, but only for limited (by amount of ram ofc) time.

Reply
  • I am not sure if you can handle 4 concurrent connections with that throughput - it is worth checking. If even increasing number of packets per connection interval does not help, i would try using DLE so packet overhead is decreased. Also, you may try lowering connection interval (for nRFs, for android you probably cannot go 7.5ms, not even 10ms...)

    Also, I would stick to notifications. What indication gives you is the application level confirmation that peer received the packet. You don't need that - just check if the transmission buffer is emptied, before sending next packets (search for high throughput examples available here on forum, there are lots of them). Retransmission and low lewel acking is done anyway - after succesfull transmission, packet is deleted from transmission buffer. Using indications will create such an overhead and transmission of useless data, that it will kill that streams anyway.

    Also, be aware that you probably WILL loose (not able to send, so application will know that) data when there are any obstacles that could lower radio performance/range... You may buffer the data in RAM, but only for limited (by amount of ram ofc) time.

Children
No Data
Related