nRF Mesh , sending hundreds of bytes packets to the mesh nodes causes NRF_MESH_EVT_SAR_FAILED

[Stanley Hung]

Hi,

 

I am conducting a mesh test and it contains:

1. An android smartphone,

- running nrf mesh 3.1.7 on github

- sending hundreds of bytes packets to the mesh nodes by “broadcasting”.

2. At least 2 nodes

- using nRF52840DK

- based on nrf5_SDK_for_Mesh_v4.2.0_src  light_switch server

 

The result shows:

1. Only the last provisioned node receives the full set of packets from smartphone.
2. Other nodes report NRF_MESH_EVT_SAR_FAILED in mesh_evt_cb(access.c) unless the total packets is limited to 8 Bytes.

 

Could you help on

1. How to solve NRF_MESH_EVT_SAR_FAILED?
2. We speculated that because the app used the last node as a proxy node, and there is a limitation with the proxy relay in large packets. If yes, is there any way to make the direct broadcasting instead of proxying ?

[Hung Bui]

Hi Stanley, 

I believe the buffer that you may want to try to increase is CORE_TX_QUEUE_BUFFER_SIZE_RELAY (128) in core_tx_adv.c 

You can find how it's called by looking at rx_handle() in proxy.c where the MESH_GATT_PDU_TYPE_NETWORK_PDU is feed into network_packet_in(). 

Inside network_packet_in() packet_relay() will be called if it's the packet to be relayed. And inside that you can find that if the buffer is full you will simply get a Warning level log of "Unable to allocate memory for relay packet" and the packet will be discarded. 

So I believe that if the data to be relayed are queued larger than CORE_TX_QUEUE_BUFFER_SIZE_RELAY they will be just discarded. This is fine if it's normal relay packet as the packet may get relayed by other node. But if it's the proxy node is the only node that has the packet to be relayed it will be discarded. 

This is different from when the proxy node itself want to send a large SAR message. The segmented message will be sent one by one from the source and the relay buffer is not used (because it's the source, not the relay). 

So what you can do is to try increasing CORE_TX_QUEUE_BUFFER_SIZE_RELAY, and also try to increase the connection interval between the phone and the proxy node, so that the data throughput is reduced giving more time for the proxy node to relay the messages. 

[Stanley Hung]

Thank you for your information, and I increased
- CORE_TX_QUEUE_BUFFER_SIZE_RELAY to 512 Bytes, and
- sent 100 bytes (resend 4 times) to group address,
The other nodes receive packet successfully sometimes, and sometimes fails. In this condition, increasing connection interval is not improved obviously.

1) In general, if increasing the RAM buffer in CORE_TX_QUEUE_BUFFER_SIZE_RELAY, to the upmost of a processor, what will be the disadvantage? Or what is the best percentage of RAM size to be allocated for buffer (I assume after proxy command, the RAM will be released, is it?)

2) Will it help by increasing CORE_TX_QUEUE_BUFFER_SIZE_ORIGINATOR in core_tx_adv.c?

[Hung Bui]

Hi Stanley, 

As far as I can see increasing CORE_TX_QUEUE_BUFFER_SIZE_RELAY  wouldn't cause any side effect except for that it would require more RAM and maybe making the latency for sending the originator message longer (just my guess). It's a fixed buffer so this amount of RAM is dedicated for CORE_TX_QUEUE_BUFFER_SIZE_RELAY.

My suggestion is to try  CORE_TX_QUEUE_BUFFER_SIZE_RELAY  at 512 but with only one sendmessage() call at a time. Then you can run a test and check the success rate to decide how many times should you resend. 

2. I don't think CORE_TX_QUEUE_BUFFER_SIZE_ORIGINATOR would help. It's for the message that's originated from the proxy node.