mirror of
https://github.com/meshtastic/meshtastic.git
synced 2024-11-09 23:24:10 -08:00
Merge branch 'master' into add-station-g2
This commit is contained in:
rcarteraz
GitHub
commit
f7ba472c51
|
|
@ -9,7 +9,7 @@ description: "Understand Meshtastic's encryption: optional network-wide AES256 s
|
||||||
|
|
||||||
## Explanation
|
## Explanation
|
||||||
|
|
||||||
Meshtastic provides AES256 encryption for the payload of each packet when sending via LoRa, with a different key for each [channel](/docs/configuration/radio/channels/). The [packet header](/docs/overview/mesh-algo/#layer-1-unreliable-zero-hop-messaging) is always sent unencrypted, which allows nodes to relay packets they can't decrypt as well. One can disable this by setting a different [rebroadcast mode](/docs/configuration/radio/device#rebroadcast-mode).
|
Meshtastic provides AES256-CTR encryption for the payload of each packet when sending via LoRa, with a different key for each [channel](/docs/configuration/radio/channels/). The [packet header](/docs/overview/mesh-algo/#layer-1-unreliable-zero-hop-messaging) is always sent unencrypted, which allows nodes to relay packets they can't decrypt as well. One can disable this by setting a different [rebroadcast mode](/docs/configuration/radio/device#rebroadcast-mode).
|
||||||
|
|
||||||
By default you have one primary channel which is encrypted with a simple known key ("AQ=="), so to use proper encryption you **must change** this key first, or create a new channel and share it with the ones you want to communicate with. However, if you don't have the default key, it means you will not be able to communicate with devices that don't have your key.
|
By default you have one primary channel which is encrypted with a simple known key ("AQ=="), so to use proper encryption you **must change** this key first, or create a new channel and share it with the ones you want to communicate with. However, if you don't have the default key, it means you will not be able to communicate with devices that don't have your key.
|
||||||
|
|
||||||
|
|
@ -19,6 +19,72 @@ All periodic broadcasts (position, telemetry, etc.) the device sends out itself
|
||||||
|
|
||||||
The device will decrypt the payload before sending it to a client app via BLE, serial, Wi-Fi/Ethernet. For MQTT you can [specify](/docs/configuration/module/mqtt#encryption-enabled) whether you want to send an encrypted or unencrypted payload.
|
The device will decrypt the payload before sending it to a client app via BLE, serial, Wi-Fi/Ethernet. For MQTT you can [specify](/docs/configuration/module/mqtt#encryption-enabled) whether you want to send an encrypted or unencrypted payload.
|
||||||
|
|
||||||
|
## Is it as secure as Wi-Fi WPA3, HTTPS TLS1.3 or Signal ?
|
||||||
|
|
||||||
|
**No**.
|
||||||
|
|
||||||
|
[WPA3](https://en.wikipedia.org/wiki/WPA3), [TLS1.3](https://en.wikipedia.org/wiki/TLS1.3), [Signal](https://en.wikipedia.org/wiki/Signal_Protocol) and Meshtastic can all use AES256, yet AES is one of the many cogs required in a modern encryption system, see below the main features "missing" in Meshtastic.
|
||||||
|
|
||||||
|
### Perfect-Forward-Secrecy
|
||||||
|
|
||||||
|
[**P**erfect-**F**orward-**S**ecrecy also known as **PFS**](https://en.wikipedia.org/wiki/Forward_secrecy) means *previous* communications and more generally anything *passively captured* cannot be decrypted ***even when the key is compromised***.
|
||||||
|
|
||||||
|
This means Meshtastic is vulnerable to [**« Harvest now, Decrypt later »**](https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later) attacks, **this attack itself is not enough to decrypt messages** it relies on an other failure leaking the channel key such as:
|
||||||
|
- Accidently sharing the channel key with the wrong person.
|
||||||
|
- One of your nodes being stolen.
|
||||||
|
- Any unknown bug revealing the channel key to an attacker.
|
||||||
|
|
||||||
|
Other protocols such as *misconfigured TLS1.2* are far more impacted by Harvest now, Decrypt later attacks because their keys will be broken by near future Quantum-Computers yet they do not provide PFS.
|
||||||
|
|
||||||
|
Meshtastic's encryption is not threatened by Quantum-Computers\* so realistic attack vectors are accidental miss-handling of channel keys and nodes being lost.
|
||||||
|
|
||||||
|
\*on the Quantum-Resistance of AES256 see:
|
||||||
|
- [this stackoverflow question, contain a bit of debates and two good answers](https://crypto.stackexchange.com/q/6712)
|
||||||
|
- [NIST's Post-Quantum FAQ](https://csrc.nist.gov/projects/post-quantum-cryptography/faqs) section « To protect against the threat of quantum computers, should we double the key length for AES now? (added 11/18/18) »
|
||||||
|
|
||||||
|
**Recommendations** for users using *private channels*:
|
||||||
|
- **Do not configure private channels on unattended nodes**, nodes will relay meshtastic traffic even if they are not able to decrypt it.
|
||||||
|
Your unattended routers should not have the private PSK configured as it is easy to gain physical access and extract the channel key.
|
||||||
|
- Keep in mind, everything sent on a channel can be stored and decrypted later by anyone who gain access to the key even if you locally delete the messages.
|
||||||
|
- Change your Channel Keys from time to time.
|
||||||
|
|
||||||
|
### Integrity
|
||||||
|
|
||||||
|
Integrity means ensuring messages cannot be modified without the key.
|
||||||
|
|
||||||
|
Meshtastic does not check messages have not been tempered with, see [`#4030`](https://github.com/meshtastic/firmware/issues/4030) for details.
|
||||||
|
|
||||||
|
**Recommendations**:
|
||||||
|
- Keep in mind, by applying a known plaintext attack anyone *could* send messages on a channel even with the channel key is private and secure.
|
||||||
|
- For developers of third party applications integrating meshtastic, include a cryptographic MAC over the message content and PSK,
|
||||||
|
we are also considering an [AEAD secured channel mode which would provide this natively](https://github.com/meshtastic/firmware/issues/4030).
|
||||||
|
|
||||||
|
### Authentication
|
||||||
|
|
||||||
|
Authentication means nodes say who they are on the network, meshtastic does not implement this so it is trivial to impersonate anyone else if you have access to the channel key.
|
||||||
|
|
||||||
|
This is because node ids are based on hardware [MAC address](https://en.wikipedia.org/wiki/MAC_address), theses are hardcoded by the manufacturer.
|
||||||
|
|
||||||
|
Some other networks like [Yggdrasil](https://yggdrasil-network.github.io/), [cjdns](https://github.com/cjdelisle/cjdns) or [libp2p](https://libp2p.io/) use [public / private key pairs](https://en.wikipedia.org/wiki/Public-key_cryptography) and the Public Key becomes the Node Identity, this make all messages bigger and or require an interactive handshake process.
|
||||||
|
|
||||||
|
**Recommendations**:
|
||||||
|
- Keep in mind, the sender field is indicative and anyone with access to the channel key can trivially lie.
|
||||||
|
|
||||||
|
## Direct-Messages
|
||||||
|
|
||||||
|
Direct-Messages are implemented as channel messages which have a `to` protobuf field set.
|
||||||
|
|
||||||
|
This means anyone in the channel can read all your direct-messages.
|
||||||
|
|
||||||
|
Also the node needs to know the right channel to use, this is done by using the latest one a NodeInfo was received, due to the lack of `Authentication` this means anyone you share a channel with can send a spoofed NodeInfo and make you send direct-messages on an incorrect public channel.
|
||||||
|
|
||||||
|
**Recommendations**:
|
||||||
|
- Keep in mind, due to NodeInfo spoof issue Direct-Messages are **very significantly less secure than a private channel** with a secure PSK.
|
||||||
|
- Do not use Direct-Messages for anything private, instead ahead of time create a new private channel and share it with the person you want to message with.
|
||||||
|
- Nodes will relay encrypted packets even if they can't decrypt it, so you only loose on some [small DM optimizations](https://github.com/meshtastic/firmware/pull/3753).
|
||||||
|
- Do not send the private channel key in direct messages or a public channel, because then anyone listening gain access.
|
||||||
|
- Use a different private channel for each person you want to have private conversations with.
|
||||||
|
|
||||||
## Comments
|
## Comments
|
||||||
|
|
||||||
Cryptography is tricky, so we've tried to 'simply' apply standard crypto solutions to our implementation. However, the project developers are not cryptography experts.
|
Cryptography is tricky, so we've tried to 'simply' apply standard crypto solutions to our implementation. However, the project developers are not cryptography experts.
|
||||||
|
|
@ -72,3 +138,14 @@ I'm assuming that meshtastic is being used to hike in places where someone capab
|
||||||
- Two other things to keep in mind are that AES-CTR does not itself provide authenticity (e.g. an attacker can flip bits in replaying data and scramble the resulting plaintext), and that the current scheme gives some hints about transmission in the size. So, if you worry about an adversary deliberately messing-up messages or knowing the length of a text message, it looks like those might be possible.
|
- Two other things to keep in mind are that AES-CTR does not itself provide authenticity (e.g. an attacker can flip bits in replaying data and scramble the resulting plaintext), and that the current scheme gives some hints about transmission in the size. So, if you worry about an adversary deliberately messing-up messages or knowing the length of a text message, it looks like those might be possible.
|
||||||
|
|
||||||
I'm guessing that the network behaves somewhat like a store-and-forward network - or, at least, that the goal is to avoid establishing a two-way connection to transmit data. I'm afraid I haven't worked with mesh networks much, but remember studying them briefly in school about ten years ago.
|
I'm guessing that the network behaves somewhat like a store-and-forward network - or, at least, that the goal is to avoid establishing a two-way connection to transmit data. I'm afraid I haven't worked with mesh networks much, but remember studying them briefly in school about ten years ago.
|
||||||
|
|
||||||
|
### Comments from @Jorropo
|
||||||
|
|
||||||
|
- The IV initialization only use 31 random bits per reboot, it then increment messages sequentially. This is not high, it makes duplicate unlikely but probable given the complete scale of the network. Thankfully IV include lower 32 bits of the MAC address which should be unique per node, so each node is it's own birthday paradox, we aren't looking for network wide birthday paradox which would be easy to hack. See [`#4031`](https://github.com/meshtastic/firmware/issues/4031).
|
||||||
|
Could be fixed.
|
||||||
|
- The lack of [integrity wasn't properly considered](https://github.com/meshtastic/firmware/issues/4030), the remote administration module implements priviliged RPC calls over AES-CTR without any MAC or AEAD.
|
||||||
|
Could be fixed.
|
||||||
|
- The AES-CTR implementation looks like it protects Confidentiality assuming IVs are not duplicated.
|
||||||
|
- The lack of Forward Secrecy is a bit worrying for a chat messenger when new users lack the paranoid and annoying key management practice that would be required for safe operation.
|
||||||
|
- IMO the clients should have a big red box the first time you open a Direct-Message indicating theses are not private and not E2E. This was not clear to me without reading the code.
|
||||||
|
- This project is completely fine for chatting with strangers, using the default key and understanding everything is public, I would not trust it with anything private without some other layer or significant reworks. For example I would consider SSH or Signal over Meshtastic safe. Yet Meshtastic does not choose to have worse crypto for bad reasons, they make the network significantly more usable over the unreliable slow LoRa backhaul it is using.
|
||||||
|
|
@ -71,16 +71,15 @@ us on [Discord](https://discord.com/invite/ktMAKGBnBs) to add your group.
|
||||||
## India
|
## India
|
||||||
- [India Bir Paragliding](https://bircom.in)
|
- [India Bir Paragliding](https://bircom.in)
|
||||||
|
|
||||||
|
## Israel
|
||||||
|
- [Israel Meshtastic Club](https://t.me/+yUGsbNw3zp41MGFk)
|
||||||
|
|
||||||
## Italy
|
## Italy
|
||||||
- [Meshtastic Italia](https://t.me/meshtastic_italia)
|
|
||||||
- [Mesh_ITA Discord Server](https://discord.gg/ETFmtyzbFT)
|
- [Mesh_ITA Discord Server](https://discord.gg/ETFmtyzbFT)
|
||||||
|
|
||||||
## Lithuania
|
## Lithuania
|
||||||
- [Meshtastic Lietuva](https://www.facebook.com/groups/1122509422249414)
|
- [Meshtastic Lietuva](https://www.facebook.com/groups/1122509422249414)
|
||||||
|
|
||||||
## The Netherlands
|
|
||||||
- [Meshtastic Netherlands](https://t.me/meshtastic_nl)
|
|
||||||
|
|
||||||
## Poland
|
## Poland
|
||||||
- [Meshtastic Poland Matrix Space](https://matrix.to/#/#meshtasticpl:matrix.org)
|
- [Meshtastic Poland Matrix Space](https://matrix.to/#/#meshtasticpl:matrix.org)
|
||||||
|
|
||||||
|
|
@ -89,14 +88,12 @@ us on [Discord](https://discord.com/invite/ktMAKGBnBs) to add your group.
|
||||||
- [Meshtastic Taiwan Community 臺灣鏈網 - Discord](https://discord.gg/2vZkuckp8E)
|
- [Meshtastic Taiwan Community 臺灣鏈網 - Discord](https://discord.gg/2vZkuckp8E)
|
||||||
|
|
||||||
## Türkiye
|
## Türkiye
|
||||||
- [Meshtastic Türkiye Community - Telegram (https://t.me/trmesh)
|
- [Meshtastic Türkiye Community - Telegram](https://t.me/trmesh)
|
||||||
- [Meshtastic Türkiye Community - Discord](https://discord.gg/ThcG4Arb)
|
- [Meshtastic Türkiye Community - Discord](https://discord.gg/7TGnZSSA)
|
||||||
- [Meshtastic Türkiye Community - Web (https://trmesh.org)
|
- [Meshtastic Türkiye Community - Web](https://trmesh.org)
|
||||||
|
|
||||||
## United Kingdom
|
## Ukraine
|
||||||
- [UK Meshtastic Kent / South East](https://www.facebook.com/groups/ukmeshtastickent/)
|
- [WiKi Meshtastic UA](https://wikimesh.pp.ua)
|
||||||
- [UK Meshtastic Brighton](https://www.facebook.com/groups/3696312513946679/)
|
|
||||||
- [UK Meshtastic North East England](https://www.facebook.com/groups/meshtasticnortheastengland/)
|
|
||||||
|
|
||||||
## United States
|
## United States
|
||||||
- [Midwest Mesh](https://discord.gg/wYwD56K439)
|
- [Midwest Mesh](https://discord.gg/wYwD56K439)
|
||||||
|
|
@ -123,7 +120,7 @@ us on [Discord](https://discord.com/invite/ktMAKGBnBs) to add your group.
|
||||||
- [Hawaii Meshnet](https://www.hawaiimesh.net/)
|
- [Hawaii Meshnet](https://www.hawaiimesh.net/)
|
||||||
|
|
||||||
### Illinois
|
### Illinois
|
||||||
- [Chicagoland Meshtastic](https://chicagolandmesh.org/)
|
- [Chicagoland Mesh](https://chicagolandmesh.org)
|
||||||
|
|
||||||
### Kansas
|
### Kansas
|
||||||
- [SecKC Amateur Radio Club of Kansas City and Surrounding Cities for Amateur Radio](https://ks3ckc.radio/home)
|
- [SecKC Amateur Radio Club of Kansas City and Surrounding Cities for Amateur Radio](https://ks3ckc.radio/home)
|
||||||
|
|
@ -152,3 +149,6 @@ us on [Discord](https://discord.com/invite/ktMAKGBnBs) to add your group.
|
||||||
|
|
||||||
### Texas
|
### Texas
|
||||||
- [Austin Mesh](https://austinmesh.org/)
|
- [Austin Mesh](https://austinmesh.org/)
|
||||||
|
|
||||||
|
### Wisconsin
|
||||||
|
- [Meshconsin](https://meshconsin.org)
|
||||||
|
|
|
||||||
|
|
@ -41,6 +41,7 @@ Input event sources accepted by the canned message module.
|
||||||
| `rotEnc1` | Basic Rotary Encoder |
|
| `rotEnc1` | Basic Rotary Encoder |
|
||||||
| `upDownEnc1` | Up Down Encoder (use this also for RAK14006 Rotary Encoder) |
|
| `upDownEnc1` | Up Down Encoder (use this also for RAK14006 Rotary Encoder) |
|
||||||
| `cardkb` | M5 Stack CardKB (this covers RAK14004 Keymatrix) |
|
| `cardkb` | M5 Stack CardKB (this covers RAK14004 Keymatrix) |
|
||||||
|
| `serialkb` | Chatter serial keypad |
|
||||||
|
|
||||||
### Rotary Encoder Enabled
|
### Rotary Encoder Enabled
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -13,7 +13,7 @@ import TabItem from "@theme/TabItem";
|
||||||
Using this module, a client device can ask a special Store & Forward Router to resend text messages after the client has been temporarily not in LoRa range of the mesh.
|
Using this module, a client device can ask a special Store & Forward Router to resend text messages after the client has been temporarily not in LoRa range of the mesh.
|
||||||
|
|
||||||
:::info
|
:::info
|
||||||
Only ESP32 based devices with onboard PSRAM like the T-Beam and T3S3 can be a Store & Forward Router. Requires the device to use at least firmware version 2.2.23 and to be set as a `ROUTER` or `ROUTER_CLIENT`.
|
Only ESP32 based devices with onboard PSRAM like the T-Beam and T3S3 can be a Store & Forward Router. Requires the device to use at least firmware version 2.2.23 and to be set as a `ROUTER`.
|
||||||
:::
|
:::
|
||||||
|
|
||||||
When a client device requests the history from the Store & Forward Router, the router will resend the text messages over LoRa that it has received. The router will only return messages that are within the time window the client has requested up to the maximum number of messages configured for the router.
|
When a client device requests the history from the Store & Forward Router, the router will resend the text messages over LoRa that it has received. The router will only return messages that are within the time window the client has requested up to the maximum number of messages configured for the router.
|
||||||
|
|
@ -33,7 +33,7 @@ Be mindful when requesting the history, as the router might send a lot of messag
|
||||||
|
|
||||||
Initial requirements for the Store and Forward Router:
|
Initial requirements for the Store and Forward Router:
|
||||||
|
|
||||||
- Must be installed on a `ROUTER` or `ROUTER_CLIENT` node.
|
- Must be installed on a `ROUTER` node.
|
||||||
- This is an artificial limitation, but is in place to enforce best practices.
|
- This is an artificial limitation, but is in place to enforce best practices.
|
||||||
- Router nodes are intended to be always online. If this module misses any messages, the reliability of the stored messages will be reduced.
|
- Router nodes are intended to be always online. If this module misses any messages, the reliability of the stored messages will be reduced.
|
||||||
- ESP32 Processor based device with onboard PSRAM (T-Beam > v1.0, T3S3, and maybe others).
|
- ESP32 Processor based device with onboard PSRAM (T-Beam > v1.0, T3S3, and maybe others).
|
||||||
|
|
@ -41,12 +41,12 @@ Initial requirements for the Store and Forward Router:
|
||||||
### Usage Overview
|
### Usage Overview
|
||||||
|
|
||||||
- To use / test this you will want at least 3 devices
|
- To use / test this you will want at least 3 devices
|
||||||
- One ESP32 device with PSRAM configured as `ROUTER` or `ROUTER_CLIENT`.
|
- One ESP32 device with PSRAM configured as `ROUTER`.
|
||||||
- Two others will be regular clients. If one client sends a text message when the other is not in range, the other can request the history from the router to receive the missed message when it is back in range.
|
- Two others will be regular clients. If one client sends a text message when the other is not in range, the other can request the history from the router to receive the missed message when it is back in range.
|
||||||
|
|
||||||
### Router setup
|
### Router setup
|
||||||
|
|
||||||
- Configure your device as a `ROUTER` or `ROUTER_CLIENT`.
|
- Configure your device as a `ROUTER`.
|
||||||
- Name your router node something that makes it easily identifiable, aka "Router".
|
- Name your router node something that makes it easily identifiable, aka "Router".
|
||||||
- Configure the Store and Forward module
|
- Configure the Store and Forward module
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -31,6 +31,8 @@ Supported sensors connected to the I2C bus of the device will be automatically d
|
||||||
| SHTC3 | 0x70 | Temperature and humidity |
|
| SHTC3 | 0x70 | Temperature and humidity |
|
||||||
| SHT31 | 0x44 | Temperature and humidity |
|
| SHT31 | 0x44 | Temperature and humidity |
|
||||||
| PMSA003I| 0x12 | Concentration units by size and particle counts by size |
|
| PMSA003I| 0x12 | Concentration units by size and particle counts by size |
|
||||||
|
| PMSA003I| 0x12 | Concentration units by size and particle counts by size |
|
||||||
|
| DFROBOT_LARK | 0x42 | Temperature, barometric pressure, humidity, wind direction, wind speed |
|
||||||
|
|
||||||
## Module Config Values
|
## Module Config Values
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -12,7 +12,8 @@ The device config options are: Role, Serial Output, and Debug Log. Device config
|
||||||
|
|
||||||
## Device Config Values
|
## Device Config Values
|
||||||
|
|
||||||
### Roles
|
## Roles
|
||||||
|
|
||||||
| Device Role | Description | Best Uses |
|
| Device Role | Description | Best Uses |
|
||||||
| -------------- | ------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
|
| -------------- | ------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
|
||||||
| CLIENT | App connected or stand alone messaging device. | General use for individuals needing to communicate over the Meshtastic network with support for client applications. |
|
| CLIENT | App connected or stand alone messaging device. | General use for individuals needing to communicate over the Meshtastic network with support for client applications. |
|
||||||
|
|
@ -25,37 +26,37 @@ The device config options are: Role, Serial Output, and Debug Log. Device config
|
||||||
| TAK_TRACKER | Enables automatic TAK PLI broadcasts and reduces routine broadcasts. | Standalone PLI integration with ATAK systems for communication in tactical or coordinated operations. |
|
| TAK_TRACKER | Enables automatic TAK PLI broadcasts and reduces routine broadcasts. | Standalone PLI integration with ATAK systems for communication in tactical or coordinated operations. |
|
||||||
| REPEATER | Infrastructure node for extending network coverage by relaying messages with minimal overhead. Not visible in Nodes list. | Best positioned in strategic locations to maximize the network's overall coverage. Device is not shown in topology. |
|
| REPEATER | Infrastructure node for extending network coverage by relaying messages with minimal overhead. Not visible in Nodes list. | Best positioned in strategic locations to maximize the network's overall coverage. Device is not shown in topology. |
|
||||||
| ROUTER | Infrastructure node for extending network coverage by relaying messages. Visible in Nodes list. | Best positioned in strategic locations to maximize the network's overall coverage. Device is shown in topology. |
|
| ROUTER | Infrastructure node for extending network coverage by relaying messages. Visible in Nodes list. | Best positioned in strategic locations to maximize the network's overall coverage. Device is shown in topology. |
|
||||||
| ROUTER_CLIENT | Combination of both ROUTER and CLIENT. Not for mobile devices. | Devices in a strategic position for priority routing that need to also serve as a standard CLIENT. |
|
|
||||||
|
|
||||||
#### Role Comparison
|
:::tip
|
||||||
|
Still not sure which role to use? Check out the [role configuration tips](/docs/configuration/tips/#roles)
|
||||||
|
:::
|
||||||
|
|
||||||
|
Looking for ROUTER_CLIENT? This role was deprecated in firmware 2.3.15. Learn more in the [2.3.15 release notes](https://github.com/meshtastic/firmware/releases/tag/v2.3.15.deb7c27)
|
||||||
|
|
||||||
|
### Role Comparison
|
||||||
|
|
||||||
This table shows the **default** values after selecting a preset. As always, individual settings can be adjusted after choosing a preset.
|
This table shows the **default** values after selecting a preset. As always, individual settings can be adjusted after choosing a preset.
|
||||||
|
|
||||||
| Device Role | BLE/WiFi/Serial | Screen Enabled | Power Consumption | Retransmit | Prioritized Routing | Visible in Nodes List |
|
| Device Role | BLE/WiFi/Serial | Screen Enabled | Power Consumption | Retransmit | Prioritized Routing | Visible in Nodes List |
|
||||||
| -------------- | --------------- | -------------- | ----------------- | ---------- | ------------------- | --------------------- |
|
| -------------- | --------------- | -------------- | ----------------- | -------------- | ------------------- | --------------------- |
|
||||||
| CLIENT | Yes | Yes | Regular | Yes | No | Yes |
|
| CLIENT | Yes | Yes | Regular | Yes | No | Yes |
|
||||||
| CLIENT_MUTE | Yes | Yes | Lowest | No | No | Yes |
|
| CLIENT_MUTE | Yes | Yes | Lowest | No | No | Yes |
|
||||||
| CLIENT_HIDDEN | Yes | Yes | Lowest | Local only | No | No |
|
| CLIENT_HIDDEN | Yes | Yes | Lowest | Local Only | No | No |
|
||||||
| TRACKER | Yes | No | Regular / Low | When awake | No | Yes |
|
| TRACKER | Yes | No | Regular / Low | Awake Only[^1] | No | Yes |
|
||||||
| LOST_AND_FOUND | Yes | No | Regular | Yes | No | Yes |
|
| LOST_AND_FOUND | Yes | No | Regular | Yes | No | Yes |
|
||||||
| SENSOR | Yes | No | Regular / Low | When awake | No | Yes |
|
| SENSOR | Yes | No | Regular / Low | Awake Only[^1] | No | Yes |
|
||||||
| TAK | Yes | Optional | Regular | Yes | No | Yes |
|
| TAK | Yes | Optional | Regular | Yes | No | Yes |
|
||||||
| TAK_TRACKER | Yes | Optional | Regular | Yes | No | Yes |
|
| TAK_TRACKER | Yes | Optional | Regular | Yes | No | Yes |
|
||||||
| ROUTER | No[^1] | No | High | Yes | Yes | Yes |
|
| ROUTER | No[^2] | No | High | Yes | Yes | Yes |
|
||||||
| ROUTER_CLIENT | Yes | Yes | Highest | Yes | Yes | Yes |
|
|
||||||
| REPEATER | Yes | No | High | Yes | Yes | No |
|
| REPEATER | Yes | No | High | Yes | Yes | No |
|
||||||
|
|
||||||
[^1]: The Router role enables [Power Saving](/docs/configuration/radio/power/#power-saving) by default. Consider ROUTER_CLIENT if BLE/WiFi/Serial are still needed.
|
[^1]: **Awake Only** indicates retransmissions will occur normally but not while asleep between transmission intervals.
|
||||||
|
|
||||||
:::info
|
[^2]: The `ROUTER` role enables [Power Saving](/docs/configuration/radio/power/#power-saving) by default (ESP32 only). When needing to update a `ROUTER` via BLE, it's recommended you utilize an admin channel to temporarily change the role in order to update and then revert when done.
|
||||||
|
|
||||||
Retransmit: *When awake* indicates retransmissions will occur normally but not while asleep between transmission intervals.
|
|
||||||
|
|
||||||
:::
|
|
||||||
|
|
||||||
## Notes about Power Saving + Role behavior
|
## Notes about Power Saving + Role behavior
|
||||||
|
|
||||||
For the ESP32 platform:
|
### ESP32 Platform Only
|
||||||
|
|
||||||
Every role except for the `TRACKER` and `SENSOR` roles are capable of traditional _sleep_ behavior using the `power.is_power_saving` setting. When a node goes to sleep, in general, the serial console, peripherals, GPS, and WiFi/Bluetooth radio are all shut down to conserve power. The CPU will enter a low power state (light sleep or deep sleep on the ESP32). The LoRA radio will be left on stand-by for receiving any packets which will _wake up_ the device to resume services and respond.
|
Every role except for the `TRACKER` and `SENSOR` roles are capable of traditional _sleep_ behavior using the `power.is_power_saving` setting. When a node goes to sleep, in general, the serial console, peripherals, GPS, and WiFi/Bluetooth radio are all shut down to conserve power. The CPU will enter a low power state (light sleep or deep sleep on the ESP32). The LoRA radio will be left on stand-by for receiving any packets which will _wake up_ the device to resume services and respond.
|
||||||
|
|
||||||
|
|
@ -63,50 +64,56 @@ Timeout configurations of `display.screen_on_secs` (Screen timeout), `power.min_
|
||||||
|
|
||||||
For the `ROUTER` role, the `power.is_power_saving` behavior of sleep is enabled automatically and cannot be turned off.
|
For the `ROUTER` role, the `power.is_power_saving` behavior of sleep is enabled automatically and cannot be turned off.
|
||||||
|
|
||||||
For the ESP32 and NRF52 platforms:
|
### ESP32 and NRF52 Platforms
|
||||||
|
|
||||||
In the `TRACKER` and `SENSOR` roles, there are special sleep behaviors when combined with `power.is_power_saving`. For `TRACKER`, the device will go to sleep for `position.position_broadcast_secs` and upon waking will send a position packet when the GPS provides a valid location and repeat the cycle. For `SENSOR`, the device will go to sleep for `telemetry.environment_update_interval` and upon waking will gather environment data and send a telemetry packet and repeat the cycle. For both of these roles, the LoRA radio does not remain in standby mode to accept packets and wake up the device. Sleep remains constrained to their respective transmission intervals.
|
In the `TRACKER` and `SENSOR` roles, there are special sleep behaviors when combined with `power.is_power_saving`. For `TRACKER`, the device will go to sleep for `position.position_broadcast_secs` and upon waking will send a position packet when the GPS provides a valid location and repeat the cycle. For `SENSOR`, the device will go to sleep for `telemetry.environment_update_interval` and upon waking will gather environment data and send a telemetry packet and repeat the cycle. For both of these roles, the LoRA radio does not remain in standby mode to accept packets and wake up the device. Sleep remains constrained to their respective transmission intervals.
|
||||||
|
|
||||||
### Rebroadcast Mode
|
## Rebroadcast Mode
|
||||||
|
|
||||||
This setting defines the device's behavior for how messages are rebroadcasted.
|
This setting defines the device's behavior for how messages are rebroadcasted.
|
||||||
|
|
||||||
| Value | Description |
|
| Value | Description |
|
||||||
|:-------------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
|
| :-----------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
|
||||||
| `ALL` | ALL (Default) - This setting will rebroadcast ALL messages from its primary mesh as well as other meshes with the same modem settings, including when encryption settings differ. |
|
| `ALL` | ALL (Default) - This setting will rebroadcast ALL messages from its primary mesh as well as other meshes with the same modem settings, including when encryption settings differ. |
|
||||||
| `ALL_SKIP_DECODING` | ALL_SKIP_DECODING - Same as behavior as ALL, but skips packet decoding and simply rebroadcasts them. **Only available with Repeater role.** |
|
| `ALL_SKIP_DECODING` | ALL_SKIP_DECODING - Same as behavior as ALL, but skips packet decoding and simply rebroadcasts them. **Only available with Repeater role.** |
|
||||||
| `LOCAL_ONLY` | LOCAL_ONLY - Ignores observed messages from foreign meshes that are open or those which it cannot decrypt. Only rebroadcasts message on the nodes local primary / secondary channels. |
|
| `LOCAL_ONLY` | LOCAL_ONLY - Ignores observed messages from foreign meshes that are open or those which it cannot decrypt. Only rebroadcasts message on the nodes local primary / secondary channels. |
|
||||||
| `KNOWN_ONLY` | KNOWN_ONLY - Ignores observed messages from foreign meshes like LOCAL_ONLY, but takes it a step further by also ignoring messages from nodenums not in the node's known list (NodeDB). |
|
| `KNOWN_ONLY` | KNOWN_ONLY - Ignores observed messages from foreign meshes like LOCAL_ONLY, but takes it a step further by also ignoring messages from nodenums not in the node's known list (NodeDB). |
|
||||||
|
|
||||||
### Serial Console
|
## Serial Console
|
||||||
|
|
||||||
Acceptable values: `true` or `false`
|
Acceptable values: `true` or `false`
|
||||||
|
|
||||||
Disabling this will disable the SerialConsole by not initializing the StreamAPI.
|
Disabling this will disable the SerialConsole by not initializing the StreamAPI.
|
||||||
|
|
||||||
### Debug Log
|
## TZDEF (Timezone Definition)
|
||||||
|
|
||||||
|
The `tzdef` setting allows the local offset to be defined for the device. It uses the TZ Database format to display the correct local time on the device display and in its logs.
|
||||||
|
|
||||||
|
To set the timezone, use the POSIX TZ Database string for the relevant region. Here is a list of [supported timezones](https://github.com/nayarsystems/posix_tz_db/blob/master/zones.csv).
|
||||||
|
|
||||||
|
## Debug Log
|
||||||
|
|
||||||
Acceptable values: `true` or `false`
|
Acceptable values: `true` or `false`
|
||||||
|
|
||||||
By default we turn off logging as soon as an API client connects. Set this to true to leave the debug log outputting even when API is active.
|
By default we turn off logging as soon as an API client connects. Set this to true to leave the debug log outputting even when API is active.
|
||||||
|
|
||||||
### GPIO for user button
|
## GPIO for user button
|
||||||
|
|
||||||
This is the GPIO pin number that will be used for the user button, if your device does not come with a predefined user button.
|
This is the GPIO pin number that will be used for the user button, if your device does not come with a predefined user button.
|
||||||
|
|
||||||
### GPIO for PWM Buzzer
|
## GPIO for PWM Buzzer
|
||||||
|
|
||||||
This is the GPIO pin number that will be used for the PWM buzzer, if your device does not come with a predefined buzzer.
|
This is the GPIO pin number that will be used for the PWM buzzer, if your device does not come with a predefined buzzer.
|
||||||
|
|
||||||
### Node Info Broadcast Seconds
|
## Node Info Broadcast Seconds
|
||||||
|
|
||||||
This is the number of seconds between NodeInfo message (containing i.a. long and short name) broadcasts from the device. The device will still respond ad-hoc to NodeInfo messages when a response is wanted. When the device hears any packet from a node it doesn't know yet, it will send its NodeInfo and ask for a response automatically.
|
This is the number of seconds between NodeInfo message (containing i.a. long and short name) broadcasts from the device. The device will still respond ad-hoc to NodeInfo messages when a response is wanted. When the device hears any packet from a node it doesn't know yet, it will send its NodeInfo and ask for a response automatically.
|
||||||
|
|
||||||
### Double Tap as Button Press
|
## Double Tap as Button Press
|
||||||
|
|
||||||
This option will enable a double tap, when a supported accelerometer is attached to the device, to be treated as a button press.
|
This option will enable a double tap, when a supported accelerometer is attached to the device, to be treated as a button press.
|
||||||
|
|
||||||
### Managed Mode
|
## Managed Mode
|
||||||
|
|
||||||
Enabling Managed mode will restrict access to all radio configurations via client applications. Radio configurations will only be accessible through the Admin channel. To avoid being locked out, make sure the Admin channel is working properly before enabling it.
|
Enabling Managed mode will restrict access to all radio configurations via client applications. Radio configurations will only be accessible through the Admin channel. To avoid being locked out, make sure the Admin channel is working properly before enabling it.
|
||||||
|
|
||||||
|
|
@ -157,7 +164,7 @@ All device config options are available in the python CLI. Example commands are
|
||||||
| Setting | Acceptable Values | Default |
|
| Setting | Acceptable Values | Default |
|
||||||
| --------------------------------- | ----------------------------------------------------------------------------------- | ----------------- |
|
| --------------------------------- | ----------------------------------------------------------------------------------- | ----------------- |
|
||||||
| device.debug_log_enabled | `true`, `false` | `false` |
|
| device.debug_log_enabled | `true`, `false` | `false` |
|
||||||
| device.role | `CLIENT`, `CLIENT_MUTE`, `ROUTER`, `ROUTER_CLIENT`, `REPEATER`, `TRACKER`, `SENSOR` | `CLIENT` |
|
| device.role | `CLIENT`, `CLIENT_MUTE`, `ROUTER`, `REPEATER`, `TRACKER`, `SENSOR` | `CLIENT` |
|
||||||
| device.rebroadcast_mode | `ALL`, `ALL_SKIP_DECODING`, `LOCAL_ONLY` | `ALL` |
|
| device.rebroadcast_mode | `ALL`, `ALL_SKIP_DECODING`, `LOCAL_ONLY` | `ALL` |
|
||||||
| device.serial_enabled | `true`, `false` | `true` |
|
| device.serial_enabled | `true`, `false` | `true` |
|
||||||
| device.button_gpio | `0` - `34` | `0` |
|
| device.button_gpio | `0` - `34` | `0` |
|
||||||
|
|
@ -184,6 +191,10 @@ meshtastic --set device.role CLIENT
|
||||||
meshtastic --set device.serial_enabled false
|
meshtastic --set device.serial_enabled false
|
||||||
```
|
```
|
||||||
|
|
||||||
|
```shell title="Set `tzdef`"
|
||||||
|
meshtastic --set device.tzdef UTC0
|
||||||
|
```
|
||||||
|
|
||||||
```shell title="Enable debug logging"
|
```shell title="Enable debug logging"
|
||||||
meshtastic --set device.debug_log_enabled true
|
meshtastic --set device.debug_log_enabled true
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -156,6 +156,8 @@ If you'd like to contribute information for your country, click the "Edit this p
|
||||||
| --- | --- | --- |
|
| --- | --- | --- |
|
||||||
| Taiwan | TW | |
|
| Taiwan | TW | |
|
||||||
| Thailand | TH | |
|
| Thailand | TH | |
|
||||||
|
| Türkiye | EU_868<br />EU_433 | [Mevzuat](https://www.mevzuat.gov.tr/mevzuat?MevzuatNo=15416&MevzuatTur=7&MevzuatTertip=5), [BTK Frekans Tahsisi](https://www.btk.gov.tr/uploads/pages/frekans-tahsisinden-muaf-telsiz-cihaz-sistemleri-olcutler-633d4ca68c0b1.pdf), [BTK Milli Frekans Planı](https://www.btk.gov.tr/uploads/pages/milli-frekans-plani-23012023.pdf) |
|
||||||
|
|
||||||
|
|
||||||
### U
|
### U
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -8,13 +8,24 @@ sidebar_position: 4
|
||||||
|
|
||||||
## Roles
|
## Roles
|
||||||
|
|
||||||
Leave your [ROLE](/docs/configuration/radio/device#roles) set to `CLIENT` unless you're sure another role would suit the node's purpose. All `CLIENT` nodes will "repeat" and "route" packets. Roles are for very specific applications so please [read the documentation](/docs/configuration/radio/device#roles) before changing your node's role.
|
It is strongly recommended to keep your [ROLE](/docs/configuration/radio/device#roles) set to `CLIENT`. Only change this if you have a specific, well-understood reason to do so.
|
||||||
|
|
||||||
:::info
|
### Why `CLIENT` is Recommended
|
||||||
|
|
||||||
Users report that the current implementation of the `ROUTER` role with bluetooth switched off causes instability. If you would like the functionality associated with this role, it is recommended you choose `ROUTER_CLIENT` until a firmware fix is issued.
|
- `CLIENT` nodes efficiently repeat and route packets as needed.
|
||||||
|
- They use smart delays for rebroadcasting, improving network stability.
|
||||||
|
|
||||||
:::
|
### Avoid `ROUTER`and `REPEATER`
|
||||||
|
|
||||||
|
Using `ROUTER` or `REPEATER` roles unnecessarily can cause serious network issues:
|
||||||
|
|
||||||
|
- Increased risk of packet collision.
|
||||||
|
- Reduced message delivery rates.
|
||||||
|
- Decreased effective network range due to unnecessary hop consumption.
|
||||||
|
|
||||||
|
These roles are for very specific applications. Before changing from `CLIENT`, carefully [review the documentation](/docs/configuration/radio/device#roles) to understand the implications. Additionally, coordinating this with your local community to ensure its impact is a positive one rather than a negative one.
|
||||||
|
|
||||||
|
Remember: A network of `CLIENT` nodes with a small number of well-placed `ROUTERS` is usually the most efficient and stable configuration.
|
||||||
|
|
||||||
## (Not) Sharing Your Location
|
## (Not) Sharing Your Location
|
||||||
|
|
||||||
|
|
@ -22,9 +33,17 @@ Telemetry is shared over your [PRIMARY channel](/docs/configuration/radio/channe
|
||||||
|
|
||||||
By default the PRIMARY channel's name is LongFast with the encryption key "AQ==" (Base64 equivalent of Hex 0x01). If this is left unchanged, your location will be shared with all nodes in range that are also using the default channel.
|
By default the PRIMARY channel's name is LongFast with the encryption key "AQ==" (Base64 equivalent of Hex 0x01). If this is left unchanged, your location will be shared with all nodes in range that are also using the default channel.
|
||||||
|
|
||||||
|
### Using Position Precision
|
||||||
|
|
||||||
|
Meshtastic now supports the ability to control the precision of location data sent over a particular channel.
|
||||||
|
|
||||||
|
The `position_precision` setting allows control of the level of precision for location data that is sent over a particular channel. This can be useful for privacy reasons, where obfuscating the exact location may be desired when sending position data over certain channels.
|
||||||
|
|
||||||
|
For detailed information on position precision settings and how to configure them, please refer to the [Position Precision documentation](/docs/configuration/radio/channels/#position-precision).
|
||||||
|
|
||||||
### Creating a Private Primary with Default Secondary
|
### Creating a Private Primary with Default Secondary
|
||||||
|
|
||||||
If you'd like to connect with other Meshtastic users but only share your location with trusted parties, you may create a private PRIMARY channel and use the defaults for a SECONDARY channel.
|
Alternatively, if you wish to only share your location with trusted parties, you may create a private PRIMARY channel and use the defaults for a SECONDARY channel.
|
||||||
|
|
||||||
1. Ensure you have not changed the LoRa [Modem Preset](/docs/configuration/radio/lora#modem-preset) from the default `unset` / `LONG_FAST`.
|
1. Ensure you have not changed the LoRa [Modem Preset](/docs/configuration/radio/lora#modem-preset) from the default `unset` / `LONG_FAST`.
|
||||||
2. On your PRIMARY channel, set anything you'd like for the channel's name and choose a random PSK.
|
2. On your PRIMARY channel, set anything you'd like for the channel's name and choose a random PSK.
|
||||||
|
|
@ -34,7 +53,7 @@ If you'd like to connect with other Meshtastic users but only share your locatio
|
||||||
### Default Primary Frequency Slots by Region
|
### Default Primary Frequency Slots by Region
|
||||||
|
|
||||||
| US | EU_433 | EU_868 | CN | JP | ANZ | KR | TW | RU | IN | NZ_865 | TH | UA_433 | UA_868 | MY_433 | MY_919 | SG_923 | LORA_24 |
|
| US | EU_433 | EU_868 | CN | JP | ANZ | KR | TW | RU | IN | NZ_865 | TH | UA_433 | UA_868 | MY_433 | MY_919 | SG_923 | LORA_24 |
|
||||||
|:--:|:------:|:------:|:--:|:--:|:---:|:--:|:--:|:--:|:--:|:------:|:--:|:------:|:------:|:------:|:------:|:------:|:-------:|
|
| :-: | :----: | :----: | :-: | :-: | :-: | :-: | :-: | :-: | :-: | :----: | :-: | :----: | :----: | :----: | :----: | :----: | :-----: |
|
||||||
| 20 | 4 | 1 | 36 | 20 | 20 | 12 | 16 | 2 | 4 | 4 | 16 | 6 | 2 | 4 | 16 | 4 | 6 |
|
| 20 | 4 | 1 | 36 | 20 | 20 | 12 | 16 | 2 | 4 | 4 | 16 | 6 | 2 | 4 | 16 | 4 | 6 |
|
||||||
|
|
||||||
To quickly test this configuration, find and scan your region's QR from [this repository](https://github.com/meshtastic/meshtastic/tree/master/static/img/configuration/qr-private-primary-example/). Remember to generate a new PSK for your private channel before sharing with your trusted nodes.
|
To quickly test this configuration, find and scan your region's QR from [this repository](https://github.com/meshtastic/meshtastic/tree/master/static/img/configuration/qr-private-primary-example/). Remember to generate a new PSK for your private channel before sharing with your trusted nodes.
|
||||||
|
|
@ -44,9 +63,13 @@ To quickly test this configuration, find and scan your region's QR from [this re
|
||||||
Meshtastic nodes will rebroadcast all packets if they share [LoRa modem settings](/docs/configuration/radio/lora#lora-config-values), regardless of encryption (unless [Rebroadcast mode](/docs/configuration/radio/device#rebroadcast-mode) is set to `LOCAL_ONLY`).
|
Meshtastic nodes will rebroadcast all packets if they share [LoRa modem settings](/docs/configuration/radio/lora#lora-config-values), regardless of encryption (unless [Rebroadcast mode](/docs/configuration/radio/device#rebroadcast-mode) is set to `LOCAL_ONLY`).
|
||||||
|
|
||||||
:::info
|
:::info
|
||||||
If you would like your nodes to include/expand the "public" mesh, you must use the default [modem preset](/docs/configuration/radio/lora#modem-preset) `LONG_FAST`. If you change your PRIMARY channel name, you must manually set the LoRa channel to the default for your region (see above).
|
If you would like your nodes to include/expand the "public" mesh, you must use the default [modem preset](/docs/configuration/radio/lora#modem-preset) `LONG_FAST`. If you change your PRIMARY channel name, you must manually set the LoRa channel to the default for your region (see above).
|
||||||
:::
|
:::
|
||||||
|
|
||||||
|
### Hop Count
|
||||||
|
|
||||||
|
It is **strongly** recommended to leave your [MAX HOPS](/docs/configuration/radio/lora#max-hops) set to 3 unless you're sure you need more (or less) to reach your destination node. Unnecessarily high hop counts often lead to network issues.
|
||||||
|
|
||||||
## Chat Channels and LoRa Frequency Slots
|
## Chat Channels and LoRa Frequency Slots
|
||||||
|
|
||||||
Previously, Meshtastic used the word "channels" to define two different configuration properties: Messaging Channels & LoRa Channel Numbers. However, this could lead to confusion since "channels" was being used to refer to two distinct concepts. To clarify the distinction, the decision was made to change "LoRa Channel Number" to "LoRa Frequency Slot".
|
Previously, Meshtastic used the word "channels" to define two different configuration properties: Messaging Channels & LoRa Channel Numbers. However, this could lead to confusion since "channels" was being used to refer to two distinct concepts. To clarify the distinction, the decision was made to change "LoRa Channel Number" to "LoRa Frequency Slot".
|
||||||
|
|
@ -62,8 +85,7 @@ There are 8 total messaging channels. Channel 0 is your PRIMARY channel, with ch
|
||||||
This property, formerly known as "LoRa Channel Number", configures the frequency the radio is set to. Check out the [frequency calculator](/docs/overview/radio-settings#frequency-slot-calculator) to view the relationship between "frequency slot" and radio frequency.
|
This property, formerly known as "LoRa Channel Number", configures the frequency the radio is set to. Check out the [frequency calculator](/docs/overview/radio-settings#frequency-slot-calculator) to view the relationship between "frequency slot" and radio frequency.
|
||||||
|
|
||||||
## Best Practices
|
## Best Practices
|
||||||
|
|
||||||
- If you are part of a large mesh and don't know what a setting does, don't change it (unless you're super curious).
|
- If you are part of a large mesh and don't know what a setting does, don't change it (unless you're super curious).
|
||||||
- Leave your [MAX HOPS](/docs/configuration/radio/lora#max-hops) set to 3 unless you're sure you need more (or less) to reach your destination node.
|
|
||||||
- TEST your settings and hardware before you install in hard-to-reach locations.
|
- TEST your settings and hardware before you install in hard-to-reach locations.
|
||||||
- Connecting a node to the [public MQTT server](/docs/configuration/module/mqtt#connect-to-the-default-public-server) may publish the locations of all nodes in your mesh to the internet. This will also add every globally connected node to your node database and potentially flood your mesh with all types of packets.
|
- Connecting a node to the [public MQTT server](/docs/configuration/module/mqtt#connect-to-the-default-public-server) may publish the locations of all nodes in your mesh to the internet. This will also add every globally connected node to your node database and potentially flood your mesh with all types of packets.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -78,6 +78,15 @@ read,notify,write
|
||||||
fromnum - the current packet # in the message waiting inside fromradio, if the phone sees this notify it should read messages
|
fromnum - the current packet # in the message waiting inside fromradio, if the phone sees this notify it should read messages
|
||||||
until it catches up with this number.
|
until it catches up with this number.
|
||||||
|
|
||||||
|
6c6fd238-78fa-436b-aacf-15c5be1ef2e3
|
||||||
|
notify
|
||||||
|
A log message as LogRecord protobuf. Clients are encouraged to listen for this notification and give the option of logging these
|
||||||
|
debug messages.
|
||||||
|
|
||||||
|
6c6fd238-78fa-436b-aacf-15c5be1ef2e2
|
||||||
|
notify
|
||||||
|
A raw log message as a string (with a newline). This characteristic is DEPRECATED and shouldn't be used on new client code.
|
||||||
|
|
||||||
The phone can write to this register to go backwards up to FIXME packets, to handle the rare case of a fromradio packet was dropped after the ESP32 callback was called, but before it arrives at the phone. If the phone writes to this register the ESP32 will discard older packets and put the next packet >= fromnum in fromradio.
|
The phone can write to this register to go backwards up to FIXME packets, to handle the rare case of a fromradio packet was dropped after the ESP32 callback was called, but before it arrives at the phone. If the phone writes to this register the ESP32 will discard older packets and put the next packet >= fromnum in fromradio.
|
||||||
When the ESP32 advances fromnum, it will delay doing the notify by 100ms, in the hopes that the notify will never actually need to be sent if the phone is already pulling from fromradio.
|
When the ESP32 advances fromnum, it will delay doing the notify by 100ms, in the hopes that the notify will never actually need to be sent if the phone is already pulling from fromradio.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -6,18 +6,24 @@ sidebar_label: Building
|
||||||
|
|
||||||
A python release consists of publishing the release to PyPi https://pypi.org/project/meshtastic/ as well as producing single-executable files that are downloadable from Github https://github.com/meshtastic/Meshtastic-python/releases.
|
A python release consists of publishing the release to PyPi https://pypi.org/project/meshtastic/ as well as producing single-executable files that are downloadable from Github https://github.com/meshtastic/Meshtastic-python/releases.
|
||||||
|
|
||||||
#### Pre-requisites
|
### Pre-requisites
|
||||||
|
|
||||||
No pre-requisites are needed locally to make a release. All builds are done via Github Actions currently.
|
No pre-requisites are needed locally to make a release. All builds are done via Github Actions currently.
|
||||||
|
|
||||||
To test/validate, you will need to run:
|
To test/validate, you will need to run:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
pip3 install -r requirements.txt
|
pip3 install poetry
|
||||||
pip install .
|
poetry install
|
||||||
```
|
```
|
||||||
|
|
||||||
#### Instructions
|
Note: we now use the [poetry](https://python-poetry.org/) package manager for building meshtastic. If you were familar with our
|
||||||
|
older 'venv' base instructions you can still access that mechanism by running "poetry shell" to open a shell with the (automatically
|
||||||
|
maintained) virtual environment activated.
|
||||||
|
|
||||||
|
This can be handy if you want to run the "meshtastic" command without installing the package globally.
|
||||||
|
|
||||||
|
### Instructions
|
||||||
|
|
||||||
- Update protobufs by running the "Update protobufs" workflow in Actions: https://github.com/meshtastic/Meshtastic-python/actions/workflows/update_protobufs.yml
|
- Update protobufs by running the "Update protobufs" workflow in Actions: https://github.com/meshtastic/Meshtastic-python/actions/workflows/update_protobufs.yml
|
||||||
|
|
||||||
|
|
@ -26,10 +32,10 @@ pip install .
|
||||||
connect one device to the serial port and run:
|
connect one device to the serial port and run:
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
pytest -m smoke1
|
poetry run pytest -m smoke1
|
||||||
```
|
```
|
||||||
|
|
||||||
- run unit tests: `pytest` (optional)
|
- run unit tests: `poetry run pytest` (optional)
|
||||||
|
|
||||||
- run bin/test-release.sh (optional)
|
- run bin/test-release.sh (optional)
|
||||||
|
|
||||||
|
|
@ -41,7 +47,7 @@ pytest -m smoke1
|
||||||
You need permissions in the GitHub project to make a build
|
You need permissions in the GitHub project to make a build
|
||||||
:::
|
:::
|
||||||
|
|
||||||
#### Instructions - automated
|
### Instructions - automated
|
||||||
|
|
||||||
- Go to Actions / Make Release / Run Workflow https://github.com/meshtastic/Meshtastic-gui-installer/actions/workflows/release.yml
|
- Go to Actions / Make Release / Run Workflow https://github.com/meshtastic/Meshtastic-gui-installer/actions/workflows/release.yml
|
||||||
- Draft & Publish release https://github.com/meshtastic/Meshtastic-gui-installer/releases
|
- Draft & Publish release https://github.com/meshtastic/Meshtastic-gui-installer/releases
|
||||||
|
|
|
||||||
|
|
@ -21,3 +21,6 @@ You may wish to perform a [Factory Erase](/docs/getting-started/flashing-firmwar
|
||||||
|
|
||||||
### Convert RAK4631-R to RAK4631
|
### Convert RAK4631-R to RAK4631
|
||||||
If your device did not come with the Arduino bootloader you will need to [perform the conversion](/docs/getting-started/flashing-firmware/nrf52/convert-rak4631r).
|
If your device did not come with the Arduino bootloader you will need to [perform the conversion](/docs/getting-started/flashing-firmware/nrf52/convert-rak4631r).
|
||||||
|
|
||||||
|
### Use Raspberry Pi as a SWDIO Flash Tool
|
||||||
|
If your device can't be flashed through USB or Bluetooth, another option might be a [direct SWDIO connection](/docs/getting-started/flashing-firmware/nrf52/swdio).
|
||||||
|
|
|
||||||
105
docs/getting-started/flashing-firmware/nrf52/swdio.mdx
Normal file
105
docs/getting-started/flashing-firmware/nrf52/swdio.mdx
Normal file
|
|
@ -0,0 +1,105 @@
|
||||||
|
---
|
||||||
|
id: swdio
|
||||||
|
title: SWDIO using a Raspberry Pi
|
||||||
|
sidebar_label: SWDIO using a Raspberry Pi
|
||||||
|
sidebar_position: 6
|
||||||
|
description: Instructions for uploading firmware through SWDIO by using a Raspberry Pi.
|
||||||
|
---
|
||||||
|
|
||||||
|
Most Meshtastic devices can be flashed simply using USB.
|
||||||
|
However, some (eg Seeed WM1110 Dev Kit) require the use of an external device that can connect via "SWDIO".
|
||||||
|
There are dedicated devices such as the [RAKDAP1](https://store.rakwireless.com/products/daplink-tool)
|
||||||
|
that can do this work. However, for many people a Raspberry Pi is more convenient.
|
||||||
|
|
||||||
|
This article provides instructions on how use a Raspberry Pi as a SWDIO Flash Tool.
|
||||||
|
|
||||||
|
## Set up Wiring
|
||||||
|
The first step is to connect two wires between your Raspberry Pi and the SWDIO ports on your NRF52-based device.
|
||||||
|
|
||||||
|
Connect GPIO pin 11 on your Raspbery Pi to the CLK pin on the Meshtastic Device.
|
||||||
|
Connect GPIO pin 8 on your Raspbery Pi to the DIO pin on the Meshtastic Device.
|
||||||
|
|
||||||
|
Ensure you get the GPIO numbers correct.
|
||||||
|
|
||||||
|
Plug in your Raspberry Pi to USB power.
|
||||||
|
Plug in the Meshtastic Device to power.
|
||||||
|
|
||||||
|
## Install OpenOCD
|
||||||
|
|
||||||
|
You can use OpenOCD to manage the SWDIO connection with the Meshtastic Device.
|
||||||
|
Install it on your Raspberry Pi.
|
||||||
|
|
||||||
|
```
|
||||||
|
$ sudo apt update
|
||||||
|
$ sudo apt install libtool autoconf automake texinfo telnet gdb-multiarch git
|
||||||
|
$ git clone git://repo.or.cz/openocd.git
|
||||||
|
$ cd openocd/
|
||||||
|
$ ./bootstrap
|
||||||
|
$ ./configure --enable-bcm2835gpio
|
||||||
|
$ make -j4
|
||||||
|
$ sudo make install
|
||||||
|
```
|
||||||
|
|
||||||
|
## Check connection
|
||||||
|
Let's try connecting to the NRF52-based device with SWDIO before we do anything with firmware.
|
||||||
|
All the configuration you need is in the openocd repository.
|
||||||
|
|
||||||
|
```
|
||||||
|
$ openocd -f ./openocd/tcl/interface/raspberrypi-native.cfg -c "transport select swd" -f openocd/tcl/target/nrf52.cfg -s tcl
|
||||||
|
```
|
||||||
|
|
||||||
|
The first flag selects the Raspberry Pi as your host machine, the transport is SWDIO, and the last flag says you are connecting to a nRF52-based chip.
|
||||||
|
You should see something like this:
|
||||||
|
|
||||||
|
```
|
||||||
|
Open On-Chip Debugger 0.12.0+dev-00633-gad87fbd1c
|
||||||
|
Licensed under GNU GPL v2
|
||||||
|
For bug reports, read
|
||||||
|
http://openocd.org/doc/doxygen/bugs.html
|
||||||
|
srst_only separate srst_gates_jtag srst_push_pull connect_deassert_srst
|
||||||
|
swd
|
||||||
|
Info : Listening on port 6666 for tcl connections
|
||||||
|
Info : Listening on port 4444 for telnet connections
|
||||||
|
Info : BCM2835 GPIO JTAG/SWD bitbang driver
|
||||||
|
Info : clock speed 100 kHz
|
||||||
|
Info : SWD DPIDR 0x2ba01477
|
||||||
|
Info : [nrf52.cpu] Cortex-M4 r0p1 processor detected
|
||||||
|
Info : [nrf52.cpu] target has 6 breakpoints, 4 watchpoints
|
||||||
|
Info : [nrf52.cpu] Examination succeed
|
||||||
|
Info : [nrf52.cpu] starting gdb server on 3333
|
||||||
|
Info : Listening on port 3333 for gdb connections
|
||||||
|
Info : accepting 'telnet' connection on tcp/4444
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
If you see “Error connecting DP: cannot read IDR”, then you've probably connected the wires to the wrong place.
|
||||||
|
|
||||||
|
## Obtaining Firmware
|
||||||
|
Check the instructions for your [hardware](/docs/hardware/devices) to find the correct firmware for your device.
|
||||||
|
For most devices following this guide, a .hex file is required.
|
||||||
|
Then, copy the firmware file to your Raspberry Pi.
|
||||||
|
|
||||||
|
|
||||||
|
## Flashing Firmware
|
||||||
|
Once you have openocd running, you can connect to your Meshtastic device using telnet.
|
||||||
|
Flashing is as simple as running a few commands inside the telnet session:
|
||||||
|
|
||||||
|
```
|
||||||
|
$ telnet 127.0.0.1 4444
|
||||||
|
Trying 127.0.0.1...
|
||||||
|
Connected to 127.0.0.1.
|
||||||
|
Escape character is '^]'.
|
||||||
|
Open On-Chip Debugger
|
||||||
|
> init
|
||||||
|
> reset init
|
||||||
|
> halt
|
||||||
|
> nrf5 mass_erase
|
||||||
|
> program firmware.hex verify
|
||||||
|
> reset
|
||||||
|
> exit 0
|
||||||
|
```
|
||||||
|
|
||||||
|
Unplug the power and plug it back in after flashing.
|
||||||
|
|
||||||
|
## Connecting
|
||||||
|
Congratulations, you should now be able to connect to your device through Bluetooth in the Meshtastic app.
|
||||||
24
docs/hardware/devices/chatter/buttons.mdx
Normal file
24
docs/hardware/devices/chatter/buttons.mdx
Normal file
|
|
@ -0,0 +1,24 @@
|
||||||
|
---
|
||||||
|
id: keypad
|
||||||
|
title: Chatter2 Hardware keypad
|
||||||
|
sidebar_label: Keypad
|
||||||
|
sidebar_position: 1
|
||||||
|
---
|
||||||
|
|
||||||
|
## Functionality
|
||||||
|
|
||||||
|
The layout is the one printed on the Chatter sticker
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Each button can be pressed up to 4 times in quick succession to access the second third and fourth character listed under it.
|
||||||
|
The shift button cycle between lower case letters, upper case, and numbers.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
The top/left button (labelled UP/LEFT) is assigned to UP and allows the user to access preregistered canned messages (SELECT to send and CANCEL to go back).
|
||||||
|
The next button (labelled DOWN/RIGHT) is assigned to RIGHT.
|
||||||
|
The BACKSPACE button is assigned to the TAB function when SHIFT has been pressed once.
|
||||||
|
To select a destination, use the TAB button (press SHIFT once then BACKSPACE) to highlight the destination field. Then use the RIGHT key to cycle through available destinations. (Press SHIFT again to return the first function of each key)
|
||||||
|
|
||||||
|
Simply starting to type a text using the letter key will automatically open a free text input panel and allow the user to write the message to send using the SELECT key.
|
||||||
48
docs/hardware/devices/chatter/index.mdx
Normal file
48
docs/hardware/devices/chatter/index.mdx
Normal file
|
|
@ -0,0 +1,48 @@
|
||||||
|
---
|
||||||
|
id: chatter
|
||||||
|
title: Chatter device
|
||||||
|
sidebar_label: Chatter
|
||||||
|
sidebar_position: 14
|
||||||
|
---
|
||||||
|
|
||||||
|
The Chatter is a DIY kit sold by CircuitMess. It is intended as a STEM toy and comes with a nice firmware allowing to connect to other Chatter and exchange messages.
|
||||||
|
However, it's HW is similar to most Meshtastic nodes, with an ESP32, a LoRa chip, a screen and few buttons.
|
||||||
|
|
||||||
|
There's two versions of the Chatter available with very few actual differences.
|
||||||
|
Chatter V2.0 sports:
|
||||||
|
- one button (Button 15) wired directly to the ESP32 (pin 36)
|
||||||
|
- an i2c port to easily connect a GPS
|
||||||
|
- a different routing
|
||||||
|
|
||||||
|
Both versions are fully supported by Meshastic with the same firmware.
|
||||||
|
|
||||||
|
The Meshtastic firmware works with the stock hardware, however, the LLCC68 LoRa chip cripples the RF capability of the device. As is, the Chatter can only communicate on the Medium-Slow channel.
|
||||||
|
Switching the chip with the pin-compatible and more capable Heltec RA62 (as mentioned in this Github issue https://github.com/meshtastic/firmware/issues/2896) unlock the full potential of the device.
|
||||||
|
|
||||||
|
|
||||||
|
## Specifications
|
||||||
|
|
||||||
|
- **MCU**
|
||||||
|
- ESP32 WROOM (WiFi & Bluetooth)
|
||||||
|
- Bluetooth 4.2
|
||||||
|
- **LoRa Transceiver**
|
||||||
|
- LLCC68
|
||||||
|
- **Frequency options**
|
||||||
|
- EU-868 MHz
|
||||||
|
- **Keypad**
|
||||||
|
- 74HC165 based serial keypad
|
||||||
|
- **Connectors**
|
||||||
|
- USB-C
|
||||||
|
|
||||||
|
## Features
|
||||||
|
|
||||||
|
- Integrated Keypad for on device message input
|
||||||
|
- 1.3 inch OLED screen
|
||||||
|
- Optional I2C GPS Module
|
||||||
|
|
||||||
|
## Resources
|
||||||
|
|
||||||
|
- Firmware file: `firmware-chatter2-X.X.X.xxxxxxx.bin`
|
||||||
|
- [Official build guide](https://circuitmess.com/blogs/resources/chatter-build-guide)
|
||||||
|
|
||||||
|
|
||||||
11
docs/hardware/devices/heltec-sensor/buttons.mdx
Normal file
11
docs/hardware/devices/heltec-sensor/buttons.mdx
Normal file
|
|
@ -0,0 +1,11 @@
|
||||||
|
---
|
||||||
|
id: buttons
|
||||||
|
title: Heltec Sensor Hardware Buttons
|
||||||
|
sidebar_label: Buttons
|
||||||
|
sidebar_position: 1
|
||||||
|
---
|
||||||
|
|
||||||
|
## Capsule Sensor V3
|
||||||
|
|
||||||
|
- **Long press 3 seconds:** Power on or shutdown.
|
||||||
|
- **Long press 8/16 seconds:** Long press for 8~16 seconds in the shutdown state until the blue indicator lights up. At this time, the device enters the WirelessBoot mode, which can be used to upload firmware.
|
||||||
75
docs/hardware/devices/heltec-sensor/index.mdx
Normal file
75
docs/hardware/devices/heltec-sensor/index.mdx
Normal file
|
|
@ -0,0 +1,75 @@
|
||||||
|
---
|
||||||
|
id: heltec-sensors
|
||||||
|
title: Heltec® Plug&Play Sensors
|
||||||
|
sidebar_label: HELTEC® Sensors
|
||||||
|
sidebar_position: 7
|
||||||
|
---
|
||||||
|
|
||||||
|
import Tabs from "@theme/Tabs";
|
||||||
|
import TabItem from "@theme/TabItem";
|
||||||
|
|
||||||
|
<Tabs
|
||||||
|
groupId="heltec"
|
||||||
|
queryString="heltec"
|
||||||
|
defaultValue="v3.0"
|
||||||
|
values={[
|
||||||
|
{label: 'Capsule V3.0', value: 'v3.0'}
|
||||||
|
]}>
|
||||||
|
<TabItem value="v3.0">
|
||||||
|
|
||||||
|
## Heltec Capsule Sensor Rev. 3.0
|
||||||
|
|
||||||
|
- **MCU:**
|
||||||
|
- ESP32-S3FN8 (WiFi & Bluetooth)
|
||||||
|
- **LoRa Transceiver:**
|
||||||
|
- Semtech SX1262
|
||||||
|
- **Frequency Options:**
|
||||||
|
- 433 MHz
|
||||||
|
- 470 - 510 MHz
|
||||||
|
- 863 - 870 MHz
|
||||||
|
- 902 - 928 MHz
|
||||||
|
- **Connectors:**
|
||||||
|
- Magnetic suction interface
|
||||||
|
- Antenna:
|
||||||
|
- Dedicated 2.4 GHz SMT antenna for WiFi/Bluetooth
|
||||||
|
- Dedicated SMT antenna for LoRa
|
||||||
|
|
||||||
|
### How to upload firmware
|
||||||
|
|
||||||
|
:::info
|
||||||
|
Capsule Sensor V3 uses WirelessBoot mode to upload firmware, exchange information, and print logs through WiFi.
|
||||||
|
That is, whether you update the firmware locally or via the Web, You need to get the device into WirelssBoot state first.
|
||||||
|
:::
|
||||||
|
Refer to this link for how to upload firmware for Capsule Sensor V3: [**Wireless Boot**](https://docs.heltec.org/en/node/esp32/capsule_sensor_v3/wireless_boot.html#).
|
||||||
|
### Touch button/Physical button differences
|
||||||
|
|
||||||
|
:::warning
|
||||||
|
Because the touch button is easy to accidentally activate while close to metal or in your pocket, Heltec has discontinued production of this version. However, a small number of samples have entered the market.
|
||||||
|
:::
|
||||||
|
- Button differences
|
||||||
|
|
||||||
|
- Other hardware differences
|
||||||
|
1. Removal of [FDG6322C](https://www.mouser.com/datasheet/2/308/1/FDG6322C_D-2312203.pdf) (a dual N & P channel FET) from the physical-button version.
|
||||||
|
2. Antenna filter values physical-button version (L11 = 1.8pF, C15 = 2.7nH, C24 = 1.8pF) align more closely with ESP32-S3 reference design than touch-button version (L11 = 1.6nH, C15 = 6.9pF, C24 = 2.4pF).
|
||||||
|
|
||||||
|
### Features
|
||||||
|
- Meshtastic preinstalled.
|
||||||
|
- Built-in battery.
|
||||||
|
- Sensor replaceable.
|
||||||
|
|
||||||
|
### Pin
|
||||||
|
- Connector:
|
||||||
|
- Model name: [DF12NB(3.0)-10DS-0.5V(51)](https://resource.heltec.cn/download/Heltec%20Capsule%20Sensor%20V3/Connector.pdf)
|
||||||
|
- Pin:
|
||||||
|
|
||||||
|
- More pin definitions please refer [Schematic Diagram](https://resource.heltec.cn/download/Heltec%20Capsule%20Sensor%20V3/Capsule_Main_Esp32_Schematic_Diagram.pdf)
|
||||||
|
### Resources
|
||||||
|
- Firmware file: `firmware-heltec_capsule_sensor_v3-X.X.X.xxxxxx.bin`
|
||||||
|
- Purchase links
|
||||||
|
- International
|
||||||
|
- [Heltec](https://heltec.org/project/heltec-capsule-sensor-v3/)
|
||||||
|
- [AliExpress](https://www.aliexpress.us/item/3256805256690400.html)
|
||||||
|
|
||||||
|
</TabItem>
|
||||||
|
|
||||||
|
</Tabs>
|
||||||
51
docs/hardware/devices/heltec-sensor/peripherals.mdx
Normal file
51
docs/hardware/devices/heltec-sensor/peripherals.mdx
Normal file
|
|
@ -0,0 +1,51 @@
|
||||||
|
---
|
||||||
|
id: peripherals
|
||||||
|
title: Heltec Sensor Peripherals
|
||||||
|
sidebar_label: Peripherals
|
||||||
|
sidebar_position: 3
|
||||||
|
---
|
||||||
|
|
||||||
|
import Tabs from "@theme/Tabs";
|
||||||
|
import TabItem from "@theme/TabItem";
|
||||||
|
|
||||||
|
<Tabs
|
||||||
|
groupId="heltec"
|
||||||
|
queryString="heltec"
|
||||||
|
defaultValue="capsule-sensor-v3"
|
||||||
|
values={[
|
||||||
|
{label: 'Capsule Sensor V3', value: 'capsule-sensor-v3'},
|
||||||
|
]}>
|
||||||
|
<TabItem value="capsule-sensor-v3">
|
||||||
|
|
||||||
|
## Capsule Sensor V3
|
||||||
|
|
||||||
|
### Introduction
|
||||||
|
Strong extensibility is an important feature of Capsule Sensor V3. By replacing the sensor module at the bottom of the device, the device can be flexibly used in various occasions.
|
||||||
|
|
||||||
|
:::warning
|
||||||
|
Different sensors may require different firmware versions, and the current version is based on the GNSS version. We will update the other firmware as soon as possible.
|
||||||
|
:::
|
||||||
|
|
||||||
|
### Heltec sensor type
|
||||||
|
:::info
|
||||||
|
Each Capsule Sensor V3 comes with a sensor module by default when you buy it, you just need to choose it at the time of purchase. You can also purchase other sensors which is Capsule Sensor V3 from Heltec, and we will continue to expand the variety of these sensors.
|
||||||
|
:::
|
||||||
|
- GNSS: [Quectel_L76K_V1](https://resource.heltec.cn/download/Heltec%20Capsule%20Sensor%20V3/Quectel_L76K_V1.1-1.pdf)
|
||||||
|
- Temperature&Humidity: [GXHTC3_EN_V2.4](https://heltec.org/project/temp-humi-sensor/)
|
||||||
|
- 3-Axis: [DA217](https://heltec.org/project/3-axis-acceleration-sensor/)
|
||||||
|
- Atmospheric pressure sensor: [BMP280](https://heltec.org/project/atmospheric-pressure-sensor/)
|
||||||
|
|
||||||
|
### Sensor module replacement step
|
||||||
|
|
||||||
|
1. Shutdown of device.
|
||||||
|
2. Remove the bottom screw of the device and remove the back cover.
|
||||||
|
3. Gently remove the old module.
|
||||||
|
4. Plug in the new sensors.
|
||||||
|
5. Close the cap and return the screw. If the firmware is not compatible, download a new one.
|
||||||
|
:::warning
|
||||||
|
Be careful not to screw too hard, otherwise it will damage the plastic structure. Also note the direction of the charging interface.
|
||||||
|
:::
|
||||||
|
|
||||||
|
</TabItem>
|
||||||
|
</Tabs>
|
||||||
|
|
||||||
|
|
@ -168,3 +168,13 @@ All-in-one development device with LoRa, WiFi, BT, touchscreen, accelerometer, g
|
||||||
| Name | MCU | Radio | WiFi | BT | GPS |
|
| Name | MCU | Radio | WiFi | BT | GPS |
|
||||||
| :------------------- | :--------------- | :----- | :--: | :-: | :-: |
|
| :------------------- | :--------------- | :----- | :--: | :-: | :-: |
|
||||||
| [unPhone](./unPhone) | ESP32-S3-WROOM-1 | RF950W | YES | 5.0 | NO |
|
| [unPhone](./unPhone) | ESP32-S3-WROOM-1 | RF950W | YES | 5.0 | NO |
|
||||||
|
|
||||||
|
### [Seeed Wio-WM1110](./seeed-wm1110)
|
||||||
|
|
||||||
|
nRF52840-based development boards with GPS, and multiple ports to attach sensors.
|
||||||
|
|
||||||
|
| Name | MCU | Radio | WiFi | BT | GPS |
|
||||||
|
| :--------------------------------------------------------- | :------- | :----- | :--: | :-: | :-: |
|
||||||
|
| [Seeed Wio-WM1110 Dev Kit](./seeed-wm1110?wio-sdk-wm1110) | nRF52840 | LR1110 | YES | 5.3 | YES |
|
||||||
|
| [Seeed Wio Tracker 1110](./seeed-wm1110?wio-tracker-wm1110) | nRF52840 | LR1110 | YES | 5.3 | YES |
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -47,8 +47,9 @@ sudo apt install libgpiod-dev libyaml-cpp-dev libbluetooth-dev
|
||||||
sudo apt install openssl libssl-dev libulfius-dev liborcania-dev
|
sudo apt install openssl libssl-dev libulfius-dev liborcania-dev
|
||||||
```
|
```
|
||||||
|
|
||||||
- The .deb Package is available as part of the release, installing the binary, a systemd service, and a config file. It is compiled for Debian Bookworm and incompatible with Bullseye.
|
- The .deb Package is available as [part of the release](https://github.com/meshtastic/firmware/releases/latest), installing the binary, a systemd service, and a config file. It is compiled for Debian Bookworm and incompatible with Bullseye.
|
||||||
```shell
|
```shell
|
||||||
|
wget https://github.com/meshtastic/firmware/releases/download/v{version}/meshtasticd_{version}_arm64.deb
|
||||||
sudo apt install ./meshtasticd_{version}arm64.deb
|
sudo apt install ./meshtasticd_{version}arm64.deb
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
|
||||||
105
docs/hardware/devices/seeed-wm1110/index.mdx
Normal file
105
docs/hardware/devices/seeed-wm1110/index.mdx
Normal file
|
|
@ -0,0 +1,105 @@
|
||||||
|
---
|
||||||
|
id: seeed-wm1110
|
||||||
|
title: Seeed Wio-WM1100
|
||||||
|
sidebar_label: Seeed Wio-WM1100
|
||||||
|
sidebar_position: 15
|
||||||
|
---
|
||||||
|
|
||||||
|
import Tabs from "@theme/Tabs";
|
||||||
|
import TabItem from "@theme/TabItem";
|
||||||
|
|
||||||
|
|
||||||
|
<Tabs
|
||||||
|
groupId="wm1110"
|
||||||
|
queryString="wm1110"
|
||||||
|
defaultValue="wio-tracker-wm1110"
|
||||||
|
values={[
|
||||||
|
{label: 'WM110 Dev Kit', value:'wio-sdk-wm1110'},
|
||||||
|
{label: 'Wio Tracker 1110', value: 'wio-tracker-wm1110'},
|
||||||
|
]}>
|
||||||
|
|
||||||
|
<TabItem value="wio-sdk-wm1110">
|
||||||
|
|
||||||
|
## Seeed Wio-WM1110 Dev Kit
|
||||||
|
|
||||||
|
:::note External GPS Required
|
||||||
|
The LR1110 GNSS functionality does not yet work. Seeed recommends at Grove - GPS (Air530).
|
||||||
|
:::
|
||||||
|
|
||||||
|
|
||||||
|
- **MCU**
|
||||||
|
- Nordic nRF52840 (WiFi & Bluetooth)
|
||||||
|
- **LoRa Transceiver**
|
||||||
|
- Semtech LR1110
|
||||||
|
- **Frequency options**
|
||||||
|
- 868 MHz
|
||||||
|
- 915 MHz
|
||||||
|
- 923 MHz
|
||||||
|
- **Navigation Module**
|
||||||
|
- Semtech LR1110
|
||||||
|
- **Connectors**
|
||||||
|
- USB-C
|
||||||
|
- LoRa Antenna: SMA antenna connector and U.FL/IPEX
|
||||||
|
- GNSS Antenna: RP-SMA antenna connector U.FL/IPEX
|
||||||
|
- NFC Antenna: U.FL/IPEX
|
||||||
|
- GPIO
|
||||||
|
- I2C x1
|
||||||
|
- UART x1
|
||||||
|
- Solar Panel
|
||||||
|
- SWDIO
|
||||||
|
|
||||||
|
|
||||||
|
### Features
|
||||||
|
|
||||||
|
- Temperature and Humidity Sensor (SHT41)
|
||||||
|
- 3-Axis Accelerometer(LIS3DHTR)
|
||||||
|
- Reset switch, power jumpers, 2 configurable buttons
|
||||||
|
- AAA Battery x3
|
||||||
|
- Screen sold separately
|
||||||
|
|
||||||
|
### Resources
|
||||||
|
|
||||||
|
- Firmware file: `firmware-wio-sdk-wm1110-X.X.X.xxxxxxx.bin`
|
||||||
|
- Purchase Links:
|
||||||
|
- International
|
||||||
|
- [Seeed Studio](https://www.seeedstudio.com/Wio-WM1110-Dev-Kit-p-5677.html)
|
||||||
|
|
||||||
|
</TabItem>
|
||||||
|
|
||||||
|
<TabItem value="wio-tracker-wm1110">
|
||||||
|
|
||||||
|
## Wio Tracker 1110 Dev Kit for Meshtastic
|
||||||
|
|
||||||
|
- **MCU**
|
||||||
|
- Nordic nRF52840 (WiFi & Bluetooth)
|
||||||
|
- **LoRa Transceiver**
|
||||||
|
- Semtech LR1110
|
||||||
|
- **Frequency options**
|
||||||
|
- 868 MHz
|
||||||
|
- 915 MHz
|
||||||
|
- 923 MHz
|
||||||
|
- **Navigation Module**
|
||||||
|
- Semtech LR1110
|
||||||
|
- **Connectors**
|
||||||
|
- USB-C
|
||||||
|
- LoRa Antenna: on-board and U.FL/IPEX
|
||||||
|
- GNSS Antenna: on-board and U.FL/IPEX
|
||||||
|
- Grove connectors: ADC x1, I2C x1, UART x1, Digital x3
|
||||||
|
|
||||||
|
|
||||||
|
### Features
|
||||||
|
|
||||||
|
- Temperature and Humidity Sensor (SHT41)
|
||||||
|
- 3-Axis Accelerometer(LIS3DHTR)
|
||||||
|
- Reset switch, power jumpers
|
||||||
|
- Screen sold separately
|
||||||
|
|
||||||
|
### Resources
|
||||||
|
|
||||||
|
- Firmware file: `firmware-wio-tracker-wm1110-X.X.X.xxxxxxx.bin`
|
||||||
|
- Purchase Links:
|
||||||
|
- International
|
||||||
|
- [Seeed Studio](https://www.seeedstudio.com/Wio-Tracker-1110-Dev-Kit-for-Meshtastic.html)
|
||||||
|
|
||||||
|
</TabItem>
|
||||||
|
</Tabs>
|
||||||
|
|
@ -87,14 +87,14 @@ 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.
|
- "`channel`" is the channel index this message was received on.
|
||||||
- "`from`" is the unique node number of the node on the mesh that sent this message.
|
- "`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 user ID of the node that sent it, which is currently just the hexadecimal representation of the node number.
|
- "`id`" inside the payload of a `NODEINFO_APP` message is the hexadecimal Node ID (sometimes called User ID) of the node that sent it.
|
||||||
- "`hardware`" is the [hardware model](https://github.com/meshtastic/protobufs/blob/master/meshtastic/mesh.proto#L215) of the node sending the `NODEINFO_APP` message.
|
- "`hardware`" is the [hardware model](https://github.com/meshtastic/protobufs/blob/master/meshtastic/mesh.proto#L215) of the node sending the `NODEINFO_APP` message.
|
||||||
- "`longname`" is the long name of the device that sent the `NODEINFO_APP` message.
|
- "`longname`" is the long name of the device that sent the `NODEINFO_APP` message.
|
||||||
- "`shortname`" is the short name of the device that sent the `NODEINFO_APP` message.
|
- "`shortname`" is the short name of the device that sent the `NODEINFO_APP` message.
|
||||||
- "`sender`" is the user ID of the gateway device, which is in this case the same node that sent the `NODEINFO_APP` message (the hexadecimal value `7efeee00` represented by an integer in decimal is `2130636288`).
|
- "`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.
|
- "`timestamp`" is the Unix Epoch when the message was received, represented as an integer in decimal.
|
||||||
- "`to`" is the node number 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.
|
- "`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.
|
||||||
|
|
@ -103,12 +103,18 @@ If the message received contains valid JSON in the payload, the JSON is deserial
|
||||||
|
|
||||||
|
|
||||||
#### JSON downlink to instruct a node to send a message
|
#### JSON downlink to instruct a node to send a message
|
||||||
You can also send a JSON message to the topic `msh/2/json/mqtt/` to instruct a gateway node to send a message to the mesh. Note that the channel you publish it on **must** be called "mqtt". The JSON message should contain the following fields:
|
You can also send a JSON message to the topic `msh/2/json/mqtt/` to instruct a gateway node to send a message to the mesh.
|
||||||
|
|
||||||
|
To make this work, ensure that your node has a Meshtastic channel configured called "mqtt". Enable Downlink. The PSK can be random and doesn't matter. This channel allows the node to listen to messages on the `msh/2/json/mqtt/` topic.
|
||||||
|
|
||||||
|
Reboot your device after creating this channel.
|
||||||
|
|
||||||
|
The JSON message should contain the following fields:
|
||||||
|
|
||||||
```json
|
```json
|
||||||
{
|
{
|
||||||
"from": <node number of MQTT node>,
|
"from": <decimal Node ID of MQTT node>,
|
||||||
"to": <node number of recipient for a DM (optional)>,
|
"to": <decimal Node ID of recipient for a DM (optional)>,
|
||||||
"channel": <channel index (optional)>,
|
"channel": <channel index (optional)>,
|
||||||
"type": "type",
|
"type": "type",
|
||||||
"payload": {
|
"payload": {
|
||||||
|
|
@ -118,7 +124,7 @@ You can also send a JSON message to the topic `msh/2/json/mqtt/` to instruct a g
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
`from` and `payload` fields are required for a valid envelope (note that in firmware <2.2.20 a field `sender` was required, but this is no longer the case). The `from` field should be equal to the node number of the node that will transmit the message. Optionally, you can specify a different channel than the primary channel by setting the `channel` field to a channel index (0-7). Furthermore, you can send a direct message by setting the `to` field to the node number of the destination. If the `to` field is not set, the message will be broadcast to all nodes on the mesh.
|
`from` and `payload` fields are required for a valid envelope (note that in firmware <2.2.20 a field `sender` was required, but this is no longer the case). The `from` field should be equal to the decimal Node ID of the node that will transmit the message. If the Node ID (sometimes called User ID) is !7efeee00, then the decimal equivalent would be 2130636288. Optionally, you can specify a different channel than the primary channel by setting the `channel` field to a channel index (0-7). Furthermore, you can send a direct message by setting the `to` field to the decimal Node ID of the destination. If the `to` field is not set, the message will be broadcast to all nodes on the mesh.
|
||||||
|
|
||||||
Currently two types of messages are supported: `"sendtext"` and `"sendposition"`.
|
Currently two types of messages are supported: `"sendtext"` and `"sendposition"`.
|
||||||
For the type `sendtext`, the `payload` should be a string containing the text to send. For the type `sendposition`, the payload should be an object with the fields `latitude_i`, `longitude_i`, `altitude` (optional) and `time` (optional).
|
For the type `sendtext`, the `payload` should be a string containing the text to send. For the type `sendposition`, the payload should be an object with the fields `latitude_i`, `longitude_i`, `altitude` (optional) and `time` (optional).
|
||||||
|
|
|
||||||
|
|
@ -8,7 +8,43 @@ sidebar_position: 4
|
||||||
|
|
||||||
The python pip package installs a "meshtastic" command line executable, which displays packets sent over the network as JSON and lets you see serial debugging information from the meshtastic devices. This command is not run inside of python, you run it from your operating system shell prompt directly. If when you type "meshtastic" it doesn't find the command and you are using Windows: Check that the python "scripts" directory is in your path.
|
The python pip package installs a "meshtastic" command line executable, which displays packets sent over the network as JSON and lets you see serial debugging information from the meshtastic devices. This command is not run inside of python, you run it from your operating system shell prompt directly. If when you type "meshtastic" it doesn't find the command and you are using Windows: Check that the python "scripts" directory is in your path.
|
||||||
|
|
||||||
## Optional Arguments
|
## Connection Arguments
|
||||||
|
|
||||||
|
### --port PORT
|
||||||
|
|
||||||
|
The port the Meshtastic device is connected to, i.e. `/dev/ttyUSB0`, `/dev/cu.wchusbserial`, `COM4` etc. if unspecified, meshtastic will try to find it. Important to use when multiple devices are connected to ensure you call the command for the correct device.
|
||||||
|
|
||||||
|
This argument can also be specified as `--serial` or `-s`.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --port /dev/ttyUSB0 --info
|
||||||
|
meshtastic --port COM4 --info
|
||||||
|
meshtastic -s --info
|
||||||
|
```
|
||||||
|
|
||||||
|
### --host HOST
|
||||||
|
|
||||||
|
The hostname/ipaddr of the device to connect to (over TCP). If a host is not provided, the CLI will try to connect to `localhost`.
|
||||||
|
|
||||||
|
This argument can also be specified as `--tcp` or `-t`.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --host meshtastic.local --info
|
||||||
|
meshtastic --host --info
|
||||||
|
```
|
||||||
|
|
||||||
|
### --ble BLE
|
||||||
|
|
||||||
|
Connect to a Meshtastic device using its BLE address or name. This option allows for wireless communication with the device, similar to how the `--host` option is used for TCP connections. If an address is not provided, meshtastic will try to find a compatible device that's paired.
|
||||||
|
|
||||||
|
This argument can also be specified as `-b`.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --ble "device_name_or_address" --info
|
||||||
|
meshtastic -b --info
|
||||||
|
```
|
||||||
|
|
||||||
|
## Help & Support Arguments
|
||||||
|
|
||||||
### -h or --help
|
### -h or --help
|
||||||
|
|
||||||
|
|
@ -17,6 +53,25 @@ Shows a help message that describes the arguments.
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic -h
|
meshtastic -h
|
||||||
```
|
```
|
||||||
|
|
||||||
|
### --version
|
||||||
|
|
||||||
|
Show program's version number and exit.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --version
|
||||||
|
```
|
||||||
|
|
||||||
|
### --support
|
||||||
|
|
||||||
|
Print out info that would be helpful supporting any issues.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --support
|
||||||
|
```
|
||||||
|
|
||||||
|
## Optional Arguments
|
||||||
|
|
||||||
### --export-config
|
### --export-config
|
||||||
|
|
||||||
Export the configuration of the device. (to be consumed by the '--configure' command).
|
Export the configuration of the device. (to be consumed by the '--configure' command).
|
||||||
|
|
@ -27,10 +82,6 @@ To create to a file with the connected device's configuration, this command's ou
|
||||||
meshtastic --export-config > example_config.yaml
|
meshtastic --export-config > example_config.yaml
|
||||||
```
|
```
|
||||||
|
|
||||||
```title="Usage"shell
|
|
||||||
meshtastic --export-config
|
|
||||||
```
|
|
||||||
|
|
||||||
### --configure
|
### --configure
|
||||||
|
|
||||||
Configure radio using a yaml file.
|
Configure radio using a yaml file.
|
||||||
|
|
@ -39,29 +90,13 @@ Configure radio using a yaml file.
|
||||||
meshtastic --configure example_config.yaml
|
meshtastic --configure example_config.yaml
|
||||||
```
|
```
|
||||||
|
|
||||||
### --port PORT
|
|
||||||
|
|
||||||
The port the Meshtastic device is connected to, i.e. `/dev/ttyUSB0`, `/dev/cu.wchusbserial`, `COM4` etc. if unspecified, meshtastic will try to find it. Important to use when multiple devices are connected to ensure you call the command for the correct device.
|
|
||||||
|
|
||||||
```shell title="Usage"
|
|
||||||
meshtastic --port /dev/ttyUSB0 --info
|
|
||||||
meshtastic --port COM4 --info
|
|
||||||
```
|
|
||||||
|
|
||||||
### --host HOST
|
|
||||||
|
|
||||||
The hostname/ipaddr of the device to connect to (over TCP).
|
|
||||||
|
|
||||||
```shell title="Usage"
|
|
||||||
meshtastic --host HOST
|
|
||||||
```
|
|
||||||
|
|
||||||
### --seriallog SERIALLOG
|
### --seriallog SERIALLOG
|
||||||
|
|
||||||
Logs device serial output to either 'stdout', 'none' or a filename to append to.
|
Logs device serial output to either 'stdout', 'none' or a filename to append to. Defaults to 'stdout' if no filename is specified.
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --port /dev/ttyUSB0 --seriallog
|
meshtastic --port /dev/ttyUSB0 --seriallog
|
||||||
|
meshtastic -t meshtastic.local --seriallog log.txt
|
||||||
```
|
```
|
||||||
|
|
||||||
### --info
|
### --info
|
||||||
|
|
@ -114,12 +149,20 @@ meshtastic --nodes
|
||||||
|
|
||||||
### --qr
|
### --qr
|
||||||
|
|
||||||
Displays the QR code that corresponds to the current channel.
|
Displays the URL and QR code that corresponds to the current primary channel.
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --qr
|
meshtastic --qr
|
||||||
```
|
```
|
||||||
|
|
||||||
|
### --qr-all
|
||||||
|
|
||||||
|
Displays the URL and QR code that corresponds to all configured channels on the node.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --qr-all
|
||||||
|
```
|
||||||
|
|
||||||
### --get [config_section]
|
### --get [config_section]
|
||||||
|
|
||||||
Gets a preferences field.
|
Gets a preferences field.
|
||||||
|
|
@ -131,6 +174,12 @@ meshtastic --get lora
|
||||||
meshtastic --get lora.region
|
meshtastic --get lora.region
|
||||||
```
|
```
|
||||||
|
|
||||||
|
To see all valid values, pass an invalid value, such as `0`:
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --get 0
|
||||||
|
```
|
||||||
|
|
||||||
### --set [config_section].[option] [value]
|
### --set [config_section].[option] [value]
|
||||||
|
|
||||||
Sets a preferences field.
|
Sets a preferences field.
|
||||||
|
|
@ -143,15 +192,24 @@ meshtastic --set lora.region Unset
|
||||||
|
|
||||||
### --seturl SETURL
|
### --seturl SETURL
|
||||||
|
|
||||||
Set a channel URL.
|
Set the channel URL, which contains LoRa configuration plus the configuration of channels. Replaces your current configuration and channels completely.
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --seturl https://www.meshtastic.org/c/GAMiIE67C6zsNmlWQ-KE1tKt0fRKFciHka-DShI6G7ElvGOiKgZzaGFyZWQ=
|
meshtastic --seturl https://www.meshtastic.org/c/GAMiIE67C6zsNmlWQ-KE1tKt0fRKFciHka-DShI6G7ElvGOiKgZzaGFyZWQ=
|
||||||
```
|
```
|
||||||
|
|
||||||
|
### --pos-fields POS_FIELDS
|
||||||
|
|
||||||
|
Configure position fields to send with positions; can pass multiple values. With 0 values, list current settings.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --pos-fields
|
||||||
|
meshtastic --pos-fields ALTITUDE HEADING SPEED
|
||||||
|
```
|
||||||
|
|
||||||
### --ch-index CH_INDEX
|
### --ch-index CH_INDEX
|
||||||
|
|
||||||
Set the specified channel index.
|
Act on the specified channel index. Applies to options that configure channels (such as `--ch-set` and `--ch-del`) as well as options that send messages to the mesh (such as `--sendtext` and `--traceroute`).
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --ch-index 1 --ch-disable
|
meshtastic --ch-index 1 --ch-disable
|
||||||
|
|
@ -161,29 +219,35 @@ meshtastic --ch-index 1 --ch-disable
|
||||||
|
|
||||||
Add a secondary channel, you must specify a channel name.
|
Add a secondary channel, you must specify a channel name.
|
||||||
|
|
||||||
|
Incompatible with `--ch-index`. If you pass `--ch-add`, any subsequent `--ch-set` and other commands that use a channel will use the index of the newly-added channel.
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --ch-add testing-channel
|
meshtastic --ch-add testing-channel
|
||||||
```
|
```
|
||||||
|
|
||||||
### --ch-del
|
### --ch-del
|
||||||
|
|
||||||
Delete the ch-index channel.
|
Delete the channel specified by `--ch-index`.
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --ch-index 1 --ch-del
|
meshtastic --ch-index 1 --ch-del
|
||||||
```
|
```
|
||||||
|
|
||||||
### --ch-enable
|
### --ch-enable (deprecated)
|
||||||
|
|
||||||
Enable the specified channel.
|
This option is deprecated. Using `--ch-add` is preferred in order to ensure there are no gaps in the channel list.
|
||||||
|
|
||||||
|
Enable the channel specified by `--ch-index`.
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --ch-index 1 --ch-enable
|
meshtastic --ch-index 1 --ch-enable
|
||||||
```
|
```
|
||||||
|
|
||||||
### --ch-disable
|
### --ch-disable (deprecated)
|
||||||
|
|
||||||
Disable the specified channel.
|
This option is deprecated. Using `--ch-del` is preferred in order to ensure there are no gaps in the channel list.
|
||||||
|
|
||||||
|
Disable the channel specified by `--ch-index`.
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --ch-index 1 --ch-disable
|
meshtastic --ch-index 1 --ch-disable
|
||||||
|
|
@ -191,7 +255,7 @@ meshtastic --ch-index 1 --ch-disable
|
||||||
|
|
||||||
### --ch-set CH_SET CH_SET
|
### --ch-set CH_SET CH_SET
|
||||||
|
|
||||||
Set a channel parameter.
|
Set a channel parameter on the channel specified by `--ch-index`.
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --ch-set id 1234 --ch-index 0
|
meshtastic --ch-set id 1234 --ch-index 0
|
||||||
|
|
@ -255,7 +319,7 @@ meshtastic --ch-shortfast
|
||||||
|
|
||||||
### --set-owner SET_OWNER
|
### --set-owner SET_OWNER
|
||||||
|
|
||||||
Set device owner name.
|
Set device owner name, sometimes called the long name.
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --set-owner "MeshyJohn"
|
meshtastic --set-owner "MeshyJohn"
|
||||||
|
|
@ -271,7 +335,9 @@ meshtastic --set-owner-short "MJ"
|
||||||
|
|
||||||
### --set-ham SET_HAM
|
### --set-ham SET_HAM
|
||||||
|
|
||||||
Set licensed Ham ID and turn off encryption.
|
Set licensed Ham ID (by setting the owner name) and turn off encryption on the primary channel.
|
||||||
|
|
||||||
|
To disable Ham mode, use `--set-owner` and `--set-owner-short` to reset the owner names, and use `--seturl` or `--ch-set` commands to configure channels with the name and encryption you wish them to have. Or, use `--factory-reset` to reset to default settings.
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --set-ham KI1345
|
meshtastic --set-ham KI1345
|
||||||
|
|
@ -279,7 +345,9 @@ meshtastic --set-ham KI1345
|
||||||
|
|
||||||
### --dest DEST
|
### --dest DEST
|
||||||
|
|
||||||
The destination node id for any sent commands. Used for [Remote Node Administration](/docs/configuration/remote-admin)
|
The destination node id for any sent commands, if not passed to a command another way. Used for [Remote Node Administration](/docs/configuration/remote-admin).
|
||||||
|
|
||||||
|
On many shells, exclamation points trigger special behavior unless enclosed in single quotes.
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --dest '!28979058' --set-owner "MeshyJohn"
|
meshtastic --dest '!28979058' --set-owner "MeshyJohn"
|
||||||
|
|
@ -287,23 +355,16 @@ meshtastic --dest '!28979058' --set-owner "MeshyJohn"
|
||||||
|
|
||||||
### --sendtext SENDTEXT
|
### --sendtext SENDTEXT
|
||||||
|
|
||||||
Send a text message. Can specify a channel index ('--ch-index') or a destination ('--dest').
|
Send a text message. Can specify a channel index (`--ch-index`) and/or a destination (`--dest`).
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --sendtext "Hello Mesh!"
|
meshtastic --sendtext 'Hello Mesh!'
|
||||||
```
|
meshtastic --ch-index 1 --sendtext 'Hello secondary channel!'
|
||||||
|
|
||||||
### --sendping
|
|
||||||
|
|
||||||
Send a ping message (which requests a reply).
|
|
||||||
|
|
||||||
```shell title="Usage"
|
|
||||||
meshtastic --sendping
|
|
||||||
```
|
```
|
||||||
|
|
||||||
### --traceroute TRACEROUTE
|
### --traceroute TRACEROUTE
|
||||||
|
|
||||||
Traceroute from connected node to a destination. You need pass the destination ID as an argument. Only nodes that have the encryption key can be traced.
|
Traceroute from connected node to a destination. You need pass the destination ID as an argument, and may pass `--ch-index` to specify a channel. The node you are tracing must have the same channel configured, and only nodes that share the channel will identify themselves within the response. With recent enough firmware, other nodes may be included as `!ffffffff` but not with their actual ID.
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --traceroute '!ba4bf9d0'
|
meshtastic --traceroute '!ba4bf9d0'
|
||||||
|
|
@ -311,19 +372,27 @@ meshtastic --traceroute '!ba4bf9d0'
|
||||||
|
|
||||||
### --request-telemetry
|
### --request-telemetry
|
||||||
|
|
||||||
Request telemetry from a node. You need to pass the destination ID as an argument with '--dest'. For repeaters, the nodeNum is required.
|
Request telemetry from a node. You need to pass the destination ID as an argument with `--dest`. For repeaters, using the node's decimal ID may be more effective, but a hexadecimal ID should work as well.
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --request-telemetry --dest '!ba4bf9d0'
|
meshtastic --request-telemetry --dest '!ba4bf9d0'
|
||||||
meshtastic --request-telemetry --dest 1828779180
|
meshtastic --request-telemetry --dest 1828779180
|
||||||
```
|
```
|
||||||
|
|
||||||
### --ack
|
### --request-position
|
||||||
|
|
||||||
Used in combination with --sendtext to wait for an acknowledgment.
|
Request position from a node. You need to pass the destination ID as an argument with `--dest`.
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --sendtext "Hello Mesh!" --ack
|
meshtastic --request-position --dest '!ba4bf9d0' --ch-index 1
|
||||||
|
```
|
||||||
|
|
||||||
|
### --ack
|
||||||
|
|
||||||
|
Used in combination with `--sendtext` and other commands to wait for an acknowledgment. Not all commands will be able to return an acknowledgment. Best used for commands that specify a single destination node.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --sendtext 'Hello Mesh!' --dest '!28979058' --ack
|
||||||
```
|
```
|
||||||
|
|
||||||
### --reboot
|
### --reboot
|
||||||
|
|
@ -358,14 +427,128 @@ Tell the node to clear its list of nodes.
|
||||||
meshtastic --reset-nodedb
|
meshtastic --reset-nodedb
|
||||||
```
|
```
|
||||||
|
|
||||||
|
### --remove-node NODE
|
||||||
|
|
||||||
|
Tell the node to remove the specified node from the NodeDB.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --remove-node '!48759737'
|
||||||
|
```
|
||||||
|
|
||||||
### --reply
|
### --reply
|
||||||
|
|
||||||
Reply to received messages.
|
Listen for messages. When one is received, send a message to the primary channel repeating the message along with some information.
|
||||||
|
|
||||||
```shell title="Usage"
|
```shell title="Usage"
|
||||||
meshtastic --reply
|
meshtastic --reply
|
||||||
```
|
```
|
||||||
|
|
||||||
|
### --no-time
|
||||||
|
|
||||||
|
Suppress sending the current time to the mesh on startup. May improve reliability and startup time.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --port /dev/ttyUSB0 --no-time
|
||||||
|
```
|
||||||
|
|
||||||
|
### --no-nodes
|
||||||
|
|
||||||
|
Instruct the node to not send nodeinfo from the NodeDB on startup. Requires firmware of sufficient version. Commands that use node information may behave unpredictably, since that information will not be populated, but this can improve efficiency for commands that don't.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --no-nodes --no-time --sendtext "Firing off a quick message"
|
||||||
|
```
|
||||||
|
|
||||||
|
### --wait-to-disconnect WAIT_TO_DISCONNECT
|
||||||
|
|
||||||
|
After performing whatever actions are specified by other options, wait before disconnecting from the device. Some devices will reboot when the serial connection disconnects, so adding a wait time may improve reliability. Defaults to 5 seconds if not provided.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --set lora.channel_num 20 --wait-to-disconnect 10
|
||||||
|
```
|
||||||
|
|
||||||
|
### --setalt SETALT
|
||||||
|
|
||||||
|
Set device altitude (allows use without GPS), and enables fixed position mode.
|
||||||
|
|
||||||
|
Can only be used on locally-connected nodes and not along with `--dest`.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --setalt 120
|
||||||
|
```
|
||||||
|
|
||||||
|
### --setlat SETLAT
|
||||||
|
|
||||||
|
Set device latitude (allows use without GPS), and enables fixed position mode.
|
||||||
|
|
||||||
|
Can only be used on locally-connected nodes and not along with `--dest`.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --setlat 25.2
|
||||||
|
```
|
||||||
|
|
||||||
|
### --setlon SETLON
|
||||||
|
|
||||||
|
Set device longitude (allows use without GPS), and enables fixed position mode.
|
||||||
|
|
||||||
|
Can only be used on locally-connected nodes and not along with `--dest`.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --setlon -16.8
|
||||||
|
```
|
||||||
|
|
||||||
|
### --remove-position
|
||||||
|
|
||||||
|
Clear the node's currently set fixed position and disable fixed position mode.
|
||||||
|
|
||||||
|
Can only be used on locally-connected nodes and not along with `--dest`.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --remove-position
|
||||||
|
```
|
||||||
|
|
||||||
|
### --debug
|
||||||
|
|
||||||
|
Show API library debug log messages.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --debug --info
|
||||||
|
```
|
||||||
|
|
||||||
|
### --listen
|
||||||
|
|
||||||
|
Stay open and listen to the stream of protocol buffer messages. This option enables `--debug` even if it is not provided alongside this argument.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --listen
|
||||||
|
```
|
||||||
|
|
||||||
|
### --test
|
||||||
|
|
||||||
|
Run stress test against all connected Meshtastic devices.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --test
|
||||||
|
```
|
||||||
|
|
||||||
|
### --ble-scan
|
||||||
|
|
||||||
|
Scan for available Meshtastic devices using BLE. This command lists discoverable devices, providing a convenient method to identify devices for connection via BLE.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
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.
|
||||||
|
|
||||||
|
```shell title="Usage"
|
||||||
|
meshtastic --noproto
|
||||||
|
```
|
||||||
|
|
||||||
|
## Remote Hardware arguments
|
||||||
|
|
||||||
### --gpio-wrb GPIO_WRB GPIO_WRB
|
### --gpio-wrb GPIO_WRB GPIO_WRB
|
||||||
|
|
||||||
Set a particular GPIO # to 1 or 0.
|
Set a particular GPIO # to 1 or 0.
|
||||||
|
|
@ -390,90 +573,14 @@ Start watching a GPIO mask for changes.
|
||||||
meshtastic --port /dev/ttyUSB0 --gpio-watch 0x10 --dest '!28979058'
|
meshtastic --port /dev/ttyUSB0 --gpio-watch 0x10 --dest '!28979058'
|
||||||
```
|
```
|
||||||
|
|
||||||
### --no-time
|
## Tunnel arguments
|
||||||
|
|
||||||
Suppress sending the current time to the mesh.
|
### --tunnel
|
||||||
|
|
||||||
```shell title="Usage"
|
Linux only, very experimental. Low bandwidth and low reliability.
|
||||||
meshtastic --port /dev/ttyUSB0 --no-time
|
|
||||||
```
|
|
||||||
|
|
||||||
### --setalt SETALT
|
Create a TUN tunnel device for forwarding IP packets over the mesh.
|
||||||
|
|
||||||
Set device altitude (allows use without GPS).
|
## --subnet TUNNEL_NET
|
||||||
|
|
||||||
```shell title="Usage"
|
Set the subnet for the local end of the tunnel established using `--tunnel`.
|
||||||
meshtastic --setalt 120
|
|
||||||
```
|
|
||||||
|
|
||||||
### --setlat SETLAT
|
|
||||||
|
|
||||||
Set device latitude (allows use without GPS).
|
|
||||||
|
|
||||||
```shell title="Usage"
|
|
||||||
meshtastic --setlat 25.2
|
|
||||||
```
|
|
||||||
|
|
||||||
### --setlon SETLON
|
|
||||||
|
|
||||||
Set device longitude (allows use without GPS).
|
|
||||||
|
|
||||||
```shell title="Usage"
|
|
||||||
meshtastic --setlon -16.8
|
|
||||||
```
|
|
||||||
|
|
||||||
### --debug
|
|
||||||
|
|
||||||
Show API library debug log messages.
|
|
||||||
|
|
||||||
```shell title="Usage"
|
|
||||||
meshtastic --debug --info
|
|
||||||
```
|
|
||||||
|
|
||||||
### --test
|
|
||||||
|
|
||||||
Run stress test against all connected Meshtastic devices.
|
|
||||||
|
|
||||||
```shell title="Usage"
|
|
||||||
meshtastic --test
|
|
||||||
```
|
|
||||||
|
|
||||||
### --ble BLE
|
|
||||||
|
|
||||||
Connect to a Meshtastic device using its BLE address or name. This option allows for wireless communication with the device, similar to how the `--host` option is used for TCP connections.
|
|
||||||
|
|
||||||
```shell title="Usage"
|
|
||||||
meshtastic --ble "device_name_or_address" --info
|
|
||||||
```
|
|
||||||
|
|
||||||
### --ble-scan
|
|
||||||
|
|
||||||
Scan for available Meshtastic devices using BLE. This command lists discoverable devices, providing a convenient method to identify devices for connection via BLE.
|
|
||||||
|
|
||||||
```shell title="Usage"
|
|
||||||
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.
|
|
||||||
|
|
||||||
```shell title="Usage"
|
|
||||||
meshtastic --noproto
|
|
||||||
```
|
|
||||||
|
|
||||||
### --version
|
|
||||||
|
|
||||||
Show program's version number and exit.
|
|
||||||
|
|
||||||
```shell title="Usage"
|
|
||||||
meshtastic --version
|
|
||||||
```
|
|
||||||
|
|
||||||
### --support
|
|
||||||
|
|
||||||
Print out info that would be helpful supporting any issues.
|
|
||||||
|
|
||||||
```shell title="Usage"
|
|
||||||
meshtastic --support
|
|
||||||
```
|
|
||||||
|
|
|
||||||
|
|
@ -1 +1 @@
|
||||||
Subproject commit eeddd10c108f1516e6e0c878fbaa8ed40a4d279d
|
Subproject commit 77fafb2b027787f1206fe3774a2f456f1ffc721d
|
||||||
BIN
static/img/hardware/chatter.webp
Normal file
BIN
static/img/hardware/chatter.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 120 KiB |
BIN
static/img/hardware/chatter_keypad.webp
Normal file
BIN
static/img/hardware/chatter_keypad.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 37 KiB |
BIN
static/img/hardware/heltec/capsule-connector.webp
Normal file
BIN
static/img/hardware/heltec/capsule-connector.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 106 KiB |
BIN
static/img/hardware/heltec/capsule-sensor-extensibility.webp
Normal file
BIN
static/img/hardware/heltec/capsule-sensor-extensibility.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 135 KiB |
BIN
static/img/hardware/heltec/capsule-sensor-v3-button.webp
Normal file
BIN
static/img/hardware/heltec/capsule-sensor-v3-button.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 110 KiB |
Loading…
Reference in a new issue