mirror of
https://github.com/meshtastic/meshtastic.git
synced 2024-11-12 16:44:20 -08:00
Merge branch 'master' into patch-1
This commit is contained in:
panaceya
GitHub
commit
b3d5af3ec6
|
|
@ -6,7 +6,7 @@ labels: ""
|
|||
assignees: ""
|
||||
---
|
||||
|
||||
Please - if you just have a question, post in our [forum](https://meshtastic.discourse.group) instead. Please reserve this system for requesting changes to the Meshtastic documentation.
|
||||
If you have a question, please post it on our [Meshtastic Discussions page](https://github.com/orgs/meshtastic/discussions) instead. This system is reserved specifically for requesting changes to the Meshtastic documentation.
|
||||
|
||||
**Describe what section of the docs is outdated or otherwise in need of change**
|
||||
Be as clear and concise as possible. Provide a URL or GitHub path to the doc you are referencing.
|
||||
|
|
|
|||
12
.github/pull_request_template.md
vendored
Normal file
12
.github/pull_request_template.md
vendored
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
<!-- Add or remove sections as needed -->
|
||||
## What did you change
|
||||
<!-- Describe what your changes will do if merged -->
|
||||
|
||||
## Why did you change it
|
||||
<!-- Be sure to link any relevant changes such as other PRs, issues, or Discord convos -->
|
||||
|
||||
## Screenshots
|
||||
### Before
|
||||
|
||||
|
||||
### After
|
||||
BIN
a0a26e4d40a5b9ccba9185eb70e2eaf66f0b0587_2_1380x888.jpeg
Normal file
BIN
a0a26e4d40a5b9ccba9185eb70e2eaf66f0b0587_2_1380x888.jpeg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 295 KiB |
20
blog/2024/October/meshtastic-solutions.mdx
Normal file
20
blog/2024/October/meshtastic-solutions.mdx
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: "Introducing Meshtastic Solutions: Supporting the Future of the Open Source Meshtastic Project"
|
||||
description: "Meshtastic Solutions is a new initiative designed to support the growth and long-term success of the open source Meshtastic project"
|
||||
slug: introducing-meshtastic-solutions
|
||||
authors: MeshtasticTeam
|
||||
tags: [meshtastic, meshtastic-solutions]
|
||||
date: 2024-10-23T13:00
|
||||
hide_table_of_contents: false
|
||||
image: "/design/web/social-preview-1200x630.png"
|
||||
---
|
||||
|
||||
The Meshtastic Team is excited to announce Meshtastic Solutions. This new venture will support the Meshtastic open source project, as well as provide a pool of expertise for anyone building tools and systems with Meshtastic. Meshtastic Solutions will ensure the long-term health and success of the Meshtastic team and ecosystem, as well as to spur development of the Meshtastic firmware, clients, libraries, and utilities.
|
||||
|
||||
This support will be fueled by partnerships with hardware vendors, many that you are familiar with, and some that are new to Meshtastic. In time, high quality devices will bear the Meshtastic seal of approval. Individual devices will be eligible for registration through Meshtastic, providing assurance of genuine hardware, as well as identity and cryptographic key attestation.
|
||||
|
||||
Meshtastic Solutions will also serve as a hub for businesses that need custom solutions or expert consultation within the Meshtastic ecosystem. Meshtastic Solutions is open for business for providing engineering, software solutions, and other support for custom use-cases. The first stage of this support is the Backer program, where existing manufacturers can financially support Meshtastic. This will be extended to include a full Partner program, offering in-depth design, close support, and device testing assistance. All with the goal of helping hardware vendors produce the best products possible for Meshtastic.
|
||||
|
||||
Meshtastic Solutions is separate from both the Meshtastic open source project, and Meshtastic LLC, the license and trademark holding entity. There will be no drastic changes to the Meshtastic project as a result of this new venture, with the exception of more development and higher quality products and solutions to choose from. This support from Backers and Partners will fuel some long-awaited milestones, including a well-tested Stable firmware release.
|
||||
|
||||
We’re looking forward to a stronger Meshtastic ecosystem that continues in the strong open source legacy the project has worked hard to foster. Follow our progress at [Meshtastic.com](https://meshtastic.com), and feel free to contact us with questions or to discuss business opportunities.
|
||||
|
|
@ -26,3 +26,11 @@ Jonathan:
|
|||
image_url: https://github.com/jp-bennett.png
|
||||
socials:
|
||||
github: jonathanbennett
|
||||
MeshtasticTeam:
|
||||
name: Meshtastic Team
|
||||
url: https://meshtastic.org
|
||||
image_url: https://github.com/meshtastic.png
|
||||
MeshtasticSolutions:
|
||||
name: Meshtastic Solutions
|
||||
url: https://meshtastic.com
|
||||
image_url: https://github.com/meshtastic-solutions.png
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Key components include:
|
|||
- **Protocol Buffers**: The backbone of communication and interactions, with changes and definitions managed in the [Meshtastic Protobuf Definitions repository](https://github.com/meshtastic/protobufs). For detailed information, see the [Protobuf API Reference](https://buf.build/meshtastic/protobufs/).
|
||||
- **Device Firmware**: Development for ESP32, nRF52, and RP2040 based devices occurs in the [firmware repository](https://github.com/meshtastic/firmware), focusing on C and C++ code for hardware interaction and communication.
|
||||
- **Firmware Modules**: Extend the core functionalities of devices and mesh networks, implemented mainly within the firmware repository. Modules are essential for adding new features and integrating devices within the ecosystem.
|
||||
- **CLI Apps (Device Interface)**: The [Meshtastic Python CLI](https://github.com/meshtastic/Meshtastic-python) enables interaction with device settings and functionalities, serving both as a utility and a library for application development.
|
||||
- **CLI Apps (Device Interface)**: The [Meshtastic Python CLI](https://github.com/meshtastic/python) enables interaction with device settings and functionalities, serving both as a utility and a library for application development.
|
||||
- **Web and JavaScript Apps**: Development for the hosted web server on ESP32 devices is done in [Meshtastic Web](https://github.com/meshtastic/web), with a JavaScript library for device interfaces available in [Meshtastic JS](https://github.com/meshtastic/meshtastic.js).
|
||||
- **Mobile and Desktop Apps**: Android, iOS, iPadOS, and macOS applications provide user interfaces for interacting with Meshtastic devices. Development for Android is detailed in the [Meshtastic-Android repository](https://github.com/meshtastic/Meshtastic-Android), while Apple platforms are supported by the [Meshtastic-Apple repository](https://github.com/meshtastic/Meshtastic-Apple).
|
||||
- **Documentation**: The source for the Meshtastic website and documentation resides in the [meshtastic/meshtastic repository](https://github.com/meshtastic/meshtastic). For guidelines on maintaining documentation, visit the [Maintaining Documentation](/docs/development/docs) page.
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ export const Faq = {
|
|||
"apple": [
|
||||
{
|
||||
title: "What version of iOS/iPadOS/macOS does the Meshtastic App Require?",
|
||||
content: `The Meshtastic App on Apple Clients require the following minimum OS versions: iOS 16.2, iPadOS 16.2, and macOS 13.`,
|
||||
content: `The Meshtastic Apple app supports the last two major versions of iOS, iPadOS or macOS.`,
|
||||
},
|
||||
{
|
||||
title: "How do I get the Apple Meshtastic App?",
|
||||
|
|
@ -164,9 +164,9 @@ If you use your ham radio license with Meshtastic, consider both the privileges
|
|||
{
|
||||
title: "How do I set my ham call sign?",
|
||||
content: `
|
||||
- On Android navigate to Radio configuration -> User and set Long name to your Ham Radio callsign, then activate the slider for 'Licensed amateur radio'.
|
||||
- On iPhone navigate to Settings -> User and set Long Name to your Ham Radio callsign, then activate the slider for 'Licensed Operator'.
|
||||
- Instructions for Enabling ham License from the Python CLI can be found [here](/docs/software/python/cli/usage#ham-radio-support).
|
||||
- On Android navigate to Radio configuration -> User and set Long name to your Ham Radio callsign, then activate the slider for 'Licensed amateur radio'.
|
||||
- On iPhone navigate to Settings -> User and set Long Name to your Ham Radio callsign, then activate the slider for 'Licensed Operator'.
|
||||
- Instructions for Enabling ham License from the Python CLI can be found [here](/docs/software/python/cli/usage#ham-radio-support).
|
||||
`,
|
||||
},
|
||||
],
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ If you are interested in a more technical overview of how Meshtastic works, visi
|
|||
|
||||
## Contributors
|
||||
|
||||
Meshtastic is an open source project available on GitHub. Our generous volunteers donate their personal time to write and maintain this codebase. If you would like to contribute see our [GitHub](https://github.com/meshtastic), join our [Discord server](https://discord.gg/ktMAKGBnBs), and read up on our [forum](https://meshtastic.discourse.group).
|
||||
Meshtastic is an open source project available on GitHub. Our generous volunteers donate their personal time to write and maintain this codebase. If you would like to contribute see our [GitHub](https://github.com/meshtastic), join our [Discord server](https://discord.gg/ktMAKGBnBs), and read up on our [Meshtastic Discussions](https://github.com/orgs/meshtastic/discussions).
|
||||
|
||||
<div className="indexCtasBody">
|
||||
<Link
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ sidebar_position: 1
|
|||
description: "Maximize your Meshtastic device's potential with detailed radio settings instructions, including frequency bands, data rates, and encryption options."
|
||||
---
|
||||
|
||||
import {FrequencyCalculator} from "/src/components/tools/FrequencyCalculator";
|
||||
import { FrequencyCalculator } from "/src/components/tools/FrequencyCalculator";
|
||||
|
||||
:::info
|
||||
Meshtastic is **not** LoRaWAN, Helium or TTN (TheThingsNetwork). Meshtastic uses the full spectrum frequency range designated to LoRa technology per region. This allows for several hundred possible frequency channels in the US region alone.
|
||||
|
|
@ -80,7 +80,7 @@ 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 / 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 |
|
||||
|
|
@ -97,7 +97,6 @@ The link budget used by these calculations assumes a transmit power of 22dBm and
|
|||
|
||||
|
||||
|
||||
|
||||
### Custom Settings
|
||||
|
||||
Custom settings can be applied by using [supported software](/docs/software).
|
||||
|
|
@ -121,10 +120,10 @@ Some example settings:
|
|||
|
||||
The link budget used by these calculations assumes a transmit power of 17dBm and an antenna with 0dB gain. Adjust your link budget assumptions based on your actual devices.
|
||||
|
||||
These frequency slot settings may not have been tested. Use at your own discretion. Share on https://meshtastic.discourse.group with your successes or failure.
|
||||
These frequency slot settings may not have been tested. Use at your own discretion. Share on the [Meshtastic Discussions page](https://github.com/orgs/meshtastic/discussions) with your successes or failure.
|
||||
|
||||
## 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.
|
||||
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.
|
||||
[^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.
|
||||
|
|
|
|||
|
|
@ -58,7 +58,6 @@ Default Very Long Slow
|
|||
|
||||
<img src="/img/records/MartinR7-message-trace.webp" alt="Trace" />
|
||||
|
||||
|
||||
#### Previous Ground Record: 254km
|
||||
|
||||
- **Range:** 254km (158 miles)
|
||||
|
|
@ -117,11 +116,11 @@ Default Long_Fast
|
|||
- **Firmware Version:** 1.2
|
||||
- **Antenna:** [868MHz Vertical 6dBi](https://ivent.co.nz/product/category/1000/868mhz%20vertical%206dbi%20antenna/38606)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<h5>Resources Used</h5>- http://www.heywhatsthat.com
|
||||
|
||||
|
|
|
|||
12
docs/blocks/_position-precision-bits.mdx
Normal file
12
docs/blocks/_position-precision-bits.mdx
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
| Precision bits | Metric | Imperial |
|
||||
| :------------: | :-----: | :--------: |
|
||||
| 10 | 23.3 km | 14.5 miles |
|
||||
| 11 | 11.7 km | 7.3 miles |
|
||||
| 12 | 5.8 km | 3.6 miles |
|
||||
| 13 | 2.9 km | 1.8 miles |
|
||||
| 14 | 1.5 km | 4787 feet |
|
||||
| 15 | 729 m | 2392 feet |
|
||||
| 16 | 364 m | 1194 feet |
|
||||
| 17 | 182 m | 597 feet |
|
||||
| 18 | 91 m | 299 feet |
|
||||
| 19 | 45 m | 148 feet |
|
||||
12
docs/blocks/_position-precision.mdx
Normal file
12
docs/blocks/_position-precision.mdx
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
| Metric | Imperial |
|
||||
| :-----: | :--------: |
|
||||
| 23.3 km | 14.5 miles |
|
||||
| 11.7 km | 7.3 miles |
|
||||
| 5.8 km | 3.6 miles |
|
||||
| 2.9 km | 1.8 miles |
|
||||
| 1.5 km | 4787 feet |
|
||||
| 729 m | 2392 feet |
|
||||
| 364 m | 1194 feet |
|
||||
| 182 m | 597 feet |
|
||||
| 91 m | 299 feet |
|
||||
| 45 m | 148 feet |
|
||||
|
|
@ -26,10 +26,24 @@ us on [Discord](https://discord.com/invite/ktMAKGBnBs) to add your group.
|
|||
|
||||
- [Canberra Meshtastic Community - Discord](https://discord.gg/4QgFsuaC3Z)
|
||||
|
||||
### New South Wales
|
||||
|
||||
- [Meshtastic Sydney - Facebook](https://www.facebook.com/groups/1041534027106861)
|
||||
|
||||
### Tasmania
|
||||
|
||||
- [Meshtastic User Group Tasmania](https://www.facebook.com/groups/1556630645195649)
|
||||
|
||||
## Brazil
|
||||
|
||||
- [Comunidade Meshtastic Brasil](https://t.me/+xS_5ZqDoP6BlODNh)
|
||||
|
||||
## Bulgaria
|
||||
|
||||
### Burgas
|
||||
|
||||
- [Burgas Mesh](https://discord.gg/5RKeFDPw)
|
||||
|
||||
## Canada
|
||||
|
||||
### Alberta
|
||||
|
|
@ -66,6 +80,7 @@ us on [Discord](https://discord.com/invite/ktMAKGBnBs) to add your group.
|
|||
### Ontario
|
||||
|
||||
- [Mesht Ontario](https://t.me/meshtOnt)
|
||||
- [Greater Ottawa Meshtastic Enthusiasts Discord](https://discord.gg/njcQ4BnKDU)
|
||||
|
||||
### Prince Edward Island
|
||||
|
||||
|
|
@ -106,7 +121,7 @@ us on [Discord](https://discord.com/invite/ktMAKGBnBs) to add your group.
|
|||
|
||||
## Israel
|
||||
|
||||
- [Israel Meshtastic Club](https://t.me/+yUGsbNw3zp41MGFk)
|
||||
- [Israel Meshtastic Club](https://www.mesh-il.com)
|
||||
|
||||
## Italy
|
||||
|
||||
|
|
@ -114,12 +129,19 @@ us on [Discord](https://discord.com/invite/ktMAKGBnBs) to add your group.
|
|||
- [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)
|
||||
|
||||
- [LithMesh Signal Group](https://signal.group/#CjQKIBScbOkXSG2bkFh_omdxjOM-XqYIU4eERDmGEDrm3jjmEhDyZhh-EeCLSfjfV-DoPvEQ)
|
||||
|
||||
## Mexico
|
||||
|
||||
- [Meshtastic Mexico Community](https://radioaficionados.mx/meshtastic)
|
||||
|
||||
## Netherlands, The
|
||||
|
||||
- [Meshtastic Netherlands Telegram](https://t.me/meshtastic_nl)
|
||||
|
|
@ -138,6 +160,10 @@ us on [Discord](https://discord.com/invite/ktMAKGBnBs) to add your group.
|
|||
- [MeshNet.si](https://meshnet.si)
|
||||
- [Slovenian Amature Radio Discord](https://discord.gg/uHDDE734DD)
|
||||
|
||||
## Spain
|
||||
|
||||
- [Meshtastic Spanish Community](https://t.me/meshtastic_esp)
|
||||
|
||||
## Taiwan
|
||||
|
||||
- [Meshtastic Taiwan Community 臺灣鏈網 - Facebook](https://www.facebook.com/groups/413628121046386)
|
||||
|
|
@ -217,9 +243,14 @@ us on [Discord](https://discord.com/invite/ktMAKGBnBs) to add your group.
|
|||
|
||||
- [Albuquerque Mesh](https://www.abqm.net)
|
||||
|
||||
### North Carolina
|
||||
|
||||
- [NCMesh](https://ncmesh.net)
|
||||
|
||||
### Ohio
|
||||
|
||||
- [Cincy Mesh](https://www.cincymesh.org)
|
||||
- [Dayton Mesh](https://daytonmesh.org/)
|
||||
|
||||
### Oklahoma
|
||||
|
||||
|
|
@ -241,6 +272,14 @@ us on [Discord](https://discord.com/invite/ktMAKGBnBs) to add your group.
|
|||
- [Cypress, Texas Meshtastic Club](https://discord.gg/KzuwNRwE6q)
|
||||
- [DFW / North Texas Mesh](https://discord.gg/jyzYRTtyMD)
|
||||
|
||||
### Virginia
|
||||
|
||||
- [MadisonMesh](https://madisonmesh.com/)
|
||||
|
||||
### Wisconsin
|
||||
|
||||
- [Meshconsin](https://meshconsin.org)
|
||||
|
||||
### Washington
|
||||
|
||||
- [Puget Mesh](https://PugetMesh.org)
|
||||
|
|
|
|||
|
|
@ -9,11 +9,9 @@ The Meshtastic ecosystem is highly extensible, and a number of community project
|
|||
|
||||
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.
|
||||
- [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.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,16 +0,0 @@
|
|||
---
|
||||
id: community-meshtasticator
|
||||
title: Meshtasticator
|
||||
sidebar_label: Meshtasticator (Simulator)
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
:::note
|
||||
|
||||
This is a community project maintained by @GUVWAF.
|
||||
Development can be followed on [GitHub](https://github.com/GUVWAF/Meshtasticator).
|
||||
Support should be sought from the respective authors.
|
||||
|
||||
:::
|
||||
|
||||
Meshtasticator is a discrete-event and interactive simulator that mimics the radio section of the device software and can be used to assess the performance of your scenario, or the scalability of the protocol. Meshtasticator was created and is maintained by GUVWAF and more information on its use and setup can be found on the [Meshtasticator Github page](https://github.com/GUVWAF/Meshtasticator)
|
||||
|
|
@ -79,14 +79,6 @@ The precision to use for the position in the map report. Defaults to a maximum d
|
|||
|
||||
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
|
||||
|
|
@ -145,7 +137,6 @@ The following configuration options are available in the Python CLI:
|
|||
| 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
|
||||
|
||||
|
|
|
|||
|
|
@ -12,9 +12,13 @@ The serial module config options are: Enabled, Echo, Mode, Receive GPIO, Transmi
|
|||
|
||||
This is an interface to talk to and control your Meshtastic device over a serial port. The module can be set to different [modes](#mode), each fulfilling a different use-case.
|
||||
|
||||
|
||||
|
||||
|
||||
<object data="https://www.youtube.com/embed/HdOiGKBtapw?autohide=1&autoplay=0" width="100%" height="400"></object>
|
||||
<object
|
||||
data="https://www.youtube.com/embed/HdOiGKBtapw?autohide=1&autoplay=0"
|
||||
width="100%"
|
||||
height="400"
|
||||
></object>
|
||||
|
||||
## Serial Module Config Values
|
||||
|
||||
|
|
@ -38,11 +42,20 @@ 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"
|
||||
- `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"
|
||||
|
||||
:::tip
|
||||
`PROTO` mode will show no obvious output when passively observed by a serial monitor. When testing, consider using the [Python CLI](https://github.com/meshtastic/python) with the `--listen` option, to view the stream of protobufs.
|
||||
:::
|
||||
|
||||
### Receive GPIO Pin
|
||||
|
||||
Set the GPIO pin to the RXD pin you have set up.
|
||||
|
||||
:::tip
|
||||
With the RAK4631 on the RAK19007 and some versions of the RAK19003 baseboards, the default pins are TXD1 (16) and RXD1 (15). For this device, setting [GPS Mode](/docs/configuration/radio/position/#gps-mode) to `Not_Present` is necessary. For other versions of the RAK19003 baseboard, the pins TXD0 (20) and RXD0 (19) are accessible.
|
||||
:::
|
||||
|
||||
### Transmit GPIO Pin
|
||||
|
||||
Set the GPIO pin to the TXD pin you have set up.
|
||||
|
|
@ -59,7 +72,7 @@ The serial baud rate.
|
|||
|
||||
The amount of time to wait before we consider your packet as "done".
|
||||
|
||||
### Override Console Serial Port
|
||||
### Override Console Serial Port
|
||||
|
||||
If set to true, this will allow Serial Module to control (set baud rate) and use the primary USB serial bus for output. This is only useful for NMEA and CalTopo modes and may behave strangely or not work at all in other modes. Setting TX/RX pins in the Serial Module config will cause this setting to be ignored.
|
||||
|
||||
|
|
@ -111,18 +124,17 @@ All serial module config options are available in the python CLI. Example comman
|
|||
|
||||
:::
|
||||
|
||||
| Setting | Acceptable Values | Default |
|
||||
| :------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------: |
|
||||
| serial.enabled | `true`, `false` | `false` |
|
||||
| serial.echo | `true`, `false` | `false` |
|
||||
| serial.mode | `DEFAULT` `SIMPLE` `PROTO` `TEXTMSG`, `NMEA`, `CALTOPO` | `DEFAULT` |
|
||||
| serial.rxd | GPIO Pin Number 1-39 | Default of `0` is Unset |
|
||||
| serial.txd | GPIO Pin Number 1-33 | Default of `0` is Unset |
|
||||
| serial.baud | `BAUD_DEFAULT` `BAUD_110` `BAUD_300` `BAUD_600` `BAUD_1200` `BAUD_2400` `BAUD_4800` `BAUD_9600` `BAUD_19200` `BAUD_38400` `BAUD_57600` `BAUD_115200` `BAUD_230400` `BAUD_460800` `BAUD_576000` `BAUD_921600` | `BAUD_DEFAULT` (38400) |
|
||||
| serial.timeout | `integer` (milli seconds) | Default of `0` corresponds to 250 ms |
|
||||
| Setting | Acceptable Values | Default |
|
||||
| :---------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :----------------------------------: |
|
||||
| serial.enabled | `true`, `false` | `false` |
|
||||
| serial.echo | `true`, `false` | `false` |
|
||||
| serial.mode | `DEFAULT` `SIMPLE` `PROTO` `TEXTMSG`, `NMEA`, `CALTOPO` | `DEFAULT` |
|
||||
| serial.rxd | GPIO Pin Number 1-39 | Default of `0` is Unset |
|
||||
| serial.txd | GPIO Pin Number 1-33 | Default of `0` is Unset |
|
||||
| serial.baud | `BAUD_DEFAULT` `BAUD_110` `BAUD_300` `BAUD_600` `BAUD_1200` `BAUD_2400` `BAUD_4800` `BAUD_9600` `BAUD_19200` `BAUD_38400` `BAUD_57600` `BAUD_115200` `BAUD_230400` `BAUD_460800` `BAUD_576000` `BAUD_921600` | `BAUD_DEFAULT` (38400) |
|
||||
| serial.timeout | `integer` (milli seconds) | Default of `0` corresponds to 250 ms |
|
||||
| serial.override_console_serial_port | `true`, `false` | `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.
|
||||
|
|
@ -255,6 +267,7 @@ while True:
|
|||
```
|
||||
|
||||
#### Arduino Mini Pro BOM
|
||||
|
||||
- An Arduino Mini Pro with example sketch from below uploaded to it.
|
||||
- T-Beam V1.1 running Meshtastic
|
||||
- PIR Sensor ([Adafruit Breadboard Model](https://www.adafruit.com/product/4871))
|
||||
|
|
|
|||
|
|
@ -2,17 +2,21 @@
|
|||
id: telemetry
|
||||
title: Telemetry Module Configuration
|
||||
sidebar_label: Telemetry
|
||||
description: This module allows sharing of Device, Environment, and Air Quality metrics from your Meshtastic device.
|
||||
description: This module allows sharing of Device, Environment, Health, and Air Quality metrics from your Meshtastic device.
|
||||
---
|
||||
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
The Telemetry Module provides three types of data over the mesh: Device metrics (Battery Level, Voltage, Channel Utilization and Airtime) from your Meshtastic device, Environment Metrics from attached I2C sensors, and Air Quality Metrics from attached I2C particle sensors.
|
||||
The Telemetry Module provides four types of data over the mesh: Device metrics (Battery Level, Voltage, Channel Utilization and Airtime) from your Meshtastic device, Environment Metrics, Air Quality Metrics, and Health metrics (Heart rate, Oxygen Saturation and body temperature).
|
||||
|
||||
Supported sensors connected to the I2C bus of the device will be automatically detected at startup. Environment Telemetry and Air Quality must be enabled for them to be instrumented and their readings sent over the mesh.
|
||||
Supported sensors connected to the I2C bus of the device will be automatically detected at startup. The Environment Telemetry, Air Quality, and Health Telemetry modules must be enabled for them to be instrumented and their readings sent over the mesh.
|
||||
|
||||
<object data="https://www.youtube.com/embed/6jj1s-fsPlc?autohide=1&autoplay=0" width="100%" height="400"></object>
|
||||
<object
|
||||
data="https://www.youtube.com/embed/6jj1s-fsPlc?autohide=1&autoplay=0"
|
||||
width="100%"
|
||||
height="400"
|
||||
></object>
|
||||
|
||||
### Currently Supported Sensor Types
|
||||
|
||||
|
|
@ -32,6 +36,8 @@ Supported sensors connected to the I2C bus of the device will be automatically d
|
|||
| SHT31 | 0x44 | Temperature and humidity |
|
||||
| PMSA003I| 0x12 | Concentration units by size and particle counts by size |
|
||||
| DFROBOT_LARK | 0x42 | Temperature, barometric pressure, humidity, wind direction, wind speed |
|
||||
| MAX30102 | 0x57 | Heart Rate, Oxygen Saturation, and body temperature |
|
||||
| MLX90614 | 0x5A | Body temperature |
|
||||
|
||||
## Module Config Values
|
||||
|
||||
|
|
@ -49,7 +55,7 @@ Default is `1800` seconds (30 minutes).
|
|||
|
||||
How often we should send Device Metrics over the mesh.
|
||||
|
||||
Default is `1800` seconds (30 minutes).
|
||||
Default is `1800` seconds (30 minutes).
|
||||
|
||||
Device Metrics to a connected client app will always be sent once per minute, regardless of this setting.
|
||||
|
||||
|
|
@ -77,6 +83,28 @@ This option is used to configure the interval (in seconds) that should be used t
|
|||
|
||||
Default is `1800` seconds (30 minutes).
|
||||
|
||||
### Power Metrics Enabled
|
||||
|
||||
This option is used to enable/disable the sending of power telemetry as gathered by an attached supported voltage/current sensor. Note that this does not need to be enabled to monitor the voltage of the battery.
|
||||
|
||||
Default is `false`.
|
||||
|
||||
### Power Metrics Interval
|
||||
|
||||
This option is used to configure the interval (in seconds) that should be used to send power metrics from an attached supported sensor over the mesh network.
|
||||
|
||||
### Health Telemetry Enabled
|
||||
|
||||
This option is used to enable/disable the sending of health data from an attached supported sensor over the mesh network.
|
||||
|
||||
Default is `false`.
|
||||
|
||||
### Health Telemetry Interval
|
||||
|
||||
This option is used to configure the interval (in seconds) that should be used to send health data from an attached supported sensor over the mesh network.
|
||||
|
||||
Default is `1800` seconds (30 minutes).
|
||||
|
||||
## Telemetry Config Client Availability
|
||||
|
||||
<Tabs
|
||||
|
|
@ -124,15 +152,21 @@ All telemetry module config options are available in the python CLI. Example com
|
|||
|
||||
## Settings
|
||||
|
||||
| Setting | Acceptable Values | Default |
|
||||
| :---------------------------------------: | :-----------------: | :---------------------------------------: |
|
||||
| Setting | Acceptable Values | Default |
|
||||
| :---------------------------------------: | :-----------------: | :----------------------------------------: |
|
||||
| telemetry.device_update_interval | `integer` (seconds) | Default `0` is 30 minutes(`1800` seconds). |
|
||||
| telemetry.environment_display_fahrenheit | `true`, `false` | `false` |
|
||||
| telemetry.environment_measurement_enabled | `true`, `false` | `false` |
|
||||
| telemetry.environment_screen_enabled | `true`, `false` | `false` |
|
||||
| telemetry.environment_display_fahrenheit | `true`, `false` | `false` |
|
||||
| telemetry.environment_measurement_enabled | `true`, `false` | `false` |
|
||||
| telemetry.environment_screen_enabled | `true`, `false` | `false` |
|
||||
| telemetry.environment_update_interval | `integer` (seconds) | Default `0` is 30 minutes(`1800` seconds). |
|
||||
| telemetry.air_quality_enabled | `true`, `false` | `false` |
|
||||
| telemetry.air_quality_interval | `integer` (seconds) | Default `0` is 30 minutes(`1800` seconds). |
|
||||
| telemetry.air_quality_enabled | `true`, `false` | `false` |
|
||||
| telemetry.air_quality_interval | `integer` (seconds) | Default `0` is 30 minutes(`1800` seconds). |
|
||||
| telemetry.power_measurement_enabled | `true`, `false` | `false` |
|
||||
| telemetry.power_update_interval | `integer` (seconds) | Default `0` is 30 minutes(`1800` seconds). |
|
||||
| telemetry.health_measurement_enabled | `true`, `false` | `false` |
|
||||
| telemetry.health_update_interval | `integer` (seconds) | Default `0` is 30 minutes(`1800` seconds). |
|
||||
| telemetry.health_screen_enabled | `true`, `false` | `false` |
|
||||
|
||||
|
||||
:::tip
|
||||
|
||||
|
|
|
|||
|
|
@ -16,6 +16,8 @@ Only nodes that know the encryption key of the channel you use can be tracked. A
|
|||
|
||||
In order to use it, make sure your devices use firmware version 2.0.8 or higher.
|
||||
|
||||
From firmware version ≥ 2.5, the route back to the origin is recorded, along with the Signal-to-Noise Ratio (SNR) for each link. Nodes with older firmware or those unable to decrypt the traceroute will be shown as "Unknown" (represented by an ID equal to 4294967295 or 0xFFFFFFFF in hexadecimal) if all nodes in the route are using at least firmware version 2.3.12.
|
||||
|
||||
<object data="https://www.youtube.com/embed/PKUmaELKaUo?autohide=1&autoplay=0" width="100%" height="400"></object>
|
||||
|
||||
## Repeater Behavior
|
||||
|
|
@ -63,18 +65,20 @@ Where for `destinationId` you have to fill in the ID of the destination you want
|
|||
meshtastic --traceroute '!bff18ce4'
|
||||
Connected to radio
|
||||
Sending traceroute request to !bff18ce4 (this could take a while)
|
||||
Route traced:
|
||||
!25048234 --> !ba4bf9d0 --> !bff18ce4
|
||||
Route traced towards destination:
|
||||
!25048234 --> !ba4bf9d0 (6.0dB) --> !bff18ce4 (-3.5dB)
|
||||
Route traced back to us:
|
||||
!bff18ce4 --> !ba4bf9d0 (-2.75dB) --> !25048234 (5.25dB)
|
||||
```
|
||||
|
||||
The first ID shown is the device you are connected to with the CLI. As you can see, this packet went through one other node to get to its destination.
|
||||
The first ID shown is the origin device connected via the CLI. As demonstrated in the image above, the packet traveled through one additional node to reach its destination and return.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="web">
|
||||
|
||||
#### Web
|
||||
|
||||
Not yet implemented.
|
||||
After selecting a node from the list, click the "route" button in the top-right corner to send a traceroute request to the selected node. The result will be displayed on the node’s message page.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
|
|
|||
|
|
@ -7,6 +7,7 @@ description: Understand how to configure channels on your Meshtastic device, inc
|
|||
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
import PositionPrecisionBits from "@site/docs/blocks/_position-precision-bits.mdx";
|
||||
|
||||
The Channels config options are: Index, Roles, and Settings. Channel config uses an admin message sending a `Channel` protobuf which also consists of a `ChannelSettings` or `ModuleSettings` protobuf.
|
||||
|
||||
|
|
@ -68,10 +69,10 @@ The Channel Settings options are: Name, PSK, Downlink Enabled, and Uplink Enable
|
|||
|
||||
A short identifier for the channel. _(< 12 bytes)_
|
||||
|
||||
| Reserved Name | Purpose |
|
||||
| :------------: | :----------------------------------------------------------------------------------------------------------------------------: |
|
||||
| `""` (default) | If left empty on the Primary channel, this designates the `default` channel. |
|
||||
| `admin` | On Secondary channels, the name `admin` (case sensitive) designates the `admin` channel used to administer nodes over the mesh |
|
||||
| Reserved Name | Purpose |
|
||||
| :------------: | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
|
||||
| `""` (default) | If left empty on the Primary channel, this designates the `default` channel. |
|
||||
| `admin` | On Secondary channels, the name `admin` (case sensitive) designates the `admin` channel used to administer nodes over the mesh. Note that this is a Legacy feature, see [Remote Admin](docs/configuration/remote-admin.mdx) for details. |
|
||||
|
||||
:::note
|
||||
|
||||
|
|
@ -117,13 +118,9 @@ The `position_precision` value is an integer between 0 and 32:
|
|||
|
||||
- A value of 0 means that location data is never sent over the given channel.
|
||||
- A value of 32 means that location data is sent with full precision.
|
||||
- Values in between indicate the number of bits of precision to be sent.
|
||||
- Values in between indicate the number of bits of precision to be sent, which correspond to a position precision from the table below.
|
||||
|
||||
Some useful values and their approximate precisions:
|
||||
|
||||
- 11: Large region, around ±11 kilometers
|
||||
- 13: City-sized region, around ±3 kilometers
|
||||
- 16: Neighborhood-level precision, around ±350 meters
|
||||
<PositionPrecisionBits />
|
||||
|
||||
The client applications have implemented different levels of precision giving the user a practical range to choose from. Setting across the full range of integers can be done via the Python CLI. See [Setting Position Precision](/docs/configuration/radio/channels/#setting-position-precision) for examples on setting different levels of precision using CLI.
|
||||
|
||||
|
|
@ -158,14 +155,14 @@ See [Android App Usage](/docs/software/android/usage#setup-a-channel) for more f
|
|||
|
||||
[](/img/android/android-channel-edit.webp)
|
||||
|
||||
Tap the Channel Name (or the pen icon) to access the Channel Menu:
|
||||
Tap "Edit" to access the Channel Menu:
|
||||
|
||||
1. Add, remove, or modify secondary channels
|
||||
2. Create or modify encryption keys
|
||||
3. Enable uplink and downlink for individual channels
|
||||
4. Set the position precision value
|
||||
|
||||
|
||||
4. Position enabled
|
||||
5. Precise location (if position is enabled)
|
||||
6. Position precision (if precise location is disabled)
|
||||
|
||||
</TabItem>
|
||||
|
||||
|
|
|
|||
|
|
@ -115,6 +115,14 @@ For testing it is useful sometimes to force a node to never listen to particular
|
|||
|
||||
Setting this to option to 'true' means the device will ignore any messages it receives via LoRa that came via MQTT somewhere along the path towards the device. Note this only works when your device and the MQTT node are running at least firmware version 2.2.19.
|
||||
|
||||
### OK to MQTT
|
||||
|
||||
Acceptable values: `true`, `false`
|
||||
|
||||
Default is `false`. When set to `true`, this configuration indicates that the user approves their packets to be uploaded to MQTT. If set to `false`, nodes receiving your packets are requested not to forward packets to MQTT. This configuration only applies to Channels configured with the `defaultpsk` and `eventpsk` keys set in the Meshtastic Firmware; Channels with custom keys ignore this setting.
|
||||
|
||||
**Important:** This is not a cryptographic solution but a polite request that is enforced in the official firmware.
|
||||
|
||||
### Override Duty Cycle Limit
|
||||
|
||||
Setting this option to 'true' means the device will ignore the hourly duty cycle limit in Europe. This means that you might violate regulations if the device transmits too much. By default, this option is set to 'false,' which means the device will stop sending data when it reaches the hourly limit and will start again when it is allowed to do so.
|
||||
|
|
@ -185,6 +193,7 @@ LoRa config commands are available in the python CLI. Example commands are below
|
|||
| lora.tx_enabled | `false`, `true` | `true` |
|
||||
| lora.channel_num | `0`, `1` to `NUM_CHANNELS` | `0` |
|
||||
| lora.ignore_mqtt | `false`, `true` | `false` |
|
||||
| lora.config_ok_to_mqtt | `true`, `false` | `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` |
|
||||
|
|
|
|||
|
|
@ -3,201 +3,157 @@ id: remote-admin
|
|||
title: Remote Node Administration
|
||||
sidebar_label: Remote Nodes
|
||||
sidebar_position: 3
|
||||
description: An advanced feature which allows remote administration of a device through a secure channel on the Mesh instead of via Bluetooth, Serial, or IPv4.
|
||||
description: An advanced feature for securely administering remote devices over the mesh network instead of via Bluetooth, Serial, or IPv4.
|
||||
---
|
||||
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
:::caution Disclaimer
|
||||
This is an advanced feature that few users should need. Keep in mind that it is possible (if you are not careful) to assign settings to a remote node that cause it to completely drop off of your mesh. We advise network admins have a test node to test settings with before applying changes to a remote node to prevent this.
|
||||
This is an advanced feature intended for experienced users. It’s possible (if not done carefully) to apply settings to a remote node that could cause it to disconnect from the mesh. Network admins are advised to use a test node to trial settings before applying changes to a remote node to prevent this.
|
||||
:::
|
||||
|
||||
This feature allows you to remotely administer Meshtastic nodes through the mesh.
|
||||
This feature allows secure remote administration of Meshtastic nodes over the mesh network.
|
||||
|
||||
By default, nodes will only respond to administrative commands via the local USB, Bluetooth, or TCP interfaces. This basic security measure prevents unauthorized access and defines how standard administration and settings changes are managed. The only difference with remote administration is that commands are sent securely as Admin Messages over the mesh.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
For any node that you want to administer, you must:
|
||||
For firmware versions 2.5 and later, remote administration is achieved by storing the public key of the local node in one of the Admin Key fields within the remote node’s Security Config. Each remote node can store up to three unique Admin Keys, providing flexibility for managing nodes across the network.
|
||||
|
||||
1. Configure a channel with the channel name of `admin`.
|
||||
2. Set the PSK for the `admin` channel with the same key you wish to administer other all other nodes of the mesh with.
|
||||
For firmware versions 2.4.x and earlier, this is achieved by creating a secondary channel named `admin` with a shared PSK. In this setup, messages exchanged on this channel are encrypted only with the channel’s PSK, allowing any node in the channel to administer others.
|
||||
|
||||
## Creating the admin channel
|
||||
This `admin` channel method is still supported in firmware versions 2.5 and later, but must be specifically enabled via the "Legacy Admin channel" setting and is only for managing pre-2.5 nodes. A firmware version 2.5 and later node cannot be managed in this way.
|
||||
|
||||
By default, nodes will **only** respond to administrative commands via the local USB/Bluetooth/TCP interface. This provides basic security to prevent unauthorized access and is how normal administration and settings changes work. The only difference for the remote case is that we are sending those commands over the mesh.
|
||||
|
||||
Before a node will allow remote admin access, it must have a primary channel:
|
||||
|
||||
```shell title="Command"
|
||||
meshtastic --info
|
||||
```
|
||||
```markdown title="Expected output"
|
||||
Connected to radio
|
||||
...
|
||||
Channels:
|
||||
PRIMARY psk=default { "psk": "AQ==" }
|
||||
Primary channel URL: https://meshtastic.org/e/#CgMSAQESCggBOANAA0gBUBs
|
||||
```
|
||||
|
||||
From this output you see can that this node knows about only one channel and that its PSK is set to the default value.
|
||||
|
||||
Now we add an admin channel:
|
||||
:::note
|
||||
The name of the channel is important and must be `admin`.
|
||||
:::
|
||||
```shell title="Command"
|
||||
meshtastic --ch-add admin
|
||||
```
|
||||
```shell title="Expected output"
|
||||
Connected to radio
|
||||
Writing modified channels to device
|
||||
```
|
||||
Run `meshtastic --info` and your channels will now look like this:
|
||||
|
||||
```shell title="Expected output"
|
||||
Connected to radio
|
||||
...
|
||||
Channels:
|
||||
PRIMARY psk=default { "psk": "AQ==" }
|
||||
SECONDARY psk=secret { "psk": "YyDCitupTAOOXTcaMDxyNhDpPa3eThiQFziPFCqT0mo=", "name": "admin" }
|
||||
Primary channel URL: https://meshtastic.org/e/#CgMSAQESCggBOANAA0gBUBs
|
||||
Complete URL (includes all channels): https://meshtastic.org/e/#CgMSAQEKKRIgYyDCitupTAOOXTcaMDxyNhDpPa3eThiQFziPFCqT0moaBWFkbWluEgoIATgDQANIAVAb
|
||||
```
|
||||
|
||||
Notice that now we have a new secondary channel and the `--info` option prints out TWO URLs. The `Complete URL` includes all of the channels this node understands. The URL contains the preshared keys and should be treated with caution and kept a secret. When deploying remote administration, you only need the node you want to administer and the node you are locally connected to, to know this new "admin" channel. All of the other nodes will forward the packets as long as they are a member of the primary channel.
|
||||
|
||||
## Sharing the admin channel with other nodes
|
||||
|
||||
Creating an "admin" channel automatically generates a preshared key. In order to administer other nodes remotely, we need to copy the preshared key to the new nodes.
|
||||
|
||||
For this step you need physical access to both the nodes.
|
||||
|
||||
1. Create the "admin" channel on the "local node" using the instructions above.
|
||||
2. Copy the "Complete URL" someplace for permanent reference/access.
|
||||
3. Connect to the "remote node" over the USB port.
|
||||
4. For the "remote node" type
|
||||
|
||||
```shell
|
||||
meshtastic --seturl the-url-from-step-2
|
||||
```
|
||||
|
||||
5. Run `meshtastic --info` and confirm that the "Complete URL" is the same for both of the nodes.
|
||||
|
||||
At this point you can take your remote node and install it far away. You will still be able to change any of its settings.
|
||||
|
||||
## Remotely administering your node
|
||||
|
||||
Now that both your local node and the remote node contain your secret admin channel key, you can now change settings remotely:
|
||||
|
||||
Get the node list from the local node:
|
||||
|
||||
```shell title="Command"
|
||||
meshtastic --nodes
|
||||
```
|
||||
```markdown title="Expected output"
|
||||
Connected to radio
|
||||
/-------------------------------------------------------------------------------------------------------------\
|
||||
|N| User |AKA| ID |Latitude|Longitude|Altitude|Battery| SNR | LastHeard | Since |
|
||||
|-+------------+---+---------+--------+---------+--------+-------+---------+-------------------+--------------|
|
||||
|1|Unknown 9058|?58|!28979058|25.0382°|121.5731°| N/A | N/A |-13.50 dB|2021-03-22 09:25:42|19 seconds ago|
|
||||
\-------------------------------------------------------------------------------------------------------------/
|
||||
```
|
||||
|
||||
Using the node ID from that list, send a message through the mesh telling that node to change its owner name.
|
||||
:::info
|
||||
The --dest argument value must be in single quotes for linux/mac: '!28979058', no quotes for Windows: !28979058.
|
||||
Remote Admin is complemented by setting [Managed Mode](/docs/configuration/radio/security/#managed-mode) on the remote node, which restricts radio configurations on that node. It is not necessary to set Managed Mode for Remote Admin to function.
|
||||
:::
|
||||
```shell title="Command"
|
||||
meshtastic --dest '!28979058' --set-owner "Im Remote"
|
||||
```
|
||||
```markdown title="Expected output"
|
||||
Connected to radio
|
||||
Setting device owner to Im Remote
|
||||
Waiting for an acknowledgment from remote node (this could take a while)
|
||||
|
||||
## Remote Admin 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
|
||||
|
||||
#### Setting up Remote Admin Using the PKC Method
|
||||
|
||||
1. Connect to the local node that will be administering the remote node.
|
||||
2. Go to **⋮ > Radio Configuration > [Security](/docs/configuration/radio/security/#public-key)** to find its public key.
|
||||
3. Copy the public key to use for configuring the remote node.
|
||||
4. Connect to the node that will be the remotely administered node.
|
||||
5. Go to the same **Security** menu as in Step 2, and press **"Add"** to paste the public key of the local node into an Admin Key field.
|
||||
6. Up to 3 Admin Keys may be supplied, one per field, allowing up to 3 controlling nodes.
|
||||
|
||||
#### Setting up Remote Admin using the Legacy method
|
||||
|
||||
An Admin channel is set up by entering a secondary channel with the name `admin` using the method described in [Channels](/docs/configuration/radio/channels/)
|
||||
|
||||
Legacy admin is enabled using the Legacy Admin channel option in [Security Config](/docs/configuration/radio/security/#admin-channel-enabled).
|
||||
|
||||
#### Carrying out Remote Admin tasks
|
||||
|
||||
1. Open the Meshtastic App, connect to the local controlling node.
|
||||
2. In the node list pane, select a node by tapping the Short Name in the colored bubble, then select More details.
|
||||
3. In the more details screen, select Remote Administration, next to a gear icon.
|
||||
4. From the Remote Administration screen, all Radio and Module configuration options are available.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="apple">
|
||||
|
||||
#### Apple
|
||||
|
||||
#### Setting up Remote Admin Using the PKC Method
|
||||
|
||||
1. Connect to the node that will be used to administer the remote node.
|
||||
2. Go to Settings > App Settings on this node and enable **Administration**.
|
||||
3. Navigate to **Settings > Radio Configuration > [Security](/docs/configuration/radio/security/#public-key)** to find its public key.
|
||||
4. Copy the public key to use for configuring the remote node.
|
||||
5. Connect to the remote node.
|
||||
6. In **Settings > Radio Configuration > Security**, add the public key of the local node as an Admin Key.
|
||||
7. Up to 3 Admin Keys may be supplied, allowing up to 3 controlling nodes.
|
||||
8. On the remote node, go to **Settings > App Settings** and enable **Administration**.
|
||||
|
||||
#### Setting up Remote Admin using the Legacy method
|
||||
|
||||
An Admin channel is set up by entering a secondary channel with the name `admin` using the method described in [Channels](/docs/configuration/radio/channels/)
|
||||
|
||||
Legacy admin is enabled using the Legacy Admin channel option in [Security Config](/docs/configuration/radio/security/#admin-channel-enabled).
|
||||
|
||||
#### Carrying out Remote Admin tasks
|
||||
|
||||
1. Open the Meshtastic App and connect to the local node you’re using to administer the remote node.
|
||||
2. Go to **Settings**.
|
||||
3. Select the node you want to manage under **Settings > Configure Node**.
|
||||
4. Suported Radio and Module settings for the remote node will be accessible from the **Settings** screen.
|
||||
5. When finished administering the remote node, select your own node again in Settings > Configure Node.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="cli">
|
||||
|
||||
#### CLI
|
||||
|
||||
#### Setting up Remote Admin Using the PKC Method
|
||||
|
||||
1. Connect via USB to the node that will be administering the remote node.
|
||||
2. Retrieve its Public Key by running:
|
||||
```bash
|
||||
meshtastic --get security.public_key
|
||||
```
|
||||
3. Copy the public key to use when configuring the remote node.
|
||||
4. Connect to the remote node via USB.
|
||||
5. Set the Admin Key on the remote node by running:
|
||||
```bash
|
||||
meshtastic --set security.admin_key "PASTEPUBLICKEYHERE"
|
||||
```
|
||||
6. You may add up to 3 Admin Keys, enabling control from up to 3 different nodes.
|
||||
|
||||
#### Setting up Remote Admin Using the Legacy Method
|
||||
|
||||
To use the legacy method, set up an Admin channel as a secondary channel with the name `admin` by following the instructions in the [Channels](/docs/configuration/radio/channels/) section.
|
||||
|
||||
Enable Legacy Admin in the [Security Config](/docs/configuration/radio/security/#admin-channel-enabled) by running the following CLI command:
|
||||
|
||||
```bash
|
||||
meshtastic --set security.admin_channel_enabled
|
||||
```
|
||||
|
||||
And you can now confirm via the local node that the remote node has changed:
|
||||
#### Carrying Out Remote Admin Tasks
|
||||
|
||||
```shell title="Command"
|
||||
meshtastic --nodes
|
||||
```
|
||||
```markdown title="Expected output"
|
||||
Connected to radio
|
||||
/----------------------------------------------------------------------------------------------------\
|
||||
|N| User |AKA| ID | Position |Battery| SNR | LastHeard | Since |
|
||||
|-+---------+---+---------+------------------------+-------+-------+-------------------+-------------|
|
||||
|1|Im Remote|IR |!28979058|25.0382°, 121.5731°, N/A| N/A |8.75 dB|2021-03-22 09:35:42|3 minutes ago|
|
||||
\----------------------------------------------------------------------------------------------------/
|
||||
Remote admin commands are issued using the `--dest` argument with the `!nodeid` of the target node. Only the `--set` and `--get` commands are supported for remote administration. You can use these commands to modify parameters, add channels, or retrieve settings from the remote node. For example:
|
||||
|
||||
```bash
|
||||
meshtastic --set security.admin_key "PASTEPUBLICKEYHERE" --dest '!28979058'
|
||||
```
|
||||
|
||||
Note: you can change **any** parameter, add channels or get settings from the remote node. Here's an example of setting ls_secs using the `--set` command and printing the position settings from the remote node using the `--get` command:
|
||||
:::info
|
||||
For Linux/Mac, enclose the `nodeid` value in single quotes: `--dest '!28979058'`. For Windows, quotes are not required: `--dest !28979058`.
|
||||
:::
|
||||
|
||||
```shell title="Command"
|
||||
meshtastic --dest '!28979058' --set power.ls_secs 301 --get position
|
||||
```
|
||||
</TabItem>
|
||||
<TabItem value="web">
|
||||
|
||||
```markdown title="Expected output"
|
||||
Connected to radio
|
||||
Requesting current config from remote node (this can take a while).
|
||||
#### Web
|
||||
|
||||
power:
|
||||
wait_bluetooth_secs: 60
|
||||
mesh_sds_timeout_secs: 7200
|
||||
sds_secs: 4294967295
|
||||
ls_secs: 300
|
||||
min_wake_secs: 10
|
||||
1. Connect to the node that will be used to administer the remote node.
|
||||
2. Navigate to **⚙ Config > ⚙ Radio Config > [Security](/docs/configuration/radio/security/#public-key)** to find its public key.
|
||||
4. Copy the public key to use for configuring the remote node.
|
||||
5. Connect to the remote node.
|
||||
6. In **⚙ Config > ⚙ Radio Config > Security**, add the public key of the local node as an Admin Key.
|
||||
7. Only one Admin Keys may be supplied through the Web interface at present.
|
||||
8. Save the configuration.
|
||||
|
||||
Set power.ls_secs to 301
|
||||
Writing modified preferences to device
|
||||
Requesting current config from remote node (this can take a while).
|
||||
Received an ACK.
|
||||
Completed getting preferences
|
||||
Waiting for an acknowledgment from remote node (this could take a while)
|
||||
#### Carrying out Remote Admin tasks
|
||||
|
||||
position:
|
||||
position_broadcast_secs: 900
|
||||
position_broadcast_smart_enabled: true
|
||||
gps_enabled: true
|
||||
gps_update_interval: 120
|
||||
gps_attempt_time: 900
|
||||
position_flags: 3
|
||||
rx_gpio: 15
|
||||
tx_gpio: 13
|
||||
broadcast_smart_minimum_distance: 100
|
||||
broadcast_smart_minimum_interval_secs: 30
|
||||
The Meshtastic Web Client does not support sending remote administration commands at this time.
|
||||
|
||||
Completed getting preferences
|
||||
```
|
||||
|
||||
To set the `hop_limit` to 4 and then get the lora settings to confirm your new settings:
|
||||
|
||||
```shell title="Command"
|
||||
meshtastic --dest '!28979058' --set lora.hop_limit 4 --get lora
|
||||
```
|
||||
```markdown title="Expected output"
|
||||
lora:
|
||||
use_preset: true
|
||||
region: US
|
||||
hop_limit: 3
|
||||
tx_enabled: true
|
||||
tx_power: 30
|
||||
|
||||
Set lora.hop_limit to 4
|
||||
Writing modified preferences to device
|
||||
Requesting current config from remote node (this can take a while).
|
||||
Received an ACK.
|
||||
Completed getting preferences
|
||||
Waiting for an acknowledgment from remote node (this could take a while)
|
||||
|
||||
lora:
|
||||
use_preset: true
|
||||
region: US
|
||||
hop_limit: 4
|
||||
tx_enabled: true
|
||||
tx_power: 30
|
||||
```
|
||||
## Admin Channel Setup is Complete
|
||||
|
||||
You've finished setting up and adding two devices to the admin channel. Remember, because this is a mesh network, it doesn't matter which node you are at; you could administer your first device we set up from the second one we added to the channel. And the settings and examples on this page are just a taste of the other settings you can set.
|
||||
|
||||
For further reading, I recommend starting out with the [Meshtastic Python CLI Guide](/docs/software/python/cli/) if you haven't already gone through this (hopefully you have since you are reading this). But for a full reference to the settings you can change, please see:
|
||||
|
||||
[Settings Overview](/docs/configuration) and
|
||||
[Complete list of user settings in Protobufs](https://buf.build/meshtastic/protobufs/docs/main:meshtastic#meshtastic.User)
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
|
|
|||
|
|
@ -10,15 +10,11 @@ sidebar_position: 1
|
|||
If you would like to develop this application we'd love your help! These build instructions are brief and should be improved, please send a PR if you can.
|
||||
|
||||
1. Use Android Studio to build/debug
|
||||
2. Use `git submodule update --init --recursive` to pull in the various sub-modules we depend on.
|
||||
3. There are a few config files which you'll need to copy from templates included in the project. Run the following commands to do so:
|
||||
2. Clone the repository and after successful cloning, change the working directory to Meshtastic-Android/
|
||||
```shell
|
||||
rm ./app/google-services.json
|
||||
cp ./app/google-services-example.json ./app/google-services.json
|
||||
rm ./app/src/main/res/values/curfirmwareversion.xml
|
||||
cp ./app/special/curfirmwareversion.xml ./app/src/main/res/values/
|
||||
git clone https://github.com/meshtastic/Meshtastic-Android.git --recursive && cd Meshtastic-Android/
|
||||
```
|
||||
4. Now you should be able to select "Run / Run" in the IDE and it will happily start running on your phone or the emulator.
|
||||
3. Now you should be able to select "Run / Run" in the IDE and it will happily start running on your phone or the emulator.
|
||||
|
||||
:::note
|
||||
The emulators don't support Bluetooth, so some features can not be used in that environment.
|
||||
|
|
|
|||
|
|
@ -6,31 +6,31 @@ 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
|
||||
## PSK for Channels, PKC for Direct Messages 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.
|
||||
Up to version 2.4.x of the firmware, Meshtastic relied entirely on Pre-Shared Key (PSK) cryptography for all messaging. Starting with firmware version 2.5.0, Meshtastic introduced Public Key Cryptography (PKC) for Direct Messages (DMs) and added Session IDs for Admin Messages. Together, these enhancements bring the security architecture of Meshtastic to 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)
|
||||
### 1. Chat Channels Using PSK
|
||||
|
||||
- **PSK Overview:**
|
||||
|
||||
- Chat Channels continue to utilize a Pre-Shared Key (PSK) for encrypting communications.
|
||||
- Chat Channels continue to utilize a 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
|
||||
### 2. 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.
|
||||
- **Digital Signatures:** DMs 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.
|
||||
|
|
|
|||
|
|
@ -189,20 +189,33 @@ MAC: 24:6f:28:b5:36:71
|
|||
Hard resetting via RTS pin...
|
||||
```
|
||||
|
||||
### Navigate to Firmware
|
||||
### Download Firmware
|
||||
|
||||
`cd` into the directory where you unzipped the latest release. For example:
|
||||
1. Head to the [Meshtastic Downloads Page](/downloads) to download the latest firmware.
|
||||
2. Scroll down to the **Firmware** section and select one of the following, depending on your preferences:
|
||||
- **Download Stable**: For stable, well-tested releases.
|
||||
- **Download Alpha**: For newer, experimental releases with the latest features.
|
||||
3. Once redirected to the GitHub release page, scroll down to the "Assets" section and expand it. Identify the correct firmware for your device by its architecture (e.g., `firmware-esp32s3` for ESP32-S3-based devices like the Heltec V3).
|
||||
4. Download the file and take note of the download location on your system (usually in your `~/Downloads` folder).
|
||||
|
||||
### Navigate to Firmware Directory
|
||||
|
||||
1. Open a terminal and navigate (`cd`) to the directory where your firmware was downloaded. The folder name typically matches the architecture and firmware version from the zip file. For example:
|
||||
|
||||
```shell title="Example"
|
||||
cd ~/Downloads/firmware/
|
||||
cd ~/Downloads/firmware-esp32s3-X.X.X.xxxxxxx/
|
||||
```
|
||||
|
||||
:::note
|
||||
Make sure to replace `esp32s3` and the version number with those corresponding to the file you downloaded.
|
||||
:::
|
||||
|
||||
### Install/Update Firmware
|
||||
|
||||
Install or Update the device that you have by using the following commands according to your operating system:
|
||||
Now, proceed with the instructions below for your operating system to install or update the firmware for your specific board:
|
||||
|
||||
:::caution
|
||||
Be very careful to install the correct firmware file for your board. In particular, the popular 'T-BEAM' radio from TTGO is not called 'TTGO-Lora' (that is a different board). So don't install the 'TTGO-Lora' build on a TBEAM, it won't work correctly. If you flash the incorrect device firmware, it may appear to successfully complete, yet the device will usually become unresponsive, displaying a blank screen (if equipped). Attempt to flash the correct version. Please note, while these devices are quite resilient and damage is not always likely, there is a possibility of onboard radio and peripheral damage due to incorrect GPIO pin direction.
|
||||
Be very careful to install the correct firmware file for your board. In particular, the popular 'T-BEAM' radio from TTGO is not called 'TTGO-Lora' (that is a different board). So don't install the 'TTGO-Lora' build on a TBEAM, it won't work correctly. If you flash the incorrect device firmware, it may appear to successfully complete, yet the device will usually become unresponsive, displaying a blank screen (if equipped). Attempt to flash the correct version. Please note, while these devices are quite resilient and damage is not always likely, there is a possibility of onboard radio and peripheral damage due to incorrect GPIO pin direction
|
||||
:::
|
||||
|
||||
<Tabs
|
||||
|
|
|
|||
|
|
@ -7,12 +7,12 @@ description: Instructions to flash Meshtastic firmware to an ESP32 chipset devic
|
|||
---
|
||||
|
||||
:::info
|
||||
The recommended method for firmware flashing is the [Web-Based Installer.](https://flasher.meshtastic.org)
|
||||
The recommended method for firmware flashing is the [Web Flasher.](https://flasher.meshtastic.org)
|
||||
:::
|
||||
|
||||
## Flashing Method for ESP32 Devices
|
||||
|
||||
1. The [Web-Based Installer](/docs/getting-started/flashing-firmware/esp32/web-flasher.mdx) requires either Chrome or Edge browsers but is an excellent choice for quickly flashing devices. **This method is highly recommended for firmware flashing, especially for new users of the project, as it is easy to use.**
|
||||
1. The [Web Flasher](/docs/getting-started/flashing-firmware/esp32/web-flasher.mdx) requires either Chrome or Edge browsers but is an excellent choice for quickly flashing devices. **This method is highly recommended for firmware flashing, especially for new users of the project, as it is easy to use.**
|
||||
2. The [CLI Script](/docs/getting-started/flashing-firmware/esp32/cli-script) is considered the "manual process" for flashing firmware.
|
||||
3. Flashing your device using an [external serial adapter](/docs/getting-started/flashing-firmware/esp32/external-serial-adapter) should only be attempted as a last resort if no other method has been successful.
|
||||
|
||||
|
|
|
|||
|
|
@ -63,7 +63,11 @@ pip install adafruit-nrfutil
|
|||
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
|
||||
adafruit-nrfutil --singlebank --touch 1200 --verbose dfu serial --package <downloaded file>.zip -p /dev/ttyACM0 -b 115200
|
||||
```
|
||||
|
||||
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/).
|
||||
|
||||
### Method 3: Using a Debugger
|
||||
|
||||
If the above methods do not work and if the hardware supports it (i.e., has the required SWD pins), a debugger like a DAPLink or J-Link can be used to flash the bootloader directly. Refer to the [Debugger Instructions](https://meshtastic.org/docs/getting-started/flashing-firmware/nrf52/convert-rak4631r/#debugger) for an example with the RAK4631.
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ If your device is not listed above, please review our [supported devices](/docs/
|
|||
|
||||
:::danger STOP! Put The Power Cable Down!
|
||||
|
||||
Never power on the radio without attaching an antenna! _It_ could damage the radio chip.
|
||||
Never power on the radio without attaching an antenna as doing so could damage the radio chip!
|
||||
|
||||
:::
|
||||
|
||||
|
|
|
|||
|
|
@ -88,6 +88,4 @@ In summary - wavelengths in Europe fair well in plain sight, curve over not-so-t
|
|||
|
||||
## Discussion
|
||||
|
||||
To comment on / join in antenna range [Meshtastic discourse](https://meshtastic.discourse.group/t/antenna-improved-range/227/35?u=sens8tion)
|
||||
|
||||
There, you will also find reference to Meshtastic range achievements and aerial recommendations. (Note we've stopped short of making specific supplier aerial recommendations in this wiki.)
|
||||
For further insights, join the conversation on antenna range and performance at [Meshtastic Discussions on GitHub.](https://github.com/orgs/meshtastic/discussions)
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Inexpensive basic ESP32-based boards.
|
|||
| ----------------------- | ----------- | ------ | ------------ | --- | --- |
|
||||
| [Capsule V3](./sensor/) | ESP32-S3FN8 | SX1262 | 2.4GHz b/g/n | 5.0 | YES |
|
||||
|
||||
### [Vision Master](./vision-master/)
|
||||
## [Vision Master](./vision-master/)
|
||||
|
||||
Versatile ESP32-S3-based boards E-Ink development boards.
|
||||
|
||||
|
|
@ -33,3 +33,9 @@ Versatile ESP32-S3-based boards E-Ink development boards.
|
|||
| [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 |
|
||||
|
||||
## [Mesh Node](./mesh-node)
|
||||
|
||||
| Name | MCU | Radio | WiFi | BT | GPS |
|
||||
| --------------------------------------------- | :------- | :----- | :--- | :-: | :------: |
|
||||
| [Mesh Node T114](./mesh-node/?mesh_node_t114) | nRF52840 | SX1262 | NO | 5.0 | OPTIONAL |
|
||||
|
|
|
|||
|
|
@ -58,10 +58,15 @@ Not recommended because of design issues! Support is being phased out. Use V3 in
|
|||
|
||||
## V3/V3.1
|
||||
|
||||
:::info
|
||||
::::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.
|
||||
|
||||
:::caution
|
||||
Be careful when interacting with the USB-C port. This device does not have ESD protection for the CP2102 USB to UART bridge chip.
|
||||
:::
|
||||
|
||||
::::
|
||||
|
||||
- **MCU:**
|
||||
- ESP32-S3FN8 (WiFi & Bluetooth)
|
||||
- **LoRa Transceiver:**
|
||||
|
|
@ -109,7 +114,7 @@ Image Source: [Heltec](<https://resource.heltec.cn/download/WiFi_LoRa32_V3/HTIT-
|
|||
- [Rokland](https://store.rokland.com/collections/heltec-products/products/heltec-wifi-lora-32v3)
|
||||
- International
|
||||
- [Heltec](https://heltec.org/project/wifi-lora-32-v3/)
|
||||
- [AliExpress](https://www.aliexpress.us/item/3256805256690400.html)
|
||||
- [AliExpress](https://www.aliexpress.us/item/3256807466584635.html)
|
||||
|
||||
</TabItem>
|
||||
|
||||
|
|
@ -162,7 +167,7 @@ Image Source: [Heltec](https://resource.heltec.cn/download/Wireless_Stick_Lite_V
|
|||
- [Rokland](https://store.rokland.com/collections/heltec-products/products/heltec-wireless-stick-litev3-902-928-mhz)
|
||||
- International
|
||||
- [Heltec](https://heltec.org/project/wireless-stick-lite-v2/)
|
||||
- [AliExpress](https://www.aliexpress.us/item/3256805256996507.html)
|
||||
- [AliExpress](https://www.aliexpress.us/item/3256807466584635.html)
|
||||
|
||||
</TabItem>
|
||||
|
||||
|
|
|
|||
|
|
@ -43,6 +43,10 @@ Previous versions of these instructions specified using a 2N2222a power transist
|
|||
|
||||
The current version of the guide now instructs using either a surface mount or through-hole MOSFET to switch the ground ("low side") of the GPS module. This allows the MOSFET to operate in the fully saturated condition, and MOSFETs will have a lower power consumption themselves than a power transistor. As the ground for the two parts will now be isolated, it is important that no parts of the GPS module, the antenna or any shielding shell are able to contact the ground for the Heltec board.
|
||||
|
||||
The essential connections for the NPN MOSFET are shown in the schematic below.
|
||||
|
||||
|
||||
|
||||
### Materials Needed
|
||||
|
||||
- Heltec ESP32 V3 board
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
id: buttons
|
||||
title: Mesh Node Hardware Buttons
|
||||
sidebar_label: Buttons
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
## Mesh Node T114
|
||||
|
||||
- **RST Button:**
|
||||
- **Single press:** Resets the device.
|
||||
- **Double press:** The device enters download mode.
|
||||
- **User Button:**
|
||||
- **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.
|
||||
65
docs/hardware/devices/heltec-automation/mesh-node/index.mdx
Normal file
65
docs/hardware/devices/heltec-automation/mesh-node/index.mdx
Normal file
|
|
@ -0,0 +1,65 @@
|
|||
---
|
||||
id: mesh-node
|
||||
title: HELTEC® Mesh Node
|
||||
sidebar_label: Mesh Node
|
||||
sidebar_position: 4
|
||||
---
|
||||
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
<Tabs
|
||||
groupId="heltec"
|
||||
queryString="heltec"
|
||||
defaultValue="mesh_node_t114"
|
||||
values={[
|
||||
{label: 'Mesh Node T114', value: 'mesh_node_t114'}
|
||||
]}>
|
||||
<TabItem value="mesh_node_t114">
|
||||
|
||||
## Mesh Node T114
|
||||
|
||||
- **MCU:**
|
||||
- nRF52840 (Bluetooth)
|
||||
- **LoRa Transceiver:**
|
||||
- Semtech SX1262
|
||||
- **Frequency Options:**
|
||||
- 433 MHz
|
||||
- 470 - 510 MHz
|
||||
- 863 - 870 MHz
|
||||
- 902 - 928 MHz
|
||||
- **Connectors:**
|
||||
- USB-C
|
||||
- 2x1.25 lithium battery interface
|
||||
- 2x1.25 solar panel interface
|
||||
- 8x1.25 GNSS interface
|
||||
- Antenna:
|
||||
- U.FL/IPEX antenna connector for LoRa.
|
||||
- Integrated 2.4 GHz patch antenna.
|
||||
|
||||
### Features
|
||||
|
||||
- Onboard 1.14 inch TFT-LCD display is optional.
|
||||
- GPS module is optional.
|
||||
- Excellent low power characteristics.
|
||||
|
||||
### Flashing
|
||||
|
||||
1. Trigger DFU mode manually by double-clicking RST button.
|
||||
|
||||
2. Send or paste the prepared firmware UF2 file into the device.
|
||||
|
||||
### Pin Map
|
||||
|
||||
|
||||
|
||||
### Resources
|
||||
|
||||
- Firmware file: `firmware-heltec-mesh-node-t114-X.X.X.xxxx.uf2`
|
||||
- Purchase links
|
||||
- International
|
||||
- [Heltec](https://heltec.org/project/mesh-node-t114/)
|
||||
- [AliExpress](https://www.aliexpress.com/item/1005007460963705.html)
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
|
@ -146,6 +146,12 @@ Versatile ESP32-S3-based boards E-Ink development boards.
|
|||
| [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 |
|
||||
|
||||
### [Mesh Node](./heltec-automation/mesh-node)
|
||||
|
||||
| Name | MCU | Radio | WiFi | BT | GPS |
|
||||
| --------------------------------------------------------------- | :------- | :----- | :--- | :-: | :------: |
|
||||
| [Mesh Node T114](./heltec-automation/mesh-node/?mesh_node_t114) | nRF52840 | SX1262 | NO | 5.0 | OPTIONAL |
|
||||
|
||||
## [B&Q Consulting](./b-and-q-consulting/)
|
||||
|
||||
### [Nano Series](./b-and-q-consulting/nano/)
|
||||
|
|
@ -241,6 +247,6 @@ DIY kit with ESP32, LoRa chip, and optional GPS. Designed for STEM education.
|
|||
|
||||
### Radio Master
|
||||
|
||||
| Name | MCU | Radio | WiFi | BT | GPS |
|
||||
| :-------------------- | :--------------- | :----- | :--: | :-: | :-: |
|
||||
| Bandit Nano ExpressLRS 900 | ESP32 | SX1276 + SKY66122 PA/LNA +30db TX, +16db RX ) | ? | YES | NO |
|
||||
| Name | MCU | Radio | WiFi | BT | GPS |
|
||||
| :------------------------- | :---- | :-------------------------------------------- | :--: | :-: | :-: |
|
||||
| Bandit Nano ExpressLRS 900 | ESP32 | SX1276 + SKY66122 PA/LNA +30db TX, +16db RX ) | ? | YES | NO |
|
||||
|
|
|
|||
|
|
@ -226,7 +226,7 @@ Early versions of these boards contained the wrong component in the LiPo battery
|
|||
- ESP32-S3 (WiFi & Bluetooth)
|
||||
- **LoRa Transceiver**
|
||||
- Semtech SX1262
|
||||
- Semtech 1276
|
||||
- Semtech SX1276
|
||||
- Semtech SX1280 with PA (Region LORA_24 worldwide use)
|
||||
- **Frequency options**
|
||||
- 868 MHz
|
||||
|
|
|
|||
|
|
@ -5,6 +5,19 @@ sidebar_label: Buttons
|
|||
sidebar_position: 1
|
||||
---
|
||||
|
||||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
<Tabs
|
||||
groupId="t-beam buttons"
|
||||
queryString="t-beam"
|
||||
defaultValue="t-beam"
|
||||
values={[
|
||||
{label: 'T-Beam', value: 't-beam'},
|
||||
{label: 'T-Beam Supreme', value:'t-beam-supreme'},
|
||||
]}>
|
||||
<TabItem value="t-beam">
|
||||
|
||||
## Functionality
|
||||
|
||||
- **Power Button (left):**
|
||||
|
|
@ -23,3 +36,28 @@ sidebar_position: 1
|
|||
width="200"
|
||||
align="center-right"
|
||||
/>
|
||||
|
||||
</TabItem>
|
||||
<TabItem value = "t-beam-supreme">
|
||||
|
||||
## Functionality
|
||||
|
||||
- **Power Button (middle):**
|
||||
- **Long press:** Powers the device on or off.
|
||||
- **Reset Button (right):**
|
||||
- **Single press:** Resets the device.
|
||||
- **User/Program Button (left):**
|
||||
- **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:** Disables the device's GPS. Repeat to re-enable. (_This will be indicated on both information screen pages on the device's display as shown below_)
|
||||
|
||||
<img src="/img/hardware/GPS-disabled.webp" width="200" align="center-left" />
|
||||
<img
|
||||
src="/img/hardware/GPS-disabled-by-button.webp"
|
||||
width="200"
|
||||
align="center-right"
|
||||
/>
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
|
|
|||
|
|
@ -37,17 +37,33 @@ The RAK5005-O is no longer in production. It is recommended to use the RAK19007
|
|||
- (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
|
||||
- JST PHR-2 connector for 3.7v LiPo battery (with charge controller)
|
||||
- JST-ZHR-2 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)
|
||||
- OLED screen support (OLED screen sold separately)
|
||||
|
||||
:::note
|
||||
The RAK5005 (without the -O) is not compatible.
|
||||
:::
|
||||
|
||||
### Connectors Diagram
|
||||
|
||||
<img
|
||||
alt="RAK19001-O Connectors"
|
||||
src="/img/hardware/rak5005-0_connectors.web"
|
||||
style={{ zoom: "50%" }}
|
||||
/>
|
||||
|
||||
### Voltages
|
||||
|
||||
- JST PHR-2 connector for 3.7v LiPo battery.
|
||||
- Charge controller max charge rate is 500mAh.
|
||||
- Minimum input voltage for charging is 3.3v, maximum 4.3v.
|
||||
- JST ZHR-2 connector for 5v solar panel.
|
||||
- Minimum input voltage to charge is 4.4v, maximum 5.5v.
|
||||
|
||||
Further information on the RAK5005-O can be found on the [RAK Documentation Center](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK5005-O/Overview/#product-description).
|
||||
|
||||
<img
|
||||
|
|
@ -63,23 +79,39 @@ Further information on the RAK5005-O can be found on the [RAK Documentation Cent
|
|||
## RAK19007
|
||||
|
||||
- [RAK19007](https://store.rakwireless.com/products/rak19007-wisblock-base-board-2nd-gen) - WisBlock Base Board (2nd Generation, an upgrade to the RAK5005-O)
|
||||
- **Slots**
|
||||
- (x1) Core Module slot
|
||||
- (x1) WisBlock IO Module slot
|
||||
- (x4) WisBlock Sensor Module slots
|
||||
- **Buttons**
|
||||
- (x1) Reset Button
|
||||
- To add a user button, you can utilize the AIN1 pin, which is exposed as pin 31 in the firmware.
|
||||
- **Connectors**
|
||||
- Connector for 3.7v LiPo battery (with charge controller)
|
||||
- Connector for 5v solar panel (max 5.5v)
|
||||
- I<sup>2</sup>C, UART, BOOT and GPIOs accessible with solder contacts
|
||||
- USB-C 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
|
||||
- To add a user button, you can utilize the AIN1 pin, which is exposed as pin 31 in the firmware.
|
||||
- **Connectors**
|
||||
- JST PHR-2 connector for 3.7v LiPo battery.
|
||||
- JST ZHR-2 connector for 5v solar panel.
|
||||
- I<sup>2</sup>C, UART, BOOT and GPIOs accessible with solder contacts
|
||||
- USB-C port for debugging and power
|
||||
- **Screen Support**
|
||||
- OLED screen support (OLED screen sold separately)
|
||||
|
||||
Further information on the RAK19007 can be found on the [RAK Documentation Center](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK19007/Overview/#product-description).
|
||||
|
||||
### Connectors Diagram
|
||||
|
||||
<img
|
||||
alt="RAK19007 Connectors"
|
||||
src="/img/hardware/rak19007_connectors.webp"
|
||||
style={{ zoom: "50%" }}
|
||||
/>
|
||||
|
||||
### Voltages
|
||||
|
||||
- JST PHR-2 connector for 3.7v LiPo battery.
|
||||
- Charge controller max charge rate is 350mAh.
|
||||
- Minimum input voltage for charging is 3.3v, maximum 4.3v.
|
||||
- JST ZHR-2 connector for 5v solar panel.
|
||||
- Minimum input voltage to charge is 4.4v, maximum 5.5v.
|
||||
|
||||
### Resources
|
||||
|
||||
- Purchase Links:
|
||||
|
|
@ -96,22 +128,38 @@ Further information on the RAK19007 can be found on the [RAK Documentation Cente
|
|||
## RAK19003
|
||||
|
||||
- [RAK19003](https://store.rakwireless.com/products/wisblock-base-board-rak19003) - WisBlock's Mini Base Board.
|
||||
- **Slots**
|
||||
- (x1) Core Module slot
|
||||
- (x2) WisBlock Sensor Module slots
|
||||
- **Buttons**
|
||||
- (x1) Reset Button
|
||||
- There is a 3rd party sensor module that breaks out the user button, available [here](https://www.etsy.com/de/listing/1254963521/mini-io-expansion-board-for-rak-wireless).
|
||||
- **Connectors**
|
||||
- Connector for 3.7v LiPo battery (with charge controller)
|
||||
- Connector for 5v solar panel (max 5.5v)
|
||||
- I<sup>2</sup>C, UART and BOOT headers accessible with solder contacts
|
||||
- USB-C port for debugging and power
|
||||
- **Screen Support**
|
||||
- OLED screen support (OLED screen sold separately)
|
||||
- **Slots**
|
||||
- (x1) Core Module slot
|
||||
- (x2) WisBlock Sensor Module slots
|
||||
- **Buttons**
|
||||
- (x1) Reset Button
|
||||
- There is a 3rd party sensor module that breaks out the user button, available [here](https://www.etsy.com/de/listing/1254963521/mini-io-expansion-board-for-rak-wireless).
|
||||
- **Connectors**
|
||||
- JST PHR-2 connector for 3.7v LiPo battery.
|
||||
- JST ZHR-2 connector for 5v solar panel.
|
||||
- I<sup>2</sup>C, UART and BOOT headers accessible with solder contacts
|
||||
- USB-C port for debugging and power
|
||||
- **Screen Support**
|
||||
- OLED screen support (OLED screen sold separately)
|
||||
|
||||
Further information on the RAK19003 can be found on the [RAK Documentation Center](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK19003/Overview/#product-description)
|
||||
|
||||
### Connectors Diagram
|
||||
|
||||
<img
|
||||
alt="RAK19003 Connectors"
|
||||
src="/img/hardware/rak19003_connectors.webp"
|
||||
style={{ zoom: "50%" }}
|
||||
/>
|
||||
|
||||
### Voltages
|
||||
|
||||
- JST PHR-2 connector for 3.7v LiPo battery.
|
||||
- Charge controller max charge rate is 350mAh.
|
||||
- Minimum input voltage for charging is 3.3v, maximum 4.3v.
|
||||
- JST ZHR-2 connector for 5v solar panel.
|
||||
- Minimum input voltage to charge is 4.4v, maximum 5.5v.
|
||||
|
||||
### Resources
|
||||
|
||||
- Purchase Links:
|
||||
|
|
@ -132,26 +180,45 @@ Further information on the RAK19003 can be found on the [RAK Documentation Cente
|
|||
## RAK19001
|
||||
|
||||
- [RAK19001](https://store.rakwireless.com/products/rak19001-wisblock-dual-io-base-board) - WisBlock's Dual IO Base Board.
|
||||
- **Slots**
|
||||
- (x1) Core Module slot
|
||||
- (x2) WisBlock IO Module slot
|
||||
- (x6) WisBlock Sensor Module slots
|
||||
- **Buttons**
|
||||
- (x1) Reset Button
|
||||
- (x1) User-defined push button switch
|
||||
- (x1) Battery selector switch
|
||||
- On this board the PIN for user button (IO5) is available as a solder contact on the upper header row.
|
||||
- **Connectors**
|
||||
- Connector for 3.7v LiPo battery (with charge controller)
|
||||
- Connector for 5v solar panel (max 5.5v)
|
||||
- Separate connector for non-rechargeable batteries
|
||||
- I<sup>2</sup>C, SPI, UART, BOOT and GPIOs accessible with solder contacts
|
||||
- USB-C port for debugging and power
|
||||
- **Screen Support**
|
||||
- OLED screen support (OLED screen sold separately)
|
||||
- **Slots**
|
||||
- (x1) Core Module slot
|
||||
- (x2) WisBlock IO Module slot
|
||||
- (x6) WisBlock Sensor Module slots
|
||||
- **Buttons**
|
||||
- (x1) Reset Button
|
||||
- (x1) User-defined push button switch
|
||||
- (x1) Battery selector switch
|
||||
- On this board the PIN for user button (IO5) is available as a solder contact on the upper header row.
|
||||
- **Connectors**
|
||||
- JST PHR-2 connector for 3.7v LiPo battery (with charge controller)
|
||||
- JST ZHR-2 connector for 5v solar panel (max 5.5v)
|
||||
- Separate FGH20005-S02M2W1B connector for non-rechargeable batteries
|
||||
- I<sup>2</sup>C, SPI, UART, BOOT and GPIOs accessible with solder contacts
|
||||
- USB-C port for debugging and power
|
||||
- **Screen Support**
|
||||
- OLED screen support (OLED screen sold separately)
|
||||
|
||||
Further information on the RAK19001 can be found on the [RAK Documentation Center](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK19001/Overview/#product-description).
|
||||
|
||||
### Connectors Diagram
|
||||
|
||||
<img
|
||||
alt="RAK19001 Connectors"
|
||||
src="/img/hardware/rak19001_connectors.webp"
|
||||
style={{ zoom: "50%" }}
|
||||
/>
|
||||
|
||||
### Voltages
|
||||
|
||||
- JST PHR-2 connector for 3.7v LiPo battery.
|
||||
- Charge controller max charge rate is 500mAh.
|
||||
- Minimum input voltage for charging is 3.3v, maximum 4.3v.
|
||||
- JST ZHR-2 connector for 5v solar panel.
|
||||
- Minimum input voltage to charge is 4.4v, maximum 5.5v.
|
||||
- FGH20005-S02M2W1B connector for non-rechargable battery.
|
||||
- Minimum required is 3.3v, typical 3.7v, maximum 5.5v.
|
||||
- Active battery is selected with the battery selector switch.
|
||||
|
||||
### Resources
|
||||
|
||||
- Purchase Links:
|
||||
|
|
|
|||
|
|
@ -16,6 +16,7 @@ values={[
|
|||
{label: 'User Button', value: 'User Button'},
|
||||
{label: 'GPS Module', value: 'GPS'},
|
||||
{label: 'Buzzer', value: 'Buzzer'},
|
||||
{label: 'Vibration', value: 'Vibration'},
|
||||
{label: 'I/O Module', value: 'IO'},
|
||||
{label: 'Environmental Sensors', value:'Sensors'},
|
||||
{label: 'RTC Module', value:'RTC'}
|
||||
|
|
@ -37,8 +38,7 @@ One side of the switch should be on GND and the other on the recommended Pin per
|
|||
|
||||
### 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>
|
||||
|
|
@ -92,16 +92,43 @@ The RAK1910 is supported on the following base boards & slots:
|
|||
|
||||
## Buzzer
|
||||
|
||||
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.
|
||||
### RAK Buzzer
|
||||
|
||||
### Resources
|
||||
The [RAK18001 Buzzer Module](https://store.rakwireless.com/products/wisblock-buzzer-module-rak18001) may be used with the External Notifications plugin. There is currently a known conflict with the buzzer if the module is placed in Slot D, although other slots should work. NOTE: Many users have complained of the RAK buzzer being very quiet as currently implemented. As of yet, there is no fix for this issue.
|
||||
|
||||
#### 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>
|
||||
### Third Party Buzzer
|
||||
|
||||
Another option is to use a standard "passive buzzer" and a transistor (such as a 2N2222 transistor). This can be done by wiring the VCC pin to leg 1 of the transistor and the positive terminal of the buzzer to leg 3. To the central pin (2) of the transistor, connect pin RX1 on the Wisblock board. Connect the negative terminal of the buzzer to the GND pin on the Wisblock board. In settings, go to Device and set Redefine PIN_BUZZER (Buzzer GPIO) to 15. Then go to External Notification and set the module to Enabled, PWM buzzer to enabled, Alert Message Buzzer to enabled and Output Buzzer GPIO to 15. Save your settings and your buzzer should activate whenever you get an incoming message.
|
||||
|
||||
#### Resources
|
||||
|
||||
- Purchase Links:
|
||||
- International
|
||||
- Amazon: [Buzzer](https://www.amazon.com/dp/B018I1WBNQ)
|
||||
- Amazon: [Transistor](https://www.amazon.com/dp/B07YN7KQQB)
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Vibration">
|
||||
|
||||
## Vibration
|
||||
|
||||
To add vibration to your Wisblock device you'll need a standard 3V DC vibramotor and a transistor (such as a 2N2222 transistor). This can be done by wiring the VCC pin to leg 1 of the transistor and the positive (red) wire of the vibramotor to leg 3. To the central pin (2) of the transistor, connect pin AIN1 on the Wisblock board. Connect the negative wire (black) of the vibramotor to the GND pin on the Wisblock board. In settings, go to External Notification and set the module to Enabled, Alert Message Vibra to enabled and Output Vibra GPIO to 31. Save your settings and vibration should activate whenever you get an incoming message.
|
||||
|
||||
### Resources
|
||||
|
||||
- Purchase Links:
|
||||
- International
|
||||
- Amazon: [Vibrator](https://www.amazon.com/dp/B07Q1ZV4MJ)
|
||||
- Amazon: [Transistor](https://www.amazon.com/dp/B07YN7KQQB)
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="IO">
|
||||
|
||||
## IO Module
|
||||
|
|
@ -126,7 +153,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
|
||||
|
|
@ -172,7 +199,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
|
||||
|
|
@ -188,5 +215,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>
|
||||
</Tabs>
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
|
@ -7,6 +7,10 @@ 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.
|
||||
|
||||
:::warning[Note]
|
||||
Currently, LR1110 radios are unable to receive Meshtastic packets from the older SX127x radios. Semtech is aware of this issue, and we're hopeful they'll provide a solution soon.
|
||||
:::
|
||||
|
||||
### Specifications
|
||||
|
||||
- **MCU**
|
||||
|
|
|
|||
|
|
@ -8,6 +8,10 @@ sidebar_position: 1
|
|||
import Tabs from "@theme/Tabs";
|
||||
import TabItem from "@theme/TabItem";
|
||||
|
||||
:::warning[Note]
|
||||
Currently, LR1110 radios are unable to receive Meshtastic packets from the older SX127x radios. Semtech is aware of this issue, and we're hopeful they'll provide a solution soon.
|
||||
:::
|
||||
|
||||
<Tabs
|
||||
groupId="wm1110"
|
||||
queryString="wm1110"
|
||||
|
|
|
|||
|
|
@ -154,6 +154,8 @@ The following uses of the Meshtastic Trademarks are not approved under any fores
|
|||
|
||||
These guidelines (except for trademark licenses executed for non software goods) may be amended from time to time at the discretion of Meshtastic and such changes will be effective ten (10) days after the changes are posted. Meshtastic may provide you with notice of such changes, but need not do so. You are responsible for checking this site for any changes.
|
||||
|
||||
In the past, community members have inquired whether it is permissible to use the Meshtastic Trademarks, including the term "Meshtastic" in software product names. You **may not** use any of Meshtastic Trademarks in either the primary or secondary branding of any third party product or service names. For example, you may not name a product either "BigCo Project Thing", "BigCo distribution of Project", or any similar kind of name where Project is any Meshtastic mark or project name.
|
||||
|
||||
## Proper Trademark Use
|
||||
|
||||
One of the purposes of Meshtastic is to encourage the use of Meshtastic software to enable the public to come to trust the use of Meshtastic Trademarks. To achieve this purpose it is important that Meshtastic can quickly be identified. Meshtastic has chosen the Meshtastic Logo to identify such software and is granting usage rights in the Meshtastic Logo (and the other Meshtastic Trademarks) as previously described in this document in order to assure widespread availability.
|
||||
|
|
|
|||
|
|
@ -14,6 +14,6 @@ If you opt-in to analytics on the Android app (thank you - that helps us know wh
|
|||
|
||||
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](https://meshtastic.discourse.group/), 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 Meshtastic Discussions page](https://github.com/orgs/meshtastic/discussions), and we'll reply/clarify/correct.
|
||||
|
||||
Keep being awesome!
|
||||
|
|
|
|||
|
|
@ -41,8 +41,6 @@ The minimum Android version is 5.0 (Lollipop 2014, first BLE support), however A
|
|||
|
||||
There is a Play Store [testing program](https://play.google.com/apps/testing/com.geeksville.mesh) with the latest cutting edge changes, though this may come with extra bugs.
|
||||
|
||||
It is recommended that you follow the [Meshtastic Discourse Alpha Testers](https://meshtastic.discourse.group/c/development/alpha-testers) channel if you decide to join.
|
||||
|
||||
_Google Play and the Google Play logo are trademarks of Google LLC._
|
||||
|
||||
### Install by Sideloading
|
||||
|
|
@ -73,4 +71,4 @@ If you do sideload, you may have to give your browser permissions to run a packa
|
|||
|
||||
Obtainium allows you to install and update Open-Source Apps directly from their releases pages, and receive notifications when new releases are made available.
|
||||
|
||||
\*Alpha releases include the latest cutting edge changes which may come with extra bugs. It is recommended that you follow the [Meshtastic Discourse Alpha Testers](https://meshtastic.discourse.group/c/development/alpha-testers) channel if you decide to use these versions.
|
||||
\*Alpha releases include the latest cutting edge changes which may come with extra bugs. It is recommended that you follow the Meshtastic Alpha Testers Channel on [Discord](https://discord.com/invite/ktMAKGBnBs) if you decide to use these versions.
|
||||
|
|
|
|||
|
|
@ -5,6 +5,11 @@ sidebar_label: Usage
|
|||
sidebar_position: 2
|
||||
---
|
||||
|
||||
import PositionPrecision from "@site/docs/blocks/_position-precision.mdx";
|
||||
import Link from "@docusaurus/Link";
|
||||
import ThemedImage from "@theme/ThemedImage";
|
||||
import useBaseUrl from "@docusaurus/useBaseUrl";
|
||||
|
||||
## Introduction
|
||||
|
||||
The Meshtastic Android app handles the communication and can show the location of everyone in your private group. Each member of your private mesh can see the location and distance of members and text messages sent to your group chat.
|
||||
|
|
@ -35,22 +40,54 @@ To find devices to connect via Bluetooth click the "+" button on the bottom righ
|
|||
|
||||
The cloud icon at the top right corner indicates if you are connected to a device. This currently has three states:
|
||||
|
||||
 Cloud with a slash through it: No device connected to the application.
|
||||
<center>
|
||||
<ThemedImage
|
||||
alt="Not connected"
|
||||
className="max-h-14"
|
||||
sources={{
|
||||
light: useBaseUrl("/img/android/android-no-ack_lt.webp"),
|
||||
dark: useBaseUrl("/img/android/android-no-ack_dk.webp"),
|
||||
}}
|
||||
/>
|
||||
</center>
|
||||
Cloud with a slash through it: No device connected to the application.
|
||||
|
||||
 Cloud with a tick in it: Device connected to the application.
|
||||
<center>
|
||||
<ThemedImage
|
||||
alt="Connected"
|
||||
className="max-h-14"
|
||||
sources={{
|
||||
light: useBaseUrl("/img/android/android-imp-ack_lt.webp"),
|
||||
dark: useBaseUrl("/img/android/android-imp-ack_dk.webp"),
|
||||
}}
|
||||
/>
|
||||
</center>
|
||||
Cloud with a check in it: Device connected to the application.
|
||||
|
||||
 Cloud with an up arrow in it: Device is connected, but currently sleeping or out of range.
|
||||
<center>
|
||||
<ThemedImage
|
||||
alt="Sleeping"
|
||||
className="max-h-14"
|
||||
sources={{
|
||||
light: useBaseUrl("/img/android/android-waiting_lt.webp"),
|
||||
dark: useBaseUrl("/img/android/android-waiting_dk.webp"),
|
||||
}}
|
||||
/>
|
||||
</center>
|
||||
Cloud with an up arrow in it: Device is connected, but currently sleeping or out
|
||||
of range.
|
||||
|
||||
## Common tasks
|
||||
|
||||
### Set your region
|
||||
|
||||
In order to start communicating with your mesh, you must select a region. This setting controls which frequency range your device uses and should be set according to your location. See [Region Settings](https://meshtastic.org/docs/getting-started/initial-config#set-regional-settings) for a list of region codes and their meanings.
|
||||
|
||||
- Tap on the "Region" dropdown in the top-right corner and make the appropriate selection.
|
||||
|
||||
### Change your name
|
||||
|
||||
Edit the "Your name", e.g. to be "Mike Bird". This is the name that other people will see, so make it unique within your group. The initials e.g. "MB" should also be unique and will be used to identify you in the message history and on the device screens. Initials, or "short name", can be customized in the Radio configuration - User settings. The four characters displayed after your initials cannot be changed. These are the last four hex digits of the device MAC address. Devices with unset names will display these four characters as the device short name.
|
||||
Edit the "Your name", e.g. to be "Mike Bird". This is the name that other people will see, so make it unique within your group. The initials e.g. "MB" should also be unique and will be used to identify you in the message history and on the device screens. Initials, or "short name", can be customized in the Radio configuration - User settings. The four characters displayed after your initials cannot be changed. These are the last four hex digits of the device MAC address. Devices with unset names will display these four characters as the device short name.
|
||||
|
||||
[](/img/android/android-settings-mike.webp)
|
||||
|
||||
|
|
@ -72,7 +109,7 @@ You will see a warning because changing the Channel will break communications wi
|
|||
|
||||
[](/img/android/android-new-channel.webp)
|
||||
|
||||
The app will generate a new QR code on the screen. This encodes the channel details and a random 256-bit key for sharing with the new group. You can share the QR code with other Meshtastic users, or use the Share button and share the link via chat message, SMS, or email. The link is a very long code, for example: https://www.meshtastic.org/d/#CgUYAyIBAQ
|
||||
The app will generate a new QR code on the screen. This encodes the channel details and a random 256-bit key for sharing with the new group. You can share the QR code with other Meshtastic users, or use the Share button and share the link via chat message, SMS, or email. The link is a very long code, for example: https://www.meshtastic.org/d/#CgUYAyIBAQ
|
||||
|
||||
### Join a channel
|
||||
|
||||
|
|
@ -83,10 +120,11 @@ The app will generate a new QR code on the screen. This encodes the channel det
|
|||
2. If the channel is shared from a file or link using the `Share` button, you can click on the file or link and you need to choose "Open with Meshtastic".
|
||||
|
||||
:::info If a QR or URL opens a webpage instead of the APP or "Open with Meshtastic" is not an option:
|
||||
|
||||
1. Go to Android Settings > Apps > Default apps > Meshtastic > Opening links
|
||||
2. Make sure you have in "links/web address": www.meshtastic.org
|
||||
3. If you see the option "Open the supported links", make sure it is enabled.
|
||||
:::
|
||||
:::
|
||||
|
||||
[](/img/android/android-accept-channel.webp)
|
||||
|
||||
|
|
@ -104,16 +142,18 @@ You can test changing channels with the QR code shown below.
|
|||
### Adjust a channel
|
||||
|
||||
You can change the following settings by tapping on the name of an existing channel:
|
||||
|
||||
1. MQTT Uplink
|
||||
2. MQTT Downlink
|
||||
3. Position precision value
|
||||
3. Position enabled
|
||||
4. Precise location (if position is enabled)
|
||||
5. Position precision (if precise location is disabled)
|
||||
|
||||
#### Position Precision
|
||||
The precision levels currently used in the app correspond to the following values:
|
||||
- HIGH_PRECISION (32), full precision
|
||||
- MED_PRECISION (16), around ±350 meters
|
||||
- LOW_PRECISION (11), around ±11 kilometers
|
||||
- DISABLED (0), location data is never sent over the given channel
|
||||
|
||||
The precision levels currently used in the app correspond the values in the table below. These can be thought of as the radius of a circle around a point (not your current location) which you are within.
|
||||
|
||||
<PositionPrecision />
|
||||
|
||||
### Send a message
|
||||
|
||||
|
|
@ -126,17 +166,76 @@ The message window operates like most messaging apps. Note that your primary cha
|
|||
|
||||
With LoRa (or any radio) there is some uncertainty that the message has been received, so there is a confirmation built-in to the protocol. There are small icons shown to the right of the messages you send:
|
||||
|
||||
- Cloud with an up arrow: the message is queued in the app, waiting to be handed to the device.
|
||||
- Cloud only: the device received the message from the app, and it has been sent and transmitted via LoRa.
|
||||
- Cloud with a check mark: received at least one node's acknowledgement response. Confirmations could be from any one device.
|
||||
- Person with a check mark - The intended recipient node of your direct message acknowledged the message.
|
||||
- Cloud crossed out: the initial sender did not receive any confirmation within a certain timeout.
|
||||
<center>
|
||||
<ThemedImage
|
||||
alt="cloud up"
|
||||
className="max-h-18"
|
||||
sources={{
|
||||
light: useBaseUrl("/img/android/android-waiting_lt.webp"),
|
||||
dark: useBaseUrl("/img/android/android-waiting_dk.webp"),
|
||||
}}
|
||||
/>
|
||||
</center>
|
||||
Cloud with an up arrow: the message is queued in the app, waiting to be handed
|
||||
to the device.
|
||||
|
||||
<center>
|
||||
<ThemedImage
|
||||
alt="cloud only"
|
||||
className="max-h-18"
|
||||
sources={{
|
||||
light: useBaseUrl("/img/android/android-sent_lt.webp"),
|
||||
dark: useBaseUrl("/img/android/android-sent_dk.webp"),
|
||||
}}
|
||||
/>
|
||||
</center>
|
||||
- Cloud only: the device received the message from the app, and it has been sent
|
||||
and transmitted via LoRa.
|
||||
|
||||
<center>
|
||||
<ThemedImage
|
||||
alt="Cloud with a check mark"
|
||||
className="max-h-18"
|
||||
sources={{
|
||||
light: useBaseUrl("/img/android/android-imp-ack_lt.webp"),
|
||||
dark: useBaseUrl("/img/android/android-imp-ack_dk.webp"),
|
||||
}}
|
||||
/>
|
||||
</center>
|
||||
- Cloud with a check mark: received at least one node's acknowledgement
|
||||
response. Confirmations could be from any one device.
|
||||
|
||||
<center>
|
||||
<ThemedImage
|
||||
alt="Person with a check mark"
|
||||
className="max-h-18"
|
||||
sources={{
|
||||
light: useBaseUrl("/img/android/android-DM-ack_lt.webp"),
|
||||
dark: useBaseUrl("/img/android/android-DM-ack_dk.webp"),
|
||||
}}
|
||||
/>
|
||||
</center>
|
||||
- Person with a check mark - The intended recipient node of your direct message
|
||||
acknowledged the message.
|
||||
|
||||
<center>
|
||||
<ThemedImage
|
||||
alt="Cloud crossed out"
|
||||
className="max-h-18"
|
||||
sources={{
|
||||
light: useBaseUrl("/img/android/android-no-ack_lt.webp"),
|
||||
dark: useBaseUrl("/img/android/android-no-ack_dk.webp"),
|
||||
}}
|
||||
/>
|
||||
</center>
|
||||
- Cloud crossed out: the initial sender did not receive any confirmation within
|
||||
a certain timeout.
|
||||
|
||||
By default there is no long-term store-and-forward of messages, so messages not received during transmission are lost.
|
||||
|
||||
### View your network
|
||||
|
||||
[](/img/android/android-nodes.webp)
|
||||
](/img/android/android-nodes.webp)
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -151,7 +250,6 @@ The network list shows all the users (devices) that have connected to the same C
|
|||
|
||||
The Map tab will show a local map with an icon for each active mesh node that has a known position. The users names are shown above the icon.
|
||||
|
||||
|
||||
[](/img/android/android-map-layers.webp)
|
||||
|
||||
- Clicking the layers icon in the top-right will allow you to select the map type.
|
||||
|
|
@ -160,7 +258,7 @@ The Map tab will show a local map with an icon for each active mesh node that ha
|
|||
|
||||
[](/img/android/android-map-download.webp)
|
||||
|
||||
- Some map types allow downloading for offline use. If offline maps are available for your selected map type, a download icon will appear in the bottom-right corner of the map. Tap this icon and choose the option to Download Region, then select the area you wish to download.
|
||||
- Some map types allow downloading for offline use. If offline maps are available for your selected map type, a download icon will appear in the bottom-right corner of the map. Tap this icon and choose the option to Download Region, then select the area you wish to download.
|
||||
|
||||
## Configuration options
|
||||
|
||||
|
|
@ -179,6 +277,7 @@ The debug panel allows you to see all packets sent between the application and t
|
|||
[](/img/android/android-radio-configuration.webp)
|
||||
|
||||
Radio Configuration opens a list of all radio and module configuration settings.
|
||||
|
||||
- See [Radio Config](/docs/configuration/radio) for radio settings.
|
||||
- See [Module Config](/docs/configuration/module) for module settings.
|
||||
- At the end of this list are buttons for Reboot, Shutdown, Factory reset, and NodeDB reset.
|
||||
|
|
@ -207,7 +306,7 @@ Opens the introduction slideshow.
|
|||
|
||||
[](/img/android/android-quick-chat.webp)
|
||||
|
||||
Brings up an editor to create and edit quick response messages. These will appear as buttons in the chat window. Messages have the option to send instantly, or be appended to your message and sent manually.
|
||||
Brings up an editor to create and edit quick response messages. These will appear as buttons in the chat window. Messages have the option to send instantly, or be appended to your message and sent manually.
|
||||
|
||||
### About
|
||||
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ sensor:
|
|||
{{ this.state }}
|
||||
{% endif %}
|
||||
device_class: "temperature"
|
||||
unit_of_measurement: "F"
|
||||
unit_of_measurement: "°F"
|
||||
# With device_class: "temperature" set, make sure to use the configured unit for temperature in your HA instance.
|
||||
# If you don't, then non-temperature messages will change the value of this sensor by reinterpreting the current state with the wrong unit, unless you account for it.
|
||||
# For Celsius use: {{ (value_json.payload.temperature | float) | round(1) }}
|
||||
|
|
|
|||
|
|
@ -6,21 +6,43 @@ sidebar_position: 6
|
|||
description: Bridging mesh networks over the internet and integrating Meshtastic protocols with popular technologies such as Home Assistant, Node Red, and Adafruit IO.
|
||||
---
|
||||
|
||||
## Bridging networks
|
||||
## Public MQTT Server
|
||||
|
||||
|
||||
|
||||
Meshtastic networks in different locations beyond the reach of LoRa can be easily bridged together using MQTT. The simplest option is to connect your mesh to the official Meshtastic MQTT broker. This makes your devices appear on the world map, and provides a copy of your mesh traffic, translated into JSON. All you have to do to join the public MQTT server is to Enable MQTT and set Uplink and Downlink on the channels that you want to share over MQTT. The default device configuration using the public MQTT Server is encrypted.
|
||||
The Meshtastic project provides a public MQTT service that users can connect to, with certain restrictions in place to ensure network stability. This service allows Meshtastic devices to bridge over the internet, providing global connectivity for remote networks.
|
||||
|
||||
You can also specify your own private MQTT broker to bridge mesh networks together, via the internet (or just a local IP network).
|
||||
For instructions on connecting to the public MQTT server, please refer to [Connect to the Default Public Server](/docs/configuration/module/mqtt/#connect-to-the-default-public-server).
|
||||
|
||||
You can find the settings available for MQTT [here](/docs/configuration/module/mqtt).
|
||||
### Restrictions on the Public MQTT Server
|
||||
|
||||
:::important
|
||||
When MQTT is turned on, you are potentially broadcasting your entire mesh's traffic onto the public internet. This includes messages and position information.
|
||||
To maintain optimal performance and protect LoRa meshes, traffic restrictions are currently applied to the public MQTT server.
|
||||
|
||||
The default channel (LongFast) on the public MQTT server usually has a lot of traffic. Your device may get overloaded and may no longer function properly anymore. It is recommended to use a different channel or to use your own MQTT server if you experience issues.
|
||||
:::
|
||||
#### Zero-Hop Policy
|
||||
|
||||
Traffic from the public MQTT server does not fully propagate through local mesh networks. Directly connected nodes will receive the data, but due to the zero-hop policy, it will not spread further to other nodes within the local mesh network.
|
||||
|
||||
#### Optimized Traffic Filtering
|
||||
|
||||
Only specific portnums are prioritized for transmission over the public MQTT server when using the default PSK:
|
||||
|
||||
- NodeinfoApp
|
||||
- TextMessageCompressedApp
|
||||
- TextMessageApp
|
||||
- PositionApp
|
||||
- TelemetryApp
|
||||
- MapReportApp
|
||||
- RoutingApp
|
||||
|
||||
#### Location Precision Filtering
|
||||
|
||||
On the default PSK, the public server also limits the precision of location data to help protect user privacy. Only position packets containing imprecise location data (10-16 bits) are shared on the topic, ensuring that precise location details are not exposed. For more information on how location precision works, see the [Position Precision](https://meshtastic.org/docs/configuration/radio/channels/#position-precision) section.
|
||||
|
||||
This filtering focuses network resources on critical traffic, improving overall performance and reducing unnecessary data flow. Since these restrictions are applied at the network level, no firmware updates are required. As Meshtastic networks continue to grow, further traffic reduction measures may become necessary to manage network load and maintain reliable performance across all channels.
|
||||
|
||||
### Using Private Brokers
|
||||
|
||||
It is not recommended to use the default key (PSK) on a private broker. Doing so potentially allows security vulnerabilities and can flood the mesh with traffic, as private brokers do not enforce the zero-hop policy needed for public channels. Private brokers are intended for use with private channels, where custom PSKs provide secure, isolated communication.
|
||||
|
||||
## Software Integrations
|
||||
|
||||
|
|
@ -35,6 +57,7 @@ If no specific [root topic](/docs/configuration/module/mqtt#root-topic) is confi
|
|||
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/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/`).
|
||||
|
|
@ -52,6 +75,7 @@ The payload is a raw protobuf, whose definitions for Meshtastic can be found [he
|
|||
If [encryption_enabled](/docs/configuration/module/mqtt#encryption-enabled) is set to true, the payload of the MeshPacket will remain encrypted with the key for the specified channel.
|
||||
|
||||
#### JSON topic
|
||||
|
||||
:::note
|
||||
JSON is not supported on the nRF52 platform.
|
||||
:::
|
||||
|
|
@ -82,7 +106,7 @@ An example of a received `NODEINFO_APP` message:
|
|||
|
||||
The meaning of these fields is as follows:
|
||||
|
||||
- "`id`" is the unique ID for this message.
|
||||
- "`id`" is the unique ID for this message.
|
||||
- "`channel`" is the channel index this message was received on.
|
||||
- "`from`" is the unique decimal-equivalent Node ID of the node on the mesh that sent this message. (The hexadecimal value `7efeee00` represented by an integer in decimal is `2130636288`).
|
||||
- "`id`" inside the payload of a `NODEINFO_APP` message is the hexadecimal Node ID (sometimes called User ID) of the node that sent it.
|
||||
|
|
@ -91,15 +115,15 @@ The meaning of these fields is as follows:
|
|||
- "`shortname`" is the short name of the device that sent the `NODEINFO_APP` message.
|
||||
- "`sender`" is the hexadecimal Node ID of the gateway device, which is in this case the same node that sent the `NODEINFO_APP` message.
|
||||
- "`timestamp`" is the Unix Epoch when the message was received, represented as an integer in decimal.
|
||||
- "`to`" is the decimal-equivalent Node ID of the destination of the message. In this case, "-1" means it was a broadcast message (this is the decimal integer representation of `0xFFFFFFFF`).
|
||||
- "`to`" is the decimal-equivalent Node ID of the destination of the message. In this case, "-1" means it was a broadcast message (this is the decimal integer representation of `0xFFFFFFFF`).
|
||||
- "`type`" is the type of the message, in this case it was a `NODEINFO_APP` message.
|
||||
|
||||
The `from` field can thus be used as a stable identifier for a specific node. Note that in firmware prior to 2.2.0, this is a signed value in JSON, while in firmware 2.2.0 and higher, the JSON values are unsigned.
|
||||
The `from` field can thus be used as a stable identifier for a specific node. Note that in firmware prior to 2.2.0, this is a signed value in JSON, while in firmware 2.2.0 and higher, the JSON values are unsigned.
|
||||
|
||||
If the message received contains valid JSON in the payload, the JSON is deserialized and added as a JSON object rather than a string containing the serialized JSON.
|
||||
|
||||
|
||||
#### JSON downlink to instruct a node to send a message
|
||||
|
||||
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/US/2/json/mqtt/` topic.
|
||||
|
|
@ -147,12 +171,6 @@ Gateway nodes (via code running in the phone) will contain two tables to whiteli
|
|||
Since multiple gateway nodes might be connected to a single mesh, it is possible that duplicate messages will be published on any particular topic. Therefore, subscribers to these topics should
|
||||
deduplicate if needed by using the packet ID of each message.
|
||||
|
||||
### Optional web services
|
||||
|
||||
#### Public MQTT broker service
|
||||
|
||||
An existing public [MQTT broker](https://mosquitto.org) will be the default for this service, but clients can use any MQTT broker they choose.
|
||||
|
||||
## Examples
|
||||
|
||||
- [Using mosquitto on a mac](/docs/software/integrations/mqtt/mosquitto.mdx)
|
||||
|
|
|
|||
|
|
@ -7,31 +7,30 @@ sidebar_position: 3
|
|||
|
||||
## Using MQTT with Node-RED
|
||||
|
||||
Node-RED is a free cross-platform programming tool for wiring together hardware, APIs, and online services developed originally by IBM for IOT. It is widely used for home automation by many non-professional programmers and runs well on Pi's. Node-RED has many plug-in modules written by the community.
|
||||
Node-RED is a free cross-platform programming tool for wiring together hardware, APIs, and online services developed originally by IBM for IOT. It is widely used for home automation by many non-professional programmers and runs well on Pi's. Node-RED has many plug-in modules written by the community.
|
||||
|
||||
I will use this platform as a practical example on how to interface with the MQTT features of Meshtastic. Everything can be done from GUI's without using command line.
|
||||
|
||||
|
||||
### Enabling MQTT
|
||||
|
||||
Use http://client.meshtastic.org/ , the python CLI, or an Apple or Android app to connect to your device and adjust these settings.
|
||||
|
||||
1. Settings--> Radio Config--> Network
|
||||
|
||||
1. Settings--> Radio Config--> Network
|
||||
- On the node that will act as the gateway between the mesh and MQTT enable a network connection (i.e. Wifi, Ethernet).
|
||||
- Save
|
||||
- On the node that will act as the gateway between the mesh and MQTT enable a network connection (i.e. Wifi, Ethernet).
|
||||
- Save
|
||||
|
||||
2. Settings--> Module Config--> MQTT config
|
||||
2. Settings--> Module Config--> MQTT config
|
||||
- Configure the MQTT gateway's network configuration.
|
||||
- Verify Encryption Enabled is OFF.
|
||||
- (optional) Turn JSON Output Enabled ON.
|
||||
- Save
|
||||
3. Channel Editor
|
||||
- Go to Channel Editor and enable Uplink and Downlink on the channels you wish to publish to MQTT.
|
||||
- Save
|
||||
|
||||
- Save
|
||||
|
||||
### Using Node-RED with Meshtastic
|
||||
|
||||
There are three common approaches:
|
||||
|
||||
1. Using JSON-encoded messages
|
||||
|
|
@ -39,6 +38,7 @@ There are three common approaches:
|
|||
3. Using protobuf-encoded messages with a protobuf decode node and the Meshtastic protobuf definitions
|
||||
|
||||
The JSON output only publishes the following subset of the messages on a Meshtastic network:
|
||||
|
||||
- Text Message
|
||||
- Telemetry
|
||||
- Device Metrics
|
||||
|
|
@ -54,11 +54,12 @@ The JSON output only publishes the following subset of the messages on a Meshtas
|
|||
> Protobufs are mesh native.
|
||||
|
||||
#### 1. Using JSON-encoded messages
|
||||
:::note
|
||||
|
||||
:::note
|
||||
JSON is not supported on the nRF52 platform.
|
||||
:::
|
||||
|
||||
Make sure that option *JSON Output Enabled* is set in MQTT module options and you have a channel called "mqtt".
|
||||
Make sure that option _JSON Output Enabled_ is set in MQTT module options and you have a channel called "mqtt".
|
||||
|
||||
Below is a valid JSON envelope for information sent by MQTT to a device for broadcast onto the mesh. The `to` field is optional and can be omitted for broadcast. The `channel` field is also optional and can be omitted to send to the primary channel.
|
||||
|
||||
|
|
@ -71,7 +72,9 @@ Below is a valid JSON envelope for information sent by MQTT to a device for broa
|
|||
"payload": text or a json object go here
|
||||
}
|
||||
```
|
||||
|
||||
#### 2. Using protobuf-encoded messages with the Meshtastic decode node
|
||||
|
||||
Install Node-Red plug-in:
|
||||
https://flows.nodered.org/node/@meshtastic/node-red-contrib-meshtastic
|
||||
|
||||
|
|
@ -80,10 +83,9 @@ More info is in the plug-in source repository.
|
|||
There is an example flow using this mechanism available
|
||||
https://github.com/scruplelesswizard/meshtastic-node-red
|
||||
|
||||
|
||||
#### 3. Using protobuf-encoded messages with a protobuf decode node and the Meshtastic protobuf definitions
|
||||
|
||||
If you don't want to depend on JSON decoding on the device, you can decode the protobuf messages off-device. To do that you will need to get the .proto files from https://github.com/meshtastic/protobufs. They function as a schema and are required for decoding in Node-RED. Save the files where the node-RED application can access them and note the file path of the "mqtt.proto" file.
|
||||
If you don't want to depend on JSON decoding on the device, you can decode the protobuf messages off-device. To do that you will need to get the .proto files from https://github.com/meshtastic/protobufs. They function as a schema and are required for decoding in Node-RED. Save the files where the node-RED application can access them and note the file path of the "mqtt.proto" file.
|
||||
|
||||
Install Node-RED plug-ins to your Node-RED application for an embedded MQTT server and a protobuf decoder.
|
||||
https://flows.nodered.org/node/node-red-contrib-aedes
|
||||
|
|
@ -91,20 +93,20 @@ https://flows.nodered.org/node/node-red-contrib-protobuf
|
|||
|
||||
Drag, drop, and wire the nodes like this. For this example, I ran Node-RED on a Windows machine. Note that file paths might be specified differently on different platforms. MQTT server wild cards are usually the same. A "+" is a single level wildcard for a specific topic level. A "#" is a multiple level wildcard that can be used at the end of a topic filter. The debug messages shown are what happens when the inject button sends a JSON message with a topic designed to be picked up by the specified Meshtastic device and then having it rebroadcast the message.
|
||||
|
||||
[<img src="/documents/mqtt/NodeRedTwo.jpg" style={{zoom:'50%'}} />](/documents/mqtt/NodeRedTwo.jpg)
|
||||
[<img src="/documents/mqtt/NodeRedThree.jpg" style={{zoom:'50%'}} />](/documents/mqtt/NodeRedThree.jpg)
|
||||
[<img src="/documents/mqtt/NR_nodes.jpg" style={{zoom:'50%'}} />](/documents/mqtt/NR_nodes.jpg)
|
||||
[<img src="/documents/mqtt/NodeRedTwo.webp" style={{zoom:'50%'}} />](/documents/mqtt/NodeRedTwo.webp)
|
||||
[<img src="/documents/mqtt/NodeRedThree.webp" style={{zoom:'50%'}} />](/documents/mqtt/NodeRedThree.webp)
|
||||
[<img src="/documents/mqtt/NR_nodes.webp" style={{zoom:'50%'}} />](/documents/mqtt/NR_nodes.webp)
|
||||
|
||||
The aedes broker must be set up on the same flow as the other nodes. By activating the Publish debug node, you can see all the published messages.
|
||||
[<img src="/documents/mqtt/Broker1.jpg" style={{zoom:'50%'}} />](/documents/mqtt/Broker1.jpg)
|
||||
[<img src="/documents/mqtt/Broker1.webp" style={{zoom:'50%'}} />](/documents/mqtt/Broker1.webp)
|
||||
Receiving a json mqtt message is very simple.
|
||||
[<img src="/documents/mqtt/Consume.jpg" style={{zoom:'50%'}} />](/documents/mqtt/Consume.jpg)
|
||||
[<img src="/documents/mqtt/Consume.webp" style={{zoom:'50%'}} />](/documents/mqtt/Consume.webp)
|
||||
Injecting a json message to be sent by a device is also very simple. You do need the correct envelope.
|
||||
[<img src="/documents/mqtt/Inject.jpg" style={{zoom:'50%'}} />](/documents/mqtt/Inject.jpg)
|
||||
[<img src="/documents/mqtt/Inject.webp" style={{zoom:'50%'}} />](/documents/mqtt/Inject.webp)
|
||||
Forwarding a text message from one device, through a broker, to another broker/device/channel would look like this.
|
||||
[<img src="/documents/mqtt/Forward.jpg" style={{zoom:'50%'}} />](/documents/mqtt/Forward.jpg)
|
||||
[<img src="/documents/mqtt/Forward.webp" style={{zoom:'50%'}} />](/documents/mqtt/Forward.webp)
|
||||
If you want to decode text and position messages without json, it gets complicated:
|
||||
[<img src="/documents/mqtt/DecodeNewest.jpg" style={{zoom:'50%'}} />](/documents/mqtt/DecodeNewest.jpg)
|
||||
[<img src="/documents/mqtt/DecodeNewest.webp" style={{zoom:'50%'}} />](/documents/mqtt/DecodeNewest.webp)
|
||||
If you are interested in my flow for this it is here:
|
||||
|
||||
```json
|
||||
|
|
@ -669,10 +671,10 @@ If you are interested in my flow for this it is here:
|
|||
(documents/mqtt/Flow.txt)
|
||||
|
||||
Node-red can rapidly (minutes vs days) put together some pretty impressive output when paired with meshtastic. Here is the output of that flow geofencing and mapping via mqtt data.
|
||||
[<img src="/documents/mqtt/Mapping.jpg" style={{zoom:'50%'}} />](/documents/mqtt/Mapping.jpg)
|
||||
[<img src="/documents/mqtt/Mapping.webp" style={{zoom:'50%'}} />](/documents/mqtt/Mapping.webp)
|
||||
|
||||
Advanced use, such as encoding Position and sending it to a device via MQTT without using JSON can get a little complicated. An example of how it can be done is below.
|
||||
[<img src="/documents/mqtt/EncodingPosition.jpg" style={{zoom:'50%'}} />](/documents/mqtt/EncodingPosition.jpg)
|
||||
[<img src="/documents/mqtt/EncodingPosition.webp" style={{zoom:'50%'}} />](/documents/mqtt/EncodingPosition.webp)
|
||||
The flow is:
|
||||
|
||||
```json
|
||||
|
|
@ -1001,4 +1003,4 @@ Sending a position to a device for broadcast to the mesh is much easier with JSO
|
|||
```
|
||||
|
||||
An example of doing this in node-red:
|
||||
[<img src="/documents/mqtt/PosJSON.jpg" style={{zoom:'50%'}} />](/documents/mqtt/PosJSON.jpg)
|
||||
[<img src="/documents/mqtt/PosJSON.webp" style={{zoom:'50%'}} />](/documents/mqtt/PosJSON.webp)
|
||||
|
|
|
|||
90
docs/software/meshtasticator/discrete-event-sim.mdx
Normal file
90
docs/software/meshtasticator/discrete-event-sim.mdx
Normal file
|
|
@ -0,0 +1,90 @@
|
|||
---
|
||||
id: discrete-event-sim
|
||||
title: Discrete Event Simulator Usage Guide
|
||||
sidebar_label: Discrete Event Simulator
|
||||
sidebar_position: 1
|
||||
description: A usage guide for simulating radio communications with configurable parameters and node behaviors.
|
||||
---
|
||||
|
||||
The discrete-event simulator mimics the radio section of the device software. It is currently based on Meshtastic 2.1.
|
||||
|
||||
## Usage
|
||||
|
||||
Please `git clone` or download this repository, navigate to the Meshtasticator folder (optionally create a virtual environment), and install the necessary requirements using:
|
||||
`pip install -r requirements.txt`
|
||||
|
||||
To start one simulation with the default configurations, run:
|
||||
`python3 loraMesh.py [nr_nodes]`
|
||||
|
||||
If no argument is given, you first have to place the nodes on a plot. After you place a node, you can optionally set the node as a Router, change its hop limit, height (elevation), and antenna gain. These settings will automatically save when you place a new node or when you start the simulation.
|
||||
|
||||
|
||||
|
||||
If the number of nodes is given, it will randomly place nodes in the area. It ensures that each node can reach at least one other node. Furthermore, all nodes are placed at a configurable minimum distance (MINDIST) from each other.
|
||||
|
||||
If you placed the nodes yourself, after a simulation the number of nodes, their coordinates, and configuration are automatically saved, and you can rerun the scenario with:
|
||||
`python3 loraMesh.py --from-file`
|
||||
|
||||
If you want to change any of the configurations, adapt the file _out/nodeConfig.yaml_ before running it with the above command.
|
||||
|
||||
For running multiple repetitions of simulations for a set of parameters, e.g., the number of nodes, run:
|
||||
`python3 batchSim.py`
|
||||
|
||||
After the simulations are done, it plots relevant metrics obtained from the simulations. It saves these metrics in _/out/report/_ for analysis later on. See _plotExample.py_ for an example Python script to plot the results.
|
||||
|
||||
To simulate different parameters, you will have to change the _batchSim.py_ script yourself.
|
||||
|
||||
## Custom configurations
|
||||
|
||||
Here we list some of the configurations, which you can change to model your scenario in _/lib/config.py_. These apply to all nodes, except those that you configure per node when using the plot.
|
||||
|
||||
### Modem
|
||||
|
||||
The LoRa modem ([see Meshtastic radio settings](/docs/overview/radio-settings#presets)) that is used, as defined below:
|
||||
|
||||
| Modem | Name | Bandwidth (kHz) | Coding rate | Spreading Factor | Data rate (kbps) |
|
||||
| ----- | -------------- | --------------- | ----------- | ---------------- | ---------------- |
|
||||
| 0 | Short Fast | 250 | 4/8 | 7 | 6.8 |
|
||||
| 1 | Short Slow | 250 | 4/8 | 8 | 3.9 |
|
||||
| 2 | Mid Fast | 250 | 4/8 | 9 | 2.2 |
|
||||
| 3 | Mid Slow | 250 | 4/8 | 10 | 1.2 |
|
||||
| 4 | Long Fast | 250 | 4/8 | 11 | 0.67 |
|
||||
| 5 | Long Moderate | 125 | 4/8 | 11 | 0.335 |
|
||||
| 6 | Long Slow | 125 | 4/8 | 12 | 0.18 |
|
||||
| 7 | Very Long Slow | 62.5 | 4/8 | 12 | 0.09 |
|
||||
|
||||
### Period
|
||||
|
||||
Mean period (in ms) with which the nodes generate a new message following an exponential distribution. For example, if you set it to 300s, each node will generate a message on average once every five minutes.
|
||||
|
||||
### Packet length
|
||||
|
||||
Payload size of each generated message in bytes. For a position packet, it will be around 40 bytes.
|
||||
|
||||
### Model
|
||||
|
||||
This feature refers to the path loss model, i.e., what the simulator uses to calculate how well a signal will propagate. Note that this is only a rough estimation of the physical environment and will not be 100% accurate, as it depends on a lot of factors. The implemented path loss models are:
|
||||
|
||||
- `0` set the log-distance model
|
||||
- `1` set the Okumura-Hata for small and medium-size cities model
|
||||
- `2` set the Okumura-Hata for metropolitan areas
|
||||
- `3` set the Okumura-Hata for suburban environments
|
||||
- `4` set the Okumura-Hata for rural areas
|
||||
- `5` set the 3GPP for suburban macro-cell
|
||||
- `6` set the 3GPP for metropolitan macro-cell
|
||||
|
||||
### Broadcasts or direct messages (DMs)
|
||||
|
||||
By default, _DMs_ is set to False, meaning it will send broadcast messages only. If you set it to True, each node will only send DMs to a random other node in the network.
|
||||
|
||||
## Explanation
|
||||
|
||||
A discrete-event simulator jumps from event to event over time, where an event is a change in the state of the system. It is therefore well-suited for simulating communication networks.
|
||||
|
||||
For every node in the simulation, an instance is created that mimics the [Meshtastic logic](/docs/overview/mesh-algo). Each node runs three processes in parallel: _generateMessage_, _transmit_, and _receive_. The first creates an event by constructing a new message with a unique sequence number at a random time, taken from an exponential distribution. For now, each generated message is of the same payload size. The second and third processes model the actual transmitting and receiving behavior, respectively.
|
||||
|
||||
The model of the LoRa physical (PHY) layer is in _/lib/phy.py_. Depending on the modem used, it calculates what the airtime of a packet is. The PHY layer uses a configurable path loss model to estimate whether nodes at a specific distance can sense each other's packets. Furthermore, it determines whether two packets collide, which depends on the frequency, spreading factor, received time, and received power of the two packets.
|
||||
|
||||
The routing behavior is implemented in each of the processes of the node. Inside _generateMessage_, reliable retransmissions are handled if no implicit acknowledgment is received. A MeshPacket (defined in _/lib/packet.py_) is created to transfer the message. Note that there may be multiple packets created containing the same message, due to retransmissions and rebroadcasting. In _receive_, it is decided what to do on reception of a packet. A packet is flooded if its hop limit is not zero and no rebroadcast of this packet was heard before. In _transmit_, delays of the Medium Access Control (MAC) layer are called from _/lib/mac.py_. The MAC uses a listen-before-talk mechanism, including introducing (random or SNR-based) delays before transmitting a packet. When a packet is ready to be transferred over the air, it is first checked whether in the meantime still no acknowledgment was received; otherwise, the transmission is canceled.
|
||||
|
||||
The actual communication between processes of different nodes is handled by a BroadcastPipe of [Simpy](https://simpy.readthedocs.io/en/latest/examples/process_communication.html). This ensures that a packet transmitted by one node creates events (one at the start of a packet and one at the end) at the receiving nodes.
|
||||
58
docs/software/meshtasticator/index.mdx
Normal file
58
docs/software/meshtasticator/index.mdx
Normal file
|
|
@ -0,0 +1,58 @@
|
|||
---
|
||||
id: meshtasticator
|
||||
title: Meshtasticator
|
||||
sidebar_label: Meshtasticator (Simulator)
|
||||
sidebar_position: 5
|
||||
description: Overview of Meshtasticator simulator for evaluating performance and scalability of the Meshtastic protocol using discrete-event and interactive simulations.
|
||||
---
|
||||
|
||||
import ReactPlayer from "react-player";
|
||||
|
||||
**Meshtasticator** is a discrete-event and interactive simulator that replicates the radio section of the device software. It helps evaluate the performance of various scenarios and the scalability of the protocol. The **Meshtasticator** simulator can be found on [Github](https://github.com/meshtastic/meshtasticator).
|
||||
|
||||
## Discrete-Event Simulator
|
||||
|
||||
The discrete-event simulator models the radio section of the device software to analyze its behavior. It can assess the performance of specific scenarios and the scalability of the protocol.
|
||||
|
||||
### Getting Started
|
||||
|
||||
For step-by-step instructions on how to use the discrete-event simulator, see the [discrete-event simulator usage guide](./discrete-event-sim).
|
||||
|
||||
### Simulation Insights
|
||||
|
||||
After each simulation, the tool plots node placements and schedules the timing for overlapping messages sent during the simulation.
|
||||
|
||||
|
||||
|
||||
The simulator allows network analysis using different parameter sets. For example, below are the results of 100 simulations, each lasting 200 seconds, with varying hop limits and node counts. As expected, the average number of nodes reached per message increases with a higher hop limit.
|
||||
|
||||
|
||||
|
||||
However, this improvement comes with a trade-off in **usefulness**—the proportion of received packets containing new (non-duplicate) messages decreases as rebroadcasting increases.
|
||||
|
||||
|
||||
|
||||
## Interactive Simulator
|
||||
|
||||
The interactive simulator leverages the [Linux-native Meshtastic application](https://meshtastic.org/docs/software/linux-native), i.e., the real device software, while emulating some hardware components, including the LoRa chip. It can also run on Windows or macOS using Docker.
|
||||
|
||||
### Setup Instructions
|
||||
|
||||
To get started with the interactive simulator, see the [interactive simulator usage guide](./interactive-sim).
|
||||
|
||||
### Debugging and Visualization
|
||||
|
||||
This simulator facilitates debugging multiple communicating nodes without needing physical devices.
|
||||
|
||||
<div style={{ maxWidth: "800px", margin: "auto" }}>
|
||||
<ReactPlayer
|
||||
url="/img/software/meshtasticator/interactive-sim-video.mp4"
|
||||
controls
|
||||
width="100%"
|
||||
height="400px"
|
||||
/>
|
||||
</div>
|
||||
|
||||
Additionally, because the simulator has an 'oracle view' of the network, it provides insights into the routes taken by messages.
|
||||
|
||||
|
||||
129
docs/software/meshtasticator/interactive-sim.mdx
Normal file
129
docs/software/meshtasticator/interactive-sim.mdx
Normal file
|
|
@ -0,0 +1,129 @@
|
|||
---
|
||||
id: interactive-sim
|
||||
title: Interactive Simulator Usage Guide
|
||||
sidebar_label: Interactive Event Simulator
|
||||
sidebar_position: 2
|
||||
description: A usage guide for simulating multiple Meshtastic instances with TCP-based communication and configurable pathloss models.
|
||||
---
|
||||
|
||||
The Python script _`interactiveSim.py`_ uses the [Linux native application of Meshtastic](https://meshtastic.org/docs/software/linux-native) to simulate multiple instances of the device software. These instances communicate using TCP via the script, simulating the LoRa chip. The simulator forwards messages from the sender to all nodes within range, based on their simulated positions and the selected pathloss model (see [Pathloss Model](#pathloss-model)). **Note:** Packet collisions are not yet simulated.
|
||||
|
||||
## Usage
|
||||
|
||||
1. Clone or download the repository and navigate to the Meshtasticator folder.
|
||||
2. (Optional) Create a virtual environment.
|
||||
3. Install dependencies:
|
||||
|
||||
```bash
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
|
||||
The simulator runs the Linux native application of Meshtastic firmware. You can use either [PlatformIO](https://meshtastic.org/docs/development/firmware/build) or [Docker](https://meshtastic.org/docs/software/linux-native#usage-with-docker) to run the firmware:
|
||||
|
||||
### Using PlatformIO
|
||||
|
||||
Select 'native' and click 'build.' Locate the generated binary file, likely in _`firmware/.pio/build/native/`_.
|
||||
|
||||
Copy the `program` file to the directory where you'll run the Python script, or provide the path as an argument with `-p`:
|
||||
|
||||
```bash
|
||||
python3 interactiveSim.py 3 -p /home/User/Meshtastic-device/.pio/build/native/program
|
||||
```
|
||||
|
||||
### Using Docker
|
||||
|
||||
The simulator pulls a Docker image that builds the latest Meshtastic firmware.
|
||||
|
||||
Ensure the Docker SDK for Python is installed:
|
||||
|
||||
```bash
|
||||
pip3 install docker
|
||||
```
|
||||
|
||||
Make sure the Docker daemon or Desktop app is running. Use the `-d` argument to launch the simulator:
|
||||
|
||||
```bash
|
||||
python3 interactiveSim.py 3 -d
|
||||
```
|
||||
|
||||
## Running the Simulator
|
||||
|
||||
To run the interactive simulator:
|
||||
|
||||
```bash
|
||||
python3 interactiveSim.py [nrNodes] [-p <full-path-to-program>]
|
||||
```
|
||||
|
||||
- **`nrNodes`** (optional): Number of instances to launch. Each instance opens a terminal and a TCP port (starting at 4403).
|
||||
- If you provide the number of nodes, they will be randomly placed; otherwise, you can manually place nodes on a plot.
|
||||
- After placing nodes, you can configure their [role](https://meshtastic.org/docs/settings/config/device#role), `hopLimit`, height (elevation), and antenna gain. Configurations are saved automatically.
|
||||
|
||||
|
||||
|
||||
## Commands During Simulation
|
||||
|
||||
Once the simulation starts, you can issue commands (or use a predefined [script](#usage-with-script)) to send messages between nodes. Use `plot` to visualize message routes and airtime statistics:
|
||||
|
||||
- Enter a message ID to see its route.
|
||||
- Hover over arcs for information and click to remove the overlay.
|
||||
- Two graphs display channel utilization (one-minute window) and airtime usage (hourly window) for each node.
|
||||
|
||||
|
||||
|
||||
## List of Commands
|
||||
|
||||
- **`broadcast <fromNode> <txt>`**: Send a broadcast from node _fromNode_ with text _txt_.
|
||||
- **`DM <fromNode> <toNode> <txt>`**: Send a Direct Message from node _fromNode_ to node _toNode_ with text _txt_.
|
||||
- **`traceroute <fromNode> <toNode>`**: Send a traceroute request from node _fromNode_ to node _toNode_.
|
||||
- **`reqPos <fromNode> <toNode>`**: Send a position request from node _fromNode_ to node _toNode_.
|
||||
- **`ping <fromNode> <toNode>`**: Send ping from node _fromNode_ to node _toNode_.
|
||||
- **`remove <id>`**: Remove node _id_ from the current simulation.
|
||||
- **`nodes <id0> [id1, etc.]`**: Show the node list as seen by node(s) _id0_, _id1_, etc.
|
||||
- **`plot`**: Plot the routes of messages sent and airtime statistics.
|
||||
- **`exit`**: Exit the simulator without plotting routes.
|
||||
|
||||
## Usage with Script
|
||||
|
||||
Modify the `try` clause in _`interactiveSim.py`_ to predefine messages. Run the simulator with the `-s` argument:
|
||||
|
||||
```bash
|
||||
python3 interactiveSim.py 3 -s
|
||||
```
|
||||
|
||||
- After nodes exchange NodeInfo, they will begin sending messages.
|
||||
- Close the simulation manually with `Ctrl+C` or wait for the timeout.
|
||||
|
||||
## Tips and Tricks
|
||||
|
||||
1. **Speeding Up NodeInfo Exchange:**
|
||||
Disable certain modules by removing `new NodeInfoModule()` from _`src/modules/Modules.cpp`_ in the firmware.
|
||||
|
||||
2. **Saving and Reloading Configurations:**
|
||||
After a simulation, node configurations are saved. You can rerun the same scenario with:
|
||||
|
||||
```bash
|
||||
python3 interactiveSim.py --from-file
|
||||
```
|
||||
|
||||
Modify the _`out/nodeConfig.yaml`_ file to adjust configurations before reloading.
|
||||
|
||||
3. **Using the Python CLI:**
|
||||
You can call functions from the Node class via `sim.getNodeById(<id>)` in _`interactiveSim.py`_. Example:
|
||||
|
||||
```python
|
||||
node.setURL('<YOUR_URL>')
|
||||
```
|
||||
|
||||
## Pathloss Model
|
||||
|
||||
The simulator estimates signal propagation using a pathloss model. This is an approximation of the physical environment, so it may not be 100% accurate. The available models are:
|
||||
|
||||
- **0**: Log-distance model
|
||||
- **1**: Okumura-Hata model (small/medium cities)
|
||||
- **2**: Okumura-Hata model (metropolitan areas)
|
||||
- **3**: Okumura-Hata model (suburban environments)
|
||||
- **4**: Okumura-Hata model (rural areas)
|
||||
- **5**: 3GPP model (suburban macro-cell)
|
||||
- **6**: 3GPP model (metropolitan macro-cell)
|
||||
|
||||
You can modify the pathloss model and area configuration in _`lib/config.py`_. LoRa settings remain at their Meshtastic defaults unless customized during node placement.
|
||||
|
|
@ -541,7 +541,7 @@ meshtastic --ble-scan
|
|||
|
||||
### --noproto
|
||||
|
||||
Don't start the API, just function as a dumb serial terminal. Probably not very helpful from the command line. Used more for testing/internal needs.
|
||||
Don't start the API, just function as a dumb serial terminal. Useful for debugging because it doesn't count as a client. Depends on a physically cabled serial connection. It will connect but not display information over a network (--host) or Bluetooth (--ble) connection.
|
||||
|
||||
```shell title="Usage"
|
||||
meshtastic --noproto
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: Meshtastic Python CLI installation
|
|||
sidebar_label: Installation
|
||||
slug: /software/python/cli/installation
|
||||
sidebar_position: 1
|
||||
description: This page offers comprehensive instructions on methods of installing the Meshtastic Python CLI across different operating systems.
|
||||
description: This page offers comprehensive instructions on methods of installing the Meshtastic Python CLI across different operating systems.
|
||||
---
|
||||
|
||||
import Tabs from "@theme/Tabs";
|
||||
|
|
@ -54,7 +54,7 @@ values={[
|
|||
- You should see something like:
|
||||
- `ID 10c4:ea60 Silicon Labs CP210x UART Bridge` for CP210X
|
||||
- `ID 1a86:55d4 QinHeng Electronics USB Single Serial` for CH9102
|
||||
- If there is no seral device shown that matches the device you are using, please review our [Install Serial Drivers](/docs/getting-started/serial-drivers/) page before proceeding.
|
||||
- If there is no seral device shown that matches the device you are using, please review our [Install Serial Drivers](/docs/getting-started/serial-drivers/) page before proceeding.
|
||||
|
||||
- Check that your computer has Python 3 installed.
|
||||
|
||||
|
|
@ -102,10 +102,10 @@ values={[
|
|||
```shell
|
||||
sudo apt install pipx && pipx install meshtastic
|
||||
```
|
||||
- If using `pipx` it may be necessary to update `$PATH` by running:
|
||||
```shell
|
||||
pipx ensurepath
|
||||
```
|
||||
- If using `pipx` it may be necessary to update `$PATH` by running:
|
||||
```shell
|
||||
pipx ensurepath
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="macos">
|
||||
|
|
@ -210,7 +210,7 @@ When installing Python, make sure to select the option to "Add Python to PATH" o
|
|||
```
|
||||
|
||||
:::note
|
||||
Be aware that the Meshtastic CLI is not able to control the nodes over USB through termux, but you can control devices over Wifi using the `--host x.x.x.x` option with the device IP address (ESP32 or Pico W only). Wifi connection is currently under development and may not be working properly just yet. If you would like to provide feedback or test this feature, please visit our [forum](https://meshtastic.discourse.group) or join our [Discord server](https://discord.gg/ktMAKGBnBs) for more information.
|
||||
Be aware that the Meshtastic CLI is not able to control the nodes over USB through termux, but you can control devices over Wifi using the `--host x.x.x.x` option with the device IP address (ESP32 or Pico W only). Wifi connection is currently under development and may not be working properly just yet. If you would like to provide feedback or test this feature, please join our [Discord server](https://discord.gg/ktMAKGBnBs) for more information.
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
|
|
@ -218,7 +218,6 @@ Be aware that the Meshtastic CLI is not able to control the nodes over USB throu
|
|||
|
||||
**You may need to close and re-open the CLI. The path variables may or may not update for the current session when installing.**
|
||||
|
||||
|
||||
### Standalone Installation (Ubuntu only)
|
||||
|
||||
1. Download the `meshtastic_ubuntu` executable from the [Releases](https://github.com/meshtastic/Meshtastic-python/releases) page.
|
||||
|
|
@ -227,6 +226,7 @@ Be aware that the Meshtastic CLI is not able to control the nodes over USB throu
|
|||
```shell
|
||||
chmod +x meshtastic_ubuntu && mv meshtastic_ubuntu meshtastic
|
||||
```
|
||||
|
||||
3. To run the CLI:
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ The `meshtastic` command is not run within python but is a script run from your
|
|||
|
||||
## Viewing Serial Output
|
||||
|
||||
The `--noproto` command in the Meshtastic Python CLI is used to disable the API and function merely as a "dumb serial terminal." This mode of operation allows both the API and device functionalities to remain accessible for regular use, while simultaneously providing a window into the raw serial output. This feature can be particularly useful for debugging, development, or understanding the low-level communication between devices.
|
||||
The `--noproto` command in the Meshtastic Python CLI is used to disable the API and function merely as a "dumb serial terminal." This mode of operation allows both the API and device functionalities to remain accessible for regular use, while simultaneously providing a window into the raw serial output. This feature can be particularly useful for debugging, development, or understanding the low-level communication between devices. Depends on a physically cabled serial connection. It will connect but not display information over a network (--host) or Bluetooth (--ble) connection.
|
||||
|
||||
```shellsession title="Example Usage"
|
||||
user@host % meshtastic --noproto
|
||||
|
|
@ -112,12 +112,12 @@ Writing modified channels to device
|
|||
|
||||
Toggling `set-ham` changes your device settings in the following ways.
|
||||
|
||||
| Setting | `set-ham` Default | Normal Default |
|
||||
| :----------: | :---------------: | :------------------------------------------------------------------------: |
|
||||
| Setting | `set-ham` Default | Normal Default |
|
||||
| :----------: | :---------------: | :----------------------------------------------------------------------------: |
|
||||
| `IsLicensed` | `true` | See [User Config - IsLicensed](/docs/configuration/radio/user#is-licensed-ham) |
|
||||
| `LongName` | _Your CallSign_ | See [User Config - LongName](/docs/configuration/radio/user#long-name) |
|
||||
| `ShortName` | _Abrv CallSign_ | See [User Config - ShortName](/docs/configuration/radio/user#short-name) |
|
||||
| `PSK` | `""` | See [Channel Settings - PSK](#changing-the-preshared-key) |
|
||||
| `PSK` | `""` | See [Channel Settings - PSK](#changing-the-preshared-key) |
|
||||
|
||||
## Changing the preshared key
|
||||
|
||||
|
|
@ -190,6 +190,7 @@ meshtastic --ble AA11BB22-CC33-DD44-EE55-FF6677889900 --info
|
|||
```shell
|
||||
meshtastic --ble Meshtastic_1234 --nodes
|
||||
```
|
||||
|
||||
#### Export device config with --export-config
|
||||
|
||||
```shell
|
||||
|
|
@ -214,8 +215,6 @@ This is a collection of common questions and answers from our friendly forum.
|
|||
|
||||
### Permission denied: ‘/dev/ttyUSB0’
|
||||
|
||||
As previously discussed on the [forum](https://meshtastic.discourse.group/t/question-on-permission-denied-dev-ttyusb0/590/3?u=geeksville)
|
||||
|
||||
This indicates an OS permission problem for access by your user to the USB serial port. Typically this is fixed by the following.
|
||||
|
||||
```shell
|
||||
|
|
@ -236,4 +235,4 @@ There is a problem with Big Sur and pyserial. The workaround is to install a new
|
|||
|
||||
```shell
|
||||
pip3 install -U --pre pyserial
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ DFU
|
|||
: Device Firmware Update, a state which a device is placed into for it to receive a firmware update
|
||||
|
||||
ESP32 | [Drivers](/docs/getting-started/serial-drivers/esp32/) | [Firmware](/docs/getting-started/flashing-firmware/esp32/)
|
||||
: A chipset of microcontroller made/designed by Espressif, used by a number of devices. Higher power usage than NRF52, but often cheaper and supports WiFi if desired.
|
||||
: A chipset of microcontroller made/designed by Espressif, used by a number of devices. Higher power usage than NRF52, but often cheaper and supports WiFi if desired.
|
||||
|
||||
Firmware | [Guide](https://meshtastic.org/docs/getting-started/flashing-firmware/)
|
||||
: The low-level software programmed onto a Meshtastic device, controlling its hardware functions and enabling it to communicate within the mesh network using LoRa technology. Firmware
|
||||
|
|
@ -73,9 +73,12 @@ Packet
|
|||
Protobuf | [Reference](/docs/development/reference/protobufs/)
|
||||
: Protocol Buffers, a method developed by Google for serializing structured data, used in Meshtastic for efficient communication protocol between devices.
|
||||
|
||||
PSK | [Encryption](/docs/overview/encryption/)
|
||||
Pre-Shared Key (PSK) | [Encryption](/docs/overview/encryption/)
|
||||
: Pre-Shared Key, a secret code or passphrase used in Meshtastic channels for encryption, ensuring that only devices with the matching PSK can communicate within that specific channel.
|
||||
|
||||
Public Key Cryptography (PKC) | [Encryption](/docs/overview/encryption/)
|
||||
: A cryptographic method introduced in Meshtastic v2.5 for Direct Messages and Admin Messages, where each device uses a unique public and private key pair. The public key, shared with other devices, enables secure message encryption, while the private key allows only the intended recipient to decrypt and authenticate the message. This approach enhances privacy and integrity for both direct device-to-device communication and sensitive admin functions.
|
||||
|
||||
Repeater | [Role Definitions](/docs/configuration/radio/device/#roles)
|
||||
: Infrastructure node for extending network coverage by relaying messages with minimal overhead. Not visible in Nodes list.
|
||||
|
||||
|
|
|
|||
|
|
@ -33,6 +33,7 @@
|
|||
"react-dom": "^18.2.0",
|
||||
"react-icons": "^5.0.1",
|
||||
"react-markdown": "^9.0.1",
|
||||
"react-player": "^2.16.0",
|
||||
"remark-deflist": "^1.0.0",
|
||||
"swr": "^2.2.5",
|
||||
"tailwindcss": "^3.4.1"
|
||||
|
|
|
|||
12077
pnpm-lock.yaml
12077
pnpm-lock.yaml
File diff suppressed because it is too large
Load diff
|
|
@ -7,10 +7,10 @@ export default function GiscusComponent() {
|
|||
|
||||
return (
|
||||
<Giscus
|
||||
repo="meshtastic/meshtastic"
|
||||
repoId="MDEwOlJlcG9zaXRvcnkzMzkzMDEyMjI="
|
||||
repo="meshtastic/discussions"
|
||||
repoId="R_kgDONDs6gA"
|
||||
category="Blog Post Comments"
|
||||
categoryId="DIC_kwDOFDlTZs4Choq7"
|
||||
categoryId="DIC_kwDONDs6gM4Cjy3h"
|
||||
mapping="pathname"
|
||||
term="specific-term" //If you didn't select "Discussion title contains a specific term", omit.
|
||||
strict="1"
|
||||
|
|
|
|||
|
|
@ -1,27 +1,28 @@
|
|||
import type React from "react";
|
||||
|
||||
import { FiExternalLink } from "react-icons/fi";
|
||||
|
||||
export interface SocialCardProps {
|
||||
children: React.ReactNode;
|
||||
color: string;
|
||||
link: string;
|
||||
isMeLink?: boolean;
|
||||
}
|
||||
|
||||
export const SocialCard = ({
|
||||
children,
|
||||
color,
|
||||
link,
|
||||
isMeLink = false,
|
||||
}: SocialCardProps): JSX.Element => {
|
||||
return (
|
||||
<div
|
||||
className={`group relative flex h-24 w-36 min-w-max flex-shrink-0 rounded-xl shadow-xl ${color} m-2`}
|
||||
className={`group relative flex h-20 w-28 min-w-max flex-shrink-0 rounded-lg shadow-lg ${color} m-1`}
|
||||
>
|
||||
{children}
|
||||
<a
|
||||
className="absolute top-0 left-0 right-0 bottom-0 hidden rounded-xl border border-accent bg-secondary bg-opacity-95 text-2xl shadow-xl group-hover:flex"
|
||||
href={link}
|
||||
rel="noreferrer"
|
||||
rel={isMeLink ? "me noreferrer" : "noreferrer"}
|
||||
target="_blank"
|
||||
>
|
||||
<FiExternalLink className="m-auto" />
|
||||
|
|
|
|||
|
|
@ -16,7 +16,9 @@ export const FirmwareCard = ({
|
|||
<div className="card__header flex justify-between">
|
||||
<h3>{variant}</h3>
|
||||
{release?.length && (
|
||||
<a href={release[0].page_url}>{release[0].title}</a>
|
||||
<a href={release[0].page_url}>
|
||||
{release[0].title.replace("Meshtastic Firmware ", "")}
|
||||
</a>
|
||||
)}
|
||||
</div>
|
||||
<div className="card__body">
|
||||
|
|
@ -29,7 +31,9 @@ export const FirmwareCard = ({
|
|||
{release.slice(1, 6).map((release) => {
|
||||
return (
|
||||
<div key={release.id}>
|
||||
<a href={release.zip_url}>{release.title}</a>
|
||||
<a href={release.page_url}>
|
||||
{release.title.replace("Meshtastic Firmware ", "")}
|
||||
</a>
|
||||
</div>
|
||||
);
|
||||
})}
|
||||
|
|
@ -38,7 +42,7 @@ export const FirmwareCard = ({
|
|||
{release?.length ? (
|
||||
<>
|
||||
<a
|
||||
href={release[0].zip_url}
|
||||
href={release[0].page_url}
|
||||
className="button button--secondary button--block margin-top--sm"
|
||||
>
|
||||
Download {variant}
|
||||
|
|
|
|||
|
|
@ -38,13 +38,12 @@ const Firmware = (): JSX.Element => {
|
|||
<div className="flex w-full flex-col bg-primary xl:flex-row">
|
||||
<div className="card m-4 border-2 border-secondary">
|
||||
<div className="card__header">
|
||||
<h3>ESP32 Web Flasher</h3>
|
||||
<h3>Web Flasher</h3>
|
||||
</div>
|
||||
<div className="card__body">
|
||||
<p>
|
||||
Web based installer for easy flashing with Chrome and Edge
|
||||
Browser. Works with T-Beam, T-Lora, Nano-G1 and similar
|
||||
boards.
|
||||
Web based flasher for easy device flashing with Chrome and
|
||||
Edge Browser. Works with all major device architectures.
|
||||
</p>
|
||||
</div>
|
||||
<div className="card__footer mt-auto">
|
||||
|
|
@ -52,7 +51,7 @@ const Firmware = (): JSX.Element => {
|
|||
href="https://flasher.meshtastic.org/"
|
||||
className="m-auto flex rounded-lg border-4 border-transparent bg-accent p-1 font-semibold text-black shadow-md hover:text-black hover:brightness-110 active:border-green-200"
|
||||
>
|
||||
Go to Flasher
|
||||
Go to Web Flasher
|
||||
<ArrowTopRightOnSquareIcon className="m-auto ml-2 h-4" />
|
||||
</a>
|
||||
</div>
|
||||
|
|
@ -97,7 +96,8 @@ const Firmware = (): JSX.Element => {
|
|||
</div>
|
||||
</div>
|
||||
<div className="card__body">
|
||||
Available on MacOS & iOS. Requires MacOS Ventura or iOS 16+.
|
||||
Available on iOS, iPadOS and macOS. The last two major OS
|
||||
versions are supported.
|
||||
</div>
|
||||
<div className="card__footer mt-auto">
|
||||
<a
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ const SocialCards: SocialCardProps[] = [
|
|||
children: (
|
||||
<img
|
||||
alt="twitter"
|
||||
className="m-auto h-14"
|
||||
className="m-auto h-10"
|
||||
src="/img/homepage/Twitter-Logo-White.svg"
|
||||
/>
|
||||
),
|
||||
|
|
@ -38,7 +38,7 @@ const SocialCards: SocialCardProps[] = [
|
|||
children: (
|
||||
<img
|
||||
alt="facebook"
|
||||
className="m-auto h-14"
|
||||
className="m-auto h-10"
|
||||
src="/img/homepage/f_logo_RGB-White_1024.webp"
|
||||
/>
|
||||
),
|
||||
|
|
@ -49,7 +49,7 @@ const SocialCards: SocialCardProps[] = [
|
|||
children: (
|
||||
<img
|
||||
alt="instagram"
|
||||
className="m-auto h-14"
|
||||
className="m-auto h-10"
|
||||
src="/img/homepage/Instagram_Glyph_Gradient.svg"
|
||||
/>
|
||||
),
|
||||
|
|
@ -60,19 +60,8 @@ const SocialCards: SocialCardProps[] = [
|
|||
children: (
|
||||
<img
|
||||
alt="youtube"
|
||||
className="m-auto h-16"
|
||||
src="/img/homepage/YouTube-Logo-White.svg"
|
||||
/>
|
||||
),
|
||||
},
|
||||
{
|
||||
color: "bg-[#ffffff]",
|
||||
link: "https://meshtastic.discourse.group",
|
||||
children: (
|
||||
<img
|
||||
alt="discourse"
|
||||
className="m-auto h-12"
|
||||
src="/img/homepage/Discourse-Logo-White.svg"
|
||||
src="/img/homepage/YouTube-Logo-White.svg"
|
||||
/>
|
||||
),
|
||||
},
|
||||
|
|
@ -82,18 +71,30 @@ const SocialCards: SocialCardProps[] = [
|
|||
children: (
|
||||
<img
|
||||
alt="reddit"
|
||||
className="m-auto h-20"
|
||||
className="m-auto h-14"
|
||||
src="/img/homepage/Reddit-Logo-White.svg"
|
||||
/>
|
||||
),
|
||||
},
|
||||
{
|
||||
color: "bg-[#563ACC]",
|
||||
link: "https://mastodon.social/@meshtastic",
|
||||
isMeLink: true,
|
||||
children: (
|
||||
<img
|
||||
alt="mastodon"
|
||||
className="m-auto h-10"
|
||||
src="/img/homepage/mastodon-logo-white.svg"
|
||||
/>
|
||||
),
|
||||
},
|
||||
{
|
||||
color: "bg-[#24A1DE]",
|
||||
link: "https://t.me/+hmKN0xOR73ExOTU6",
|
||||
children: (
|
||||
<img
|
||||
alt="telegram"
|
||||
className="m-auto h-14"
|
||||
className="m-auto h-10"
|
||||
src="/img/homepage/telegram-single-path-240px.svg"
|
||||
/>
|
||||
),
|
||||
|
|
@ -147,9 +148,14 @@ function Home() {
|
|||
<main className="flex flex-col gap-4">
|
||||
<div className="bg-primaryDark mx-auto flex w-full lg:w-auto flex-col gap-4 p-4 shadow-inner">
|
||||
<h3 className="text-xl font-bold">Connect with us.</h3>
|
||||
<div className="flex w-full overflow-x-auto">
|
||||
<div className="flex w-full overflow-x-auto gap-2 flex-wrap justify-center">
|
||||
{SocialCards.map((card) => (
|
||||
<SocialCard key={card.link} color={card.color} link={card.link}>
|
||||
<SocialCard
|
||||
key={card.link}
|
||||
color={card.color}
|
||||
link={card.link}
|
||||
isMeLink={card.isMeLink}
|
||||
>
|
||||
{card.children}
|
||||
</SocialCard>
|
||||
))}
|
||||
|
|
@ -177,11 +183,7 @@ function Home() {
|
|||
<li>Radio</li>
|
||||
<li>Battery</li>
|
||||
<li>Case</li>
|
||||
<li>
|
||||
Antenna (most devices include an antenna, but the quality
|
||||
can be a bit of a mixed bag from some suppliers on stock
|
||||
antennas)
|
||||
</li>
|
||||
<li>Antenna</li>
|
||||
</ul>
|
||||
</p>
|
||||
</div>
|
||||
|
|
@ -192,7 +194,7 @@ function Home() {
|
|||
</div>
|
||||
<div className="card__body flex justify-center">
|
||||
<p>
|
||||
The Meshtastic Web-Based Flasher & Clients can assist you in
|
||||
The Meshtastic Web Flasher & Clients can assist you in
|
||||
flashing the firmware and configuring settings.
|
||||
</p>
|
||||
</div>
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB |
BIN
static/documents/mqtt/Broker1.webp
Normal file
BIN
static/documents/mqtt/Broker1.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 6.8 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 37 KiB |
BIN
static/documents/mqtt/Consume.webp
Normal file
BIN
static/documents/mqtt/Consume.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 9 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 129 KiB |
BIN
static/documents/mqtt/Decode.webp
Normal file
BIN
static/documents/mqtt/Decode.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 148 KiB |
BIN
static/documents/mqtt/DecodeNewest.webp
Normal file
BIN
static/documents/mqtt/DecodeNewest.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 143 KiB |
BIN
static/documents/mqtt/EncodingPosition.webp
Normal file
BIN
static/documents/mqtt/EncodingPosition.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 121 KiB |
BIN
static/documents/mqtt/Forward.webp
Normal file
BIN
static/documents/mqtt/Forward.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 36 KiB |
BIN
static/documents/mqtt/Inject.webp
Normal file
BIN
static/documents/mqtt/Inject.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 10 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 168 KiB |
BIN
static/documents/mqtt/MapFlow.webp
Normal file
BIN
static/documents/mqtt/MapFlow.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 45 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 191 KiB |
BIN
static/documents/mqtt/Mapping.webp
Normal file
BIN
static/documents/mqtt/Mapping.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 146 KiB |
BIN
static/documents/mqtt/NR_nodes.webp
Normal file
BIN
static/documents/mqtt/NR_nodes.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 54 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 415 KiB |
BIN
static/documents/mqtt/NodeRedThree.webp
Normal file
BIN
static/documents/mqtt/NodeRedThree.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 101 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 409 KiB |
BIN
static/documents/mqtt/NodeRedTwo.webp
Normal file
BIN
static/documents/mqtt/NodeRedTwo.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 98 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 95 KiB |
BIN
static/documents/mqtt/PosJSON.webp
Normal file
BIN
static/documents/mqtt/PosJSON.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
BIN
static/img/android/android-DM-ack_dk.webp
Normal file
BIN
static/img/android/android-DM-ack_dk.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 600 B |
BIN
static/img/android/android-DM-ack_lt.webp
Normal file
BIN
static/img/android/android-DM-ack_lt.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 532 B |
BIN
static/img/android/android-imp-ack_dk.webp
Normal file
BIN
static/img/android/android-imp-ack_dk.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 704 B |
BIN
static/img/android/android-imp-ack_lt.webp
Normal file
BIN
static/img/android/android-imp-ack_lt.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 674 B |
BIN
static/img/android/android-no-ack_dk.webp
Normal file
BIN
static/img/android/android-no-ack_dk.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 700 B |
BIN
static/img/android/android-no-ack_lt.webp
Normal file
BIN
static/img/android/android-no-ack_lt.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 662 B |
BIN
static/img/android/android-sent_dk.webp
Normal file
BIN
static/img/android/android-sent_dk.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 656 B |
BIN
static/img/android/android-sent_lt.webp
Normal file
BIN
static/img/android/android-sent_lt.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 626 B |
BIN
static/img/android/android-waiting_dk.webp
Normal file
BIN
static/img/android/android-waiting_dk.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 668 B |
BIN
static/img/android/android-waiting_lt.webp
Normal file
BIN
static/img/android/android-waiting_lt.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 638 B |
Binary file not shown.
|
Before Width: | Height: | Size: 54 KiB After Width: | Height: | Size: 53 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue