Bluetooth uses LL_CHANNEL_MAP_REQ PDU in Link Layer Control to negotiate channel mapping.
This issue is related to a Bluetooth feature called Adaptive Frequency Hopping (AFH). When you manually set a channel classification to "bad", then in afh_channel_map selection, that channel will be avoided. The HCI commands associated to AFH should include:
In WICED Studio, you can find the code example related to this topic, which is app.snip.ble.ancs. In the file hcimsgs.h, you can find the following declarations:
HCI_API extern BOOLEAN btsnd_hcic_set_afh_channels (UINT8 first, UINT8 last);
HCI_API extern BOOLEAN btsnd_hcic_write_afh_channel_assessment_mode (UINT8 mode);
HCI_API extern BOOLEAN btsnd_hcic_set_afh_host_channel_class (const UINT8 afhchannelmap[HCI_AFH_CHANNEL_MAP_LEN]);
HCI_API extern BOOLEAN btsnd_hcic_read_afh_channel_assessment_mode(void);
HCI_API extern BOOLEAN btsnd_hcic_read_afh_channel_map (UINT16 handle);
These APIs expose the HCI commands related to AFH, and the commands are defined in Bluetooth Specs. So you may refer to Bluetooth Specs to find out how to use them or how AFH works.
Please note that:
- The minimum BR/EDR channels you can reduce to are 20. Therefore please ensure at least 20 channels are reserved in "good" state when you manually configure the channel classification.
- AFH can be autonomous. The device can collect the assessment of the channels and automatically mark the busy channels as "bad". So you may not need to explicitly configure this.
Sincere regards from C. L.
unfortunately this will not work. I've got feedback from our SW engineers that they have already tested this but without success.
We also caannot find the example you mentioned. We are using WICED 6.4 and there is nowhere any file which contents one of the function call you mentioned. There are only the function declaratuions there in hcimsgs.h, this is available, but no example how to use it.
Here is the comment from our SW Engineers:
I did find these 2 functions (not in header files, but in other chipsets). I added them to our project and it builds, but it doesn’t make a difference:
I tried using all kinds of variations of this but nothing I did made a difference. I called these functions when the BT stack was enabled (at startup when we initialize BLE and all the profiles). Again none of this is documented anywhere so I don’t know if this is right or wrong, we really need to get a hold of someone from Cypress to get answers for this…
Any further kind of information available?
In fact, I agree with you that there are no implementations of these functions in the public versions of WICED SDK. Because AFH doesn't fall in common usage.
If you insist, I suggest you contact your local sales representatives and ask for internal support to see if they can get the implementation libraries for you. Since there are declarations, there should exist implementations.
Or you may try a totally different way. You can use CYW20706 in standard Bluetooth HCI Mode. In this case, it behaves like a standard Bluetooth Controller and will respond to standard Bluetooth commands. So AFH commands will be executed since they are standard Bluetooth commands. While in Application Mode, CYW20706 may not respond to AFH commands because they are not implemented in WICED SDK. But you need to modify your project in greater efforts.
And kindly inform you that, AFH exists separately in BR/EDR or LE. For example, if you want to set channel classification in BR/EDR, you need the following HCI command:
But in LE, you need the following HCI command: