Open xight155 opened 3 months ago
@xight155
Regarding this issue, I need to confirm the following points:
ieee802154_receive_done()
function in ~/esp-idf/components/ieee802154/driver/esp_ieee802154_dev.c
to check if the original RSSI value meets the requirement?static void ieee802154_receive_done(uint8_t *data, esp_ieee802154_frame_info_t *frame_info)
{
// If the RX done packet is written in the stub buffer, drop it silently.
if (s_rx_index == CONFIG_IEEE802154_RX_BUFFER_SIZE) {
esp_rom_printf("receive buffer full, drop the current frame.\n");
} else {
// Otherwise, post it to the upper layer.
frame_info->process = true;
esp_rom_printf("rssi: %d\n", frame_info->rssi);
esp_ieee802154_receive_done(data, frame_info);
}
}
@xieqinan Thank you for the quick reply, we are testing the network (with 2/3 hops) now in a warehouse with a free line of sight.
1.1.2 works well, with a join lqi of 5. I will test the code below, normally I get the Lqi and neighbour table from the control bridge/coordinator
I tested the function with a CB and three nodes (as router), two routers with a distance of 1 meter of another and a router with a distance of 15/16 meters
Router A with mac:404C ----- 1028, RSSI -48 and -87
Distance A and B is 1meter
Router B with mac:5432 -----38f4, RSSI -62 and -101
I think the module batch start with MAC:5432 have a poor/weak RX (I tested several modules starts with 5432). How can I check if the batch with 5432 is a 100% original Espressif C6 module?
Please check the refreshing of the neighbour table (of a router with V1.4.0) and lqi, Lqi is very low compare with a router running with 1.1.2 Zigbee version.
@BaWe155 ,
I think the module batch start with MAC:5432 have a poor/weak RX (I tested several modules starts with 5432). How can I check if the batch with 5432 is a 100% original Espressif C6 module?
I think you can run esptool.py -p /dev/ttyUSB1 flash_id
to get the BASE MAC
, and then verify the MAC address on the OUI page.
Please check the refreshing of the neighbour table (of a router with V1.4.0) and lqi, Lqi is very low compare with a router running with 1.1.2 Zigbee version.
Were the test results for esp-zigbee-sdk v1.4.0 and v1.1.2 generated in the same environment? If so, please modify the ieee802154_receive_done()
function according to the instructions in https://github.com/espressif/esp-zigbee-sdk/issues/418#issuecomment-2324198261 and then provide us with the test results.
Hi @xieqinan,
I will test it, can you check/compare it if there is anything changed with the neighbour table and refreshing of it? I see nodes in the table who are longtime offline and there are better neighbours available.
Hi @xieqinan I checked the Mac bove are original ESP32-C6 modules but a difference of +/- -20dBm, how can I get in the future the modules with a good RX level? maybe ask a colleague about the hardware?
@BaWe155 ,
Does the ESP32C6 have enable the Wi-Fi feature on your test?
how can I get in the future the modules with a good RX level? maybe ask a colleague about the hardware?
Please contact our hardware support team: https://www.espressif.com/en/contact-us/technical-inquiries/hardware-issues.
@BaWe155 ,
Does the ESP32C6 have enable the Wi-Fi feature on your test?
how can I get in the future the modules with a good RX level? maybe ask a colleague about the hardware?
Please contact our hardware support team: https://www.espressif.com/en/contact-us/technical-inquiries/hardware-issues.
We know the issue now, there is something wrong with the matching circuit, thank you
Answers checklist.
IDF version.
IDF 5.1.3
esp-zigbee-lib version.
1.4.0
esp-zboss-lib version.
1.4.0
Espressif SoC revision.
ESP32-C6
What is the expected behavior?
In older zigbee lib versions the LQI was must higher, also in the neighbour tables.
Also the distance >20meter can’t reach any more. Now +/- 15 meter with LQI 0 is max.
What is the actual behavior?
low LQI, distance 5meter with LQI +/- 20
Steps to reproduce.
test
More Information.
No response