Zigbee reconnection speed for multi-channel is slow

[Dunliang]

Hi，

I am using nRF54L15-DK for Zigbee light_stwitch startup testing. After successfully connecting the development board to the Hub for the first time, I evaluated the time from booting up to reconnecting to the Hub by clicking the RESET button.

After adding the following configuration, the time delay from each boot to successful Zigbee reconnection is about 5 seconds (default configuration is about 1 second):

CONFIG_ZIGBEE_CHANNEL_SELECTION_MODE_MULTI=y
CONFIG_ZIGBEE_CHANNEL_MASK=0x3FE0000

Best Regards
Dwenliang Weng

[Dunliang]

Fullscreen 4645.device_log.txt Download

[2025-05-29 09:34:48.539]
RX：I: nRF5 802154 radio initialized
*** Booting nRF Connect SDK v2.8.0-a2386bfc8401 ***
*** Using Zephyr OS v3.7.99-0bc3393fb112 ***
I: Starting ZBOSS Light Switch example
I: ZBOSS Light Switch example started
I: Production configuration is not present or invalid (status: -1)
I: Zigbee stack initialized

[2025-05-29 09:34:53.371]
RX：I: Unimplemented signal (signal: 56, status: 0)
I: Joined network successfully on reboot signal (Extended PAN ID: 35f8be00b1eb94cc, PAN ID: 0xa88a)

You can see from the device logs that the rejoin process takes a few seconds to wait.

I don't have a sniffing tool, so I can't provide sniffing logs.

[Kazi Afroza Sultana]

Hello,

The device log doesn't really give much information about the problem unfortunately. If you have a nRF52840 Dongle or DK, or nRF5340 DK they can use our nRF Sniffer for 802.15.4.

[Dunliang]

Fullscreen light_switch.log Download

[2025-06-09 09:35:40.560]
RX：I: nRF5 802154 radio initialized
*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
I: Starting Zigbee R23 Light Switch example
I: Zigbee R23 Light Switch example started
I: Production configuration is not present or invalid (status: -1)
I: Zigbee stack initialized

[2025-06-09 09:35:45.371]
RX：I: Unimplemented signal (signal: 56, status: 0)
I: Joined network successfully on reboot signal (Extended PAN ID: 35f8be00b1eb94cc, PAN ID: 0xa88a)

[2025-06-09 09:35:47.398]
RX：I: Found bulb addr: 0 ep: 1

[2025-06-09 10:02:28.029]
RX：II: nRF5 802154 radio initialized
*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
I: Starting Zigbee R23 Light Switch example
I: Zigbee R23 Light Switch example started
I: Production configuration is not present or invalid (status: -1)
I: Zigbee stack initialized
I: Device started for the first time
I: Start network steering
I: Started network rejoin procedure.

[2025-06-09 10:02:57.327]
RX：I: Unimplemented signal (signal: 56, status: 0)

[2025-06-09 10:02:57.917]
RX：I: Unimplemented signal (signal: 55, status: 0)
I: Joined network successfully (Extended PAN ID: 35f8be00b1eb94cc, PAN ID: 0xa88a)
I: Network rejoin procedure stopped as NOT scheduled.

[2025-06-09 10:03:00.005]
RX：I: Found bulb addr: 0 ep: 1

[2025-06-09 10:03:07.320]
RX：I: Bulb not found, try again

[2025-06-09 10:03:12.952]
RX：I: nRF5 802154 radio initialized
*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
I: Starting Zigbee R23 Light Switch example
I: Zigbee R23 Light Switch example started
I: Production configuration is not present or invalid (status: -1)
I: Zigbee stack initialized

[2025-06-09 10:03:17.772]
RX：I: Unimplemented signal (signal: 56, status: 0)
I: Joined network successfully on reboot signal (Extended PAN ID: 35f8be00b1eb94cc, PAN ID: 0xa88a)

[2025-06-09 10:03:19.810]
RX：I: Found bulb addr: 0 ep: 1

light_switch.pcapngThe DK's ID is 0x70d4.Rejion time ranges from [10:03:12] to [10:03:17], approximately 5 seconds.

[Kazi Afroza Sultana]

Hello,

Following is the feedback from the team

NLME-NETWORK-DISCOVERY.request::ScanDuration (in C: #define ZB_DEFAULT_SCAN_DURATION), and 
- aBaseSuperframeDuration (for 2.4GHz)

 

According to the NLME-NETWORK-DISCOVERY.request description, it can be calculated (with default ScanDuration=5) that scanning one channel takes 506 ms. If the user sets a mask containing 9 channels, in the worst case, the ED will have to scan the first 8 channels and only connect to the network on the 9th. Therefore, the connection delay will be 8 * 506 ms, compared to the case where the correct channel is known.

 

In summary, according to what we see in the doc, observing a 4-second increase in network-discovery time is expected behavior