Closed CrowdedFuzzball closed 1 year ago
Hi,
The coexistence module determines its RF priority based on the current scenario of the wireless protocol. However, certain upper-layer application scenarios of some wireless protocols require a higher priority to ensure stable performance. The coexistence module cannot determine whether the upper-layer application is in one of these scenarios.. As a solution, the two APIs have been provided to allow upper-layer applications to manually specify whether they are in specific scenarios.
Currently, these two APIs have a "type" parameter with support for either ESP_COEX_ST_TYPE_BLE
or ESP_COEX_ST_TYPE_BT
(ESP_COEX_ST_TYPE_WIFI
is not supported). The "status" parameter can be ESP_COEX_BLE_ST_MESH_CONFIG
, ESP_COEX_BLE_ST_MESH_TRAFFIC
, ESP_COEX_BLE_ST_MESH_STANDBY
for BLE and can be ESP_COEX_BT_ST_A2DP_STREAMING
or ESP_COEX_BT_ST_A2DP_PAUSED
for BT.
There are no separate examples of using these two APIs. However, there is a similar usage in the esp-idf master branch that you can refer to.
In components/bt/host/bluedroid/bta/dm/bta_dm_main.c:481
case BTA_COEX_EVT_STREAMING_STARTED:
BTM_ConfigCoexStatus(BTM_COEX_OP_SET, BTM_COEX_TYPE_BT, BTM_COEX_BT_ST_A2DP_STREAMING);
BTM_ConfigCoexStatus(BTM_COEX_OP_CLEAR, BTM_COEX_TYPE_BT, BTM_COEX_BT_ST_A2DP_PAUSED);
break;
case BTA_COEX_EVT_STREAMING_STOPPED:
BTM_ConfigCoexStatus(BTM_COEX_OP_CLEAR, BTM_COEX_TYPE_BT, BTM_COEX_BT_ST_A2DP_STREAMING);
BTM_ConfigCoexStatus(BTM_COEX_OP_CLEAR, BTM_COEX_TYPE_BT, BTM_COEX_BT_ST_A2DP_PAUSED);
break;
It use Vendor HCI Command to send message of setting/clearing coexistence status bit.
If you have any other confusion, feel free to ask.
For more RF coexistence documents, see https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/coexist.html
@esp-lrh Thank you very much for clear explanation!
To be honest I didn't understand how to proper migrate to new APIs.
In our firmware, before sending a BLE signal (remote control emulation via BLE HID), we previously switched the priority of the radio module to BLE, this allowed us to confidently transmit a command to the controlled device.
Before sending BLE command esp_coex_preference_set(ESP_COEX_PREFER_BT);
After sending esp_coex_preference_set(ESP_COEX_PREFER_WIFI);
This way we got stable BLE operation at the moment when it was needed and in other cases priority was given to WiFi
In your example, if we give higher priority to BLE via esp_coex_status_bit_set(ESP_COEX_ST_TYPE_BLE, ESP_COEX_BLE_ST_MESH_TRAFFIC); (is it right?) It’s not clear how then to return priority to Wi-Fi as ESP_COEX_ST_TYPE_WIFI not supported Do we need to simply clearing this flag?
Yes, just clearing the flag!
The previous RF coexistence solution also use time-division multiplexing for Bluetooth and WiFi coexistence. The old API esp_coex_preference_set
is used to adjust the RF usage time ratio between Bluetooth and WiFi.
With the new RF coexistence solution, we can Influence the time ratio by manually setting the status of specific Bluetooth scenarios.
In the current status given, ESP_COEX_BLE_ST_MESH_CONFIG
allows Bluetooth to have highest time rate. So you can use the new APIs just like that:
// Before sending BLE command
esp_coex_status_bit_set(ESP_COEX_ST_TYPE_BLE, ESP_COEX_BLE_ST_MESH_CONFIG);
// After sending
esp_coex_status_bit_clear(ESP_COEX_ST_TYPE_BLE, ESP_COEX_BLE_ST_MESH_CONFIG);
This can achieve similar effects to the previous API.
@esp-lrh Thank you very much!
Answers checklist.
General issue report
Hello!
As I see esp_coex_preference_set is deprecated now.
Are there any examples esp_coex_status_bit_set and esp_coex_status_bit_clear functions? It is not clear how to use the Status field. If it were bool, logic dictates that it should contain 1 for the desired channel to have priority, 0 for not. But the field has dimension uint32_t
Thnx