Multiple nodes acknowledgement problem

[Anaya]

Getting acknowledgement only from single node which is 1st connected

[Anaya]

Hello,

Yes as you suggested,It works after retries, but it is very slow. Most of the times it on/off the lamp  after 2nd or 3rd reply and in 1 out of 30 operations not executed at all after 3 reply also, where as the 1st node on which it connects 1st, it works very fast i.e not required to retry.

So that the for other nodes operations it gives very bad user experience.

My requirement is that the operating experience should be same for all nodes in the network. 

Then why it is different for 1st and other nodes as they all are configured in same mesh network.

Is it required to connect to each node separately?

Please  guide and please give the solution as early as possible.

Thank you!

Regards!

[Hung Bui]

Hi Anaya, 

We need to clarify this. 

Let's test without the retry mechanism, how often do you see the issue ? When the issue happened did you see the destination node turn off/on the light (meaning only the ack message was missing) ? 

When you test with the iOS phone do you see the same issue that it takes much longer time to send a command to remote node compare to the proxy node ? 

We need also to test the mesh operation without using the phone/proxy, please try to test using our light switch example, where you press a button on the client it can control the server. This way we can rule out any issue with the phone or the proxy protocol. 

What I'm suspecting here is that the mesh traffic has lots of packet drop, either because of the hardware or because of the interference from other network (wifi, etc) we need to make it clear that the normal mesh operation can work fine before testing with the phone. 

[Anaya]

Hi,

1. Let's test without the retry mechanism, how often do you see the issue ? When the issue happened did you see the destination node turn off/on the light (meaning only the ack message was missing) ? 

• -> without retry mechanism sometimes, on/off server switch on/off the light and not gives acknowledgement, this case occurrs approximately 3-4 times out of 10.
• And say about 6-7 times out of 10, it's on/off the light but does not give acknowledgement

2. When you test with the iOS phone do you see the same issue that it takes much longer time to send a command to remote node compare to the proxy node ? 

•  Need Ito check  will tell about this after sometime.

3. We need also to test the mesh operation without using the phone/proxy, please try to test using our light switch example, where you press a button on the client it can control the server. This way we can rule out any issue with the phone or the proxy protocol. 

•  Checked, it works perfectly without with light switch client without phone.

What I'm suspecting here is that the mesh traffic has lots of packet drop, either because of the hardware or because of the interference from other network (wifi, etc) we need to make it clear that the normal mesh operation can work fine before testing with the phone. 

• I agree with you. It works fine without phone.

Thank you.

Regards!

[Anaya]

Hello,

For the point 2,

When you test with the iOS phone do you see the same issue that it takes much longer time to send a command to remote node compare to the proxy node ? 

• We again checked in nRF mesh app for iOS, we found the same problem. It doesn't show the timeout error, but the lamp on/off not works, its missing packets for the other nodes in the network except 1st node to which it's connected.
• For the 1st connected node it works perfectly without the packet loss.

Also we the same issue in android and iOS application that, for the other nodes in the network the problem is same for configuration messages such as binding app key, publication address etc.

Please give the appropriate solution as soon as possible.

Regards!

[Hung Bui]

Hi Anaya,

Here is the reply from your colleague Madhav that I quote:

We are seeing this issue once in a 10 times in Android application.

Also we have taken trials with iOS application where in we have operated for approximately 200 times and still there was no single occurrence of timeout error.

So what have changed ? It seems to be much worst now. 

What you can do is to test with our light switch example and check if the proxy node has the same issue. Also please try to test using our NRF52 DK just to align the hardware with what we can test here. 

What you described is much worst than what we are observing here, we also see the issue only once in about 10-20 trial, not 6-8 times out of 10. There must be something else that affected this. 

A possibility is that the connection interval on BLE connection to the phone was too small. If it's too small it will occupies the time domain reserved for mesh. Could you try capture a sniffer trace of the connection ? 
Or do you have any long interrupt handler that can cause any affect on the mesh performance ?