Multiple nodes acknowledgement problem

[Anaya]

Getting acknowledgement only from single node which is 1st connected

[Hung Bui]

Hi Anaya, 

Please be more specific when asking question. You will get the support faster. 

Please provide us information how you setup the nodes, if they subscribe to anything, how you send the message. What kind of message it is. 

[Anaya]

Good evening Sir,

Ok Sir. I will explain the case :

1. I have created a mesh network where  I have configured 2 nodes say A and B.

2. on A node I have 2 on-off servers and set publication address 0x0001 and 0x0002. The lamp operates ok on hardware.

3. on B node I have 2 on-off servers and set publication address 0x0003 and 0x0004. The lamp operates ok on hardware.

4. I disconnect the network and again reconnect. Then Node A occurred 1st. I got connected to network.

5.  I redirect to a new activity where I have given Lamp1, Lamp2, Lamp3, Lamp4 with on-off buttons.

6. While click on on/off of Lamp1 and Lamp2 then lamp1 operates at hardware and also get onMeshMessageReceived acknowledgment on which I want to show on/off status.

   But when I operate Lamp3 or Lamp4, I didn't get onMeshMessageReceived acknowledgment.

7. But if I connected to node B, then it works exact opposite of point 5.

   That is I got acknowledgment of Lamp4 and Lamp5 but not of Lamp1 and Lamp2 which are configured on node A.

8. My requirement is need to receive every lamp acknowledgment when connected to any node in the network.

Kindly give the solution.

[Dinesh]

Hi Hung

Greetings!

As per your suggestion we tried to debug issue and we are having below observations.

1. We have disabled flash activity and checked. In this case we are experiencing timeout issue

2. Then we have increased 500uSec timer interval, here also we are experiencing timeout issue

3. Then we disabled that 500 uSec timer then also bad luck

Also as per your suggestion we enabled mesh_gatt.c and proxy.c logs and below are observation

1. The node to which android app is connected (proxy_node) shows log for number of request made

Sample logs

a. Request successful

proxy.c 640: RX

proxy.c 571: RX GATT PDU type 0x0, len 20

proxy.c 648: TX Complete

b. Request NOT successful

proxy.c 640: RX

proxy.c 571: RX GATT PDU type 0x0, len 20

Here "proxy.c 648: TX Complete" log is not appearing

So we have decided go further and debug. So we have added log statement to node (end_node) of which status is requested. That node shows that status has been sent successfully.

Request you to please guide further

Note: attaching screenshot of log for your reference

Regards,

Dinesh

[Hung Bui]

Hi Dinesh, 

Thanks for the information. We actually reproduced the issue here even with the light switch server. So most likely it's not what you implemented caused the issue. 
But how often do you see the issue when you get the time out ? Is it what similar to my video ? Like once out of 7-10 times ? 

[Madhav]

Hi Hung,

Greetings !

I am colleague of Dinesh and Anaya. Thanks for your reply and sorry for delayed response.

Please note our observations as below.

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.

Also we have another observation that while connecting to mesh network from Android and iOS application we are seeing below message two times in Android and once in iOS.

Message:- "ble_softdevice_support.c, 104, successfully updated connection parameter"

Please guide us further to resolve this issue.

Madhav,

[Hung Bui]

Hi Madhav, 
We are still investigating the issue. But it's most likely due to interference. 

The main difference between the iOS app and the Android app is that the iOS app re-transmit the packets if it doesn't receive a response. 

Our suggestion for now is to do the same on your Android app (to retry sending message after a few seconds timeout) 

[Anaya]

Hello Sir,

I have checked in iOS app, the retry command goes from the NRF mesh library itself, but in android application it is not implemented.

I want to solve this issue in android application, then where we should implement retry logic, in NRF mesh library for android or in example app?

Please guide us.

[Hung Bui]

Please modify the Android app to send the retry logic. So instead of having a long timeout and wait for the ACK message. You should have shorter timeout (1/3 of the original) and when it timed out, you send a new message. And after 3 times you then can throw the actual timeout to the GUI interface. 

[Anaya]

Hello,

As per your suggestion I tried the retry logic, but it didn't work as expected.

Please suggest some solution.

Thank you.

Regards!

[Hung Bui]

What exactly didn't work ? please describe.
You mentioned before the issue only happens once in 10 times, so with a few retries, it should only happen once in 1000 times or more. 

[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.