mudhorn/meshtastic
1
0
Fork 0
mirror of https://github.com/meshtastic/meshtastic.git synced 2024-12-25 05:34:11 -08:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Merge branch 'master' into patch-1

Browse source
This commit is contained in:
pdxlocations 2024-09-20 22:44:14 -07:00 committed by GitHub
parent 57a15f7015 4daa4b421c
commit c633f68f82
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
118 changed files with 4762 additions and 3107 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

96
blog/2024/August/meshtastic-opposition-to-nextnav-proposed-changes.mdx.mdx Normal file
View file

@ -0,0 +1,96 @@
---
title: Meshtastic's Opposition to Proposed Changes on 900 MHz Band
description: "Why We Oppose NextNav's 900 MHz Proposal: A Threat to Open Communication Networks"
slug: meshtastic-opposition-to-nextnav-proposed-changes
authors: crichton
tags: [meshtastic]
date: 2024-08-13T12:00
hide_table_of_contents: false
image: "/design/web/social-preview-1200x630.png"
---
The Federal Communications Commission (FCC) is currently considering a proposal from NextNav that could drastically reshape the 900 MHz band. While this proposal may seem like just another routine reconfiguration, it has significant implications for a broad range of users, particularly those who rely on unlicensed spectrum for innovative, community-driven projects. At the heart of the debate lies the potential impact on open-source initiatives like Meshtastic, an open-source, decentralized communication platform that operates in the 900 MHz ISM band.
{/* truncate */}
As a community, we are raising our voices in opposition to this proposal, and here’s why we believe it’s crucial for all stakeholders, especially amateur radio operators, tech enthusiasts, and public safety advocates, to understand the ramifications of this change.
## Understanding the 900 MHz Band and Its Importance
The 900 MHz band is a critical piece of spectrum used for various applications, including industrial, scientific, and medical (ISM) purposes, as well as amateur radio. It’s a unique band that supports a wide array of technologies, from garage door openers and baby monitors to more advanced uses like Meshtastic’s decentralized communication networks.
Meshtastic leverages LoRa (Long Range) technology to facilitate long-distance communication without relying on centralized infrastructure. This capability is especially valuable in remote areas where traditional communication networks are either unavailable or unreliable. The proposal by NextNav threatens to disrupt this delicate balance by reallocating portions of the 900 MHz band, which could severely impact these unlicensed applications.
## Key Concerns with NextNav’s Proposal
### 1. Potential Interference with Unlicensed Bands
NextNav’s proposal suggests creating a 5-MHz uplink in the 902-907 MHz band paired with a 10-MHz downlink in the 918-928 MHz band. However, these changes could lead to significant interference with existing unlicensed, low-power devices that currently operate within these frequencies. For the Meshtastic community and others relying on these bands, the result could be a substantial degradation in network performance, especially in rural and underserved regions where alternatives are limited.
> _“The 900 MHz band serves as a critical resource for those of us building decentralized networks. Interference from reallocated spectrum could cripple these grassroots communication efforts.”_ – JM Casler aka MC Hamster, Meshtastic Project Lead
### 2. Impact on Innovation and Open-Source Projects
Open-source projects like Meshtastic thrive in an environment where access to unlicensed spectrum is available for experimentation and innovation. By granting exclusive or prioritized access to these frequencies, the FCC risks stifling the creativity and diversity of applications that have historically driven advancements in wireless technology.
The open-source community has long been a bastion of innovation, creating technologies that benefit a wide range of users, from hobbyists to public safety officials. Restricting access to this spectrum could not only limit the development of new tools and applications but also hinder the progression of existing projects that rely on these frequencies.
### 3. Threat to Public Safety and Community Resilience
In disaster-prone or remote areas, decentralized communication networks are often the only lifeline when traditional infrastructure fails. Meshtastic’s low-power, long-range communication capabilities have proven invaluable in such situations, providing critical connectivity in times of need. By reallocating the spectrum these networks depend on, NextNav’s proposal could inadvertently weaken community resilience and public safety.
### 4. Equity and Accessibility Concerns
One of the most powerful aspects of the unlicensed spectrum is its ability to democratize communication. It allows small-scale operators, hobbyists, and underserved communities to build and maintain their own networks without the need for expensive licenses or subscriptions. NextNav’s proposal risks creating a barrier to entry, effectively widening the digital divide and excluding those who can’t afford to compete with larger entities for spectrum access.
## Meshtastic's Formal Opposition to NextNav’s 900 MHz Proposal
As part of our commitment to protecting the interests of our community and the broader public that relies on the 900 MHz band, Meshtastic has officially filed an opposition to NextNav’s proposed changes with the FCC. This filing outlines our concerns about the potential interference and the negative impact this reallocation could have on open-source projects, innovation, and public safety.
We believe it's vital that the FCC hears from all stakeholders who will be affected by these changes. By formally opposing the proposal, we aim to ensure that the voices of small-scale operators, hobbyists, and underserved communities are heard.
### View the Opposition Letter
<object
data="/documents/blog/Opposition_Letter.pdf"
type="application/pdf"
width="100%"
height="600px"
>
<p>
Your browser does not support PDFs.
<a href="/documents/blog/Opposition_Letter.pdf">Download the PDF</a>.
</p>
</object>
This document details our stance and the reasons we believe the proposed changes are detrimental to the community. We encourage our readers to review the letter and consider how this issue might affect their own use of the 900 MHz band.
## Key Takeaways
- **Unlicensed Spectrum is Vital:** The 900 MHz band is crucial for a wide range of applications, particularly for community-driven projects like Meshtastic that rely on this spectrum to operate effectively.
- **Innovation at Risk:** Limiting access to unlicensed spectrum could stifle innovation within the open-source community, hindering the development of new technologies and applications.
- **Public Safety Concerns:** Decentralized communication networks provide critical connectivity in emergencies; reallocating this spectrum could weaken these vital lifelines.
- **Equity and Accessibility:** The unlicensed spectrum serves as a democratizing resource, and restricting access could disproportionately impact small-scale operators and underserved communities.
## Frequently Asked Questions (FAQ)
**Q1: What exactly is NextNav proposing with the 900 MHz band?**
A1: NextNav is proposing to reconfigure the lower 900 MHz band by creating a 5-MHz uplink in the 902-907 MHz band paired with a 10-MHz downlink in the 918-928 MHz band, which could interfere with existing unlicensed uses of this spectrum.
**Q2: How will this proposal impact Meshtastic users?**
A2: The proposal could cause significant interference with Meshtastic’s low-power, long-range communication networks, potentially degrading performance, especially in remote and underserved areas.
**Q3: Why is unlicensed spectrum important for open-source projects?**
A3: Unlicensed spectrum allows for experimentation and innovation without the need for costly licenses, fostering a diverse range of applications and advancing wireless technology.
**Q4: What are the potential public safety implications of this proposal?**
A4: By reallocating spectrum that decentralized networks rely on, the proposal could undermine public safety by weakening the communication networks used in emergencies.
**Q5: Who stands to lose the most if this proposal is approved?**
A5: Small-scale operators, hobbyists, and underserved communities who rely on unlicensed spectrum for affordable communication solutions are likely to be the most affected.
## Conclusion
The proposed changes to the 900 MHz band by NextNav could have far-reaching consequences for a wide range of users, particularly those involved in community-driven, open-source projects like Meshtastic. It’s crucial that the FCC considers these impacts and seeks a balanced approach that protects the interests of all stakeholders, ensuring that this valuable public resource remains accessible for innovation, public safety, and community resilience.
Let’s ensure that the airwaves remain a shared space for all, fostering innovation and supporting those who need it most. Join us in voicing our opposition to this proposal and advocating for a fair and equitable solution.

55
blog/2024/August/recent-public-mqtt-broker-changes.mdx Normal file
View file

@ -0,0 +1,55 @@
---
title: Important Changes to the Meshtastic Project-Hosted MQTT Server
description: "Recent changes to the Meshtastic project-hosted MQTT server enhance user privacy and data protection."
slug: recent-public-mqtt-broker-changes
authors: crichton
tags: [meshtastic]
date: 2024-08-24T12:00
hide_table_of_contents: false
image: "/design/web/social-preview-1200x630.png"
---
The Meshtastic project-hosted [MQTT](/docs/software/integrations/mqtt/) server, which allows sharing mesh traffic over the Internet, has recently made an important change that impacts the way information is shared via MQTT: the ability to subscribe to all topics has been removed. However, users can still subscribe to regional topics, such as `msh/US/#`, to view nodes in their specific area. The MQTT functionality remains intact, public maps are still accessible, and users can continue to see nodes within their specified regions with some new changes.
{/* truncate */}
## Understanding the Change
On **August 21, 2024**, the Meshtastic development team made the decision to remove the ability for users to subscribe to all topics.
### Why This Change Was Necessary
The decision to restrict topic subscriptions was not made lightly. It stemmed from our observations that public mesh maps were now storing and, in some cases, tracking node positions over time. While users may have shared their position with their regional mesh, many might not have been aware that this information was being shared publicly online.
This data, being shared by third parties, raised significant concerns regarding personally identifiable information (PII). We recognized that users were not adequately informed about how their location data could be used, which prompted us to act swiftly.
We believe that while users have a responsibility to protect their information, the project also has a duty to the community to ensure that the services we provide do not contribute to potential privacy issues. This commitment is essential not only for the well-being of our community but also to protect the integrity of the Meshtastic project.
### The Benefits of the Change
1. **Regional Information Control**: By limiting topic subscriptions, we ensure that information stays within its relevant region, preventing groups from sharing data outside users' designated areas.
2. **Improved Server Performance**: With over 50% of MQTT traffic previously related to position data reporting, this change has significantly reduced server resource requirements. As a result, we have seen improvements in:
- **Availability**
- **Stability**
- **Reliability**
3. **Cost Efficiency**: Hosting a free service comes with its own set of challenges. The reduction in traffic has led to lower hosting costs, making the service more sustainable in the long run.
4. **Continued Success**: Like the success we experienced at DEF CON 32, where we implemented previous [traffic management policies](https://x.com/TheMeshtastic/status/1811082966283735317), we believe this change will further contribute to a successful MQTT server for the community.
### New Features Implemented
In response to community feedback, we have already enacted one of the solutions to enhance user experience. While subscribing to all topics remains disabled, we have introduced precise location filtering. This means:
- **Server-Level Filtering**: Only position packets with imprecise location information will be passed to the topic, ensuring that sensitive data is not exposed. **Note: This filtering is only applied to the default key.**
## Key Takeaways
- The Meshtastic project has removed the ability to subscribe to all topics to ensure that information remains within relevant regions.
- Users can still subscribe to regional topics to receive localized updates.
- This change has improved server performance and reduced hosting costs.
- Precise location filtering has been implemented to prevent sensitive data exposure.
## Conclusion
The Meshtastic project is committed to protecting user privacy while providing a reliable and efficient service. We understand that changes can be challenging, but we believe that these adjustments will ultimately benefit our community. We appreciate your understanding and support as we navigate these important changes together.
*Thank you for being a part of the Meshtastic community! Your feedback is invaluable as we continue to improve our services. Feel free to use the comment section below.*

52
blog/2024/August/why-meshtastic-uses-managed-flood-router.mdx Normal file
View file

@ -0,0 +1,52 @@
---
title: Why Meshtastic Uses Managed Flood Routing
description: "Why one of the simplest solutions is best for Meshtastic"
slug: why-meshtastic-uses-managed-flood-routing
authors: [thebentern, GUVWAF]
tags: [meshtastic, technical]
date: 2024-08-18T12:00
hide_table_of_contents: false
image: "/img/blog/route_plot.png"
---
Designing a low-bandwidth wireless mesh network to run on low-power microprocessors with limited memory is challenging. Arguably the simplest mesh routing protocol is Flood Routing: each radio receiving a packet will rebroadcast this again, up to a defined hop limit. Although Meshtastic is based on this strategy, there are a few subtle, but significant enhancements. Most importantly, before a node rebroadcasts, it waits a short while and listens if anyone else is already rebroadcasting. If so, it will not rebroadcast again. Therefore, “Managed Flood Routing” would be a better name. For more details on the enhancements, please review our [documentation](https://meshtastic.org/docs/overview/mesh-algo/).
{/* truncate */}
Since Flood Routing is not very efficient, we realize that this approach is not perfect. The firmware has a number of measures in place to limit traffic in order not to overwhelm a mesh, but as with any RF based protocol, there are limitations to the capacity of the mesh. In attempts to enhance the efficiency, we have evaluated “smarter” routing protocols at times in the past. However, we have yet to find anything that would consistently outperform the current approach in the use-cases and scenarios Meshtastic is currently being utilized. We’ll go over several reasons for why we believe Managed Flood Routing remains a superior approach for Meshtastic.
## Key Advantages of Meshtastic's Managed Flood Routing
1. Eliminates route discovery overhead
2. Provides superior adaptation to dynamic network topologies
3. Optimized for broadcast-heavy traffic patterns common in Meshtastic
4. Demonstrates excellent scalability in low-bandwidth environments
5. Minimizes resource utilization on constrained IoT devices
6. Empirically validated through extensive network simulations
## Avoids Route Discovery
First and foremost, Managed Flood Routing eliminates the need for route discovery or centralized control. In traditional routing algorithms, devices rely on predefined or dynamic routes to forward messages to their destinations. With Managed Flood Routing, you can start messaging immediately after booting your device. Furthermore, route discovery and maintenance leads to overhead, which quickly becomes very significant with a low-bandwidth protocol such as LoRa. In order to maintain routes, either additional control packets are needed, or metadata has to be added to normal traffic. Either increases utilization of precious airtime. In static scenarios, this is not a significant issue, but when the topology changes often -as we discuss in the next section- the overhead quickly outweighs the benefit of a smarter routing protocol.
## Seamlessly Adapts to Network Topology Changes
Another significant advantage of Managed Flood Routing is its ability to adapt to network topology changes. In mesh networks, devices can join or leave the network at any time, and in the case of Meshtastic, nodes are often mobile causing the network topology to change frequently. Even environmental changes such as the weather or the time of day may influence routes. Traditional routing algorithms struggle to keep up with these changes, often leading to message loss or delays. Managed Flood Routing, however, excels in such scenarios. As each device will participate in the routing when called upon, the network quickly adapts to the changes, ensuring that messages find their way to the destination even in the face of frequent topology changes.
## Inefficiency is Limited
A routing protocol aims to deliver packets at the destination in the most efficient way possible. Indeed for packets with a single destination, a lot can be gained by choosing only one efficient route. However, for broadcasts the potential gain is limited, as it is intended to be delivered to every node in the mesh. Since the majority of packets in Meshtastic are broadcasts rather than messages targeting a specific node, a smarter protocol would have limited influence. Additionally, in a wireless medium, even if a packet is directed to a certain node, all nodes in range will witness it and during that time they cannot transmit or receive another packet, meaning that even with a _perfect_ routing protocol, nodes that may not be interested in a packet will still receive it, especially if they have good receiver sensitivity, which is frequently the case for LoRa.
## Provides Scalability on low-bandwidth LoRa transport
Furthermore, Managed Flood Routing is certainly scalable, because nodes that are unlikely to contribute to routing will not participate. In large-scale mesh networks, where hundreds of devices are meshing, scalability becomes a critical factor, and minimizing airtime is king. Traditional routing algorithms often struggle to handle the increasing number of devices and the associated routing overhead, due to the additional control messages required to maintain routes with highly ephemeral topologies. On the other hand, with Managed Flood Routing, new devices joining the network integrate into the routing process without any additional ceremony, contributing to the overall network resilience and message delivery efficiency.
## Functions on Resource Constrained Devices
Finally, Managed Flood Routing minimizes footprint on very resource-constrained low power IoT devices. Traditional routing algorithms often require devices to maintain large routing tables or perform complex calculations, consuming additional RAM, flash, and valuable computational resources. Managed Flood Routing, with its simplicity and distributed nature, significantly reduces the resource overhead. Devices only need to forward messages they receive, without the need for complex computations, resulting in more device resource availability for other valuable features and improved device autonomy.
> Many decisions are based on data from [Meshtasticator](https://github.com/GUVWAF/Meshtasticator) simulations ![Route Plot](/img/blog/route_plot.png)
## Considerations and Future Directions
While Managed Flood Routing has proven highly effective for Meshtastic, we acknowledge its limitations:
- Not optimal for all network configurations
- Potential for improvement in specific unicast scenarios
- Ongoing research into hybrid approaches for future implementations
The current Managed Flood Routing is not perfect and success is not guaranteed, but it has been proven to be effective even in large meshes of more than 100 nodes with proper traffic control. There are trade-offs associated with any approach, and utilizing any “smarter” protocol will inevitably lead to overhead in several ways which, in our view, can quickly diminish its benefits.

56
blog/2024/September/introducing-new-public-key-cryptography-in-v2_5.mdx Normal file
View file

@ -0,0 +1,56 @@
---
title: "Meshtastic Encryption: Evolving from Simple Messaging to a Versatile Solution"
description: "Meshtastic's encryption has evolved, introducing our new Public Key Cryptography in v2.5.0 to enhance security in off-grid communication."
slug: introducing-new-public-key-cryptography-in-v2_5
authors: [Jonathan, crichton]
tags: [meshtastic, technical]
date: 2024-09-12T21:00
hide_table_of_contents: false
image: "/img/blog/Meshtastic_PKC_ECDH.png"
---
Meshtastic began with a straightforward goal: to keep hiking buddies connected in the outdoors when cell service was unavailable. What started as a simple project has grown, thanks to a passionate community pushing the boundaries of what's possible. Today, Meshtastic is used in Search and Rescue operations, off-grid communication, disaster recovery, and even grid-down scenarios. Whether it's preparing for the next flood or tornado, extending communication over the Internet with MQTT, or simply enjoying an off-grid adventure, Meshtastic has become an essential tool for many.
{/* truncate */}
### Balancing Encryption with Practical Use
For many, Meshtastic's encryption is a key part of the appeal. Over the years, the challenge has been finding a balance: implementing strong encryption without excluding low-power IoT platforms or overwhelming LoRa's limited bandwidth. Before version 2.5, encryption relied on a static pre-shared key per channel, which was quite robust. However, it had one notable limitation: Direct Messages (DMs).
DMs were sent using the same shared channel key, which meant that while DMs were theoretically private, they were accessible to anyone on the same channel. The honor system was the only safeguard, particularly since the default Meshtastic setup uses a publicly known encryption key, leaving DMs effectively unencrypted out of the box.
### Challenges with Remote Administration
Remote administration also presented hurdles. The conventional method involved creating an "admin" channel, allowing any node on that channel to be controlled remotely. This approach had drawbacks, notably that nodes open to administering others were also vulnerable to being administered themselves.
## Introducing Public Key Cryptography (PKC) to Meshtastic
In 2022, a user named edinnen proposed a solution with a pull request that introduced a public/private key scheme for DMs. Although the initial feedback was promising, the patch became outdated as time passed. Recently, everything aligned, and we revisited and reworked this patch, making it the foundation of Meshtastic's version 2.5 development.
Our new PKC implementation is now a core feature, providing each node with a unique public key generated at first boot. This key enables secure, encrypted connections between nodes and serves as a unique identifier within the mesh. It also solves the remote administration challenge—nodes can now be identified and authorized as remote administrators through their public keys.
### A Major Step Forward in Security
With this new PKC scheme, Meshtastic offers enhanced encryption for DMs and secure remote administration for difficult-to-reach nodes. While we still caution against relying solely on Meshtastic encryption for life-or-death situations, this update marks a significant advancement in privacy and security for the mesh network.
### Technical Deep Dive: The Mechanics of Meshtastic's New Encryption
At the heart of Meshtastic's new encryption system lies the X25519 elliptic curve Diffie-Hellman key exchange. This process unfolds in two key steps:
1. Key Generation: Upon first boot, each device generates a random private key and derives a corresponding public key using the X25519 algorithm. This public key is then broadcast to the mesh as part of the node's regular announcements.
2. Secure Communication: When a node initiates a Direct Message (DM), it completes the X25519 key exchange by combining its private key with the recipient's public key. This process generates a unique shared secret, which is then used to encrypt the DM. The receiving node can independently derive the same shared secret using its private key and the sender's public key, enabling secure decryption.
> ![Meshtastic's X25519 Key Exchange Process](/img/blog/Meshtastic_PKC_ECDH.png) Figure 1: Visual representation of Meshtastic's X25519 key exchange process
The encryption scheme employs AES-CCM (Counter with CBC-MAC), which provides both confidentiality and authenticity. A notable feature is the inclusion of a short Message Authentication Code, verifying the sender's identity and ensuring message integrity. To further enhance security, DM messages incorporate an additional 4 bytes of random nonce, effectively preventing potential compromises due to nonce reuse.
Remote administration has also seen significant improvements. Administration messages now include an 8-byte session key, set by the node being administered. This key is included in responses and must be present in any packet attempting to make changes. With a 300-second timeout, this mechanism provides robust protection against replay attacks of captured administration traffic.
## Conclusion
Meshtastic's journey from a simple hiking communication tool to a versatile, secure mesh networking solution showcases the power of community-driven development. The introduction of our new Public Key Cryptography scheme in version 2.5 represents a significant advancement in the platform's security capabilities, addressing long-standing challenges in direct messaging and remote administration.
As we continue to refine and expand Meshtastic's features, we remain committed to balancing robust security with practical usability. While this update significantly enhances the platform's privacy and security, we encourage users to approach encryption with a clear understanding of its strengths and limitations, especially in critical scenarios.
Looking ahead, we're excited about the possibilities this new encryption framework opens up. We invite our community to explore these new features, provide feedback, and continue pushing the boundaries of what's possible with Meshtastic. Together, we're building a more secure and connected future for off-grid communication.

28
blog/authors.yml Normal file
View file

@ -0,0 +1,28 @@
crichton:
name: Crichton
title: "Lead: Community Outreach & Development"
url: https://github.com/rcarteraz
image_url: https://github.com/rcarteraz.png
socials:
github: rcarteraz
thebentern:
name: TheBentern
title: "Device Firmware Development Lead"
url: https://github.com/thebentern
image_url: https://github.com/thebentern.png
socials:
github: thebentern
GUVWAF:
name: GUVWAF
title: "Lead: Routing & Mesh Algorithm Development"
url: https://github.com/GUVWAF
image_url: https://github.com/GUVWAF.png
socials:
github: GUVWAF
Jonathan:
name: Jonathan Bennett
title: "Lead: The Linux Guy, Amateur Cryptographer, Position Wrangler, Privacy Protector, Bug Hunter"
url: https://github.com/jp-bennett
image_url: https://github.com/jp-bennett.png
socials:
github: jonathanbennett

27
docs/about/contributing.mdx
View file

@ -76,9 +76,9 @@ If direct development contribution is not feasible for you, financial support is
</div>
</div>
### Fiscal Sponsorships
### Sponsors
We're deeply thankful for the backing from the Open Collective, Open Source Collective, DigitalOcean, and Vercel, which has been instrumental in our project's sustainability and growth:
We're deeply thankful for the backing from our sponsors, listed below, which has been instrumental in our project's sustainability and growth. Their support enables us to continue serving and expanding our community.
<div className="flex flex-wrap items-start">
<div className="w-full sm:w-3/12 p-3">
@ -86,8 +86,8 @@ We're deeply thankful for the backing from the Open Collective, Open Source Coll
alt="Open Collective"
className="max-h-8"
sources={{
light: useBaseUrl("/img/Open_Collective_logo_2021.svg"),
dark: useBaseUrl("/img/Open_Collective_logo_2021.svg"),
light: useBaseUrl("/img/contributing/Open_Collective_logo_2021.svg"),
dark: useBaseUrl("/img/contributing/Open_Collective_logo_2021.svg"),
}}
/>
</div>
@ -117,8 +117,8 @@ We're deeply thankful for the backing from the Open Collective, Open Source Coll
alt="Vercel"
className="max-h-8"
sources={{
light: useBaseUrl('/img/vercel-logotype-dark.svg'),
dark: useBaseUrl('/img/vercel-logotype-light.svg'),
light: useBaseUrl('/img/contributing/vercel-logotype-dark.svg'),
dark: useBaseUrl('/img/contributing/vercel-logotype-light.svg'),
}}
/>
</div>
@ -126,3 +126,18 @@ We're deeply thankful for the backing from the Open Collective, Open Source Coll
By covering our hosting costs, Vercel directly contributes to Meshtastic's growth, enhancing our web scalability and presence. Their sponsorship is crucial for our continued development and focus on creating a robust platform for decentralized communication.
</div>
</div>
<div className="flex flex-wrap items-start">
<div className="w-full sm:w-3/12 p-3">
<ThemedImage
alt="Datadog"
className="max-h-8"
sources={{
light: useBaseUrl("/img/contributing/dd_logo_h_rgb.svg"),
dark: useBaseUrl("/img/contributing/dd_logo_h_white.svg"),
}}
/>
</div>
<div className="w-full sm:w-9/12 p-3">
Datadog is an observability and security platform for cloud applications, providing infrastructure monitoring, application performance monitoring, and log management. They sponsor us by granting free infrastructure monitoring and logging, aiding our development and operational efforts.
</div>
</div>

4
docs/about/introduction.mdx
View file

@ -27,9 +27,9 @@ Meshtastic® is a project that enables you to use inexpensive LoRa radios as a l
Meshtastic utilizes LoRa, a long-range radio protocol, which is widely accessible in most regions without the need for additional licenses or certifications, unlike HAM radio operations.
These radios are designed to rebroadcast messages they receive, forming a mesh network. This setup ensures that every group member, including those at the furthest distance, can receive messages. Depending on the settings employed, the Meshtastic mesh network can support up to 100 devices concurrently.
These radios are designed to rebroadcast messages they receive, forming a mesh network. This setup ensures that every group member, including those at the furthest distance, can receive messages.
Additionally, Meshtastic radios can be paired with a single phone, allowing friends and family to send messages directly to your specific radio. It's important to note that each device is capable of supporting a connection from only one user at a time."
Additionally, Meshtastic radios can be paired with a single phone, allowing friends and family to send messages directly to your specific radio. It's important to note that each device is capable of supporting a connection from only one user at a time.
If you are interested in a more technical overview of how Meshtastic works, visit the overview section below:

151
docs/about/overview/encryption.mdx
View file

@ -1,151 +0,0 @@
---
id: encryption
title: Meshtastic Encryption
sidebar_label: Encryption
slug: /overview/encryption
sidebar_position: 3
description: "Understand Meshtastic's encryption: optional network-wide AES256 security for off-grid communication, ensuring confidentiality against passive eavesdropping."
---
## Explanation
Meshtastic provides AES256-CTR encryption for the payload of each packet when sending via LoRa, with a different key for each [channel](/docs/configuration/radio/channels/). The [packet header](/docs/overview/mesh-algo/#layer-1-unreliable-zero-hop-messaging) is always sent unencrypted, which allows nodes to relay packets they can't decrypt as well. One can disable this by setting a different [rebroadcast mode](/docs/configuration/radio/device#rebroadcast-mode).
By default you have one primary channel which is encrypted with a simple known key ("AQ=="), so to use proper encryption you **must change** this key first, or create a new channel and share it with the ones you want to communicate with. However, if you don't have the default key, it means you will not be able to communicate with devices that don't have your key.
Direct messages to a specific node (e.g. text, traceroute or position requests) may use any channel you share with the recipient. Namely, the device will use the one where it most recently heard a NodeInfo packet from the recipient on. Client apps will not show messages directed to other nodes, but in principle they could be read by **anyone** who knows the used channel key. This means that if it uses the default key, you have to assume anyone could read your direct messages.
All periodic broadcasts (position, telemetry, etc.) the device sends out itself are sent over the primary channel and thus encrypted with that key.
The device will decrypt the payload before sending it to a client app via BLE, serial, Wi-Fi/Ethernet. For MQTT you can [specify](/docs/configuration/module/mqtt#encryption-enabled) whether you want to send an encrypted or unencrypted payload.
## Is it as secure as Wi-Fi WPA3, HTTPS TLS1.3 or Signal ?
**No**.
[WPA3](https://en.wikipedia.org/wiki/WPA3), [TLS1.3](https://en.wikipedia.org/wiki/TLS1.3), [Signal](https://en.wikipedia.org/wiki/Signal_Protocol) and Meshtastic can all use AES256, yet AES is one of the many cogs required in a modern encryption system, see below the main features "missing" in Meshtastic.
### Perfect-Forward-Secrecy
[**P**erfect-**F**orward-**S**ecrecy also known as **PFS**](https://en.wikipedia.org/wiki/Forward_secrecy) means *previous* communications and more generally anything *passively captured* cannot be decrypted ***even when the key is compromised***.
This means Meshtastic is vulnerable to [**« Harvest now, Decrypt later »**](https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later) attacks, **this attack itself is not enough to decrypt messages** it relies on an other failure leaking the channel key such as:
- Accidently sharing the channel key with the wrong person.
- One of your nodes being stolen.
- Any unknown bug revealing the channel key to an attacker.
Other protocols such as *misconfigured TLS1.2* are far more impacted by Harvest now, Decrypt later attacks because their keys will be broken by near future Quantum-Computers yet they do not provide PFS.
Meshtastic's encryption is not threatened by Quantum-Computers\* so realistic attack vectors are accidental miss-handling of channel keys and nodes being lost.
\*on the Quantum-Resistance of AES256 see:
- [this stackoverflow question, contain a bit of debates and two good answers](https://crypto.stackexchange.com/q/6712)
- [NIST's Post-Quantum FAQ](https://csrc.nist.gov/projects/post-quantum-cryptography/faqs) section « To protect against the threat of quantum computers, should we double the key length for AES now? (added 11/18/18) »
**Recommendations** for users using *private channels*:
- **Do not configure private channels on unattended nodes**, nodes will relay meshtastic traffic even if they are not able to decrypt it.
Your unattended routers should not have the private PSK configured as it is easy to gain physical access and extract the channel key.
- Keep in mind, everything sent on a channel can be stored and decrypted later by anyone who gain access to the key even if you locally delete the messages.
- Change your Channel Keys from time to time.
### Integrity
Integrity means ensuring messages cannot be modified without the key.
Meshtastic does not check messages have not been tempered with, see [`#4030`](https://github.com/meshtastic/firmware/issues/4030) for details.
**Recommendations**:
- Keep in mind, by applying a known plaintext attack anyone *could* send messages on a channel even with the channel key is private and secure.
- For developers of third party applications integrating meshtastic, include a cryptographic MAC over the message content and PSK,
we are also considering an [AEAD secured channel mode which would provide this natively](https://github.com/meshtastic/firmware/issues/4030).
### Authentication
Authentication means nodes say who they are on the network, meshtastic does not implement this so it is trivial to impersonate anyone else if you have access to the channel key.
This is because node ids are based on hardware [MAC address](https://en.wikipedia.org/wiki/MAC_address), theses are hardcoded by the manufacturer.
Some other networks like [Yggdrasil](https://yggdrasil-network.github.io/), [cjdns](https://github.com/cjdelisle/cjdns) or [libp2p](https://libp2p.io/) use [public / private key pairs](https://en.wikipedia.org/wiki/Public-key_cryptography) and the Public Key becomes the Node Identity, this make all messages bigger and or require an interactive handshake process.
**Recommendations**:
- Keep in mind, the sender field is indicative and anyone with access to the channel key can trivially lie.
## Direct-Messages
Direct-Messages are implemented as channel messages which have a `to` protobuf field set.
This means anyone in the channel can read all your direct-messages.
Also the node needs to know the right channel to use, this is done by using the latest one a NodeInfo was received, due to the lack of `Authentication` this means anyone you share a channel with can send a spoofed NodeInfo and make you send direct-messages on an incorrect public channel.
**Recommendations**:
- Keep in mind, due to NodeInfo spoof issue Direct-Messages are **very significantly less secure than a private channel** with a secure PSK.
- Do not use Direct-Messages for anything private, instead ahead of time create a new private channel and share it with the person you want to message with.
- Nodes will relay encrypted packets even if they can't decrypt it, so you only loose on some [small DM optimizations](https://github.com/meshtastic/firmware/pull/3753).
- Do not send the private channel key in direct messages or a public channel, because then anyone listening gain access.
- Use a different private channel for each person you want to have private conversations with.
## Comments
Cryptography is tricky, so we've tried to 'simply' apply standard crypto solutions to our implementation. However, the project developers are not cryptography experts.
Based on comments from reviewers (see below), here are some tips for usage of these radios, so that you may know the level of protection offered:
- It is pretty likely that the AES256 security is implemented 'correctly' and an observer will not be able to decode your messages.
- Warning: If an attacker is able to get one of the radios in their possession, they could either a) extract the channel key from that device or b) use that radio to listen to new communications.
- Warning: If an attacker is able to get the "Channel QR code/URL" that you share with others - that attacker could then be able to read any messages sent on the channel (either tomorrow or in the past - if they kept a raw copy of those broadcast packets)
The current implementation provides optional confidentiality to members of a configured network:
- Encryption is implemented in devices/nodes with network-wide encryption keys.
- Encryption is optional and is turned off when devices are in 'Ham mode'.
- There is no encryption supported in the clients (iOS, Android) to facilitate distribution as mass market software.
- Pairing from client-to-device is by:
- direct USB cable
- BT pairing
- Devices are 'promiscuous' and will pair with any near-by client. Network confidentiality requires physical protection of all nodes.
Always keep in mind [xkcd's note on encryption](https://xkcd.com/538).
- If you are a cryptography expert, please review these notes and our questions below. Can you help us by reviewing our notes below and offering advice? We will happily give as much or as little credit as you wish ;-).
- Consider our existing solution 'alpha' and probably fairly secure against a not particularly aggressive adversary (but we can't yet make a more confident statement).
### Notes for reviewers
If you are reviewing our implementation, this is a brief statement of our method.
- We do all crypto at the SubPacket (payload) level only, so that all Meshtastic nodes will route for others - even those channels which are encrypted with a different key.
- Mostly based on reading [Wikipedia](<https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_(CTR)>) and using the modes the ESP32 provides support for in hardware.
- We use AES256-CTR as a stream cypher (with zero padding on the last BLOCK) because it is well supported with hardware acceleration.
- Our AES key is 128 or 256 bits, shared as part of the 'Channel' specification.
- The node number concatenated with the packet number is used as the NONCE. This nonce will be stored in flash in the device and should essentially never repeat. If the user makes a new 'Channel' (i.e. picking a new random 256 bit key), the packet number will start at zero.
- The packet number is sent in cleartext with each packet. The node number can be derived from the "from" field of each packet. (Cleartext is acceptable because it merely provides IV for each encryption run)
- Each 16 byte BLOCK for a packet has an incrementing COUNTER. COUNTER starts at zero for the first block of each packet.
- The IV for each block is constructed by concatenating the NONCE as the upper 96 bits of the IV and the COUNTER as the bottom 32 bits. Since our packets are small counter portion will really never be higher than 32 (five bits).
### Comments from reviewer #1
This reviewer is a cryptography professional, but would like to remain anonymous. We thank them for their comments ;-):
I'm assuming that meshtastic is being used to hike in places where someone capable is trying to break it - like you were going to walk around DefCon using these. I spent about an hour reviewing the encryption, and have the following notes:
- The write-up isn't quite as clear as the code.
- The code is using AES-CTR mode correctly to ensure confidentiality.
- The comment for initNonce really covers the necessary information.
- I think the bigger encryption question is "what does the encryption need to do"? As it stands, an attacker who has yet to capture any of the devices cannot reasonably capture text or location data. An attacker who captures any device in the channel/mesh can read everything going to that device, everything stored on that device, and any other communication within the channel that they captured in encrypted form. If that capability basically matches your expectations, it is suitable for whatever adventures this was intended for, then, based on information publicly available or widely disclosed, the encryption is good. If those properties are distressing (like, device history is deliberately limited and you don't want a device captured today to endanger the information sent over the channel yesterday) we could talk about ways to achieve that (most likely synchronizing time and replacing the key with its own SHA256 every X hours, and ensuring the old key is not retained unnecessarily).
- Two other things to keep in mind are that AES-CTR does not itself provide authenticity (e.g. an attacker can flip bits in replaying data and scramble the resulting plaintext), and that the current scheme gives some hints about transmission in the size. So, if you worry about an adversary deliberately messing-up messages or knowing the length of a text message, it looks like those might be possible.
I'm guessing that the network behaves somewhat like a store-and-forward network - or, at least, that the goal is to avoid establishing a two-way connection to transmit data. I'm afraid I haven't worked with mesh networks much, but remember studying them briefly in school about ten years ago.
### Comments from @Jorropo
- The IV initialization only use 31 random bits per reboot, it then increment messages sequentially. This is not high, it makes duplicate unlikely but probable given the complete scale of the network. Thankfully IV include lower 32 bits of the MAC address which should be unique per node, so each node is it's own birthday paradox, we aren't looking for network wide birthday paradox which would be easy to hack. See [`#4031`](https://github.com/meshtastic/firmware/issues/4031).
Could be fixed.
- The lack of [integrity wasn't properly considered](https://github.com/meshtastic/firmware/issues/4030), the remote administration module implements priviliged RPC calls over AES-CTR without any MAC or AEAD.
Could be fixed.
- The AES-CTR implementation looks like it protects Confidentiality assuming IVs are not duplicated.
- The lack of Forward Secrecy is a bit worrying for a chat messenger when new users lack the paranoid and annoying key management practice that would be required for safe operation.
- IMO the clients should have a big red box the first time you open a Direct-Message indicating theses are not private and not E2E. This was not clear to me without reading the code.
- This project is completely fine for chatting with strangers, using the default key and understanding everything is public, I would not trust it with anything private without some other layer or significant reworks. For example I would consider SSH or Signal over Meshtastic safe. Yet Meshtastic does not choose to have worse crypto for bad reasons, they make the network significantly more usable over the unreliable slow LoRa backhaul it is using.

72
docs/about/overview/encryption/comments.mdx Normal file
View file

@ -0,0 +1,72 @@
---
id: comments
title: Comments on Meshtastic's Encryption
sidebar_label: Comments
sidebar_position: 2
description: "Explore community insights and expert opinions on Meshtastic's encryption, including AES256 implementation, security tips, and potential vulnerabilities."
---
This page compiles community feedback and expert reviews on Meshtastic's encryption approach. We value these insights and aim to improve our encryption implementation where feasible. Explore key details, practical tips, and understand the strengths and potential limitations of Meshtastic's AES256 encryption.
## Comments
Cryptography is tricky, so we've tried to 'simply' apply standard crypto solutions to our implementation. However, the project developers are not cryptography experts.
Based on comments from reviewers (see below), here are some tips for using these radios, so that you may know the level of protection offered:
- It is likely that the AES256 security is implemented 'correctly' and an observer will not be able to decode your messages.
- **Warning:** If an attacker is able to get one of the radios in their possession, they could either a) extract the channel key from that device, or b) use that radio to listen to new communications.
- **Warning:** If an attacker is able to get the "Channel QR code/URL" that you share with others, that attacker could then be able to read any messages sent on the channel (either tomorrow or in the past - if they kept a raw copy of those broadcast packets).
The current implementation provides optional confidentiality to members of a configured network:
- Encryption is implemented in devices/nodes with network-wide encryption keys.
- Encryption is optional and is turned off when devices are in 'Ham mode'.
- There is no encryption supported in the clients (iOS, Android) to facilitate distribution as mass-market software.
- Pairing from client-to-device is by:
- Direct USB cable
- BT pairing
- Devices are 'promiscuous' and will pair with any nearby client. Network confidentiality requires physical protection of all nodes.
Always keep in mind [xkcd's note on encryption](https://xkcd.com/538).
- If you are a cryptography expert, please review these notes and our questions below. Can you help us by reviewing our notes below and offering advice? We will happily give as much or as little credit as you wish ;-).
- Consider our existing solution 'alpha' and probably fairly secure against a not particularly aggressive adversary (but we can't yet make a more confident statement).
## Notes for reviewers
If you are reviewing our implementation, this is a brief statement of our method.
- We do all crypto at the SubPacket (payload) level only, so that all Meshtastic nodes will route for others - even those channels which are encrypted with a different key.
- Mostly based on reading [Wikipedia](<https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_(CTR)>) and using the modes the ESP32 provides support for in hardware.
- We use AES256-CTR as a stream cypher (with zero padding on the last BLOCK) because it is well supported with hardware acceleration.
- Our AES key is 128 or 256 bits, shared as part of the 'Channel' specification.
- The node number concatenated with the packet number is used as the NONCE. This nonce will be stored in flash in the device and should essentially never repeat. If the user makes a new 'Channel' (i.e. picking a new random 256 bit key), the packet number will start at zero.
- The packet number is sent in cleartext with each packet. The node number can be derived from the "from" field of each packet. (Cleartext is acceptable because it merely provides IV for each encryption run)
- Each 16 byte BLOCK for a packet has an incrementing COUNTER. COUNTER starts at zero for the first block of each packet.
- The IV for each block is constructed by concatenating the NONCE as the upper 96 bits of the IV and the COUNTER as the bottom 32 bits. Since our packets are small counter portion will really never be higher than 32 (five bits).
### Comments from reviewer #1
This reviewer is a cryptography professional, but would like to remain anonymous. We thank them for their comments ;-):
I'm assuming that meshtastic is being used to hike in places where someone capable is trying to break it - like you were going to walk around DefCon using these. I spent about an hour reviewing the encryption, and have the following notes:
- The write-up isn't quite as clear as the code.
- The code is using AES-CTR mode correctly to ensure confidentiality.
- The comment for initNonce really covers the necessary information.
- I think the bigger encryption question is "what does the encryption need to do"? As it stands, an attacker who has yet to capture any of the devices cannot reasonably capture text or location data. An attacker who captures any device in the channel/mesh can read everything going to that device, everything stored on that device, and any other communication within the channel that they captured in encrypted form. If that capability basically matches your expectations, it is suitable for whatever adventures this was intended for, then, based on information publicly available or widely disclosed, the encryption is good. If those properties are distressing (like, device history is deliberately limited and you don't want a device captured today to endanger the information sent over the channel yesterday) we could talk about ways to achieve that (most likely synchronizing time and replacing the key with its own SHA256 every X hours, and ensuring the old key is not retained unnecessarily).
- Two other things to keep in mind are that AES-CTR does not itself provide authenticity (e.g. an attacker can flip bits in replaying data and scramble the resulting plaintext), and that the current scheme gives some hints about transmission in the size. So, if you worry about an adversary deliberately messing-up messages or knowing the length of a text message, it looks like those might be possible.
I'm guessing that the network behaves somewhat like a store-and-forward network - or, at least, that the goal is to avoid establishing a two-way connection to transmit data. I'm afraid I haven't worked with mesh networks much, but remember studying them briefly in school about ten years ago.
### Comments from @Jorropo
- The IV initialization only use 31 random bits per reboot, it then increment messages sequentially. This is not high, it makes duplicate unlikely but probable given the complete scale of the network. Thankfully IV include lower 32 bits of the MAC address which should be unique per node, so each node is it's own birthday paradox, we aren't looking for network wide birthday paradox which would be easy to hack. See [`#4031`](https://github.com/meshtastic/firmware/issues/4031).
Could be fixed.
- The lack of [integrity wasn't properly considered](https://github.com/meshtastic/firmware/issues/4030), the remote administration module implements priviliged RPC calls over AES-CTR without any MAC or AEAD.
Could be fixed.
- The AES-CTR implementation looks like it protects Confidentiality assuming IVs are not duplicated.
- The lack of Forward Secrecy is a bit worrying for a chat messenger when new users lack the paranoid and annoying key management practice that would be required for safe operation.
- IMO the clients should have a big red box the first time you open a Direct-Message indicating theses are not private and not E2E. This was not clear to me without reading the code.
- This project is completely fine for chatting with strangers, using the default key and understanding everything is public, I would not trust it with anything private without some other layer or significant reworks. For example I would consider SSH or Signal over Meshtastic safe. Yet Meshtastic does not choose to have worse crypto for bad reasons, they make the network significantly more usable over the unreliable slow LoRa backhaul it is using.

115
docs/about/overview/encryption/index.mdx Normal file
View file

@ -0,0 +1,115 @@
---
id: encryption
title: Meshtastic Encryption
sidebar_label: Encryption
slug: /overview/encryption
sidebar_position: 3
description: "Understand Meshtastic's encryption: optional network-wide AES256 security for off-grid communication, ensuring confidentiality against passive eavesdropping."
---
## Explanation
Meshtastic provides AES256-CTR encryption for the payload of each packet when sending via LoRa, with a different key for each [channel](/docs/configuration/radio/channels/). The [packet header](/docs/overview/mesh-algo/#layer-1-unreliable-zero-hop-messaging) is always sent unencrypted, which allows nodes to relay packets they can't decrypt as well. One can disable this by setting a different [rebroadcast mode](/docs/configuration/radio/device#rebroadcast-mode).
By default, you have one primary channel, which is encrypted with a simple known key ("AQ=="), so to use proper encryption, you **must change** this key first, or create a new channel and share it with the ones you want to communicate with. However, if you don't have the default key, it means you will not be able to communicate with devices that don't have your key.
Direct messages to a specific node are now encrypted using Public Key Cryptography (PKC). Each node is equipped with a unique public/private key pair, and direct messages are encrypted with the recipient's public key. This ensures that only the recipient can decrypt the message using their private key. Additionally, messages are signed with the sender's private key, allowing the recipient to verify the sender's identity and ensuring the message's integrity.
All periodic broadcasts (position, telemetry, traceroutes, etc.) the device sends out itself are sent over the primary channel and thus encrypted with that key.
The device will decrypt the payload before sending it to a client app via BLE, serial, Wi-Fi/Ethernet. For MQTT, you can [specify](/docs/configuration/module/mqtt#encryption-enabled) whether you want to send an encrypted or unencrypted payload.
## Is it as secure as Wi-Fi WPA3, HTTPS TLS1.3, or Signal?
**No**.
[WPA3](https://en.wikipedia.org/wiki/WPA3), [TLS1.3](https://en.wikipedia.org/wiki/TLS1.3), [Signal](https://en.wikipedia.org/wiki/Signal_Protocol), and Meshtastic can all use AES256. Yet AES is one of the many cogs required in a modern encryption system. Below are the main features "missing" in Meshtastic.
### Perfect-Forward-Secrecy
[**P**erfect-**F**orward-**S**ecrecy, also known as **PFS**](https://en.wikipedia.org/wiki/Forward_secrecy), means _previous_ communications and more generally anything _passively captured_ cannot be decrypted **_even when the key is compromised_**.
This means Meshtastic is vulnerable to [**« Harvest now, Decrypt later »**](https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later) attacks. **This attack itself is not enough to decrypt messages**; it relies on another failure leaking the channel key, such as:
- Accidentally sharing the channel key with the wrong person.
- One of your nodes being stolen.
- Any unknown bug revealing the channel key to an attacker.
Other protocols, such as _misconfigured TLS1.2_, are far more impacted by Harvest now, Decrypt later attacks because their keys will be broken by near-future Quantum-Computers, yet they do not provide PFS.
Meshtastic's AES256 encryption is considered quantum-resistant[^1], but the public/private key exchange for DMs is not, as current quantum-resistant cryptography schemes don't fit in LoRa packets or our IoT hardware; realistic attack vectors include accidental mishandling of channel keys, nodes being lost, and potential future quantum attacks on DM key exchanges.
[^1]: On the Quantum-Resistance of AES256, see [this stackoverflow question, containing a bit of debate and two good answers](https://crypto.stackexchange.com/q/6712) and the [NIST's Post-Quantum FAQ](https://csrc.nist.gov/projects/post-quantum-cryptography/faqs) section "To protect against the threat of quantum computers, should we double the key length for AES now? (added 11/18/18)"
#### Recommendations for users using private channels
- **Do not configure private channels on unattended nodes**. Nodes will relay Meshtastic traffic even if they are not able to decrypt it. Your unattended routers should not have the private PSK configured as it is easy to gain physical access and extract the channel key.
- Keep in mind that everything sent on a channel can be stored and decrypted later by anyone who gains access to the key, even if you locally delete the messages.
- Change your Channel Keys from time to time.
#### Changes since 2.5.0 Firmware release
- Direct Messages are now protected with PKC when messaging between devices on v2.5.0 or newer and key exchange has taken place, messaging to legacy 2.4.3 or older firmware versions are not protected.
- Admin Messages between two v2.5.0 or newer nodes are now protected and additonal relay attack protection in place.
### Integrity
Integrity means ensuring messages cannot be modified without the key.
Meshtastic does not verify the integrity of channel messages to check if they have been tampered with (see [issue #4030](https://github.com/meshtastic/firmware/issues/4030) for details).
#### Recommendations
- Keep in mind that by applying a known plaintext attack, anyone _could_ send messages on a channel even if the channel key is private and secure.
- For developers of third-party applications integrating Meshtastic, include a cryptographic MAC over the message content and PSK. We are also considering an [AEAD secured channel mode which would provide this natively](https://github.com/meshtastic/firmware/issues/4030).
#### Changes since 2.5.0 Firmware release
- Message integrity is checked for Direct Messages or Admin Control when communication is between v2.5.0 or newer firmware.
### Authentication
Authentication means nodes say who they are on the network. Meshtastic does not implement this, so it is trivial to impersonate anyone else if you have access to the channel key
This is because node IDs are based on hardware [MAC address](https://en.wikipedia.org/wiki/MAC_address), which are hardcoded by the manufacturer.
Some other networks like [Yggdrasil](https://yggdrasil-network.github.io/), [cjdns](https://github.com/cjdelisle/cjdns), or [libp2p](https://libp2p.io/) use [public/private key pairs](https://en.wikipedia.org/wiki/Public-key_cryptography), and the Public Key becomes the Node Identity. This makes all messages bigger and/or requires an interactive handshake process.
#### Recommendations
- Keep in mind that the sender field is indicative, and anyone with access to the channel key can trivially lie.
#### Changes since 2.5.0 Firmware release
- The above now only relates to group chats/channels as DM's are protected when messaging between devices on 2.5 or newer, messaging to legacy 2.4 or older devices are not afforded this addition authentication.
## Direct Messages
Direct Messages (DMs) are now implemented using Public Key Cryptography (PKC). This provides a significant upgrade in security compared to the previous channel-based encryption:
- **Message Encryption:** Each DM is encrypted using the recipient's public key, ensuring that only the recipient can decrypt the message with their private key.
- **Digital Signatures:** Messages are signed with the sender's private key, allowing the recipient to verify the sender's identity and ensuring the integrity of the message.
### Prior to 2.5.0 Firmware Release
Previously, DMs were implemented as channel messages with a `to` protobuf field set. This meant anyone in the channel could read all your direct messages. With PKC, this issue is resolved, as only the intended recipient can decrypt and read the message.
### Recommendations
- While PKC significantly enhances the security of DMs, it's still advisable to avoid sharing sensitive information in direct messages without proper verification of the recipient's public key.
## Admin Messages
Admin Messages/Control are now protected by enhanced security features, making sure that critical operations within the network are more secure than ever before.
- **Stronger Encryption:** Admin Messages now use advanced encryption methods to ensure that only the intended recipients can access and read them.
- **Session IDs:** Each administrative session is assigned a unique Session ID, which helps prevent unauthorized access and ensures that messages are not tampered with or replayed.
### Prior to 2.5.0 Firmware Release
Previously, admin messages were not as secure, but with these updates, they are now much better protected against potential attacks and replay attacks.
### Recommendations
- Always ensure that your devices are using the latest firmware to benefit from these improved security features.
- Regularly monitor your network for any unusual activity to maintain a high level of security.

10
docs/about/overview/mesh-alg.mdx
View file

@ -77,15 +77,15 @@ The default messaging provided by Layer 1 is extended by setting the `WantAck` f
If a transmitting node does not receive an ACK (or NAK) packet after a certain expiration time, it will use Layer 1 to attempt a re-transmission of the sent packet. A reliable packet (at this 'zero hop' level) will be resent a maximum of three times. If no ACK or NAK has been received by then the local node will internally generate a NAK (either for local consumption or use by higher layers of the protocol). The re-transmission expiration time is based on the maximum time it would take to receive an (implicit) ACK, taking the airtime of the sent packet and any processing delay into account.
For direct messages, the intended recipient will also send a real ACK all the way back to the original sender, but the device will only retransmit when it received no ACK at all.
### Layer 3: (Naive) Flooding for Multi-Hop Messaging
### Layer 3: Managed Flooding for Multi-Hop Messaging
Given our use-case for the initial release, most of our protocol is built around [flooding](<https://en.wikipedia.org/wiki/Flooding_(computer_networking)>). The implementation is currently 'naive' and doesn't try to optimize flooding, except by abandoning re-transmission once a node has seen a nearby receiver ACK the packet it's trying to flood. This means that up to N re-transmissions of a packet could occur in an N node mesh.
Given the various use-cases and scenarios Meshtastic supports, most of our protocol is built around [flooding](<https://en.wikipedia.org/wiki/Flooding_(computer_networking)>), meaning that every node rebroadcasts a packet it receives, up till a certain hop limit. However, an important difference in Meshtastic is that before rebroadcasting, a node listens a short while to see if no other node already rebroadcasted it. If so, it will not rebroadcast. "Managed Flooding" is therefore a better term.
If any mesh node sees a packet with a HopLimit other than zero, it will decrement that HopLimit and attempt re-transmission on behalf of the original sending node. In order to promote letting nodes that are further away flood the message, such that the message eventually reaches farther, the contention window (see Layer 1) for a flooding message depends on the Signal-to-Noise Ratio (SNR) of the received packet. The CW size is small for a low SNR, such that nodes that are further away are more likely to flood first and closer nodes that hear this will refrain from flooding.
The principle is as follows. If any mesh node sees a packet with a HopLimit other than zero, it will decrement that HopLimit and attempt to rebroadcast on behalf of the original sending node. In order to promote letting nodes that are further away flood the message, such that the message eventually reaches farther, the contention window (see Layer 1) for a flooding message depends on the Signal-to-Noise Ratio (SNR) of the received packet. The CW size is small for a low SNR, such that nodes that are further away are more likely to flood first and closer nodes that hear this will refrain from flooding. An exception to this rule is for the `ROUTER` and `REPEATER` roles, that have a higher priority to rebroadcast and will do so even if they hear another node rebroadcasting.
### Example
Below you see an example topology consisting of four nodes, where at a certain point node 0 wants to send a broadcast message.
Below you see an example topology consisting of four nodes in `CLIENT` mode, where at a certain point node 0 wants to send a broadcast message.
Due to limited coverage, it only reaches nodes 1 and 2. Since node 2 is farther away, its SNR is lower and therefore starts rebroadcasting earlier than 1.
After node 0 received this rebroadcast, its message is acknowledged. Note that a message is already acknowledged once a rebroadcast from any Meshtastic node (whether or not it has the same encryption key) is received.
Since node 1 heard the rebroadcast by 2, it will not rebroadcast again. Node 3 heard the message for the first time and the HopLimit is not yet zero, so it starts a rebroadcast for potential other receivers.
@ -110,6 +110,6 @@ As meshes grow larger and traffic becomes more contentious, the firmware will in
Starting with version 2.4.0, the firmware will scale back Telemetry, Position, and other ancillary port traffic for meshes larger than 40 nodes (nodes seen in the past 2 hours) using the following algorithm:
`ScaledInterval = Interval * (1.0 + ((NumberOfOnlineNodes - 40) * 0.075)))`
`ScaledInterval = Interval * (1.0 + ((NumberOfOnlineNodes - 40) * 0.075))`
For example an active mesh of 62 nodes would scale back `telemetry.device_update_interval` to 79.5 minutes instead of the 30 minute default.

26
docs/about/overview/radio-settings.mdx
View file

@ -79,21 +79,25 @@ Various data-rate options are available when configuring a frequency slot and ar
We have eight LoRa radio presets. These are the most common settings and have been proven to work well:
| Channel setting | Alt Channel Name | Data-Rate | SF / Symbols | Coding Rate | Bandwidth | Link Budget |
| :--------------------: | :--------------: | :-----------------: | :----------: | :---------: | :-------: | :---------: |
| Short Range / Fast| Short Fast| 10.94 kbps| 7 / 128| 4/5| 250| 143dB|
| Short Range / Slow| Short Slow| 6.25 kbps| 8 / 256| 4/5| 250| 145.5dB|
| Medium Range / Fast| Medium Fast| 3.52 kbps| 9 / 512| 4/5| 250| 148dB|
| Medium Range / Slow| Medium Slow| 1.95 kbps| 10 / 1024| 4/5| 250| 150.5dB|
| Long Range / Fast| Long Fast| 1.07 kbps| 11 / 2048| 4/5| 250| 153dB|
| Long Range / Moderate| Long Moderate| 0.34 kbps| 11 / 2048| 4/8| 125| 156dB|
| Long Range / Slow| Long Slow| 0.18 kbps| 12 / 4096| 4/8| 125| 158.5dB|
| Very Long Range / Slow| Very Long Slow| 0.09 kbps| 12 / 4096| 4/8| 62.5| 161.5dB|
| Channel setting | Alt Channel Name | Data-Rate | SF / Symbols | Coding Rate | Bandwidth | Link Budget |
|:----------------------:|:----------------:|:----------:|:------------:|:-----------:|:---------:|:-----------:|
| Short Range / Turbo | Short Turbo | 21.88 kbps | 7 / 128 | 4/5 | 500[^1] | 140dB |
| Short Range / Fast | Short Fast | 10.94 kbps | 7 / 128 | 4/5 | 250 | 143dB |
| Short Range / Slow | Short Slow | 6.25 kbps | 8 / 256 | 4/5 | 250 | 145.5dB |
| Medium Range / Fast | Medium Fast | 3.52 kbps | 9 / 512 | 4/5 | 250 | 148dB |
| Medium Range / Slow | Medium Slow | 1.95 kbps | 10 / 1024 | 4/5 | 250 | 150.5dB |
| Long Range / Fast | Long Fast | 1.07 kbps | 11 / 2048 | 4/5 | 250 | 153dB |
| Long Range / Moderate | Long Moderate | 0.34 kbps | 11 / 2048 | 4/8 | 125 | 156dB |
| Long Range / Slow | Long Slow | 0.18 kbps | 12 / 4096 | 4/8 | 125 | 158.5dB |
| Very Long Range / Slow | Very Long Slow | 0.09 kbps | 12 / 4096 | 4/8 | 62.5 | 161.5dB |
:::note
The link budget used by these calculations assumes a transmit power of 22dBm and an antenna with 0dB gain. Adjust your link budget assumptions based on your actual devices. Data-rate in this table is the theoretical max but doesn't account for packet headers, hops and re-transmissions. Calculations based on data from the official [Semtech LoRa calculator](https://www.semtech.com/design-support/lora-calculator).
:::
![link budget vs data rate plot](/img/about/link-budget-vs-data-rate.webp)
### Custom Settings
Custom settings can be applied by using [supported software](/docs/software).
@ -122,3 +126,5 @@ These frequency slot settings may not have been tested. Use at your own discreti
## Cryptography
The pre-shared key (PSK) used by the devices can be an AES128 or AES256 sequence. Alternatively, encryption can be turned off, which may be useful if you are operating under a Ham Radio license.
[^1]: Short Turbo is the fastest preset and the only one with 500kHz bandwidth. It is not legal to use in all regions due to this wider bandwidth.

22
docs/about/overview/range-test.mdx
View file

@ -30,6 +30,7 @@ values={[
<h5 id="modem-settings-254">Modem Settings</h5>
Default Long_Fast
- **Frequency:** 915MHz
- **Bandwidth:** 250
- **Spread Factor:** 11
@ -37,13 +38,13 @@ Default Long_Fast
<h5 id="node-a-254">Node A</h5>
- **Device:** [RAK4631 Core](https://meshtastic.org/docs/hardware/devices/rak/core-module) with [RAK 5005-O Base Board](https://meshtastic.org/docs/hardware/devices/rak/base-board)
- **Device:** [RAK4631 Core](/docs/hardware/devices/rak-wireless/wisblock/core-module/?rakcore=RAK4631) with [RAK 5005-O Base Board](/docs/hardware/devices/rak-wireless/wisblock/base-board/?rakbase=RAK5005-O)
- **Firmware Version:** 2.1.17
- **Antenna:** 902-928MHz 5.8 dBi Slinkdsco Outdoor
- **Antenna:** 902-928MHz 5.8 dBi Slinkdsco Outdoor
<h5 id="node-b-254">Node B</h5>
- **Device:** [RAK4631 Core](https://meshtastic.org/docs/hardware/devices/rak/core-module) with [RAK 19003 Mini Base Board](https://meshtastic.org/docs/hardware/devices/rak/base-board)
- **Device:** [RAK4631 Core](/docs/hardware/devices/rak-wireless/wisblock/core-module/?rakcore=RAK4631) with [RAK 19003 Mini Base Board](/docs/hardware/devices/rak-wireless/wisblock/base-board/?rakbase=RAK19003)
- **Firmware Version:** 2.1.18
- **Antenna:** Standard LoRa 915MHz 60mm 2dBi Omnidirectional
@ -53,8 +54,7 @@ Default Long_Fast
<img src="/img/records/kboxlabs_map.webp" alt="Geographic Locations" />
##### Previous Record 166km
#### Previous Record 166km
- **Range:** 166km (103 miles)
- **Record Holder:** _PuzzledPancake_
@ -69,13 +69,13 @@ Default Long_Fast
<h5 id="node-a-166">Node A</h5>
- **Device:** [LILYGO TTGO T-Beam w/ SX1262](/docs/hardware/devices/tbeam)
- **Device:** [LILYGO TTGO T-Beam w/ SX1262](/docs/hardware/devices/lilygo/tbeam/?t-beam=sx1262)
- **Firmware Version:** 1.2
- **Antenna:** [868MHz 5dBi Antenna](https://ivent.co.nz/product/category/1000/868mhz%205dbi%20antenna%20193mm%20black%20sma%20%28m%29/38646)
<h5 id="node-b-166">Node B</h5>
- **Device:** [LILYGO TTGO T-Beam w/ SX1262](/docs/hardware/devices/tbeam)
- **Device:** [LILYGO TTGO T-Beam w/ SX1262](/docs/hardware/devices/lilygo/tbeam/?t-beam=sx1262)
- **Firmware Version:** 1.2
- **Antenna:** [868MHz Vertical 6dBi](https://ivent.co.nz/product/category/1000/868mhz%20vertical%206dbi%20antenna/38606)
@ -85,8 +85,7 @@ Default Long_Fast
![Node B](https://canada1.discourse-cdn.com/free1/uploads/meshtastic/optimized/2X/1/1c8bd5fc41f7bab925404b657a9c481882de9313_2_1332x1000.jpeg)
<h5>Resources Used</h5>
- http://www.heywhatsthat.com
<h5>Resources Used</h5>- http://www.heywhatsthat.com
</TabItem>
@ -103,6 +102,7 @@ Default Long_Fast
<h5 id="modem-settings-206">Modem Settings</h5>
Default Long_Fast
- **Frequency:** 915MHz
- **Bandwidth:** 250
- **Spread Factor:** 11
@ -110,13 +110,13 @@ Default Long_Fast
<h5 id="node-a-206">Node A</h5>
- **Device:** [LILYGO TTGO T-Beam](/docs/hardware/devices/tbeam)
- **Device:** [LILYGO TTGO T-Beam](/docs/hardware/devices/lilygo/tbeam/?t-beam=1.1)
- **Firmware Version:** 2.1.10
- **Antenna:** Stock Antenna
<h5 id="node-b-206">Node B</h5>
- **Device:** [LILYGO TTGO T-Beam](/docs/hardware/devices/tbeam)
- **Device:** [LILYGO TTGO T-Beam](/docs/hardware/devices/lilygo/tbeam/?t-beam=1.1)
- **Firmware Version:** 2.1.10 (modified to place GPS in flight mode)
- **Antenna:** Stock Antenna

79
docs/community/local-groups.mdx
View file

@ -16,95 +16,148 @@ them for assistance in getting started or if you're interested in contributing t
organizer with an online presence and wish to be included in this list, please edit this page directly or reach out to
us on [Discord](https://discord.com/invite/ktMAKGBnBs) to add your group.
## Argentina
- [Meshtastic Argentina Community](https://github.com/Meshtastic-Argentina/)
## Australia
### Australian Capital Territory
- [Canberra Meshtastic Community - Discord](https://discord.gg/4QgFsuaC3Z)
### Tasmania
- [Meshtastic User Group Tasmania](https://www.facebook.com/groups/1556630645195649)
## Canada
### Alberta
- [YYC Mesh](https://yycmesh.com/)
- [Mesht Calgary](https://t.me/meshtcalgary)
- [Mesht Alberta](https://t.me/meshtAlta)
### British Columbia
- [Meshtastic BC users group](https://t.me/Mesh_BC)
- [Meshtastic Dawson Creek BC users group](https://t.me/Mesh_BC_Dawson_Creek)
### Manitoba
- [Mesht Manitoba](https://t.me/MeshtManitoba)
### New Brunswick
- [Mesht New Brunswick](https://t.me/MeshtNB)
### Newfoundland
- [Mesht Newfoundland](https://t.me/MeshtNewfoundland)
### Northwest Territories
- [Mesht Northwest Territories](https://t.me/MeshtNWT)
### Nova Scotia
- [Mesht Nova Scotia](https://t.me/MeshtNovaScotia)
### Ontario
- [Mesht Ontario](https://t.me/meshtOnt)
### Prince Edward Island
- [Mesht PEI](https://t.me/MeshtPEI)
### Quebec
- [Mesht Quebec](https://t.me/meshtQuebec)
### Saskatchewan
- [Mesht Saskatchewan](https://t.me/MeshtSaska)
## Denmark
- [Danske Meshtastic Brugere](https://discord.gg/EXWWwDmfBN)
## Finland
- [Mesh Finland Discord](https://discord.com/invite/GHnaVAjqed)
- [Mesh Finland Website](https://mesh-finland.github.io)
## Germany
- [Meshtastic Users D-A-CH](https://t.me/meshtasticgermany) for technical chat
- [Meshtastic Users Germany - Facebook](https://www.facebook.com/share/o6CZ9E35UmDKjp9U/)
- [Mesh Hessen](https://t.me/Mesh_Hessen)
## India
- [India Bir Paragliding](https://bircom.in)
## Israel
- [Israel Meshtastic Club](https://t.me/+yUGsbNw3zp41MGFk)
## Italy
- [Meshtastic Italia Community](https://t.me/meshtastic_italia_community)
- [Mesh_ITA Discord Server](https://discord.gg/ETFmtyzbFT)
## Japan
- [Meshtastic Japan Community](https://www.facebook.com/share/g/BQCGxZhw9SxFQja8/?mibextid=K35XfP)
## Lithuania
- [Meshtastic Lietuva](https://www.facebook.com/groups/1122509422249414)
## Netherlands, The
- [Meshtastic Netherlands Telegram](https://t.me/meshtastic_nl)
- [MeshNet Meshtastic Community](https://www.meshnet.nl/)
## New Zealand
- [New Zealand Meshtastic Community Discord](https://discord.gg/xb9bBZJUpz)
## Poland
- [Meshtastic Poland Matrix Space](https://matrix.to/#/#meshtasticpl:matrix.org)
## Taiwan
- [Meshtastic Taiwan Community 臺灣鏈網 - Facebook](https://www.facebook.com/groups/413628121046386)
- [Meshtastic Taiwan Community 臺灣鏈網 - Discord](https://discord.gg/2vZkuckp8E)
## Türkiye
- [Meshtastic Türkiye Community - Telegram](https://t.me/trmesh)
- [Meshtastic Türkiye Community - Discord](https://discord.gg/7TGnZSSA)
- [Meshtastic Türkiye Community - Discord](https://discord.gg/7TGnZSSA)
- [Meshtastic Türkiye Community - Web](https://trmesh.org)
## Ukraine
- [WiKi Meshtastic UA](https://wikimesh.pp.ua)
## United States
- [Midwest Mesh](https://discord.gg/wYwD56K439)
### Arizona
- [Tucson Meshtastic Community](https://discord.gg/7MzbMMd2kg)
- [Arizona Meshtastic Community](https://azmsh.net)
- [Mesa/Phoenix Meshtastic Community](https://discord.gg/wE39ZyCKu3)
### Arkansas
- [Fort Smith Mesh](https://discord.com/invite/nwsvcXeqMX)
### California
- [SoCal Mesh](https://socalmesh.org)
- [Laguna Mesh](https://lagunamesh.com)
- [Mission Viejo Mesh](https://missionviejomesh.org/)
@ -117,41 +170,65 @@ us on [Discord](https://discord.com/invite/ktMAKGBnBs) to add your group.
- [Sac Valley Mesh](http://www.sacvalleymesh.com)
### Colorado
- [Denver Mesh](https://denvermesh.org)
### Hawaii
- [Hawaii Meshnet](https://www.hawaiimesh.net/)
### Illinois
- [Chicagoland Mesh](https://chicagolandmesh.org)
### Kansas
- [SecKC Amateur Radio Club of Kansas City and Surrounding Cities for Amateur Radio](https://ks3ckc.radio/home)
### Massachusetts
- [Boston Meshnet](https://github.com/Darachnid/Boston-Meshnet)
### Michigan
- [Michigan Meshtastic Network](https://discord.gg/3A5RREcBcc)
### Missouri
- [Kansas City Meshtastic Group](https://www.facebook.com/share/XZ9jnhxy1YT4wWqC/)
- [MeshSTL - St. Louis](https://discord.gg/QYxUdKZpBd)
### Nevada
- [VegasMesh Discord](https://discord.gg/vUmWuZxYPh)
### New Mexico
- [Albuquerque Mesh](https://www.abqm.net)
### Ohio
- [Cincy Mesh](https://www.cincymesh.org)
### Oklahoma
- [Oklahoma Meshtastic Group](https://www.facebook.com/groups/942404880478488)
### Oregon
- [Southern Oregon Meshtastic Community](https://sites.google.com/view/someshtastic/home)
- [PDXMesh for Portland & SW Washington](https://pdxmesh.com)
- [Willamette Valley Mesh Eugene / Springfield](https://discord.gg/gf4mShtJz4)
### Tennessee
- [Nashville Meshville](https://meshville.org/)
### Texas
- [Austin Mesh](https://austinmesh.org/)
- [Cypress, Texas Meshtastic Club](https://discord.gg/KzuwNRwE6q)
### Wisconsin
- [Meshconsin](https://meshconsin.org)

2
docs/community/software/index.mdx
View file

@ -12,6 +12,8 @@ Current community projects:
- [Meshtasticator (Simulator)](/docs/community/software/community-meshtasticator) - Meshtasticator is a discrete-event and interactive simulator that mimics the radio section of the device software.
- [Meshtastic Web API](/docs/community/software/meshtastic-web-api) - Meshtastic Web API provides a RESTful interface to interact with a Meshtastic node via a serial connection.
- [Mesh-metrics](/docs/community/software/community-mesh-metrics) - Meshtastic repeater metrics scraper using meshtastic-cli to be ingested by node_exporter for use in Prometheus or Victoria Metrics Time series DB with a Grafana dashboard and sample alerting rules.
- [Node-RED Messages Node](/docs/community/software/community-node-red-messages) - Node-RED node to send and receive packets / text messages from a device connected via HTTP.
- [MQTT Connect for Meshtastic](https://github.com/pdxlocations/MQTT-Connect-for-Meshtastic) - A nodeless python client for communicating with Meshtastic devices over MQTT.
Support for these projects should be sought from their respective authors.

37
docs/community/software/node-red-messages.mdx Normal file
View file

@ -0,0 +1,37 @@
---
id: community-node-red-messages
title: Node-RED Messages Node
sidebar_label: Node-RED Messages
sidebar_position: 4
---
:::note
This is a community project maintained by @danpeig.
Development can be followed on [GitHub](https://github.com/danpeig/node-red-meshtastic-msg).
Support should be sought from the respective authors.
:::
## Overview
This [Node-RED](https://nodered.org) node allows sending and receiving packets to a Meshtastic mesh network thru a device connected via HTTP.
It is based on [Meshtastic.js](https://js.meshtastic.org/) library.
## Features
- Send and receive text messages to/from any device in the mesh
- Supervise/monitor device status
- Subscribe and receive all types of events supported by [Meshtastic.js](https://js.meshtastic.org/) (examples: Atak, Position, Range Test, Map Report, Store and Forward, etc...)
- Send packets to any Meshtastic APP (port num)
- Plug and Play: no additional servers, no containers, no CLI, no binary files, super simple configuration
- Indirect support to MQTT via uplink/downlink channels
## Limitations
- Connect directly to the MQTT server: this is not supported by [Meshtastic.js](https://js.meshtastic.org/)
- Connect to a device via Bluetooth or Serial (not implemented yet)
## Instructions
For installation and usage instructions, please visit the project page at [GitHub](https://github.com/danpeig/node-red-meshtastic-msg).
## Screenshot
![Node-RED Meshtastic Messages node](</img/community/node-red_messages_flow_example.webp>)

32
docs/configuration/module/canned-message.mdx
View file

@ -34,14 +34,15 @@ The list of pre-set messages as configured by the user. Messages should be separ
### Input Source
Input event sources accepted by the canned message module.
| Value | Description |
| :----------: | :------------------------------------------------------------------: |
| `_any` | Default. Allows any peripheral input device connected to the device. |
| `rotEnc1` | Basic Rotary Encoder |
| `upDownEnc1` | Up Down Encoder (use this also for RAK14006 Rotary Encoder) |
| `cardkb` | M5 Stack CardKB (this covers RAK14004 Keymatrix) |
| `serialkb` | Chatter serial keypad |
| Value | Description |
| :-------------: | :------------------------------------------------------------------: |
| `_any` | Default. Allows any peripheral input device connected to the device. |
| `rotEnc1` | Basic Rotary Encoder |
| `upDownEnc1` | Up Down Encoder (use this also for RAK14006 Rotary Encoder) |
| `scanAndSelect` | Single push-button (short and long press) |
| `cardkb` | M5 Stack CardKB (this covers RAK14004 Keymatrix) |
| `serialkb` | Chatter serial keypad |
### Rotary Encoder Enabled
@ -236,6 +237,21 @@ If you don't want to broadcast your freetext message, you can use the CardKB to
Just use UP/DOWN/ENTER to select a predefined message and send it.
### Scan and Select
Use a single push-button to select and send predefined messages.
#### Setup
* Connect a normally-open push-button between ground and a GPIO pin of your choice
* Configure the canned messages module
- Set [Input Source](#input-source) to `scanAndSelect`
- Set [Input Broker Pin Press](#input-broker-pin-press) to your chosen GPIO
- Define a [list of pre-set messages](#messages)
#### Usage
* Short press: scroll through messages
* Long press: send the currently highlighted message to your primary channel
### Rotary encoder
Meshtastic supports hardwired rotary encoders as input devices.

52
docs/configuration/module/mqtt.mdx
View file

@ -10,11 +10,10 @@ import TabItem from "@theme/TabItem";
If your device is connected to Internet via wifi or ethernet, you can enable it to forward packets along to an MQTT server. This allows users on the local mesh to communicate with users on the internet. One or more channels must also be enabled as uplink and/or downlink for packets to be transmitted from and/or to your mesh (See [channels](/docs/configuration/radio/channels#downlink-enabled)). Without these settings enabled, the node will still connect to the MQTT server but only send status messages.
The MQTT module config options are: Enabled, Server Address, Username, Password, Encryption Enabled, JSON Enabled, TLS Enabled, Root Topic, Client Proxy Enabled, Map Reporting Enabled (with Position Precision and Publish Interval). MQTT Module config uses an admin message sending a `ConfigModule.MQTT` protobuf.
The MQTT module config options are: Enabled, Server Address, Username, Password, Encryption Enabled, JSON Enabled, TLS Enabled, Root Topic, Client Proxy Enabled, Map Reporting Enabled (with Position Precision and Publish Interval), and Okay to MQTT. MQTT Module config uses an admin message sending a `ConfigModule.MQTT` protobuf.
## Settings
## MQTT Module Config Values
### Enabled
@ -56,27 +55,40 @@ If true, we attempt to establish a secure connection using TLS.
The root topic to use for MQTT messages. This is useful if you want to use a single MQTT server for multiple meshtastic networks and separate them via ACLs.
### Client Proxy Enabled
If true, let the device use the client's (e.g. your phone's) network connection to connect to the MQTT server. If false, it uses the device's network connection which you have to enable via the [network settings](/docs/configuration/radio/network).
### Map Reporting Enabled
Available from firmware version 2.3.2 on.
If true, your node will periodically send an unencrypted map report to the MQTT server to be displayed by online maps that support this packet. This report includes the following information:
- The node's long and short name and ID;
- The node's position (with configurable precision) and altitude;
- The node's hardware model and [role](/docs/configuration/radio/device/#roles);
- The node's firmware version;
- The node's LoRa region, modem preset and primary channel name;
- The node's LoRa region, modem preset and primary channel name;
- Whether the node can be reached on the default channel with known key;
- Number of local online nodes (heard in the last 2 hours, excluding those heard via MQTT).
#### Map Report Position Precision
The precision to use for the position in the map report. Defaults to a maximum deviation of around 1459m.
#### Map Report Publish Interval
How often we should publish the map report to the MQTT server in seconds. Defaults to 900 seconds (15 minutes).
### OK to MQTT
Acceptable values: `true`, `false`
Default is `false`. When set to `true`, this configuration indicates that the user approves the packet to be uploaded to MQTT. If set to `false`, remote nodes are requested not to forward packets to MQTT.
**Important:** This is not a cryptographic solution but a polite request that is enforced in the official firmware.
## MQTT Module Config Client Availability
<Tabs
groupId="settings"
defaultValue="apple"
@ -121,18 +133,19 @@ The following configuration options are available in the Python CLI:
:::
| Setting | Acceptable Values | Default |
| :--------------------------: | :---------------: | :-----------------: |
| mqtt.enabled | `true`, `false` | `false` |
| mqtt.address | `string` |`mqtt.meshtastic.org`|
| mqtt.username | `string` | `meshdev` |
| mqtt.password | `string` | `large4cats` |
| mqtt.encryption_enabled | `true`, `false` | `false` |
| mqtt.json_enabled | `true`, `false` | `false` |
| mqtt.tls_enabled | `true`, `false` | `false` |
| mqtt.root | `string` | |
| mqtt.proxy_to_client_enabled | `true`, `false` | `false` |
| mqtt.map_reporting_enabled | `true`, `false` | `false` |
| Setting | Acceptable Values | Default |
| :--------------------------: | :---------------: | :-------------------: |
| mqtt.enabled | `true`, `false` | `false` |
| mqtt.address | `string` | `mqtt.meshtastic.org` |
| mqtt.username | `string` | `meshdev` |
| mqtt.password | `string` | `large4cats` |
| mqtt.encryption_enabled | `true`, `false` | `false` |
| mqtt.json_enabled | `true`, `false` | `false` |
| mqtt.tls_enabled | `true`, `false` | `false` |
| mqtt.root | `string` | |
| mqtt.proxy_to_client_enabled | `true`, `false` | `false` |
| mqtt.map_reporting_enabled | `true`, `false` | `false` |
| mqtt.config_ok_to_mqtt | `true`, `false` | `false` |
:::tip
@ -191,7 +204,7 @@ Navigate to: Vertical Ellipsis (3 dots top right) > Radio configuration > MQTT:
[![MQTT Settings](/img/modules/mqtt/android_mqtt_encryption_sm.webp)](/img/modules/mqtt/android_mqtt_encryption.webp)
*Optional:* To use your phone's internet connection to send and receive packets over the web, also enable the slider for **MQTT Client Proxy** and skip the Configure Network Settings step below.
_Optional:_ To use your phone's internet connection to send and receive packets over the web, also enable the slider for **MQTT Client Proxy** and skip the Configure Network Settings step below.
[![Client Proxy](/img/modules/mqtt/android_mqtt_proxy_sm.webp)](/img/modules/mqtt/android_mqtt_proxy_encryption.webp)
@ -219,7 +232,7 @@ Navigate to Settings > MQTT: Turn on the slider for MQTT enabled and tap **Save*
[![MQTT Settings 1](/img/modules/mqtt/apple_mqtt_1_encryption_sm.webp)](/img/modules/mqtt/apple_mqtt_1_encryption.webp)
[![MQTT Settings 2](/img/modules/mqtt/apple_mqtt_2_sm.webp)](/img/modules/mqtt/apple_mqtt_2.webp)
*Optional:* To use your phone's internet connection to send and receive packets over the web, also enable the slider for **MQTT Client Proxy** and skip the Configure Network Settings step below.
_Optional:_ To use your phone's internet connection to send and receive packets over the web, also enable the slider for **MQTT Client Proxy** and skip the Configure Network Settings step below.
[![Client Proxy](/img/modules/mqtt/apple_mqtt_1_proxy_sm.webp)](/img/modules/mqtt/apple_mqtt_1_proxy_encryption.webp)
@ -254,6 +267,7 @@ meshtastic --ch-set downlink_enabled true --ch-index 0
```
or chained together:
```shell
meshtastic --ch-set uplink_enabled true --ch-index 0 --ch-set downlink_enabled true --ch-index 0
```
@ -267,6 +281,7 @@ meshtastic --set network.wifi_psk yourpassword
```
or chained together:
```shell
meshtastic --set network.wifi_enabled true --set network.wifi_ssid "your network" --set network.wifi_psk yourpassword
```
@ -282,7 +297,7 @@ Navigate to Config > Module Config > MQTT - Turn on the slider for MQTT enabled
[![MQTT Settings](/img/modules/mqtt/web_mqtt_encryption_sm.webp)](/img/modules/mqtt/web_mqtt_encryption.webp)
*Optional:* To use your client's internet connection to send and receive packets over the web, also enable the slider for **Proxy to Client Enabled** and skip the Configure Network Settings step below.
_Optional:_ To use your client's internet connection to send and receive packets over the web, also enable the slider for **Proxy to Client Enabled** and skip the Configure Network Settings step below.
[![Client Proxy](/img/modules/mqtt/web_mqtt_proxy_sm.webp)](/img/modules/mqtt/web_mqtt_proxy_encryption.webp)
@ -292,7 +307,6 @@ Though this option may be visible in your UI, Client Proxy is not yet functional
:::
##### 2. Enable Channel Uplink & Downlink
Navigate to Channels > Primary: Turn on the sliders for **Uplink Enabled** and **Downlink Enabled** - Click the **Save** icon.

2
docs/configuration/module/serial.mdx
View file

@ -38,7 +38,7 @@ Available Values:
- `TEXTMSG` will allow you to send a string over the serial port to the device, which will be broadcasted as a text message to the default channel. Any text message received from the mesh will be sent to the serial port as follows: `<Short Name>: <text>`.
- `NMEA` will output a NMEA 0183 Data stream containing the internal GPS or fixed position and other node locations as Waypoints (WPL).
- `CALTOPO` will output NMEA 0183 Waypoints (WPL) every 10 seconds for all valid node locations, to be consumed by [CalTopo / SARTopo](/docs/software/integrations/caltopo.mdx).
- `WS85` will parse and compute wind speed data received over serial from the Ecowitt WS85. Transmits valuess via telemetry packet every 5 minutes. Modification of the WS85 weather sensor is required (https://hackaday.io/project/196990-meshtastic-ultrasonic-anemometer-wx-station). If option is not available in app then enable with cli command "meshtastic --set serial.mode 6"
### Receive GPIO Pin
Set the GPIO pin to the RXD pin you have set up.

3
docs/configuration/module/telemetry.mdx
View file

@ -22,7 +22,7 @@ Supported sensors connected to the I2C bus of the device will be automatically d
| BMP180 | 0x76, 0x77 | Temperature and barometric pressure |
| BMP280 | 0x76, 0x77 | Temperature and barometric pressure |
| BME280 | 0x76, 0x77 | Temperature, barometric pressure and humidity |
| BME680 | 0x76, 0x77 | Temperature, barometric pressure, humidity and air resistance |
| BME68x | 0x76, 0x77 | Temperature, barometric pressure, humidity and air resistance |
| MCP9808 | 0x18 | Temperature |
| INA260 | 0x40, 0x41, 0x43 | Current and Voltage |
| INA219 | 0x40, 0x41, 0x43 | Current and Voltage |
@ -31,7 +31,6 @@ Supported sensors connected to the I2C bus of the device will be automatically d
| SHTC3 | 0x70 | Temperature and humidity |
| SHT31 | 0x44 | Temperature and humidity |
| PMSA003I| 0x12 | Concentration units by size and particle counts by size |
| PMSA003I| 0x12 | Concentration units by size and particle counts by size |
| DFROBOT_LARK | 0x42 | Temperature, barometric pressure, humidity, wind direction, wind speed |
## Module Config Values

47
docs/configuration/radio/device.mdx
View file

@ -79,23 +79,11 @@ This setting defines the device's behavior for how messages are rebroadcasted.
| `LOCAL_ONLY` | LOCAL_ONLY - Ignores observed messages from foreign meshes that are open or those which it cannot decrypt. Only rebroadcasts message on the nodes local primary / secondary channels. |
| `KNOWN_ONLY` | KNOWN_ONLY - Ignores observed messages from foreign meshes like LOCAL_ONLY, but takes it a step further by also ignoring messages from nodenums not in the node's known list (NodeDB). |
## Serial Console
Acceptable values: `true` or `false`
Disabling this will disable the SerialConsole by not initializing the StreamAPI.
## TZDEF (Timezone Definition)
The `tzdef` setting allows the local offset to be defined for the device. It uses the TZ Database format to display the correct local time on the device display and in its logs.
To set the timezone, use the POSIX TZ Database string for the relevant region. Here is a list of [supported timezones](https://github.com/nayarsystems/posix_tz_db/blob/master/zones.csv).
## Debug Log
Acceptable values: `true` or `false`
By default we turn off logging as soon as an API client connects. Set this to true to leave the debug log outputting even when API is active.
To set the timezone, use the POSIX TZ Database string for the relevant region. Here is a list of [supported timezones](https://github.com/nayarsystems/posix_tz_db/blob/master/zones.csv). For example, if your region is `America/Los_Angeles`, you would input `PST8PDT,M3.2.0,M11.1.0` as the timezone.
## GPIO for user button
@ -113,10 +101,6 @@ This is the number of seconds between NodeInfo message (containing i.a. long and
This option will enable a double tap, when a supported accelerometer is attached to the device, to be treated as a button press.
## Managed Mode
Enabling Managed mode will restrict access to all radio configurations via client applications. Radio configurations will only be accessible through the Admin channel. To avoid being locked out, make sure the Admin channel is working properly before enabling it.
## Device Config Client Availability
<Tabs
@ -161,24 +145,21 @@ All device config options are available in the python CLI. Example commands are
:::
| Setting | Acceptable Values | Default |
| --------------------------------- | ----------------------------------------------------------------------------------- | ----------------- |
| device.debug_log_enabled | `true`, `false` | `false` |
| Setting | Acceptable Values | Default |
| --------------------------------- | ------------------------------------------------------------------ | ----------------- |
| device.role | `CLIENT`, `CLIENT_MUTE`, `ROUTER`, `REPEATER`, `TRACKER`, `SENSOR` | `CLIENT` |
| device.rebroadcast_mode | `ALL`, `ALL_SKIP_DECODING`, `LOCAL_ONLY` | `ALL` |
| device.serial_enabled | `true`, `false` | `true` |
| device.button_gpio | `0` - `34` | `0` |
| device.buzzer_gpio | `0` - `34` | `0` |
| device.node_info_broadcast_secs | `0` - `UINT MAX` | `10800` (3 hours) |
| device.double_tap_as_button_press | `false`, `true` | `false` |
| device.is_managed | `false`, `true` | `false` |
| device.rebroadcast_mode | `ALL`, `ALL_SKIP_DECODING`, `LOCAL_ONLY` | `ALL` |
| device.button_gpio | `0` - `34` | `0` |
| device.buzzer_gpio | `0` - `34` | `0` |
| device.node_info_broadcast_secs | `3600` - `UINT MAX` | `10800` (3 hours) |
| device.double_tap_as_button_press | `false`, `true` | `false` |
:::tip
Because the device will reboot after each command is sent via CLI, it is recommended when setting multiple values in a config section that commands be chained together as one.
```shell title="Example:"
meshtastic --set device.role CLIENT --set device.debug_log_enabled true
meshtastic --set device.role CLIENT --set device.tzdef UTC0
```
:::
@ -187,18 +168,10 @@ meshtastic --set device.role CLIENT --set device.debug_log_enabled true
meshtastic --set device.role CLIENT
```
```shell title="Disable serial console"
meshtastic --set device.serial_enabled false
```
```shell title="Set `tzdef`"
```shell title="Set tzdef"
meshtastic --set device.tzdef UTC0
```
```shell title="Enable debug logging"
meshtastic --set device.debug_log_enabled true
```
</TabItem>
<TabItem value="web">

38
docs/configuration/radio/lora.mdx
View file

@ -38,7 +38,9 @@ The presets are designed to provide further options for optimizing either speed
The Presets available are as follows, and follow a linear pattern of Fastest \<\-\-\> Slowest, and Shortest \<\-\-\> Longest range:
1. `SHORT_FAST` (Fastest, highest bandwidth, lowest airtime, shortest range)
1. `SHORT_TURBO` (Fastest, highest bandwidth, lowest airtime, shortest range. It is not legal to use in all regions due to it's 500kHz bandwidth.)
1. `SHORT_FAST`
2. `SHORT_SLOW`
@ -169,23 +171,23 @@ LoRa config commands are available in the python CLI. Example commands are below
:::
| Setting | Acceptable Values | Default |
|:---------------------------:|:---------------------------------------------------------------------------------------------------------------------------------------------------------:|:----------------------------:|
| lora.modem_preset | `LONG_FAST`, `LONG_SLOW`, `VERY_LONG_SLOW`, `MEDIUM_SLOW`, `MEDIUM_FAST`, `SHORT_SLOW`, `SHORT_FAST` | `LONG_FAST`, `LONG_MODERATE` |
| lora.use_preset | `false`, `true` | `false` |
| lora.region | `UNSET`, `US`, `EU_433`, `EU_868`, `CN`, `JP`, `ANZ`, `KR`, `TW`, `RU` ,`IN`, `NZ_865`, `TH`, `LORA_24`, `UA_433`, `UA_868`, `MY_433`, `MY_919`, `SG_923` | `UNSET` |
| lora.bandwidth | `31`, `62`, `125`, `250`, `500` | `250` |
| lora.spread_factor | `7`, `8`, `9`, `10`, `11`, `12` | `12` |
| lora.coding_rate | `5`, `6`, `7`, `8` | `8` |
| lora.frequency_offset | `0` to `1000000` | `0` |
| lora.hop_limit | `1`,`2`,`3`,`4`,`5`,`6`,`7` | `3` |
| lora.tx_power | `0` to `30` | `0` |
| lora.tx_enabled | `false`, `true` | `true` |
| lora.channel_num | `0`, `1` to `NUM_CHANNELS` | `0` |
| lora.ignore_mqtt | `false`, `true` | `false` |
| lora.override_duty_cycle | `false`, `true` | `false` |
| lora.sx126x_rx_boosted_gain | `false`, `true` | `false` |
| lora.override_frequency | Any supported frequency the LoRA radio is capable of. Please respect local rules and regulations | `0` |
| Setting | Acceptable Values | Default |
|:---------------------------:|:---------------------------------------------------------------------------------------------------------------------------------------------------------:|:-----------:|
| lora.modem_preset | `LONG_FAST`, `LONG_SLOW`, `VERY_LONG_SLOW`, `MEDIUM_SLOW`, `MEDIUM_FAST`, `SHORT_SLOW`, `SHORT_FAST`, `SHORT_TURBO` | `LONG_FAST` |
| lora.use_preset | `false`, `true` | `false` |
| lora.region | `UNSET`, `US`, `EU_433`, `EU_868`, `CN`, `JP`, `ANZ`, `KR`, `TW`, `RU` ,`IN`, `NZ_865`, `TH`, `LORA_24`, `UA_433`, `UA_868`, `MY_433`, `MY_919`, `SG_923` | `UNSET` |
| lora.bandwidth | `31`, `62`, `125`, `250`, `500` | `250` |
| lora.spread_factor | `7`, `8`, `9`, `10`, `11`, `12` | `12` |
| lora.coding_rate | `5`, `6`, `7`, `8` | `8` |
| lora.frequency_offset | `0` to `1000000` | `0` |
| lora.hop_limit | `1`,`2`,`3`,`4`,`5`,`6`,`7` | `3` |
| lora.tx_power | `0` to `30` | `0` |
| lora.tx_enabled | `false`, `true` | `true` |
| lora.channel_num | `0`, `1` to `NUM_CHANNELS` | `0` |
| lora.ignore_mqtt | `false`, `true` | `false` |
| lora.override_duty_cycle | `false`, `true` | `false` |
| lora.sx126x_rx_boosted_gain | `false`, `true` | `false` |
| lora.override_frequency | Any supported frequency the LoRA radio is capable of. Please respect local rules and regulations | `0` |
:::tip

2
docs/configuration/radio/position.mdx
View file

@ -155,7 +155,7 @@ meshtastic --set position.fixed_position true --setlat 37.8651 --setlon -119.538
:::
```shell title="Set GPS update interval (Default of 0 is 30 seconds)"
```shell title="Set GPS update interval (Default of 0 is 2 Minutes)"
meshtastic --set position.gps_update_interval 0
meshtastic --set position.gps_update_interval 45
```

127
docs/configuration/radio/security.mdx Normal file
View file

@ -0,0 +1,127 @@
---
id: security
title: Security Configuration
sidebar_label: Security
description: This section covers security options for the device such public key, privaate key, and admin key
---
import Tabs from "@theme/Tabs";
import TabItem from "@theme/TabItem";
The security config options are: Public Key, Private Key, Admin Key, Is Managed, Serial Console, Debug Logs, and Admin Channel.
## Security Config Values
### Public Key
Acceptable values: `bytes`
The public key of the device, shared with other nodes on the mesh to allow them to compute a shared secret key for secure communication.
### Private Key
Acceptable values: `bytes`
The private key of the device, used to create a shared key with a remote device for secure communication.**This key should be kept confidential.**
### Admin Key
Acceptable values: `repeated bytes`
The public key(s) authorized to send administrative messages to this node. Only messages signed by these keys will be accepted for administrative control.
### Managed Mode
Acceptable values: `true` or `false`
Enabling Managed Mode restricts access to all radio configurations via client applications. Radio configurations will only be accessible through the Admin channel. Ensure the Admin channel is functioning properly before enabling this mode to avoid being locked out.
### Serial Console
Acceptable values: `true` or `false`
Disabling this will prevent the Serial Console from initializing the Stream API.
### Debug Log
Acceptable values: `true` or `false`
By default, logging is disabled when an API client connects to keep the shared serial link quiet. Set this to true to continue outputting live debug logs over serial or Bluetooth when the API is active.
### Admin Channel Enabled
Acceptable values: `true` or `false`
Allows incoming device control over the insecure legacy admin channel. Enabling this option permits control messages to be received through the older, less secure admin channel.
## Device Config Client Availability
<Tabs
groupId="settings"
defaultValue="apple"
values={[
{label: 'Android', value: 'android'},
{label: 'Apple', value: 'apple'},
{label: 'CLI', value: 'cli'},
{label: 'Web', value: 'web'},
]}>
<TabItem value="android">
#### Android
All Security config options are available for Android.
1. Open the Meshtastic App
2. Navigate to: **Vertical Ellipsis (3 dots top right) > Radio Configuration > Security**
</TabItem>
<TabItem value="apple">
#### Apple
All Security config options are available on iOS, iPadOS and macOS at Settings > Radio Configuration > Security.
</TabItem>
<TabItem value="cli">
#### CLI
All Security config options are available in the python CLI. Example commands are below:
| Setting | Acceptable Values | Default |
| ------------------------------ | ----------------- | ------- |
| security.public_key | `bytes` | `None` |
| security.private_key | `bytes` | `None` |
| security.admin_key | `repeated bytes` | `None` |
| security.is_managed | `true`, `false` | `false` |
| security.serial_enabled | `true`, `false` | `true` |
| security.debug_log_api_enabled | `true`, `false` | `false` |
| security.admin_channel_enabled | `true`, `false` | `false` |
:::tip
Because the device may reboot after each command is sent via CLI, it is recommended when setting multiple values in a config section that commands be chained together as one.
```shell title="Example:"
meshtastic --set security.is_managed false --set device.debug_log_api_enabled true
```
:::
```shell title="Disable serial console"
meshtastic --set security.serial_enabled false
```
```shell title="Enable debug logging"
meshtastic --set security.debug_log_api_enabled true
```
</TabItem>
<TabItem value="web">
#### Web
All Security config options are available in the Web client.
</TabItem>
</Tabs>

192
docs/configuration/region-by-country.mdx
View file

@ -12,173 +12,171 @@ If you'd like to contribute information for your country, click the "Edit this p
### A
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Albania | EU_868<br />EU_433 | |
| Australia | ANZ | |
| Austria | EU_868<br />EU_433 | |
| Country | LoRa Region | Regulatory document |
| --------- | ------------------ | ---------------------------------------------------------------------------------------------------------- |
| Albania | EU_868<br />EU_433 | |
| Australia | ANZ | [IoT Spectrum in Australia](https://www.iot.org.au/wp/wp-content/uploads/2016/12/IoTSpectrumFactSheet.pdf) |
| Austria | EU_868<br />EU_433 | |
### B
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Belgium | EU_868<br />EU_433 | |
| Bosnia-Herzegowina | EU_868<br />EU_433 | |
| Brazil | ANZ | https://www.gov.br/anatel/pt-br/regulado/radiofrequencia/radiacao-restrita |
| Bulgaria | EU_868<br />EU_433 | |
| Country | LoRa Region | Regulatory document |
| ------------------ | ------------------ | --------------------------------------------------------------------------------------------------- |
| Belgium | EU_868<br />EU_433 | |
| Bosnia-Herzegowina | EU_868<br />EU_433 | |
| Brazil | ANZ | [Brazilian Regulations](https://www.gov.br/anatel/pt-br/regulado/radiofrequencia/radiacao-restrita) |
| Bulgaria | EU_868<br />EU_433 | |
### C
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Canada | US | |
| China | CN | |
| Croatia | EU_868<br />EU_433 | |
| Cyprus | EU_868<br />EU_433 | |
| Czech Republic | EU_868<br />EU_433 | |
| Country | LoRa Region | Regulatory document |
| -------------- | ------------------ | -------------------------------------------------------------------------------------------------------------------------------- |
| Canada | US | [LoRaWAN Regional Parameters](https://www.thethingsnetwork.org/docs/lorawan/regional-parameters/) |
| China | CN | [LoRaWAN Regional Parameters](https://lora-alliance.org/wp-content/uploads/2020/11/lorawan_regional_parameters_v1.0.3reva_0.pdf) |
| Croatia | EU_868<br />EU_433 | |
| Cyprus | EU_868<br />EU_433 | |
| Czech Republic | EU_868<br />EU_433 | |
### D
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Denmark | EU_868<br />EU_433 | |
| Country | LoRa Region | Regulatory document |
| ------- | ------------------ | --------------------------------------------------------------------- |
| Denmark | EU_868<br />EU_433 | [Danish Regulations](https://www.retsinformation.dk/eli/lta/2024/490) |
### E
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Estonia | EU_868<br />EU_433 | |
| Country | LoRa Region | Regulatory document |
| ------- | ------------------ | ------------------- |
| Estonia | EU_868<br />EU_433 | |
### F
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| France | EU_868<br />EU_433 | |
| Finland | EU_868<br />EU_433 | |
| Country | LoRa Region | Regulatory document |
| ------- | ------------------ | ------------------- |
| France | EU_868<br />EU_433 | |
| Finland | EU_868<br />EU_433 | |
### G
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Germany | EU_868<br />EU_433 | |
| Greece | EU_868<br />EU_433 | |
| Country | LoRa Region | Regulatory document |
| ------- | ------------------ | ------------------- |
| Germany | EU_868<br />EU_433 | |
| Greece | EU_868<br />EU_433 | |
### H
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Hungary | EU_868<br />EU_433 | |
| Country | LoRa Region | Regulatory document |
| ------- | ------------------ | ------------------- |
| Hungary | EU_868<br />EU_433 | |
### I
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| India | IN | |
| Ireland | EU_868<br />EU_433 | |
| Italy | EU_868<br />EU_433 | |
| Country | LoRa Region | Regulatory document |
| ------- | ------------------ | ------------------- |
| India | IN | |
| Ireland | EU_868<br />EU_433 | |
| Italy | EU_868<br />EU_433 | |
### J
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Japan | JP | |
| Country | LoRa Region | Regulatory document |
| ------- | ----------- | ---------------------------------------------------------------------------------------------- |
| Japan | JP | [Japanese Regulations](https://www.arib.or.jp/english/html/overview/doc/5-STD-T108v1_5-E1.pdf) |
### K
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Korea | KR | |
| Country | LoRa Region | Regulatory document |
| ------- | ----------- | --------------------------------------------------------------------------- |
| Korea | KR | [Korean Regulations](https://qiita.com/ammo0613/items/d952154f1195b64dc29f) |
### L
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Latvia | EU_868<br />EU_433 | |
| Lithauania | EU_868<br />EU_433 | |
| Luxembourg | EU_868<br />EU_433 | |
| Country | LoRa Region | Regulatory document |
| ---------- | ------------------ | ------------------- |
| Latvia | EU_868<br />EU_433 | |
| Lithauania | EU_868<br />EU_433 | |
| Luxembourg | EU_868<br />EU_433 | |
### M
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Malaysia | MY_919<br />MY_433 | |
| Montenegro | EU_868<br />EU_433 | |
| Country | LoRa Region | Regulatory document |
| ---------- | ------------------ | ------------------------------------------------------------------------------------------------------------- |
| Malaysia | MY_919<br />MY_433 | [MCMC Regulations](https://www.mcmc.gov.my/skmmgovmy/media/General/pdf/Short-Range-Devices-Specification.pdf) |
| Montenegro | EU_868<br />EU_433 | |
### N
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Netherlands | EU_868<br />EU_433 | |
| New Zealand | ANZ<br />NZ_865 | |
| North Macedonia | EU_868<br />EU_433 | |
| Norway | EU_868<br />EU_433 | |
| Country | LoRa Region | Regulatory document |
| --------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------- |
| Netherlands | EU_868<br />EU_433 | [Overheid.nl](https://wetten.overheid.nl/BWBR0036378) |
| New Zealand | ANZ<br />NZ_865 | [IoT Spectrum in NZ](https://iotalliance.org.nz/wp-content/uploads/sites/4/2019/05/IoT-Spectrum-in-NZ-Briefing-Paper.pdf) |
| North Macedonia | EU_868<br />EU_433 | |
| Norway | EU_868<br />EU_433 | |
### O
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| ------- | ----------- | ------------------- |
### P
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Poland | EU_868<br />EU_433 | |
| Portugal | EU_868<br />EU_433 | |
| Country | LoRa Region | Regulatory document |
| -------- | ------------------ | ------------------- |
| Poland | EU_868<br />EU_433 | |
| Portugal | EU_868<br />EU_433 | |
### Q
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| ------- | ----------- | ------------------- |
### R
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Romania | EU_868<br />EU_433 | |
| Russia | RU | |
| Country | LoRa Region | Regulatory document |
| ------- | ------------------ | ----------------------------------------------------------------------------------------------------------- |
| Romania | EU_868<br />EU_433 | |
| Russia | RU | [Russian Regulations](https://digital.gov.ru/uploaded/files/prilozhenie-12-k-reshenyu-gkrch-18-46-03-1.pdf) |
### S
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Serbia | EU_868<br />EU_433 | |
| Singapore | SG_923 | |
| Slowakia | EU_868<br />EU_433 | |
| Slowenia | EU_868<br />EU_433 | |
| Spain | EU_868<br />EU_433 | |
| Sweden | EU_868<br />EU_433 | |
| Switzerland | EU_868<br />EU_433 | |
| Country | LoRa Region | Regulatory document |
| ----------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Serbia | EU_868<br />EU_433 | |
| Singapore | SG_923 | [IMDA Regulations](https://www.imda.gov.sg/-/media/imda/files/regulation-licensing-and-consultations/ict-standards/telecommunication-standards/radio-comms/imdatssrd.pdf) |
| Slowakia | EU_868<br />EU_433 | |
| Slowenia | EU_868<br />EU_433 | |
| Spain | EU_868<br />EU_433 | |
| Sweden | EU_868<br />EU_433 | |
| Switzerland | EU_868<br />EU_433 | |
### T
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Taiwan | TW | |
| Thailand | TH | |
| Türkiye | EU_868<br />EU_433 | [Mevzuat](https://www.mevzuat.gov.tr/mevzuat?MevzuatNo=15416&MevzuatTur=7&MevzuatTertip=5), [BTK Frekans Tahsisi](https://www.btk.gov.tr/uploads/pages/frekans-tahsisinden-muaf-telsiz-cihaz-sistemleri-olcutler-633d4ca68c0b1.pdf), [BTK Milli Frekans Planı](https://www.btk.gov.tr/uploads/pages/milli-frekans-plani-23012023.pdf) |
| Country | LoRa Region | Regulatory document |
| -------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Taiwan | TW | [Taiwan Regulations](https://www.ncc.gov.tw/english/files/23070/102_5190_230703_1_doc_C.PDF) |
| Thailand | TH | [LoRaWAN Regional Parameters](https://lora-alliance.org/wp-content/uploads/2020/11/lorawan_regional_parameters_v1.0.3reva_0.pdf) |
| Türkiye | EU_868<br />EU_433 | [Mevzuat](https://www.mevzuat.gov.tr/mevzuat?MevzuatNo=15416&MevzuatTur=7&MevzuatTertip=5), [BTK Frekans Tahsisi](https://www.btk.gov.tr/uploads/pages/frekans-tahsisinden-muaf-telsiz-cihaz-sistemleri-olcutler-633d4ca68c0b1.pdf), [BTK Milli Frekans Planı](https://www.btk.gov.tr/uploads/pages/milli-frekans-plani-23012023.pdf) |
### U
| Country | LoRa Region | Regulatory document |
| ------------------------------ | ------------------ | -------------------------------------------------------------------------------- |
| Ukraine | UA_868<br />UA_433 | |
| United Kingdom (UK) | EU_868<br />EU_433 | [IR2030](https://www.ofcom.org.uk/__data/assets/pdf_file/0028/84970/ir-2030.pdf) |
| United States of America (USA) | US | |
| Country | LoRa Region | Regulatory document |
| ------------------------------ | ------------------ | ------------------------------------------------------------------------------------------------- |
| Ukraine | UA_868<br />UA_433 | [Ukrainian Regulations](https://nkrzi.gov.ua/images/upload/256/5810/PDF_UUZ_19_01_2016.pdf) |
| United Kingdom (UK) | EU_868<br />EU_433 | [IR2030](https://www.ofcom.org.uk/__data/assets/pdf_file/0028/84970/ir-2030.pdf) |
| United States of America (USA) | US | [LoRaWAN Regional Parameters](https://www.thethingsnetwork.org/docs/lorawan/regional-parameters/) |
### V
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| Vatican City | EU_868<br />EU_433 | |
| Country | LoRa Region | Regulatory document |
| ------------ | ------------------ | ------------------- |
| Vatican City | EU_868<br />EU_433 | |
### Y
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| ------- | ----------- | ------------------- |
### Z
| Country | LoRa Region | Regulatory document |
| --- | --- | --- |
| ------- | ----------- | ------------------- |

12
docs/configuration/tips.mdx
View file

@ -15,6 +15,9 @@ It is strongly recommended to keep your [ROLE](/docs/configuration/radio/device#
- `CLIENT` nodes efficiently repeat and route packets as needed.
- They use smart delays for rebroadcasting, improving network stability.
![Client Node Example](/img/configuration/client.webp)
*One example of a 'Client' node. Photo credit: Cully@KBOXLABS*
### Avoid `ROUTER`and `REPEATER`
Using `ROUTER` or `REPEATER` roles unnecessarily can cause serious network issues:
@ -27,9 +30,12 @@ These roles are for very specific applications. Before changing from `CLIENT`, c
Remember: A network of `CLIENT` nodes with a small number of well-placed `ROUTERS` is usually the most efficient and stable configuration.
![Router Node Example](/img/configuration/router.webp)
*One example of a 'Router' node. Photo credit: Cully@KBOXLABS*
## (Not) Sharing Your Location
Telemetry is shared over your [PRIMARY channel](/docs/configuration/radio/channels#role). This means that if your node has acquired GPS coordinates from an integrated GPS chip, or from your mobile device, your coordinates will be sent to the mesh over this channel, using it's defined encryption (if any).
Telemetry is shared over your [PRIMARY channel](/docs/configuration/radio/channels#role). This means that if your node has acquired GPS coordinates from an integrated GPS chip, or from your mobile device, your coordinates will be sent to the mesh over this channel, using its defined encryption (if any).
By default the PRIMARY channel's name is LongFast with the encryption key "AQ==" (Base64 equivalent of Hex 0x01). If this is left unchanged, your location will be shared with all nodes in range that are also using the default channel.
@ -70,6 +76,8 @@ If you would like your nodes to include/expand the "public" mesh, you must use t
It is **strongly** recommended to leave your [MAX HOPS](/docs/configuration/radio/lora#max-hops) set to 3 unless you're sure you need more (or less) to reach your destination node. Unnecessarily high hop counts often lead to network issues.
![Hop Count Image](/img/configuration/max-hops.webp)
## Chat Channels and LoRa Frequency Slots
Previously, Meshtastic used the word "channels" to define two different configuration properties: Messaging Channels & LoRa Channel Numbers. However, this could lead to confusion since "channels" was being used to refer to two distinct concepts. To clarify the distinction, the decision was made to change "LoRa Channel Number" to "LoRa Frequency Slot".
@ -88,4 +96,4 @@ This property, formerly known as "LoRa Channel Number", configures the frequency
- If you are part of a large mesh and don't know what a setting does, don't change it (unless you're super curious).
- TEST your settings and hardware before you install in hard-to-reach locations.
- Connecting a node to the [public MQTT server](/docs/configuration/module/mqtt#connect-to-the-default-public-server) may publish the locations of all nodes in your mesh to the internet. This will also add every globally connected node to your node database and potentially flood your mesh with all types of packets.
- Connecting a node to the [public MQTT server](/docs/configuration/module/mqtt#connect-to-the-default-public-server) may publish the locations of all nodes in your mesh to the internet.

28
docs/development/device/error-codes.mdx
View file

@ -11,16 +11,18 @@ The device might report these fault codes on the screen, but it will also be out
This table is derived from the [protobufs](https://buf.build/meshtastic/protobufs/docs/main:meshtastic#meshtastic.CriticalErrorCode)
:::
| Name | Number | Description |
| :-----------------: | :----: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| TxWatchdog | 1 | A software bug was detected while trying to send LoRa |
| SleepEnterWait | 2 | A software bug was detected on entry to sleep |
| NoRadio | 3 | No LoRa radio hardware could be found |
| Unspecified | 4 | Not normally used |
| UBloxInitFailed | 5 | We failed while configuring a UBlox GPS |
| NoAXP192 | 6 | This board was expected to have a power management chip and it is missing or broken |
| InvalidRadioSetting | 7 | The channel tried to set a radio setting which is not supported by this chipset, radio comms settings are now undefined |
| TransmitFailed | 8 | Radio transmit hardware failure. We sent data to the radio chip, but it did not reply with an interrupt |
| Brownout | 9 | We detected that the main CPU voltage dropped below the minimum acceptable value |
| SX1262Failure | 10 | Selftest of SX1262 radio chip failed |
| RadioSpiBug | 11 | A (likely software but possibly hardware) failure was detected while trying to send packets. If this occurs on your board, please post in the forum so that we can ask you to collect some information to allow fixing this bug |
| Name | Number | Description |
| :--------------------------: | :----: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| TxWatchdog | 1 | A software bug was detected while trying to send LoRa. |
| SleepEnterWait | 2 | A software bug was detected on entry to sleep. |
| NoRadio | 3 | No LoRa radio hardware could be found. |
| Unspecified | 4 | Not normally used. |
| UBloxInitFailed | 5 | Failed while configuring a UBlox GPS. |
| NoAXP192 | 6 | This board was expected to have a power management chip, but it is missing or broken. |
| InvalidRadioSetting | 7 | The channel tried to set a radio setting not supported by this chipset; radio communication settings are now undefined. |
| TransmitFailed | 8 | Radio transmit hardware failure. Data was sent to the radio chip, but it did not respond with an interrupt. |
| Brownout | 9 | Main CPU voltage dropped below the minimum acceptable value. |
| SX1262Failure | 10 | Self-test of the SX1262 radio chip failed. |
| RadioSpiBug | 11 | A failure (likely software, possibly hardware) was detected while sending packets. If this occurs on your board, please post in the forum to help us collect information to fix this bug. |
| FlashCorruptionRecoverable | 12 | Corruption was detected on the flash filesystem, but it was repaired. |
| FlashCorruptionUnrecoverable | 13 | Corruption was detected on the flash filesystem, and it could not be repaired. _Note: Your node will likely need reconfiguration upon the next reboot (e.g., loss of region code)._ |

20
docs/development/documentation/local-dev.mdx
View file

@ -4,10 +4,6 @@ title: Serving Docs Locally for Development
sidebar_label: Local Development
---
:::note
Some things won't display properly like logos or protobufs page, this is not cause for concern.
:::
## Prerequisites
In order to set up your local environment, you will need to install:
@ -24,17 +20,23 @@ Log into GitHub and create a fork of the [meshtastic/meshtastic](https://github.
### Clone your Meshtastic Repository fork
:::note
Replace `username` with your GitHub username.
Replace `YOUR_GITHUB_USERNAME` with your GitHub username.
:::
```shell title="Clone username/Meshtastic Repo"
git clone https://github.com/username/meshtastic.git
```shell title="Clone your Fork of the Documentation Repository"
git clone https://github.com/YOUR_GITHUB_USERNAME/meshtastic.git
```
### Change directory to Local copy
### Change directory into your Local Copy
```shell title="Change Directory"
cd ~/meshtastic
cd ./meshtastic
```
### Install Submodules
```shell title="Install Submodules"
git submodule update --init --recursive
```
### Install Dependencies

14
docs/development/firmware/building.mdx
View file

@ -62,8 +62,20 @@ The build system is modular. Adding a new board variant for an already supported
1. Perform all of the steps [building with custom hardware](#build-with-custom-hardware) until your hardware runs fine.
2. [Send a proposal](https://github.com/meshtastic/firmware/issues/new?assignees=&labels=enhancement%2Ctriage&template=New+Board.yml&title=%5BBoard%5D%3A+) to add a new board.
3. If approved, go to (https://github.com/meshtastic/protobufs) and send a Pull Request for the `mesh.proto` file, adding your board to the `HardwareModel` Enum.
3. If approved, go to [https://github.com/meshtastic/protobufs](https://github.com/meshtastic/protobufs) and send a Pull Request for the `mesh.proto` file, adding your board to the `HardwareModel` Enum.
4. Change your define in `platformio.ini` from `PRIVATE_HW` to `YOUR_BOARD`. Adjust any macro guards in the code you need to support your board.
5. Add your board identifier to `architecture.h` on the firmware repo in the folder of the platform you are using, and send in that Pull Request too.
6. Wait for the Pulls to be merged back into Master.
7. Profit :-)
## Alternative route: Gitpod
Gitpod offers an alternative method for compiling the firmware without installing Visual Studio Code. It is a web browser-based online IDE that can be used with a GitHub account. Gitpod provides a free tier suitable for light use, such as compiling custom firmware.
1. Go to [https://gitpod.io#https://github.com/meshtastic/firmware](https://gitpod.io#https://github.com/meshtastic/firmware).
2. Make the desired changes to the chosen variant.
3. Build the firmware by running: `pio run -e <variant_name>`
4. Once complete, download `<variant_name>.bin` or `<variant_name>.uf2` from `/workspace/firmware/.pio/build/<variant_name>.`
5. As flashing directly to the device isn't possible using Gitpod, upload using either:
- [Drag & Drop](/docs/getting-started/flashing-firmware/nrf52/#drag--drop) for NRF52/RP2040 devices.
- [Web flasher](https://flasher.meshtastic.org/) for ESP32 devices.

78
docs/development/reference/encryption-technical.mdx Normal file
View file

@ -0,0 +1,78 @@
---
id: encryption-technical
title: Updated Security Implementation
sidebar_label: Encryption Technical
sidebar_position: 5
description: Technical Overview of Encryption Employed with Meshtastic from Firmware 2.5.0 Onwards
---
## PSK for Channels, PKC for Direct Messages (DMs) and Admin Messages
Starting with firmware version 2.5.0, which introduces Public Key Cryptography (PKC) for Direct Messages (DMs) and additionally incorporating the use of Session IDs for Admin Messages, the security architecture of Meshtastic has reached a new level of robustness.
Below is a detailed overview of how PSK, PKC, and Session IDs are integrated into your system to secure Channels, Direct Messages, and Admin Messages.
### 1. Chat Channels Using Pre-Shared Key (PSK)
- **PSK Overview:**
- Chat Channels continue to utilize a Pre-Shared Key (PSK) for encrypting communications.
- All participants share the same PSK for their Channels, which is used for both encryption and decryption within the channel.
- **Security Considerations:**
- **Confidentiality:** Only participants with the correct PSK can access messages within the Chat Channel.
- **Key Management:** Secure distribution and regular rotation of the PSK are essential to maintaining the channel's security.
### 2. Direct Messages (DMs) Now Using PKC
- **PKC Implementation for DMs:**
- **Public/Private Key Pairs:** Each node is equipped with a unique public/private key pair. The private key is securely stored on the node, and the public key is shared with other nodes, allowing for secure, authenticated communication.
- **Encryption and Signature:**
- **Encryption:** DMs are encrypted using the recipient’s public key, ensuring only the recipient with the corresponding private key can decrypt the message.
- **Digital Signatures:** Messages are signed with the sender’s private key before encryption, allowing the recipient to verify the sender’s identity and the message’s integrity using the sender’s public key.
- **Security Enhancements with PKC:**
- **Message Confidentiality and Integrity:** With PKC, each DM is encrypted and signed, ensuring that only the intended recipient can read the message, and verifying that it has not been tampered with.
### 3. Admin Messages: Enhanced Security with PKC and Session IDs
- **Key Exchange with DH Curve25519:**
- **Initial Key Exchange Setup:**
- **Key Generation:** A Diffie-Hellman (DH) key exchange occurs using Curve25519 upon first communication between nodes. This generates a shared secret for establishing a symmetric encryption key.
- **Hardware Support:** Curve25519 is supported in hardware, ensuring efficient and secure key exchanges.
- **Shared Secret:** The derived shared secret is used for all subsequent communications between the nodes.
- **Use of Shared Secret for Encryption:**
- **Symmetric Encryption:** Following the key exchange, messages are encrypted and decrypted using the shared secret with symmetric encryption algorithms like AES-CTR or AES-CCM.
- **Efficiency:** Symmetric encryption, especially when based on a secure DH exchange, balances security and performance, making it ideal for real-time applications.
- **Session ID for Admin Messages:**
- **Session ID Usage:** Session IDs are generated for each admin session and used as an additional value inside the encrypted packet. This ensures that each session is secure and unique.
- **Session Duration:** The session ID is valid only for a short duration (e.g., 300 seconds) and is discarded once the session ends or after the next control message is sent.
- **Security Enhancements with PKC and Session ID:**
- **Replay Attack Mitigation:** By utilizing session IDs, replay attacks are effectively mitigated. Old session IDs cannot be reused, ensuring that intercepted packets are invalidated.
- **Isolated Impact:** The use of session IDs confines any issues related to session management to admin messages, without affecting broader communication functions like DMs or Chat Channels.
### 4. Overall Security Architecture
- **Integration of PKC with Existing Systems:**
- **Direct Messages:** PKC enhances the security of DMs by providing encryption, authentication, and integrity through the use of asymmetric encryption and digital signatures.
- **Admin Messages:** The combination of PKC and session IDs secures admin-related operations, providing an additional layer of protection for critical functions.
- **Use of PSK with Existing Systems:**
- **Channels:** PSKs continue to be used for group communication, ensuring secure message exchanges within the channel.
- **Scalability and Performance:**
- **Efficient Use of Resources:** PKC for DMs leverages asymmetric encryption for secure communication, while PSKs for Chat Channels and session IDs for admin messages optimize resource consumption on the platform.
- **Memory Management:** The selective use of PKC, PSKs, and session IDs ensures that memory and computational resources are effectively managed, allowing the system to scale while maintaining high security.
## Conclusion
PSKs and the expanded use of PKC and session IDs across different MCU architectures—ESP32, nRF52, and ARM—demonstrates a tailored approach to security that balances performance, power consumption, and memory management. Each architecture's strengths are leveraged to ensure that secure communications are maintained without compromising the efficiency or scalability of the system. This approach provides robust security for a wide range of applications, from low-power wearable devices to more powerful, feature-rich systems.

4
docs/getting-started/flashing-firmware/esp32/cli-script.mdx
View file

@ -17,9 +17,9 @@ Make sure not to power the radio on without first attaching the antenna! You cou
Before you flash your device start by verifying connectivity with the device being flashed. Outlined below are steps that can be taken to verify connectivity and, if necessary, to install the appropriate drivers. If you end up needing to install drivers be sure to reboot your computer afterwards to verify the installation is complete.
:::note
The [T-Beam 0.7](/docs/hardware/devices/tbeam/?t-beam=0.7) board is an earlier version of the T-Beam board, and due to changes in the design in subsequent iterations this board uses a specific firmware file different from the other T-Beam boards.
The [T-Beam 0.7](/docs/hardware/devices/lilygo/tbeam/?t-beam=0.7) board is an earlier version of the T-Beam board, and due to changes in the design in subsequent iterations this board uses a specific firmware file different from the other T-Beam boards.
`firmware-tbeam0.7-X.X.X.xxxxxxx.bin` is the correct firmware. `firmware-tbeam-X.X.X.xxxxxxx.bin` is incompatible. For all other [T-Beam](/docs/hardware/devices/tbeam) boards `firmware-tbeam-X.X.X.xxxxxxx.bin` is the correct selection.
`firmware-tbeam0.7-X.X.X.xxxxxxx.bin` is the correct firmware. `firmware-tbeam-X.X.X.xxxxxxx.bin` is incompatible. For all other [T-Beam](/docs/hardware/devices/lilygo/tbeam) boards review the resources section for the correct selection.
:::
## Command Line Interface Instructions

10
docs/getting-started/flashing-firmware/nrf52/nrf52-erase.mdx
View file

@ -11,7 +11,7 @@ import Link from "@docusaurus/Link";
Meshtastic uses the [littlefs](https://github.com/littlefs-project/littlefs) library to store configuration, logs, and other data in the internal flash of nRF52 & RP2040 devices. Updating the firmware does _not_ erase this additional data, which can cause issues when the format and location of data changes between releases.
:::info
You may now use the [Meshtastic Web Flasher](https://flasher.meshtastic.org) to Factory Erase your nRF52 or RP2040-based devices. Visit the flasher, select your board, and click the trash can icon to the right of the Flash button. This will open a dialogue to begin the erase procedure.
You may now use the [Meshtastic Web Flasher](https://flasher.meshtastic.org) to Factory Erase your nRF52 or RP2040-based devices. Visit the flasher, select your board, and click the trash can icon to the right of the Flash button. This will open a dialogue to begin the erase procedure.
Alternatively, follow the instructions below.
:::
@ -25,9 +25,10 @@ To reset the flash storage on your nRF52 board:
3. Double click the reset button on your device (this will put it into bootloader mode)
4. Notice a new drive will be mounted on your computer (Windows, Mac, or Linux)
5. Open this drive and you should see three files: `CURRENT.UF2`, `INDEX.HTM`, and `INFO_UF2.TXT`
6. Find the file included in the downloaded firmware named `Meshtastic_nRF52_factory_erase.uf2` and copy it onto the new drive. The device should reboot.
7. With the [Meshtastic CLI](/docs/software/python/cli/) installed, open your Terminal/Console and enter the command: `meshtastic --noproto`.
8. Press any key, you should see the message: `Formatting... Done`.
6. Open the `INFO_UF2.TXT` file with a text editor and note the `SoftDevice` value.
7. Find the file included in the downloaded firmware matching your softdevice major version number (7.x.x or 6.x.x). Either use `Meshtastic_nRF52_factory_erase_v3_S140_7.3.0.uf2` or `Meshtastic_nRF52_factory_erase_v3_S140_6.3.0.uf2` and copy it onto the new drive. The device should reboot.
8. With the [Meshtastic CLI](/docs/software/python/cli/) installed, open your Terminal/Console and enter the command: `meshtastic --noproto`.
9. You should see the message: `Formatting... Done`.
Once the device has been erased, you can proceed to install the latest Meshtastic firmware on a clean storage filesystem by clicking the link below.
@ -41,7 +42,6 @@ To reset the flash storage on your RP2040 board:
4. Copy the flash_nuke.uf2 file to the device.
5. The board will now restart and the flash memory will be erased.
Once the device has been erased, you can proceed to install the latest Meshtastic firmware on a clean storage filesystem by clicking the link below.
<div className="indexCtasBody">

69
docs/getting-started/flashing-firmware/nrf52/update-booloader.mdx Normal file
View file

@ -0,0 +1,69 @@
---
id: update-nrf52-bootloader
title: How to Update or Recover the Bootloader on nRF52 Devices to the Latest Version
sidebar_label: Update nRF52 Bootloader
sidebar_position: 5
description: Instructions for updating or recovering the bootloader on nRF52 devices.
---
If you're experiencing issues with updating or flashing newer versions of the Meshtastic firmware, and your nRF52 device is not running the latest bootloader version, updating the bootloader may resolve these problems.
To check which version of the bootloader your device is running, place the device into DFU mode. Then, open the mounted drive that appears on your computer and check the `INFO_UF2.TXT` file.
## Updating bootloader
Below are the steps to update your bootloader.
### Method 1: Using the UF2 File (Recommended)
Depending on your device, you need to select the correct bootloader package. Below are the links to the bootloader packages:
- [Lilygo T-Echo](https://github.com/meshtastic/firmware/raw/master/bin/update-lilygo_techo_bootloader-0.6.1_nosd.uf2)
- [RAK4631](https://github.com/RAKWireless/WisBlock/raw/master/bootloader/RAK4630/Latest/wiscore_rak4631_board_bootloader-0.4.3_s140_6.1.1.uf2)
- [Seeed Tracker 1000-E](https://github.com/adafruit/Adafruit_nRF52_Bootloader/releases/download/0.9.2/update-t1000_e_bootloader-0.9.2_nosd.uf2)
- [Generic Meshtastic 6.1.1 for DIY](https://github.com/meshtastic/firmware/raw/master/bin/generic/Meshtastic_6.1.0_bootloader-0.9.2_s140_6.1.1.zip)
- [Generic Meshtastic 7.3.0 for DIY](https://github.com/meshtastic/firmware/raw/master/bin/generic/Meshtastic_7.3.0_bootloader-0.9.2_s140_7.3.0.zip)
1. Download the correct UF2 Bootloader File.
2. Connect your device to your computer via USB.
3. Activate bootloader mode by quickly double pressing the RESET button on your device. For The Seeed Tracker 1000-E, you need to press-and-hold the user button and quickly connect the USB cable to the magsafe port twice. The device should appear as a removable drive on your computer.
4. Drag and drop the UF2 file you downloaded into the removable drive. The device will automatically update the bootloader and reset.
5. Once the device resets, the update is complete. Your device is now running the latest bootloader version and you can proceed with [flashing the firmware](/docs/getting-started/flashing-firmware/nrf52/drag-n-drop/).
### Method 2: Using adafruit-nrfutil
:::caution
Unlike uf2 uploads, adafruit-nrfutil does not check if you have the correct bootloader package for your device. If you flash the wrong bootloader, you may brick your device. Please also verify the SHA256 checksum before flashing.
:::
:::info
These instructions assume you have python and pip already installed. If you do not, please install the latest verion of python (which includes pip) from [Python.org](https://www.python.org/downloads/).
:::
Depending on your device, you need to select the correct bootloader package. Below are the links to the bootloader packages:
- [Lilygo T-Echo](https://github.com/meshtastic/firmware/raw/master/bin/lilygo_techo_bootloader-0.6.1.zip) SHA256: 85d8a334bbf82802d712e183f29ec5215f06786ca88914687c437aceab75d9cf
- [RAK4631](https://github.com/RAKWireless/WisBlock/raw/master/bootloader/RAK4630/Latest/wiscore_rak4631_board_bootloader-0.4.3_s140_6.1.1.zip) SHA256: 4a216ad2be8be23b80371a11753677c850c5711d3b85129390a416fc47ea0910
- [Seeed Tracker 1000-E](https://github.com/adafruit/Adafruit_nRF52_Bootloader/releases/download/0.9.2/t1000_e_bootloader-0.9.2_s140_7.3.0.zip) SHA256: 8c69f0d43a7aac925055451d7262682d6926d4cfb7ea8240b466dc8f16a692ba
- [Generic Meshtastic 6.1.1 for DIY](https://github.com/meshtastic/firmware/raw/master/bin/generic/update-Meshtastic_6.1.0_bootloader-0.9.2_nosd.uf2) SHA256: 069791053d21e73115d917110aaa09605945f4130d8febc038c902ed40b0822a
- [Generic Meshtastic 7.3.0 for DIY](https://github.com/meshtastic/firmware/raw/master/bin/generic/update-Meshtastic_7.3.0_bootloader-0.9.2_nosd.uf2) SHA256: a3bea38a522e3707b90b387449b4d051abfd80bd43a69fc4db75002c0fe57268
1. Open a terminal or command prompt and install adafruit-nrfutil by running:
```bash
pip install adafruit-nrfutil
```
2. Obtain the correct zip package.
3. Connect your device to your computer via USB.
4. In the terminal or command prompt, navigate to the directory where you downloaded the bootloader zip package and execute the following command, replacing /dev/ttyACM0 with the correct port for your device (Windows users might use COMx):
```bash
adafruit-nrfutil --verbose dfu serial --package <downloaded file>.zip -p /dev/ttyACM0 -b 115200 --singlebank --touch 1200
```
5. Once the process finishes, the update is complete. Your device is now running the latest bootloader version and you can proceed with [flashing the firmware](/docs/getting-started/flashing-firmware/nrf52/drag-n-drop/).

49
docs/getting-started/flashing-firmware/nrf52/update-techo-booloader.mdx
View file

@ -1,49 +0,0 @@
---
id: update-techo-bootloader
title: How to Update the LilyGo T-Echo Bootloader to the Latest Version
sidebar_label: Update T-Echo Bootloader
sidebar_position: 5
description: Instructions for updating the T-Echo bootloader to the latest version for use with Meshtastic.
---
If you're experiencing issues with updating or flashing newer versions of the Meshtastic firmware, and your LilyGo T-Echo is not running the latest bootloader version (0.6.1), updating the bootloader may resolve these problems.
To check which version of the bootloader your device is running, place the device into DFU mode by double-pressing the reset button. Then, open the mounted drive that appears on your computer and check the INFO_UF2.TXT file.
## Updating bootloader
Below are the steps to update your bootloader.
### Method 1: Using the UF2 File (Recommended)
1. Download the Latest UF2 Bootloader File for the T-Echo from [Github](https://github.com/meshtastic/firmware/blob/master/bin/update-lilygo_techo_bootloader-0.6.1_nosd.uf2).
2. Connect your LilyGo T-Echo to your computer via USB.
3. Activate bootloader mode by quickly double pressing the RESET button on your T-Echo. The device should appear as a removable drive on your computer.
4. Drag and drop the .uf2 file you downloaded into the T-Echo's drive. The device will automatically update the bootloader and reset.
5. Once the device resets, the update is complete. Your T-Echo is now running the latest bootloader version and you can proceed with [flashing the firmware](/docs/getting-started/flashing-firmware/nrf52/drag-n-drop/).
### Method 2: Using adafruit-nrfutil
Should flashing the UF2 file to update your bootloader fail, you can use adafruit-nrfutil.
:::info
These instructions assume you have python and pip already installed. If you do not, please install the latest verion of python (which includes pip) from [Python.org](https://www.python.org/downloads/).
:::
1. Open a terminal or command prompt and install adafruit-nrfutil by running:
```bash
pip install adafruit-nrfutil
```
2. Obtain the lilygo_techo_bootloader-0.6.1.zip package from [Github](https://github.com/meshtastic/firmware/blob/master/bin/lilygo_techo_bootloader-0.6.1.zip).
3. Connect your LilyGo T-Echo to your computer via USB.
4. In the terminal or command prompt, navigate to the directory where you downloaded the bootloader zip package and execute the following command, replacing /dev/ttyACM0 with the correct port for your device (Windows users might use COMx):
```bash
adafruit-nrfutil --verbose dfu serial --package lilygo_techo_bootloader-0.6.1.zip -p /dev/ttyACM0 -b 115200 --singlebank --touch 1200
```
5. Once the process finishes, the update is complete. Your T-Echo is now running the latest bootloader version and you can proceed with [flashing the firmware](/docs/getting-started/flashing-firmware/nrf52/drag-n-drop/).

25
docs/hardware/devices/b-and-q-consulting/index.mdx Normal file
View file

@ -0,0 +1,25 @@
---
id: b-and-q-consulting
title: B&Q Consulting Devices
sidebar_label: B&Q Consulting
sidebar_position: 5
---
## [Nano Series](./nano/)
Portable and durable devices designed for Meshtastic.
| Name | MCU | Radio | WiFi | BT | GPS |
| :------------------------------------------- | :---------- | :----- | :----------: | :-: | :-: |
| [Nano G2 Ultra](./nano/?nano-series=g2) | NRF52840 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
| [Nano G1 Explorer](./nano/?nano-series=g1-e) | ESP32 WROOM | SX1262 | 2.4GHz b/g/n | 4.2 | YES |
| [Nano G1](./nano/?nano-series=g1) | ESP32 WROOM | SX1276 | 2.4GHz b/g/n | 4.2 | YES |
## [Station Series](./station-series/)
High power LoRa transceiver designed for Meshtastic Licensed HAM operation.
| Name | MCU | Radio | WiFi | BT | GPS |
| :------------------------------ | :--------------- | :----- | :----------: | :-: | :------: |
| [Station G1](./station-series/) | ESP32 WROOM | SX1262 | 2.4GHz b/g/n | 4.2 | OPTIONAL |
| [Station G2](./station-series/) | ESP32-S3 WROOM-1 | SX1262 | 2.4GHz b/g/n | 5.0 | OPTIONAL |

5
docs/hardware/devices/nano/buttons.mdx → docs/hardware/devices/b-and-q-consulting/nano/buttons.mdx
View file

@ -28,7 +28,7 @@ values={[
- **User/Program Button:**
- **Single press:** Changes the information page displayed on the device's screen.
- **Double press:** Sends an adhoc ping of the device's position to the network.
- **Long press:** Will signal the device to shutdown after 5 seconds (*soft off*).
- **Long press:** Will signal the device to shutdown after 5 seconds (_soft off_).
- **Message Read Button:**
- **Single press:** Clears the New Message LED.
@ -44,7 +44,6 @@ values={[
- **Toggle Up:** Selects Buzzer for Enhanced Message Notification Circuit.
- **Toggle Down:** Selects LED for Enhanced Message Notification Circuit.
</TabItem>
<TabItem value="g1-e">
@ -73,7 +72,5 @@ values={[
</TabItem>
<TabItem value="g1">
</TabItem>
</Tabs>

2
docs/hardware/devices/nano/index.mdx → docs/hardware/devices/b-and-q-consulting/nano/index.mdx
View file

@ -2,7 +2,7 @@
id: nano-series
title: Nano Series
sidebar_label: Nano Series
sidebar_position: 8
sidebar_position: 1
---
import Tabs from "@theme/Tabs";

0
docs/hardware/devices/station-series/buttons.mdx → docs/hardware/devices/b-and-q-consulting/station-series/buttons.mdx
View file

2
docs/hardware/devices/station-series/index.mdx → docs/hardware/devices/b-and-q-consulting/station-series/index.mdx
View file

@ -2,7 +2,7 @@
id: station-series
title: Station Series
sidebar_label: Station Series
sidebar_position: 9
sidebar_position: 2
---
import Tabs from "@theme/Tabs";

35
docs/hardware/devices/heltec-automation/index.mdx Normal file
View file

@ -0,0 +1,35 @@
---
id: heltec-automation
title: HELTEC® Devices
sidebar_label: HELTEC®
sidebar_position: 4
---
## [LoRa 32](./lora32/)
Inexpensive basic ESP32-based boards.
| Name | MCU | Radio | WiFi | BT | GPS |
| :---------------------------------------------------------------- | :---------- | :----- | :----------: | :-: | :-: |
| [LoRa32 V2.1](./lora32/?heltec=v2.1) | ESP32 | SX127x | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 V3/3.1](./lora32/?heltec=v23) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | NO |
| [Wireless Stick Lite V3](./lora32/?heltec=Wireless+Stick+Lite+V3) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | NO |
| [Wireless Tracker v1.0](./lora32/?heltec=tracker-v1.0) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
| [Wireless Tracker v1.1](./lora32/?heltec=tracker-v1.1) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
| [Wireless Paper](./lora32/?heltec=paper) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | NO |
## [Plug & Play Sensors](./sensor/)
| Name | MCU | Radio | WiFi | BT | GPS |
| ----------------------- | ----------- | ------ | ------------ | --- | --- |
| [Capsule V3](./sensor/) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
### [Vision Master](./vision-master/)
Versatile ESP32-S3-based boards E-Ink development boards.
| Name | MCU | Radio | WiFi | BT | GPS |
| :--------------------------------------------------------------- | :--------- | :----- | :----------: | :-: | :-: |
| [Vision Master E213](./vision-master/?heltec=vision_master_e213) | ESP32-S3R8 | SX1262 | 2.4GHz b/g/n | 5.0 | NO |
| [Vision Master E290](./vision-master/?heltec=vision_master_e290) | ESP32-S3R8 | SX1262 | 2.4GHz b/g/n | 5.0 | NO |
| [Vision Master T190](./vision-master/?heltec=vision_master_t190) | ESP32-S3R8 | SX1262 | 2.4GHz b/g/n | 5.0 | NO |

2
docs/hardware/devices/heltec/buttons.mdx → docs/hardware/devices/heltec-automation/lora32/buttons.mdx
View file

@ -1,6 +1,6 @@
---
id: buttons
title: Heltec LoRa 32 Hardware Buttons
title: HELTEC® LoRa 32 Buttons
sidebar_label: Buttons
sidebar_position: 1
---

84
docs/hardware/devices/heltec/index.mdx → docs/hardware/devices/heltec-automation/lora32/index.mdx
View file

@ -1,8 +1,8 @@
---
id: heltec
id: lora32
title: HELTEC® LoRa 32
sidebar_label: HELTEC® LoRa 32
sidebar_position: 7
sidebar_label: LoRa 32
sidebar_position: 1
---
import Tabs from "@theme/Tabs";
@ -16,7 +16,8 @@ values={[
{label: 'LoRa32 V2.1', value: 'v2.1'},
{label: 'LoRa32 V3/V3.1', value:'v3'},
{label: 'Wireless Stick Lite V3', value:'Wireless Stick Lite V3'},
{label: 'Wireless Tracker', value: 'tracker'},
{label: 'Wireless Tracker v1.0', value: 'tracker-v1.0'},
{label: 'Wireless Tracker v1.1', value: 'tracker-v1.1'},
{label: 'Wireless Paper v1.0', value: 'paper-v1.0'},
{label: 'Wireless Paper v1.1', value: 'paper-v1.1'}
]}>
@ -78,7 +79,7 @@ This device may have issues charging a connected battery if utilizing a USB-C to
### V3.1 differences
Firmware remains the same as V3 below. Compare schematics: [V3.0](https://web.archive.org/web/20221127054612/https://resource.heltec.cn/download/WiFi_LoRa32_V3/HTIT-WB32LA(F)_V3_Schematic_Diagram.pdf) and [V3.1](https://resource.heltec.cn/download/WiFi_LoRa_32_V3/HTIT-WB32LA(F)_V3.1_Schematic_Diagram.pdf). Key differences:
Firmware remains the same as V3 below. Compare schematics: [V3.0](<https://web.archive.org/web/20221127054612/https://resource.heltec.cn/download/WiFi_LoRa32_V3/HTIT-WB32LA(F)_V3_Schematic_Diagram.pdf>) and [V3.1](<https://resource.heltec.cn/download/WiFi_LoRa_32_V3/HTIT-WB32LA(F)_V3.1_Schematic_Diagram.pdf>). Key differences:
- Removal of [FDG6322C](https://www.mouser.com/datasheet/2/308/1/FDG6322C_D-2312203.pdf) (a dual N & P channel FET) from the V3.1 power supply.
- Antenna filter values in V3.1 (L11 = 1.8pF, C15 = 2.7nH, C24 = 1.8pF) align more closely with ESP32-S3 reference design than V3.0 (L11 = 1.6nH, C15 = 6.9pF, C24 = 2.4pF).
@ -165,9 +166,73 @@ Image Source: [Heltec](https://resource.heltec.cn/download/Wireless_Stick_Lite_V
</TabItem>
<TabItem value="tracker">
<TabItem value="tracker-v1.0">
## Wireless Tracker
## Wireless Tracker v1.0
:::info
This device may have issues charging a connected battery if utilizing a USB-C to USB-C cable. It's recommended to use a USB-A to USB-C cable.
:::
- **MCU:**
- ESP32-S3FN8 (WiFi & Bluetooth)
- **LoRa Transceiver:**
- Semtech SX1262
- **Frequency Options:**
- 470 - 510 MHz
- 863 - 870 MHz
- 902 - 928 MHz
- **Connectors:**
- USB-C
- Antenna:
- Dedicated 2.4 GHz metal spring antenna for WiFi/Bluetooth
- U.FL/IPEX antenna connector for LoRa and GNSS
### Features
- Onboard 0.96-inch LCD display
- User and Reset Buttons
### Flashing
To flash ESP32-S3 devices like the Wireless Tracker, you typically need to place them in Espressif's firmware download mode. Use the "1200bps reset" button in the web flasher to do this. If this method does not work for any reason, you can follow the manual process below.
:::warning
Do not proceed unless an antenna is connected to avoid possible damage to the device's radio.
:::
The following process will manually place the device into the Espressif Firmware Download mode:
1. Unplug the device.
2. Press and hold the USER button.
3. Plug device in.
4. After 2-3 seconds, release the USER button.
With the device now in the Espressif Firmware Download mode, you can proceed with flashing using one of the supported flashing methods. It's generally recommended to use the [Web Flasher](https://flasher.meshtastic.org/). You can select "Heltec Wireless Tracker" from the device drop-down.
### Pin Map
![HT-Tracker_V1 Pin Map](/img/hardware/HT-Tracker_V1_Pin_Map.webp)
Image Source: [Heltec](https://heltec.org/project/wireless-tracker/)
### Resources
- Firmware file: `firmware-heltec-wireless-tracker-V1-0-X.X.X.xxxxxxx.bin`
- Purchase Links:
:::note
Heltec revised the Wireless Tracker schematics and released a V1.1, most devices being sold are now [V1.1.](/docs/hardware/devices/heltec-automation/lora32/?heltec=tracker-v1.1#resources-4)
:::
</TabItem>
<TabItem value="tracker-v1.1">
## Wireless Tracker v1.1
:::info
This device may have issues charging a connected battery if utilizing a USB-C to USB-C cable. It's recommended to use a USB-A to USB-C cable.
@ -239,8 +304,6 @@ Image Source: [Heltec](https://heltec.org/project/wireless-tracker/)
This device may have issues charging a connected battery if utilizing a USB-C to USB-C cable. It's recommended to use a USB-A to USB-C cable.
:::
- **MCU:**
- ESP32-S3FN8 (WiFi & Bluetooth)
- **LoRa Transceiver:**
@ -281,7 +344,6 @@ This device may have issues charging a connected battery if utilizing a USB-C to
This device may have issues charging a connected battery if utilizing a USB-C to USB-C cable. It's recommended to use a USB-A to USB-C cable.
:::
- **MCU:**
- ESP32-S3FN8 (WiFi & Bluetooth)
- **LoRa Transceiver:**
@ -306,7 +368,7 @@ This device may have issues charging a connected battery if utilizing a USB-C to
### Resources
- Firmware file: `firmware-heltec-wireless-paper-X.X.X.xxxxxxx.bin`
- Purchase Links:
- Purchase Links:
- US
- [Rokland](https://store.rokland.com/collections/heltec-products/products/heltec-wireless-paper-wi-fi-lora-bt)
- International

44
docs/hardware/devices/heltec/peripherals.mdx → docs/hardware/devices/heltec-automation/lora32/peripherals.mdx
View file

@ -1,6 +1,6 @@
---
id: peripherals
title: Heltec ESP32 V3 Supported Peripherals
title: Heltec® LoRa 32 Peripherals
sidebar_label: Peripherals
sidebar_position: 3
---
@ -22,43 +22,48 @@ values={[
## GPS Module
### Introduction
This informational guide outlines the process of enhancing the Heltec ESP32 V3 board by integrating the GT-U7 GPS Module. The addition of this module provides precise GPS capabilities and a real-time clock (RTC), eliminating the need for WiFi or a smartphone for time tracking. This enhancement is particularly beneficial for the mesh, where tracking the duration since the last seen device is crucial.
However, it's important to note that the GPS module increases the power demand of your node. We'll address this by detailing how to incorporate a switch or an NPN 2N2222 transistor into your setup. This enables firmware-controlled power management, conserving battery life without sacrificing functionality.
It is important to note that the GPS module increases the power demand of the node. This guide details the incorporation of a switch or an NPN 2N2222 transistor to enable firmware-controlled power management, conserving battery life without compromising functionality.
### Benefits
- **GPS Capabilities**: Provides the node with the ability to determine its location with high precision, which is invaluable for tracking, mapping, and various other applications requiring location data.
- **Real-Time Clock (RTC)**: Ensures accurate timekeeping on the mesh network without relying on external time sources such as the internet or a connected smartphone.
### Power Consumption Considerations
The GT-U7 module is known for its high power consumption, which can potentially shorten the battery lifespan of the node. To mitigate this, two approaches are recommended:
- **Manual Switch**: A simple on/off switch for the GPS module, allowing for manual power management.
- **NPN 2N2222 Transistor**: Facilitates automatic power control through the firmware, enabling the device to turn off the GPS module based on specific conditions or after a set period.
- **Manual Switch**: A simple on/off switch for the GPS module, allowing for manual power management.
- **NPN 2N2222 Transistor**: Facilitates automatic power control through the firmware, enabling the device to turn off the GPS module based on specific conditions or after a set period.
### Materials Needed
- Heltec ESP32 V3 board
- GT-U7 GPS Module
- NPN 2N2222 Transistor
- Wires and soldering equipment
- (Optional) Switch for manual power control
- Heltec ESP32 V3 board
- GT-U7 GPS Module
- NPN 2N2222 Transistor
- Wires and soldering equipment
- (Optional) Switch for manual power control
### Instructions
1. Solder a cable from the TXD slot on the GPS module to GPIO 48 on Heltec board. (You may choose your own GPIO pin)
2. Solder a cable from the RXD slot on the GPS module to GPIO 47 on Heltec board. (You may choose your own GPIO pin)
3. Solder a cable from the GND slot on the GPS module to GND pin on Heltec board.
4. Solder a cable from left leg of NPN 2N2222 Transistor to VCC skit on GPS module.
5. Solder a cable from Right leg of NPN 2N2222 Transistor to 3V/5V pin on Heltec board.
6. Solder a cable from Middle leg of NPN 2N2222 Transistor to GPIO 48 of Heltec board. (You may choose your own GPIO pin)
7. Go to Meshtastic app > Radio Configurations > Position
8. Set GPS_RX_PIN to 48 (This will communicate to the TXD slot on the GPS)
9. Set GPS_TX_PIN to 47 (This will communicate to the RXD slot on the GPS)
10. Set PIN_GPS_EN to 46 (This will allow the meshtastic firmware to turn off the power on the GPS board with the user button of the Heltec Board by pressing it 3 times)
1. Solder a cable from the TXD slot on the GPS module to GPIO 48 on Heltec board. (You may choose your own GPIO pin)
2. Solder a cable from the RXD slot on the GPS module to GPIO 47 on Heltec board. (You may choose your own GPIO pin)
3. Solder a cable from the GND slot on the GPS module to GND pin on Heltec board.
4. Solder a cable from left leg of NPN 2N2222 Transistor to VCC skit on GPS module.
5. Solder a cable from Right leg of NPN 2N2222 Transistor to 3V/5V pin on Heltec board.
6. Solder a cable from Middle leg of NPN 2N2222 Transistor to GPIO 48 of Heltec board. (You may choose your own GPIO pin)
7. Go to Meshtastic app > Radio Configurations > Position
8. Set GPS_RX_PIN to 48 (This will communicate to the TXD slot on the GPS)
9. Set GPS_TX_PIN to 47 (This will communicate to the RXD slot on the GPS)
10. Set PIN_GPS_EN to 46 (This will allow the meshtastic firmware to turn off the power on the GPS board with the user button of the Heltec Board by pressing it 3 times)
### Wiring Diagram
![HeltecESP32V3-gps-module](</img/hardware/HeltecESP32V3-gps-module.webp>)
![HeltecESP32V3-gps-module](/img/hardware/HeltecESP32V3-gps-module.webp)
### Troubleshooting Tips
@ -88,4 +93,3 @@ Coming Soon
</TabItem>
</Tabs>

11
docs/hardware/devices/heltec-automation/sensor/buttons.mdx Normal file
View file

@ -0,0 +1,11 @@
---
id: buttons
title: Heltec Sensor Hardware Buttons
sidebar_label: Buttons
sidebar_position: 1
---
## Capsule Sensor V3
- **Long press 3 seconds:** Power on or shutdown.
- **Long press 8/16 seconds:** Long press for 8~16 seconds in the shutdown state until the blue indicator lights up. At this time, the device enters the WirelessBoot mode, which can be used to upload firmware.

20
docs/hardware/devices/heltec-sensor/index.mdx → docs/hardware/devices/heltec-automation/sensor/index.mdx
View file

@ -1,8 +1,8 @@
---
id: heltec-sensors
title: Heltec® Plug&Play Sensors
sidebar_label: HELTEC® Sensors
sidebar_position: 7
title: HELTEC® Plug&Play Sensors
sidebar_label: Sensors
sidebar_position: 2
---
import Tabs from "@theme/Tabs";
@ -38,32 +38,38 @@ values={[
:::info
Capsule Sensor V3 uses WirelessBoot mode to upload firmware, exchange information, and print logs through WiFi.
That is, whether you update the firmware locally or via the Web, You need to get the device into WirelssBoot state first.
That is, whether you update the firmware locally or via the Web, You need to get the device into WirelssBoot state first.
:::
Refer to this link for how to upload firmware for Capsule Sensor V3: [**Wireless Boot**](https://docs.heltec.org/en/node/esp32/capsule_sensor_v3/wireless_boot.html#).
### Touch button/Physical button differences
:::warning
Because the touch button is easy to accidentally activate while close to metal or in your pocket, Heltec has discontinued production of this version. However, a small number of samples have entered the market.
:::
- Button differences
![Capsule Sensor V3 Button](</img/hardware/heltec/capsule-sensor-v3-button.webp>)
![Capsule Sensor V3 Button](/img/hardware/heltec/capsule-sensor-v3-button.webp)
- Other hardware differences
1. Removal of [FDG6322C](https://www.mouser.com/datasheet/2/308/1/FDG6322C_D-2312203.pdf) (a dual N & P channel FET) from the physical-button version.
2. Antenna filter values physical-button version (L11 = 1.8pF, C15 = 2.7nH, C24 = 1.8pF) align more closely with ESP32-S3 reference design than touch-button version (L11 = 1.6nH, C15 = 6.9pF, C24 = 2.4pF).
### Features
- Meshtastic preinstalled.
- Built-in battery.
- Sensor replaceable.
### Pin
- Connector:
- Model name: [DF12NB(3.0)-10DS-0.5V(51)](https://resource.heltec.cn/download/Heltec%20Capsule%20Sensor%20V3/Connector.pdf)
- Model name: [DF12NB(3.0)-10DS-0.5V(51)](https://resource.heltec.cn/download/Heltec%20Capsule%20Sensor%20V3/Connector.pdf)
- Pin:
![Capsule Sensor V3 pin](</img/hardware/heltec/capsule-connector.webp>)
![Capsule Sensor V3 pin](/img/hardware/heltec/capsule-connector.webp)
- More pin definitions please refer [Schematic Diagram](https://resource.heltec.cn/download/Heltec%20Capsule%20Sensor%20V3/Capsule_Main_Esp32_Schematic_Diagram.pdf)
### Resources
- Firmware file: `firmware-heltec_capsule_sensor_v3-X.X.X.xxxxxx.bin`
- Purchase links
- International

28
docs/hardware/devices/heltec-automation/vision-master/buttons.mdx Normal file
View file

@ -0,0 +1,28 @@
---
id: buttons
title: Vision Master Hardware Buttons
sidebar_label: Buttons
sidebar_position: 1
---
## Functionality
### Vision Master E213/E290
- **RST Button(side):**
- **Single press:** Resets the device.
- **GPIO21 Button(side):**
- **Long press:** Will signal the device to shutdown after 5 seconds.
- **Single press:** Changes the information page displayed on the device's screen.
- **Double press:** Sends an adhoc ping of the device's position to the network.
- **Triple press:** Enables/Disables the GPS Module on demand. If an NPN Transistor is added it will cut power to the GPS board. The NPN pin must be configured on the PIN_GPS_EN inside the Position module in the App for this switching to work.
### Vision Master T190
- **RST Button(side):**
- **Single press:** Resets the device.
- **BOOT Button(top):**
- **Long press:** Will signal the device to shutdown after 5 seconds.
- **Single press:** Changes the information page displayed on the device's screen.
- **Double press:** Sends an adhoc ping of the device's position to the network.
- **Triple press:** Enables/Disables the GPS Module on demand. If an NPN Transistor is added it will cut power to the GPS board. The NPN pin must be configured on the PIN_GPS_EN inside the Position module in the App for this switching to work.

206
docs/hardware/devices/heltec-automation/vision-master/index.mdx Normal file
View file

@ -0,0 +1,206 @@
---
id: vision-master
title: HELTEC® Vision Master
sidebar_label: Vision Master
sidebar_position: 3
---
import Tabs from "@theme/Tabs";
import TabItem from "@theme/TabItem";
<Tabs
groupId="heltec"
queryString="heltec"
defaultValue="vision_master_e213"
values={[
{label: 'Vision Master E213', value: 'vision_master_e213'},
{label: 'Vision Mater E290', value:'vision_master_e290'},
{label: 'Vision Master T190', value:'vision_master_t190'}
]}>
<TabItem value="vision_master_e213">
## Vision Master E213
- **MCU:**
- ESP32-S3R8 (WiFi & Bluetooth)
- **LoRa Transceiver:**
- HT-RA62(Semtech SX1262)
- **Frequency Options:**
- 433 MHz
- 470 - 510 MHz
- 863 - 870 MHz
- 902 - 928 MHz
- **Connectors:**
- USB-C
- 2x1.25 lithium battery interface
- 2 x SH1.0-4P sensor interface
- Antenna:
- U.FL/IPEX antenna connector for LoRa
- Integrated 2.4 GHz PCB antenna, U.FL/IPEX antenna connector for 2.4 GHz.
### Features
- Onboard 2.13-inch black and white E-Ink display screen
- Boot, Reset, and Custom(GPIO 21) switches
- No GPS
### Flashing
To flash ESP32-S3 devices like the Vission Master E213, you typically need to place them in Espressif's firmware download mode. Use the "1200bps reset" button in the web flasher to do this. If this method does not work for any reason, you can follow the manual process below.
:::warning
Do not proceed unless an antenna is connected to avoid possible damage to the device's radio.
:::
The following process will manually place the device into the Espressif Firmware Download mode:
1. Unplug the device.
2. Press and hold the BOOT button.
3. Plug the device in.
4. After 2-3 seconds, release the BOOT button.
With the device now in the Espressif Firmware Download mode, you can proceed with flashing using one of the supported flashing methods. It's generally recommended to use the [Web Flasher](https://flasher.meshtastic.org/). You can select "Heltec Vision Master E213" from the device drop-down.
### Pin Map
![HT-VME213_PIN_MAP](/img/hardware/heltec/HT-VME213_PIN_MAP.webp)
Image Source: [Heltec](https://resource.heltec.cn/download/HT-VME213/HT-VME213.png)
### Resources
There is an additional interface on the board for 2.4GHz wireless signals. When connecting an external antenna, the resistor needs to be rotated 90 degrees to the left. For more details, please check the [FAQ on Heltec's official website](https://heltec.org/project/vision-master-e213/).
- Firmware file: `firmware-heltec-vision-master-e213-X.X.X.xxxxxxx.bin`
- Purchase Links:
- [Heltec](https://heltec.org/project/vision-master-e213/)
- [AliExpress](https://www.aliexpress.com/item/1005007209756502.html)
</TabItem>
<TabItem value="vision_master_e290">
## Vision Master E290
- **MCU:**
- ESP32-S3R8 (WiFi & Bluetooth)
- **LoRa Transceiver:**
- HT-RA62(Semtech SX1262)
- **Frequency Options:**
- 433 MHz
- 470 - 510 MHz
- 863 - 870 MHz
- 902 - 928 MHz
- **Connectors:**
- USB-C
- 2x1.25 lithium battery interface
- SH1.0-4P sensor interface
- Antenna:
- U.FL/IPEX antenna connector for LoRa
- Integrated 2.4 GHz PCB antenna, U.FL/IPEX antenna connector for 2.4 GHz.
### Features
- Onboard 2.90-inch black and white E-Ink display screen
- Boot, Reset, and Custom(GPIO 21) switches
- Raspberry Pi GPIO famale header - 2x20
- No GPS
### Flashing
To flash ESP32-S3 devices like the Vission Master E290, you typically need to place them in Espressif's firmware download mode. Use the "1200bps reset" button in the web flasher to do this. If this method does not work for any reason, you can follow the manual process below.
:::warning
Do not proceed unless an antenna is connected to avoid possible damage to the device's radio.
:::
The following process will manually place the device into the Espressif Firmware Download mode:
1. Unplug the device.
2. Press and hold the BOOT button.
3. Plug the device in.
4. After 2-3 seconds, release the BOOT button.
With the device now in the Espressif Firmware Download mode, you can proceed with flashing using one of the supported flashing methods. It's generally recommended to use the [Web Flasher](https://flasher.meshtastic.org/). You can select "Heltec Vision Master E290" from the device drop-down.
### Pin Map
![HT-VME290_PIN_MAP](/img/hardware/heltec/HT-VME290_PIN_MAP.webp)
Image Source: [Heltec](https://resource.heltec.cn/download/HT-VME290/HT-VME290%20Pin%20map.png)
### Resources
There is an additional interface on the board for 2.4GHz wireless signals. When connecting an external antenna, the resistor needs to be rotated 90 degrees to the left. For more details, please check the [FAQ on Heltec's official website](https://heltec.org/project/vision-master-e290/).
- Firmware file: `firmware-vision-master-e290-X.X.X.xxxxxxx.bin`
- Purchase Links:
- [Heltec](https://heltec.org/project/vision-master-e290/)
- [AliExpress](https://www.aliexpress.com/item/1005007234361986.html)
</TabItem>
<TabItem value="vision_master_t190">
## Vision Master T190
- **MCU:**
- ESP32-S3R8 (WiFi & Bluetooth)
- **LoRa Transceiver:**
- HT-RA62(Semtech SX1262)
- **Frequency Options:**
- 433 MHz
- 470 - 510 MHz
- 863 - 870 MHz
- 902 - 928 MHz
- **Connectors:**
- USB-C
- 2x1.25 lithium battery interface
- SH1.0-4P sensor interface
- Antenna:
- U.FL/IPEX antenna connector for LoRa
- Integrated 2.4 GHz PCB antenna, U.FL/IPEX antenna connector for 2.4 GHz.
### Features
- Onboard 1.90-inch TFT-LCD color screen
- Boot, Reset, and USER switches
- No GPS
### Flashing
To flash ESP32-S3 devices like the Vission Master T190, you typically need to place them in Espressif's firmware download mode. Use the "1200bps reset" button in the web flasher to do this. If this method does not work for any reason, you can follow the manual process below.
:::warning
Do not proceed unless an antenna is connected to avoid possible damage to the device's radio.
:::
The following process will manually place the device into the Espressif Firmware Download mode:
1. Unplug the device.
2. Press and hold the BOOT button.
3. Plug the device in.
4. After 2-3 seconds, release the BOOT button.
With the device now in the Espressif Firmware Download mode, you can proceed with flashing using one of the supported flashing methods. It's generally recommended to use the [Web Flasher](https://flasher.meshtastic.org/). You can select "Heltec Vision Master T190" from the device drop-down.
### Pin Map
![HT-VMT190_PIN_MAP](/img/hardware/heltec/HT-VMT190_PIN_MAP.webp)
Image Source: [Heltec](https://resource.heltec.cn/download/HT-VMT190/HT-VMT190%20pin%20map.png)
### Resources
There is an additional interface on the board for 2.4GHz wireless signals. When connecting an external antenna, the resistor needs to be rotated 90 degrees to the left. For more details, please check the [FAQ on Heltec's official website](https://heltec.org/project/vision-master-t190/).
- Firmware file: `firmware-vision-master-t190-X.X.X.xxxxxxx.bin`
- Purchase Links:
- [Heltec](https://heltec.org/project/vision-master-t190/)
</TabItem>
</Tabs>

11
docs/hardware/devices/heltec-sensor/buttons.mdx
View file

@ -1,11 +0,0 @@
---
id: buttons
title: Heltec Sensor Hardware Buttons
sidebar_label: Buttons
sidebar_position: 1
---
## Capsule Sensor V3
- **Long press 3 seconds:** Power on or shutdown.
- **Long press 8/16 seconds:** Long press for 8~16 seconds in the shutdown state until the blue indicator lights up. At this time, the device enters the WirelessBoot mode, which can be used to upload firmware.

51
docs/hardware/devices/heltec-sensor/peripherals.mdx
View file

@ -1,51 +0,0 @@
---
id: peripherals
title: Heltec Sensor Peripherals
sidebar_label: Peripherals
sidebar_position: 3
---
import Tabs from "@theme/Tabs";
import TabItem from "@theme/TabItem";
<Tabs
groupId="heltec"
queryString="heltec"
defaultValue="capsule-sensor-v3"
values={[
{label: 'Capsule Sensor V3', value: 'capsule-sensor-v3'},
]}>
<TabItem value="capsule-sensor-v3">
## Capsule Sensor V3
### Introduction
Strong extensibility is an important feature of Capsule Sensor V3. By replacing the sensor module at the bottom of the device, the device can be flexibly used in various occasions.
:::warning
Different sensors may require different firmware versions, and the current version is based on the GNSS version. We will update the other firmware as soon as possible.
:::
### Heltec sensor type
:::info
Each Capsule Sensor V3 comes with a sensor module by default when you buy it, you just need to choose it at the time of purchase. You can also purchase other sensors which is Capsule Sensor V3 from Heltec, and we will continue to expand the variety of these sensors.
:::
- GNSS: [Quectel_L76K_V1](https://resource.heltec.cn/download/Heltec%20Capsule%20Sensor%20V3/Quectel_L76K_V1.1-1.pdf)
- Temperature&Humidity: [GXHTC3_EN_V2.4](https://heltec.org/project/temp-humi-sensor/)
- 3-Axis: [DA217](https://heltec.org/project/3-axis-acceleration-sensor/)
- Atmospheric pressure sensor: [BMP280](https://heltec.org/project/atmospheric-pressure-sensor/)
### Sensor module replacement step
![Capsule Sensor V3 Button](</img/hardware/heltec/capsule-sensor-extensibility.webp>)
1. Shutdown of device.
2. Remove the bottom screw of the device and remove the back cover.
3. Gently remove the old module.
4. Plug in the new sensors.
5. Close the cap and return the screw. If the firmware is not compatible, download a new one.
:::warning
Be careful not to screw too hard, otherwise it will damage the plastic structure. Also note the direction of the charging interface.
:::
</TabItem>
</Tabs>

229
docs/hardware/devices/index.mdx
View file

@ -14,10 +14,11 @@ Meshtastic firmware can be installed on a wide range of development boards. The
While all the boards listed on this page will run Meshtastic and mesh with each other, some current community favorites are:
- RAK Meshtastic Start Kit
- Station G1
- LILYGO LoRa T3-S3
- HELTEC LoRa V3
- RAK Meshtastic Start Kit: [RAK19007](/docs/hardware/devices/rak-wireless/wisblock/base-board/?rakbase=RAK19007)+[RAK4631](/docs/hardware/devices/rak-wireless/wisblock/core-module/?rakcore=RAK4631)
- [HELTEC LoRa V3](/docs/hardware/devices/heltec-automation/lora32/?heltec=v23)
- [Nano G2 Ultra](/docs/hardware/devices/b-and-q-consulting/nano/?nano-series=g2)
- [Station G2](/docs/hardware/devices/b-and-q-consulting/station-series/?station-series=g2)
- [LILYGO LoRa T3-S3](/docs/hardware/devices/lilygo/lora/?t-lora=S3-v1)
Please do your research and choose the board that meets your needs (or maybe already have in a bin somewhere).
@ -26,134 +27,186 @@ Please do your research and choose the board that meets your needs (or maybe alr
- The Semtech SX1262 transceiver is newer than the SX1276 and provides increased receive and transmit performance.
- nRF52-based devices use a fraction of the power compared to ESP32-based devices and are therefore generally preferred for solar and handset applications.
- ESP32-based devices require more power to operate but are typically lower-cost alternatives that do perform well when using house power, or for handsets that only require a day or two of runtime, and for applications that require WiFi connectivity.
:::
### [RAK Wisblock](./rak/)
:::
## RAK®
### [Wisblock](./rak-wireless/wisblock/)
Modular hardware system with Base, Core and Peripheral modules including the low-power and solar ready nRF52840-based Meshtastic Starter Kit (19007 & 4631).
[**WisBlock Core Modules**](./rak/core-module/)<br/>
[**WisBlock Core Modules**](./rak-wireless/wisblock/core-module/)<br/>
| Name | MCU | Radio | WiFi | BT | GPS |
|:-----------------------------------------------|:---------|:-------|:------------:|:---:|:------:|
| [RAK4631](./rak/core-module?rakcore=RAK4631) | nRF52840 | SX1262 | NO | 5.0 | add-on |
| [RAK11200](./rak/core-module?rakcore=RAK11200) | ESP32 | add-on | 2.4GHz b/g/n | 4.2 | add-on |
| [RAK11310](./rak/core-module?rakcore=RAK11310) | RP2040 | SX1262 | NO | NO | add-on |
| [RAK4631](./rak-wireless/wisblock/core-module?rakcore=RAK4631) | nRF52840 | SX1262 | NO | 5.0 | add-on |
| [RAK11200](./rak-wireless/wisblock/core-module?rakcore=RAK11200) | ESP32 | add-on | 2.4GHz b/g/n | 4.2 | add-on |
| [RAK11310](./rak-wireless/wisblock/core-module?rakcore=RAK11310) | RP2040 | SX1262 | NO | NO | add-on |
[**Base Boards**](./rak/base-board/)<br/>
[RAK5005-O](./rak/base-board?rakbase=RAK5005-O)<br/>
[RAK19007](./rak/base-board?rakbase=RAK19007)<br/>
[RAK19003](./rak/base-board?rakbase=RAK19003)<br/>
[RAK19001](./rak/base-board?rakbase=RAK19001)<br/>
[**Base Boards**](./rak-wireless/wisblock/base-board/)<br/>
[RAK5005-O](./rak-wireless/wisblock/base-board?rakbase=RAK5005-O)<br/>
[RAK19007](./rak-wireless/wisblock/base-board?rakbase=RAK19007)<br/>
[RAK19003](./rak-wireless/wisblock/base-board?rakbase=RAK19003)<br/>
[RAK19001](./rak-wireless/wisblock/base-board?rakbase=RAK19001)<br/>
[**WisBlock Displays**](./rak/screens/)<br/>
[RAK1921](./rak/screens?rakscreens=OLED)<br/>
[RAK1400](./rak/screens?rakscreens=E-Ink)<br/>
[**WisBlock Displays**](./rak-wireless/wisblock/screens/)<br/>
[RAK1921](./rak-wireless/wisblock/screens?rakscreens=OLED)<br/>
[RAK1400](./rak-wireless/wisblock/screens?rakscreens=E-Ink)<br/>
[**WisBlock Peripherals**](./rak/peripherals/)<br/>
[RAK1910](./rak/peripherals?rakmodules=GPS) GPS<br/>
[RAK12500](./rak/peripherals?rakmodules=GPS) GPS<br/>
[RAK18001](./rak/peripherals?rakmodules=Buzzer) Buzzer<br/>
[RAK13002](./rak/peripherals?rakmodules=IO) IO<br/>
[**WisBlock Peripherals**](./rak-wireless/wisblock/peripherals/)<br/>
[RAK1910](./rak-wireless/wisblock/peripherals?rakmodules=GPS) GPS<br/>
[RAK12500](./rak-wireless/wisblock/peripherals?rakmodules=GPS) GPS<br/>
[RAK18001](./rak-wireless/wisblock/peripherals?rakmodules=Buzzer) Buzzer<br/>
[RAK13002](./rak-wireless/wisblock/peripherals?rakmodules=IO) IO<br/>
RAK14001 RGB LED<br/>
[RAK12002](./rak/peripherals?rakmodules=RTC) RTC<br/>
[RAK1901](./rak/peripherals?rakmodules=Sensors&sensors=RAK1901) Temperature and Humidity Sensor<br/>
[RAK1902](./rak/peripherals?rakmodules=Sensors&sensors=RAK1902) Barometric Pressure Sensor<br/>
[RAK1906](./rak/peripherals?rakmodules=Sensors&sensors=RAK1906) Environment Sensor<br/>
[RAK12002](./rak-wireless/wisblock/peripherals?rakmodules=RTC) RTC<br/>
[RAK1901](./rak-wireless/wisblock/peripherals?rakmodules=Sensors&sensors=RAK1901) Temperature and Humidity Sensor<br/>
[RAK1902](./rak-wireless/wisblock/peripherals?rakmodules=Sensors&sensors=RAK1902) Barometric Pressure Sensor<br/>
[RAK1906](./rak-wireless/wisblock/peripherals?rakmodules=Sensors&sensors=RAK1906) Environment Sensor<br/>
RAK12013 Radar Sensor<br/>
RAK13800 Ethernet Module<br/>
### [LILYGO® T-Beam](./tbeam/)
## LILYGO®
### [T-Beam](./lilygo/tbeam/)
Boards complete with GPS, 18650 battery holder, and optional screen.
| Name | MCU | Radio | WiFi | BT | GPS |
| :--------------------------------------- | :------- | :---------------- | :----------: | :-: | :-: |
| [T-Beam v0.7](./tbeam/?t-beam=0.7) | ESP32 | SX1276 | 2.4GHz b/g/n | 4.2 | YES |
| [T-Beam v1.1](./tbeam/?t-beam=1.1) | ESP32 | SX1276 | 2.4GHz b/g/n | 4.2 | YES |
| [T-Beam with M8N](./tbeam/?t-beam=m8n) | ESP32 | SX1276<br/>SX1262 | 2.4GHz b/g/n | 4.2 | YES |
| [T-Beam S3-Core](./tbeam/?t-beam=s3core) | ESP32-S3 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
| [T-BeamSUPREME](./tbeam/?t-beam=supreme) | ESP32-S3 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
| Name | MCU | Radio | WiFi | BT | GPS |
| :---------------------------------------------- | :------- | :---------------- | :----------: | :-: | :-: |
| [T-Beam v0.7](./lilygo/tbeam/?t-beam=0.7) | ESP32 | SX1276 | 2.4GHz b/g/n | 4.2 | YES |
| [T-Beam v1.1](./lilygo/tbeam/?t-beam=1.1) | ESP32 | SX1276 | 2.4GHz b/g/n | 4.2 | YES |
| [T-Beam with M8N](./lilygo/tbeam/?t-beam=m8n) | ESP32 | SX1276<br/>SX1262 | 2.4GHz b/g/n | 4.2 | YES |
| [T-Beam S3-Core](./lilygo/tbeam/?t-beam=s3core) | ESP32-S3 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
| [T-BeamSUPREME](./lilygo/tbeam/?t-beam=supreme) | ESP32-S3 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
### [LILYGO® T-Echo](./techo/)
### [T-Echo](./lilygo/techo/)
All-in-one unit with E-Ink screen, GPS and battery in injection-molded case. Features the low-power nRF52840 for long battery life.
| Name | MCU | Radio | WiFi | BT | GPS |
| :----------------- | :------- | :----- | :--: | :-: | :-: |
| [T-Echo](./techo/) | nRF52840 | SX1262 | NO | 5.0 | YES |
| Name | MCU | Radio | WiFi | BT | GPS |
| :------------------------ | :------- | :----- | :--: | :-: | :-: |
| [T-Echo](./lilygo/techo/) | nRF52840 | SX1262 | NO | 5.0 | YES |
### [LILYGO® LoRa](./lora/)
### [LoRa](./lilygo/lora/)
Inexpensive basic ESP32-based boards.
| Name | MCU | Radio | WiFi | BT | GPS |
| :----------------------------------------- | :------- | :--------------------------- | :----------: | :-: | :-: |
| [LoRa32 V1](./lora/?t-lora=v1) | ESP32 | SX127x | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 V1.3](./lora/?t-lora=v1.3) | ESP32 | SX127x | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 V2.0](./lora/?t-lora=v2.0) | ESP32 | SX127x | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 V2.1-1.6](./lora/?t-lora=v2.1) | ESP32 | SX127x | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 V2.1-1.8](./lora/?t-lora=v2.1-1.8) | ESP32 | SX1280 | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 T3-S3 V1.0](./lora/?t-lora=S3-v1) | ESP32-S3 | SX1262<br/>SX1276<br/>SX1280 | 2.4GHz b/g/n | 5.0 | NO |
| Name | MCU | Radio | WiFi | BT | GPS |
| :------------------------------------------------ | :------- | :--------------------------- | :----------: | :-: | :-: |
| [LoRa32 V1](./lilygo/lora/?t-lora=v1) | ESP32 | SX127x | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 V1.3](./lilygo/lora/?t-lora=v1.3) | ESP32 | SX127x | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 V2.0](./lilygo/lora/?t-lora=v2.0) | ESP32 | SX127x | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 V2.1-1.6](./lilygo/lora/?t-lora=v2.1) | ESP32 | SX127x | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 V2.1-1.8](./lilygo/lora/?t-lora=v2.1-1.8) | ESP32 | SX1280 | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 T3-S3 V1.0](./lilygo/lora/?t-lora=S3-v1) | ESP32-S3 | SX1262<br/>SX1276<br/>SX1280 | 2.4GHz b/g/n | 5.0 | NO |
### [LILYGO® T-Deck](./tdeck/)
### [T-Deck](./lilygo/tdeck/)
Standalone device with screen and keyboard
| Name | MCU | Radio | WiFi | BT | GPS |
| :----------------- | :---------- | :----- | :--: | :-: | :-: |
| [T-Deck](./tdeck/) | ESP32-S3FN8 | SX1262 | YES | 5.0 | NO |
| Name | MCU | Radio | WiFi | BT | GPS |
| :------------------------ | :---------- | :----- | :--: | :-: | :-: |
| [T-Deck](./lilygo/tdeck/) | ESP32-S3FN8 | SX1262 | YES | 5.0 | NO |
### [LILYGO® T-Watch S3](./twatch/)
### [T-Watch S3](./lilygo/twatch/)
| Name | MCU | Radio | WiFi | BT | GPS |
| :---------------------- | :------- | :----- | :--: | :-: | :-: |
| [T-Watch S3](./twatch/) | ESP32-S3 | SX1262 | YES | 5.0 | NO |
| Name | MCU | Radio | WiFi | BT | GPS |
| :----------------------------- | :------- | :----- | :--: | :-: | :-: |
| [T-Watch S3](./lilygo/twatch/) | ESP32-S3 | SX1262 | YES | 5.0 | NO |
### [HELTEC® LoRa 32](./heltec/)
## HELTEC®
### [LoRa 32](./heltec-automation/lora32/)
Inexpensive basic ESP32-based boards.
| Name | MCU | Radio | WiFi | BT | GPS |
| :---------------------------------------------------------------- | :---------- | :----- | :----------: | :-: | :-: |
| [LoRa32 V2.1](./heltec/?heltec=v2.1) | ESP32 | SX127x | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 V3/3.1](./heltec/?heltec=v23) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | NO |
| [Wireless Stick Lite V3](./heltec/?heltec=Wireless+Stick+Lite+V3) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | NO |
| [Wireless Tracker](./heltec/?heltec=tracker) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
| [Wireless Paper](./heltec/?heltec=paper) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | NO |
| Name | MCU | Radio | WiFi | BT | GPS |
| :---------------------------------------------------------------------------------- | :---------- | :----- | :----------: | :-: | :-: |
| [LoRa32 V2.1](./heltec-automation/lora32/?heltec=v2.1) | ESP32 | SX127x | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 V3/3.1](./heltec-automation/lora32/?heltec=v23) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | NO |
| [Wireless Stick Lite V3](./heltec-automation/lora32/?heltec=Wireless+Stick+Lite+V3) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | NO |
| [Wireless Tracker v1.0](./heltec-automation/lora32/?heltec=tracker-v1.0) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
| [Wireless Tracker v1.1](./heltec-automation/lora32/?heltec=tracker-v1.1) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
| [Wireless Paper](./heltec-automation/lora32/?heltec=paper) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | NO |
### [Nano Series](./nano/)
### [Plug & Play Sensors](./heltec-automation/sensor/)
| Name | MCU | Radio | WiFi | BT | GPS |
| ----------------------------------------- | ----------- | ------ | ------------ | --- | --- |
| [Capsule V3](./heltec-automation/sensor/) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
### [Vision Master](./heltec-automation/vision-master/)
Versatile ESP32-S3-based boards E-Ink development boards.
| Name | MCU | Radio | WiFi | BT | GPS |
| :--------------------------------------------------------------------------------- | :--------- | :----- | :----------: | :-: | :-: |
| [Vision Master E213](./heltec-automation/vision-master/?heltec=vision_master_e213) | ESP32-S3R8 | SX1262 | 2.4GHz b/g/n | 5.0 | NO |
| [Vision Master E290](./heltec-automation/vision-master/?heltec=vision_master_e290) | ESP32-S3R8 | SX1262 | 2.4GHz b/g/n | 5.0 | NO |
| [Vision Master T190](./heltec-automation/vision-master/?heltec=vision_master_t190) | ESP32-S3R8 | SX1262 | 2.4GHz b/g/n | 5.0 | NO |
## [B&Q Consulting](./b-and-q-consulting/)
### [Nano Series](./b-and-q-consulting/nano/)
Portable and durable devices designed for Meshtastic.
| Name | MCU | Radio | WiFi | BT | GPS |
| :------------------------------------------- | :---------- | :----- | :----------: | :-: | :-: |
| [Nano G2 Ultra](./nano/?nano-series=g2) | NRF52840 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
| [Nano G1 Explorer](./nano/?nano-series=g1-e) | ESP32 WROOM | SX1262 | 2.4GHz b/g/n | 4.2 | YES |
| [Nano G1](./nano/?nano-series=g1) | ESP32 WROOM | SX1276 | 2.4GHz b/g/n | 4.2 | YES |
| Name | MCU | Radio | WiFi | BT | GPS |
| :-------------------------------------------------------------- | :---------- | :----- | :----------: | :-: | :-: |
| [Nano G2 Ultra](./b-and-q-consulting/nano/?nano-series=g2) | NRF52840 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
| [Nano G1 Explorer](./b-and-q-consulting/nano/?nano-series=g1-e) | ESP32 WROOM | SX1262 | 2.4GHz b/g/n | 4.2 | YES |
| [Nano G1](./b-and-q-consulting/nano/?nano-series=g1) | ESP32 WROOM | SX1276 | 2.4GHz b/g/n | 4.2 | YES |
### [Station Series](./station-series/)
### [Station Series](./b-and-q-consulting/station-series/)
High power LoRa transceiver designed for Meshtastic Licensed HAM operation.
| Name | MCU | Radio | WiFi | BT | GPS |
| :------------------------------ | :--------------- | :----- | :----------: | :-: | :------: |
| [Station G1](./station-series/) | ESP32 WROOM | SX1262 | 2.4GHz b/g/n | 4.2 | OPTIONAL |
| [Station G2](./station-series/) | ESP32-S3 WROOM-1 | SX1262 | 2.4GHz b/g/n | 5.0 | OPTIONAL |
| Name | MCU | Radio | WiFi | BT | GPS |
| :------------------------------------------------- | :--------------- | :----- | :----------: | :-: | :------: |
| [Station G1](./b-and-q-consulting/station-series/) | ESP32 WROOM | SX1262 | 2.4GHz b/g/n | 4.2 | OPTIONAL |
| [Station G2](./b-and-q-consulting/station-series/) | ESP32-S3 WROOM-1 | SX1262 | 2.4GHz b/g/n | 5.0 | OPTIONAL |
### [Raspberry Pi Pico](./raspberry-pi/)
## [Raspberry Pi](./raspberrypi/)
### [Raspberry Pi Pico](./raspberrypi/pico/)
Fast versatile boards using the RP2040.
| Name | MCU | Radio | WiFi | BT | GPS |
| :----------------------------------- | :----- | :----- | :----------: | :-----------: | :-: |
| [Raspberry Pi Pico](./raspberry-pi/) | RP2040 | SX1262 | 2.4GHz b/g/n | not supported | NO |
| Name | MCU | Radio | WiFi | BT | GPS |
| :-------------------------------------- | :----- | :----- | :----------: | :-----------: | :-: |
| [Raspberry Pi Pico](./raspberrypi/pico) | RP2040 | SX1262 | 2.4GHz b/g/n | not supported | NO |
[**Pico Peripherals**](./raspberry-pi/peripherals/)<br/>
[**Pico Peripherals**](./raspberrypi/pico/peripherals/)<br/>
SSD1306 OLED Display<br/>
SH1106 OLED Display<br/>
CardKB Keyboard<br/>
### [CanaryOne](./canary)
### [Raspberry Pi Zero/Zero2/3/4/400/5](./linux-native-hardware/)
Meshtastic offers support for Raspberry Pi devices through our Linux native platform, meshtasticd. For full information, please see our [Linux Native Hardware](./linux-native-hardware/) documentation.
## Seeed Studio
### SenseCap
The SenseCAP product line offers a comprehensive range of solutions for both hobbyists and industrial users, featuring the T1000-E card tracker, an IP65-rated, ready-to-go Meshtastic device, and the Indicator with a 4-inch touchscreen driven by ESP32-S3 and RP2040 Dual-MCU, coming soon.
| Name | MCU | Radio | WiFi | BT | GPS |
| ------------------------------------------------------------- | ------------- | ------ | ---- | --- | --- |
| [Card Tracker T1000-E](./seeed-studio/sensecap/card-tracker/) | nRF52840 | LR1110 | NO | 5.1 | YES |
| [SenseCAP Indicator](./seeed-studio/) (coming soon) | ESP32, RP2040 | - | - | - | - |
### [Seeed Wio-WM1110](./seeed-studio/wm1110)
nRF52840-based development boards with GPS, and multiple ports to attach sensors.
| Name | MCU | Radio | WiFi | BT | GPS |
| :------------------------------------------------------------------------ | :------- | :----- | :--: | :-: | :-: |
| [Seeed Wio-WM1110 Dev Kit](./seeed-studio/wm1110?wm1110=wio-sdk-wm1110) | nRF52840 | LR1110 | YES | 5.3 | YES |
| [Seeed Wio Tracker 1110](./seeed-studio/wm1110?wm1110=wio-tracker-wm1110) | nRF52840 | LR1110 | YES | 5.3 | YES |
## [CanaryOne](./canary)
Complete solution with battery, screen, case, and antenna. Ships pre-flashed with latest Meshtastic firmware.
@ -161,7 +214,7 @@ Complete solution with battery, screen, case, and antenna. Ships pre-flashed wit
| :-------------------- | :------- | :----- | :--: | :-: | :-: |
| [CanaryOne](./canary) | nRF52840 | SX1262 | NO | 5.0 | YES |
### [unPhone](./unPhone)
## [unPhone](./unPhone)
All-in-one development device with LoRa, WiFi, BT, touchscreen, accelerometer, gyroscop, vibration motor, LiPo battery and more!
@ -169,12 +222,10 @@ All-in-one development device with LoRa, WiFi, BT, touchscreen, accelerometer, g
| :------------------- | :--------------- | :----- | :--: | :-: | :-: |
| [unPhone](./unPhone) | ESP32-S3-WROOM-1 | RF950W | YES | 5.0 | NO |
### [Seeed Wio-WM1110](./seeed-wm1110)
## [Chatter](./chatter)
nRF52840-based development boards with GPS, and multiple ports to attach sensors.
| Name | MCU | Radio | WiFi | BT | GPS |
| :--------------------------------------------------------- | :------- | :----- | :--: | :-: | :-: |
| [Seeed Wio-WM1110 Dev Kit](./seeed-wm1110?wio-sdk-wm1110) | nRF52840 | LR1110 | YES | 5.3 | YES |
| [Seeed Wio Tracker 1110](./seeed-wm1110?wio-tracker-wm1110) | nRF52840 | LR1110 | YES | 5.3 | YES |
DIY kit with ESP32, LoRa chip, and optional GPS. Designed for STEM education.
| Name | MCU | Radio | WiFi | BT | GPS |
| :------------------- | :---- | :----- | :--: | :-: | :-: |
| [Chatter](./chatter) | ESP32 | LLCC68 | YES | 4.2 | No |

53
docs/hardware/devices/lilygo/index.mdx Normal file
View file

@ -0,0 +1,53 @@
---
id: lilygo
title: LILYGO® Devices
sidebar_label: LILYGO®
sidebar_position: 2
---
## [T-Beam](./tbeam/)
Boards complete with GPS, 18650 battery holder, and optional screen.
| Name | MCU | Radio | WiFi | BT | GPS |
| :--------------------------------------- | :------- | :---------------- | :----------: | :-: | :-: |
| [T-Beam v0.7](./tbeam/?t-beam=0.7) | ESP32 | SX1276 | 2.4GHz b/g/n | 4.2 | YES |
| [T-Beam v1.1](./tbeam/?t-beam=1.1) | ESP32 | SX1276 | 2.4GHz b/g/n | 4.2 | YES |
| [T-Beam with M8N](./tbeam/?t-beam=m8n) | ESP32 | SX1276<br/>SX1262 | 2.4GHz b/g/n | 4.2 | YES |
| [T-Beam S3-Core](./tbeam/?t-beam=s3core) | ESP32-S3 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
| [T-BeamSUPREME](./tbeam/?t-beam=supreme) | ESP32-S3 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
## [T-Echo](./techo/)
All-in-one unit with E-Ink screen, GPS and battery in injection-molded case. Features the low-power nRF52840 for long battery life.
| Name | MCU | Radio | WiFi | BT | GPS |
| :----------------- | :------- | :----- | :--: | :-: | :-: |
| [T-Echo](./techo/) | nRF52840 | SX1262 | NO | 5.0 | YES |
## [LoRa32](./lora/)
Inexpensive basic ESP32-based boards.
| Name | MCU | Radio | WiFi | BT | GPS |
| :----------------------------------------- | :------- | :--------------------------- | :----------: | :-: | :-: |
| [LoRa32 V1](./lora/?t-lora=v1) | ESP32 | SX127x | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 V1.3](./lora/?t-lora=v1.3) | ESP32 | SX127x | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 V2.0](./lora/?t-lora=v2.0) | ESP32 | SX127x | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 V2.1-1.6](./lora/?t-lora=v2.1) | ESP32 | SX127x | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 V2.1-1.8](./lora/?t-lora=v2.1-1.8) | ESP32 | SX1280 | 2.4GHz b/g/n | 4.2 | NO |
| [LoRa32 T3-S3 V1.0](./lora/?t-lora=S3-v1) | ESP32-S3 | SX1262<br/>SX1276<br/>SX1280 | 2.4GHz b/g/n | 5.0 | NO |
## [T-Deck](./tdeck/)
Standalone device with screen and keyboard
| Name | MCU | Radio | WiFi | BT | GPS |
| :----------------- | :---------- | :----- | :--: | :-: | :-: |
| [T-Deck](./tdeck/) | ESP32-S3FN8 | SX1262 | YES | 5.0 | NO |
## [T-Watch S3](./twatch/)
| Name | MCU | Radio | WiFi | BT | GPS |
| :---------------------- | :------- | :----- | :--: | :-: | :-: |
| [T-Watch S3](./twatch/) | ESP32-S3 | SX1262 | YES | 5.0 | NO |

0
docs/hardware/devices/lora/buttons.mdx → docs/hardware/devices/lilygo/lora/buttons.mdx
View file

0
docs/hardware/devices/lora/gpio.mdx → docs/hardware/devices/lilygo/lora/gpio.mdx
View file

5
docs/hardware/devices/lora/index.mdx → docs/hardware/devices/lilygo/lora/index.mdx
View file

@ -1,8 +1,8 @@
---
id: lora
title: LILYGO® TTGO Lora Devices
sidebar_label: LILYGO® Lora
sidebar_position: 4
sidebar_label: LoRa32
sidebar_position: 1
---
import Tabs from "@theme/Tabs";
@ -25,6 +25,7 @@ values={[
<TabItem value="v1">
## Lora v1
:::warning
Not recommended with a battery! These boards contain the wrong component in the LiPo battery charging circuit allowing the battery to be overcharged.
:::

0
docs/hardware/devices/tbeam/buttons.mdx → docs/hardware/devices/lilygo/tbeam/buttons.mdx
View file

8
docs/hardware/devices/tbeam/index.mdx → docs/hardware/devices/lilygo/tbeam/index.mdx
View file

@ -1,7 +1,7 @@
---
id: tbeam
title: LILYGO® TTGO T-Beam Devices
sidebar_label: LILYGO® T-Beam
sidebar_label: T-Beam
sidebar_position: 2
---
@ -134,10 +134,10 @@ This is an earlier version of the T-Beam board. Due to changes in the design thi
### Resources
- Firmware file: `firmware-tbeam-X.X.X.xxxxxxx.bin`
- Purchase Links:
- Purchase Links:
- US
- [Rokland](https://store.rokland.com/products/lilygo-ttgo-t-beam-v1-1-ipex-esp32-lora-915mhz-wifi-wireless-bluetooth-module-gps-neo-m8n-ipex-18650-battery-holder-q107?ref=8Bb2mUO5i-jKwt)
- International
- International
- [AliExpress](https://www.aliexpress.com/item/32889583204.html)
![TTGO T-Beam M8N](/img/hardware/t-beam-m8n.webp)
@ -210,7 +210,7 @@ This is an earlier version of the T-Beam board. Due to changes in the design thi
### Resources
- Firmware file: `firmware-tbeam-s3-core-X.X.X.xxxxxxx.bin`
- Purchase Links:
- Purchase Links:
- International
- [AliExpress](https://www.aliexpress.com/item/1005005418286231.html)

1
docs/hardware/devices/tbeam/screens.mdx → docs/hardware/devices/lilygo/tbeam/screens.mdx
View file

@ -19,6 +19,7 @@ To attach the screen:
![Connecting the OLED screen to a T-Beam](/img/hardware/t-beam-screen.webp)
### Resources
- Purchase Links:
- US
- [Rokland](https://store.rokland.com/products/lilygo-ttgo-0-96-inch-oled-white-color-text-display-module-l206-for-t-beam-and-t-sim)

6
docs/hardware/devices/tdeck/index.mdx → docs/hardware/devices/lilygo/tdeck/index.mdx
View file

@ -1,8 +1,8 @@
---
id: tdeck
title: LILYGO® T-Deck
sidebar_label: LILYGO® T-Deck
sidebar_position: 5
sidebar_label: T-Deck
sidebar_position: 4
---
The T-Deck is a compact device featuring a 2.8-inch IPS LCD touch screen with a resolution of 320x240 pixels, integrated with a small keyboard, trackball, microphone and speaker running on an ESP32-S3 dual-core processor.
@ -32,7 +32,7 @@ The T-Deck is a compact device featuring a 2.8-inch IPS LCD touch screen with a
## Keyboard Shortcuts
| Shortcut | Function |
|-------------------|-----------------------------------------------------|
| ----------------- | --------------------------------------------------- |
| `alt` & `b` | Toggle keyboard backlight on/off. |
| `alt` & `c` | Toggle modifier function. `Fn` displayed on screen. |
| `alt` & `c` + `m` | Disable/Enable notifications. |

10
docs/hardware/devices/techo/buttons.mdx → docs/hardware/devices/lilygo/techo/buttons.mdx
View file

@ -8,17 +8,17 @@ sidebar_position: 1
## Functionality
- **Capacitive Touch Button (Top):**<br />
- **Touch:**
- **Touch:**
- Update the display
- *(at screensaver)* Wake the display.
- _(at screensaver)_ Wake the display.
- **Reset Button (Button 1):**
- **Single press:** Power-on / reboot.
- **Double press:** Enter bootloader mode, for firmware update.
- **Program Button (Button 2):**
- **Single press:**
- **Single press:**
- Display next page of information.
- *(at screensaver)* Wake the display.
- *(when off)* Enter bootloader mode, for firmware update.
- _(at screensaver)_ Wake the display.
- _(when off)_ Enter bootloader mode, for firmware update.
- **Double press:** Send an "adhoc ping": announce device to network.
- ** 3x press:** Enable / disable GPS.
- ** 4x press:** Enable / disable display's backlight.

2
docs/hardware/devices/techo/index.mdx → docs/hardware/devices/lilygo/techo/index.mdx
View file

@ -1,7 +1,7 @@
---
id: techo
title: LILYGO® TTGO T-Echo devices
sidebar_label: LILYGO® T-Echo
sidebar_label: T-Echo
sidebar_position: 3
---

4
docs/hardware/devices/twatch/index.mdx → docs/hardware/devices/lilygo/twatch/index.mdx
View file

@ -1,8 +1,8 @@
---
id: twatch
title: LILYGO® T-Watch
sidebar_label: LILYGO® T-Watch
sidebar_position: 6
sidebar_label: T-Watch
sidebar_position: 5
---
The T-Watch S3 is a compact wearable device featuring a 1.54-inch IPS LCD touch screen with a resolution of 240x240 pixels. It includes haptic feedback, an integrated microphone, speaker, real-time clock, and a three-axis accelerometer.

2
docs/hardware/devices/linux-native-hardware/linux-native-hardware.mdx
View file

@ -115,6 +115,8 @@ Webserver:
Port: 443 # Port for Webserver & Webservices
RootPath: /usr/share/doc/meshtasticd/web # Root Dir of WebServer
```
### Bluetooth Support
Bluetooth is currently unsupported and not functional on Linux Native devices. This may change in the future.
### GPS Support

44
docs/hardware/devices/rak-wireless/index.mdx Normal file
View file

@ -0,0 +1,44 @@
---
id: rak-wireless
title: RAK Wireless Devices
sidebar_label: RAK®
sidebar_position: 1
---
## [RAK Wisblock](./wisblock/)
Modular hardware system with Base, Core and Peripheral modules including the low-power and solar ready nRF52840-based Meshtastic Starter Kit (19007 & 4631).
### [**WisBlock Core Modules**](./wisblock/core-module/)
| Name | MCU | Radio | WiFi | BT | GPS |
| :-------------------------------------------------- | :------- | :----- | :----------: | :-: | :----: |
| [RAK4631](./wisblock/core-module?rakcore=RAK4631) | nRF52840 | SX1262 | NO | 5.0 | add-on |
| [RAK11200](./wisblock/core-module?rakcore=RAK11200) | ESP32 | add-on | 2.4GHz b/g/n | 4.2 | add-on |
| [RAK11310](./wisblock/core-module?rakcore=RAK11310) | RP2040 | SX1262 | NO | NO | add-on |
### [**Base Boards**](./wisblock/base-board/)
[RAK5005-O](./wisblock/base-board?rakbase=RAK5005-O)<br/>
[RAK19007](./wisblock/base-board?rakbase=RAK19007)<br/>
[RAK19003](./wisblock/base-board?rakbase=RAK19003)<br/>
[RAK19001](./wisblock/base-board?rakbase=RAK19001)<br/>
### [**WisBlock Displays**](./wisblock/screens/)
[RAK1921](./wisblock/screens?rakscreens=OLED)<br/>
[RAK1400](./wisblock/screens?rakscreens=E-Ink)<br/>
### [**WisBlock Peripherals**](./wisblock/peripherals/)
[RAK1910](./wisblock/peripherals?rakmodules=GPS) GPS<br/>
[RAK12500](./wisblock/peripherals?rakmodules=GPS) GPS<br/>
[RAK18001](./wisblock/peripherals?rakmodules=Buzzer) Buzzer<br/>
[RAK13002](./wisblock/peripherals?rakmodules=IO) IO<br/>
RAK14001 RGB LED<br/>
[RAK12002](./wisblock/peripherals?rakmodules=RTC) RTC<br/>
[RAK1901](./wisblock/peripherals?rakmodules=Sensors&sensors=RAK1901) Temperature and Humidity Sensor<br/>
[RAK1902](./wisblock/peripherals?rakmodules=Sensors&sensors=RAK1902) Barometric Pressure Sensor<br/>
[RAK1906](./wisblock/peripherals?rakmodules=Sensors&sensors=RAK1906) Environment Sensor<br/>
RAK12013 Radar Sensor<br/>
RAK13800 Ethernet Module<br/>

52
docs/hardware/devices/rak/base-boards.mdx → docs/hardware/devices/rak-wireless/wisblock/base-boards.mdx
View file

@ -8,7 +8,7 @@ sidebar_position: 1
import Tabs from "@theme/Tabs";
import TabItem from "@theme/TabItem";
Operation requires both a base board and a [core module](/docs/hardware/devices/rak/core-module).
Operation requires both a base board and a [core module](../core-module/).
<Tabs
groupId="rakbase board"
@ -29,20 +29,20 @@ The RAK5005-O is no longer in production. It is recommended to use the RAK19007
:::
- [RAK5005-O](https://store.rakwireless.com/products/rak5005-o-base-board) - The original WisBlock Base Board.
- **Slots**
- (x1) Core Module slot
- (x1) WisBlock IO Module slot
- (x4) WisBlock Sensor Module slots
- **Buttons**
- (x1) Reset Button
- It may be possible to add a user button using the [13002 IO module](https://store.rakwireless.com/collections/wisblock-interface/products/adapter-module-rak13002).
- **Connectors**
- Connector for 3.7v LiPo battery (with charge controller)
- Connector for 5v solar panel (max 5.5v)
- I<sup>2</sup>C, UART, GPIOs and analog input accessible with solder contacts
- Micro USB port for debugging and power
- **Screen Support**
- OLED screen support (OLED screen sold separately)
- **Slots**
- (x1) Core Module slot
- (x1) WisBlock IO Module slot
- (x4) WisBlock Sensor Module slots
- **Buttons**
- (x1) Reset Button
- It may be possible to add a user button using the [13002 IO module](https://store.rakwireless.com/collections/wisblock-interface/products/adapter-module-rak13002).
- **Connectors**
- Connector for 3.7v LiPo battery (with charge controller)
- Connector for 5v solar panel (max 5.5v)
- I<sup>2</sup>C, UART, GPIOs and analog input accessible with solder contacts
- Micro USB port for debugging and power
- **Screen Support**
- OLED screen support (OLED screen sold separately)
:::note
The RAK5005 (without the -O) is not compatible.
@ -56,9 +56,9 @@ Further information on the RAK5005-O can be found on the [RAK Documentation Cent
style={{ zoom: "50%" }}
/>
</TabItem>
</TabItem>
<TabItem value="RAK19007">
<TabItem value="RAK19007">
## RAK19007
@ -81,16 +81,17 @@ Further information on the RAK5005-O can be found on the [RAK Documentation Cent
Further information on the RAK19007 can be found on the [RAK Documentation Center](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK19007/Overview/#product-description).
### Resources
- Purchase Links:
- US
- US
- [Rokland](https://store.rokland.com/products/rak-wireless-wisblock-base-board-2nd-gen-rak19007-ver-b-pid-110082)
- International
- [RAK Wireless](https://store.rakwireless.com/products/wisblock-base?variant=42441632284870)
- [RAK Wireless Starter Kit](https://store.rakwireless.com/products/wisblock-meshtastic-starter-kit)
</TabItem>
</TabItem>
<TabItem value="RAK19003">
<TabItem value="RAK19003">
## RAK19003
@ -112,8 +113,9 @@ Further information on the RAK19007 can be found on the [RAK Documentation Cente
Further information on the RAK19003 can be found on the [RAK Documentation Center](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK19003/Overview/#product-description)
### Resources
- Purchase Links:
- US
- US
- [Rokland](https://store.rokland.com/products/rak-wireless-wisblock-mini-base-board-rak19003-ver-b-pid-306024)
- International
- [RAK Wireless](https://store.rakwireless.com/products/wisblock-base?variant=42441632252102)
@ -151,12 +153,12 @@ Further information on the RAK19003 can be found on the [RAK Documentation Cente
Further information on the RAK19001 can be found on the [RAK Documentation Center](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK19001/Overview/#product-description).
### Resources
- Purchase Links:
- US
- US
- [Rokland](https://store.rokland.com/products/rak-wireless-wisblock-dual-io-base-board-rak19001-pid-110081)
- International
- [RAK Wireless](https://store.rakwireless.com/products/wisblock-base?variant=42441631924422)
</TabItem>
</Tabs>
</TabItem>
</Tabs>

0
docs/hardware/devices/rak/buttons.mdx → docs/hardware/devices/rak-wireless/wisblock/buttons.mdx
View file

39
docs/hardware/devices/rak/core-modules.mdx → docs/hardware/devices/rak-wireless/wisblock/core-modules.mdx
View file

@ -62,7 +62,6 @@ Please be aware of the difference between the RAK4631 (Arduino bootloader) and t
style={{ zoom: "50%" }}
/>
### GPIO
:::caution Note
@ -93,7 +92,7 @@ meshtastic --set external_notification.output 10
This will use IO6 on a RAK4631
</TabItem>
</TabItem>
<TabItem value="RAK11200">
## RAK11200 - ESP32
@ -140,23 +139,23 @@ The RAK11200 does not contain a LoRa transceiver, and thus needs to be added sep
:::
- **MCU:**
- Raspberry Pi RP2040
- Dual M0+ Core
- 133MHz CPU Clock
- **LoRa Transceiver:**
- SX1262
- **Frequency Options:**
- 433 MHz
- 470 MHz
- 864 MHz
- 865 MHz
- 868 MHz
- 915 MHz
- 920 MHz
- 923 MHz
- **Connectors:**
- U.FL/IPEX antenna connector for LoRa
- **MCU:**
- Raspberry Pi RP2040
- Dual M0+ Core
- 133MHz CPU Clock
- **LoRa Transceiver:**
- SX1262
- **Frequency Options:**
- 433 MHz
- 470 MHz
- 864 MHz
- 865 MHz
- 868 MHz
- 915 MHz
- 920 MHz
- 923 MHz
- **Connectors:**
- U.FL/IPEX antenna connector for LoRa
### Resources
@ -169,5 +168,5 @@ The RAK11200 does not contain a LoRa transceiver, and thus needs to be added sep
- [RAK Wireless Store](https://store.rakwireless.com/products/rak11310-wisblock-lpwan-module)
- [RAK Wireless Aliexpress](https://www.aliexpress.us/item/3256803225175784.html)
</TabItem>
</TabItem>
</Tabs>

32
docs/hardware/devices/rak-wireless/wisblock/index.mdx Normal file
View file

@ -0,0 +1,32 @@
---
id: wisblock
title: RAK WisBlock Devices
sidebar_label: WisBlock
sidebar_position: 1
---
import Tabs from "@theme/Tabs";
import TabItem from "@theme/TabItem";
The RAK WisBlock is a modular hardware system that can be used to build Meshtastic devices.
RAK Wireless currently sells a [Meshtastic Starter kit](https://store.rakwireless.com/products/wisblock-meshtastic-starter-kit) that has the minimum you need to get started.
If you wish to purchase parts separately, you will need a [WisBlock Base Board](./base-board) and a [WisBlock Core Module](./core-module). Please ensure you choose the correct operating frequency for your country when purchasing.
You can optionally purchase peripherals such as a GPS module, Screen, Sensor, or other various modules.
Please see the RAK documentation for the correct way to connect your hardware to the baseboard to ensure that you do not damage the device.
## Resources
- RAK's Wisblock [Documentation Center](https://docs.rakwireless.com/Product-Categories/WisBlock)
- RAK's [GitHub Page](https://github.com/RAKWireless/WisBlock) for the WisBlock
- RAK's [WisBlock IO Pin Mapping Tool](https://docs.rakwireless.com/Knowledge-Hub/Pin-Mapper/).
- This tool helps properly map your WisBlock modules by identifying the compatible pins and their possible conflicts. Be sure to reference the RAK4631 [variant.h](https://github.com/meshtastic/firmware/blob/master/variants/rak4631/variant.h) to cross-reference potential conflicts to Meshtastic's firmware pin definitions.
- Purchase links
- See purchase links under specific base boards, core modules, and peripherals
- China RAK Direct [RAK Wireless Starter Kit w/ Gen2 Base board](https://store.rakwireless.com/products/wisblock-meshtastic-starter-kit)
- US Distributor Rokland [RAK Wireless Starter Kit w/ Gen2 Base board](https://store.rokland.com/products/rak-wireless-wisblock-meshtastic-starter-kit)
- US Distributor Rokland [RAK Wireless Starter Kit w/ Gen1 Base board](https://store.rokland.com/products/rakwireless-meshtastic-starter-kit-alternative-with-rak5005-o-base)
- UK/EU Distributor ConnectedThings [RAK Wireless Starter Kit w/ Gen2 Base board](https://connectedthings.store/gb/meshtastic/rak-wisblock-meshtastic-starter-kit.html)

27
docs/hardware/devices/rak/peripherals.mdx → docs/hardware/devices/rak-wireless/wisblock/peripherals.mdx
View file

@ -24,8 +24,7 @@ values={[
## User Button
Any tactile momemtary push button is compatible as long as it is wired to the correct pins, here's a sample of a [Push Button](https://a.co/d/bPhhTxm)
Any tactile momemtary push button is compatible as long as it is wired to the correct pins, here's a sample of a [Push Button](https://a.co/d/bPhhTxm)
The button is recommended to be used on the following base board's exposed pins or slots :
@ -33,16 +32,17 @@ The button is recommended to be used on the following base board's exposed pins
- RAK19001 on IO5 (Pin 37)
### Wiring
One side of the switch should be on GND and the other on the recommended Pin per your baseboard. The pin must be configured on the node using the app, webclient or CLI.
One side of the switch should be on GND and the other on the recommended Pin per your baseboard. The pin must be configured on the node using the app, webclient or CLI.
### Resources
For more information on the User Button functionality refer to
For more information on the User Button functionality refer to
- [RAK WisBlock Hardware Buttons](https://meshtastic.org/docs/hardware/devices/rak/buttons/)
</TabItem>
<TabItem value="GPS">
## GPS Modules
@ -75,6 +75,7 @@ The RAK1910 is supported on the following base boards & slots:
- RAK19001 on slot F
### Resources
- RAK Documentation Center
- [RAK12500](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK12500/Overview/#product-description)
- [RAK1910](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK1910/Overview/#product-description)
@ -94,12 +95,13 @@ The RAK1910 is supported on the following base boards & slots:
The [RAK18001 Buzzer Module](https://store.rakwireless.com/products/wisblock-buzzer-module-rak18001) is currently being tested for integration with the External Notifications plugin. There is currently a known conflict with buzzer if the module is placed in Slot D, although other slots should work.
### Resources
- [RAK Documentation Center RAK18001](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK18001/Overview/#product-description)
- Purchase Links:
- International
- [RAK Wireless](https://store.rakwireless.com/products/wisblock-buzzer-module-rak18001)
</TabItem>
</TabItem>
<TabItem value="IO">
## IO Module
@ -116,6 +118,7 @@ The [RAK13002 IO Module](https://store.rakwireless.com/collections/wisblock-inte
There is development activity in progress to get sensors such as this added to the Meshtastic Core.
### Resources
- [RAK Documentation Center RAK13002](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK13002/Overview)
- Purchase Links:
- US
@ -123,7 +126,7 @@ There is development activity in progress to get sensors such as this added to t
- International
- [RAK Wireless](https://store.rakwireless.com/collections/wisblock-interface/products/adapter-module-rak13002)
</TabItem>
</TabItem>
<TabItem value="Sensors">
## Environmental Sensors
@ -154,7 +157,8 @@ The [RAK1906 Environment Sensor](https://store.rakwireless.com/products/rak1906-
- Air Quality measurement
#### Resources
- RAK Documentation Center
- RAK Documentation Center
- [RAK1901](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK1901/Overview/#product-description)
- [RAK1902](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK1902/Overview/#product-description)
- [RAK1906](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK1906/Overview/#product-description)
@ -168,7 +172,7 @@ The [RAK1906 Environment Sensor](https://store.rakwireless.com/products/rak1906-
- [RAK Wireless RAK1902](https://store.rakwireless.com/products/rak1902-kps22hb-barometric-pressure-sensor)
- [RAK Wireless RAK1906](https://store.rakwireless.com/products/rak1906-bme680-environment-sensor)
</TabItem>
</TabItem>
<TabItem value="RTC">
## RTC Module
@ -176,6 +180,7 @@ The [RAK1906 Environment Sensor](https://store.rakwireless.com/products/rak1906-
The [RAK12002 WisBlock RTC Module](https://store.rakwireless.com/products/rtc-module-rak12002) is a real-time-clock with a supercapacitor backup, allowing a node to maintain the correct time across reboots and for up to seven days without power. It operates on a crystal oscilator and communicates via the i2c interface. The module can be inserted into slots A, B or C (some users have reported issues with slot D) and is plug and play - no settings are required.
### Resources
- [RAK Documentation Center RAK12002](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK12002/Overview/)
- Purchase Links:
- US
@ -183,5 +188,5 @@ The [RAK12002 WisBlock RTC Module](https://store.rakwireless.com/products/rtc-mo
- International
- [RAK Wireless](https://store.rakwireless.com/products/rtc-module-rak12002)
</TabItem>
</TabItem>
</Tabs>

31
docs/hardware/devices/rak/screens.mdx → docs/hardware/devices/rak-wireless/wisblock/screens.mdx
View file

@ -33,12 +33,13 @@ Similar modules are widely available from other suppliers, but do check the boar
If pin ordering on the OLED board are swapped, there are some tricks to allow either reconfiguring the pins of the OLED via soldered jumpers, or by carefully soldering wire for those pins that are out-of-sequence. The final option is to use longer wires between the board and display, which permits re-ordering the wires as required.
### Resources
- [RAK Documentation Center](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK1921/Overview/#product-description)
- Purchase Links:
- US
- [Rokland](https://store.rokland.com/products/rak-wireless-wisblock-oled-display-rak1921-pid-110004)
- International
- [RAK Wireless](https://store.rakwireless.com/products/rak1921-oled-display-panel)
- US
- [Rokland](https://store.rokland.com/products/rak-wireless-wisblock-oled-display-rak1921-pid-110004)
- International
- [RAK Wireless](https://store.rakwireless.com/products/rak1921-oled-display-panel)
[<img alt="0.96 inch OLED display" src="/img/hardware/screen.webp" style={{zoom:'25%'}} />](/img/hardware/screen.webp)
@ -54,23 +55,23 @@ The [RAK1400 EPD module](https://store.rakwireless.com/products/wisblock-epd-mod
- Resolution 212 x 104 pixels
- Occupies the IO Port of a Wisblock Base
Please note only the white-black display is supported at this time, the white-black-red display may work, but is not supported.
Please note only the white-black display is supported at this time, the white-black-red display may work, but is not supported.
### Resources
- Firmware for 5005 with RAK14000 e-paper: [`firmware-rak4631_eink-X.X.X.xxxxxxx.uf2`](/downloads)
- [RAK Documentation Center](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK14000/Overview/#product-description)
- Purchase Links:
- US
- [Rokland](https://store.rokland.com/products/rak-wireless-wisblock-epd-module-rak14000-pid-110024)
- International
- [RAK Wireless](https://store.rakwireless.com/products/wisblock-epd-module-rak14000)
- US
- [Rokland](https://store.rokland.com/products/rak-wireless-wisblock-epd-module-rak14000-pid-110024)
- International
- [RAK Wireless](https://store.rakwireless.com/products/wisblock-epd-module-rak14000)
<img
alt="RAK4631 5005 14000"
src="/img/hardware/rak4631_5005_epaper.webp"
style={{ zoom: "50%" }}
/>
<img
alt="RAK4631 5005 14000"
src="/img/hardware/rak4631_5005_epaper.webp"
style={{ zoom: "50%" }}
/>
</TabItem>
</Tabs>

32
docs/hardware/devices/rak/index.mdx
View file

@ -1,32 +0,0 @@
---
id: wisBlock
title: RAK WisBlock Devices
sidebar_label: RAK WisBlock
sidebar_position: 1
---
import Tabs from "@theme/Tabs";
import TabItem from "@theme/TabItem";
The RAK WisBlock is a modular hardware system that can be used to build Meshtastic devices.
RAK Wireless currently sells a [Meshtastic Starter kit](https://store.rakwireless.com/products/wisblock-meshtastic-starter-kit) that has the minimum you need to get started.
If you wish to purchase parts separately, you will need a [WisBlock Base Board](/docs/hardware/devices/rak/base-board) and a [WisBlock Core Module](/docs/hardware/devices/rak/core-module). Please ensure you choose the correct operating frequency for your country when purchasing.
You can optionally purchase peripherals such as a GPS module, Screen, Sensor, or other various modules.
Please see the RAK documentation for the correct way to connect your hardware to the baseboard to ensure that you do not damage the device.
## Resources
- RAK's Wisblock [Documentation Center](https://docs.rakwireless.com/Product-Categories/WisBlock)
- RAK's [GitHub Page](https://github.com/RAKWireless/WisBlock) for the WisBlock
- RAK's [WisBlock IO Pin Mapping Tool](https://docs.rakwireless.com/Knowledge-Hub/Pin-Mapper/).
- This tool helps properly map your WisBlock modules by identifying the compatible pins and their possible conflicts. Be sure to reference the RAK4631 [variant.h](https://github.com/meshtastic/firmware/blob/master/variants/rak4631/variant.h) to cross-reference potential conflicts to Meshtastic's firmware pin definitions.
- Purchase links
- See purchase links under specific base boards, core modules, and peripherals
- China RAK Direct [RAK Wireless Starter Kit w/ Gen2 Base board](https://store.rakwireless.com/products/wisblock-meshtastic-starter-kit)
- US Distributor Rokland [RAK Wireless Starter Kit w/ Gen2 Base board](https://store.rokland.com/products/rak-wireless-wisblock-meshtastic-starter-kit)
- US Distributor Rokland [RAK Wireless Starter Kit w/ Gen1 Base board](https://store.rokland.com/products/rakwireless-meshtastic-starter-kit-alternative-with-rak5005-o-base)
- UK/EU Distributor ConnectedThings [RAK Wireless Starter Kit w/ Gen2 Base board](https://connectedthings.store/gb/meshtastic/rak-wisblock-meshtastic-starter-kit.html)

18
docs/hardware/devices/raspberrypi/index.mdx Normal file
View file

@ -0,0 +1,18 @@
---
id: raspberry-pi
title: Raspberry Pi
sidebar_label: Raspberry Pi
sidebar_position: 5
---
### [Raspberry Pi Pico](./pico/)
Fast versatile boards using the RP2040.
| Name | MCU | Radio | WiFi | BT | GPS |
| :--------------------------- | :----- | :----- | :----------: | :-----------: | :-: |
| [Raspberry Pi Pico](./pico/) | RP2040 | SX1262 | 2.4GHz b/g/n | not supported | NO |
### [Raspberry Pi Zero/Zero2/3/4/400/5](/docs/hardware/devices/linux-native-hardware/)
Meshtastic offers support for Raspberry Pi devices through our Linux native platform, meshtasticd. For full information, please see our [Linux Native Hardware](/docs/hardware/devices/linux-native-hardware/) documentation.

6
docs/hardware/devices/raspberry-pi/index.mdx → docs/hardware/devices/raspberrypi/pico/index.mdx
View file

@ -1,8 +1,8 @@
---
id: raspberry-pi
id: raspberry-pi-pico
title: Raspberry Pi Pico
sidebar_label: Raspberry Pi Pico
sidebar_position: 10
sidebar_position: 1
---
import Tabs from "@theme/Tabs";
@ -42,7 +42,7 @@ Please be aware that the Raspberry Pi Pico must be used in combination with a [W
:::note
LoRa transmissions may interfere with the USB connection. It is recommended to place the antenna as far away from the USB port as possible.
LoRa transmissions may interfere with the USB connection. It is recommended to place the antenna as far away from the USB port as possible.
:::

0
docs/hardware/devices/raspberry-pi/peripherals.mdx → docs/hardware/devices/raspberrypi/pico/peripherals.mdx
View file

27
docs/hardware/devices/seeed-studio/index.mdx Normal file
View file

@ -0,0 +1,27 @@
---
id: seeed-studios
title: Seeed Studio
sidebar_label: Seeed Studio
sidebar_position: 6
---
Seeed Studio is a tech company focused on Edge AI and IoT. With the mission of "making technology accessible for all", Seeed Studio has been embracing open source since DAY 1. Seeed works closely with the Meshtastic community to bring easy-to-use, affordable products to community members. By listening to the voices, communicating and collaborating closely with innovators in this community, iterations of products and new services are brought to life.
### [SenseCap](./sensecap/)
The SenseCAP product line offers a comprehensive range of solutions for both hobbyists and industrial users, featuring the T1000-E card tracker, an IP65-rated, ready-to-go Meshtastic device, and the Indicator with a 4-inch touchscreen driven by ESP32-S3 and RP2040 Dual-MCU, coming soon.
| Name | MCU | Radio | WiFi | BT | GPS |
| ------------------------------------------------ | ------------- | ------ | ---- | --- | --- |
| [Card Tracker T1000-E](./sensecap/card-tracker/) | nRF52840 | LR1110 | NO | 5.1 | YES |
| [SenseCAP Indicator](#) (coming soon) | ESP32, RP2040 | - | - | - | - |
### [Wio-WM1110](./wm1110)
nRF52840-based development boards with GPS, and multiple ports to attach sensors.
| Name | MCU | Radio | WiFi | BT | GPS |
| :----------------------------------------------------------- | :------- | :----- | :--: | :-: | :-: |
| [Seeed Wio-WM1110 Dev Kit](./wm1110?wm1110=wio-sdk-wm1110) | nRF52840 | LR1110 | YES | 5.3 | YES |
| [Seeed Wio Tracker 1110](./wm1110?wm1110=wio-tracker-wm1110) | nRF52840 | LR1110 | YES | 5.3 | YES |

42
docs/hardware/devices/seeed-studio/sensecap/card-tracker.mdx Normal file
View file

@ -0,0 +1,42 @@
---
id: card-tracker
title: SenseCAP Card Tracker T1000-E
sidebar_label: Card Tracker T1000-E
sidebar_position: 2
---
SenseCAP T1000-E is a high-performance tracker designed for Meshtastic. As small as a credit card, effortlessly fitting in your pocket or attaching to your assets. It embeds Semtech's LR1110, Nordic's nRF52840, and Mediatek's AG3335 GPS module, providing Meshtastic users with a high-precision, low-power positioning and communication solution.
### Specifications
- **MCU**
- Nordic nRF52840 (supports Bluetooth)
- **LoRa Transceiver**
- Semtech LR1110
- **Frequency options**
- 865-928 MHz
- **Navigation Module**
- Mediatek AG3335 GPS chip
- **Battery Capacity**
- Rechargeable lithium battery, 700mAh
- **Charging**
- USB magnetic charging cable
### Features
- **Button and Buzzer**: For user interaction and alerts.
- **Pogo Pins**: Four pins for USB, DFU, serial logging, and charging.
- **Rugged Build**: IP65 rated, waterproof and durable for various environments.
### Resources
- Firmware file: `firmware-tracker-t1000-e-X.X.X.xxxxxxx.bin`
- Purchase Links:
- International
- [Seeed Studio](https://www.seeedstudio.com/SenseCAP-Card-Tracker-T1000-E-for-Meshtastic-p-5913.html)
- [User Guide](https://wiki.seeedstudio.com/sensecap_t1000_e/)
#### Images
![SenseCAP Card Tracker T1000-E for Meshtastic](/img/hardware/seeed/t1000-e-meshtastic.webp)
![SenseCAP Card Tracker T1000-E Dimensions](/img/hardware/seeed/t1000-e-hardware.webp)

11
docs/hardware/devices/seeed-studio/sensecap/index.mdx Normal file
View file

@ -0,0 +1,11 @@
---
id: seeed-sensecap
title: Seeed SenseCAP
sidebar_label: SenseCAP
sidebar_position: 1
---
| Name | MCU | Radio | WiFi | BT | GPS |
| ------------------------------------------------- | ------------- | ------ | ---- | --- | --- |
| [Card Tracker T1000-E](../sensecap/card-tracker/) | nRF52840 | LR1110 | NO | 5.1 | YES |
| [SenseCAP Indicator](#) (coming soon) | ESP32, RP2040 | - | - | - | - |

14
docs/hardware/devices/seeed-wm1110/index.mdx → docs/hardware/devices/seeed-studio/wm1110/index.mdx
View file

@ -1,14 +1,13 @@
---
id: seeed-wm1110
title: Seeed Wio-WM1100
sidebar_label: Seeed Wio-WM1100
sidebar_position: 15
sidebar_label: Wio-WM1100
sidebar_position: 1
---
import Tabs from "@theme/Tabs";
import TabItem from "@theme/TabItem";
<Tabs
groupId="wm1110"
queryString="wm1110"
@ -26,9 +25,8 @@ values={[
The LR1110 GNSS functionality does not yet work. Seeed recommends at Grove - GPS (Air530).
:::
- **MCU**
- Nordic nRF52840 (WiFi & Bluetooth)
- Nordic nRF52840
- **LoRa Transceiver**
- Semtech LR1110
- **Frequency options**
@ -36,7 +34,7 @@ The LR1110 GNSS functionality does not yet work. Seeed recommends at Grove - GPS
- 915 MHz
- 923 MHz
- **Navigation Module**
- Semtech LR1110
- Grove GPS Air530 (Supports GPS, Beidou, Glonass, Galileo, QZSS, SBAS)
- **Connectors**
- USB-C
- LoRa Antenna: SMA antenna connector and U.FL/IPEX
@ -48,7 +46,6 @@ The LR1110 GNSS functionality does not yet work. Seeed recommends at Grove - GPS
- Solar Panel
- SWDIO
### Features
- Temperature and Humidity Sensor (SHT41)
@ -73,7 +70,7 @@ The LR1110 GNSS functionality does not yet work. Seeed recommends at Grove - GPS
## Wio Tracker 1110 Dev Kit for Meshtastic
- **MCU**
- Nordic nRF52840 (WiFi & Bluetooth)
- Nordic nRF52840 (BLE 5.3)
- **LoRa Transceiver**
- Semtech LR1110
- **Frequency options**
@ -88,7 +85,6 @@ The LR1110 GNSS functionality does not yet work. Seeed recommends at Grove - GPS
- GNSS Antenna: on-board and U.FL/IPEX
- Grove connectors: ADC x1, I2C x1, UART x1, Digital x3
### Features
- Temperature and Humidity Sensor (SHT41)

1
docs/legal/licensing-and-trademark.mdx
View file

@ -108,6 +108,7 @@ We are excited to introduce two new logos for our community members: the "M-Powe
- **Freedom of Use:** Unlike the main Meshtastic logo, using the "M-Powered" or "M-PWRD" logos does not require a trademark grant. These logos are intended for broader use in the community to signify that a project is Meshtastic-compatible.
- **Appropriate Contexts:** In most scenarios, the "M-Powered" or "M-PWRD" logos will be more suitable than the official Meshtastic logo. They are ideal for project documentation, promotional materials, and product designs to show compatibility with Meshtastic.
- **Non-Endorsement:** It's important to note that using these logos does not imply endorsement or sponsorship by the Meshtastic Project. They are purely for indicating compatibility or association with Meshtastic technology.
- **Good Standing Requirement:** Permission to use the M-Powered logo is granted only to individuals or projects that are in good standing within the Meshtastic community. Users who have been banned or are otherwise restricted from community participation due to violations of the [Code of Conduct](https://meshtastic.org/docs/legal/conduct/) are prohibited from using the M-Powered logo in any form.
We have provided design files for these logos in our [Meshtastic Design repository](https://github.com/meshtastic/design/tree/master/Meshtastic%20Powered%20Logo).

8
docs/legal/privacy.mdx
View file

@ -1,17 +1,19 @@
---
id: privacy
title: Meshtastic privacy policy
title: Meshtastic Privacy Policy
sidebar_label: Privacy
custom_edit_url: null
sidebar_position: 2
---
We don't collect any personal identifying information. We never capture usernames, the contents of your texts, or your location data.
We don't collect any personal identifying information. We never capture usernames or the contents of your texts.
Location data is used to enable features like showing your mesh network on a map. We do not collect or store your location data. If your mesh network has MQTT enabled, location data may be accessed by third parties.
If you opt-in to analytics on the Android app (thank you - that helps us know what things we need to improve), we will receive anonymized information about user behavior. This includes crash reports, screens used in the app, etc... Analytics is provided by [Firebase Crashlytics](https://firebase.google.com/products/crashlytics).
The search engine for this website is provided by Algolia, please see their [privacy policy](https://www.algolia.com/policies/privacy) for details of what information they collect.
This is an open-source project run by hobbyists, and we try to be completely transparent. If you have questions on this policy, please post on the forum, and we'll reply/clarify/correct.
This is an open-source project run by hobbyists, and we try to be completely transparent. If you have questions on this policy, please [post on the forum](https://meshtastic.discourse.group/), and we'll reply/clarify/correct.
Keep being awesome!

2
docs/legal/trademark-grants.mdx
View file

@ -53,3 +53,5 @@ This process ensures transparency and community involvement in the granting of t
- Details: Simon is a Meshtastic designer of devices, device enclosures and accessories that carry the "Meshtastic" , Meshtastic.org URL and "M" logos. The use of the Meshtastic Logo and Trademarks does not imply Simon is sponsored or endorsed by Meshtastic. Simon also agrees to maintain compliance with the Meshtastic Legal requirements. This grant is revokable at any time for any reason.
- Grant: [Rokland LLC](https://www.rokland.com)
- Details: Rokland LLC is a Meshtastic contributor/distributor of parts and devices that run Meshtastic firmware. The Meshtastic "M" logo will be used on a promotional give-away t-shirt to promote the RAKwireless WisMesh Pocket product. The use of the Meshtastic Logo and Trademarks does not imply Rokland LLC is sponsored or endorsed by Meshtastic. Rokland LLC also agrees to maintain compliance with the Meshtastic Legal requirements. This grant is revokable at any time for any reason.
- Grant: Meshtastic Solutions LLC
- Details: Meshtastic Solutions LLC is a company focused on Meshtastic Research and Development and expanding Meshtastic into new industries. Meshtastic Solutions LLC is granted use of all Meshtastic logos and trademarks. Meshtastic Solutions LLC agrees to maintain compliance with all Meshtastic Legal requirements.

6
docs/software/android/usage.mdx
View file

@ -140,8 +140,10 @@ By default there is no long-term store-and-forward of messages, so messages not
The network list shows all the users (devices) that have connected to the same Channel. For each entry, it shows the last time they were active, their location and distance (when available), and their last known power status. In the example above, Monkey is the local user, Rabbit was last heard from 10 minutes ago and is 50m away, and Panda was last heard 11 minutes ago and 5m away.
- Tap on a node from the list to start Direct Messaging, request a position update, request a [traceroute](/docs/configuration/module/traceroute) or add it to your [Ignore Incoming Array](/docs/configuration/radio/lora#ignore-incoming-array).
- If you have an [Admin Channel](/docs/configuration/remote-admin) enabled on your devices, tapping on the node will also display an option to remotely configure the node.
- Tap on a node in the list to show more details about the node. A Show Details toggle is in the filter menu.
- Tap on a node's colored chip to start Direct Messaging, request a position update, request a [traceroute](/docs/configuration/module/traceroute) or add it to your [Ignore Incoming Array](/docs/configuration/radio/lora#ignore-incoming-array).
- Tap on a node's location coordinates to open in your maps application, long press to copy the coordinates to your clipboard.
- If you have an [Admin Channel](/docs/configuration/remote-admin) enabled on your devices, tapping on the node's colored chip will also display an option to remotely configure the node.
### View the map

14
docs/software/apple/usage.mdx
View file

@ -7,16 +7,8 @@ sidebar_position: 2
## Offline Maps
The Meshtastic app for iOS, iPadOS and macOS supports the sharing of a .mbtiles file with the app for offline map support.
### Apple Maps
There is an open source cross platform mapping program call [QGIS](https://www.qgis.org/en/site/)
By default, the Meshtastic app for iOS supports the use of native offline Apple Maps.
to get a mbtiles out of qgis, start with a small area that you are familiar with. Open qgis, and add a openstreetmap source from the left bar (might be under one of the tile headings). Now you should see something in the main map view. zoom to the area you want.
In the Processing Toolbox (right bar, you may have to show it from the View menu), open Raster Tools > Generate XYZ Tiles (MBTiles)
In Extent, choose Use Map Canvas Extent. This defines the area of the map that will be rendered into the export file
Use a zoom level of 12-17. You can play with this later, but thats a good starting point. Note that every increment of maximum zoom will increase the map size 4x.
Select JPG if there's aerial/satellite imagery, otherwise just use PNG. That will give the best compression.
Finally choose a location for the output file. Click Run and you should eventually get a file that should play nice in the Meshtastic app.
To download offline maps, follow the official instructions from Apple for [iPhone](https://support.apple.com/en-gb/105084) or [iPad](https://support.apple.com/en-gb/guide/ipad/ipadc6e7e4d7/ipados). Video instructions are also [available](https://youtube.com/watch?v=L260qixQrYs).

28
docs/software/integrations/mqtt/home-assistant.mdx
View file

@ -44,7 +44,7 @@ sensor:
- name: "Node 1 Battery Voltage"
unique_id: "node_1__battery_voltage"
state_topic: "msh/2/json/LongFast/!67ea9400"
state_topic: "msh/US/2/json/LongFast/!67ea9400"
state_class: measurement
value_template: >-
{% if value_json.from == 4038675309 and
@ -60,7 +60,7 @@ sensor:
- name: "Node 1 Battery Percent"
unique_id: "node_1_battery_percent"
state_topic: "msh/2/json/LongFast/!67ea9400"
state_topic: "msh/US/2/json/LongFast/!67ea9400"
state_class: measurement
value_template: >-
{% if value_json.from == 4038675309 and value_json.payload.battery_level is defined %}
@ -73,7 +73,7 @@ sensor:
- name: "Node 1 ChUtil"
unique_id: "node_1_chutil"
state_topic: "msh/2/json/LongFast/!67ea9400"
state_topic: "msh/US/2/json/LongFast/!67ea9400"
state_class: measurement
value_template: >-
{% if value_json.from == 4038675309 and value_json.payload.channel_utilization is defined %}
@ -85,7 +85,7 @@ sensor:
- name: "Node 1 AirUtilTX"
unique_id: "node_1_airutiltx"
state_topic: "msh/2/json/LongFast/!67ea9400"
state_topic: "msh/US/2/json/LongFast/!67ea9400"
state_class: measurement
value_template: >-
{% if value_json.from == 4038675309 and value_json.payload.air_util_tx is defined %}
@ -104,7 +104,7 @@ sensor:
- name: "Node 1 Temperature"
unique_id: "node_1_temperature"
state_topic: "msh/2/json/LongFast/!67ea9400"
state_topic: "msh/US/2/json/LongFast/!67ea9400"
state_class: measurement
value_template: >-
{% if value_json.from == 4038675309 and value_json.payload.temperature is defined %}
@ -121,7 +121,7 @@ sensor:
- name: "Node 1 Humidity"
unique_id: "node_1_humidity"
state_topic: "msh/2/json/LongFast/!67ea9400"
state_topic: "msh/US/2/json/LongFast/!67ea9400"
state_class: measurement
value_template: >-
{% if value_json.from == 4038675309 and value_json.payload.relative_humidity is defined %}
@ -134,7 +134,7 @@ sensor:
- name: "Node 1 Pressure"
unique_id: "node_1_pressure"
state_topic: "msh/2/json/LongFast/!67ea9400"
state_topic: "msh/US/2/json/LongFast/!67ea9400"
state_class: measurement
value_template: >-
{% if value_json.from == 4038675309 and value_json.payload.barometric_pressure is defined %}
@ -149,7 +149,7 @@ sensor:
- name: "Node 1 Gas Resistance"
unique_id: "node_1_gas_resistance"
state_topic: "msh/2/json/LongFast/!67ea9400"
state_topic: "msh/US/2/json/LongFast/!67ea9400"
state_class: measurement
value_template: >-
{% if value_json.from == 4038675309 and value_json.payload.gas_resistance is defined %}
@ -167,7 +167,7 @@ sensor:
```yaml
- name: "Node 1 Messages"
unique_id: "node_1_messages"
state_topic: "msh/2/json/LongFast/!67ea9400"
state_topic: "msh/US/2/json/LongFast/!67ea9400"
value_template: >-
{% if value_json.from == 4038675309 and value_json.payload.text is defined %}
{{ value_json.payload.text }}
@ -187,7 +187,7 @@ alias: Update Node 1 location
description: Update Meshtastic node when corresponding MQTT messages are seen.
trigger:
- platform: mqtt
topic: msh/2/json/LongFast/!67ea9400
topic: msh/US/2/json/LongFast/!67ea9400
payload: "on"
value_template: |-
{% if value_json.from == 4038675309 and
@ -216,7 +216,7 @@ Home Assistant entities can be created for any data type that is published to MQ
### Configure With Your Topic & Node ID's
- In every entity, replace `msh/2/json/LongFast/!67ea9400` with the topic your node publishes to. In this example, `!67ea9400` refers to the node that has mqtt enabled on the mesh and is publishing to the broker.
- In every entity, replace `msh/US/2/json/LongFast/!67ea9400` with the topic your node publishes to. In this example, `!67ea9400` refers to the node that has mqtt enabled on the mesh and is publishing to the broker.
- In every entity replace `4038675309` with the node number of the radio you wish to monitor. In this example `4038675309` is the node on the mesh with environment sensors and telemetry that I wish to observe. Node numbers can be found by monitoring the output in MQTT Explorer, listening with the MQTT addon or by using the Python CLI with `meshtastic --info`.
@ -227,7 +227,7 @@ Copy and paste these entities then change `name`, `unique_id`, `from`, and `stat
```yaml
- name: "Node 2 Messages"
unique_id: "node_2_messages"
state_topic: "msh/2/json/LongFast/!67ea9400"
state_topic: "msh/US/2/json/LongFast/!67ea9400"
value_template: >-
{% if value_json.from == 695318008 and value_json.payload.text is defined %}
{{ value_json.payload.text }}
@ -279,7 +279,7 @@ Add the following code to your automations.yaml file. Be sure to modify the `to
description: any message with an @Tropho will send to mobile device
trigger:
- platform: mqtt
topic: msh/2/json/LongFast/!67ea9400
topic: msh/US/2/json/LongFast/!67ea9400
condition:
- condition: template
value_template: "{{ trigger.payload_json.payload.text | regex_search('@Tropho') }}"
@ -336,7 +336,7 @@ This automation will check the send box for changes. After typing a message, ei
data:
qos: 0
retain: false
topic: msh/2/json/mqtt/!67ea9400
topic: msh/US/2/json/mqtt/!67ea9400
payload: >-
{"from":1743426560,"type":"sendtext","payload":"{{
states('input_text.meshtastic_send_box') }}"}

17
docs/software/integrations/mqtt/index.mdx
View file

@ -30,19 +30,16 @@ When MQTT is enabled, the Meshtastic device simply uplinks and/or downlinks ever
### MQTT [Topics](https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices)
If no specific [root topic](/docs/configuration/module/mqtt#root-topic) is configured, the default root topic will be `msh/`.
Each device that is connected to MQTT will publish its MQTT state (`online`/`offline`) to:
If no specific [root topic](/docs/configuration/module/mqtt#root-topic) is configured, the default root topic will be `msh/REGION`.
`msh/2/stat/USERID`, where `USERID` is the node ID of the gateway device (the one connected to MQTT).
For each channel where uplink and/or downlink is enabled, two other topics might be used:
For each channel where uplink and/or downlink is enabled, two topics might be used:
#### Protobufs topic
A gateway node will uplink and/or downlink raw ([protobuf](https://developers.google.com/protocol-buffers)) MeshPackets to the topic:
`msh/2/e/CHANNELNAME/USERID`, where `CHANNELNAME` is the name of the channel (firmware versions prior to 2.3.0 will publish to a topic with `/c/` in the place of `/e/`).
`msh/REGION/2/e/CHANNELNAME/USERID`, where `CHANNELNAME` is the name of the channel (firmware versions prior to 2.3.0 will publish to a topic with `/c/` in the place of `/e/`).
For example: `msh/2/e/LongFast/!abcd1234`
For example: `msh/US/2/e/LongFast/!abcd1234`
The payload is a raw protobuf, whose definitions for Meshtastic can be found [here](https://github.com/meshtastic/protobufs/blob/master/meshtastic). Reference guides for working with protobufs in several popular programming languages can be found [here](https://protobuf.dev/reference/). Looking at the MQTT traffic with a program like `mosquitto_sub` will tell you it's working, but you won't get much useful information out of it. For example:
@ -61,7 +58,7 @@ JSON is not supported on the nRF52 platform.
If [JSON is enabled](/docs/configuration/module/mqtt#json-enabled), packets from the following [port numbers](/docs/development/firmware/portnum) are serialized to JSON: `TEXT_MESSAGE_APP`, `TELEMETRY_APP`, `NODEINFO_APP`, `POSITION_APP`, `WAYPOINT_APP`, `NEIGHBORINFO_APP`, `TRACEROUTE_APP`, `DETECTION_SENSOR_APP`, `PAXCOUNTER_APP` and `REMOTE_HARDWARE_APP`. These are then forwarded to the topic:
`msh/2/json/CHANNELNAME/USERID`.
`msh/US/2/json/CHANNELNAME/USERID`.
An example of a received `NODEINFO_APP` message:
@ -103,9 +100,9 @@ If the message received contains valid JSON in the payload, the JSON is deserial
#### JSON downlink to instruct a node to send a message
You can also send a JSON message to the topic `msh/2/json/mqtt/` to instruct a gateway node to send a message to the mesh.
You can also send a JSON message to the topic `msh/US/2/json/mqtt/` to instruct a gateway node to send a message to the mesh.
To make this work, ensure that your node has a Meshtastic channel configured called "mqtt". Enable Downlink. The PSK can be random and doesn't matter. This channel allows the node to listen to messages on the `msh/2/json/mqtt/` topic.
To make this work, ensure that your node has a Meshtastic channel configured called "mqtt". Enable Downlink. The PSK can be random and doesn't matter. This channel allows the node to listen to messages on the `msh/US/2/json/mqtt/` topic.
Reboot your device after creating this channel.

8
docs/software/python-cli/installation.mdx
View file

@ -98,6 +98,14 @@ values={[
```shell
pip3 install --upgrade meshtastic
```
- Using pipx as an alternative to pip3 if `externally-managed-environment` error is encountered
```shell
sudo apt install pipx && pipx install meshtastic
```
- If using `pipx` it may be necessary to update `$PATH` by running:
```shell
pipx ensurepath
```
</TabItem>
<TabItem value="macos">

2
docs/software/python-cli/usage.mdx
View file

@ -90,6 +90,8 @@ Use `--ch-set psk random --ch-index 0` to assign a new (high quality) random AES
Use `--ch-set psk default --ch-index 0` to restore the standard 'default' (minimally secure, because it is in the source code for anyone to read) AES128 key.
Use `--ch-set psk base64:{key} --ch-index {index}` to set the PSK of a channel to a known entity
All `ch-set` commands need to have the `ch-index` parameter specified:
```shell

13
docusaurus.config.js
View file

@ -30,6 +30,10 @@ const config = {
srcDark: "design/logo/svg/Mesh_Logo_White.svg",
},
items: [
{
label: "Blog",
to: "blog",
},
{
label: "Docs",
to: "docs/introduction",
@ -38,10 +42,6 @@ const config = {
label: "Downloads",
to: "downloads",
},
{
label: "Donate",
to: "docs/contributing/#supporting-and-contributing-to-meshtastic",
},
{
label: "About",
position: "right",
@ -130,6 +130,11 @@ const config = {
showLastUpdateAuthor: true,
remarkPlugins: [remarkDefList],
},
blog: {
blogTitle: "Meshtastic Blog",
blogDescription:
"Discover in-depth insights from developers and maintainers, including project updates and changes. Hear from the community about their projects and ideas.",
},
theme: {
customCss: require.resolve("./src/css/custom.css"),
},

5
package.json
View file

@ -19,9 +19,10 @@
"@docusaurus/preset-classic": "3.1.1",
"@docusaurus/theme-common": "3.1.1",
"@docusaurus/theme-mermaid": "3.1.1",
"@giscus/react": "^3.0.0",
"@heroicons/react": "^2.1.1",
"@mdx-js/react": "^3.0.1",
"@meshtastic/js": "2.2.23-0",
"@meshtastic/js": "2.3.7-5",
"autoprefixer": "^10.4.17",
"base64-js": "^1.5.1",
"clsx": "^2.1.0",
@ -38,7 +39,7 @@
},
"devDependencies": {
"@biomejs/biome": "^1.5.3",
"@buf/meshtastic_protobufs.bufbuild_es": "1.7.2-20240216123215-6b07c41c68c9.1",
"@buf/meshtastic_protobufs.bufbuild_es": "2.0.0-20240906232734-3da561588c55.2",
"@docusaurus/module-type-aliases": "3.1.1",
"@tailwindcss/typography": "^0.5.10",
"@tsconfig/docusaurus": "^2.0.2",

4621
pnpm-lock.yaml
View file

File diff suppressed because it is too large Load diff

27
src/components/GiscusComponent/index.js Normal file
View file

@ -0,0 +1,27 @@
import { useColorMode } from "@docusaurus/theme-common";
import Giscus from "@giscus/react";
import React from "react";
export default function GiscusComponent() {
const { colorMode } = useColorMode();
return (
<Giscus
repo="meshtastic/meshtastic"
repoId="MDEwOlJlcG9zaXRvcnkzMzkzMDEyMjI="
category="Blog Post Comments"
categoryId="DIC_kwDOFDlTZs4Choq7"
mapping="pathname"
term="specific-term" //If you didn't select "Discussion title contains a specific term", omit.
strict="1"
reactionsEnabled="1"
emitMetadata="0"
inputPosition="top"
theme={colorMode}
lang="en"
loading="lazy"
crossorigin="anonymous"
async
/>
);
}

42
src/components/tools/FrequencyCalculator.tsx
View file

@ -215,6 +215,14 @@ const modemPresets = new Map<
Protobuf.Config.Config_LoRaConfig_ModemPreset,
Modem
>([
[
Protobuf.Config.Config_LoRaConfig_ModemPreset.SHORT_TURBO,
{
bw: 500,
cr: 5,
sf: 7,
},
],
[
Protobuf.Config.Config_LoRaConfig_ModemPreset.SHORT_FAST,
{
@ -323,8 +331,9 @@ export const FrequencyCalculator = (): JSX.Element => {
return (
<div className="flex flex-col border-l-[5px] shadow-md my-4 border-accent rounded-lg p-4 bg-secondary gap-2">
<div className="flex gap-2">
<label>Modem Preset:</label>
<label htmlFor="modemPreset">Modem Preset:</label>
<select
id="modemPreset"
value={modemPreset}
onChange={(e) =>
setModemPreset(
@ -342,8 +351,9 @@ export const FrequencyCalculator = (): JSX.Element => {
</select>
</div>
<div className="flex gap-2">
<label>Region:</label>
<label htmlFor="region">Region:</label>
<select
id="region"
value={region}
onChange={(e) => setRegion(Number.parseInt(e.target.value))}
>
@ -354,15 +364,21 @@ export const FrequencyCalculator = (): JSX.Element => {
))}
</select>
</div>
<div className="flex gap-2 mb-4">
<label className="font-semibold">Number of slots:</label>
<input type="number" disabled={true} value={numChannels} />
<label htmlFor="numSlots" className="font-semibold">
Number of slots:
</label>
<input
id="numSlots"
type="number"
disabled={true}
value={numChannels}
/>
</div>
<div className="flex gap-2">
<label>Frequency Slot:</label>
<label htmlFor="frequencySlot">Frequency Slot:</label>
<select
id="frequencySlot"
value={channel}
onChange={(e) => setChannel(Number.parseInt(e.target.value))}
>
@ -373,10 +389,16 @@ export const FrequencyCalculator = (): JSX.Element => {
))}
</select>
</div>
<div className="flex gap-2">
<label className="font-semibold">Frequency of slot:</label>
<input type="number" disabled={true} value={channelFrequency} />
<label htmlFor="slotFrequency" className="font-semibold">
Frequency of slot:
</label>
<input
id="slotFrequency"
type="number"
disabled={true}
value={channelFrequency}
/>
</div>
</div>
);

25
src/css/custom.css
View file

@ -82,7 +82,6 @@ html[data-theme="dark"] .header-github-link:before {
color: var(--ifm-link-color);
}
.split-container {
display: flex;
justify-content: space-between;
@ -105,7 +104,6 @@ html[data-theme="dark"] .header-github-link:before {
}
}
.indexCtasBody {
--ifm-button-size-multiplier: 1.6;
display: flex;
@ -138,8 +136,12 @@ html[data-theme="dark"] .header-github-link:before {
--ifm-button-border-color: rgb(77, 77, 77);
}
.indexCtas a:first-of-type {
margin-right: 20px;
}
.indexCtas a:last-of-type {
margin: 20px 36px;
margin: 20px;
}
.theme-doc-markdown {
@ -183,6 +185,7 @@ a + .navbar__link > svg {
.markdown :where(li):not(:where([class~="not-prose"] *)) {
margin-bottom: 0;
margin-top: 0;
line-height: 1.6;
}
.markdown
@ -262,3 +265,19 @@ td {
background-color: var(--ifm-hover-overlay);
border-radius: 0;
}
blockquote p::before,
blockquote p::after,
.markdown blockquote p::before,
.markdown blockquote p::after {
content: none !important;
display: none !important;
}
p {
line-height: 1.6;
}
.markdown img {
margin-bottom: 0;
}

48
src/css/faq.css
View file

@ -1,46 +1,46 @@
.accordion {
border-radius: 2px;
border: 1px solid var(--ifm-color-emphasis-200);
border-radius: 2px;
border: 1px solid var(--ifm-color-emphasis-200);
}
.accordion__item + .accordion__item {
border-top: 1px solid var(--ifm-color-emphasis-200);
border-top: 1px solid var(--ifm-color-emphasis-200);
}
.accordion__button {
background-color: var(--ifm-footer-background-color);
border: none;
cursor: pointer;
padding: calc(var(--ifm-pre-padding)/1.5);
text-align: left;
width: 100%;
background-color: var(--ifm-footer-background-color);
border: none;
cursor: pointer;
padding: calc(var(--ifm-pre-padding) / 1.5);
text-align: left;
width: 100%;
}
.accordion__button:hover {
background-color: var(--ifm-background-surface-color);
background-color: var(--ifm-background-surface-color);
}
.accordion__button:before {
border-bottom: 2px solid currentColor;
border-right: 2px solid currentColor;
content: '';
display: inline-block;
height: 10px;
margin-right: 12px;
transform: rotate(-45deg);
width: 10px;
border-bottom: 2px solid currentColor;
border-right: 2px solid currentColor;
content: "";
display: inline-block;
height: 10px;
margin-right: 12px;
transform: rotate(-45deg);
width: 10px;
}
.accordion__button[aria-expanded='true']::before,
.accordion__button[aria-selected='true']::before {
transform: rotate(45deg);
.accordion__button[aria-expanded="true"]::before,
.accordion__button[aria-selected="true"]::before {
transform: rotate(45deg);
}
[hidden] {
display: none;
display: none;
}
.accordion__panel {
background: var(--ifm-background-color);
padding: var(--ifm-pre-padding);
background: var(--ifm-background-color);
padding: var(--ifm-pre-padding);
}

6
src/pages/index.tsx
View file

@ -135,6 +135,12 @@ function Home() {
<Link className="button button--lg" to="/docs/getting-started">
Get Started
</Link>
<Link
className="button button--lg"
to="/docs/contributing/#supporting-and-contributing-to-meshtastic"
>
Donate
</Link>
</div>
</div>
</header>

37
src/theme/BlogPostPage/Metadata/index.js Normal file
View file

@ -0,0 +1,37 @@
import { PageMetadata } from "@docusaurus/theme-common";
import { useBlogPost } from "@docusaurus/theme-common/internal";
import React from "react";
export default function BlogPostPageMetadata() {
const { assets, metadata } = useBlogPost();
const { title, description, date, tags, authors, frontMatter } = metadata;
const { keywords } = frontMatter;
const image = assets.image ?? frontMatter.image;
return (
<PageMetadata
title={title}
description={description}
keywords={keywords}
image={image}
>
<meta property="og:type" content="article" />
<meta property="article:published_time" content={date} />
{/* TODO double check those article meta array syntaxes, see https://ogp.me/#array */}
{authors.some((author) => author.url) && (
<meta
property="article:author"
content={authors
.map((author) => author.url)
.filter(Boolean)
.join(",")}
/>
)}
{tags.length > 0 && (
<meta
property="article:tag"
content={tags.map((tag) => tag.label).join(",")}
/>
)}
</PageMetadata>
);
}

67
src/theme/BlogPostPage/index.js Normal file
View file

@ -0,0 +1,67 @@
import {
HtmlClassNameProvider,
ThemeClassNames,
} from "@docusaurus/theme-common";
import {
BlogPostProvider,
useBlogPost,
} from "@docusaurus/theme-common/internal";
import GiscusComponent from "@site/src/components/GiscusComponent";
import BlogLayout from "@theme/BlogLayout";
import BlogPostItem from "@theme/BlogPostItem";
import BlogPostPageMetadata from "@theme/BlogPostPage/Metadata";
import BlogPostPaginator from "@theme/BlogPostPaginator";
import TOC from "@theme/TOC";
import Unlisted from "@theme/Unlisted";
import clsx from "clsx";
import React from "react";
function BlogPostPageContent({ sidebar, children }) {
const { metadata, toc } = useBlogPost();
const { nextItem, prevItem, frontMatter, unlisted } = metadata;
const {
hide_table_of_contents: hideTableOfContents,
toc_min_heading_level: tocMinHeadingLevel,
toc_max_heading_level: tocMaxHeadingLevel,
} = frontMatter;
return (
<BlogLayout
sidebar={sidebar}
toc={
!hideTableOfContents && toc.length > 0 ? (
<TOC
toc={toc}
minHeadingLevel={tocMinHeadingLevel}
maxHeadingLevel={tocMaxHeadingLevel}
/>
) : undefined
}
>
{unlisted && <Unlisted />}
<BlogPostItem>{children}</BlogPostItem>
<GiscusComponent />
{(nextItem || prevItem) && (
<BlogPostPaginator nextItem={nextItem} prevItem={prevItem} />
)}
</BlogLayout>
);
}
export default function BlogPostPage(props) {
const BlogPostContent = props.content;
return (
<BlogPostProvider content={props.content} isBlogPostPage>
<HtmlClassNameProvider
className={clsx(
ThemeClassNames.wrapper.blogPages,
ThemeClassNames.page.blogPostPage,
)}
>
<BlogPostPageMetadata />
<BlogPostPageContent sidebar={props.sidebar}>
<BlogPostContent />
</BlogPostPageContent>
</HtmlClassNameProvider>
</BlogPostProvider>
);
}

BIN
static/documents/blog/Opposition_Letter.pdf Normal file
View file

Binary file not shown.

1
static/img/Open_Collective_logo_2021.svg
View file

@ -1 +0,0 @@
<svg width="457" height="60" xmlns="http://www.w3.org/2000/svg"><g fill="none" fill-rule="evenodd"><path d="M34.62 18.179C36.75 21.249 38 24.979 38 29s-1.25 7.75-3.38 10.821L29.697 34.9A12.16 12.16 0 0 0 31.214 29c0-2.14-.55-4.15-1.516-5.9l4.921-4.921ZM29.82 13.38 24.9 18.302A12.16 12.16 0 0 0 19 16.786c-6.746 0-12.214 5.468-12.214 12.214S12.254 41.214 19 41.214c2.14 0 4.15-.55 5.9-1.516l4.921 4.921A18.912 18.912 0 0 1 19 48C8.507 48 0 39.493 0 29s8.507-19 19-19c4.021 0 7.75 1.25 10.821 3.38Z" fill="#7FADF2"/><path d="M34.62 18.179C36.75 21.249 38 24.979 38 29s-1.25 7.75-3.38 10.821L29.697 34.9A12.16 12.16 0 0 0 31.214 29c0-2.14-.55-4.15-1.516-5.9l4.921-4.921Z" fill="#B8D3F4"/><g fill="#515F71"><path d="M110.7 13.6c-3.7 0-7.2 1.4-9.8 3.6v-2.3c0-.6-.5-1-1-1h-3.4c-.6 0-1 .5-1 1v43.7c0 .5.4 1 1 1h3.5c.5 0 1-.4 1-1V40.3c2.6 2.2 6.1 3.6 9.8 3.6 8.4 0 15.2-6.8 15.2-15.2-.2-8.4-7-15.1-15.3-15.1Zm0 24.8c-5.4 0-9.7-4.4-9.7-9.7 0-5.4 4.4-9.7 9.7-9.7 5.4 0 9.7 4.4 9.7 9.7 0 5.4-4.4 9.7-9.7 9.7ZM176.6 13.6c-3.7 0-7.1 1.3-9.7 3.5v-1.3c0-1.1-.9-2-2-2h-1.5c-1.1 0-2 .9-2 2v26.3c0 .8.7 1.5 1.5 1.5h2.5c.8 0 1.5-.7 1.5-1.5V29.6c0-5.4 4.4-10.6 9.7-10.6 3.5 0 9.7 1.9 9.7 10.6v12.5c0 .8.7 1.5 1.5 1.5h2.5c.8 0 1.5-.7 1.5-1.5V29.5c0-13.2-10.4-15.9-15.2-15.9ZM158.2 25.5c-1.5-7.1-8-12.3-15.6-11.9-7.6.4-13.8 6.4-14.3 14-.6 8.9 6.4 16.3 15.1 16.3 5.9 0 11-3.3 13.5-8.2.4-.7-.1-1.6-.9-1.8l-3-.6c-.5-.1-1 .1-1.3.6-1.7 2.7-4.8 4.6-8.2 4.6-3 0-5.7-1.4-7.5-3.5l17.2-7.2 5-2.3Zm-24.4 4.4c0-.4-.1-.8-.1-1.2 0-5.4 4.4-9.7 9.7-9.7 3 0 5.8 1.4 7.5 3.6l-17.1 7.3ZM77.3 13.4c-8.4 0-15.2 6.8-15.2 15.2 0 8.4 6.8 15.2 15.2 15.2 8.4 0 15.2-6.8 15.2-15.2 0-8.4-6.8-15.2-15.2-15.2Zm0 24.9c-5.4 0-9.7-4.4-9.7-9.7 0-5.4 4.4-9.7 9.7-9.7 5.4 0 9.7 4.4 9.7 9.7.1 5.3-4.3 9.7-9.7 9.7ZM258.7 13.3c-8.4 0-15.2 6.8-15.2 15.2 0 8.4 6.8 15.2 15.2 15.2 8.4 0 15.2-6.8 15.2-15.2 0-8.4-6.8-15.2-15.2-15.2Zm0 24.9c-5.4 0-9.7-4.4-9.7-9.7 0-5.4 4.4-9.7 9.7-9.7 5.4 0 9.7 4.4 9.7 9.7 0 5.3-4.3 9.7-9.7 9.7ZM390.6 4.3h-3.1c-.7 0-1.2.5-1.2 1.2v3.1c0 .7.5 1.2 1.2 1.2h3.1c.7 0 1.2-.5 1.2-1.2V5.5c0-.7-.6-1.2-1.2-1.2ZM454.5 33.7l-3.6-.7c-.4-.1-.8.1-1 .5-1.7 2.8-4.8 4.7-8.3 4.7-3 0-5.7-1.4-7.5-3.5l17.2-7.2 5.2-2.2c-1.5-7.1-8-12.3-15.6-11.9-7.6.4-13.8 6.5-14.3 14.1-.6 8.9 6.4 16.3 15.1 16.3 6 0 11.2-3.5 13.6-8.5.2-.8-.2-1.5-.8-1.6Zm-22.7-5.3c0-5.4 4.4-9.7 9.7-9.7 3 0 5.8 1.4 7.5 3.6l-17.2 7.3v-1.2ZM332 25.2c-1.5-7.1-8-12.3-15.6-11.9-7.6.4-13.8 6.5-14.3 14.1-.6 8.9 6.4 16.3 15.1 16.3 6 0 11.2-3.5 13.7-8.6.3-.6-.1-1.3-.7-1.4l-3.6-.7c-.4-.1-.8.1-1 .5-1.7 2.8-4.8 4.7-8.3 4.7-3 0-5.7-1.4-7.5-3.5l17.2-7.2 5-2.3Zm-24.5 4.4c0-.4-.1-.8-.1-1.2 0-5.4 4.4-9.7 9.7-9.7 3 0 5.8 1.4 7.5 3.6l-17.1 7.3ZM283.2.7h-3.6c-.5 0-.9.4-.9.9v40.7c0 .5.4 1 1 1h3.5c.5 0 1-.4 1-1V1.6c0-.5-.5-.9-1-.9ZM295.5.7h-3.6c-.5 0-.9.4-.9.9v40.7c0 .5.4 1 1 1h3.5c.5 0 1-.4 1-1V1.6c-.1-.5-.5-.9-1-.9ZM390.6 13.4h-3.1c-.7 0-1.2.5-1.2 1.2v27.6c0 .7.5 1.2 1.2 1.2h3.1c.7 0 1.2-.5 1.2-1.2V14.5c0-.6-.6-1.1-1.2-1.1ZM380.4 13.4h-3.9c-.4 0-.8-.4-.8-.8V1.5c0-.4-.4-.8-.8-.8H371c-.4 0-.8.4-.8.8v11.1c0 .4-.4.8-.8.8h-3.9c-.4 0-.8.4-.8.8V18c0 .4.4.8.8.8h3.9c.4 0 .8.4.8.8v22.7c0 .6.5 1 1 1h3.4c.6 0 1-.5 1-1V19.6c0-.4.4-.8.8-.8h3.9c.4 0 .8-.4.8-.8v-3.9c.1-.4-.2-.7-.7-.7ZM358.8 35.5c-.4-.4-1.1-.4-1.5 0-1.8 1.7-4.1 2.7-6.8 2.7-5.7 0-10.3-5-9.7-10.8.5-4.5 4.2-8.1 8.7-8.6 2.8-.3 5.5.7 7.4 2.4.6.5 1.5.5 2.1-.1l1.7-1.7c.6-.6.6-1.6 0-2.2-2.9-2.7-6.9-4.2-11.2-3.9-7.7.5-13.9 6.9-14.2 14.7-.3 8.6 6.6 15.6 15.2 15.6 4.1 0 7.9-1.6 10.6-4.3.4-.4.4-1.1 0-1.5l-2.3-2.3ZM239.1 35.5c-.4-.4-1.1-.4-1.5 0-1.8 1.7-4.1 2.7-6.8 2.7-5.7 0-10.3-5-9.7-10.8.5-4.5 4.2-8.1 8.7-8.6 2.8-.3 5.5.7 7.4 2.4.6.5 1.5.5 2.1-.1l1.7-1.7c.6-.6.6-1.6 0-2.2-2.9-2.7-6.9-4.2-11.2-3.9-7.7.5-13.9 6.9-14.2 14.7-.3 8.6 6.6 15.6 15.2 15.6 4.1 0 7.9-1.6 10.6-4.3.4-.4.4-1.1 0-1.5l-2.3-2.3ZM424 13.7h-4.9c-.1 0-.2.1-.2.2l-8 23.5c-.1.2-.4.2-.4 0l-8-23.5c0-.1-.1-.2-.2-.2h-4.9c-.2 0-.3.2-.2.3l9.9 29.1c0 .1.1.2.2.2h6.8c.1 0 .2-.1.2-.2l9.9-29.1c.1-.1 0-.3-.2-.3Z"/></g></g></svg>
Side by side

Before

Width:  |  Height:  |  Size: 3.9 KiB

BIN
static/img/about/link-budget-vs-data-rate.webp Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 20 KiB

BIN
static/img/blog/Meshtastic_PKC_ECDH.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 117 KiB

Some files were not shown because too many files have changed in this diff Show more