Issues with NCP device at higher data rate recieved from SED

RE: Issues with NCP device at higher data rate recieved from SED

Simonr — Fri, 11 Nov 2022 10:12:21 GMT

Hi again

The easiest would be to run an example that enables CLI and read out the parameters (I.E. the simple_coap_server), but the default parameters should be:

Extended PANID: dead00beef00cafe
PAN ID: 0xabcd
Mesh Prefix: fdde:ad00:beef::
Masterkey: 00112233445566778899aabbccddeeff

Best regards,

Simon

RE: Issues with NCP device at higher data rate recieved from SED

Brian (Geek) — Thu, 10 Nov 2022 13:17:51 GMT

Hello, I have been using Nordic Border Router image given with SDK. The issue which I was talking about occurred while forming network using OpenThread web page. Due to some odd reason my device network was getting reseted.

I would like to know the network parameters used by Nordic to form the Thread Network which supports example given by nRF5 Thread sdk.

RE: Issues with NCP device at higher data rate recieved from SED

Simonr — Thu, 10 Nov 2022 09:09:37 GMT

It's likely that this is an issue with the OTBR-MQTT-SN, and I think you should report it in the issues tab over on that GitHub page. We don't have much experience with it here as it's not an official Nordic border router. How have you set the network name and parameters when setting up the border router on your end?

Best regards.

Simon

RE: Issues with NCP device at higher data rate recieved from SED

Brian (Geek) — Thu, 10 Nov 2022 06:07:39 GMT

Okay here is thing which i have noted.

Whenever i form a network using below parameters on border router, it forms the network with the given credentials.

Custom Parameters:

Network Name:         OpenThreadDemo8
Extended PANID:    1111111122222222
PAN ID:            0xABCD
PassPhrase:           123456
Netwok Key:           00112233445566778899aabbccddeeff
Mesh Prefix:       fdde:ad00:beef::

Paho Config File:

GatewayUDP6Broadcast = ff33:40:fd11:1111:1122:0:0:1

When i run the "sudo wpanctl status " command after forming new network with above credentials it gives the the above parameters like network name channel panid are same. I have configured UDP6Broadcast address accordingly in paho configuration file : GatewayUDP6Broadcast = ff33:40:fd11:1111:1122:0:0:1 . This works fine for 2-3 minute my device are able to communicate everything is going fine.

But after few minutes when i run the "sudo wpanctl status" command it gives me the old parameters such as Network Name= "OTBR-MQTT-SN" but it should give network name "OpenThreadDemo8" instead of "OTBR-MQTT-SN". But at this point of time my devices are still able to communicate somehow.

So can you please tell why are the parameters getting reseted to its default value after few minutes, Because due to this my mesh local prefix is getting changed so i have to again form network with my custom parameters.

And how could i get rid of this issue ?

RE: Issues with NCP device at higher data rate recieved from SED

Brian (Geek) — Wed, 02 Nov 2022 03:26:07 GMT

[quote userid="75734" url="~/f/nordic-q-a/92861/issues-with-ncp-device-at-higher-data-rate-recieved-from-sed/393226"]Again, I think it would be best if you were able to share some log info from your end where you have already reproduced this.[/quote]

Okay i will try to get this at INFO level .

RE: Issues with NCP device at higher data rate recieved from SED

Simonr — Mon, 31 Oct 2022 12:33:03 GMT

Unfortunately we won't be able to set this up to test on our end at the moment, as we have some trouble setting up an OTBR like yours due to firewall issues. Again, I think it would be best if you were able to share some log info from your end where you have already reproduced this.

Best regards,

Simon

RE: Issues with NCP device at higher data rate recieved from SED

Brian (Geek) — Mon, 24 Oct 2022 13:49:28 GMT

I haven't tried it yet because we are having holidays for week.

But logs at info level doesn't give much information in my sleepy end device application. Even if I set log info at debug level I don't get more detailed information regarding thread device connections when it's state changes to disabled.

RE: Issues with NCP device at higher data rate recieved from SED

Simonr — Mon, 24 Oct 2022 10:56:07 GMT

Okay, thank you for the update, we'll need little time to get this set up, but will get back to you when we know. Did you have any luck getting logging info or reproducing this at lower transmit speeds on your end?

Best regards,

Simon

RE: Issues with NCP device at higher data rate recieved from SED

Brian (Geek) — Fri, 21 Oct 2022 09:19:06 GMT

My device are connecting to MQTT-SN gateway which is pre-installed in OTBR setup given by Nordic Border router image.

RE: Issues with NCP device at higher data rate recieved from SED

Simonr — Fri, 21 Oct 2022 07:48:49 GMT

I've built and flashed your example project now, but what have you used to connect the device to exactly? Just the standard mqttsn_sleepy_subscriber example project or some other project/device? I just want to make sure we have as similar set ups as possible here.

Best regards,

Simon

RE: Issues with NCP device at higher data rate recieved from SED

Brian (Geek) — Thu, 20 Oct 2022 06:52:04 GMT

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:

devzone.nordicsemi.com/.../mqttsn_5F00_sleepy_5F00_publisher_5F00_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:

RE: Issues with NCP device at higher data rate recieved from SED

Simonr — Thu, 20 Oct 2022 06:30:12 GMT

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

RE: Issues with NCP device at higher data rate recieved from SED

Brian (Geek) — Wed, 19 Oct 2022 16:18:40 GMT

[quote userid="75734" url="~/f/nordic-q-a/92861/issues-with-ncp-device-at-higher-data-rate-recieved-from-sed/391189"]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? [/quote]

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.

[quote userid="75734" url="~/f/nordic-q-a/92861/issues-with-ncp-device-at-higher-data-rate-recieved-from-sed/391189"]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?[/quote]

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.

RE: Issues with NCP device at higher data rate recieved from SED

Simonr — Tue, 18 Oct 2022 12:12:46 GMT

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

RE: Issues with NCP device at higher data rate recieved from SED

Brian (Geek) — Mon, 17 Oct 2022 10:32:22 GMT

anyone there ?

RE: Issues with NCP device at higher data rate recieved from SED

Brian (Geek) — Sat, 15 Oct 2022 09:22:21 GMT

[quote userid="75734" url="~/f/nordic-q-a/92861/issues-with-ncp-device-at-higher-data-rate-recieved-from-sed/390816"] What was the state prior to this, and what exactly is "state 1"?[/quote]

I meant thread device gets into "OT_DEVICE_ROLE_DETACHED" state, previously it was in in "OT_DEVICE_ROLE_CHILD" state.

[quote userid="75734" url="~/f/nordic-q-a/92861/issues-with-ncp-device-at-higher-data-rate-recieved-from-sed/390816"]If all the data arrives to the NCP correctly without any corruptions, I don't see why it would be an issue on the NCP side of the application, since the SED is the side that is having trouble as far as I can tell.[/quote]

Okay.

[quote userid="75734" url="~/f/nordic-q-a/92861/issues-with-ncp-device-at-higher-data-rate-recieved-from-sed/390816"] Do you see any kind of error when this state change occurs.[/quote]

At the Info level i don't see any sort of error, it just changes is state and reconnect back to thread network in 2-3 seconds.

[quote userid="75734" url="~/f/nordic-q-a/92861/issues-with-ncp-device-at-higher-data-rate-recieved-from-sed/390816"]Can you check whether this state change always happens after a set amount of time, this might be some timer trigging somewhere between 10 and 15 minutes that requires it to stop transmitting, perhaps that it needs to update its status to the network for example[/quote]

Yes this happen every time but the time duration is not specific. Sometimes it happens after hours, sometimes after 30-40 minutes.

[quote userid="75734" url="~/f/nordic-q-a/92861/issues-with-ncp-device-at-higher-data-rate-recieved-from-sed/390816"]A sniffer trace of this occurring might be helpful to narrow down what happens exactly. You can use an nRF52840 DK or Dongle and the nRF Sniffer for 802.15.4 to do this.[/quote]

Below is the Sniffer trace of the issue which i am facing. In the sniffer trace, the issue arises between time slot of 16:43:20 (packet no: 3318) - 16:44:00 (packet no: 39666). There is no communication after time 16:43:24.125260 (packet number: 38879).

Here is sniffer capture:

Parameters used Channel: 11 PAN ID: 0xABCD , masterkey: 00112233445566778899aabbccddeeff

devzone.nordicsemi.com/.../SED_5F00_State_5F00_Disabled1.pcapng

Hopefully you can find issue out of this ?

RE: Issues with NCP device at higher data rate recieved from SED

Simonr — Fri, 14 Oct 2022 13:23:03 GMT

[quote user=""]my SED suddenly changes it's state to 1[/quote]

Sorry, but what do you mean by the state changing to 1? What was the state prior to this, and what exactly is "state 1"?

1. If all the data arrives to the NCP correctly without any corruptions, I don't see why it would be an issue on the NCP side of the application, since the SED is the side that is having trouble as far as I can tell.

2. Can you check whether this state change always happens after a set amount of time, this might be some timer trigging somewhere between 10 and 15 minutes that requires it to stop transmitting, perhaps that it needs to update its status to the network for example? Do you see any kind of error when this state change occurs. A sniffer trace of this occurring might be helpful to narrow down what happens exactly. You can use an nRF52840 DK or Dongle and the nRF Sniffer for 802.15.4 to do this.

Best regards,

Simon