mudhorn/meshtastic
1
0
Fork 0
mirror of https://github.com/meshtastic/meshtastic.git synced 2024-11-09 23:24:10 -08:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Typos, spelling, and grammar corrected (#3)

Browse source 
Thanks to aspell and languagetool. Hand picked from these, there are too
many strange things in the English language to be perfectly syntactical.
This commit is contained in:
linagee 2021-12-27 12:39:42 -07:00 committed by GitHub
parent 1d9ab151fd
commit f2e22d63c9
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
78 changed files with 381 additions and 381 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
1.1 1.5 feature list ideas.md
View file

@ -2,7 +2,7 @@
This is a collection of ideas for post 1.0 features. Based on community input we can tweak this list. Please add (but do not delete) ideas you are interested in. Feel free to add details/comments/links to **the bottom** of these lists, then post in [this thread](https://meshtastic.discourse.group/t/the-1-1-feature-work-list-triage-thread-lobby-for-your-features-here/1324) so we can discuss how to prioritize.
We have two approximate buckets: 1.1 features (next threeish months?) and 1.5 features (next sixish months). Mostly the focus now is on selecting which of the proposed 1.1 ideas developers actually want to work on. So please don't feel bad if your idea isn't high on this list, instead post in the linked thread and hopefully one of our volunteer devs will get excited to work on it. Or if you'd like to learn how to be a dev, we can mentor you through a github issue or on our slack channel.
We have two approximate buckets: 1.1 features (next threeish months?) and 1.5 features (next sixish months). Mostly the focus now is on selecting which of the proposed 1.1 ideas developers actually want to work on. So please don't feel bad if your idea isn't high on this list, instead post in the linked thread and hopefully one of our volunteer devs will get excited to work on it. Or if you'd like to learn how to be a dev, we can mentor you through a GitHub issue or on our slack channel.
But of course if someone wants to work on something (even if not in this list, or if it is low) work on it and have fun. We will happily merge pull-requests as possible.
@ -18,9 +18,9 @@ Probably in 1.1:
* MQTT protocol/gateway so nodes(And other devices) can communicate through internet if they have an AP.(See issue #377)
* Use MQTT layer to allow remote GPIO control
* Use MQTT layer to allow text messaging gateway via the internet and riot.im.
* Any node in the mesh that has internet connectivity (via direct wifi or via connected PC/phone) will route MQTT for other nodes. #8
* Any node in the mesh that has internet connectivity (via direct Wifi or via connected PC/phone) will route MQTT for other nodes. #8
* Use the new named-attribute feature to make a 'remote GPIO' on device app, for easy remote control/monitoring of GPIOs with no custom code required. #182
* Port meshtastic to the Pinetab lora radio (this would also allow meshtastic to run on most Posix targets) #143
* Port meshtastic to the Pinetab LoRa radio (this would also allow meshtastic to run on most POSIX targets) #143
* Support totally opaque payloads, for use with really low end MCUs ( https://github.com/meshtastic/Meshtastic-device/issues/383 )
* Port meshtastic to very exciting boards I've been told about.
* When battery voltage falls below TBD threshold, change network params to maximize battery life and ensure we can still be contacted by radio if needed. (especially useful for solar powered router nodes) (T-Beam needs power-up default, at present they need a button press to start, not useful for unattended repeater)
@ -32,7 +32,7 @@ Probably later:
* Implement a 'I need emergency help button' #60
* Make a new 'geofencing' on device app, which messages when a node enters/leaves a place. Could allow **very** long battery life for animal tracking.
* Store and forward messaging - If the mesh gets fragmented or a node goes out of range for x-period of time, eventually deliver the messages to the node that has rejoined. Especially useful for the hiking use case because someone may be over a ridge and have lost the Line of Sight.
* TTGO v2.0 2.1 navigation buttons soldered on the board(ability to customize button gpios via preferences)
* TTGO v2.0 2.1 navigation buttons soldered on the board(ability to customize button GPIOs via preferences)
* Extend the portduino simulator to run whole meshes of nodes in simulation.
* Enable a specific node in the mesh to log all position packets to a file (either in the App or SD card on device) to allow post activity route analysis of each node
* Buzzer support: Beeps for message received, node join, low battery etc
@ -40,15 +40,15 @@ Probably later:
* show compass heading in degrees as well as arrow. Makes it easier to track the true direction of a person in distress.
* add text-to-speech option in the app, for hands/screen free monitoring (while busy with stuff) and warnings of system events (new node discovered, low battery etc...)
* add speech-to-text to the app, now it can be used almost as a normal phone.
* External buttons - Have firmware recognise several exposed GPIO pins for 'scroll', 'event', etc. so that external mom.spst (reed sw, mercury sw. etc) can trigger these events. At present, we must expose device to the elements, or manufacture weatherproof actuators (difficult).
* Let app distribute APKs of itself over bluetooth or wifi: per [this forum post](https://meshtastic.discourse.group/t/suggestion-ability-to-transfer-app-apk-to-another-android-device-via-bt-or-other-non-network-dependent-method/711). let the device distribute the app or have a wifi web client for basic use for any wifi enabled device.
* External buttons - Have firmware recognize several exposed GPIO pins for 'scroll', 'event', etc. so that external mom.spst (reed sw, mercury sw. etc) can trigger these events. At present, we must expose device to the elements, or manufacture weatherproof actuators (difficult).
* Let app distribute APKs of itself over Bluetooth or Wifi: per [this forum post](https://meshtastic.discourse.group/t/suggestion-ability-to-transfer-app-apk-to-another-android-device-via-bt-or-other-non-network-dependent-method/711). let the device distribute the app or have a Wifi web client for basic use for any Wifi enabled device.
* Rearrange tabs on screen and add sorting option by name, range, battery, etc. See [Issue 387](https://github.com/meshtastic/Meshtastic-device/issues/387)
* Keyboard feature: Either connect a bluetooth or I2C cheap keyboard or use T-Beam buttons to select characters(One button select letters A-Z and the other one is the Next button.If you hold the next button down it will transmit the message)
* Keyboard feature: Either connect a Bluetooth or I2C cheap keyboard or use T-Beam buttons to select characters(One button select letters A-Z and the other one is the Next button.If you hold the next button down it will transmit the message)
Probably much-much later (or never? unless someone wants to do this):
* Code to support TTGO T-Dear mini, TTGO T-SOLAR, Lora32u4 II, Heltec Cube.Features: Recognise a relay in the nodeList as a relay.Ability to redirect all channels or only a list of channels.Have an owner password in order to change settings on the go(Like allowed channels name and battery status usage view etc).It should have a mode that it's used by the owner to map it's range. (@geeksville comment: I know of a couple of upcoming products that I think will make all of these 'ASR6505 based' low RAM devices obsolete. i.e. same price (approx), much more RAM and flash, even lower power consumption. So I don't recommend spending much time on this idea)
* Implement TTN LoraWan communication for messages and for 'I need emergency help button' #60 #377 (@geeksville comment: I think once we add our MQTT gateway/routing feature, there is minimal need for this case - given that TTN coverage is far lower than what meshtastic can achieve by letting any node gateway if it can get wifi or 4G)
* Code to support TTGO T-Dear mini, TTGO T-SOLAR, Lora32u4 II, Heltec Cube.Features: Recognize a relay in the nodeList as a relay.Ability to redirect all channels or only a list of channels.Have an owner password in order to change settings on the go(Like allowed channels name and battery status usage view etc).It should have a mode that it's used by the owner to map it's range. (@geeksville comment: I know of a couple of upcoming products that I think will make all of these 'ASR6505 based' low RAM devices obsolete. i.e. same price (approx), much more RAM and flash, even lower power consumption. So I don't recommend spending much time on this idea)
* Implement TTN LoRaWAN communication for messages and for 'I need emergency help button' #60 #377 (@geeksville comment: I think once we add our MQTT gateway/routing feature, there is minimal need for this case - given that TTN coverage is far lower than what meshtastic can achieve by letting any node gateway if it can get Wifi or 4G)
* Stealth Mode: Fully disable GPS and location services to increase privacy. (I think this is already mentioned somewhere, can't find a link)
## Plumbing ideas
@ -57,15 +57,15 @@ Not user visible but useful for the future.
Probably in 1.1:
* Clean up the device code - make the 'mesh' layer a separate library. Split the current gui into an on device 'app'
* Clean up the device code - make the 'mesh' layer a separate library. Split the current GUI into an on device 'app'
* Minor code cleanups, bugs #108, #107
* Portduino: meshtastic for base Posix (non arduino) systems.
* Portduino: meshtastic for base POSIX (non Arduino) systems.
* Add real power-on and factory diags, to detect failed hardware #128
Probably later:
* Report device crashes via the android analytics pipe
* Revisit the power measurements on ESP32 and NRF52 and retune, confirm new battery life
* Revisit the power measurements on ESP32 and NRF52 and re-tune, confirm new battery life
* Use the MQTT gateway to let users (optionally) upload signal strength and position info, so we can build a corpus of real-world measured radio performance
## App Ideas
@ -80,14 +80,14 @@ Probably in 1.1:
* Enable landscape layout (I forget the bug number)
* Tap on failed message to re-send them
* Implement Ping button for each node in the app list in order to refresh details about the position and the signal strength.
* Display nodes Rssi connection status with other nodes (It would be cool to see the RSSI on the map for each node from the entire network(This can be called to diagnose the network and has to be done through a button press in order to get this info when it's needed).This would help to extend coverage in the area)
* Display nodes RSSI connection status with other nodes (It would be cool to see the RSSI on the map for each node from the entire network(This can be called to diagnose the network and has to be done through a button press in order to get this info when it's needed).This would help to extend coverage in the area)
* Notifications when node joins your network.
* Set wifi SSID PASSWORD, MQTT SERVER IP, power profiles #389 from the app. Probably best done by using reflection to get various settings names.
* Set Wifi SSID PASSWORD, MQTT SERVER IP, power profiles #389 from the app. Probably best done by using reflection to get various settings names.
Probably later:
* Whatsapp Style communication system with full name display and correct message positioning(Sender's messages in the right and receiver's message in the left)
* Different icons for different node models, different icons for the nodes that are connected to the internet to suggest internet and mqtt connection, also more info on the "People" section(second tab from the left): RSSI, Board Info, Wifi Access, MQTT Access.
* Different icons for different node models, different icons for the nodes that are connected to the internet to suggest internet and MQTT connection, also more info on the "People" section(second tab from the left): RSSI, Board Info, Wifi Access, MQTT Access.
* Allow the sharing of static GPS Waypoints that would be plotted on the application map such as: Meeting locations, First AID, Water source, Vista, etc.
# 1.5 feature ideas

2
How to configure a device as a relay.md
View file

@ -41,7 +41,7 @@ Using this site, find the location of where you plan to place your relay.
Move the place marker over the spot where your relay is to placed, and it will give you the latitude, longitude and altitude.
Enter the latitude and longitude to one decimal place and altitude is recorded in metres in the configuration file.
Enter the latitude and longitude to one decimal place and altitude is recorded in meters in the configuration file.
As a suggestion, save the configuration file into the same folder, where you have downloaded the latest device firmware.
Save the file as `relay.sh`

2
README.md
View file

@ -36,7 +36,7 @@ Meshtastic® is a project that lets you use inexpensive LoRa radios as a long ra
The radios automatically create a mesh to forward packets as needed, so everyone in the group can receive messages from even the furthest member. The radios will optionally work with your phone, but no phone is required.
Meshtastic uses LoRa for the long range communcations and depending on settings used the maximum theoritical group size ranges from 30-200 device nodes. Currently each device can only support a connection from a single user at a time.
Meshtastic uses LoRa for the long range communications and depending on settings used the maximum theoretical group size ranges from 30-200 device nodes. Currently each device can only support a connection from a single user at a time.
Please see our [website](https://meshtastic.org) for more information about Meshtastic.

4
docs/developers/android/build.md
View file

@ -27,10 +27,10 @@ If you would like to develop this application we'd love your help! These build
MAPBOX_DOWNLOADS_TOKEN=sk.yourtokenherexxx
```
* Now you should be able to select "Run / Run" in the IDE and it will happily start running on your phoneor the emulator.
* Now you should be able to select "Run / Run" in the IDE and it will happily start running on your phone or the emulator.
:::note
The emulators don't support bluetooth, so some features can not be used in that environment.
The emulators don't support Bluetooth, so some features can not be used in that environment.
:::
## Analytics setup

4
docs/developers/build.md
View file

@ -27,14 +27,14 @@ To get a clean build you may have to delete the auto-generated file `./.vscode/c
:::
## Manual Installation on Linux
1. On a linux distro (like Ubuntu), ensure you have pre-requisites installed:
1. On a Linux distro (like Ubuntu), ensure you have pre-requisites installed:
```
sudo apt-get update
sudo apt-get install python3 g++ zip
```
2. Install platformio (which is usually via wget/curl command).
2. Install PlatformIO (which is usually via wget/curl command).
```
wget https://raw.githubusercontent.com/platformio/platformio-core-installer/master/get-platformio.py -O get-platformio.py

8
docs/developers/codespaces.md
View file

@ -4,7 +4,7 @@ title: Creating a build/development environment online with Codespaces
sidebar_label: Building with Codespaces
---
GitHub Codespaces is a new feature to make is really easy for anyone to build device code (or other projects like out backend server) from scratch. This builds on our existing continuous integration test builds and uses either a bare browser or (optionally) Visual Studio Code. It is a great way for anyone who has problems installing and building locally to get a gauranteed good build environment in the cloud that works and feels just like you are developing on your local machine.
GitHub Codespaces is a new feature to make is really easy for anyone to build device code (or other projects like out backend server) from scratch. This builds on our existing continuous integration test builds and uses either a bare browser or (optionally) Visual Studio Code. It is a great way for anyone who has problems installing and building locally to get a guaranteed good build environment in the cloud that works and feels just like you are developing on your local machine.
GitHub Codespaces is still in active beta and you need to [sign up](https://github.com/features/codespaces) to a waiting list to get access to it.
@ -20,9 +20,9 @@ After that you will be added to the waiting list and will be contacted when you
Once you have been granted access, go to the project you wish to develop (for example the [Meshtastic device code](https://github.com/meshtastic/Meshtastic-device) or the [backend server code](https://github.com/meshtastic/meshtastic-backend)) and click the button in the upper right that says "Fork". It will ask you to confirm, then GitHub will generate your "fork" of the master code.
<!--add images for this section once I have access to Codespaces-->
Browse to your fork of the code and in the upper right of the window click on the "Code" dropdown button, then click "Open with Codespaces".
Browse to your fork of the code and in the upper right of the window click on the "Code" drop-down button, then click "Open with Codespaces".
Github will then create a new virtual machine for you. This will take a few minutes the first time it is created as it installs Platformio and other dependancies.
Github will then create a new virtual machine for you. This will take a few minutes the first time it is created as it installs Platformio and other dependencies.
You can now edit code and click to build and run just like you are on your own machine.
<!--add examples of usage-->
<!--add examples of usage-->

18
docs/developers/device/device-api.md
View file

@ -6,7 +6,7 @@ sidebar_label: Device API
This document describes the protocol for external API clients using our devices. If you are interested in running your own code on the device itself, see the [plugin API](plugin-api.md) documentation instead.
The Device API is design to have only a simple stream of ToRadio and FromRadio packets and all polymorphism comes from the flexible set of Google Protocol Buffers which are sent over the wire. We use protocol buffers extensively both for the bluetooth API and for packets inside the mesh or when providing packets to other applications on the phone.
The Device API is design to have only a simple stream of ToRadio and FromRadio packets and all polymorphism comes from the flexible set of Google Protocol Buffers which are sent over the wire. We use protocol buffers extensively both for the Bluetooth API and for packets inside the mesh or when providing packets to other applications on the phone.
## Streaming version
@ -28,7 +28,7 @@ The receiver will validate length and if >512 it will assume the packet is corru
## MeshBluetoothService (the BLE API)
This is the main bluetooth service for the device and provides the API your app should use to get information about the mesh, send packets or provision the radio.
This is the main Bluetooth service for the device and provides the API your app should use to get information about the mesh, send packets or provision the radio.
For a reference implementation of a client that uses this service see [RadioInterfaceService](https://github.com/meshtastic/Meshtastic-Android/blob/master/app/src/main/java/com/geeksville/mesh/service/RadioInterfaceService.kt).
@ -65,7 +65,7 @@ Description (including human readable name)
8ba2bcc2-ee02-4a55-a531-c525c5e454d5
read
fromradio - contains a newly received FromRadio packet destined towards the phone (up to MAXPACKET bytes per packet).
After reading the esp32 will put the next packet in this mailbox. If the FIFO is empty it will put an empty packet in this
After reading the ESP32 will put the next packet in this mailbox. If the FIFO is empty it will put an empty packet in this
mailbox.
f75c76d2-129e-4dad-a1dd-7866124401e7
@ -77,10 +77,10 @@ read,notify,write
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.
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 actally need to be sent if the phone is already pulling from 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.
Note: that if the phone ever sees this number decrease, it means the esp32 has rebooted.
Note: that if the phone ever sees this number decrease, it means the ESP32 has rebooted.
Re: queue management
Not all messages are kept in the fromradio queue (filtered based on SubPacket):
@ -98,7 +98,7 @@ This device will work with any MTU size, but it is highly recommended that you c
On connect, you should send a want_config_id protobuf to the device. This will cause the device to send its node DB and radio config via the fromradio endpoint. After sending the full DB, the radio will send a want_config_id to indicate it is done sending the configuration.
### Other bluetooth services
### Other Bluetooth services
This document focuses on the core device protocol, but it is worth noting that the following other Bluetooth services are also
provided by the device.
@ -113,7 +113,7 @@ Characteristics
| UUID | properties | description |
| ------------------------------------ | ----------- | ----------------------------------------------------------------------------------------------------------------- |
| e74dd9c0-a301-4a6f-95a1-f0e1dbea8e1e | write,read | total image size, 32 bit, write this first, then read read back to see if it was acceptable (0 mean not accepted) |
| e74dd9c0-a301-4a6f-95a1-f0e1dbea8e1e | write,read | total image size, 32 bit, write this first, then read back to see if it was acceptable (0 mean not accepted) |
| e272ebac-d463-4b98-bc84-5cc1a39ee517 | write | data, variable sized, recommended 512 bytes, write one for each block of file |
| 4826129c-c22a-43a3-b066-ce8f0d5bacc6 | write | crc32, write last - writing this will complete the OTA operation, now you can read result |
| 5e134862-7411-4424-ac4a-210937432c77 | read,notify | result code, readable but will notify when the OTA operation completes |
@ -128,4 +128,4 @@ Implements the standard BLE contract for this service (has software version, har
#### BatteryLevelService
Implements the standard BLE contract service, provides battery level in a way that most client devices should automatically understand (i.e. it should show in the bluetooth devices screen automatically)
Implements the standard BLE contract service, provides battery level in a way that most client devices should automatically understand (i.e. it should show in the Bluetooth devices screen automatically)

6
docs/developers/device/encryption.md
View file

@ -16,13 +16,13 @@ Always keep in mind [xkcd's note on encryption](https://xkcd.com/538/).
Based on comments from reviewers (see below), here's some tips for usage of these radios. So you can know the level of protection offered:
- It is pretty likely that the AES256 security is implemented 'correctly' and an observer will not be able to decode your messages.
- Warning: If an attacker is able to get one of the radios in their posession, they could either a) extract the channel key from that device or b) use that radio to listen to new communications.
- Warning: If an attacker is able to get one of the radios in their possession, they could either a) extract the channel key from that device or b) use that radio to listen to new communications.
- Warning: If an attacker is able to get the "Channel QR code/URL" that you share with others - that attacker could then be able to read any messages sent on the channel (either tomorrow or in the past - if they kept a raw copy of those broadcast packets)
Possible future areas of work (if there is enough interest - post in our [forum](https://meshtastic.discourse.group) if you want this):
1. Optionally requiring users to provide a PIN to regain access to the mesh. This could be based on: intentionally locking the device, time since last use, or any member could force all members to reauthenticate,
2. Until a device reauthenticates, any other access via BLE or USB would be blocked (this would protect against attackers who are not prepared to write custom software to extract and reverse engineer meshtastic flash memory)
1. Optionally requiring users to provide a PIN to regain access to the mesh. This could be based on: intentionally locking the device, time since last use, or any member could force all members to re-authenticate,
2. Until a device re-authenticates, any other access via BLE or USB would be blocked (this would protect against attackers who are not prepared to write custom software to extract and reverse engineer meshtastic flash memory)
3. Turning on read-back protection in the device fuse-bits (this would extend protection in #2 to block all but **extremely** advanced attacks involving chip disassembly)
4. Time limiting keys used for message transmission and automatically cycling them on a schedule. This would protect past messages from being decoded even if an attacker learns the current key.

6
docs/developers/device/http-api.md
View file

@ -63,11 +63,11 @@ Since authentication is also eventually needed for our other transports (TCP and
## Client
### Javascript
### JavaScript
See: <https://github.com/meshtastic/meshtastic.js>
A reference client written in Javascript will provide a Javascript API for using this transport. That client will do HTTP connections, use the generated protobuf javascript code and provide an API that hides all of this REST plumbing. The two key methods will be "sendToRadio(packet) and onFromRadio(callback)".
A reference client written in JavaScript will provide a JavaScript API for using this transport. That client will do HTTP connections, use the generated protobuf JavaScript code and provide an API that hides all of this REST plumbing. The two key methods will be "sendToRadio(packet) and onFromRadio(callback)".
### Protoman
@ -77,7 +77,7 @@ Protoman is able to interface with the Meshtastic REST API out of the box. This
## Security
HTTP and HTTPS are both supported on the esp32 using self signed certificates on HTTPS.
HTTP and HTTPS are both supported on the ESP32 using self signed certificates on HTTPS.
## Related documents

86
docs/developers/device/mesh-alg.md
View file

@ -10,12 +10,12 @@ The routing protocol for Meshtastic is really quite simple (and suboptimal). It
### A note about protocol buffers
Because we want our devices to work across various vendors and implementations, we use [Protocol Buffers](https://github.com/meshtastic/Meshtastic-protobufs) pervasively. For information on how the protocol buffers are used wrt API clients see [sw-design](/software/other/sw-design.md), for purposes of this document you mostly only
Because we want our devices to work across various vendors and implementations, we use [Protocol Buffers](https://github.com/meshtastic/Meshtastic-protobufs) pervasively. For information on how the protocol buffers are used with respect to API clients see [sw-design](/software/other/sw-design.md), for purposes of this document you mostly only
need to consider the MeshPacket and Subpacket message types.
### Layer 1: Non reliable zero hop messaging
This layer is conventional non-reliable lora packet transmission. The transmitted packet has the following representation on the ether:
This layer is conventional non-reliable LoRa packet transmission. The transmitted packet has the following representation on the ether:
- A 32 bit LORA preamble (to allow receiving radios to synchronize clocks and start framing). We use a longer than minimum (8 bit) preamble to maximize the amount of time the LORA receivers can stay asleep, which dramatically lowers power consumption.
@ -23,12 +23,12 @@ After the preamble the 16 byte packet header is transmitted. This header is desc
- to (4 bytes): the unique NodeId of the destination (or 0xffffffff for NodeNum_BROADCAST)
- from (4 bytes): the unique NodeId of the sender)
- id (4 bytes): the unique (wrt the sending node only) packet ID number for this packet. We use a large (32 bit) packet ID to ensure there is enough unique state to protect any encrypted payload from attack.
- flags (4 bytes): Only a few bits are are currently used - 3 bits for for the "HopLimit" (see below) and 1 bit for "WantAck"
- id (4 bytes): the unique (with respect to the sending node only) packet ID number for this packet. We use a large (32 bit) packet ID to ensure there is enough unique state to protect any encrypted payload from attack.
- flags (4 bytes): Only a few bits are currently used - 3 bits for the "HopLimit" (see below) and 1 bit for "WantAck"
After the packet header the actual packet is placed onto the the wire. These bytes are merely the encrypted packed protobuf encoding of the SubPacket protobuf. A full description of our encryption is available in [crypto](/docs/developers/device/encryption). It is worth noting that only this SubPacket is encrypted, headers are not. Which leaves open the option of eventually allowing nodes to route packets without knowing the keys used to encrypt.
After the packet header, the actual packet is placed onto the the wire. These bytes are merely the encrypted packed protobuf encoding of the SubPacket protobuf. A full description of our encryption is available in [crypto](/docs/developers/device/encryption). It is worth noting that only this SubPacket is encrypted, headers are not. Which leaves open the option of eventually allowing nodes to route packets without knowing the keys used to encrypt.
NodeIds are constructed from the bottom four bytes of the macaddr of the bluetooth address. Because the OUI is assigned by the IEEE and we currently only support a few CPU manufacturers, the upper byte is defacto guaranteed unique for each vendor. The bottom 3 bytes are guaranteed unique by that vendor.
NodeIds are constructed from the bottom four bytes of the macaddr of the Bluetooth address. Because the OUI is assigned by the IEEE, and we currently only support a few CPU manufacturers, the upper byte is defacto guaranteed unique for each vendor. The bottom 3 bytes are guaranteed unique by that vendor.
To prevent collisions all transmitters will listen before attempting to send. If they hear some other node transmitting, they will reattempt transmission in x milliseconds. This retransmission delay is random between FIXME and FIXME (these two numbers are currently hardwired, but really should be scaled based on expected packet transmission time at current channel settings).
@ -39,19 +39,19 @@ This layer adds reliable messaging between the node and its immediate neighbors
The default messaging provided by layer-1 is extended by setting the "want-ack" flag in the MeshPacket protobuf. If want-ack is set the following documentation from mesh.proto applies:
"""This packet is being sent as a reliable message, we would prefer it to arrive
at the destination. We would like to receive a ack packet in response.
at the destination. We would like to receive an ACK packet in response.
Broadcasts messages treat this flag specially: Since acks for broadcasts would
rapidly flood the channel, the normal ack behavior is suppressed. Instead,
Broadcast messages treat this flag specially: Since acks for broadcasts would
rapidly flood the channel, the normal ACK behavior is suppressed. Instead,
the original sender listens to see if at least one node is rebroadcasting this
packet (because naive flooding algorithm). If it hears that the odds (given
typical LoRa topologies) the odds are very high that every node should
packet (because naive flooding algorithm). If it hears that, the odds (given
typical LoRa topologies) are very high that every node should
eventually receive the message. So FloodingRouter.cpp generates an implicit
ack which is delivered to the original sender. If after some time we don't
ACK which is delivered to the original sender. If after some time we don't
hear anyone rebroadcast our packet, we will timeout and retransmit, using the
regular resend logic."""
If a transmitting node does not receive an ACK (or a NAK) packet within FIXME milliseconds, it will use layer-1 to attempt a retransmission of the sent packet. A reliable packet (at this 'zero hop' level) will be resent a maximum of three times. If no ack or nak has been received by then the local node will internally generate a nak (either for local consumption or use by higher layers of the protocol).
If a transmitting node does not receive an ACK (or a NAK) packet within FIXME milliseconds, it will use layer-1 to attempt a retransmission of the sent packet. A reliable packet (at this 'zero hop' level) will be resent a maximum of three times. If no ACK or NAK has been received by then the local node will internally generate a NAK (either for local consumption or use by higher layers of the protocol).
### Layer 3: (Naive) flooding for multi-hop messaging
@ -62,13 +62,13 @@ Each node in the mesh, if it sees a packet on the ether with HopLimit set to a v
### Layer 4: DSR for multi-hop unicast messaging
This layer is not yet fully implemented (and not yet used). But eventually (if we stay with our own transport rather than switching to QMesh or Reticulum)
we will use conventional DSR for unicast messaging. Currently (even when not requiring 'broadcasts') we send any multi-hop unicasts as 'broadcasts' so that we can
leverage our (functional) flooding implementation. This is suboptimal but it is a very rare use-case, because the odds are high that most nodes (given our small networks and 'hiking' use case) are within a very small number of hops. When any node witnesses an ack for a packet, it will realize that it can abandon its own
we will use conventional DSR for unicast messaging. Currently, (even when not requiring 'broadcasts') we send any multi-hop unicasts as 'broadcasts' so that we can
leverage our (functional) flooding implementation. This is suboptimal but it is a very rare use-case, because the odds are high that most nodes (given our small networks and 'hiking' use case) are within a very small number of hops. When any node witnesses an ACK for a packet, it will realize that it can abandon its own
broadcast attempt for that packet.
## Misc notes on remaining tasks
This section is currently poorly formatted, it is mostly a mere set of todo lists and notes for @geeksville during his initial development. After release 1.0 ideas for future optimization include:
This section is currently poorly formatted, it is mostly a mere set of TODO lists and notes for @geeksville during his initial development. After release 1.0 ideas for future optimization include:
- Make flood-routing less naive (because we have GPS and radio signal strength as heuristics to avoid redundant retransmissions)
- If nodes have been user marked as 'routers', preferentially do flooding via those nodes
@ -86,21 +86,21 @@ reliable messaging tasks (stage one for DSR):
- DONE add a max hops parameter, use it for broadcast as well (0 means adjacent only, 1 is one forward etc...). Store as three bits in the header.
- DONE add a 'snoopReceived' hook for all messages that pass through our node.
- DONE use the same 'recentmessages' array used for broadcast msgs to detect duplicate retransmitted messages.
- DONE in the router receive path?, send an ack packet if want_ack was set and we are the final destination. FIXME, for now don't handle multihop or merging of data replies with these acks.
- DONE in the router receive path?, send an ACK packet if want_ack was set and we are the final destination. FIXME, for now don't handle multi-hop or merging of data replies with these acks.
- DONE keep a list of packets waiting for acks
- DONE for each message keep a count of # retries (max of three). Local to the node, only for the most immediate hop, ignorant of multihop routing.
- DONE for each message keep a count of # retries (max of three). Local to the node, only for the most immediate hop, ignorant of multi-hop routing.
- DONE delay some random time for each retry (large enough to allow for acks to come in)
- DONE once an ack comes in, remove the packet from the retry list and deliver the ack to the original sender
- DONE after three retries, deliver a no-ack packet to the original sender (i.e. the phone app or mesh router service)
- DONE test one hop ack/nak with the python framework
- DONE after three retries, deliver a no-ACK packet to the original sender (i.e. the phone app or mesh router service)
- DONE test one hop ACK/NAK with the python framework
- DONE Do stress test with acks
dsr tasks
DSR tasks
- DONE oops I might have broken message reception
- DONE Don't use broadcasts for the network pings (close open github issue)
- DONE Don't use broadcasts for the network pings (close open GitHub issue)
- DONE add ignoreSenders to radioconfig to allow testing different mesh topologies by refusing to see certain senders
- DONE test multihop delivery with the python framework
- DONE test multi-hop delivery with the python framework
optimizations / low priority:
@ -111,7 +111,7 @@ optimizations / low priority:
- change nodenums and packetids in protobuf to be fixed32
- low priority: think more careful about reliable retransmit intervals
- make ReliableRouter.pending threadsafe
- bump up PacketPool size for all the new ack/nak/routing packets
- bump up PacketPool size for all the new ACK/NAK/routing packets
- handle 51 day rollover in doRetransmissions
- use a priority queue for the messages waiting to send. Send acks first, then routing messages, then data messages, then broadcasts?
@ -134,49 +134,49 @@ routeDiscovery
- if we've already passed through us (or is from us), then it ignore it
- use the nodes already mentioned in the request to update our routing table
- if they were looking for us, send back a routereply
- NOT DOING FOR NOW -if max_hops is zero and they weren't looking for us, drop (FIXME, send back error - I think not though?)
- NOT DOING FOR NOW -if max_hops is zero, and they weren't looking for us, drop (FIXME, send back error - I think not though?)
- if we receive a discovery packet, and we don't have next_hop set in our nodedb, we use it to populate next_hop (if needed) towards the requester (after decrementing max_hops)
- if we receive a discovery packet, and we have a next_hop in our nodedb for that destination we send a (reliable) we send a route reply towards the requester
when sending any reliable packet
- if timeout doing retries, send a routeError (nak) message back towards the original requester. all nodes eavesdrop on that packet and update their route caches.
- if timeout doing retries, send a routeError (NAK) message back towards the original requester. all nodes eavesdrop on that packet and update their route caches.
when we receive a routereply packet
- update next_hop on the node, if the new reply needs fewer hops than the existing one (we prefer shorter paths). fixme, someday use a better heuristic
- update next_hop on the node, if the new reply needs fewer hops than the existing one (we prefer shorter paths). FIXME, someday use a better heuristic
when we receive a routeError packet
- delete the route for that failed recipient, restartRouteDiscovery()
- if we receive routeerror in response to a discovery,
- fixme, eventually keep caches of possible other routes.
- FIXME, eventually keep caches of possible other routes.
TODO:
- optimize our generalized flooding with heuristics, possibly have particular nodes self mark as 'router' nodes.
- DONE reread the radiohead mesh implementation - hop to hop acknowledgement seems VERY expensive but otherwise it seems like DSR
- DONE reread the radiohead mesh implementation - hop to hop acknowledgment seems VERY expensive but otherwise it seems like DSR
- DONE read about mesh routing solutions (DSR and AODV)
- DONE read about general mesh flooding solutions (naive, MPR, geo assisted)
- DONE reread the disaster radio protocol docs - seems based on Babel (which is AODVish)
- REJECTED - seems dying - possibly dash7? <https://www.slideshare.net/MaartenWeyn1/dash7-alliance-protocol-technical-presentation> <https://github.com/MOSAIC-LoPoW/dash7-ap-open-source-stack> - does the opensource stack implement multihop routing? flooding? their discussion mailing list looks dead-dead
- update duty cycle spreadsheet for our typical usecase
- REJECTED - seems dying - possibly dash7? <https://www.slideshare.net/MaartenWeyn1/dash7-alliance-protocol-technical-presentation> <https://github.com/MOSAIC-LoPoW/dash7-ap-open-source-stack> - does the open source stack implement multi-hop routing? flooding? their discussion mailing list looks dead-dead
- update duty cycle spreadsheet for our typical use case
a description of DSR: <https://t>ools.ietf.org/html/rfc4728 good slides here: <https://www.slideshare.net/ashrafmath/dynamic-source-routing>
good description of batman protocol: <https://www.open-mesh.org/projects/open-mesh/wiki/BATMANConcept>
interesting paper on lora mesh: <https://portal.research.lu.se/portal/files/45735775/paper.pdf>
interesting paper on LoRa mesh: <https://portal.research.lu.se/portal/files/45735775/paper.pdf>
It seems like DSR might be the algorithm used by RadioheadMesh. DSR is described in <https://tools.ietf.org/html/rfc4728>
<https://en.wikipedia.org/wiki/Dynamic_Source_Routing>
broadcast solution:
Use naive flooding at first (FIXME - do some math for a 20 node, 3 hop mesh. A single flood will require a max of 20 messages sent)
Then move to MPR later (<http://www.olsr.org/docs/report_html/node28.html>). Use altitude and location as heursitics in selecting the MPR set
Then move to MPR later (<http://www.olsr.org/docs/report_html/node28.html>). Use altitude and location as heuristics in selecting the MPR set
compare to db sync algorithm?
what about never flooding gps broadcasts. instead only have them go one hop in the common case, but if any node X is looking at the position of Y on their gui, then send a unicast to Y asking for position update. Y replies.
What about never flooding GPS broadcasts? Instead, only have them go one hop in the common case. But if any node X is looking at the position of Y on their GUI, then send a unicast to Y asking for position update. Y replies.
If Y were to die, at least the neighbor nodes of Y would have their last known position of Y.
@ -184,7 +184,7 @@ If Y were to die, at least the neighbor nodes of Y would have their last known p
- send all broadcasts with a TTL
- periodically(?) do a survey to find the max TTL that is needed to fully cover the current network.
- to do a study first send a broadcast (maybe our current initial user announcement?) with TTL set to one (so therefore no one will rebroadcast our request)
- to do a study, first send a broadcast (maybe our current initial user announcement?) with TTL set to one (so therefore no one will rebroadcast our request)
- survey replies are sent unicast back to us (and intervening nodes will need to keep the route table that they have built up based on past packets)
- count the number of replies to this TTL 1 attempt. That is the number of nodes we can reach without any rebroadcasts
- repeat the study with a TTL of 2 and then 3. stop once the # of replies stops going up.
@ -193,10 +193,10 @@ If Y were to die, at least the neighbor nodes of Y would have their last known p
## approach 2
- send a TTL1 broadcast, the replies let us build a list of the nodes (stored as a bitvector?) that we can see (and their rssis)
- send a TTL1 broadcast, the replies let us build a list of the nodes (stored as a bitvector?) that we can see (and their RSSIs)
- we then broadcast out that bitvector (also TTL1) asking "can any of ya'll (even indirectly) see anyone else?"
- if a node can see someone I missed (and they are the best person to see that node), they reply (unidirectionally) with the missing nodes and their rssis (other nodes might sniff (and update their db) based on this reply but they don't have to)
- given that the max number of nodes in this mesh will be like 20 (for normal cases), I bet globally updating this db of "nodenums and who has the best rssi for packets from that node" would be useful
- if a node can see someone I missed (and they are the best person to see that node), they reply (unidirectionally) with the missing nodes and their RSSIs (other nodes might sniff (and update their db) based on this reply, but they don't have to)
- given that the max number of nodes in this mesh will be like 20 (for normal cases), I bet globally updating this db of "nodenums and who has the best RSSI for packets from that node" would be useful
- once the global DB is shared, when a node wants to broadcast, it just sends out its broadcast . the first level receivers then make a decision "am I the best to rebroadcast to someone who likely missed this packet?" if so, rebroadcast
## approach 3
@ -204,19 +204,19 @@ If Y were to die, at least the neighbor nodes of Y would have their last known p
- when a node X wants to know other nodes positions, it broadcasts its position with want_replies=true. Then each of the nodes that received that request broadcast their replies (possibly by using special timeslots?)
- all nodes constantly update their local db based on replies they witnessed.
- after 10s (or whatever) if node Y notices that it didn't hear a reply from node Z (that Y has heard from recently ) to that initial request, that means Z never heard the request from X. Node Y will reply to X on Z's behalf.
- could this work for more than one hop? Is more than one hop needed? Could it work for sending messages (i.e. for a msg sent to Z with want-reply set).
- could this work for more than one hop? Is more than one hop needed? Could it work for sending messages (i.e. for a message sent to Z with want-reply set).
## approach 4
look into the literature for this idea specifically.
- don't view it as a mesh protocol as much as a "distributed db unification problem". When nodes talk to nearby nodes they work together
- don't view it as a mesh protocol as much as a "distributed db unification problem". When nodes talk to nearby nodes, they work together
to update their nodedbs. Each nodedb would have a last change date and any new changes that only one node has would get passed to the
other node. This would nicely allow distant nodes to propogate their position to all other nodes (eventually).
other node. This would nicely allow distant nodes to propagate their position to all other nodes (eventually).
- handle group messages the same way, there would be a table of messages and time of creation.
- when a node has a new position or message to send out, it does a broadcast. All the adjacent nodes update their db instantly (this handles 90% of messages I'll bet).
- Occasionally a node might broadcast saying "anyone have anything newer than time X?" If someone does, they send the diffs since that date.
- Occasionally, a node might broadcast saying "anyone have anything newer than time X?" If someone does, they send the diffs since that date.
- essentially everything in this variant becomes broadcasts of "request db updates for >time X - for _all_ or for a particular nodenum" and nodes sending (either due to request or because they changed state) "here's a set of db updates". Every node is constantly trying to
build the most recent version of reality, and if some nodes are too far, then nodes closer in will eventually forward their changes to the distributed db.
- construct non ambigious rules for who broadcasts to request db updates. ideally the algorithm should nicely realize node X can see most other nodes, so they should just listen to all those nodes and minimize the # of broadcasts. the distributed picture of nodes rssi could be useful here?
- construct non ambiguous rules for who broadcasts to request db updates. ideally the algorithm should nicely realize node X can see most other nodes, so they should just listen to all those nodes and minimize the # of broadcasts. the distributed picture of nodes RSSI could be useful here?
- possibly view the BLE protocol to the radio the same way - just a process of reconverging the node/msgdb database.

10
docs/developers/device/plugin-api.md
View file

@ -4,7 +4,7 @@ title: Plugin API
sidebar_label: Plugin API
---
This is a tutorial on how to write small plugins which run on the device. Plugins are bits regular 'arduino' code that can send and receive packets to other nodes/apps/PCs using our mesh.
This is a tutorial on how to write small plugins which run on the device. Plugins are bits regular 'Arduino' code that can send and receive packets to other nodes/apps/PCs using our mesh.
## Key concepts
@ -14,9 +14,9 @@ Messages are sent to particular port numbers (similar to UDP networking). Your n
Packets can be sent/received either as raw binary structures or as [Protobufs](https://developers.google.com/protocol-buffers).
### Class heirarchy
### Class hierarchy
The relevant bits of the class heirarchy are as follows
The relevant bits of the class hierarchy are as follows
- [MeshPlugin](http://github.com/meshtastic/meshtastic-device/tree/master/src/mesh/MeshPlugin.h) (in src/mesh/MeshPlugin.h) - you probably don't want to use this baseclass directly
- [SinglePortPlugin](http://github.com/meshtastic/meshtastic-device/tree/master/src/mesh/SinglePortPlugin.h) (in src/mesh/SinglePortPlugin.h) - for plugins that send/receive from a single port number (the normal case)
@ -48,7 +48,7 @@ A number of [key services](http://github.com/meshtastic/meshtastic-device/tree/m
The easiest way to get started is:
- [Build and install](/docs/software/other/build-instructions) the standard codebase from github.
- [Build and install](/docs/software/other/build-instructions) the standard codebase from GitHub.
- Copy [src/plugins/ReplyPlugin.\*](http://github.com/meshtastic/meshtastic-device/tree/master/src/plugins/ReplyPlugin.cpp) into src/plugins/YourPlugin.*. Then change the port number from *PortNum_REPLY_APP* to *PortNum_PRIVATE_APP\*.
- Edit plugins/Plugins.cpp:setupPlugins() to add a call to create an instance of your plugin (see comment at head of that function)
- Rebuild with your new messaging goodness and install on the device
@ -71,7 +71,7 @@ If you are making a new app using meshtastic, please send in a pull request to a
- **0-63** Core Meshtastic use; do not use for third party apps
- **64-127** Registered 3rd party apps. Send in a pull request that adds a new entry to portnums.proto to register your application
- **256-511** Use one of these portnums for your private applications that you don't want to register publically
- **256-511** Use one of these portnums for your private applications that you don't want to register publicly
- **1024-66559** Are reserved for use by IP tunneling (see _FIXME_ for more information)
All other values are reserved.

4
docs/developers/device/port-numbers.md
View file

@ -12,7 +12,7 @@ If you are making a new app using meshtastic, please send in a pull request to a
| --- | --- |
| 0-63 | Core Meshtastic use, do not use for third party apps |
| 64-127 | Registered 3rd party apps, send in a pull request that adds a new entry to portnums.proto to register your application |
| 256-511 | Use one of these portnums for your private applications that you do not want to register publically |
| 256-511 | Use one of these portnums for your private applications that you do not want to register publicly |
All other values are reserved.
@ -20,4 +20,4 @@ Note: This was formerly a Type enum named `typ` with the same id #
We have changed to this 'portnum' based scheme for specifying app handlers for particular payloads. This change is backwards compatible by treating the legacy OPAQUE/CLEAR_TEXT values identically.
The current list of port numbers can be found listed in the [protobufs](/docs/developers/protobufs/api#portnumsproto)
The current list of port numbers can be found listed in the [protobufs](/docs/developers/protobufs/api#portnumsproto)

14
docs/developers/device/radio-settings.md
View file

@ -42,13 +42,13 @@ Various data-rates are selectable when configuring a channel and are inversely p
Considerations:
- Spreading Factor - How much we "spread" our data over time.
- Each step up in Spreading Factor dobules the airtime to transmit.
- Each step up in Spreading Factor doubles the airtime to transmit.
- Each step up in Spreading Factor adds about 2.5db extra link budget.
- Bandwidth - How big of a slice of the spectrum we use.
- Each doubling of the bandwidth is almost 3db less link budget.
- Bandwidths less than 31 may be unstable unless you have a high quality Crystal Ossilator.
- Coding Rate - How much redundency we encode to resist noise.
- Increasing coding rate increases reliability while decrasing data-rate.
- Bandwidths less than 31 may be unstable unless you have a high quality Crystal Oscillator.
- Coding Rate - How much redundancy we encode to resist noise.
- Increasing coding rate increases reliability while decreasing data-rate.
- 4/5 - 1.25x overhead
- 4/6 - 1.5x overhead
- 4/7 - 1.75x overhead
@ -92,12 +92,12 @@ Some example settings:
| 0.610 kbps | 10 / 1024 | 4/8 | 125 | 149dB | |
| 0.488 kbps | 11 / 2048 | 4/6 | 125 | 152dB | |
| 0.336 kbps | 11 / 2048 | 4/8 | 125 | 152dB | |
| 0.073 kbps | 12 / 4096 | 4/5 | 31 | 160dB | Twice the range and/or coverage of "Long Slow", low resliance to noise |
| 0.046 kbps | 12 / 4096 | 4/8 | 31 | 160dB | Twice the range and/or coverage of "Long Slow", high resliance to noise |
| 0.073 kbps | 12 / 4096 | 4/5 | 31 | 160dB | Twice the range and/or coverage of "Long Slow", low resilience to noise |
| 0.046 kbps | 12 / 4096 | 4/8 | 31 | 160dB | Twice the range and/or coverage of "Long Slow", high resilience to noise |
The link budget used by these calculations assumes a transmit power of 17dBm and an antenna with 0dB gain. Adjust your link budget assumptions based on your actual devices.
These channel settings may have not been tested. Use at your own discression. Share on <https://meshtastic.discourse.group> with your successes or failure.
These channel settings may have not been tested. Use at your own discretion. Share on <https://meshtastic.discourse.group> with your successes or failure.
## Cryptography

10
docs/developers/overview.md
View file

@ -6,7 +6,7 @@ slug: /developers
---
# How to Help
Meshtastic is a team of volunteers and as such there is always plenty of ways to help. This project gets great contributions from people in their off hours. Those contributors work on the features they are interested in. It is a very open and welcoming developer community and we are always looking for help improving Meshtastic.
Meshtastic is a team of volunteers and as such there is always plenty of ways to help. This project gets great contributions from people in their off hours. Those contributors work on the features they are interested in. It is a very open and welcoming developer community, and we are always looking for help to improve Meshtastic.
* If you're a developer, there's plenty stuff to do. Dig in!
* If you're interacting with Meshtastic radios, we could use help with testing, documenting and providing feedback.
@ -24,18 +24,18 @@ There are many technologies (and repositories) used in creating the Meshtastic e
Most communication and interactions happen with protocol buffers. The [Meshtastic-protobufs](https://github.com/meshtastic/Meshtastic-protobufs) repo is where all of the protocol buffer changes happen. See the [Protobuf API Reference](https://meshtastic.org/docs/developers/protobufs/api) for more details.
## Firmware
The [Meshtastic-device](https://github.com/meshtastic/Meshtastic-device) is where all of the firmware development happens. This is where the code for the esp32 and nrf52 based devices to interact is developed. It is mainly C and C++ code.Think Arduino. It is where the first level of hardware interaction begins and ends.
The [Meshtastic-device](https://github.com/meshtastic/Meshtastic-device) is where all of the firmware development happens. This is where the code for the ESP32 and nRF52 based devices to interact is developed. It is mainly C and C++ code.Think Arduino. It is where the first level of hardware interaction begins and ends.
## Plugins
[Plugins](https://meshtastic.org/docs/software/plugins/) are also implemented mainly in the Meshtastic-device repo above. Typically, you would add functionality in the protobufs repo and the device repo to implement plugin functionality. You probably also want to have some client/device use/interact with the plugin and that is where the Device support comes into play.
## Device Support
The [Meshtastic-python](https://github.com/meshtastic/Meshtastic-python) is typically where the first device interaction takes place, but that is not a requirement. This repo has a cli that allows you to interact with most functionality with the devices. This python library can also be consumed for other applications. See [Community applications](https://meshtastic.org/docs/software/community/community-overview) for other Meshtastic applications.
The [Meshtastic-python](https://github.com/meshtastic/Meshtastic-python) is typically where the first device interaction takes place, but that is not a requirement. This repo has a command line utility that allows you to interact with most functionality with the devices. This python library can also be consumed for other applications. See [Community applications](https://meshtastic.org/docs/software/community/community-overview) for other Meshtastic applications.
## Web Application
The [Meshtastic-web](https://github.com/meshtastic/meshtastic-web) is where the hosted web server on the esp32 devices in Typescript is developed. See the [Web interface overview](https://meshtastic.org/docs/software/web/web-app-software) for more details.
The [Meshtastic-web](https://github.com/meshtastic/meshtastic-web) is where the hosted web server on the ESP32 devices in Typescript is developed. See the [Web interface overview](https://meshtastic.org/docs/software/web/web-app-software) for more details.
The [meshtastic.js](https://github.com/meshtastic/meshtastic.js) is a javascript library that provides an interface for Meshtastic devices.
The [meshtastic.js](https://github.com/meshtastic/meshtastic.js) is a JavaScript library that provides an interface for Meshtastic devices.
@sachaw has been making tons of progress on the web app and would love help with:

6
docs/developers/publish.md
View file

@ -18,7 +18,7 @@ If you’d like to do ‘real’ releases with your changes, the procedure is:
* * git commit -m "updating proto submodule to latest"
* run bin/regen-protos.sh
* edit version.properties to set release version
* commit and push (or merge) to root of repo - this should cause github to start a release build (see the CI actions)
* commit and push (or merge) to root of repo - this should cause GitHub to start a release build (see the CI actions)
* edit the draft release text and click publish
### Update Protobufs
@ -54,7 +54,7 @@ TBD
## Python
### Pre-requistes
### Pre-requisites
* Python Packages
* * pip3 install pdoc3
@ -82,5 +82,5 @@ TBD
I usually just edit setup.py to bump the version number, then run "bin/upload-release.sh" (though you should use bin/test-release.sh for the first time - which is just a dry deploy to the pypi test server). This script does the build (including new docs - which will end up in the git checkin) and upload to pypi. Then I do a git commit/push and tag wit the version number.
:::note
You need permissions in the github project to make a build
You need permissions in the GitHub project to make a build
:::

8
docs/getting-started/concepts.md
View file

@ -7,7 +7,7 @@ slug: /getting-started/concepts
Various high level concepts used in the Meshtastic metaverse:
* mesh networking: By using [low-power radios](https://meshtastic.org/docs/hardware) to connect other low-power radios using LoRa to be able to send and receive messages and data. This can be completely separate from any other network such as the internet. You can start small and get two devices to start experiementing. Do not expect to stream music or videos as LoRa is intended for smaller, lower bandwidth type uses.
* captive portal: Using Meshtastic, you can create a separate wifi network for you join your phone or computer on a mesh network. See [Web Interface](https://meshtastic.org/docs/software/web/web-app-software) for more info. This is ideal in a situation where you are remote, such as in the forest or on a mountain or if there is a major power/internet outage such as in a storm other other disaster.
* Meshtastic channels: Can create a *somewhat* secure method of communication on the same mesh network. They channel can be encrypted, to prevent normal people from listening in on the traffic. But, it could probably be easily cracked by determined indviduals. See [Channel Config](https://meshtastic.org/docs/software/settings/channel) for more info.
* LoRaWan: If you add a LoRa gateway, then you can interact with more networks, such as the internet.
* mesh networking: By using [low-power radios](https://meshtastic.org/docs/hardware) to connect other low-power radios using LoRa to be able to send and receive messages and data. This can be completely separate from any other network such as the internet. You can start small and get two devices to start experimenting. Do not expect to stream music or videos as LoRa is intended for smaller, lower bandwidth type uses.
* captive portal: Using Meshtastic, you can create a separate Wifi network for you join your phone or computer on a mesh network. See [Web Interface](https://meshtastic.org/docs/software/web/web-app-software) for more info. This is ideal in a situation where you are remote, such as in the forest or on a mountain or if there is a major power/internet outage such as in a storm or other disaster.
* Meshtastic channels: Can create a *somewhat* secure method of communication on the same mesh network. They channel can be encrypted, to prevent normal people from listening in on the traffic. But, it could probably be easily cracked by determined individuals. See [Channel Config](https://meshtastic.org/docs/software/settings/channel) for more info.
* LoRaWAN: If you add a LoRa gateway, then you can interact with more networks, such as the internet.

6
docs/getting-started/faq.md
View file

@ -48,10 +48,10 @@ Q: My device has gone to sleep. Are received messages lost?
Q: My device has gone to sleep and I can't send any messages.
* Once the node wakes up from sleep, your phone will relay any delayed messages through your node and to the mesh network. Give it a few minutes and it'll do the right thing.
Q: How do I turn off an esp32 t-beam based device?
Q: How do I turn off an ESP32 t-beam based device?
* Hold down the middle button for about 10 seconds.
Q: How do I turn on an esp32 t-beam based device?
Q: How do I turn on an ESP32 t-beam based device?
* Push the power button for about 1 second.
Q: How can I tell the device not to sleep?
@ -96,7 +96,7 @@ Q: How do I get the Meshtastic iOS App?
## Bluetooth
Q: How do I pair my phone to the device if my device doesn't have a screen?
* Answer TBD (perhaps consider using web if esp32)
* Answer TBD (perhaps consider using web if ESP32)
Q: Can I have Bluetooth enabled and use WiFi radio?
* No. Only one method will work at a time.

2
docs/getting-started/flashing-esp32.md
View file

@ -52,7 +52,7 @@ values={[
### Download Latest Firmware
Firmware can be downloaded from the [Firmware](/firmware) page. Your initial installation has to happen over USB from your Mac, Windows or Linux PC. Once our software is installed, all future software updates happen over bluetooth from your phone.
Firmware can be downloaded from the [Firmware](/firmware) page. Your initial installation has to happen over USB from your Mac, Windows or Linux PC. Once our software is installed, all future software updates happen over Bluetooth from your phone.
:::note
The [T-Beam 0.7](../hardware/tbeam-hardware#t-beam---v07) board is an earlier version of the T-Beam board, and due to changes in the design in subsequent iterations this board uses a specific firmware file different from the other T-Beam boards.

10
docs/getting-started/flashing-nrf52.md
View file

@ -7,7 +7,7 @@ sidebar_label: nRF52 devices
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
## Pre-requisits
## Pre-requisites
:::tip
Please ensure that you use a data USB-C cable, as many USB-C cables provide power only and not the data lines.
@ -16,7 +16,7 @@ Please ensure that you use a data USB-C cable, as many USB-C cables provide powe
### T-Echo
:::tip
The usb-C to usb-A cable from LILYGO is _NOT_ a "data cable", and can only be used for charging.
The USB-C to USB-A cable from LILYGO is _NOT_ a "data cable", and can only be used for charging.
:::
#### Windows:
@ -28,7 +28,7 @@ You may need to install the [USB device drivers](http://www.wch-ic.com/search?q=
Last Verified T-Echo nRF52840 on: Mac OS Monterey v12.0.1 (Intel chipset)
:::tip
You can use the latest [Apple USB-C Charge cables](https://www.apple.com/shop/product/MLL82AM/A/usb-c-charge-cable-2-m). The cable that is provided with the iPad Pro works. Older Laptop usb-C Power cables will _NOT_ work, as they are missing the data lines.
You can use the latest [Apple USB-C Charge cables](https://www.apple.com/shop/product/MLL82AM/A/usb-c-charge-cable-2-m). The cable that is provided with the iPad Pro works. Older Laptop USB-C Power cables will _NOT_ work, as they are missing the data lines.
:::
:::caution
@ -66,7 +66,7 @@ Please ensure that you have updated the bootloader to the latest version using t
## Download Latest Firmware
Firmware can be downloaded from the [Firmware](/firmware) page. Your initial installation has to happen over USB from your Mac, Windows or Linux PC. Once our software is installed, all future software updates happen over bluetooth from your phone.
Firmware can be downloaded from the [Firmware](/firmware) page. Your initial installation has to happen over USB from your Mac, Windows or Linux PC. Once our software is installed, all future software updates happen over Bluetooth from your phone.
## Install/Update Firmware
@ -74,7 +74,7 @@ Firmware can be downloaded from the [Firmware](/firmware) page. Your initial ins
Be careful to install the correct load for your board. While it is unlikely that you will cause damage to your device, the wrong firmware will cause it to not work.
:::
- Connect your device to your computer with a USB cable. If you computer complains about needing to format a new drive, cancel the format command.
- Connect your device to your computer with a USB cable. If your computer complains about needing to format a new drive, cancel the format command.
- Double click the `Reset` button on your device, this will put it into boot loader mode.
[<img alt="LILYGO T-Echo" src="/img/hardware/t-echo-lilygo.jpg" style={{zoom:'25%'}} />](/img/hardware/t-echo-lilygo.jpg)

24
docs/getting-started/getting_started.md
View file

@ -11,11 +11,11 @@ Meshtastic® is a project that lets you use inexpensive LoRa radios as a long ra
The radios automatically create a mesh to forward packets as needed, so everyone in the group can receive messages from even the furthest member. The radios will optionally work with your phone, but no phone is required.
Meshtastic uses LoRa for the long range communcations and depending on settings used the maximum theoritical group size ranges from 30-200 device nodes. Currently each device can only support a connection from a single user at a time.
Meshtastic uses LoRa for the long range communications and depending on settings used the maximum theoretical group size ranges from 30-200 device nodes. Currently, each device can only support a connection from a single user at a time.
## Purchase a Radio
The easiest way is to [buy a device with the software already installed](https://www.aliexpress.com/item/4001178678568.html). Other devices are [available](/docs/hardware/tbeam-hardware). In the Americas get the 915mhz version, in Europe the 868Mhz, or Asia 923Mhz. See this listing by [The Things Network](https://www.thethingsnetwork.org/docs/lorawan/frequencies-by-country.html) for frequencies by specific countries.
The easiest way is to [buy a device with the software already installed](https://www.aliexpress.com/item/4001178678568.html). Other devices are [available](/docs/hardware/tbeam-hardware). In the Americas get the 915MHz version, in Europe the 868MHz, or Asia 923MHz. See this listing by [The Things Network](https://www.thethingsnetwork.org/docs/lorawan/frequencies-by-country.html) for frequencies by specific countries.
## Setup the Radio
@ -27,11 +27,11 @@ Make sure not to power the radio on without first attaching the antenna! You cou
## Download Firmware
Firmware can be downloaded from the [Firmware](/firmware) page. Your initial installation has to happen over USB from your Mac, Windows or Linux PC. Once our software is installed, all future software updates happen over bluetooth from your phone.
Firmware can be downloaded from the [Firmware](/firmware) page. Your initial installation has to happen over USB from your Mac, Windows or Linux PC. Once our software is installed, all future software updates happen over Bluetooth from your phone.
## Flashing Firmware
If your device already has Meshtastic flashed to it, You can update it over the air (OTA). Otherwise you'll need a computer and a **data** USB cable. This can be done in the following ways:
If your device already has Meshtastic flashed to it, You can update it over the air (OTA). Otherwise, you'll need a computer and a **data** USB cable. This can be done in the following ways:
- Install using the command line interface (CLI)
- Install using a graphical user interface (GUI)
@ -46,7 +46,7 @@ There are many ways to connect to your new radio!
- Graphic user interface (GUI)
- Serial connection
- Bluetooth
- Web app over wifi (in development)
- Web app over Wifi (in development)
## A good first test (connect via USB and CLI)
@ -67,20 +67,20 @@ The Android app is currently more robust than the iOS app. But, they both should
- Install Android or iOS Meshtastic app
- Start Meshtastic app
- Connect to radio(s) from inside the app
- Pair with radio(s). A paring code should show on the radio. Enter that value when prompted to pair a bluetooth device.
- Note: May want to set the bluetooth timeout (ex: "meshtastic --set wait_bluetooth_secs 28800")
- Pair with radio(s). A paring code should show on the radio. Enter that value when prompted to pair a Bluetooth device.
- Note: May want to set the Bluetooth timeout (ex: "meshtastic --set wait_bluetooth_secs 28800")
- Send message(s) from inside the app.
- Verify that all radios are receiving the messages. Might have to click on the button on the radio to see most recent message.
## A good third test (connect via Wifi/http)
## A good third test (connect via Wifi/HTTP)
- Configure the _wifi_ssid_ and _wifi_password_. "meshtastic --set wifi_ssid 'xxx' --set wifi_password 'yyy'" (where xxx and yyy are the appropriate values for your neetwork)
- Configure the _wifi_ssid_ and _wifi_password_. "meshtastic --set wifi_ssid 'xxx' --set wifi_password 'yyy'" (where xxx and yyy are the appropriate values for your network)
- Reboot radio by either removing power or pressing the power button.
- Click on the button to cycle thru to the screen with ip address and verify that there was a connection to the wifi access point.
- Click on the button to cycle through to the screen with IP address and verify that there was a connection to the Wifi access point.
- Send message(s). "meshtastic --host 192.168.1.200 --sendtext hello"
- Verify that all radios are receiving the messages. Might have to click on the button on the radio(s) to see most recent message.
- Open up a brower to http://meshtastic.local to view the web UI (currently under development). You may need to open http://meshtastic.local/static )
- If you want to switch back to bluetooth, you will need to set the _wifi_ssid_ and _wifi_password_ values to blank values (ex: '').
- Open up a browser to http://meshtastic.local to view the web UI (currently under development). You may need to open http://meshtastic.local/static )
- If you want to switch back to Bluetooth, you will need to set the _wifi_ssid_ and _wifi_password_ values to blank values (ex: '').
## Troubleshooting

8
docs/hardware/antenna/aerials.md
View file

@ -11,7 +11,7 @@ Matching an aerial to the frequency of transmission is important, as is choosing
The aerial's design will affect:
- proportion of the signal which leaves the aerial (efficiency),
- directions in which it's transmitted, and whether it will be affected by horizontal / vertical polarisation,
- directions in which it's transmitted, and whether it will be affected by horizontal / vertical polarization,
- proportion of signal which is reflected back within the device itself.
:::caution
@ -25,8 +25,8 @@ While the LoRa devices we are using for Meshtastic are relatively low power radi
- See this listing by [The Things Network](https://www.thethingsnetwork.org/docs/lorawan/frequencies-by-country.html) for frequencies licensed for specific countries.
- How will you be carrying / transporting the radio?
- A large directional aerial will transmit over significantly greater distance than an omni-directional aerial. However, it must be pointed at its target so isn't optimal for mobile use.
- A tuned half wave whip aerial may have more omni-directional range than the quarter wave stubby; but it will be conspicuous in your pocket.
- Many antennas, especially quater wave stubby antennas, require the use of ground planes to transmit at peak performance.
- A tuned half-wave whip aerial may have more omni-directional range than the quarter wave stubby; but it will be conspicuous in your pocket.
- Many antennas, especially quarter wave stubby antennas, require the use of ground planes to transmit at peak performance.
- Do you want transmission in all directions?
- While humans (mostly water) don't attenuate signal greatly (at LoRa frequencies), buildings & walls do.
- If your aerial is permanently positioned against a building, signal transmitted towards the wall will be largely lost.
@ -42,4 +42,4 @@ While the LoRa devices we are using for Meshtastic are relatively low power radi
You could do a lot worse than reading the [Wikipedia entry for Antenna](https://en.wikipedia.org/wiki/Antenna_(radio)), along with the [Wikipedia entry for LoRa](https://en.wikipedia.org/wiki/LoRa).
Instead of listing the terms, let us recommend this superb [tutorial](https://www.youtube.com/watch?v=J3PBL9oLPX8) by Andreas Speiss (the 'guy with the Swiss accent').
Instead of listing the terms, let us recommend this superb [tutorial](https://www.youtube.com/watch?v=J3PBL9oLPX8) by Andreas Spiess (the 'guy with the Swiss accent').

8
docs/hardware/antenna/antenna.md
View file

@ -9,8 +9,8 @@ slug: /hardware/antenna
If you have sufficient range with your existing aerial, skip this section. If you don't, consider either getting more nodes and / or replace the stock aerial with one tuned (to your region transmitter's frequency):
- A quarter quarter wave _tuned_ stubby aerial (<10cm for fit-in-pocket) should have a real-world range of a couple of km without significant obstacles (buildings / hills).
- Aerial criteria: 50 Ohm, appropriate connector (usually SMA male or U.FL), low VSWR (<2) (at tuning frequency - see its datasheet), gain > 0 dbi .
- A quarter wave _tuned_ stubby aerial (<10cm for fit-in-pocket) should have a real-world range of a couple of km without significant obstacles (buildings / hills).
- Aerial criteria: 50 Ohm, appropriate connector (usually SMA male or U.FL), low VSWR (<2) (at tuning frequency - see its datasheet), gain > 0 dBi .
- Caution, avoid suppliers who:
- don't state the aerial's tuned frequency and its specific purpose (LoRa network)
- claim huge gain figures on omni-directional aerials
@ -20,11 +20,11 @@ If you want more range, directionality, or specificity read on.
## General guidance
The Meshtastic system is designed to be simple and intuitive to use. However, its LoRa radios rely on point to point communications, unit to unit, aerial to aerial; quite different to the near ubiquitous radio coverage of today's cellphone & wi-fi connections.
The Meshtastic system is designed to be simple and intuitive to use. However, its LoRa radios rely on point-to-point communications, unit to unit, aerial to aerial; quite different to the near ubiquitous radio coverage of today's cellphone & Wifi connections.
Some understanding of the factors affecting radio communications will help achieve substantially better service, faster transmission, over a greater range with your devices. Here, we'll attempt to provide a top-level set of guidance for use and aerial selection, how to test the aerials, and a set of resources for further research and plenty of opportunity for going deeper.
The Meshtastic devices (of various flavours) lend themselves to experimentation, not only because you can replace their aerials, but also because of their mesh operation. All nodes will, without alteration, relay communications from any other members of the mesh around obstacles and over greater distances. The cost of aerial investment should be weighed against investment in additional low-cost nodes.
The Meshtastic devices (of various flavors) lend themselves to experimentation, not only because you can replace their aerials, but also because of their mesh operation. All nodes will, without alteration, relay communications from any other members of the mesh around obstacles and over greater distances. The cost of aerial investment should be weighed against investment in additional low-cost nodes.
:::caution
While the LoRa devices we are using for Meshtastic are relatively low power radios, care should be taken _not_ to operate any radio transmission device without an aerial or with a poorly matched aerial. Un-transmitted radio signal reflected back to the transmitter can damage the device.

6
docs/hardware/antenna/non-aerial.md
View file

@ -16,9 +16,9 @@ Unless you're using your devices in a vacuum with clear line of sight between ae
### Environmental factors
For a bit of light reading on environmental research:
- [RF attentuation in vegetation](https://www.itu.int/dms_pubrec/itu-r/rec/p/R-REC-P.833-9-201609-I!!PDF-E.pdf) (yes really); if you wander through the woods wondering how your RF is bouncing off leaves dependent on their variety, and wind speed … well you do, now.
- [RF attentuation with various building materials](https://www.ofcom.org.uk/__data/assets/pdf_file/0016/84022/building_materials_and_propagation.pdf).
- [RF attenuation in vegetation](https://www.itu.int/dms_pubrec/itu-r/rec/p/R-REC-P.833-9-201609-I!!PDF-E.pdf) (yes really); if you wander through the woods wondering how your RF is bouncing off leaves dependent on their variety, and wind speed … well you do, now.
- [RF attenuation with various building materials](https://www.ofcom.org.uk/__data/assets/pdf_file/0016/84022/building_materials_and_propagation.pdf).
- This one by ITU again is very detailed in its [analysis of the drivers of attenuation](https://www.itu.int/dms_pubrec/itu-r/rec/p/R-REC-P.2040-1-201507-I!!PDF-E.pdf) (I wasn’t aware that all EMF radiation exhibits reflection / transmission characteristics akin to light hitting a material boundary. So, depending on the angle of incidence, material and the EMF wavelength, it will be reflected and / or transmitted through).
- These RF bands are also made more [noisy by adjacent LTE](https://www.ofcom.org.uk/__data/assets/pdf_file/0023/55922/lte-coexistence.pdf)
In summary - wavelengths in Europe fair well in plain sight, curve over not-so-tall obstacles (including trees), reflect of surfaces at low angles of incidence. They go through humans without much attenuation; but not brick or stone or anything much above glass / kevlar. Oh, and don’t sit under an LTE tower and expect it to be plain sailing.
In summary - wavelengths in Europe fair well in plain sight, curve over not-so-tall obstacles (including trees), reflect of surfaces at low angles of incidence. They go through humans without much attenuation; but not brick or stone or anything much above glass / Kevlar. Oh, and don’t sit under an LTE tower and expect it to be plain sailing.

6
docs/hardware/antenna/resources.md
View file

@ -46,8 +46,8 @@ slug: /hardware/resources
* [Building an 868/915 MHz co-linear antenna tutorial](https://www.youtube.com/watch?v=1_1LxuOngHs)
* [868 Mhz antenna schematic PDF](https://github.com/IRNAS/ttn-irnas-gw/blob/master/Collinear868MHzLoRaantenna.PDF)
* [915 Mhz antenna schematic PDF](https://github.com/IRNAS/ttn-irnas-gw/blob/master/CollinearLoRaantenna915MHzIRNAS.PDF)
* [868 MHz antenna schematic PDF](https://github.com/IRNAS/ttn-irnas-gw/blob/master/Collinear868MHzLoRaantenna.PDF)
* [915 MHz antenna schematic PDF](https://github.com/IRNAS/ttn-irnas-gw/blob/master/CollinearLoRaantenna915MHzIRNAS.PDF)
* [NEC based antenna modeler and optimizer](https://www.qsl.net/4nec2/)
* [NEC based antenna modeler and optimizer](https://www.qsl.net/4nec2/)

14
docs/hardware/antenna/testing.md
View file

@ -4,13 +4,13 @@ title: Antenna testing
sidebar_label: Testing
---
Testing of antennas can be both simple and complex. At its simplest, testing involves sending messages from different locations and seeing which ones are received and then comparing the results against other antennas. This ranges upto using expensive test chambers and equipment to measure the signal strength, gain and radiation patterns. However, it seems that a reasonable job can be done with cheaper methods.
Testing of antennas can be both simple and complex. At its simplest, testing involves sending messages from different locations and seeing which ones are received and then comparing the results against other antennas. This ranges up to using expensive test chambers and equipment to measure the signal strength, gain and radiation patterns. However, it seems that a reasonable job can be done with cheaper methods.
## Range testing
As mentioned, while stating the obvious, the simplest way of performing test is:
- Walk around with a radio sending messages,
- For each message, note location and whether 'ack' ticks are received,
- For each message, note location and whether 'ACK' ticks are received,
- Also note reported signal strengths,
- Change aerials, repeat & contrast.
@ -18,18 +18,18 @@ As mentioned, while stating the obvious, the simplest way of performing test is:
The [range test plugin](/docs/software/plugins/range-test-plugin) has been designed for exactly this purpose. It allows one node to transmit a frequent message, and another node to record which messages were received. This data is saved and can be imported to applications such as Google Earth.
:::
On the topic of testing - performing your own testing and providing feedback is the lifeblood of Meshtastic and OpenSource projects.
On the topic of testing - performing your own testing and providing feedback is the lifeblood of Meshtastic and open source projects.
## Signal strength testing
Real world testing is also discussed by Andreas Speiss (the 'guy with the Swiss accent') in his [tutorial](https://www.youtube.com/watch?v=J3PBL9oLPX8). He has written [code](https://github.com/SensorsIot/Antenna-Tester) for testing antennas using two Lora32 V1 boards to compare how different antennas behave. Lilygo have also made code available for testing the rssi on the [LORA32](https://github.com/LilyGO/TTGO-LORA32) [boards](https://github.com/Xinyuan-LilyGO/TTGO-LoRa-Series) and the [T-Beam](https://github.com/LilyGO/TTGO-T-Beam).
Real world testing is also discussed by Andreas Spiess (the 'guy with the Swiss accent') in his [tutorial](https://www.youtube.com/watch?v=J3PBL9oLPX8). He has written [code](https://github.com/SensorsIot/Antenna-Tester) for testing antennas using two Lora32 V1 boards to compare how different antennas behave. Lilygo have also made code available for testing the RSSI on the [LORA32](https://github.com/LilyGO/TTGO-LORA32) [boards](https://github.com/Xinyuan-LilyGO/TTGO-LoRa-Series) and the [T-Beam](https://github.com/LilyGO/TTGO-T-Beam).
Here are a [couple](https://medium.com/home-wireless/testing-lora-antennas-at-915mhz-6d6b41ac8f1d) of [excellent](https://medium.com/home-wireless/testing-and-reviewing-lora-antennas-5b37dfa594a3) aerial comparisons. Their utility goes beyond the specific aerials tested, giving insight into:
- Aerial types & their characteristics,
- Testing approaches.
## Antenna matching & vector network analysers
## Antenna matching & vector network analyzers
One of the first things to ensure is that the antenna you have is tuned to the frequency that you are using. A lot of cheap antennas come labeled with an incorrect working frequency, and this will immediately reduce the emittted signal stregth. A Vector Network Analyser (VNA) can be used to ensure that the antenna is appropriately matched to the tranmission circuit, ensuring that it is operating at the correct impeadance and has a low level of power reflected back from the antenna to the transmitter at the desired transmission frequency.
One of the first things to ensure is that the antenna you have is tuned to the frequency that you are using. A lot of cheap antennas come labeled with an incorrect working frequency, and this will immediately reduce the emitted signal strength. A Vector Network Analyzer (VNA) can be used to ensure that the antenna is appropriately matched to the transmission circuit, ensuring that it is operating at the correct impedance and has a low level of power reflected back from the antenna to the transmitter at the desired transmission frequency.
Andeas Speiss also gives a great explanation of [how to use Vector Network Analysers](https://www.youtube.com/watch?v=ZpKoLvqOWyc) to correctly tune your antennas, as well as a more [in depth tutorial of how to use VNAs](https://www.youtube.com/watch?v=_pjcEKQY_Tk). It is important to remember however, that VNAs can only tell you if the antenna is well matched, not how well it is transmitting. A 50 ohm resistor across the transmitter output would show as ideally matched, but it would be useless at transmitting a signal. There are a number of VNAs now available for less than $100, making this no longer out of reach for most hobbiests unlike expensive spectrum analysers.
Andreas Spiess also gives a great explanation of [how to use Vector Network Analyzers](https://www.youtube.com/watch?v=ZpKoLvqOWyc) to correctly tune your antennas, as well as a more [in depth tutorial of how to use VNAs](https://www.youtube.com/watch?v=_pjcEKQY_Tk). It is important to remember however, that VNAs can only tell you if the antenna is well-matched, not how well it is transmitting. A 50 ohm resistor across the transmitter output would show as ideally matched, but it would be useless at transmitting a signal. There are a number of VNAs now available for less than $100, making this no longer out of reach for most hobbyists unlike expensive spectrum analyzers.

2
docs/hardware/buttons.md
View file

@ -4,7 +4,7 @@ title: Modifying devices to add buttons
sidebar_label: Adding buttons
---
Many of the TTGO Lora32 devices do not have a progam button to navigate the displayed pages. It is possible to add a button to the following device:
Many of the TTGO Lora32 devices do not have a program button to navigate the displayed pages. It is possible to add a button to the following device:
## TTGO Lora32 V2.1-1.6

4
docs/hardware/linux.md
View file

@ -8,8 +8,8 @@ This page is a place holder.
The device software can run on Hardware that runs Linux to execute unit tests.
Fledgling support for a Lora USB dongle has been in the works.
Fledgling support for a LoRa USB dongle has been in the works.
This page will be updated with more information as information is made available.
Please be mindful that a lot of this is incomplete, so please don't get too excited and asking for builds and/or timelines.
Please be mindful that a lot of this is incomplete, so please don't get too excited and asking for builds and/or timelines.

6
docs/hardware/lora.md
View file

@ -8,7 +8,7 @@ sidebar_label: LILYGO® Lora
## Lora V1
* ESP32 - Wifi & Bluetooth
* SX1276 - LoRa Tranceiver
* SX1276 - LoRa Transceiver
* Frequency options:
* 868 MHz
* 915 MHz
@ -80,7 +80,7 @@ sidebar_label: LILYGO® Lora
* [Purchase link](https://www.aliexpress.com/item/32915894264.html)
:::warning
Some of these boards contained the wrong component in the lipo battery charging circuit allowing the battery to be overcharged. While this does appear to have been fixed recently, please see the [warning](https://www.thethingsnetwork.org/community/berlin/post/warning-attention-users-of-ttgo21-v16-boards-labeled-t3_v16-on-pcb-battery-exploded-and-got-on-fire) on The Things Network for more information.
Some of these boards contained the wrong component in the LiPo battery charging circuit allowing the battery to be overcharged. While this does appear to have been fixed recently, please see the [warning](https://www.thethingsnetwork.org/community/berlin/post/warning-attention-users-of-ttgo21-v16-boards-labeled-t3_v16-on-pcb-battery-exploded-and-got-on-fire) on The Things Network for more information.
:::
[<img src="/img/hardware/lora-v2.1-1.6.png" alt="LILYGO® TTGO Lora V2.1-1.6" style={{zoom:'25%'}} />](/img/hardware/lora-v2.1-1.6.png)
[<img src="/img/hardware/lora-v2.1-1.6.png" alt="LILYGO® TTGO Lora V2.1-1.6" style={{zoom:'25%'}} />](/img/hardware/lora-v2.1-1.6.png)

8
docs/hardware/overview.md
View file

@ -9,16 +9,16 @@ We currently support devices that use the ESP32 and the nRF52 microcontrollers.
## ESP32
The ESP32 devices have the advantage of having a wifi interface. This allows you to connect to an access point, or run the device as an access point, and host the [web interface](/docs/software/web/web-app-software). Unfortunately the ESP32 does not support Bluetooth 5.0, and so has to wake up from sleep mode every now and then to connect to bluetooth devices to receive messages. This can result in delays sending a message from your phone.
The ESP32 devices have the advantage of having a Wifi interface. This allows you to connect to an access point, or run the device as an access point, and host the [web interface](/docs/software/web/web-app-software). Unfortunately the ESP32 does not support Bluetooth 5.0, and so has to wake up from sleep mode now and then to connect to Bluetooth devices to receive messages. This can result in delays sending a message from your phone.
The following ESP32 devices are supported:
* [Lilygo TTGO T-Beam](/docs/hardware/tbeam-hardware) - versions 0.7, 1.1 (including M8N gps and SX1262 LoRa variants)
* [Lilygo TTGO T-Beam](/docs/hardware/tbeam-hardware) - versions 0.7, 1.1 (including M8N GPS and SX1262 LoRa variants)
* [Lilygo TTGO Lora](/docs/hardware/lora-hardware) - versions 1, 1.3, 2.0, 2.1-1.6
* [Heltec Lora 32 (V2)](/docs/hardware/heltec-hardware)
* [Heltec LoRa 32 (V2)](/docs/hardware/heltec-hardware)
## nRF52
The nRF52 devices have the advantage of a Bluetooth 5.0 implementation. This allows for very low power bluetooth connections to be maintained without having to wake the microprocessor up at regular intervals. Unfortunately, the nRF52 devices do not have wifi built in, meaning that currently you cannot use the web interface with these devices.
The nRF52 devices have the advantage of a Bluetooth 5.0 implementation. This allows for very low power Bluetooth connections to be maintained without having to wake the microprocessor up at regular intervals. Unfortunately, the nRF52 devices do not have Wifi built in, meaning that currently you cannot use the web interface with these devices.
The following nRF52 devices are currently supported:
* [Lilygo TTGO T-Echo](/docs/hardware/techo-hardware)

22
docs/hardware/rak4631.md
View file

@ -16,21 +16,21 @@ To add a GPS to the 5005 base board you need the [1910 GPS sensor](https://store
To add a GPS to the 19003 base board you need the [12500 GPS sensor](https://store.rakwireless.com/products/wisblock-gnss-location-module-rak12500) it is supported via I2C on slot B for firmware versions 1.49 and above.
Flashing the firmware is a simple process connect your device via usb and click the reset button twice and a drive will appear on Windows Linux or Mac drag the appropriate .uf2 firmware file onto the root of the drive and the firmware will be updated.
Flashing the firmware is a simple process connect your device via USB and click the reset button twice and a drive will appear on Windows Linux or Mac drag the appropriate .uf2 firmware file onto the root of the drive and the firmware will be updated.
There is currently no pin required to pair RAK devices via BLE.
* nRF52840 - Bluetooth BLE 5.0 and very low power consumption
* SX1262 - LoRa transceiver
* Frequency options:
* 433 Mhz
* 470 Mhz
* 799 Mhz
* 865 Mhz
* 868 Mhz
* 915 Mhz
* 920 Mhz
* 923 Mhz
* 433 MHz
* 470 MHz
* 799 MHz
* 865 MHz
* 868 MHz
* 915 MHz
* 920 MHz
* 923 MHz
* Optional GPS
* U.FL antenna connector
* Optional switches
@ -40,7 +40,7 @@ There is currently no pin required to pair RAK devices via BLE.
* Firmware for 5005 base board: [`firmware-rak4631_5005-1.x.x.uf2`](https://meshtastic.org/firmware)
* Firmware for 19003 base board: [`firmware-rak4631_19003-1.x.x.uf2`](https://meshtastic.org/firmware)
* [Installation instructions](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK4631/Quickstart/#rak4631-lora-mesh-via-meshtastic)
* Dont forget to [update the bootloader](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK4631/Quickstart/#updating-the-bootloader) first!
* Don't forget to [update the bootloader](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK4631/Quickstart/#updating-the-bootloader) first!
* RAK's [GitHub Page](https://github.com/RAKWireless/WisBlock) for the WisBlock
<img alt="RAK4631 Core Module" src="/img/hardware/rak4631.png" style={{zoom:'50%'}} />
<img alt="RAK4631 Core Module" src="/img/hardware/rak4631.png" style={{zoom:'50%'}} />

2
docs/hardware/tbeam.md
View file

@ -34,7 +34,7 @@ This is an earlier version of the T-Beam board, and due to changes in the design
:::
* ESP32 - Wifi & Bluetooth
* SX1276 - LoRa Tranceiver
* SX1276 - LoRa Transceiver
* Frequency options:
* 868 MHz
* 915 MHz

4
docs/legal/licensing.md
View file

@ -3,8 +3,8 @@ id: licensing
title: Licensing & Commercial Projects Usage
sidebar_label: Licensing
---
You are hereby granted a two year non-exclusive license to use the Meshtastic® logo and trademark on your product/project. No fee is required for this usage, though if you wish keeping $1/unit set-aside so that it can eventually fund [meshtastic.org](https://meshtastic.org) it would be appreciated.
You are hereby granted a two-year non-exclusive license to use the Meshtastic® logo and trademark on your product/project. No fee is required for this usage, though if you wish keeping $1/unit set-aside so that it can eventually fund [meshtastic.org](https://meshtastic.org) it would be appreciated.
We only ask that you include a line in your support text that states:
> Meshtastic® is a registered trademark of Geeksville Industries LLC. Meshtastic software components are released under various licenses, see github for details. No warranty is provided - use at your own risk.
> Meshtastic® is a registered trademark of Geeksville Industries LLC. Meshtastic software components are released under various licenses, see GitHub for details. No warranty is provided - use at your own risk.

4
docs/legal/overview.md
View file

@ -8,7 +8,7 @@ slug: /legal
This project is still pretty young but moving at a pretty good pace. Not all features are fully implemented in the current alpha builds.
* We don't make these devices and they haven't been tested by UL or the FCC. If you use them you are experimenting and we can't promise they won't burn your house down ;-)
* We don't make these devices and they haven't been tested by UL or the FCC. If you use them, you are experimenting and we can't promise they won't burn your house down ;-)
* The encryption implementation is good but see this list of [caveats](/docs/developers/device/encryption#summary-of-strengthsweaknesses-of-our-current-implementation) to determine risks you might face.
## Legal FAQ
@ -21,4 +21,4 @@ Nope. though if some other person/group wanted to use this software and a more c
(Kindly borrowed from the geeks at [ffmpeg](http://ffmpeg.org/legal.html))
We do not know, we are not lawyers so we are not qualified to answer this. Also we have never read patents to implement any part of this, so even if we were qualified we could not answer it as we do not know what is patented. Furthermore the sheer number of software patents makes it impossible to read them all so no one (lawyer or not) could answer such a question with a definite no. We are merely geeks experimenting on a fun and free project.
We do not know, we are not lawyers so we are not qualified to answer this. Also, we have never read patents to implement any part of this, so even if we were qualified we could not answer it as we do not know what is patented. Furthermore, the sheer number of software patents makes it impossible to read them all, so no one (lawyer or not) could answer such a question with a definite no. We are merely geeks experimenting on a fun and free project.

4
docs/legal/privacy.md
View file

@ -14,6 +14,6 @@ Maps provided by Mapbox require analytics to work. For more information about wh
The search engine for this website is provided by Algolia, please see their [privacy policy](https://www.algolia.com/policies/privacy/) for details of what information they collect.
This is an open-source project run by hobbyists and we try to be completely transparent. If you have questions on this policy, please post on the forum and we'll reply/clarify/correct.
This is an open-source project run by hobbyists, and we try to be completely transparent. If you have questions on this policy, please post on the forum, and we'll reply/clarify/correct.
Keep being awesome!
Keep being awesome!

2
docs/legal/trademark.md
View file

@ -3,4 +3,4 @@ id: trademark
title: Trademark Rules & Brand Guidelines
sidebar_label: Trademark
---
Meshtastic® is a registered trademark of Geeksville Industries LLC. Meshtastic software components are released under various licenses, see github for details. No warranty is provided - use at your own risk.
Meshtastic® is a registered trademark of Geeksville Industries LLC. Meshtastic software components are released under various licenses, see GitHub for details. No warranty is provided - use at your own risk.

8
docs/software/android/installation.md
View file

@ -3,25 +3,25 @@ id: android-installation
title: Android application installation
sidebar_label: Installation
---
~~Our Android application is available to download on Google Play.~~ Our Google Play listing has been removed by google due to a recent policy change by them with respect to the background location accesss (which our app needs). We've started the '[appeal](/docs/software/android/location-access)' process, but for now you'll need to get the app from other places.
~~Our Android application is available to download on Google Play.~~ Our Google Play listing has been removed by google due to a recent policy change by them with respect to the background location access (which our app needs). We've started the '[appeal](/docs/software/android/location-access)' process, but for now you'll need to get the app from other places.
The app is also available on the Amazon [Appstore](https://www.amazon.com/Geeksville-Industries-Meshtastic/dp/B08CY9394Q). You will need to install the Amazon Appstore onto your phone in order to install the Meshtastic application.
<p align="center"><a href="https://play.google.com/store/apps/details?id=com.geeksville.mesh&referrer=utm_source%3Dgithub-homepage"><img alt="Download at https://play.google.com/store/apps/details?id=com.geeksville.mesh" src="https://play.google.com/intl/en_us/badges/static/images/badges/en_badge_web_generic.png" style={{zoom:'35%'}} /></a> <a href="https://www.amazon.com/Geeksville-Industries-Meshtastic/dp/B08CY9394Q"><img alt="Download at https://www.amazon.com/Geeksville-Industries-Meshtastic/dp/B08CY9394Q" src="/img/amazon-fire-button.png" style={{zoom:'20%',padding:'3.5em'}} /></a></p>
The application may not be found if your phone/Android version are too old. The minimum Android version is 5.0 (Lollipop 2014, first BLE support). However Android 6, Marshmallow 2015, is recommended as the Bluetooth is more stable.
The application may not be found if your phone/Android version are too old. The minimum Android version is 5.0 (Lollipop 2014, first BLE support). However, Android 6, Marshmallow 2015, is recommended as the Bluetooth is more stable.
The app can also be sideloaded by downloading the .apk from the <a href="https://github.com/meshtastic/Meshtastic-Android/releases/latest">GitHub releases</a> page. If you do sideload, you may have to give your browser permissions to run a package installer. If you wish to view the code or contribute to development of the app, please visit the app's <a href="https://github.com/meshtastic/Meshtastic-Android">GitHub page</a>.
:::note
Be aware that you may have to open the drop down menu for "Compare" to see the latest alpha/beta builds. Generally the versions will follow the device versions.
:::
After installing the Meshtastic app, open it and navigate to the settings page. The app will ask you to give it permissions to access your location. This is needed for any app to use bluetooth, as the app is then able to scan the local area for bluetooth devices. If you give location permissions "only while using the app", the app will only be able to use bluetooth while it is open and visible to the user. This means if the screen is locked, or you are using another app, Meshtastic will not be able to use bluetooth, and will not be able to receive any messages from the node.
After installing the Meshtastic app, open it and navigate to the settings page. The app will ask you to give it permissions to access your location. This is needed for any app to use Bluetooth, as the app is then able to scan the local area for Bluetooth devices. If you give location permissions "only while using the app", the app will only be able to use Bluetooth while it is open and visible to the user. This means if the screen is locked, or you are using another app, Meshtastic will not be able to use Bluetooth, and will not be able to receive any messages from the node.
[![Messages page](/img/android/android-messages-sm.png)](/img/android/android-messages-sm.png) [![Nodes page](/img/android/android-nodes-sm.png)](/img/android/android-nodes.png) [![Channel page](/img/android/android-channel-sm.png)](/img/android/android-channel.png) [![Settings page](/img/android/android-settings-sm.png)](/img/android/android-settings.png) [![Debug page](/img/android/android-debug-sm.png)](/img/android/android-debug.png)
:::note
Be aware that every OS has a different way of handling permissions. In order to prevent the user from accidently allowing background location services, the dialog box may not give you the option.
Be aware that every OS has a different way of handling permissions. In order to prevent the user from accidentally allowing background location services, the dialog box may not give you the option.
Click on the image to see a quick video of where I found it on my phone.

24
docs/software/android/location-access.md
View file

@ -2,21 +2,21 @@
Google Play has some newish requirements for access to background location. This doc is a collection of work items needed to meet those requirements.
The app is currently removed from the play store ([broken store link](https://play.google.com/store/apps/details?id=com.geeksville.mesh)), and some kind googlers inside of google are helping with this problem. **Hopefully** it will be
relisted soon (while we address these newish requirements), but we've got to do a bit of code to add a new dialog (and make a video for google). It will take about a week to make these changes (including testing time with the [alpha-tester group](https://meshtastic.discourse.group/c/development/alpha-testers/) on the forum).
The app is currently removed from the Play Store ([broken store link](https://play.google.com/store/apps/details?id=com.geeksville.mesh)), and some kind Googlers inside of Google are helping with this problem. **Hopefully** it will be
relisted soon (while we address these newish requirements), but we've got to do a bit of code to add a new dialog (and make a video for Google). It will take about a week to make these changes (including testing time with the [alpha-tester group](https://meshtastic.discourse.group/c/development/alpha-testers/) on the forum).
Until relisted in the play store (hopefully they can relist while we make these fixes), you'll need to install [raw APKs from github](https://github.com/meshtastic/Meshtastic-Android/releases). Which is not ideal, but works.
Until relisted in the Play Store (hopefully they can relist while we make these fixes), you'll need to install [raw APKs from GitHub](https://github.com/meshtastic/Meshtastic-Android/releases). Which is not ideal, but works.
Sorry ya'll.
(The remainder of this public document is mostly for googlers)
(The remainder of this public document is mostly for Googlers)
## Why this app needs "foreground location access"
We need foreground location access for two reaons:
We need foreground location access for two reasons:
* (Primarily) [This app](https://github.com/meshtastic/Meshtastic-Android) is a navigation app that uses long range LoRa mesh radios for communication in the back country. These radios can run for weeks on a charge and talk to the user's phone over USB or bluetooth to provide the UX. We need foreground location so we can show the user's current position on the same map that is showing positions of the other users.
* (Secondarily) Using the old bluetooth BLE API (which we need to use to support older devices), scanning for bluetooth low energy devices requires this permission (because 'beacons' etc... could leak location info to the app). Without this permission (on older phones) the BLE discovery results are always empty.
* (Primarily) [This app](https://github.com/meshtastic/Meshtastic-Android) is a navigation app that uses long range LoRa mesh radios for communication in the back country. These radios can run for weeks on a charge and talk to the user's phone over USB or Bluetooth to provide the UX. We need foreground location so we can show the user's current position on the same map that is showing positions of the other users.
* (Secondarily) Using the old Bluetooth BLE API (which we need to use to support older devices), scanning for Bluetooth low energy devices requires this permission (because 'beacons' etc... could leak location info to the app). Without this permission (on older phones) the BLE discovery results are always empty.
If it is helpful, [here](https://meshtastic.org/docs/software/android/android-usage) is a slightly stale set of screenshots/instructions showing how the user uses our application.
@ -34,11 +34,11 @@ Since we need background location access for the app to work, we need to do thre
per https://support.google.com/googleplay/android-developer/answer/9799150
### TODO: Update play store listing
### TODO: Update Play Store listing
The existing text explains what the app does, but it needs to be even more explicit:
Requirements from google site:
Requirements from Google site:
If you plan to use location in the background in your app, you should communicate this to users in the Google Play Store Listing via your app description, screenshots and (if applicable) title or icon.
Here are some suggestions on how to highlight use of location in the background to users:
@ -51,7 +51,7 @@ If applicable, your app title or icon may also signal the location feature of yo
We currently explain why we need location access on the settings page and in the help. But we need a new dialog at launch, which needs to be **super** explicit:
Requirements from google site:
Requirements from Google site:
Must be within the app itself, not only in the app description or on a website;
Must be displayed in the normal usage of the app and not require the user to navigate into a menu or settings;
Must describe the data being accessed or collected;
@ -78,7 +78,7 @@ Note: If the feature does not have a user-facing interface when location in the
I'm awful at making videos, so I'll ask someone from the [forum](https://meshtastic.discourse.group/) to help with this!
Requirements from google site:
Requirements from Google site:
As part of the permissions declaration, you must provide a link to a short video that demonstrates the location-based feature in your app that requires access to location in the background (while the app is not in use).
You can see an example of what this video demonstration should look like below.
@ -97,4 +97,4 @@ The recommended duration is 30 seconds or less. A YouTube link is the preferred
Note:
If the feature does not have a user-facing interface when location in the background is active, please note this in your declaration and demonstrate the feature or its impacts as much as possible in the video.
Ensure that your video is made using an Android device.
Ensure that your video is made using an Android device.

20
docs/software/android/usage.md
View file

@ -19,7 +19,7 @@ You will need a device with Meshtastic installed to go any further. See the [get
Open the Settings tab (last tab), and it should look similar to the screen below. It shows any Meshtastic devices that are found over Bluetooth.
:::note
Android requires location permission granted and location must be turned on to find new devices via bluetooth. You can turn it off again afterwards.
Android requires location permission granted and location must be turned on to find new devices via Bluetooth. You can turn it off again afterwards.
:::
[![Device available to select](/img/android/android-settings-deselected-c.png)](/img/android/android-settings-deselected.png)
@ -50,7 +50,7 @@ The cloud icon at the top right corner indicates if you are connected to a devic
## Common tasks
Once you are connected to a Device the App will work, and you can test it by "sending" a message. However you will need to join or create a new mesh network so you have someone to communicate with. If you have been sent a QR code or link for Meshtastic, then skip ahead to Join a Channel, otherwise you will need to Setup a Channel.
Once you are connected to a Device the App will work, and you can test it by "sending" a message. However, you will need to join or create a new mesh network so you have someone to communicate with. If you have been sent a QR code or link for Meshtastic, then skip ahead to Join a Channel, otherwise you will need to Setup a Channel.
### Setup a channel
@ -85,7 +85,7 @@ You should see a message with the option "open with Meshtastic".
If you don't see "Meshtastic" as an option to open the file or link with:<br />
1. Go to Android Settings > Apps > Default apps > Meshtastic > Opening links<br />
2. Make sure you have in "links/web address": www.meshtastic.org<br />
3. If you see the option "Open the supported links" make sure it is enabled.<br />
3. If you see the option "Open the supported links", make sure it is enabled.<br />
</div>
</div>
</details>
@ -122,10 +122,10 @@ The message window operates like any chat applications. Note that any messages s
With LoRa (or any radio) there is some uncertainty that the messages has been received, so there is a confirmation built-in to the protocol. There are small cloud icons shown to the right of the messages you send:
* Cloud with an up arrow: the application is waiting for the device to some out of sleep mode (or come back into bluetooth range), to upload the message to the device.
* Cloud with an up arrow: the application is waiting for the device to some out of sleep mode (or come back into Bluetooth range), to upload the message to the device.
* Cloud only: message has been sent via Bluetooth and transmitted via LoRa.
* Cloud with a check mark: message has been delivered to at least one node in the mesh and at least one node sent back a confirmation (successfully received by the initial sender).
* Cloud crossed out: message may have been delivered to at least one node in the mesh. If at least one node sent a confirmation back the initial sender did not receive the confirmation within a certain timeout.
* Cloud crossed out: message may have been delivered to at least one node in the mesh. The initial sender did not receive at least one node's confirmation within a certain timeout.
Thus, in a group size of 3 and up, confirmations could be from any one device (not person), so it is good practice to respond, so the initial sender knows you have read their message.
@ -147,12 +147,12 @@ The Map tab will show a local map with an icon for each active mesh node that ha
[![Mapping provided by Mapbox](/img/android/android-map-sm.png)](/img/android/android-map.png)
The map is not developed by the Meshtastic project, and the source of the mapping system is [Mapbox](https://docs.mapbox.com/help/how-mapbox-works/) (free-tier), and the map data is sourced from [OpenStreetMap OSM](https://www.openstreetmap.org/). Mapbox currently requires analytics to be enabled for you to use their mapping system. There is currently no off-line maps (phone needs mobile data or wifi), although this will be improved in the future. If you don't see the features that you'd expect on the map then head over to [OpenStreetMap OSM](https://www.openstreetmap.org/) where you can contribute new data to the map.
The map is not developed by the Meshtastic project, and the source of the mapping system is [Mapbox](https://docs.mapbox.com/help/how-mapbox-works/) (free-tier), and the map data is sourced from [OpenStreetMap OSM](https://www.openstreetmap.org/). Mapbox currently requires analytics to be enabled for you to use their mapping system. There is currently no off-line maps (phone needs mobile data or Wifi), although this will be improved in the future. If you don't see the features that you'd expect on the map then head over to [OpenStreetMap OSM](https://www.openstreetmap.org/) where you can contribute new data to the map.
## Configuration options
Pressing the three verticle dots in the top right corner shows the configuration menu.
Pressing the three vertical dots in the top right corner shows the configuration menu.
[![Meshtastic configuration options](/img/android/android-settings-options-c.png)](/img/android/android-settings-options.png)
@ -162,7 +162,7 @@ Pressing the three verticle dots in the top right corner shows the configuration
#### Broadcast position period
This allows you to change the frequency with which your location is broadcast across the mesh. By default this is set to 900 seconds (15 minutes). The minimum time this can be set to is 375 seconds, the reasons for which have been [discussed on the forum](https://meshtastic.discourse.group/t/lost-messages-while-testing/2455/19).
This allows you to change the frequency with which your location is broadcast across the mesh. By default, this is set to 900 seconds (15 minutes). The minimum time this can be set to is 375 seconds, the reasons for which have been [discussed on the forum](https://meshtastic.discourse.group/t/lost-messages-while-testing/2455/19).
#### Device sleep period
@ -174,9 +174,9 @@ By default, ESP32 devices will enter sleep mode after 300 seconds of inactivity
The debug page allows you to see all packets sent between the application and the device. This can then be used for debugging purposes.
### Save messages as csv
### Save messages as CSV
This allows you to save your messages to a .csv (comma sparated value) file on your phone.
This allows you to save your messages to a .csv (comma separated value) file on your phone.
### Theme

2
docs/software/community/go.md
View file

@ -10,7 +10,7 @@ Development can be followed on [GitHub](https://github.com/lmatte7/meshtastic-go
Support should be sought from the respective authors.
:::
This is a command line interface for Meshtastic devices that has been built using the Go programming language developed by Google. This allows for an executable file to be downloaded for your operating system and run without installing other pre-requisits. The only requirement is for the [CP210x USB to UART bridge drivers](https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers) to be installed. A selection of executables for different operating systems are available, and further operating systems can be supported as required.
This is a command line interface for Meshtastic devices that has been built using the Go programming language developed by Google. This allows for an executable file to be downloaded for your operating system and run without installing other pre-requisites. The only requirement is for the [CP210x USB to UART bridge drivers](https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers) to be installed. A selection of executables for different operating systems are available, and further operating systems can be supported as required.
### Command syntax

4
docs/software/community/overview.md
View file

@ -8,7 +8,7 @@ The Meshtastic ecosystem is highly extensible, and a number of community project
Current community projects:
* Meshtastic plugin for ATAK (Android Team Awareness Kit)
* PyGUI - Platform independant graphical user interface for Meshtastic devices
* Go CLI - A command line interface using Go that requires no pre-requisits to be installed
* PyGUI - Platform independent graphical user interface for Meshtastic devices
* Go CLI - A command line interface using Go that requires no pre-requisites to be installed
Support for these projects should be sought from their respective authors.

2
docs/software/community/pygui.md
View file

@ -10,7 +10,7 @@ Development can be followed on [GitHub](https://github.com/ZebusJesus/Meshtastic
Support should be sought from the respective authors.
:::
PyGUI is a platform independant graphical user interface for meshtastic devices. It allows the sending of messages, changing of a lot of settings, monitoring of packets, and uploading firmware.
PyGUI is a platform independent graphical user interface for meshtastic devices. It allows the sending of messages, changing of a lot of settings, monitoring of packets, and uploading firmware.
![Python GUI](/img/pygui.jpg)

4
docs/software/device/channels.md
View file

@ -12,9 +12,9 @@ Version 1.2 of the software adds support for multiple (simultaneous) channels.
### What is the Primary channel
The way this works is that each node keeps a list of channels it knows about. One of those channels (normally the first one) is labelled as the "PRIMARY" channel. The primary channel is the **only** channel that is used to set radio parameters. This channel controls things like spread factor, coding rate, bandwidth etc... Indirectly this channel also is used to select the specific frequency that all members of this mesh are talking over.
The way this works is that each node keeps a list of channels it knows about. One of those channels (normally the first one) is labeled as the "PRIMARY" channel. The primary channel is the **only** channel that is used to set radio parameters. This channel controls things like spread factor, coding rate, bandwidth etc... Indirectly this channel also is used to select the specific frequency that all members of this mesh are talking over.
This channel may or may not have a PSK (encryption). If you are providing mesh to 'the public' we recommend that you always leave this channel with its default psk. The default PSK is technically encrypted (and random users sniffing the ether would have to use Meshtastic to decode it), but the key is included in the github source code and you should assume any 'attacker' would have it. But for a 'public' mesh you want this, because it allows anyone using Meshtastic in your area to send packets through 'your' mesh.
This channel may or may not have a PSK (encryption). If you are providing mesh to 'the public' we recommend that you always leave this channel with its default PSK. The default PSK is technically encrypted (and random users sniffing the ether would have to use Meshtastic to decode it), but the key is included in the GitHub source code and you should assume any 'attacker' would have it. But for a 'public' mesh you want this, because it allows anyone using Meshtastic in your area to send packets through 'your' mesh.
```bash title="Setting default channel"
$ meshtastic --seturl https://www.meshtastic.org/d/#CgUYAyIBAQ

6
docs/software/device/critical-faults.md
View file

@ -12,12 +12,12 @@ This table is derived from the [protobufs](/docs/developers/protobufs/api#critic
| Name | Number | Description |
| ---- | ------ | ----------- |
| TxWatchdog | 1 | A software bug was detected while trying to send lora |
| TxWatchdog | 1 | A software bug was detected while trying to send LoRa |
| SleepEnterWait | 2 | A software bug was detected on entry to sleep |
| NoRadio | 3 | No Lora radio hardware could be found |
| NoRadio | 3 | No LoRa radio hardware could be found |
| Unspecified | 4 | Not normally used |
| UBloxInitFailed | 5 | We failed while configuring a UBlox GPS |
| NoAXP192 | 6 | This board was expected to have a power management chip and it is missing or broken |
| InvalidRadioSetting | 7 | The channel tried to set a radio setting which is not supported by this chipset, radio comms settings are now undefined. |
| TransmitFailed | 8 | Radio transmit hardware failure. We sent data to the radio chip, but it did not reply with an interrupt. |
| Brownout | 9 | We detected that the main CPU voltage dropped below the minumum acceptable value |
| Brownout | 9 | We detected that the main CPU voltage dropped below the minimum acceptable value |

8
docs/software/device/firmware.md
View file

@ -18,13 +18,13 @@ A number of devices support buttons that can be used to interact with the firmwa
- Power button - This is present on some devices. A long press powers the device off or turns it back on again.
- Program button - This is present of some devices and has a number of functions:
- Single press - This changes the page of information displayed on the screen.
- Double press - This sets the bluetooth pairing code to `123456` (useful if you do not have a screen on the device).
- Double press - This sets the Bluetooth pairing code to `123456` (useful if you do not have a screen on the device).
- Long press - This adjusts the contrast of the screen.
- Long press during reboot - This turns on the software wifi access point on devices that support wifi.
- Long press during reboot - This turns on the software Wifi access point on devices that support Wifi.
### Screens
A number of devices have screens capable of displaying the messages received and information about the mesh and other details. On powering the device it will display the Meshtastic splashscreen for a couple of seconds:
A number of devices have screens capable of displaying the messages received and information about the mesh and other details. On powering the device it will display the Meshtastic splash screen for a couple of seconds:
![Splash screen](/img/screen/mesh-splash.jpg)
@ -44,7 +44,7 @@ The final page shows current battery voltage and capacity, as well as noting how
![GPS page](/img/screen/mesh-gps.jpg)
If the device wifi has been enabled (only possible on ESP32 devices), another page appears displaying information about the WiFi settings, IP address and number of devices connected to the WiFi.
If the device Wifi has been enabled (only possible on ESP32 devices), another page appears displaying information about the WiFi settings, IP address and number of devices connected to the WiFi.
![Wifi page](/img/screen/mesh-wifi.jpg)

14
docs/software/device/power.md
View file

@ -10,27 +10,27 @@ Long battery life is one of the main goals of this project. Based on initial mea
From lower to higher power consumption.
- Super-deep-sleep (SDS) - everything is off, CPU, radio, bluetooth, GPS. Only wakes due to timer or button press. We enter this mode only after no radio comms for a few hours, used to put the device into what is effectively "off" mode.
- Super-deep-sleep (SDS) - everything is off, CPU, radio, Bluetooth, GPS. Only wakes due to timer or button press. We enter this mode only after no radio comms for a few hours, used to put the device into what is effectively "off" mode.
* onEntry: setBluetoothOn(false), call doDeepSleep
* onExit: (standard bootup code, starts in DARK)
- deep-sleep (DS) - CPU is off, radio is on, bluetooth and GPS is off. Note: This mode is never used currently, because it only saves 1.5mA vs light-sleep - (Not currently used).
- light-sleep (LS) - CPU is suspended (RAM stays alive), radio is on, bluetooth is off, GPS is off. Note: currently GPS is not turned off during light sleep, but there is a TODO item to fix this.
- deep-sleep (DS) - CPU is off, radio is on, Bluetooth and GPS is off. Note: This mode is never used currently, because it only saves 1.5mA vs light-sleep - (Not currently used).
- light-sleep (LS) - CPU is suspended (RAM stays alive), radio is on, Bluetooth is off, GPS is off. Note: currently GPS is not turned off during light sleep, but there is a TODO item to fix this.
* NOTE: On NRF52 platforms (because CPU current draw is so low), light-sleep state is never used.
* onEntry: setBluetoothOn(false), setGPSPower(false), doLightSleep()
* onIdle: (if we wake because our led blink timer has expired) blink the led then go back to sleep until we sleep for ls_secs
* onExit: setGPSPower(true), start trying to get gps lock: gps.startLock(), once lock arrives service.sendPosition(BROADCAST)
- No bluetooth (NB) - CPU is running, radio is on, GPS is on but bluetooth is off, screen is off.
* onExit: setGPSPower(true), start trying to get GPS lock: gps.startLock(), once lock arrives service.sendPosition(BROADCAST)
- No Bluetooth (NB) - CPU is running, radio is on, GPS is on but Bluetooth is off, screen is off.
* onEntry: setBluetoothOn(false)
* onExit:
- running dark (DARK) - Everything is on except screen.
* onEntry: setBluetoothOn(true)
* onExit:
- serial API usage (SERIAL) - Screen is on, device doesn't sleep, bluetooth off.
- serial API usage (SERIAL) - Screen is on, device doesn't sleep, Bluetooth off.
* onEntry: setBluetooth off, screen on
* onExit:
- full on (ON) - Everything is on, can eventually timeout and lower to a lower power state.
* onEntry: setBluetoothOn(true), screen.setOn(true)
* onExit: screen->setOn(false)
- has power (POWER) - Screen is on, device doesn't sleep, bluetooth on, will stay in this state as long as we have power.
- has power (POWER) - Screen is on, device doesn't sleep, Bluetooth on, will stay in this state as long as we have power.
* onEntry: setBluetooth off, screen on
* onExit:

10
docs/software/device/remote-admin.md
View file

@ -1,14 +1,14 @@
---
id: device-remote-admin
title: Remote node administration
sidebar_label: Remote node admininstration
sidebar_label: Remote node administration
---
This feature will allow you to use the multiple channels feature to enable remote adminstration of meshtastic nodes. This will let you talk through the mesh to some far away node and change that node's settings. This is an advanced feature that (currently) few users would need. Also, keep in mind it is possible (if you are not careful) to assign settings to that remote node that cause it to completely drop off of your mesh. We advise network admins have a test node to test settings with before applying changes to a remote node to prevent this.
This feature will allow you to use the multiple channels feature to enable remote administration of meshtastic nodes. This will let you talk through the mesh to some far away node and change that node's settings. This is an advanced feature that (currently) few users would need. Also, keep in mind it is possible (if you are not careful) to assign settings to that remote node that cause it to completely drop off of your mesh. We advise network admins have a test node to test settings with before applying changes to a remote node to prevent this.
## Creating the admin channel
By default, nodes will **only** respond to adminstrative commands via the local USB/bluetooth/TCP interface. This provides basic security to prevent unauthorized access and is how normal administration and settings changes work. The only difference for the remote case is that we are sending those commands over the mesh.
By default, nodes will **only** respond to administrative commands via the local USB/Bluetooth/TCP interface. This provides basic security to prevent unauthorized access and is how normal administration and settings changes work. The only difference for the remote case is that we are sending those commands over the mesh.
Before a node will allow remote admin access, it must have a primary channel:
```bash title="Expected output"
@ -47,7 +47,7 @@ Primary channel URL: https://www.meshtastic.org/d/#CgUYAyIBAQ
Complete URL (includes all channels): https://www.meshtastic.org/d/#CgUYAyIBAQopIiAdbsTecxuI1u-voyGwOicsKaPt5ICG23ONsjH-vk5CaCoFYWRtaW4
```
Notice that now we have a new secondary channel and the `--info` option prints out TWO URLs. The `Complete URL` includes all of the channels this node understands. The URL contains the preshared keys and should be treated with caution and kept a secret. When deploying remote adminstration, you only need the node you want to administer and the node you are locally connected to know this new "admin" channel. All of the other nodes will forward the packets as long as they are a member of the primary channel.
Notice that now we have a new secondary channel and the `--info` option prints out TWO URLs. The `Complete URL` includes all of the channels this node understands. The URL contains the preshared keys and should be treated with caution and kept a secret. When deploying remote administration, you only need the node you want to administer and the node you are locally connected to know this new "admin" channel. All of the other nodes will forward the packets as long as they are a member of the primary channel.
## Sharing the admin channel with other nodes
@ -145,4 +145,4 @@ For further reading, I recommend starting out with [Meshtastic-python](../python
## Areas for future development
In the future we will add a "deadman timer" to this feature so that the remote node will revert any changes if you fail to send a special "commit changes" command. This will protect against sending bad settings to nodes that you can't physically access. Instead if the node does not receive a commit message within 10 minutes it will revert all changes and (hopefully) rejoin the mesh.
In the future we will add a "deadman timer" to this feature so that the remote node will revert any changes if you fail to send a special "commit changes" command. This will protect against sending bad settings to nodes that you can't physically access. Instead, if the node does not receive a commit message within 10 minutes it will revert all changes and (hopefully) rejoin the mesh.

8
docs/software/device/remote-hardware-service.md
View file

@ -9,7 +9,7 @@ GPIO access is fundamentally dangerous because invalid options can physically da
:::
:::note
This feature uses a preinstalled plugin in the device code and associated commandline flags/classes in the python code. You'll need to be running at least version 1.2.23 (or later) of the python and device code to use this feature.
This feature uses a preinstalled plugin in the device code and associated command line flags/classes in the python code. You'll need to be running at least version 1.2.23 (or later) of the python and device code to use this feature.
:::
You can get the latest python tool/library with `pip3 install --upgrade meshtastic` on Windows/Linux/OS-X. See the [python section](/docs/software/python/python-installation) for more details.
@ -29,7 +29,7 @@ To prevent access from untrusted users you must first make a `gpio` channel that
The procedure using the python command line tool is:
1. Connect local device via USB
2. Create a GPIO channel
2. Create a gpio channel
```bash
meshtastic --ch-add gpio
```
@ -38,7 +38,7 @@ The procedure using the python command line tool is:
meshtastic --info
```
4. Connect the remote device via USB (or use the [remote admin](device-remote-admin) feature to reach it through the mesh)
5. Set it to join the GPIO channel you created
5. Set it to join the gpio channel you created
```bash
meshtastic --seturl theurlyoucopiedinstep3
```
@ -75,4 +75,4 @@ Received RemoteHardware typ=GPIOS_CHANGED, gpio_value=16
Received RemoteHardware typ=GPIOS_CHANGED, gpio_value=0
Received RemoteHardware typ=GPIOS_CHANGED, gpio_value=16
< press ctrl-c to exit >
```
```

4
docs/software/device/wifi.md
View file

@ -33,7 +33,7 @@ http://meshtastic.local
* * * * *
```
You should then be able to connect to the node using either the displayed IP address or the http link.
You should then be able to connect to the node using either the displayed IP address or the HTTP link.
To disable the WiFi, set the preferences to empty strings.
@ -47,7 +47,7 @@ Writing modified preferences to device
## Setting up WiFi in AP mode
The device can also be set up in access point mode and is capable of hosting upto four connected devices. The access point is enalbed by setting the following preferences:
The device can also be set up in access point mode and is capable of hosting up to four connected devices. The access point is enabled by setting the following preferences:
* `wifi_ap_mode`
* `wifi_ssid`

2
docs/software/js/connecting.md
View file

@ -4,7 +4,7 @@ title: Connecting to a device
sidebar_label: Connecting
---
Currently Two connection methods are supported, HTTP and BLE.
Currently, two connection methods are supported, HTTP and BLE.
## HTTP

8
docs/software/js/events.md
View file

@ -6,15 +6,15 @@ sidebar_label: Events
## Preface
The event system that the library uses is provided by RxJS, this is the fundamental way in which to interract with tevices and the mesh network.
The event system that the library uses is provided by RxJS, this is the fundamental way in which to interact with devices and the mesh network.
:::tip
Full guide to using RxJS is avaliable at [rxjs.dev](https://rxjs.dev/guide/overview)
Full guide to using RxJS is available at [rxjs.dev](https://rxjs.dev/guide/overview)
:::
...
:::info
Many of the packet types that the device is designed to send are automatically processed and decoded for you in there own event stream
Many of the packet types that the device is designed to send are automatically processed and decoded for you in their own event stream
:::
## Events
@ -23,7 +23,7 @@ Many of the packet types that the device is designed to send are automatically p
### Device Status
### Device Transation
### Device Translation
### From Radio

4
docs/software/js/getting-started.md
View file

@ -5,12 +5,12 @@ sidebar_label: Getting Started
---
:::tip
Full API docummentation is avaliable at [js.meshtastic.org](https://js.meshtastic.org)
Full API documentation is available at [js.meshtastic.org](https://js.meshtastic.org)
:::
## Intro
Meshtastic.js is a JavaScript library that provides an interface to Meshtastic devices. It can be used to build applications to interface with a Meshtastic network. Currently HTTP(S) and Bluetooth connections are supported.
Meshtastic.js is a JavaScript library that provides an interface to Meshtastic devices. It can be used to build applications to interface with a Meshtastic network. Currently, HTTP(S) and Bluetooth connections are supported.
If you wish to view the code or contribute to development of the library, please visit the JavaScript code <a href="https://github.com/meshtastic/meshtastic.js">GitHub page</a>.

6
docs/software/other/build-instructions.md
View file

@ -4,7 +4,7 @@ title: Build Instructions
sidebar_label: Building
---
This project uses the simple PlatformIO build system. PlatformIO is an extension to Microsoft VSCode. Workflows from building from the GUI or from the commandline are listed below.
This project uses the simple PlatformIO build system. PlatformIO is an extension to Microsoft VSCode. Workflows from building from the GUI or from the command line are listed below.
If you encounter any problems, please post a question in [our forum](https://meshtastic.discourse.group). And when you learn a fix, update these instructions for the next person (i.e. edit this file and send in a [pull-request](https://opensource.com/article/19/7/create-pull-request-github) which we will eagerly merge).
@ -40,7 +40,7 @@ Note - To get a clean build you may have to delete the auto-generated file `./.v
5. If you are outside the USA, run "export COUNTRY=EU865" (or whatever) to set the correct frequency range for your country. Options are provided for `EU433`, `EU865`, `CN`, `JP` and `US` (default). Pull-requests eagerly accepted for other countries.
6. Plug the radio into your USB port
7. Type `pio run --environment XXX -t upload` (This command will fetch dependencies, build the project and install it on the board via USB). For XXX, use the board type you have (either `tlora-v2, tlora-v1, tlora-v2-1-1.6, tbeam, heltec, tbeam0.7`).
8. Platform IO also installs a very nice VisualStudio Code based IDE, see their [tutorial](https://docs.platformio.org/en/latest/tutorials/espressif32/arduino_debugging_unit_testing.html) if you'd like to use it.
8. PlatformIO also installs a very nice VisualStudio Code based IDE, see their [tutorial](https://docs.platformio.org/en/latest/tutorials/espressif32/arduino_debugging_unit_testing.html) if you'd like to use it.
## Decoding stack traces
@ -58,6 +58,6 @@ If you get a crash, you can decode the addresses from the `Backtrace:` line:
You can run the exception decoder to monitor the serial output and decode backtraces in real time.
1. From within PlatformIO, open a new terminal.
2. At the the terminal, enter:
2. At the terminal, enter:
`pio device monitor --port /dev/cu.SLAB_USBtoUART -f esp32_exception_decoder`
Replace the value of port with the location of your serial port.

2
docs/software/other/esp32-arduino-build.md
View file

@ -43,7 +43,7 @@ Build esp32-arduino:
./build.sh
```
Copy sdk files into the platformio framework:
Copy SDK files into the PlatformIO framework:
```bash
cp -ar out/tools/sdk/* ~/.platformio/packages/framework-arduinoespressif32/tools/sdk

26
docs/software/other/mqtt.md
View file

@ -54,7 +54,7 @@ Any gateway-device will contact the MQTT broker.
The "mesh/crypt/CHANNELID/NODEID/PORTID" [topic](https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/) will be used for messages sent from/to a mesh.
Gateway nodes will foward any MeshPacket from a local mesh channel with uplink_enabled. The packet (encapsulated in a ServiceEnvelope) will remain encrypted with the key for the specified channel.
Gateway nodes will forward any MeshPacket from a local mesh channel with uplink_enabled. The packet (encapsulated in a ServiceEnvelope) will remain encrypted with the key for the specified channel.
For any channels in the local node with downlink_enabled, the gateway node will forward packets from MQTT to the local mesh. It will do this by subscribing to mesh/crypt/CHANNELID/# and forwarding relevant packets.
@ -62,7 +62,7 @@ If the channelid 'well known'/public it could be decrypted by a web service (if
FIXME, discuss how text message global mirroring could scale (or not)
FIXME, possibly don't global mirror text messages - instead rely on matrix/riot?
FIXME, discuss possible attacks by griefers and how they can be prvented
FIXME, discuss possible attacks by griefers and how they can be prevented
#### Service Envelope
@ -72,7 +72,7 @@ ServiceEnvelope will include the message, and full information about arrival tim
#### NODEID
The unique ID for a node. A hex string that starts with a ! symbol.
The unique ID for a node. A hex string that starts with an ! symbol.
#### USERID
@ -84,11 +84,11 @@ FIXME, figure out how channelids work
### Gateway nodes
Any meshtastic node that has a direct connection to the internet (either via a helper app or installed wifi/4G/satellite hardware) can function as a "Gateway node".
Any meshtastic node that has a direct connection to the internet (either via a helper app or installed Wifi/4G/satellite hardware) can function as a "Gateway node".
Gateway nodes (via code running in the phone) will contain two tables to whitelist particular traffic to either be delivered toward the internet, or down toward the mesh. Users that are developing custom apps will be able to customize these filters/subscriptions.
Since multiple gateway nodes might be connected to a single mesh, it is possible that duplicate messages will be published on any particular topic. Therefore subscribers to these topics should
Since multiple gateway nodes might be connected to a single mesh, it is possible that duplicate messages will be published on any particular topic. Therefore, subscribers to these topics should
deduplicate if needed by using the packet ID of each message.
### Optional web services
@ -97,7 +97,7 @@ deduplicate if needed by using the packet ID of each message.
An existing public [MQTT broker](https://mosquitto.org/) will be the default for this service, but clients can use any MQTT broker they choose.
FIXME - figure out how to avoid impersonation (because we are initially using a public mqtt server with no special security options). FIXME, include some ideas on this in the ServiceEnvelope documentation.
FIXME - figure out how to avoid impersonation (because we are initially using a public MQTT server with no special security options). FIXME, include some ideas on this in the ServiceEnvelope documentation.
#### Riot.im messaging bridge
@ -109,7 +109,7 @@ There is apparently [already](https://github.com/derEisele/tuple) a riot.im [bri
:::caution
All of the folowing concepts have been deprecated
All of the following concepts have been deprecated
:::
@ -133,7 +133,7 @@ The type of DESTID this message should be delivered to. A short one letter seque
| L | local mesh node ID or ^all |
| A | an application specific message, ID will be an APP ID |
| S | SMS gateway, DESTID is a phone number to reach via Twilio.com |
| E | Emergency message, see bug #fixme for more context |
| E | Emergency message, see bug #FIXME for more context |
#### DESTID (deprecated)
@ -143,7 +143,7 @@ Can be...
- an internet username: kevinh@geeksville.com
- ^ALL for anyone
- An app ID (to allow apps out in the web to receive arbitrary binary data from nodes or simply other apps using meshtastic as a transport). They would connect to the MQTT broker and subscribe to their topic
- An app ID (to allow apps out on the web to receive arbitrary binary data from nodes or simply other apps using meshtastic as a transport). They would connect to the MQTT broker and subscribe to their topic
## Rejected idea: RAW UDP
@ -155,8 +155,8 @@ This idea has been rejected
A number of commenters have requested/proposed using UDP for the transport. We've considered this option and decided to use MQTT instead for the following reasons:
- Most UDP uses cases would need to have a server anyways so that nodes can reach each other from anywhere (i.e. if most gateways will be behind some form of NAT which would need to be tunnelled)
- Raw UDP is dropped **very** agressively by many cellular providers. MQTT from the gateway to a broker can be done over a TCP connection for this reason.
- Most UDP uses cases would need to have a server anyways so that nodes can reach each other from anywhere (i.e. if most gateways will be behind some form of NAT which would need to be tunneled)
- Raw UDP is dropped **very** aggressively by many cellular providers. MQTT from the gateway to a broker can be done over a TCP connection for this reason.
- MQTT provides a nice/documented/standard security model to build upon
- MQTT is fairly wire efficient with multiple broker implementations/providers and numerous client libraries for any language. The actual implementation of MQTT is quite simple.
@ -173,7 +173,7 @@ on how this will be implemented and guesses at approximate work items.
- Add new multi channel concept
- Send new channels to python client
- Let python client add channels
- Add portion of channelid to the raw lora packet header
- Add portion of channelid to the raw LoRa packet header
- Confirm that we can now forward encrypted packets without decrypting at each node
- Use a channel named "remotehw" to secure the GPIO service. If that channel is not found, don't even start the service. Document this as the standard method for securing services.
- Add first cut of the "gateway node" code (i.e. MQTT broker client) to the python API (very little code needed for this component)
@ -183,6 +183,6 @@ on how this will be implemented and guesses at approximate work items.
### Enhancements in following releases
The initial gateway will be added to the python tool. But the gateway implementation is designed to be fairly trivial/dumb. After the initial release the actual gateway code can be ported to also run inside of the android app. In fact, we could have ESP32 based nodes include a built-in "gateway node" implementation.
The initial gateway will be added to the python tool. But the gateway implementation is designed to be fairly trivial/dumb. After the initial release, the actual gateway code can be ported to also run inside the android app. In fact, we could have ESP32 based nodes include a built-in "gateway node" implementation.
Store and forward could be added so that nodes on the mesh could deliver messages (i.e. text messages) on an "as possible" basis. This would allow things like "hiker sends a message to friend - mesh can not currently reach friend - eventually (days later) mesh can somehow reach friend, message gets delivered"

60
docs/software/other/nrf52-TODO.md
View file

@ -4,7 +4,7 @@ title: NRF52 TODO
sidebar_label: NRF52
---
- Possibly switch from softdevice to Apachy Newt: <https://github.com/espressif/esp-nimble>
- Possibly switch from softdevice to Apache Newt: <https://github.com/espressif/esp-nimble>
<https://github.com/apache/mynewt-core> - use nimble BLE on both ESP32 and NRF52
## RAK815
@ -15,15 +15,15 @@ sidebar_label: NRF52
- use S113 soft device 7.2.0
- properly test charge controller config and read battery/charge status
- fix bluetooth
- fix Bluetooth
- fix LCD max contrast (currently too high, needs to be about 40?)
- save brightness settings in flash
- make ST7567Wire driver less ugly, move OLED stuff into a common class treee
- add LCD power save mode for lcd per page 31 of datasheet
- add LCD power off sequence per datasheet to lcd driver
- make ST7567Wire driver less ugly, move OLED stuff into a common class tree
- add LCD power save mode for LCD per page 31 of datasheet
- add LCD power off sequence per datasheet to LCD driver
- leave LCD screen on most of the time (because it needs little power)
### general nrf52 TODO
### general nRF52 TODO
- turn off transitions on eink screens
- change update interval on eink from 1/sec frames to one frame every 5 mins
@ -32,9 +32,9 @@ sidebar_label: NRF52
- require button press to pair
- shrink soft device RAM usage
- get nrf52832 working again (currently OOM)
- i2c gps comms not quite right
- ble: AdafruitBluefruit::begin - adafruit_ble_task was assigned an invalid stack pointer. out of memory?
- get nRF52832 working again (currently OOM)
- i2c GPS comms not quite right
- BLE: AdafruitBluefruit::begin - adafruit_ble_task was assigned an invalid stack pointer. out of memory?
- measure power draw
### Bootloader
@ -67,15 +67,15 @@ In another, run:
bin/nrf52-console.sh
```
On NRF52 I've been using the jlink fake serial console. But since the rak815 has the serial port hooked up we can switch back to that once the basics are working.
On NRF52 I've been using the jlink fake serial console. But since the RAK815 has the serial port hooked up we can switch back to that once the basics are working.
## Misc work items
RAM investigation.
nRF52832-QFAA 64KB ram, 512KB flash vs
nrf52832-QFAB 32KB ram, 512kb flash
nrf52833 128KB RAM
nrf52840 256KB RAM, 1MB flash
nRF52832-QFAB 32KB ram, 512kb flash
nRF52833 128KB RAM
nRF52840 256KB RAM, 1MB flash
Manual hacks needed to build (for now):
@ -102,7 +102,7 @@ Minimum items needed to make sure hardware is good.
Needed to be fully functional at least at the same level of the ESP32 boards. At this point users would probably want them.
- DONE get serial API working
- get full BLE api working
- get full BLE API working
- make power management/sleep work properly
- make a settimeofday implementation
- DONE increase preamble length? - will break other clients? so all devices must update
@ -112,8 +112,8 @@ Needed to be fully functional at least at the same level of the ESP32 boards. At
- we need to enable the external tcxo for the sx1262 (on dio3)?
- figure out which regulator mode the sx1262 is operating in
- turn on security for BLE, make pairing work
- make ble endpoints not require "start config", just have them start in config mode
- use new PMU to provide battery voltage/% full to app (both bluetooth and screen)
- make BLE endpoints not require "start config", just have them start in config mode
- use new PMU to provide battery voltage/% full to app (both Bluetooth and screen)
- do initial power measurements, measure effects of more preamble bits, measure power management and confirm battery life
- set UICR.CUSTOMER to indicate board model & version
@ -141,10 +141,10 @@ Nice ideas worth considering someday...
- enable monitor mode debugging (need to use real jlink): <https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/monitor-mode-debugging-with-j-link-and-gdbeclipse>
- Improve efficiency of PeriodicTimer by only checking the next queued timer event, and carefully sorting based on schedule
- make a Mfg Controller and device under test classes as examples of custom app code for third party devs. Make a post about this. Use a custom payload type code. Have device under test send a broadcast with max hopcount of 0 for the 'mfgcontroller' payload type. mfg controller will read SNR and reply. DOT will declare failure/success and switch to the regular app screen.
- Hook Segger RTT to the nordic logging framework. <https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/debugging-with-real-time-terminal>
- Use nordic logging for DEBUG_MSG
- Hook Segger RTT to the Nordic logging framework. <https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/debugging-with-real-time-terminal>
- Use Nordic logging for DEBUG_MSG
- use the Jumper simulator to run meshes of simulated hardware: <https://docs.jumper.io/docs/install.html>
- make/find a multithread safe debug logging class (include remote logging and timestamps and levels). make each log event atomic.
- make/find a multi-thread safe debug logging class (include remote logging and timestamps and levels). make each log event atomic.
- turn on freertos stack size checking
- Currently we use Nordic's vendor ID, which is apparently okay: <https://devzone.nordicsemi.com/f/nordic-q-a/44014/using-nordic-vid-and-pid-for-nrf52840> and I just picked a PID of 0x4403
- Use NRF logger module (includes flash logging etc...) instead of DEBUG_MSG
@ -153,15 +153,15 @@ Nice ideas worth considering someday...
- in addition to the main CPU watchdog, use the PMU watchdog as a really big emergency hammer
- turn on 'shipping mode' in the PMU when device is 'off' - to cut battery draw to essentially zero
- make Lorro_BQ25703A read/write operations atomic, current version could let other threads sneak in (once we start using threads)
- make the segger logbuffer larger, move it to RAM that is preserved across reboots and support reading it out at runtime (to allow full log messages to be included in crash reports). Share this code with ESP32 (use gcc noinit attribute)
- make the segger logbuffer larger, move it to RAM that is preserved across reboots and support reading it out at runtime (to allow full log messages to be included in crash reports). Share this code with ESP32 (use GCC noinit attribute)
- convert hardfaults/panics/asserts/wd exceptions into fault codes sent to phone
- stop enumerating all i2c devices at boot, it wastes power & time
- consider using "SYSTEMOFF" deep sleep mode, without RAM retension. Only useful for 'truly off - wake only by button press' only saves 1.5uA vs SYSTEMON. (SYSTEMON only costs 1.5uA). Possibly put PMU into shipping mode?
- consider using "SYSTEMOFF" deep sleep mode, without RAM retention. Only useful for 'truly off - wake only by button press' only saves 1.5uA vs SYSTEMON. (SYSTEMON only costs 1.5uA). Possibly put PMU into shipping mode?
- change the BLE protocol to be more symmetric. Have the phone _also_ host a GATT service which receives writes to
'fromradio'. This would allow removing the 'fromnum' mailbox/notify scheme of the current approach and decrease the number of packet handoffs when a packet is received.
- Using the preceeding, make a generalized 'nrf52/esp32 ble to internet' bridge service. To let nrf52 apps do MQTT/UDP/HTTP POST/HTTP GET operations to web services.
- lower advertise interval to save power, lower ble transmit power to save power
- the SX126x class does SPI transfers on a byte by byte basis, which is very ineffecient. Much better to do block writes/reads.
- Using the preceding, make a generalized 'nRF52/ESP32 BLE to internet' bridge service. To let nRF52 apps do MQTT/UDP/HTTP POST/HTTP GET operations to web services.
- lower advertise interval to save power, lower BLE transmit power to save power
- the SX126x class does SPI transfers on a byte by byte basis, which is very inefficient. Much better to do block writes/reads.
## Old unorganized notes
@ -186,12 +186,12 @@ Nice ideas worth considering someday...
- DONE change rx95 to radiolib
- DONE track rxbad, rxgood, txgood
- DONE neg 7 error code from receive
- DONE remove unused sx1262 lib from github
- DONE remove unused SX1262 lib from GitHub
- at boot we are starting our message IDs at 1, rather we should start them at a random number. also, seed random based on timer. this could be the cause of our first message not seen bug.
- add a NMEA based GPS driver to test GPS
- DONE use "variants" to get all gpio bindings
- DONE use "variants" to get all GPIO bindings
- DONE plug in correct variants for the real board
- turn on DFU assistance in the appload using the nordic DFU helper lib call
- turn on DFU assistance in the appload using the Nordic DFU helper lib call
- make a new boarddef with a variant.h file. Fix pins in that file. In particular (at least):
#define PIN_SPI_MISO (46)
#define PIN_SPI_MOSI (45)
@ -202,14 +202,14 @@ Nice ideas worth considering someday...
- remove the MeshRadio wrapper - we don't need it anymore, just do everything in RadioInterface subclasses.
- DONE use SX126x::startReceiveDutyCycleAuto to save power by sleeping and briefly waking to check for preamble bits. Change xmit rules to have more preamble bits.
- scheduleOSCallback doesn't work yet - it is way too fast (causes rapid polling of busyTx, high power draw etc...)
- find out why we reboot while debugging - it was bluetooth/softdevice
- find out why we reboot while debugging - it was Bluetooth/softdevice
- make a file system implementation (preferably one that can see the files the bootloader also sees) - preferably <https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/master/libraries/InternalFileSytem/examples/Internal_ReadWrite/Internal_ReadWrite.ino> else use <https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.3.0/lib_fds_usage.html?cp=7_5_0_3_55_3>
- change packet numbers to be 32 bits
per
<https://docs.platformio.org/en/latest/tutorials/nordicnrf52/arduino_debugging_unit_testing.html>
ardunino github is here <https://github.com/sandeepmistry/arduino-nRF5>
Arduino GitHub is here <https://github.com/sandeepmistry/arduino-nRF5>
devboard hw docs here:
<https://infocenter.nordicsemi.com/topic/ug_nrf52840_dk/UG/nrf52840_DK/hw_buttons_leds.html?cp=4_0_4_7_6>
@ -245,7 +245,7 @@ examples of turning off the loop call to save power:
example of a more complex BLE service:
<https://learn.adafruit.com/bluefruit-nrf52-feather-learning-guide/custom-hrm>
See g_ADigitalPinMap to see how arduino maps to the real gpio#s - and all in P0
See g_ADigitalPinMap to see how Arduino maps to the real GPIO#s - and all in P0
```cpp
#define LED1 14

20
docs/software/other/pinetab.md
View file

@ -13,26 +13,26 @@ CS0 from RF95 goes to CS0 on CH341
DIO0 from RF95 goes to INT on CH341
RST from RF95 goes to RST on CH341
This linux driver claims to provide USB-SPI support: https://github.com/gschorcht/spi-ch341-usb
This Linux driver claims to provide USB-SPI support: https://github.com/gschorcht/spi-ch341-usb
Notes here on using that driver: https://www.linuxquestions.org/questions/linux-hardware-18/ch341-usb-to-spi-adaptor-driver-doesn%27t-work-4175622736/
Or if **absolutely** necessary could bitbang: https://www.cnx-software.com/2018/02/16/wch-ch341-usb-to-serial-chip-gets-linux-driver-to-control-gpios-over-usb/
Or if **absolutely** necessary could bit bang: https://www.cnx-software.com/2018/02/16/wch-ch341-usb-to-serial-chip-gets-linux-driver-to-control-gpios-over-usb/
## Portduino tasks
- How to access spi devices via ioctl (spidev): https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md#:~:text=Troubleshooting-,Overview,bus)%2C%20UARTs%2C%20etc.
- access gpio via libgpiod?
- How to access SPI devices via ioctl (spidev): https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md#:~:text=Troubleshooting-,Overview,bus)%2C%20UARTs%2C%20etc.
- access GPIO via libgpiod?
- Use dkms to distribute driver?
- echo 100 > /sys/module/spi_ch341_usb/parameters/poll_period
## Task list
- Port meshtastic to build (under platformio) for a poxix target. spec: no screen, no gpios, sim network interface, posix threads, posix semaphores & queues, IO to the console only
Use ARM linux: https://platformio.org/platforms/linux_arm
And linux native: https://platformio.org/platforms/native
- Port meshtastic to build (under PlatformIO) for a POSIX target. spec: no screen, no GPIOs, SIM network interface, POSIX threads, POSIX semaphores & queues, IO to the console only
Use ARM Linux: https://platformio.org/platforms/linux_arm
And Linux native: https://platformio.org/platforms/native
- Test cs341 driver - just test reading/writing a register and detecting interrupts, confirm can see rf95
- Make a radiolib spi module that targets the cs341 (and builds on linux)
- use new radiolib module to hook pinebook lora to meshtastic, confirm mesh discovery works
- Make a subclass of StreamAPI that works as a posix TCP server
- Make a radiolib SPI module that targets the cs341 (and builds on Linux)
- use new radiolib module to hook pinebook LoRa to meshtastic, confirm mesh discovery works
- Make a subclass of StreamAPI that works as a POSIX TCP server
- Use new TCP endpoint from meshtastic-python

40
docs/software/other/power.md
View file

@ -14,21 +14,21 @@ Since one of the main goals of this project is long battery life, it is importan
From lower to higher power consumption.
- Super-deep-sleep (SDS) - everything is off, CPU, radio, bluetooth, GPS. Only wakes due to timer or button press. We enter this mode only after no radio comms for a few hours, used to put the device into what is effectively "off" mode.
- Super-deep-sleep (SDS) - everything is off, CPU, radio, Bluetooth, GPS. Only wakes due to timer or button press. We enter this mode only after no radio comms for a few hours, used to put the device into what is effectively "off" mode.
onEntry: setBluetoothOn(false), call doDeepSleep
onExit: (standard bootup code, starts in DARK)
- deep-sleep (DS) - CPU is off, radio is on, bluetooth and GPS is off. Note: This mode is never used currently, because it only saves 1.5mA vs light-sleep
- deep-sleep (DS) - CPU is off, radio is on, Bluetooth and GPS is off. Note: This mode is never used currently, because it only saves 1.5mA vs light-sleep
(Not currently used)
- light-sleep (LS) - CPU is suspended (RAM stays alive), radio is on, bluetooth is off, GPS is off. Note: currently GPS is not turned
- light-sleep (LS) - CPU is suspended (RAM stays alive), radio is on, Bluetooth is off, GPS is off. Note: currently GPS is not turned
off during light sleep, but there is a TODO item to fix this.
NOTE: On NRF52 platforms (because CPU current draw is so low), light-sleep state is never used.
onEntry: setBluetoothOn(false), setGPSPower(false), doLightSleep()
onIdle: (if we wake because our led blink timer has expired) blink the led then go back to sleep until we sleep for ls_secs
onExit: setGPSPower(true), start trying to get gps lock: gps.startLock(), once lock arrives service.sendPosition(BROADCAST)
onExit: setGPSPower(true), start trying to get GPS lock: gps.startLock(), once lock arrives service.sendPosition(BROADCAST)
- No bluetooth (NB) - CPU is running, radio is on, GPS is on but bluetooth is off, screen is off.
- No Bluetooth (NB) - CPU is running, radio is on, GPS is on but Bluetooth is off, screen is off.
onEntry: setBluetoothOn(false)
onExit:
@ -36,7 +36,7 @@ From lower to higher power consumption.
onEntry: setBluetoothOn(true)
onExit:
- serial API usage (SERIAL) - Screen is on, device doesn't sleep, bluetooth off
- serial API usage (SERIAL) - Screen is on, device doesn't sleep, Bluetooth off
onEntry: setBluetooth off, screen on
onExit:
@ -44,7 +44,7 @@ From lower to higher power consumption.
onEntry: setBluetoothOn(true), screen.setOn(true)
onExit: screen->setOn(false)
- has power (POWER) - Screen is on, device doesn't sleep, bluetooth on, will stay in this state as long as we have power
- has power (POWER) - Screen is on, device doesn't sleep, Bluetooth on, will stay in this state as long as we have power
onEntry: setBluetooth off, screen on
onExit:
@ -62,41 +62,41 @@ From lower to higher power consumption.
- While in NB: If we do have packets the phone (EVENT_PACKETS_FOR_PHONE) would want we transition to DARK mode for wait_bluetooth secs.
- While in DARK/ON: If we receive EVENT_BLUETOOTH_PAIR we transition to ON and start our screen_on_secs timeout
- While in NB/DARK/ON: If we receive EVENT_NODEDB_UPDATED we transition to ON (so the new screen can be shown)
- While in DARK: While the phone talks to us over BLE (EVENT_CONTACT_FROM_PHONE) reset any sleep timers and stay in DARK (needed for bluetooth sw update and nice user experience if the user is reading/replying to texts)
- While in DARK: While the phone talks to us over BLE (EVENT_CONTACT_FROM_PHONE) reset any sleep timers and stay in DARK (needed for Bluetooth sw update and nice user experience if the user is reading/replying to texts)
- while in LS/NB/DARK: if SERIAL_CONNECTED, go to serial
- while in any state: if we have AC power, go to POWER
### events that decrease cpu activity
### events that decrease CPU activity
- While in POWER: if lose AC go to ON
- While in SERIAL: if SERIAL_DISCONNECTED, go to NB
- While in ON: If PRESS event occurs, reset screen_on_secs timer and tell the screen to handle the pess
- While in ON: If PRESS event occurs, reset screen_on_secs timer and tell the screen to handle the mess
- While in ON: If it has been more than screen_on_secs since a press, lower to DARK
- While in DARK: If time since last contact by our phone exceeds phone_timeout_secs (15 minutes), we transition down into NB mode
- While in DARK or NB: If nothing above is forcing us to stay in a higher mode (wait_bluetooth_secs, min_wake_secs) we will lower down to LS state
- While in LS: If either phone_sds_timeout_secs (default 2 hr) or mesh_sds_timeout_secs (default 2 hr) are exceeded we will lower into SDS mode for sds_secs (default 1 yr) (or a button press). (Note: phone_sds_timeout_secs is currently disabled for now, because most users
are using without a phone)
- Any time we enter LS mode: We stay in that until an interrupt, button press or other state transition. Every ls_secs (default 1 hr) and let the arduino loop() run one iteration (FIXME, not sure if we need this at all), and then immediately reenter lightsleep mode on the CPU.
- Any time we enter LS mode: We stay in that until an interrupt, button press or other state transition. Every ls_secs (default 1 hr) and let the Arduino loop() run one iteration (FIXME, not sure if we need this at all), and then immediately reenter lightsleep mode on the CPU.
TODO: Eventually these scheduled intervals should be synchronized to the GPS clock, so that we can consider leaving the lora receiver off to save even more power.
TODO: In NB mode we should put cpu into light sleep any time we really aren't that busy (without declaring LS state) - i.e. we should leave GPS on etc...
TODO: Eventually these scheduled intervals should be synchronized to the GPS clock, so that we can consider leaving the LoRa receiver off to save even more power.
TODO: In NB mode we should put CPU into light sleep any time we really aren't that busy (without declaring LS state) - i.e. we should leave GPS on etc...
# Low power consumption tasks
General ideas to hit the power draws our spreadsheet predicts. Do the easy ones before beta, the last 15% can be done after 1.0.
- don't even power on the gps until someone else wants our position, just stay in lora deep sleep until press or rxpacket (except for once an hour updates)
- (possibly bad idea - better to have lora radio always listen - check spreadsheet) have every node wake at the same tick and do their position syncs then go back to deep sleep
- don't even power on the GPS until someone else wants our position, just stay in LoRa deep sleep until press or rxpacket (except for once an hour updates)
- (possibly bad idea - better to have LoRa radio always listen - check spreadsheet) have every node wake at the same tick and do their position syncs then go back to deep sleep
- lower BT announce interval to save battery
- change to use RXcontinuous mode and config to drop packets with bad CRC (see section 6.4 of datasheet) - I think this is already the case
- have mesh service run in a thread that stays blocked until a packet arrives from the RF95
- platformio sdkconfig CONFIG_PM and turn on modem sleep mode
- keep cpu 100% in deepsleep until irq from radio wakes it. Then stay awake for 30 secs to attempt delivery to phone.
- keep CPU 100% in deepsleep until irq from radio wakes it. Then stay awake for 30 secs to attempt delivery to phone.
- use https://lastminuteengineers.com/esp32-sleep-modes-power-consumption/ association sleep pattern to save power - but see https://github.com/espressif/esp-idf/issues/2070 and https://esp32.com/viewtopic.php?f=13&t=12182 it seems with BLE on the 'easy' draw people are getting is 80mA
- stop using loop() instead use a job queue and let cpu sleep
- stop using loop() instead use a job queue and let CPU sleep
- measure power consumption and calculate battery life assuming no deep sleep
- do lowest sleep level possible where BT still works during normal sleeping, make sure cpu stays in that mode unless lora rx packet happens, bt rx packet happens or button press happens
- optionally do lora messaging only during special scheduled intervals (unless nodes are told to go to low latency mode), then deep sleep except during those intervals - before implementing calculate what battery life would be with this feature
- do the lowest sleep level possible where BT still works during normal sleeping, make sure CPU stays in that mode unless LoRa rx packet happens, bt rx packet happens or button press happens
- optionally do LoRa messaging only during special scheduled intervals (unless nodes are told to go to low latency mode), then deep sleep except during those intervals - before implementing calculate what battery life would be with this feature
- see section 7.3 of https://cdn.sparkfun.com/assets/learn_tutorials/8/0/4/RFM95_96_97_98W.pdf and have hope radio wake only when a valid packet is received. Possibly even wake the ESP32 from deep sleep via GPIO.
- never enter deep sleep while connected to USB power (but still go to other low power modes)
- when main cpu is idle (in loop), turn cpu clock rate down and/or activate special sleep modes. We want almost everything shutdown until it gets an interrupt.
- when main CPU is idle (in loop), turn CPU clock rate down and/or activate special sleep modes. We want almost everything shutdown until it gets an interrupt.

2
docs/software/other/remote-hardware-service.md
View file

@ -4,7 +4,7 @@ title: Remote Hardware Service
sidebar_label: Remote Hardware
---
FIXME - the following are a collection of notes moved from elsewhere. We need to refactor these notes into actual documentation on the remote-hardware/gpio service.
FIXME - the following are a collection of notes moved from elsewhere. We need to refactor these notes into actual documentation on the remote-hardware/GPIO service.
### 1.7.2. New 'no-code-IOT' mini-app

8
docs/software/overview.md
View file

@ -10,17 +10,17 @@ The following applications are available to support your Meshtastic network:
- The [firmware](/docs/software/device/device-firmware) to run on the devices
- Connect to the devices with our [Android app](/docs/software/android/android-installation)
- An [iOS application](/docs/software/ios/ios-development) is in the works
- [Meshtastic.js](/docs/software/js/getting-started) provides a javascript library to interface with devices
- [Meshtastic.js](/docs/software/js/getting-started) provides a JavaScript library to interface with devices
- [Meshtastic-python](/docs/software/python/python-installation) provides access from desktop computers including a command line interface
- A [web interface](/docs/software/web/web-app-software) can be accessed over wifi on ESP32 devices
- A [web interface](/docs/software/web/web-app-software) can be accessed over Wifi on ESP32 devices
- Pre-installed device plugins for:
- [Range testing](/docs/software/plugins/range-test-plugin)
- [External notifications](/docs/software/plugins/ext-notif-plugin)
- [Serial communication](/docs/software/plugins/serial-plugin)
- [Store and forewarding messages](/docs/software/plugins/store-forward-plugin) (in development)
- [Store and forwarding messages](/docs/software/plugins/store-forward-plugin) (in development)
- [Environment measurement](/docs/software/plugins/environment-plugin) (in development)
- Community projects include:
- A [plugin](/docs/software/community/community-atak) for the [Android Team Awareness Kit (ATAK)](https://play.google.com/store/apps/details?id=com.atakmap.app.civ)
- [PyGUI](/docs/software/community/community-pygui), a platform agnostic graphical user interface for devices
The devices running Meshtastic have a large number of preferences that can be set, see the [Settings](/docs/settings) pages for more details.
The devices running Meshtastic have many preferences that can be set, see the [Settings](/docs/settings) pages for more details.

10
docs/software/plugins/external-notifications.md
View file

@ -54,7 +54,7 @@ For basic usage, start with:
ext_notification_plugin_alert_message = 1
Depending on how your external cirtcuit configured is configured, you may need to set the active state to true.
Depending on how your external circuit configured is configured, you may need to set the active state to true.
ext_notification_plugin_active = 1
@ -68,7 +68,7 @@ We support being alerted on two events:
1) Incoming Text Message
2) Incoming Text Message that contains the ascii bell character. At present, only the Python API can send an ascii bell character, but more support may be added in the future.
2) Incoming Text Message that contains the ASCII bell character. At present, only the Python API can send an ASCII bell character, but more support may be added in the future.
#### Bell Character
@ -76,7 +76,7 @@ The bell character is ASCII 0x07. Include 0x07 anywhere in the text message and
## External Hardware
Be mindful of the max current sink and source of the esp32 GPIO. The easiest devices to interface with would be either an LED or Active Buzzer.
Be mindful of the max current sink and source of the ESP32 GPIO. The easiest devices to interface with would be either an LED or Active Buzzer.
Ideas for external hardware:
@ -88,6 +88,6 @@ Ideas for external hardware:
## Known Problems
* This won't directly support an passive (normal) speaker as it does not generate any audio wave forms.
* This currently only supports the esp32. Other targets may be possible, I just don't have to test with.
* This won't directly support a passive (normal) speaker as it does not generate any audio wave forms.
* This currently only supports the ESP32. Other targets may be possible, I just don't have to test with.
* This plugin only monitors text messages. We won't trigger on any other packet types.

2
docs/software/plugins/plugins.md
View file

@ -12,5 +12,5 @@ These plugins are currently integrated into the firmware:
* Serial - Allows messages to be sent across the mesh by sending strings across a serial port
These plugins are currently in development:
* Store and forward - Allows a node to store messages and resend them to nodes that have intermittant connection to the mesh
* Store and forward - Allows a node to store messages and resend them to nodes that have intermittent connection to the mesh
* Environment measurement - Allows a node to measure it's local environment and report across the mesh

14
docs/software/plugins/range-test.md
View file

@ -4,7 +4,7 @@ title: Range test plugin
sidebar_label: Range test
---
This plugin allows you to test he range of your Meshtastic nodes. It uses two nodes, one to send a message every minute, and another to receive the messages. The receiving node then saves the messages along with the GPS coordinates at which they were received into a .csv file. This .csv file can then be integrated into, for example, Google Earth, allowing you to see where you have coverage.
This plugin allows you to test the range of your Meshtastic nodes. It uses two nodes, one to send a message every minute, and another to receive the messages. The receiving node then saves the messages along with the GPS coordinates at which they were received into a .csv file. This .csv file can then be integrated into, for example, Google Earth, allowing you to see where you have coverage.
## Configuration
@ -34,7 +34,7 @@ The device must be restarted after the settings have been changed for the plugin
For basic usage, you will need two devices both with a GPS. A device with a paired phone with GPS may work, I have not tried it.
The first thing to do is to turn on the plugin. The device will need to be restarted after appling the settings. With the plugin turned on, the other settings will be available:
The first thing to do is to turn on the plugin. The device will need to be restarted after applying the settings. With the plugin turned on, the other settings will be available:
range_test_plugin_enabled = 1
@ -71,7 +71,7 @@ Receiver
Be sure to turn off either the plugin configured as a sender or the device where the plugin setup as sender when not in use. This will use a lot of time on air and will spam your channel.
Also be mindful of your space usage on the file system. It has protections from filling up the space but it's best to delete old range test results.
Also, be mindful of your space usage on the file system. It has protections from filling up the space but it's best to delete old range test results.
## Application Examples
@ -87,8 +87,8 @@ Steps:
5. Select “rx lat” & “rx long” for the appropriate lat/lng fields
6. Click finish
2. When it prompts you to create a style template, click yes.
1. Set the name field to whichever column you want to be displayed on the map (don’t worry about this too much, when you click on an icon, all the relavant data appears)
2. select a color, icon, etc. and hit ok.
1. Set the name field to whichever column you want to be displayed on the map (don’t worry about this too much, when you click on an icon, all the relevant data appears)
2. select a color, icon, etc. and hit OK.
Your data will load onto the map, make sure to click the checkbox next to your dataset in the sidebar to view it.
@ -102,7 +102,7 @@ You can style the ranges differently based on the values, so you can have the pi
## Known Problems
If turned on, using mesh network will become unwieldly because messages are sent over the same channel as the other messages. See TODO below.
If turned on, using mesh network will become unwieldy because messages are sent over the same channel as the other messages. See TODO below.
## TODO
@ -123,7 +123,7 @@ Q: Can I use this as a message logger?
* While it's not the intended purpose, sure, why not. Do it!
Q: What will happen if I run out of space on my device?
* We have a protection in place to keep you from completly filling up your device. This will make sure that other device critical functions will continue to work. We will reserve at least 50k of free space.
* We have a protection in place to keep you from completely filling up your device. This will make sure that other device critical functions will continue to work. We will reserve at least 50k of free space.
Q: What do I do with the rangetest.csv file when I'm done?
* Go to /static and delete the file.

6
docs/software/plugins/serial.md
View file

@ -13,7 +13,7 @@ Default is to use RX GPIO 16 and TX GPIO 17.
## Basic Usage:
1. Enable the plugin by setting `serialplugin_enabled` to `1`.
2. Set the pins (`serialplugin_rxd` / `serialplugin_rxd`) for your preferred RX and TX GPIO pins. On tbeam boards it is recommend to use:
2. Set the pins (`serialplugin_rxd` / `serialplugin_rxd`) for your preferred RX and TX GPIO pins. On tbeam boards it is recommended to use:
* RXD 35
* TXD 15
3. Set `serialplugin_timeout` to the amount of time to wait before we consider your packet as "done".
@ -28,7 +28,7 @@ The device must be restarted after the settings have been changed for the plugin
## TODO (in this order):
* Define a verbose RX mode to report on mesh and packet infomration.
* Define a verbose RX mode to report on mesh and packet information.
:::note
This won't happen any time soon.
@ -36,5 +36,5 @@ This won't happen any time soon.
## Known Problems
* Until the plugin is initilized by the startup sequence, the TX pin is in a floating state. Device connected to that pin may see this as "noise".
* Until the plugin is initialized by the startup sequence, the TX pin is in a floating state. Device connected to that pin may see this as "noise".
* Will not work on NRF and the Linux device targets.

12
docs/software/plugins/store-forward.md
View file

@ -11,7 +11,7 @@ This is a work in progress and is not yet available.
The Store Forward Plugin is an implementation of a Store and Forward system to enable resilient messaging in the event that a client device is disconnected from the main network.
Because of the increased network traffic for this overhead, it's not adviced to use this if you are duty cycle limited for your airtime usage nor is it adviced to use this for SF12 (Long range but Slow).
Because of the increased network traffic for this overhead, it's not advised to use this if you are duty cycle limited for your airtime usage nor is it advised to use this for SF12 (Long range but Slow).
### About - How it works
@ -55,13 +55,13 @@ With an aftermarket coaxial antenna or moxon antenna, that will give you roughly
* * * store_forward_plugin_enabled - Set this to true to enable the plugin. False to disable the plugin.
* * Optional configuration
* * * store_forward_plugin_records - Set this to the maximum number of records to save. Best to leave this at the default (0) where the plugin will use 2/3 of your device's available PSRAM. This is about 11,000 records.
* Name your router node something that makes it easily identifable, aka "Router".
* Name your router node something that makes it easily identifiable, aka "Router".
Don't enable the Store and Forward plugin on multile routers!
Don't enable the Store and Forward plugin on multiple routers!
### Client Usage
Currently, no sepcial configuration is required. To request your history sent to you, send the command into the message field "SF". That's it. This will eventually change to make it easier. At the moment, that message will be sent to everyone on the mesh but we'll (eventually) make it easier to use where there'll be a button (or maybe it'll be transparent) and the command isn't sent as a text message to the mesh.
Currently, no special configuration is required. To request your history sent to you, send the command into the message field "SF". That's it. This will eventually change to make it easier. At the moment, that message will be sent to everyone on the mesh but we'll (eventually) make it easier to use where there'll be a button (or maybe it'll be transparent) and the command isn't sent as a text message to the mesh.
Available Commands:
@ -153,13 +153,13 @@ Not necessarily in this order:
* Restrict operation of S&F on the slow channel configurations.
* Create a tx queue to prevent the history from being modified in flight.
* Create a TX queue to prevent the history from being modified in flight.
* Only allow n-number of requests to the router at any one time.
* Set number of max messages from the history.
* Calculate a new channel with 250mhz bandwidth and ~1.5kbit.
* Calculate a new channel with 250MHz bandwidth and ~1.5kbit.
*** Done

10
docs/software/python/cli.md
View file

@ -20,7 +20,7 @@ Because of the growing nature of this project, not all commands may appear when
## Getting a list of User Preferences
You can get a list of user preferences by running '--get' with an invalid atrribute such as 'all'.
You can get a list of user preferences by running '--get' with an invalid attribute such as 'all'.
```bash
meshtastic --get all
```
@ -28,7 +28,7 @@ meshtastic --get all
## Changing settings
You can also use this tool to set any of the device parameters which are stored in persistent storage. For instance, here's how to set the device
to keep the bluetooth link alive for eight hours (any usage of the bluetooth protocol from your phone will reset this timer)
to keep the Bluetooth link alive for eight hours (any usage of the Bluetooth protocol from your phone will reset this timer)
```bash title="Expected Output"
# You should see a result similar to this:
@ -44,7 +44,7 @@ Or to set a node at a fixed position and never power up the GPS.
meshtastic --setlat 25.2 --setlon -16.8 --setalt 120
```
Or to configure an ESP32 based board to join a wifi network as a station:
Or to configure an ESP32 based board to join a Wifi network as a station:
```bash
meshtastic --set wifi_ap_mode false --set wifi_ssid mywifissid --set wifi_password mywifipsw
@ -62,7 +62,7 @@ For a full list of preferences which can be set (and their documentation) can be
### Changing channel settings
The channel settings can also be changed, either by using a standard (sharable) meshtastic URL or you can set particular channel parameter (for advanced users).
The channel settings can also be changed, either by using a standard (shareable) meshtastic URL or you can set particular channel parameter (for advanced users).
:::warning
Meshtastic encodes the radio channel and PSK in the channel's URL. All nodes must connect to the channel again by using the URL provided after a change in this section by performing the `--info` switch. Please refer to [Multiple Channel Support](../device/device-channels).
@ -124,4 +124,4 @@ There is a problem with Big Sur and pyserial. The workaround is to install a new
pip3 install -U --pre pyserial
```
Afterwards you can use the meshatstic python client again on MacOS.
Afterwards you can use the meshtastic python client again on MacOS.

4
docs/software/python/installation.md
View file

@ -179,13 +179,13 @@ Wifi connection is currently under development and may not be working properly j
```
pkg install python
```
* Upgrade pip and installed meshtastic and its dependancies
* Upgrade pip and installed meshtastic and its dependencies
```
pip install --upgrade pip pygatt pytap2 wheel mesthtastic
```
:::note
Be aware that the Meshtastic CLI is not able to control the nodes over USB through termux, but you can control devices over wifi using the `--host x.x.x.x` option with the device IP address. However, only ESP32 devices can use wifi currently.
Be aware that the Meshtastic CLI is not able to control the nodes over USB through termux, but you can control devices over Wifi using the `--host x.x.x.x` option with the device IP address. However, only ESP32 devices can use Wifi currently.
:::
</TabItem>
</Tabs>

2
docs/software/python/usage.md
View file

@ -53,7 +53,7 @@ while True:
interface.close()
```
Note: Be sure to change the ip address in the code above to a valid ip address for your setup.
Note: Be sure to change the IP address in the code above to a valid IP address for your setup.
You can get and update settings like this:

2
docs/software/settings/environmental-measurment-plugin.md
View file

@ -34,7 +34,7 @@ Enables the plugin.
### environmental_measurement_plugin_display_farenheit
The sensor is always read in Celsius, but the user can opt to view the temperature display in Farenheit using this setting.
The sensor is always read in Celsius, but the user can opt to view the temperature display in Fahrenheit using this setting.
### environmental_measurement_plugin_read_error_count_threshold

10
docs/software/settings/gps.md
View file

@ -40,7 +40,7 @@ If set, this node is at a fixed position. The device will generate GPS updates a
### gps_attempt_time
Determines the amount of time that a GPS fix should be allowed to take. The default is every 30 seconds. If you increase this value, it will allow the device that amount of time in seconds to aquire coordinates. If the device is unable to get a fix, it will turn off until the next interval. GPS coordinates are updated every [`gps_update_interval`](#gps_update_interval) seconds.
Determines the amount of time that a GPS fix should be allowed to take. The default is every 30 seconds. If you increase this value, it will allow the device that amount of time in seconds to acquire coordinates. If the device is unable to get a fix, it will turn off until the next interval. GPS coordinates are updated every [`gps_update_interval`](#gps_update_interval) seconds.
### gps_operation
@ -60,7 +60,7 @@ This is independent of how our location is shared with other devices. For that s
### gps_update_interval
Determines how often should the device should attempt to aquire a GPS position (in seconds). The length of time the device is allowed to attempt to aquire GPS coordinates each interval is set using [`gps_attempt_time`](#gps_attempt_time). The default is every 30 seconds.
Determines how often should the device should attempt to acquire a GPS position (in seconds). The length of time the device is allowed to attempt to acquire GPS coordinates each interval is set using [`gps_attempt_time`](#gps_attempt_time). The default is every 30 seconds.
### location_share
@ -76,7 +76,7 @@ Determines whether location is shared with other nodes. See more details.
How often our position is sent to the mesh (but only if it has changed significantly).
The gps updates will be sent out every `position_broadcast_secs`, with either the actual gps location, or an empty location if no gps fix was achieved. This defaults to broadcast every 15 minutes.
The GPS updates will be sent out every `position_broadcast_secs`, with either the actual GPS location, or an empty location if no GPS fix was achieved. This defaults to broadcast every 15 minutes.
### position_broadcast_smart
@ -126,7 +126,7 @@ Note: A person walking in a straight line will take about 90 seconds to travel 1
</Tabs>
:::note
`gps_operation GpsOpTimeOnly` is prefered to `gps_operation GpsOPDisabled` because it allows the device to get a highres time.
`gps_operation GpsOpTimeOnly` is preferred to `gps_operation GpsOPDisabled` because it allows the device to get a hi-res time.
:::
### Disable Location Sharing
@ -178,7 +178,7 @@ Disabling location sharing does not disable the GPS functionality, only the loca
</Tabs>
:::note
The device will continue to aquire GPS coordinates according to the `gps_update_interval`, but will use the last saved coordinates as its fixed point.
The device will continue to acquire GPS coordinates according to the `gps_update_interval`, but will use the last saved coordinates as its fixed point.
:::
### Set Fixed Position – Specify Lat/Lon

4
docs/software/settings/misc.md
View file

@ -40,11 +40,11 @@ If true, radio should not try to be smart about what packets to queue to the pho
### serial_disabled
If set, this will disable the SerialConsole by not initilizing the StreamAPI.
If set, this will disable the SerialConsole by not initializing the StreamAPI.
### hop_limit
Overides the deault number of hops a message will be passed. If not set, will default to 3 hops.
Overrides the default number of hops a message will be passed. If not set, will default to 3 hops.
Meshtastic allows a maximum of 7 hops (this is a limit of the protocol). Setting a hop_limit of greater than 7 will be replaced with 7 on the device.

6
docs/software/settings/overview.md
View file

@ -7,11 +7,11 @@ slug: /settings
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
Customization of your settings is vital to configuring your own mesh. Changing settings is currently most reliably done using the commandline interface available within `Meshtastic-python`. Setting support is being added to all other methods of interfacing with your device.
Customization of your settings is vital to configuring your own mesh. Changing settings is currently most reliably done using the command line interface available within `Meshtastic-python`. Setting support is being added to all other methods of interfacing with your device.
## Settings
Below are some of the most common settings that a new user will want to become aquainted with, but it isn't an exhaustive list. Make sure to take a look at the sidebar for additional settings. If you find something missing or incorrect, please help us improve our docs by filing an issue, creating a pull request, or mentioning it in our forum.
Below are some of the most common settings that a new user will want to become acquainted with, but it isn't an exhaustive list. Make sure to take a look at the sidebar for additional settings. If you find something missing or incorrect, please help us improve our docs by filing an issue, creating a pull request, or mentioning it in our forum.
### Channel Settings
@ -43,7 +43,7 @@ At the bottom of each setting page, examples will be available displaying how to
<TabItem value="cli">
:::note
The CLI examples will require you to utilize the Commandline Interface that is available through Meshtastic-python. Installation instructions can be found [here](software/python/python-installation).
The CLI examples will require you to utilize the Command line Interface that is available through Meshtastic-python. Installation instructions can be found [here](software/python/python-installation).
:::
```bash title="Example - Set Region (an important first step!)"

2
docs/software/settings/power.md
View file

@ -104,7 +104,7 @@ Wait number of seconds for Bluetooth - Power management state machine option. Se
### is_always_powered
If the device is plugged into the wall (not from battery), you may consider using this setting to always keep the device from sleeping. This is a useful setting if you are on esp32 and using the wifi options.
If the device is plugged into the wall (not from battery), you may consider using this setting to always keep the device from sleeping. This is a useful setting if you are on ESP32 and using the Wifi options.
## Examples

6
docs/software/settings/range-test-plugin.md
View file

@ -29,15 +29,15 @@ Enables the plugin.
### range_test_plugin_save
If enabled, we will save a log of all received messages to `/static/rangetest.csv` which you can access from the webserver. We will abort writing if there is less than 50k of space on the filesystem to prevent filling up the storage.
If enabled, we will save a log of all received messages to `/static/rangetest.csv` which you can access from the web server. We will abort writing if there is less than 50k of space on the filesystem to prevent filling up the storage.
### range_test_plugin_sender
Number of seconds to wait between sending packets. Using the long_slow channel configuration, it's best not to go more frequent than once every 60 seconds. You can be more agressive with faster settings. `0` is default which disables sending messages.
Number of seconds to wait between sending packets. Using the long_slow channel configuration, it's best not to go more frequent than once every 60 seconds. You can be more aggressive with faster settings. `0` is default which disables sending messages.
## Details
While a minumum of two radios is required, more can be used. You can have any number of receivers and senders that your mesh is able to handle. You can test having a single sender with multiple receivers or a single reciever with multiple senders. Let us know on the [forum thread](https://meshtastic.discourse.group/t/new-plugin-rangetestplugin/2591/) the results of your configuration.
While a minimum of two radios is required, more can be used. You can have any number of receivers and senders that your mesh is able to handle. You can test having a single sender with multiple receivers or a single receiver with multiple senders. Let us know on the [forum thread](https://meshtastic.discourse.group/t/new-plugin-rangetestplugin/2591/) the results of your configuration.
Be sure to turn off either the plugin configured as a sender or the device where the plugin setup as sender when not in use. This will use a lot of time on air and will spam your channel.

2
docs/software/settings/store-and-forward-plugin.md
View file

@ -15,7 +15,7 @@ This is a work in progress and is not yet available.
The Store Forward Plugin is an implementation of a Store and Forward system to enable resilient messaging in the event that a client device is disconnected from the main network.
Because of the increased network traffic for this overhead, it's not adviced to use this if you are duty cycle limited for your airtime usage nor is it adviced to use this for SF12 (Long range but Slow).
Because of the increased network traffic for this overhead, it's not advised to use this if you are duty cycle limited for your airtime usage nor is it advised to use this for SF12 (Long range but Slow).
## Settings

2
docs/software/settings/wifi.md
View file

@ -61,7 +61,7 @@ This will reboot the device with the SSID set to `meshtasticAdmin` and the passw
### WiFi Client
With `wifi_ssid` & `wifi_password` populated, the device will now to connect to your network. Make sure you are in range of your WiFi. If you have a single device on your local network it's easy to connect to your device `http://meshtastic.local`. If you have multiple devices you will need to connect using thier respective IP addresses.
With `wifi_ssid` & `wifi_password` populated, the device will now to connect to your network. Make sure you are in range of your WiFi. If you have a single device on your local network it's easy to connect to your device `http://meshtastic.local`. If you have multiple devices you will need to connect using their respective IP addresses.
To disable WiFi completely, set `wifi_ap_mode` to `false`, and both `wifi_ssid` & `wifi_password` to an empty string `""`.

10
docs/software/web/config.md
View file

@ -10,11 +10,11 @@ Pre-requisite: You have Meshtastic Device firmware between version 1.0.32 - 1.1.
We do realize this installation method is not "easy" and are exploring ways to simplify this in the future, ideally rolling it out as part of the device firmware.
Once you have your device loaded with the Meshtastic Device firmware you need to connect to it's wifi and then manually upload the web interface files.
Once you have your device loaded with the Meshtastic Device firmware you need to connect to it's Wifi and then manually upload the web interface files.
### Connect to device wifi
### Connect to device Wifi
The easiest way to turn on the device wifi is to do the following after the device has been powered on:
The easiest way to turn on the device Wifi is to do the following after the device has been powered on:
* Hold down the user button
* Press and release the reset button
@ -45,7 +45,7 @@ To enable the WiFi to access the web interface, you must at minimum set two pref
`wifi_ssid`
`wifi_password`
For the wifi features to be enabled, those two properties must be set.
For the Wifi features to be enabled, those two properties must be set.
To turn it off, either of preference must be set as an empty string, that is a pair of double quotes each:
@ -56,7 +56,7 @@ Alternatively, you can enable the internal Soft Access Point:
`wifi_ap_mode true`
With that enabled, we will broadcast a new wifi network with the SSID and password you set. In AP mode, your device will act as a Captive Portal with a built in DNS server that resolves all name requests back to the device. Additionally, Apple Captive Portal Assistant is implemented -- if you're on an Apple device, the web interface will pop up automagically.
With that enabled, we will broadcast a new Wifi network with the SSID and password you set. In AP mode, your device will act as a Captive Portal with a built in DNS server that resolves all name requests back to the device. Additionally, Apple Captive Portal Assistant is implemented -- if you're on an Apple device, the web interface will pop up automagically.
To turn it off, simply reboot the device.

2
docs/software/web/web-app.md
View file

@ -4,7 +4,7 @@ title: Web interface overview
sidebar_label: Overview
---
The Meshtastic firmware incorporates an embedded webserver using the [ESP32 HTTPS Server](https://github.com/fhessel/esp32_https_server) project. This allows the wifi supporting ESP32 devices to run our web interface to access Meshtastic directly from your browser. This imports the [Meshtastic.js library](/docs/software/js/getting-started) to provide a web page capable of interacting with the device.
The Meshtastic firmware incorporates an embedded web server using the [ESP32 HTTPS Server](https://github.com/fhessel/esp32_https_server) project. This allows the Wifi supporting ESP32 devices to run our web interface to access Meshtastic directly from your browser. This imports the [Meshtastic.js library](/docs/software/js/getting-started) to provide a web page capable of interacting with the device.
:::caution
Please note that this is under active development and liable to change

4
website/docs/software/device/channels.md
View file

@ -12,9 +12,9 @@ Version 1.2 of the software adds support for multiple (simultaneous) channels.
### What is the Primary channel
The way this works is that each node keeps a list of channels it knows about. One of those channels (normally the first one) is labelled as the "PRIMARY" channel. The primary channel is the **only** channel that is used to set radio parameters. This channel controls things like spread factor, coding rate, bandwidth etc... Indirectly this channel also is used to select the specific frequency that all members of this mesh are talking over.
The way this works is that each node keeps a list of channels it knows about. One of those channels (normally the first one) is labeled as the "PRIMARY" channel. The primary channel is the **only** channel that is used to set radio parameters. This channel controls things like spread factor, coding rate, bandwidth etc... Indirectly this channel also is used to select the specific frequency that all members of this mesh are talking over.
This channel may or may not have a PSK (encryption). If you are providing mesh to 'the public' we recommend that you always leave this channel with its default psk. The default PSK is technically encrypted (and random users sniffing the ether would have to use Meshtastic to decode it), but the key is included in the github source code and you should assume any 'attacker' would have it. But for a 'public' mesh you want this, because it allows anyone using Meshtastic in your area to send packets through 'your' mesh.
This channel may or may not have a PSK (encryption). If you are providing mesh to 'the public' we recommend that you always leave this channel with its default PSK. The default PSK is technically encrypted (and random users sniffing the ether would have to use Meshtastic to decode it), but the key is included in the GitHub source code and you should assume any 'attacker' would have it. But for a 'public' mesh you want this, because it allows anyone using Meshtastic in your area to send packets through 'your' mesh.
```bash title="Setting default channel"
$ meshtastic --seturl https://www.meshtastic.org/d/#CgUYAyIBAQ