How I can know a xenon is a repeater or endpoint?

I built a mesh network using argons and xenons. I know the xenon can be repeater or endpoint. But how I can know their roles for each devices? I have read some related question, but still confused it.
Should I use some API function to program their role? For example, I use mesh.publish and mesh.subscribe in xenon A to assign it is a repeater; and the xenon B only programmed using mesh.publish. Or particle boards will automatically recongnize their roles deponds on something I don’t know?

Currently there is no disitinction - all Gen3 devices will act as repeaters, there currently is no pure endnode mode.
Since there is no API to disable the repeater functionality there is also no API to request the obvious.

Thank you for your answer. But I am still confused. So, as you said, all these devices can be repeaters. I found in Google that the function of the transponder in the mesh network is signal relay, which receives the signal and then sends the signal to the next node.
How can I observe that it works like this? This is my confusion.

You can “observe” this by the fact that you device can connect to the mesh gateway indirectly though another Xenon. From within the device, the relay is done within the DeviceOS, most likely within the Nordic SoftDevice software stack. As such, it cannot be “observed” from the user application as there is no API to do so at this time.

1 Like

So, you mean, if I program xenon A using mesh.publish as endpoint, and program the argon using mesh.subscribe as gateway, and don’t program xenon B, the xenon B will act as the repeater? It seems to be in sleep mode, but is actually passing the signal?
What should I do? For example, put the Xenon B between Xenon A and the gateway? So the xenon B will work as repeater?
Sorry about that, but I really confused it. The “device connect to the mesh gateway indirectly through another xenon”, I can’t think of any way to be sure that it works like this.

@sgjtian2, Mesh sub/pub messages are implemented on the mesh network using multi-cast UDP OpenThread messages. That means that ALL nodes in the mesh will get the message but won’t necessarily subscribe to it. So, you don’t have to “program” any repeater stuff since it is all done for you!

A node CANNOT repeat if it is asleep (“sleepy node”). For repeating, a node MUST be awake (always on), much like a gateway cannot be asleep while relaying cloud requests from mesh nodes.

Planning a mesh requires you understanding mesh topology. Endpoint nodes that are expected to sleep cannot be expected to be repeaters so you need one or more always-on repeater nodes if those sleepy nodes can’t reach the gateway directly. Typically, repeater nodes are used for extending mesh range and adding redundant paths to the gateway.

Eventually, an API will exist to designate repeater vs sleep node functionality. This will allow sleepy nodes to NOT try to relay messages when they wake, reducing power consumption.


Thank you very much for answering me patiently.
Sorry I said wrong, I know it’s not sleep mode. May I re-describe my question
This is my assumption. I assign the argon is the gateway, the xenon A is the endpoint. Now, the xenon B is free. I just confuse the role of xenon B in mesh network (not work or repeater).
Devices use msh sub/pub to transceive messages. If the xenon B does not be programmed using mesh sub/pub, the multi-cast message will also visit xenon B, right?
If xenon A thinks it is closer to gateway, the xenon B will not work. If xenon B is located between xenon A and gateway, so xenon A will make xenon B as repeater?
So, the role of xenon B (repeater or not work) depends on its place.
Can I think like that?

@sgjtian2, you are over-thinking this. Mesh nodes always act as repeaters/nodes. You are correct that placement will dictate if a node will repeat another node’s traffic or not. That is up to you and how you lay out your mesh (topology). However, it is not always obvious what a node’s route to the gateway is if you have multiple nodes within range of each other. Until an API allows the setting of repeater vs sleepy node, this will remain a tricky situation.


Thank you so much! I understood.