Multiple nodes acknowledgement problem

[Anaya]

Getting acknowledgement only from single node which is 1st connected

[Dinesh]

Hi Hung,

Greetings!

I am colleague of Mrs. Anaya, working on nRF52 part.

As suggested by you, we have to debug this issue in more better way so let me introduce myself in this communication.

Please see my reply as below considering your above queries.

1. We have Wi-Fi network in our company with 2.4GHz frequency (auto mode channel).

2. Also please note that yesterday we had trials and have also experienced same thing which you had. At first trial we had good communication response but in next trial it was worst experience.

Here let me understand that if Wi-Fi network is causing for data loss then what can we do to improve this?

3. In our test setup we are using 2 devices under test. However in our lab there are more Bluetooth devices are active say about 8-10 devices which are being used by my colleagues (provisioned with different android devices)

Here let me understand below point as you asked for number of devices.

Is increase in number of devices lead to decrease communication response/performance?

4. We have also test it on nRF52 DK and have also experienced this timeout error

5. We will take trials with logging enabled as you suggested and will let you know the test results.

6. At present we are using SDK 4.0.0 with modified light switch server application.

I think it would be for us better to test using this application as we had more trials with this setup till now.

7. Can you please explain bit more on what do you mean by different environment?

So that it will help us to take trials precisely.

8. One more point which I would like to share with you that. Yesterday we have trials with devices which do not go for flash write operations (to save device status).

Here we have seen improvement in communication but it is not that worth to say that problem is resolved. Here improvement is about 10% only

Thank you so much.

Regards,

Dinesh

[Dinesh]

Hi Hung,

Greetings!

Please note that we have taken trials as suggested by you (with SDK4.0.0).

1. We have taken trials keeping Wi-Fi network On and Off
2. We have enabled log as you told
3. We are also experiencing that proxy node forwards command to end node but at end node it looks like packet is not received
4. Also we have observed that decrypt status for network RX packet is '5' (NRF_ERROR_NOT_FOUND). You can see this log in screenshot as "Net RX decrypt status: 5"

Please see attached screenshot(s) for your reference.

Regards,

Dinesh

[Hung Bui]

Hi Dinesh, 

It's not possible for us to debug based on the log screenshot. I would suggest you to check and confirm that the proxy node sent the packet but the destination node couldn't receive the packet. 

Then the next step is to test normal mesh communication (instead of sending command from the phone, you send the mesh command directly from one node to another node, and check the failure rate of this method). 

My suggestion on testing on different environment is to do the same test at a location with less Wifi (or other RF) traffic. Check for other bluetooth device in the building, if there is a device that keep transmitting all the time at low interval it can cause the problem. So it's important to test on a clean enviroment (try to test outside, in an open area for example) 

Please try to test using more devices in the network. This will improve the redundancy and the packet drop rate will be lower. 

[Dinesh]

Hi Hung,

Greetings!

As you suggested we have taken trials with below setup
SDK: v4.0.0
Client: Stock SDK Light switch application on nRF52DK hardware
Server: Modified SDK Light switch server application on custom hardware/pcb
Mobile App: nRF Mesh App on Android

Trials are as below

1. Indoor trials
a. From Embedded switch client (Client device)
i. 1 Server and 1 client in setup (Client Device -------> 1st Server)
It is observed that there is no data miss with this device.

ii. 2 Server devices and 1 client device (Client Device -------> 1st Server -------> 2nd Server)
Here data miss or timeout issue occurred (data missing rate is around 20%)
We have placed devices in such a way that 2nd server is not operable from client device.
In this case we have observed data miss issue (operated 2nd server) and as per log it is observed that
ACK from end device is received at 1st server but it is not forwarded to client device,

b. From Mobile App
i. 1 Server and 1 client in setup (Client Device -------> 1st Server)
No data loss occurrs as client device (mobile app) is directly connected to end node

ii. 2 Server devices and 1 client device (Client Device -------> 1st Server -------> 2nd Server)
Data missing issue occurred (data missing rate is above 50%).
As per log it is observed that at some time proxy node forwarded command but end node did not received it,
and at some time end node send back ACK command but proxy node did not received it.

2. Outdoor trials
a. From Embedded switch client (Client device)
i. 1 Server and 1 client in setup (Client Device -------> 1st Server)
ii. 2 Server devices and 1 client device (Client Device -------> 1st Server -------> 2nd Server)
It is observed that there is no data miss issue if devices are kept at line of sight.
However if there is change of 2-3 feets change in line-of-sight resulted in 15-20% data missing.

b. From Mobile App
i. 1 Server and 1 client in setup (Client Device -------> 1st Server)
No data loss occurrs as client device (mobile app) is directly connected to end node

ii. 2 Server devices and 1 client device (Client Device -------> 1st Server -------> 2nd Server)
Here data miss or timeout issue occurred (data missing rate is above 50%).

Request you to please provide us possible resolution to this issue.
We are waiting for your positive reply on the same.
Thank you once again for your extended help to us.

Regards,

Dinesh

[Hung Bui]

Hi Dinesh, 

Thanks for the intensive test information.

Could you give more information about the range you achieved in the test ? 

- What was the range achieved in the test outdoor ? Especially the test with 3 devices. 

- Have you tried to test the same with only the nRF52 DK (on both 2 servers) ? The reason for this is to avoid any RF issue on your hardware board. 

The success rate you achieve is much lower that what we observed here. 

Another test you can do is to use the sniffer to track the Mesh packet. If you use this filter: btcommon.eir_ad.entry.type == 0x2a like this: 

You should be able to filter out only ADV mesh packets. 

You can see a successful transaction (turn on or off the light) should be something like this: 

In this device 86:06 is the one who connected to the phone, and the 29:17 was the destination node. 

If it failed either the initial packet from 86:06 would be missing, or the 86:06 is received by the sniffer but couldn't receive by the 29:17. 

By doing the trace we can observe if the problem happen because the proxy node doesn't send packet, or it's the packet was not received by the destination node or both. You can try to leave the sniffer very close to the proxy node.