[NRF 52833] [Bluetooth Mesh] Mising message when hops between node

[Tien_Nguyen]

Hello developers,
I am using nRF52833 chip for Mesh sensor application.

The picture below is my mesh network model.
1. The model includes devices such as Sensor Server, Sensor Client, and other devices in the mesh network.
2. The message is transferred directly from Server to Client (within 10m radius) or from Server - Other Node - Client. TTL (time to live) = 7.
3. Other devices in close proximity (<20cm) will be classified into 1 group. The distance between Server - group 1 - group 2 - Client is respectively 10-7-7-7 (m), Server - group 1 - Client is respectively 10-7-7 (m).
4. The message miss rate is shown in the figure.

I would like to ask if there is a way to improve the chance of message success if the message goes through the nodes in the network.
If you need any information about mesh network configuration, feel free to ask.

More about my project: Zephyr RTOS + nRF Connect SDK 2.0, LPN is not implemented.

Thanks in advance,

[Hieu]

Hi Tien,

Are all nodes in Group 1 and Group 2 relays?

My first guess is that perhaps the network is congested in Group 1 and Group 2, where the nodes are too close, and all relay the same messages at around the same time.

Could you try these tests individually, and let me know what the success rate is like:

• Only one node in Group 1 and only one node in Group 2 serve as a relay
• Test with a message that is not only relay by Group 1 and Group 2 node, but also received by Group 1 and Group 2, and see what the success rate in Group 1 and Group 2 is.
• Decrease TTL to 5

Please also provide a little more information about your network:

• Network Transmit Count and Interval
• Relay Retransmit Count and Interval
• Segment retransmission configurations
• If you use periodic publishing, Publish Period, Publication Interval and Publication Retransmission
• Message size
• How many nodes are there in Group 1 and in Group 2?

Also, are your message going from Server to Client, or the opposite, or both? Your written description contrast with your image a little. This is not important though, since your setup looks same going from both ends to the other.

Hieu

[Tien_Nguyen]

Hieu said:

Only one node in Group 1 and only one node in Group 2 serve as a relay

>In my case the number of devices is unpredictable, so every device must be a relay.

Hieu said:

Test with a message that is not only relay by Group 1 and Group 2 node, but also received by Group 1 and Group 2, and see what the success rate in Group 1 and Group 2 is.

>I'm trying this option

Hieu said:

Decrease TTL to 5

>How will this affect the success %, please explain to me. Because if you increase the number of hops to extend the distance, reducing the TTL in my opinion is not suitable

Hieu said:

• Network Transmit Count and Interval
• Relay Retransmit Count and Interval
• Segment retransmission configurations
• If you use periodic publishing, Publish Period, Publication Interval and Publication Retransmission
• Message size

>Default by example

Hieu said:

How many nodes are there in Group 1 and in Group 2?

>For now the number will be 3, but like I said, the number in each group is unpredictable, it will be random in range 1-3.

Hieu said:

Also, are your message going from Server to Client, or the opposite, or both?

I only do it from Server to Client

[Hieu]

Tien_Nguyen said:

Only one node in Group 1 and only one node in Group 2 serve as a relay

>In my case the number of devices is unpredictable, so every device must be a relay.

Please check this case regardless. This is to rule out whether or not your devices in Group 1 or Group 2 are congesting the network with too many redundant retransmissions.

Tien_Nguyen said:

How will [decreasing TTL] affect the success %, please explain to me. Because if you increase the number of hops to extend the distance, reducing the TTL in my opinion is not suitable

In the network you described, even the Server and Client should be in range of each other (10+7+7), so a TTL of 7 seems much too high.

However, I made that recommendation while forgetting that a Mesh node does not relay the same message more than once. That feature ensures that a too big TTL value will not burden the network too much. Thus, your high TTL should not be the main cause of your low success rate.

Sorry for this.

Tien_Nguyen said:

• Network Transmit Count and Interval
• Relay Retransmit Count and Interval
• Segment retransmission configurations
• If you use periodic publishing, Publish Period, Publication Interval and Publication Retransmission
• Message size

>Default by example

To be sure, is it this sample? Bluetooth: Mesh sensor — nRF Connect SDK 2.0.0 documentation (nordicsemi.com)