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

UNSTABLE NERWORK

In past I try to solve this problem:

https://devzone.nordicsemi.com/f/nordic-q-a/51249/state-chaneged-flags

Now I have new informations about this problem.

Using hardware:

Testing on hardware moduls ebyte e73-2g4m08s1c and fanstel bt-840 which contains NRF-52840.

this moduls have onboard or external antenna 

Tested using SDK:[1]

-nRF5_SDK_for_Thread_and_Zigbee_v3.2.0

-nRF5_SDK_for_Thread_and_Zigbee_v3.1.0

Project examples:[2]

-simple coap client

-simple coap server

-dfu client + iot coap

Size of network:[3]

2 - 8 nodes

verifyed through thread topology monitor

nodes are in one room, two furthest distance is 1-6 meters

Count of nodes which is unstable[4]

                    count of unstable  /  size of network

sometimes                          [2 / 2]

sometimes                          [1 / 2]

sometimes                          [1 / 3]

sometimes                          [4 / 5]

sometimes                          [2-3 / 8]

OT DEVICE ROLES:[5]

role                                                   number of role

OT_DEVICE_ROLE_DISABLED     0

OT_DEVICE_ROLE_DETACHED   1

OT_DEVICE_ROLE_CHILD            2

OT_DEVICE_ROLE_ROUTER       3

OT_DEVICE_ROLE_LEADER       4

Time to go UNSTABE[6]

sometimes 1min, sometimes 5min, sometimes more...

1-30 min

Desctiption of behaviour:

-I create THREAD network using some example[1] from SDK [2]

-nodes create THREAD mesh network [3]

-after time[6] some nodes[4] go from ROLE 2 or 3 or 4  to ROLE 1 [5]

-sometimes one of nodes in ROLE 1 go to ROLE 4 and pbobably create separate THREAD mesh network and others join 

-normally nodes which is unstable stay in ROLE 1 unless is device restarted

Other informations:

-is used DRV TIMER 2

-is used UART 2

-set Transmit Power to +8dBm

-thread CLI init is not call becouse need use these pins for my UART

- I use COAP protocol to comunicate with NCP

-NCP never have this problem

  • Hi Fran,

    What do you mean by "the node becomes unstable"? Do you have any sniffer logs when this is happening you can share? I recommend you use a nRF52840 dongle together with our nRF Sniffer for 802.15.4 for Wireshark.

    Best regards,

    Marjeris

  • Unstable means that node go to role OT_DEVICE_ROLE_DETACHED and dont respond on mesages. When I try capture communication, sender node send message, but receiver node ignores all messages. 

  • Change role to OT_DEVICE_ROLE_DETACHED is accompanied by this flags:

    OT_CHANGED_THREAD_ROLE

    OT_CHANGED_THREAD_RLOC_REMOVED

    OT_CHANGED_IP6_MULTICAST_UNSUBSRCRIBED

    OT_CHANGED_BORDER_AGENT_STATE

    Now I use Thread Topology monitor for monitoring connections between nodes.

    I notice some atributes that have node which described above problem 

    -node (role - OT_DEVICE_ROLE_ROUTER) comunicating and participating ind mesh network

    -node become lost all conections with others nodes

    -node deleted from TTM topology

    -after cca 1 min node change role to OT_DEVICE_ROLE_DETACHED

     

    What reasons allow node change role to OT_DEVICE_ROLE_DETACHED?

  • Hi Fran,

    There could be many reasons for a node to go out of the network. The OT_DEVICE_ROLE_DETACHED only means that the node is not currently participating in a Thread network or partition. 

    Can you attach a sniffer trace and debug logs printed when this is happening?

    Best regards,

    Marjeris

  • First wireshark capture with 8 devices without rtt viewer 

    there is captured file from nrf Sniffer

    https://drive.google.com/open?id=15VyOkNNCnNE18K5QsD46eIB6yOcMy4eo

    used 8 devices:

    my_id           address

    NCP       fe80::24d8:36bb:dd04:966e

    6001       fe80::8e8:477b:71a1:7398

    6002       fe80::24c2:a227:dc47:880

    6003       fe80::705b:2f03:7522:38ec

    6004       fe80::dc00:40a1:eeb2:1ee0

    6005       fe80::f0ed:7b27:a883:9803

    6006       fe80::249a:e461:2916:e858

    6008       fe80::a872:13ac:9a7c:345e

    description:

    NCP and device  6008  is started at the begining of capture. Others devices is still turned off. 

    after packet no. 108 start device 6002.

    after packet no. 184 start device 6005

    after packet no. 320 start device 6003

    after packet no. 459 start device 6006

    after packet no. 656 start device 6004

    after packet no. 806 start device 6001

    In this capture I monitor LED1 on all devices. LED1 signalize that:

    -if device is in role 0 or 1 (OT_DEVICE_ROLE_DISABLED     or OT_DEVICE_ROLE_DETACHED than not lights

    -and when is in other role (2, 3, 4 - CHILD, ROUTER, LEADER)  than  lights

    logs:

    dev 6002

    -between packets no. 459-561 LED1 stop lights and approximately after packet 653 start lights 

    -between packets no. 806-947 LED1 stop lights and approximately after packet 1024 start lights 

    -between packets no. 1042-1053 LED1 stop lights and approximately after packet 1095 start lights 

    -between packets no. 1126-1150 LED1 stop lights and approximately after packet 1172 start lights 

    -between packets no. 1192-1204 LED1 stop lights and approximately after packet 1239 start lights 

    -between packets no. 1320-1327 LED1 stop lights 

    dev 6006

    -between packets no. 1095-1113 LED1 stop lights and approximately after packet 1154 start lights 

    -between packets no. 1172-1176 LED1 stop lights and approximately after packet 1208 start lights

    -between packets no. 1239-1242 LED1 stop lights and approximately after packet 1327 start lights

    dev 6003

    -between packets no. 1095-1126 LED1 stop lights and approximately after packet 1157 start lights 

    -between packets no. 1172-1182 LED1 stop lights and approximately after packet 1212 start lights

    -between packets no. 1239-1244 LED1 stop lights and approximately after packet 1327 start lights

    my communication

    between 1240-1320 my communication- my custom hello pacet from NCP to multicast, ncp gets only 3 responses(3/7

    _________________________________________________________________________________

    Second wireshark capture with 3 problem devices (6002, 6006, 6003) with rtt viewer on device 6006

    there is captured file from nrf Sniffer

    https://drive.google.com/open?id=1OK66wFvklKMDjHJFtKwW3QudX78gCb4U

    there is logfrom rtt viewer

    https://drive.google.com/open?id=1FaRMx7uMl0dC5nYdG728E-h64ySr5Zu5

Related