Getting acknowledgement only from single node which is 1st connected
Getting acknowledgement only from single node which is 1st connected
Hi Hung,
Greetings!
Please note my reply to your queries as below
- Could you give more information about the range you achieved in the test ?
For indoor trials: Distance between client device and server devices are about 15 feet and distance between to servers is around 15 feet.
- What was the range achieved in the test outdoor ? Especially the test with 3 devices.
For outdoor trials: Distance between client device and server devices are about 50 feet and distance between to servers is around 15 feet.
- 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.
No we have not conducted trials using nRF52 DK.
So considering this and wireshark filetrs as suggested by you we have taken trials on nRF52 DK.
Details for this setup is as below
Devices:
a. Client Device: Nordic nRF Mesh Android App
b. Server Device: nRF52 DK based modified Light Switch Server (2 nos), distance between this 2 devices is 30 feet
c. Sniffer Device: nRF52 DK based
Setup:
a. As suggested by you, we have kept sniffer near to proxy device to which android app is connected
b. 2 Servers are kept at different locations with distance between them is 30 feet.
Observations:
a. Then we have captured wireshark sniffer log and device RTT log for proxy node.
b. We tried to read and understand wireshark capture and rtt log after timeout issue occurred while operating from android app.
c. If we have read these logs correctly then it is something like below
app send command to proxy node --> proxy node transmitted on mesh network --> proxy node did not receive ACK command
d. Here we do not know whether end node has received command and responded to that command,
so in another trial we tried to catch end node device rtt log.
(sorry to day but it was not possible for us (rtt) log all devices at a time, so we have taken end node rtt log in separate trial).
e. Here we have found that end node has transmitted ACK command to APP
Conclusion:
a. Timeout issue: As per our analysis it looks like that end node transmits ACK but it do not get received by proxy node.
b. Data missing rate: On nRF52 DK based setup, it is observed that data missing rate is 1 in 50 operations and that too without re-transmit logic at android app side.
Request you to please go through attached log file and guide us on the same.
I hope these trials are sufficient for pointing out the possible issue and to provide fix.
Attachements:
TRIAL_1 to TRIAL_3: Wireshark captures and proxy node rtt log
TRIAL_4: End node device rtt log
Regards,
Dinesh
Hi Dinesh,
It's difficult for us to look at the log and figure out what exactly happened. The reason is that we don't know at which period the time out happened.
But from what you described I have some thoughts as follow:
- There is a chance that the proxy is not in listening mode all the time as it supposed to do.
- But the issue could also be the radio hardware you have on the board, as you described the range you are testing is only 15-30 feet and I assume it's the max range you can achieve, then it's too short. With a tuned antenna it can achieve at least 50feet.
- To make sure it's the ACK that didn't receive by the proxy, please clarify that when you see the timeout issue occurred on the phone, you do see that the destination node actually turn off/on as the command from the phone. It's just the phone didn't receive confirmation , but the actual command is executed (the light turn on/off as expected).
The case has been dragging for quite some time. I would strongly suggest you to do the following test:
- Test using only nRF52 DK. I can see that you have at least 2 nRF52 DK. One as the server and one as the sniffer. Please use both of them as server for testing. And please use unmodified light switch server for testing. This test is very important.
- After test #1 is done (both indoor and our door, close range and long range) You can start testing with your hardware, and only use unmodified light switch server firmware for testing.
- After test #2, you can try to increase the TX_POWER of the node, if the power consumption is not a big issue. To change TX_Power, you can modify set_default_broadcast_configuration() to set it to RADIO_POWER_NRF_POS4DBM instead of RADIO_POWER_NRF_0DBM. This would increase the signal power and overcome the interference. But if it's the issue that the proxy doesn't listen, then we should see no change in performance.
Hi Hung,
Greetings!
Please note my reply to your queries as below.
Before that I wish to clear one point related to BLE module is that. We have two types of BLE modules having NRF52832. So we have conducted trials for both modules and observed the result as follows.
test #1 is done (both indoor and our door, close range and long range) You can start testing with your hardware, and only use unmodified light switch server firmware for testing.
Herewith please find following table for data missing observations. Average data missing count indicates that after specified operations data will miss.
| Sr.No. | Node Setup Description | Application | Range | Average Data Missing Count |
| 1 | Bluetooth controller with Old module | Gladiance | Short | 12 |
| Long | 2 | |||
| 2 | Development Board | Gladiance | Short | 32 |
| Long | 12 | |||
| 3 | Bluetooth controller with New module | Gladiance | Short | 165 |
| Long | 15 | |||
| 4 | Development Board | Stock App. | Short | 72 |
| Long | 60 |
Bluetooth controller with New module, Gladiance Application for short range is working very well. Where as Bluetooth controller with Old module with Gladiance Application for long range is working very poor.
test #2, you can try to increase the TX_POWER of the node, if the power consumption is not a big issue. To change TX_Power, you can modify set_default_broadcast_configuration() to set it to RADIO_POWER_NRF_POS4DBM instead of RADIO_POWER_NRF_0DBM.
We'll get back to you on this shortly after concluding on test #1 as we wish to have some safe margin for increasing range.
Regards,
Dinesh
Hi Dinesh,
Thanks for the information. Could you give some more detail about how you calculate the "Average Data Missing Count" , how many trials did you perform to get the result ?
Hi Hung,
Please note that we have taken 25 trials and calculated it's average count.occur
Also can you please let us know, how you have solved timeout issue which occurred at your side (as mentioned by you in below quoted message)?
Hi Anaya,
I just tried here with the stock example and found the same issue. Most likely it's the update on the app caused the issue. I will continue the test and let you know if we find the root cause.
Regards,
Dinesh
