How to log message relay path in Bluetooth Mesh Chat sample (nRF52840DK, NCS v3.0.2)

RE: How to log message relay path in Bluetooth Mesh Chat sample (nRF52840DK, NCS v3.0.2)

Edvin — Mon, 20 Oct 2025 13:06:54 GMT

I understand.

Well, as mentioned, the packet doesn't contain any information of the devices that has relayed it when it arrives. It is only the radio of the receiver that can see the address of the originator, and the last relay node. So if you want to see whether R3 was the one who relayed the packet to GW1, you need to look at the address of the packet. But I guess this was a simplified model. I guess you also want to check something like this:

CN1 -> R1 -> R2 -> R3 -> GW1 = OK Path

CN1 -> R1 -> R3 -> GW1 = NOT OK Path. R1 is within range of R3, and you don't want that.

In that case, the GW1 received the packet from R3 in both cases, and it is not able to see directly whether R2 was involved or not. But that is not possible from GW1. The added challenge is that R2 will probably also get the packet and relay it, but R3 was just able to pick up the packet directly from R1 in one of the cases. So you would need to monitor logs on R3 to see what nodes it can pick up packets from, or you need to monitor the TTL on GW1 to see how many hops the packet has done.

Best regards,

Edvin

RE: How to log message relay path in Bluetooth Mesh Chat sample (nRF52840DK, NCS v3.0.2)

tanmayi — Thu, 16 Oct 2025 05:32:47 GMT

Thanks Edvin for your reply. TTL seems to be a good idea.
To explain further on what I would like to achieve...
I am preparing for a dense network, where Relay will be scattered. I would like to ensure that the message from Client Node follow specific Relay route. If I notice, that my messages are following non-desired path, I would like to move Relay away from those nodes or reduce the transmission power of the Client. For that to happen, I would like to know what is the MAC/Mesh address of earlier Relay that forwarded the message. e.g.

CN1 -> R1 -> R2 -> GW1 = OK Path

CN1 -> R1 -> R3 -> GW1 = NOT OK Path. In that case, I would move R3 away from R1.

CN1 - Client Node
R1/R2 - Relay
GW1 - Gateway

RE: How to log message relay path in Bluetooth Mesh Chat sample (nRF52840DK, NCS v3.0.2)

Edvin — Wed, 15 Oct 2025 14:02:44 GMT

Hello,

There is no information regarding the path of the packet in a Bluetooth Mesh packet.

Since Bluetooth Mesh is a flooding mesh, and not a routed Mesh, so packets don't have a planned route when traversing the network.

In addition, for this to work, the packet would need to include the address of the nodes that are relaying the message. This mean they would have to open the packet and modify it's content before relaying it. But since this is no longer following the mesh specification, then you will end up debugging your own network implementation, rather than the actual Mesh network you are trying to debug.

I ran this by our Bluetooth Mesh team, and they had some ideas on how to approach this. Perhaps the simplest way is to use a fixed TTL for your messages, and when you receive a message, you can look at the TTL (time to live), which will tell you how many relays the packet has traversed. Mapping this against the source of the packets gives some idea of what nodes that are within reach, or how many hops there typically is between two nodes. Note that this may vary from message to message.

But this data needs to be gathered periodically e.g. by the gateway, for you to be able to represent it visually, e.g. every minute or so.

Alternatively, you can turn on logging on the network layer, to print the SRC (source address) and SEQ (sequence number), and print this information from each node over UART. This then needs to be collected, and perhaps parsed using some python script to represent the statistics of your network.

May I ask what exactly you were hoping to find using this debugging? Did you encounter some issues while developing a certain feature?

Best regards,

Edvin