Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

esp_wifi_config_espnow_rate bug or undocumented calling order (IDFGH-10505) #11751

Closed
3 tasks done
CmosC1CA opened this issue Jun 27, 2023 · 5 comments
Closed
3 tasks done
Assignees
Labels
Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally Type: Bug bugs in IDF

Comments

@CmosC1CA
Copy link

Answers checklist.

  • I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
  • I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
  • I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.0.2-dirty

Operating System used.

Linux

How did you build your project?

Eclipse IDE

If you are using Windows, please specify command line type.

None

Development Kit.

NodeMCU ESP-32S (ESP-WROOM-32)

Power Supply used.

USB

What is the expected behavior?

I should be able to call esp_wifi_config_espnow_rate after esp_wifi_start according to the documentation. (https://docs.espressif.com/projects/esp-idf/en/v5.0.2/esp32/api-reference/network/esp_now.html?highlight=esp_wifi_config_espnow_rate#_CPPv427esp_wifi_config_espnow_rate16wifi_interface_t15wifi_phy_rate_t)

But this is not the case if WIFI_IF_STA and WIFI_PROTOCOL_LR is used.

What is the actual behavior?

The buggy behavior is ONLY present in WIFI_IF_STA mode WIFI_IF_AP works as expected.

This calling order is valid, according to the docs but results in an assert crash, at esp_wifi_config_espnow_rate

ESP_ERROR_CHECK(esp_wifi_start());
ESP_ERROR_CHECK(esp_wifi_set_protocol(WIFI_IF_STA, WIFI_PROTOCOL_LR));
ESP_ERROR_CHECK(esp_wifi_config_espnow_rate(WIFI_IF_STA, WIFI_PHY_RATE_LORA_500K));
ESP_ERROR_CHECK(esp_now_init());

BUT

If you call esp_wifi_config_espnow_rate AFTER esp_now_init it works fine.

ESP_ERROR_CHECK(esp_wifi_start());
ESP_ERROR_CHECK(esp_wifi_set_protocol(WIFI_IF_STA, WIFI_PROTOCOL_LR));
ESP_ERROR_CHECK(esp_now_init());
ESP_ERROR_CHECK(esp_wifi_config_espnow_rate(WIFI_IF_STA, WIFI_PHY_RATE_LORA_500K));

Either this should be fixed, or the documentation should mention that esp_wifi_config_espnow_rate should be called after esp_now_init in case WIFI_IF_STA is used.
But based on that this behavior is not present with WIFI_IF_AP, I would guess that this is a bug.

(Suggestion) Also your example code (https://github.com/espressif/esp-idf/blob/v5.0.2/examples/wifi/espnow/main/espnow_example_main.c) should contain a call to esp_wifi_config_espnow_rate with LORA values, so the users would not have to spend hours to figure out the call order.

Steps to reproduce.

Using WIFI_MODE_STA / WIFI_IF_STA , WIFI_PROTOCOL_LR mode, call esp_wifi_config_espnow_rate with an LR value (WIFI_PHY_RATE_LORA_500K/WIFI_PHY_RATE_LORA_250K) before esp_now_init.

ESP_ERROR_CHECK(esp_wifi_start());
ESP_ERROR_CHECK(esp_wifi_set_protocol(WIFI_IF_STA, WIFI_PROTOCOL_LR));
ESP_ERROR_CHECK(esp_wifi_config_espnow_rate(WIFI_IF_STA, WIFI_PHY_RATE_LORA_500K));
ESP_ERROR_CHECK(esp_now_init());

Debug Logs.

I (723) wifi:mode : sta (78:e3:6d:0b:03:ec)
I (723) wifi:enable tsf
W (723) wifi:invalid rate, need change phy mode to LR
ESP_ERROR_CHECK failed: esp_err_t 0xffffffff (ESP_FAIL) at 0x400d6486

More Information.

Related :
#11595

@CmosC1CA CmosC1CA added the Type: Bug bugs in IDF label Jun 27, 2023
@espressif-bot espressif-bot added the Status: Opened Issue is new label Jun 27, 2023
@github-actions github-actions bot changed the title esp_wifi_config_espnow_rate bug or undocumented calling order esp_wifi_config_espnow_rate bug or undocumented calling order (IDFGH-10505) Jun 27, 2023
@sywxf
Copy link

sywxf commented Aug 11, 2023

`
const wifi_promiscuous_pkt_t *ppkt = (wifi_promiscuous_pkt_t *)buf;
const wifi_ieee80211_packet_t *ipkt = (wifi_ieee80211_packet_t *)ppkt->payload;
const wifi_ieee80211_mac_hdr_t *hdr = &ipkt->hdr;

if (memcmp(&(hdr->addr2), revice_mac, 6) == 0) // 判断为节点时修改RSSI
{
    // ESP_LOGI(TAG, "rssi:%d,add1:" MACSTR "add2:" MACSTR "add3:" MACSTR "add4:" MACSTR "duration_id: %d, frame_ctrl: %d, sequence_ctrl: %d",
    //          rssi, MAC2STR(hdr->addr1), MAC2STR(hdr->addr2),
    //          MAC2STR(hdr->addr3), MAC2STR(hdr->addr4),
    //          hdr->duration_id, hdr->frame_ctrl, hdr->sequence_ctrl);
    rssi = ppkt->rx_ctrl.rssi;
    rate = ppkt->rx_ctrl.rate;`

不管是ap还是站,也不管在esp_now_init();之前还是之后设置LR_500K或者LR_250K,只要能运行,在混杂模式下读出的速率都不是对应的速率, 为什么?我的代码有错误?

@zhangyanjiaoesp
Copy link
Collaborator

@CmosC1CA Thanks for your report, we have identified this issue and have the MR for it, will merge it ASAP.

@espressif-bot espressif-bot added Status: In Progress Work is in progress and removed Status: Opened Issue is new labels Aug 17, 2023
@zhangyanjiaoesp
Copy link
Collaborator

@sywxf 你期望读到的速率是什么?实际读到的速率是什么?你的场景是什么?使用 ESP-NOW 的时候设置为 LR only 模式,然后用 sniffer 抓包得到对应的 rssi 和速率吗?

@espressif-bot espressif-bot added Status: Done Issue is done internally Resolution: NA Issue resolution is unavailable and removed Status: In Progress Work is in progress labels Aug 18, 2023
@sywxf
Copy link

sywxf commented Aug 23, 2023

@sywxf你期望读到的速率是什么?实际读到的速率是什么?你的场景是什么?使用 ESP-NOW 的时候设置为 LR only 模式,然后用 sniffer 抓包得到对应的 rssi 和速率吗?

感谢您的回复,我只是在源码里看到接收回调中可以转换wifi_pkt_rx_ctrl_t类型,其中有rate和rssi,当使用AP设置速率,没有报错,日志输出RATE的值对应设置的速率并不相同,并没有用sniffer抓包.

我期望在速率大于3200bps不丢包的情况下距离越远越好.

@zhangyanjiaoesp
Copy link
Collaborator

@sywxf 因为这个问题已经关闭,而且你的问题和原问题并不相同,请你创建一个新的 ticket 来记录你的问题。

espressif-bot pushed a commit that referenced this issue Sep 21, 2023
1. Fix the LR rate set fail for espnow and 80211 tx
2. Check phy bandwidth when setting espnow peer rate

Closes #11751
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: NA Issue resolution is unavailable Status: Done Issue is done internally Type: Bug bugs in IDF
Projects
None yet
Development

No branches or pull requests

4 participants