mudhorn/meshtastic
1
0
Fork 0
mirror of https://github.com/meshtastic/meshtastic.git synced 2025-01-12 14:27:45 -08:00
Code Issues Actions Packages Projects Releases Wiki Activity

convert md to mdx file add truncate
Some checks are pending
CI / quality (push) Waiting to run
Details
CI / build (push) Waiting to run
Details

Browse source
This commit is contained in:
rcarteraz 2024-11-14 10:04:15 -07:00
parent 87ed319954
commit 7ee785052c
2 changed files with 14 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
blog/2024/November/2024-11-10-choosing-a-device-role.md → blog/2024/November/2024-11-10-choosing-a-device-role.mdx
View file

@ -11,6 +11,8 @@ image: "/design/web/social-preview-1200x630.png"
When setting up your Meshtastic network, configuring the correct Role for each device can be crucial for optimizing performance and ensuring reliable communication. Conversely, the pitfalls of choosing the incorrect Role can lead to congestion and poor performance on your mesh. In this post, we'll explore why you might choose certain device roles and avoid others.
{/* truncate */}
## What is a device Role?
A device role in Meshtastic defines the primary function of a device within the network. Each role is tailored to specific usage and helps in managing the network and the behavior of the device more efficiently. Here are some of the common device roles to consider:
@ -19,22 +21,21 @@ A device role in Meshtastic defines the primary function of a device within the
The defacto role for devices is the `CLIENT` role. This is a flexible, general purpose role for devices which should serve the overwhelming majority of use cases. When in doubt about what role you should go with, simply sticking with Client is a safe bet.
Despite the apparent baggage of the term *Client* in some technological contexts, Clients in Meshtastic do actually repeat / route messages. Unfortunately in the past this has caused some confusion, landing some individuals to incorrectly choose the `ROUTER` role.
Despite the apparent baggage of the term _Client_ in some technological contexts, Clients in Meshtastic do actually repeat / route messages. Unfortunately in the past this has caused some confusion, landing some individuals to incorrectly choose the `ROUTER` role.
### Client Mute
The `CLIENT_MUTE` role is similar to the `CLIENT` role but with one key difference: it does not repeat or route messages. This role is ideal for devices that are intended to be used in areas with high network traffic where additional message routing could cause congestion. By using the `CLIENT_MUTE` role, you can ensure that the device will only send and receive its own messages without contributing to network traffic.
The `CLIENT_MUTE` role is similar to the `CLIENT` role but with one key difference: it does not repeat or route messages. This role is ideal for devices that are intended to be used in areas with high network traffic where additional message routing could cause congestion. By using the `CLIENT_MUTE` role, you can ensure that the device will only send and receive its own messages without contributing to network traffic.
This role is also highly recommended if you are a mesh enthusiast with multiple devices. Select one of your devices to be a `CLIENT` and set the rest to `CLIENT_MUTE` to keep your airtime usage more responsible.
### Router and Repeater
The `ROUTER` role is designed for devices which are intended to primarily route messages to other devices on the mesh. This role is ONLY suitable for stationary devices placed in extremely strategic locations to act as unofficial hubs for routing packets on the mesh. Routers focus on relaying messages from other devices by _cutting in line_ before other nodes have a chance to rebroadcast a message, making them key for extending the range and reliability of your mesh. Additionally Routers *always* rebroadcast, whereas most other roles potentially choose to forego rebroadcasting if they hear a neighbor rebroadcasting first.
The `ROUTER` role is designed for devices which are intended to primarily route messages to other devices on the mesh. This role is ONLY suitable for stationary devices placed in extremely strategic locations to act as unofficial hubs for routing packets on the mesh. Routers focus on relaying messages from other devices by _cutting in line_ before other nodes have a chance to rebroadcast a message, making them key for extending the range and reliability of your mesh. Additionally Routers _always_ rebroadcast, whereas most other roles potentially choose to forego rebroadcasting if they hear a neighbor rebroadcasting first.
Another default behavior of Routers is that the device tries to save as much power as possible by attemtping to sleep as well as send telemetry packets less frequently than other devices on the mesh. This is because they are chiefly tasked with routing others' traffic rather than originating their own messages.
The `REPEATER` role behaves very similar to `ROUTER` in terms of becoming a preferred device for routing packets, however it goes a step further by completely turning off any broadcasted traffic such as telemetry. It only responds to other nodes packets instead of originating messages.
The `REPEATER` role behaves very similar to `ROUTER` in terms of becoming a preferred device for routing packets, however it goes a step further by completely turning off any broadcasted traffic such as telemetry. It only responds to other nodes packets instead of originating messages.
#### What is a strategic location anyway?
@ -46,19 +47,18 @@ When evaluating strategic locations for these two roles, consider a tower on mou
If a poor location is chosen for Routers and Repeaters, it can cause a number of issues:
1) Increased rate of packet collisions
Because Routers and Repeaters always rebroadcast, when too many devices are applied with these roles and the devices are direct neighbors, packets will potentially be rebroadcasted at the same time, creating higher noise levels and packet error rates. This frequently culminates in sporadic delivery failures.
1. Increased rate of packet collisions
2) Decreased overall range
Because Routers and Repeaters always rebroadcast, when too many devices are applied with these roles and the devices are direct neighbors, packets will potentially be rebroadcasted at the same time, creating higher noise levels and packet error rates. This frequently culminates in sporadic delivery failures.
An improperly located router will potentially prematurely *hop gobble* any packets routing through it. This has the effect of consuming a hop in the routing of a packet before it would be able to reach more strategicly located nodes. This can greatly limit range for instance, in the case of many Routers being deployed in a valley consuming all of the available hops before a packet is able to reach its destination through a more stratically node placed on a peak above the valley.
2. Decreased overall range
3) Asymetrical links
An improperly located router will potentially prematurely _hop gobble_ any packets routing through it. This has the effect of consuming a hop in the routing of a packet before it would be able to reach more strategicly located nodes. This can greatly limit range for instance, in the case of many Routers being deployed in a valley consuming all of the available hops before a packet is able to reach its destination through a more stratically node placed on a peak above the valley.
3. Asymetrical links
Similarly to the issue of decreased range, the same scenario can also result in asymetrical communication, wherein a subset of the mesh can send messages to a different group, but that group is unable to reach back with responses through the improperly placed Routers' premature consumption of hops before the message is able to deliver. This phenomena can also lead to a reaction of users increasing the hop limit to compensate for the problem, which unfortunately further increases congestion by utilizing more air time.
### Sensor
The `SENSOR` role is intended for devices which primarily gather and transmit sensor data. These devices still participate in routing messages for other devices, but they prioritize sending their own telemetry data to the network, even in the face of high channel utilization. This role is ideal for environmental monitoring, weather stations, or any application where the device's main function is to collect and report telemetry.

2
blog/2024/October/meshtastic-solutions.mdx
View file

@ -11,6 +11,8 @@ image: "/design/web/social-preview-1200x630.png"
The Meshtastic Team is excited to announce Meshtastic Solutions. This new venture will support the Meshtastic open source project, as well as provide a pool of expertise for anyone building tools and systems with Meshtastic. Meshtastic Solutions will ensure the long-term health and success of the Meshtastic team and ecosystem, as well as to spur development of the Meshtastic firmware, clients, libraries, and utilities.
{/* truncate */}
This support will be fueled by partnerships with hardware vendors, many that you are familiar with, and some that are new to Meshtastic. In time, high quality devices will bear the Meshtastic seal of approval. Individual devices will be eligible for registration through Meshtastic, providing assurance of genuine hardware, as well as identity and cryptographic key attestation.
Meshtastic Solutions will also serve as a hub for businesses that need custom solutions or expert consultation within the Meshtastic ecosystem. Meshtastic Solutions is open for business for providing engineering, software solutions, and other support for custom use-cases. The first stage of this support is the Backer program, where existing manufacturers can financially support Meshtastic. This will be extended to include a full Partner program, offering in-depth design, close support, and device testing assistance. All with the goal of helping hardware vendors produce the best products possible for Meshtastic.