Need help to improve Bluetooth Mesh throughput

[aleccontrol]

I am currently using two nRF52832 SDK boards to implement text message exchange with another nRF52832 SDK board via BLE Mesh.

I based my development on the Light Switch example that was included with the Mesh SDK 1.0.0 

One of the board was based on the Lightswitch Client and the other board is based on Lightswitch Server.

I added two opcodes to the original _SET, _GET, _SET_UNRELIABLE and _STATUS. One opcode is called "SEND_COMMAND "and the second opcode is "SEND_RESPONSE".  I avoided building a custom model at this time so that I can avoid any issue with the provisioning. The main purpose is to test the throughput and latency to see if it is useable for a new product that we are developing.

The client board is programmed to send a text string about 15 characters. The opcode "SEND_COMMAND" is appended to the message.opcode together with a data structure that contains the text string and the length. The "access_model_publish() function is called to send out the packet. The command is published to a group address so that all the servers board will receive the command (currently I only have 1 server connected but the plan is to have all servers that subscribed to the group to receive the command in future)

The server board upon receiving the packet will decode the packet and then send a response. The response is sent with the opcode "SEND_RESPONSE" together with a response string of about 20 characters back to the client. The server too send the response using "access_model_publish()" function.

So far the application codes on both the client and server works well when triggering the client once a second to send the command text string and it does receive the response text string from the server most of the time. 

However, when I try to increase the frequency of sending the command the communication seem to choke. The client could barely send and receive more than 2 command/response packets per second before it starts to choke and lose communication. Once the client stop sending the command you can see some of  the previous packets being sent through but could take a few seconds to complete.

Has anyone experienced the same kind of throughput issue as I did? Is there any parameters that I can adjust to increase the throughput? I read somewhere on this forum that it may be possible for a node to send message of up to 24Hz (I assume it means the client could send up to 24 packets a second) but currently I could not even send and receive faster than 2 packets a second.

Hopefully anyone who has gone through the same experience could point me to possible solutions.

Thank you!

[David Edwin]

Can you repeat the test where you reduce the payload to 10 bytes. I think you are triggering the SAR and that will have a substantial impact on throughput.

[aleccontrol]

Thanks I did try with sending command message that is only 4 bytes long and got  response that is also 4 bytes long. It has improved a bit when tried to send two commands every seconds but the communication still chokes when tried to increase the frequency to sending about 4 commands a second. When the communication chokes you can see that the server simply stop responding for a few seconds and then handle the last command it receives.

We are hoping to be able to exchange text messages of possibly between 10 to 100 bytes via BLE Mesh, just like how we normally do via UART. Many control applications make use of such command/response messages to exchange data between devices (e.g. Modbus ASCII or RTU).  BLE Mesh is supposed to be able to handle data payload as large as 300+ bytes, but even when we tested with small packets such as 10 to 15 bytes the delay we experienced frankly is unacceptably high to be useable for command/response message exchange. I hope what I encountered is due to my configuration and not something inherent to BLE mesh.

[David Edwin]

The fastest transfer methods are unreliable and where the application manages the responses and not the lower stack. It appears you are doing this. However verify that you are not using a reliable message. (I have not checked the zip file as I noticed it quite late)

Edited : 4 packets a second is within the capability of the Mesh. 24-20 packets per seconds is possible to be transmitted but there will be a portion of packets lost based on topology. You many need to consider the Nordic Instaburst as well if you want larger bandwidth

Get the statistical data from the stack so you can check if your configuration of queue sizes are ok. i.e. no overflows etc.

You can also check the return codes of the functions where you are sending data to the stack to see if did manage to get to the incoming queues. 

[David Edwin]

statistical information is available through scanner.h -> scanner_stats_get() , this should get you the statistics for the normal(excludes instaburst) mesh channel operations.

Instaburst statistics are available through instaburst_rx.h -> instaburst_rx_stats_get(channel) , you will need to iterate through all the channels you are using.