UNSTABLE NERWORK

RE: UNSTABLE NERWORK

František — Fri, 22 May 2020 14:07:01 GMT

I think I found the problem. When some message was not transfer, openthred resend this message, and total resending spent cca 35seconds(resends + timeouts) and this message was still in buffer. But cappacity of buffer was only 4 messages. So when I lost 4 messages it will stop reciving and transmitting.

RE: UNSTABLE NERWORK

František — Thu, 19 Mar 2020 20:58:07 GMT

I will prepare my project and send you for tests.

RE: UNSTABLE NERWORK

Marjeris Romero — Thu, 19 Mar 2020 12:33:55 GMT

Hi Fran,

Are you building your application with debug config? Can you try to set the log level to debug to get as much information as possible? And can you share these logs with me?

Difficult to know what is happening without more information.

Best regards,

Marjeris

RE: UNSTABLE NERWORK

František — Wed, 18 Mar 2020 10:34:56 GMT

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

RE: UNSTABLE NERWORK

Marjeris Romero — Wed, 18 Mar 2020 10:17:18 GMT

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?

RE: UNSTABLE NERWORK

František — Sat, 07 Mar 2020 12:12:34 GMT

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.

RE: UNSTABLE NERWORK

Marjeris Romero — Thu, 23 Jan 2020 10:02:23 GMT

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

RE: UNSTABLE NERWORK

Rob C — Fri, 17 Jan 2020 16:21:21 GMT

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

RE: UNSTABLE NERWORK

Marjeris Romero — Fri, 17 Jan 2020 12:42:18 GMT

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.

RE: UNSTABLE NERWORK

František — Thu, 16 Jan 2020 19:39:31 GMT

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

Thank you for your support Majeris

RE: UNSTABLE NERWORK

Marjeris Romero — Wed, 15 Jan 2020 14:22:51 GMT

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.

[quote user="fero.masiar"] Now I tested it without my custom board, only moduls and problem still persists.[/quote]

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

RE: UNSTABLE NERWORK

Marjeris Romero — Wed, 15 Jan 2020 14:11:07 GMT

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.

RE: UNSTABLE NERWORK

František — Wed, 08 Jan 2020 17:39:08 GMT

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

RE: UNSTABLE NERWORK

Rob C — Wed, 08 Jan 2020 16:47:50 GMT

Marjeris,

Can you comment on the HFXO accuracy/stability requirements for Thread? The table below mentions proprietary and BLE.

Thanks,

Rob

RE: UNSTABLE NERWORK

František — Thu, 19 Dec 2019 11:00:49 GMT

I don´t thing that problem is in hardware. Now I tested it without my custom board, only moduls and problem still persists. I tested modul Fanstel BT-840, ISP1807-LR Test Board, ebyte e73-2g4m08s1c.

ISP1807-LR

www.insightsip.com/.../isp_ble_DS1807.pdf

https://www.insightsip.com/fichiers_insightsip/pdf/ble/ISP1807/ISP1807_LR_TB_Schematic.pdf

____________________________________________________________________

Fanstel BT-840

https://www.cdiweb.com/datasheets/fanstel/bluenor_bt840_f_e_x_xe_datasheets.pdf

____________________________________________________________________

ebyte e73-2g4m08s1c

http://www.ebyte.com/en/downpdf.aspx?id=445

____________________________________________________________________

This is schematic of my custom board

drive.google.com/open

RE: UNSTABLE NERWORK

František — Thu, 19 Dec 2019 10:48:26 GMT

devices are on desk, max 2 meters apart. To recover I must restart device from power.

RE: UNSTABLE NERWORK

Marjeris Romero — Wed, 18 Dec 2019 12:27:51 GMT

Hi Fran,

Sorry for the late reply here. As far as I understand, the problem does not happen when using the nRF52840 DK? It only happens when using your custom board with the fanstel module? Can you attach your schematics and gerber files of your custom board to this ticket? If the problem is not in software then a hardware review will be the next logical step in this case.

[quote user="fero.masiar"]It possible that modules lost communication with others becouse they are on work desk close to each other and they have too strong tx power?[/quote]

I don't think this is very likely. How close are they to each other?

Another question: what are you doing to recover the devices that go out of the network? Do you need to reset them to attach them to the network again or do they reattach to the network by themselves?

Best regards,

Marjeris

RE: UNSTABLE NERWORK

František — Fri, 13 Dec 2019 14:25:31 GMT

It possible that modules lost communication with others becouse they are on work desk close to each other and they have too strong tx power?

RE: UNSTABLE NERWORK

František — Wed, 11 Dec 2019 16:50:17 GMT

fanstel bt-840

crystal is in board

RE: UNSTABLE NERWORK

Marjeris Romero — Wed, 11 Dec 2019 16:41:30 GMT

Hi Fran,

[quote user="fero.masiar"] Can you use some moduls with chip NRF52840? Becouse this problem not happen on DK board.[/quote]

Which nRF52840 module are you usin? Are you using the module in a custom board? Does the module include an LF crystal or do you use an LF crystal in your board?

Best regards,

Marjeris

RE: UNSTABLE NERWORK

František — Wed, 11 Dec 2019 15:45:38 GMT

drive.google.com/open

this is from nRF5_SDK_for_Thread_and_Zigbee_v3.2.0_9fade31/examples/

projekt which I use is thread/dfu/client

RE: UNSTABLE NERWORK

František — Wed, 11 Dec 2019 15:31:44 GMT

This problem also worked in other project which does not contains dfu. This problem may happen through DFU too. Can you use some moduls with chip NRF52840? Becouse this problem not happen on DK board.

RE: UNSTABLE NERWORK

Marjeris Romero — Wed, 11 Dec 2019 14:39:13 GMT

Hi Fran,

Sorry for the late reply. From the RTT logs it seems something is going wrong with the DFU tranfer and then the device disconnects from the network. What happens if you don't start the DFU transfer right away? Does the device stays in the network without problems until the DFU transfer starts?

Could you share your code with me so I can try to recreate the problem using 3 devices?

Best regards,

Marjeris

RE: UNSTABLE NERWORK

František — Mon, 02 Dec 2019 15:22:03 GMT

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

RE: UNSTABLE NERWORK

Marjeris Romero — Wed, 20 Nov 2019 13:45:47 GMT

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