Adaptive Frequency Hopping | Channel Classification | nrf5340

[Tom Lasman]

Dear Nordic Support Team,

I am currently working on a project using the nRF5340 and would like to implement BLE Channel Classification, similar to Adaptive Frequency Hopping in legacy Bluetooth.
Could you please confirm if this feature is supported in SDK 2.8 and, if so, provide an example or guidance on how to use it?

Thanks in advance.

[Asbjørn]

Hi Tom,

Adaptive Frequency Hopping is integrated into the Bluetooth low energy protocol itself by default. 

"In a given environment, some Bluetooth radio channels might not be functioning well, perhaps because interference is impacting them, whereas other channels are working reliably. Over time, the list of reliable channels and unreliable channels may change, as other wireless communication devices in the environment come and go."

https://www.bluetooth.com/wp-content/uploads/2022/05/Bluetooth_LE_Primer_Paper.pdf

https://www.bluetooth.com/wp-content/uploads/2019/03/Bluetooth_5-FINAL.pdf

Bluetooth core spec v6.0 Vol6: Low energy controller, Part B: 4.5.8 General-purpose channel group index selection (Page 3101 and onwards)

Details a bit of the options for customers to define the channel selection algorithm.

Core Spec: https://www.bluetooth.com/specifications/specs/core-specification-6-0/

Core Specification 6.0 Adopted - Bluetooth Technology Website This specification defines the technologies required to create interoperable Bluetooth devices. Note: Errata Correction 25800 is mandatory when claiming compliance to Core Specification 6.0… www.bluetooth.com



Best regards

Asbjørn

[Tom Lasman]

Dear Asbjørn,

Thank you for your response, I appreciate the references provided.

Regarding my original query, I’d like to delve a bit deeper:

Does the Nordic SDK 2.8.0 provide APIs or mechanisms to detect interference on specific channels and dynamically exclude these "bad channels" by adjusting the channel map, or is this entirely managed by the BLE stack's automatic handling?

[tesc]

Hi,

In BLE, there is the possibility to change channel map from the central side, and the peripheral will use the channel map decided by the central.

We do have proprietary QoS feature support in the BLE stack, see SoftDevice Controller for overview of supported features.

Please note that in the case of bad channels, while you risk no data transfer during one connection event, that data will be attempted retransmitted on the next connection event (on the next channel in the channel hopping scheme), and then the next event after that (on another channel), and so on, until successful transfer or supervision timeout. Therefore, the effect of bad channels will be occasional jitter / latency / reduced throughput, but there will not be loss of data.

Regards,
Terje