Issues with NCP device at higher data rate recieved from SED

[Brian (Geek)]

Hello,

My product is developed on mqttsn example of nRF5 SDK for Thread. Current setup is having one SED and one NCP device connected to OTBR ( having Nordic Image). 

So issue arises when i transfer data from  SED at high data rate i.e (1 payload of size 95 bytes/100ms). And i have confirmed from Thread group discussion that a device in network can send data at this rate if there aren't any other devices in the network. So after 10-15 minutes of continuously running my SED  suddenly changes it's state to 1, which causes it to stop transmitting data.

I would like to know the reason behind this sort of behaviour:

1. Is it NCP firmware issue. Do i have to change any parameters or allocate memory blocks in NCP firmware to handle such a fast speed data reception from sleepy device ? Because i think my NCP device gets uninitialized than get initialized again as its in while loop in the NCP firmware. And when my NCP device gets de-initialized due to some issue my SED go to state 1. This could be a possible issue, but i am not sure if this is the case.

Does data rate 100ms have any imapct on NCP device connected to OTBR ? And if yes how to debug or solve ?

2. If it's not a NCP issue, than i would like to know why my SED are getting its state changed to 1 ?

[Simonr]

Hi

Sorry about the late reply. Unfortunately we haven't been able to track down what causes this from your sniffer trace, since it seems like the end device still transmits data to the parent after packet 38879 as well, just not the data you've set it up to transmit, right? 

Would you be able to provide device logs, preferably with increased log level, as that will likely help us see what exactly is going on on the SED application's side?

Best regards,

Simon

[Brian (Geek)]

Simonr said:

it seems like the end device still transmits data to the parent after packet 38879 as well, just not the data you've set it up to transmit, right? 

My end device is transmitting at data rate of 100ms with the help of hardware timer interrupt triggering at 100 ms. When my device gets disabled suddenly (i.e thread state 1), I am executing timer stop function to stop publishing data at 100 ms. So I thought the packets which are getting transmitted (after 38879) could be of re-transmission attempt from mqtt-sn protocol, but that also shouldn't happen because I can see my device state as 1 (disabled) at that point of time as well. 

Simonr said:

Would you be able to provide device logs, preferably with increased log level, as that will likely help us see what exactly is going on on the SED application's side?

My firmware are using multiple peripherals like CLI (thread cmd), QSPI (external flash), SAADC (voltage measurement), TWI (sensor), Hardware Timers (send data at 100ms ), App Timers (3-4 single shot app timers and 2 repeated app timer for maintaining the state machine) and also library such as CJSON to parse the received payload. Can any one of this peripheral create issue ? 

I will try to provide logs but it's difficult to capture logs even at Log level  set to INFO as it goes too fast due to my transmission speed. But will try again to capture that. 

Basic info level log that I can see -

- MQTTSN publish getting acknowledged

- Suddenly thread device state changes to 1 (reason unknown).

- Device continue to publish although it should stop but it doesn't again reason unknown. (as device state is disabled and also I am stopping hardware timer if Thread device state is less than Child state). 

- Than after few 4_5 seconds I get error of memory, can't allocate memory for OT Message returned from otUDPNewMessage function. 

Above is the exact sequence of events I get at info level. But I will try to capture more logs at debug level of I could. 

[Simonr]

One possibility could be to see if this is reproducible at lower transmission speeds as well, as that would make logging easier, and also narrow down the issue. If it is reproducible with lower transmission speeds, we know that the transmission/throughput is not the issue, but rather something else. While if it's not reproducible at lower transmission speeds it might very well be that either end device or parent can't handle the transmit speed you've set.

Best regards,

Simon

[Brian (Geek)]

Okay i will try that as well. 

I freshly downloaded the SDK for Thread and just changed the following things in "mqttsn sleepy publisher" example :

1. Automated the whole mqtt-sn gateway discovery and connection procedure by using flags, so that i don't have to use buttons to perform the same.

2. Used hardware timer instance 3 to generate interrupt every 100 ms and publish custom payload from handler.

3. Had to change the macro given in "mqttsn_client.h" file

  "#define MQTTSN_PACKET_FIFO_MAX_LENGTH            256 "

The following changes in the default example will cause the issue i am talking about in 20-30 minutes.

Here is the sample project which i have created with above steps implemented, just change the macro "MQTTSN_PACKET_FIFO_MAX_LENGTH"  in mqttsn_client.h file in your SDK and run it on nRF52840 DK board.

Here is the zip version of the project:

mqttsn_sleepy_publisher_test.zip

You will see that after device publishes for 20-40 minutes the device state change its state to 1 (disabled) can be verified by putting a break point in state changed callback function as shown below: