How to disable BLE retransmission and how to realize first listening and then adaptive frequency hopping

[Weng Zhuwei]

Hello

1. I want to disable the BLE retransmission mechanism on NRF52840, because this may cause a lot of latency in my application, how can I achieve this?
   
   
2. I see these two functions in the SDK17.0:

   ble_srv_is_notification_enabled 

   ble_srv_is_indication_enabled

   Can I disable retransmission through enabled notification?
3. I want to use SDK17.0 to realize the mechanism of first listening and then adaptive frequency hopping on NRF52840, can it be realized?

Looking forward to your reply！

Thanks a lot!

[ovrebekk]

Hi Weng

1. How do you experience this latency? 

There is no way to disable the link layer retransmission mechanism, this is always be active. 

If you send less data there should be less need for retransmissions, but otherwise there is little you can do. 

2. You can't disable retransmissions on specific characteristics no, but the client can chose to disable notifications or indications on specific characteristics to stop the data flow. This will reduce the need for retransmissions (but also stop incoming data, which might be a problem for your application). 

3. You mean you want to implement your own proprietary protocol instead of using Bluetooth?

Best regards
Torbjørn

[Weng Zhuwei]

Hello

1. I need to transmit 100 bytes of data every 7.5ms, so the requirement for real-time performance is relatively high. If there is data loss in the middle, I want to discard it, rather than increase the delay caused by constant retransmission.

2. Referring to the ST SDK, they can avoid multiple retransmissions by enabling the Flushable_notification flag, so I wonder if you can implement a similar feature with Nordic.

3. I would like to make some optimizations on the standard BLE protocol, as BLE is currently frequency-hopping based on the CSA#2 algorithm, which is used even if there is interference in the channel. We want to first listen which channel has been heavily occupied, and then update the channel map according to the listen results, and then perform frequency hopping.

[ovrebekk]

Hi 

1. There is no such feature in the Nordic stack, unless you use isochronous channels. When using isochronous channels each packet will only be retransmitted a certain number of times, before it is discarded. 

2. This seems to be a proprietary extension to their stack, and not a standard Bluetooth feature. The documentation you link to also indicate this, as they describe how standard BLE works. We don't have a similar feature in our stack. As mentioned above the standard way of doing something like this is to use isochronous channels. 

3. BLE will always change frequency for each connection event, regardless of whether or not there is interference. With the introduction of CSA#2 the channel sequence is more randomized, to avoid interference between multiple Bluetooth links in the area. 

You can't change the channel selection algorithm, but the SoftDevice include a Quality of Service feature that allows you to detect which channels are the most affected by interference. This can be used to update the channel map on your link to avoid using the channels that are most affected. 

For more information about the QoS API please have a look here. 

Best regards
Torbjørn

[Weng Zhuwei]

Hello Torbjørn，

Thanks for you reply.

If I use classic Bluetooth, can I realize the following requirements?

1. Disable retransmission

2. First listening and then adaptive frequency hopping

3. One master connects to seven slaves at the same time

4. Connection interval <= 10ms

5. The amount of data transferred per connection is greater than 100 bytes

6. Different slave sets different connection intervals

[ovrebekk]

Hi 

By classic Bluetooth, do you mean standard Bluetooth LE like we support in the Nordic stacks, or do you mean the older BR/EDR Bluetooth standards?

"Classic Bluetooth" normally refers to the older Bluetooth BR/EDR standards that we don't support in any Nordic devices (more information about this here). 

I think the only way to implement your requirements using Nordic devices is to make your own protocol based on the ESB libraries. Then you have full control over the number of retransmits, channel selection and more. 

The drawback of this method is that you need to develop much more of the RF protocol yourself, and you will not be compliant with non Nordic devices that can not implement the same protocol. 

Best regards
Torbjørn