Implementation of Adaptive Frequency Hopping with nrf5340 and nrf21540

[Piwy]

Hi,

I want to add the implementation of an adaptive frequency Hopping for the BLE to be able to respect the +20 dBm regulation and also to be able to have less noise.

I saw this post :  What's new in Bluetooth 5.3? and i want to know if it's possible with nrf connect sdk 2.4.2 to be able to do it ? 

Is there any example that can help about that ? or internal project ?

Regards,

Pierre-Yves

[PaKa]

It is not possible to be Bluetooth compliant and at the same time comply with the EU definition of Adaptive Frequency Hopping Spread Spectrum. Due to this you will be limited to using 10dBm maximum for use in the EU zone. This is caused by the fact that there are only 3 advertising channels and you would need 5 to be compliant.

[Piwy]

In this document : https://docs.silabs.com/bluetooth/4.0/general/system-and-performance/tx-power-limitations-for-regulatory-compliance-etsi-fcc
They spok about the fact that the channel 39 (advertising) is not limited in dbm, is this wrong ?

[PaKa]

The article states that if you are using Adaptive Frequency Hopping then it won't be limited in dBm. Blueteooth does not comply with the ETSI definition of AFHSS so this doesn't happen. This is why for advertising you have the limit of 10dBm in Europe while for connections you may use higher power, this is due to connections using more channels.

From https://devzone.nordicsemi.com/f/nordic-q-a/105265/improving-ble-immunity-on-nrf52840-with-dynamic-frequency-hopping,

An update and correction to my last reply. BLE is not adaptive by design as defined by ETSI, but we have a QoS module that can be used to enable adaptivity. Since it is the central that decides the channel mapping, it's not always possible to archive proper adaptivity. Thus, advertising will always happen on three channels. No BLE stack is adaptive by design. The Bluetooth spec does not have any requirements for adaptivity. So in case this is needed, it has to be a custom implementation and has to be handles by the application. The peripheral must always do what the central tells it to, including connection parameters and channel map.

If you want to make the solution more resilient then I recommend to look at the QoS module and utilize this feature to map out bad channels. What algorithms will work the best will be depending a lot on the operating environment so this will be something you will have to look at implementing.

[Piwy]

I understood that the AFH is only valid when there are at least 5 channels, but in the article when it talks about advertising channels 37,38 and 39 it remains unclear if it is necessary or not to have 10 dBm because they write : on all channels except of on channel 37 and 38 (physical channels not logical channels) . The output power is limited to 18 dBm on channel 37 and 15.3 dBm on channel 38 in the case of all PHYs. There isn’t any limitation on channel 39 because the upper channel is only used for advertisements, so with the low duty cycle correction advertisements can be sent at full power.
Is there any other article that can be more precise ?

When i saw this post : What's new in Bluetooth 5.3? i understand that before this features it wasn't possible. Then i thought that this feature was implemented in nrf connect.

I will check the QoS module, Do you know any project or exemple of use of this library ?

Regards,

Pierre-Yves

[PaKa]

If you have questions what SiLabs means then you need to ask in their forum. We state you can only use 10dBm while advertising on Bluetooth LE.

The QoS has been around for some time but in the past only the Central could perform the evaluation, the update in 5.3 is that this is now also supported to use the Peripheral for this.

Not sure what samples potentially supports the QoS, potentially open a new ticket for that.