Particle has discontinued development of Particle Mesh, our OpenThread-based mesh networking solution, and will no longer be manufacturing the associated Xenon development board. Particle will continue investing in its other “Gen 3” products, the flagship cellular (Boron) and Wi-Fi (Argon) product lines. Read more about the deprecation here.
In a Particle Mesh network, there are three types of roles a device can take: a gateway, a repeater, or an endpoint. A previous post, Particle Mesh 101, introduces the basic concepts of roles but stops short of suggesting which role a particular device in your network should take.
This post picks up where the last left off. By the end of it, you’ll learn a quick approach to selecting the right role for your device and be introduced to the relationships devices have in Particle Mesh networks.
Roles describe the networking responsibility of a device
Roles define the network and routing responsibilities of a device in your Particle Mesh network, yet assigning a particular role does not limit the functionality of your Argon, Boron, or Xenon. Regardless of their role in the network, all three boards can run custom application code, interface with the peripherals like GPIO, and make Particle Cloud Primitive calls.
The quick approach to selecting a role
Determining the right role for an Argon, Boron, or Xenon is as straightforward as asking yourself what radios are available on each device.
Note: For now, you should exclude counting a Bluetooth radio, since its initial function in Particle Mesh is to provision a device not handle network traffic.
| Boards | Wi-Fi | Cellular | Mesh |
|---|---|---|---|
| Argon | ✔ | ✔ | |
| Boron | ✔ | ✔ | |
| Xenon | ✔ |
Gateways connect disparate networks
As a general rule, if your device features a Wi-Fi or cellular radio in addition to mesh radio, like the Argon or Boron, it’s well-suited for the role of a gateway.
Wi-Fi gateways
For the Argon, the role of a gateway brings the responsibility of routing network traffic between the local mesh network and the Wi-Fi network it is a client of. It handles the additional network management responsibilities of authenticating and provisioning other devices to the mesh network and routes local traffic to the Particle Device Cloud.
Cellular gateways
Whether you have a Boron 2G/3G or the Boron LTE, both versions make for great gateways. A Boron gateway takes on the same responsibilities as an Argon gateway except the Boron connects the local mesh network and a cellular network.
Repeaters & Endpoints
A corollary to the general rule above is that if your device only has a mesh radio, it’s best for the role of a repeater or endpoint — the Xenon is a great example.
As a repeater, the Xenon increases your mesh network size and coverage while keeping costs low — after all, the Xenon is the least expensive of the Particle Mesh boards. As an endpoint, the Xenon can be powered off of a coin cell battery and can enter a sleep state to conserve battery life. When sensors need polling, the Xenon can wake-up and take measurements.
But this raises a big question, which of the two roles — repeater or endpoint — should a Xenon take? To properly answer this question you need to know about a low-level mesh networking concept: device relationships.
A family of device relationships
As you learned, gateways and repeaters have the responsibility to route network traffic in a Particle Mesh network. Because of this responsibility, they need to keep a record of all of the devices on the network. This is done by applying a parent-child metaphor to the devices roles in the network.
In Particle Mesh, gateways and repeaters are considered parent devices and endpoints are child devices. The parent-child relationship is built into the low-level mesh protocol and does not require you to configure anything.
No sleep for parent devices
Parent devices cannot be sleepy because they are responsible for routing traffic. If a parent device goes to sleep, network traffic wouldn’t be able to find a route to its destination and the network would fail.
Naps are allowed for child devices
Child devices (think endpoints) can sleep since they don’t need to route network traffic and therefore don’t need to keep track of all the devices in the network.
For example, a child device that has a sensor attached to it can record sensor values, send them to the cloud, then fall asleep to save power. When more values are needed for the device, it can wake up and record sensor values, rejoin the network and send its readings, and then fall back asleep.
So, if you want your Xenon to enter low-power mode, pick the role of an endpoint; if power isn’t at a premium, you’re probably fine giving your Xenon the role of a repeater.
Now that you know which devices should generally be used for a particular role in Particle Mesh and gained a bit of familiarity with the parent-child relationship between devices, you should have a better sense of the devices you need for your mesh network.
And don’t forget, during the Particle Mesh preorder, hardware prices on all the new hardware are discounted, make sure to get your boards and join the mesh conversation in the forum.
