COAP Thread Server stops receiving messages at a high rate and with multiple sensors

[Rajendra]

Hello there,

I have developed simple coap client and simple coap server based firmwares on nRF52840. My hardware/software configuration is:

SDK: nRF5_SDK_for_Thread_v0.10.0_e1c3d11
Thread version:OPENTHREAD/g6a15261b-dirty
THREAD Border Router = nRF52840 dev kit.

I am sending data from client to server every 1 min. There are 7 such client sensors. There is a parallel activity to forward this data to gateway device over TWI. I am using a queue to buffer this data. With these activities, Thread server works for 7/8 hours and then stops receiving data but the main loop works fine. i.e TWI works fine. Probably thread is overloaded and crashed.

When I send data after every 2 seconds it works for 15-20 mins.

Possible causes:
1. Two Thread packets arrive at the same time?
2. Thread internal buffer gets full/overwritten abruptly?

Questions:
1. At what rate thread is able to receive messages? What happens when two thread messages arrive at same time.
2. Is there any way to know if the thread is alive or not?

Can you please help me with this?

[haakonsh]

Hey Rajendra,

1. Do you get any error messages?
2. Can you describe your network topology, devices and their network roles?

Best regards,
Håkon. 

[Rajendra]

I do not get any error message. The data receive handler stops printing the log. I have mesh topology. Most of the time server is in leader mode and sensors as a child.

[Rajendra]

I have found that Thread stops receiving data when its state changes to one of following.

0x2E5, 0x2A5, 0x224, 0x264. i.e. state_changed_callback(uint32_t flags, void * p_context) gives these flags values. I have analyzed these values further. 

I am not sure why these states occur and if there are more such problematic states?

Best Regards,

Rajendra

[haakonsh]

Hey Rajendra,

I'm sorry for the late reply.

The common denominator for these four state changes are Role change, RLOC added, and Thread network data changed. I think it is safe to assume that one or more of these state changes are the culprit.

I suggest you force one of the state changes at a time and see if your problem appears.

I can also suggest that you migrate to nRF5 SDK for Thread and Zigbee v1.0.0. 

Cheers,

Håkon.

[Rajendra]

Thank you Håkon,

Yes RLOC added, and Thread network data changed states needs to be focused on. Is there any state machine/source code which shows the step by step formation of thread network? Which would help to understand these states better.

How can I force the state change, is there any way to do it? As I know these states come as a result of thread network formation.

I will try to use Thread V1.0. In 1.0, I could see there are some major improvements.

Regards,

Rajendra