UNSTABLE NERWORK

[František]

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

[Marjeris Romero]

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

[František]

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?

[František]

Sorry about wrong information I overlooked information that LF crystal is not implemented in these modules. It possible make my problem. 

[Marjeris Romero]

Hi Rob,

The required HFXO accuracy is stated in IEEE 802.15.4-2015 in chapter 12.3.3: 2450 MHz band with an accuracy of ± 40 × 10^-6, so 40 ppm.

[Marjeris Romero]

Hi Fran,

My mistake, I didn't find any LF requirement for Thread 1.1 or 802.15.4, so the LF crystal should not be needed, but it can be added for lower power consumption. I still think it would be a good idea if you could attach your hardware files (please attach layout files as well). If you want me I can make this case private before you attach the files.

František said:

Now I tested it without my custom board, only moduls and problem still persists.

You shouldn't test the modules on their own, they need to be integrated in a proper custom PCB or evaluation board to work properly.

BR,

Marjeris

[František]

I add LF crystal to my board and after test looks like it helped. 

Thank you for your support Majeris

[Marjeris Romero]

OK that's good news,I think I know the reason for this. There are no LF crystal requirement for Thread, but the OpenThread stack use in the SDK is compiled to use the LFCLK. If you don't want to use an external LF crystal, you need to change the LF clock source in sdk_config.h to run with the internal RC oscillator instead.

BR,

Marjeris

Edit: you don't need to actually build the OpenThread stack again to use the RC oscillator, you only need to change the LFCLK source in sdk_config.

[Rob C]

Marjeris,

Can you clarify what needs to be modified in the OpenThread stack source in order to use other than an external LF crystal?  Can the stack tolerate a low accuracy source for LFCLK (like the internal RC) or does it require the LFCLK be synthesized from the external HF crystal?

Thanks,
Rob

[Marjeris Romero]

Hi Rob,

My bad, the Openthread stack actually uses the clock driver from the nRF5 SDK, so you only need to change the clock source in sdk_config.h. There are no LF clock requirement for Thread, so yes you can use the internal RC as the LFCLK source.

Best regards,

Marjeris

[František]

Hi Marjeris,

I add LF crystal to moduls and now I find new bug. 

When I try to test modules during night, in the morning around half modules not communicated.

Describe the module behaviour when stop response:

I have the same led as LED1 on prewiew DK which signalizate that thread is running. This led is still light. (It is make like all is ok)

When I connect to RTT-viewer there is no log which be describe situation. (It is make like all is ok)

I added button which send request message to NCP, but this message has not arrived.

I try to connect to CLI and when module stop response, CLI also dont response. 

Then I must restart module and then it is ok. 

Now I use SDK 3.2 for thread and zigbee.

[Marjeris Romero]

Hi Fran,

 Sorry for the late reply. Did you changed the LF clock source in the sdk_config.h to use an external LF crystal?

[František]

yes, and try it with internatl rc too. I was the same. Problem has occured especially during fast communication