This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Zigbee end device unstable problem

I'm using NRF52840 develope a Zigbee end device  over nRF5 SDK v 3.2.0 . In my example there are 10 of nodes and a coordinator( the coordinator with nRF5 SDK v3.2.0 or 4.1.0 ).
There are 2 types fail in some ZED,I'm captured two sections of nrf log ,first log is from some nodes that  leaving the network and never come back, the only way to recover is reboot,when the ZED stop operation the log is break; second log is some node is make rejoin operation after random time.

When I change the ZED  sdk to 4.1,there is other problems.Some ZED lost communication randomly is there.  When I stop the coordinator,some ZED can't chang their state ,these  ZED no beacon requist send ,and send data requist always even there is no ack from the coordinator,so the rejoin operation can't start after the coordinator is recovered.

If using WDT to solve the programe break,where is the best point to feed the WDT counter,because the zigbee stack handle the sleep operation.

  • <info> zboss:  01 00 00 00 01 00 00 00|........
    <info> zboss:  01 00 00 00 DE AD 1A 02|........
    <info> zboss:  47 00 2B 00 2B 08 04 07|G.+.+...
    <info> zboss:  00 00 00 00 ED 94 00 00|........
    <info> zboss:  0C 00 00 00 01 00 00 00|........
    <info> zboss:  DE AD 0E 02 0B 00 11 00|........
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 0E 02 0B 00 12 00|........
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 0E 02 10 00 13 00|........
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 0E 02 10 00 14 00|........
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 0E 02 11 00 15 00|........
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 0E 02 11 00 16 00|........
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 0E 02 11 00 17 00|........
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 0E 02 12 00 18 00|........
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 0E 02 16 00 19 00|........
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 0E 02 17 00 1A 00|........
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 0E 02 17 00 1B 00|........
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 0E 02 18 00 1C 00|........
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 0E 02 1C 00 1D 00|........
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 0E 02 1D 00 1E 00|........
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 0E 02 1D 00 1F 00|........
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 0E 02 1E 00 20 00|...... .
    <info> zboss:  7A 6E 08 03 03 00 00 00|zn......
    <info> zboss:  DE AD 12 02 47 00 2C 00|....G.,.
    <info> zboss:  2B 08 05 07 A5 A8 61 72|+.....ar
    <info> zboss:  E1 36 CE F4 DE AD 16 02|.6......
    <info> zboss:  4E 00 33 00 2B 08 F7 03|N.3.+...
    <info> zboss:  04 00 00 00 00 00 00 00|........
    <info> zboss:  06 00 00 00 DE AD 0E 02|........
    <info> zboss:  47 00 2D 00 7A 6E 75 02|G.-.znu.
    <info> zboss:  05 00 00 00 DE AD 0E 02|........
    <info> zboss:  48 00 2E 00 7A 6E 08 03|H...zn..
    <info> zboss:  03 00 00 00 DE AD 0E 02|........
    <info> zboss:  48 00 2F 00 7A 6E 75 02|H./.znu.
    <info> zboss:  02 00 00 00 DE AD 0E 02|........
    <info> zboss:  48 00 30 00 7A 6E 08 03|H.0.zn..
    <info> zboss:  03 00 00 00 DE AD 0E 02|........
    <info> zboss:  48 00 31 00 7A 6E 08 03|H.1.zn..
    <info> zboss:  03 00 00 00 DE AD 0E 02|........
    <info> zboss:  4A 00 32 00 7A 6E 75 02|J.2.znu.
    <info> app: Joined network successfully
    <info> zboss:  05 00 00 00            |....
    
    
    
    5611.log_2.txt

  • Hello,

    first log is from some nodes that  leaving the network and never come back, the only way to recover is reboot,when the ZED stop operation the log is break; second log is some node is make rejoin operation after random time.

     How do you try to rejoin before the reboot? And in what way do you leave the network in the first place?

    I didn't really understand the second case. And I don't understand the chinese bullet points. Can you please translate them to english?

  • Thank you for your reply!

    The no use bullet points was deleted,   I find the  entrance to edit the first Q&A  board.

    When I using SDK 3.2 with  the multi sensor and cli router example I find the end node 40% lost link.some node was stopped,like program broken and  the log was stopped too,these node need reboot,some node fall in rejoin cycle frequently,these node maybe RF signal problem.

    I think the SDK4.1 maybe have some bug,When the end node lost uplink to coordinator some node  can't chang the state.

  • cai_2020 said:
    When I using SDK 3.2 with  the multi sensor and cli router example I find the end node 40% lost link.some node was stopped,like program broken and  the log was stopped too,these node need reboot,some node fall in rejoin cycle frequently,these node maybe RF signal problem.

     What HW are you running this on? If it is a DK, what version of the DK do you have?

    I tested the 3.2 SDK example now, but I did not see any similar issues. Have you tried to capture a sniffer trace? If not, can you try? You can use the nRF Sniffer for 802.15.4. Save the trace as a .pcapng file (default format), and upload it here. 

    Best regards,

    Edvin

  • Thank you for your test.

    I also tested the basically unchanged multi-sensor example.  I tested 9 end nodes overnight, one  node was offline, and the other 8 nodes were normal.  The reason for being offline is unclear.
          The details of the last test are explained here.  The program is modified based on the multi-sensor example, adding DC voltage sampling and an accelerometer LIS3DH(using the TWI interface non-blocking mode) reading in zb_app_timer_handler,  and reporting XYZ 3 16-bit data (occupying a 64-bit integers).
          I am using E73-2G​​4M08S1C module.  The signal of this module is very poor.  As for why the modification caused instability, it is currently unclear.  I will get some packets using a sniffer.

Related