Getting acknowledgement only from single node which is 1st connected
Getting acknowledgement only from single node which is 1st connected
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.
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.
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.
Hello,
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.
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!
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.
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.
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) ?
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 ?
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.
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.
Thank you.
Regards!
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 ?
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!
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 ?
Hi Hung,
Greetings!
1. As per your suggestion we have tried sniffer trace and have taken few trials with 3 different devices.
We have connected only 2 devices at a time and operated 2nd device by connecting app to first device.
Out of these 3 devices 1 is nRF52DK and rest 2 are our devices.
Also we have used nRF Mesh Android App for these trials.
Please find attached Wireshark Capture Log files for your reference and guide us further.
2. Also please note that we are not using any long interrupt handler in our device firmwares
Regards,
Anaya
Hi Anaya,
The sniffer trace you provided didn't track any connection.
You need to select the advertiser before the connection. Inside the Interface menu, there is a dropdown list of all advertiser, you need to choose the one you want to sniff. After that you make the connection from the phone. Please follow the instruction in the sniffer manual. Most important thing is that you can see the connection established in the sniffer trace. In your current traces there are only advertising packet.
Do you see the same issue when you test with our stock light switch example (no modification) ?
