major organizational revamp

docs/1.2-End-of-life/hardware/heltec.mdx

@@ -1,46 +1,36 @@
 ---
-id: techo
-title: LILYGO® TTGO T-Echo devices
-sidebar_label: LILYGO® T-Echo
-sidebar_position: 2
+id: heltec
+title: Heltec device
+sidebar_label: Heltec
+sidebar_position: 6
 ---
 
-The T-Echo is the latest device to be release by LILYGO® supporting a low power consumption microcontroller.
+## WiFi LoRa 32 (V2) * Not Recommended - Support may be dropped
 
-### Features
+It continues to be a struggle to support this very old ESP32 chip, not officially supported in 1.3 / 2.0 and support may be dropped completely.
 
-- nRF52840 - Bluetooth BLE 5.0, NFC and very low power consumption
-- SX1262 - LoRa transceiver
-- 1.54" eInk display
-- L76K - GNSS receiver - Supporting GPS, BeiDou, GLONASS & QZSS
-- Reset, Program and capacitive touch buttons
+Using this device with a battery is not recommended.
+
+- ESP32 - Wifi & Bluetooth
+- SX127x - LoRa Transceiver
+- Frequency options:
+  - 433 MHz
+  - 470-510 MHz
+  - 863-870 MHz
+  - 902-928 MHz
+- Built in 0.96 inch OLED display
 - U.FL antenna connector
-- Optional BME280 - Humidity and Pressure Sensor
-- Comes with a case and battery
+- Reset and Program switches
+- No GPS
 
-### Resources
+- Firmware file: `firmware-heltec-1.x.x.bin`
 
-- Firmware file: `firmware-t-echo-2.x.x.uf2`
-- [Purchase link](https://www.aliexpress.com/item/1005002842456390.html)
-- TTGO's [GitHub page](https://github.com/Xinyuan-LilyGO/LilyGO-T-Echo) for the T-Echo
+[<img src="Heltec WiFi LoRa 32 (V2)" src="/img/hardware/heltec-v2.png" style={{zoom:'25%'}} />](/img/hardware/heltec-v2.png)
 
-<img
-  alt="LILYGO T-Echo"
-  src="/img/hardware/t-echo.png"
-  style={{ zoom: '15%' }}
-/>
+[<img src="Heltec WiFi LoRa 32 (V2) Pinouts" src="/img/hardware/heltec_v2_pinmap.png" style={{zoom:'25%'}} />](/img/hardware/heltec_v2_pinmap.png)
 
-### T-Echo button functions
+There are two versions of the Heltec (V2). Below is a picture highlighting the visual differences:
 
-- Capacitive top button
-  - A short press refreshes the current screen
-- Button 1
-  - A single press resets the device
-  - A double press puts the device into bootloader mode ready to receive a new firmware
-- Button 2
-  - A single press changes the page displayed on the device
-  - A double press turns the screen backlight on/off
-  - A long press turns the device off
+[<img src="Heltec WiFi LoRa 32 (V2)" src="/img/hardware/heltec_v2_vs_v21.png" style={{zoom:'25%'}} />](/img/hardware/heltec_v2_vs_v21.png)
 
-
-[<img alt="LILYGO T-Echo" src="/img/hardware/t-echo-lilygo.jpg" style={{zoom:'25%'}} />](/img/hardware/t-echo-lilygo.jpg)
+- See [hardware update log](https://docs.heltec.org/en/node/esp32/dev-board/hardware_update_log.html) for more details

docs/1.2-End-of-life/settings/range-test-module.mdx

@@ -179,7 +179,7 @@ Be sure to turn off either the plugin configured as a sender or the device where
 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.
 
 :::note
-Leaving this plugin on can slow down your mesh. Currently, the messages are sent using the same `TEXT_MESSAGE_APP` [port that all other messages](/docs/developers/protobufs/api#portnumsproto) are sent on.
+Leaving this plugin on can slow down your mesh. Currently, the messages are sent using the same `TEXT_MESSAGE_APP` [port that all other messages](/docs/development/firmware/portnum) are sent on.
 :::
 
 ```plaintext title="Example URLs"

docs/1.2-End-of-life/settings/store-and-forward-module.mdx

@@ -291,7 +291,7 @@ Initial Requirements:
 
 ### Meshtastic channel configuration
 
-Don't use this on the "Long Range / Slow" or "Long Range / Fast" channel settings. You're welcome to try and report back, but those channels have a [very low bitrate](/docs/developers/firmware/radio-settings#pre-defined).
+Don't use this on the "Long Range / Slow" or "Long Range / Fast" channel settings. You're welcome to try and report back, but those channels have a [very low bitrate](/docs/mesh/radio-settings#pre-defined).
 
 Either use a custom channel configuration with at an at least 1kbit data rate or use "Medium Range / Fast".
 

docs/1.2-End-of-life/software/mqtt.mdx

@@ -36,7 +36,7 @@ The payload is a raw protobuf. Looking at the MQTT traffic with a program like `
 	ShortFast	!937bed1c
 ```
 
-Packets from the following [port numbers](/docs/developers/Firmware/portnum) are serialized to JSON and then forwarded to the `msh/1/json/CHANNELID/DEVICEID` topic: `TEXT_MESSAGE_APP`, `ENVIRONMENTAL_MEASUREMENT_APP`, `NODEINFO_APP` and `POSITION_APP`.
+Packets from the following [port numbers](/docs/development/firmware/portnum) are serialized to JSON and then forwarded to the `msh/1/json/CHANNELID/DEVICEID` topic: `TEXT_MESSAGE_APP`, `ENVIRONMENTAL_MEASUREMENT_APP`, `NODEINFO_APP` and `POSITION_APP`.
 
 An example of a received `NODEINFO_APP` message:
 
@@ -147,7 +147,7 @@ FIXME - explain this more, talk about how useful for users and security domains.
 
 ## On device API
 
-For information on the related on-device API see [here](/docs/developers/firmware/device-api).
+For information on the related on-device API see [here](/docs/development/protobuf-api).
 
 ## MQTT transport
 
@@ -169,7 +169,7 @@ FIXME, discuss possible attacks by griefers and how they can be prevented
 
 #### Service Envelope
 
-The payload published on mesh/... will always be wrapped in a [ServiceEnvelope protobuf](/docs/developers/protobufs/api#serviceenvelope).
+The payload published on mesh/... will always be wrapped in a [ServiceEnvelope protobuf](/docs/development/protobuf-api#serviceenvelope).
 
 ServiceEnvelope will include the message, and full information about arrival time, who forwarded it, source channel, source mesh id, etc...
 

docs/about/_category_.yml

@@ -0,0 +1,7 @@
+position: 1 # float position is supported
+label: About
+collapsible: true # make the category collapsible
+link:
+  type: generated-index
+  title: About Meshtastic
+  slug: /about

docs/about/contributing.mdx

@@ -1,11 +1,10 @@
 ---
-id: contributing
-title: Contributing
-slug: /developers/contributing
+title: Community Guide
+sidebar_label: Contributing
+slug: /contributing
+sidebar_position: 2
 ---
 
-# 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 to improve Meshtastic.
 
 - If you're a developer, there's plenty stuff to do. Dig in!
@@ -22,7 +21,7 @@ There are many technologies (and repositories) used in creating the Meshtastic e
 
 ## Protocol buffers
 
-Most communication and interactions happen with protocol buffers. The [Meshtastic Protobuf Definitions](https://github.com/meshtastic/protobufs) repo is where all of the protocol buffer changes happen. See the [Protobuf API Reference](/docs/developers/protobufs/api) for more details.
+Most communication and interactions happen with protocol buffers. The [Meshtastic Protobuf Definitions](https://github.com/meshtastic/protobufs) repo is where all of the protocol buffer changes happen. See the [Protobuf API Reference](/docs/development/protobuf-api) for more details.
 
 ## Firmware
 
@@ -53,7 +52,7 @@ The [meshtastic/meshtastic.js](https://github.com/meshtastic/meshtastic.js) repo
 
 There are two phone apps that interact with the Meshtastic devices:
 
-- The [meshtastic/Meshtastic-Android](https://github.com/meshtastic/Meshtastic-Android) repository repo contains the Kotlin code for Android based interactions with Meshtastic devices. See [here](/docs/developers/android/build-app) for how to build/create a development environment for the Meshtastic Android App.
+- The [meshtastic/Meshtastic-Android](https://github.com/meshtastic/Meshtastic-Android) repository repo contains the Kotlin code for Android based interactions with Meshtastic devices. See [here](/docs/development/android/build-app) for how to build/create a development environment for the Meshtastic Android App.
 - The iOS app is in the process of a complete re-write in Swift and will have the new repo published soon. Note: There are a couple of earlier implementations.
 
 ## Documentation

docs/about/faq.mdx

@@ -2,31 +2,10 @@
 id: faq
 title: FAQs
 slug: /faq
-sidebar_position: 8
+sidebar_position: 3
 ---
 
-<!---
-Note to Contributors:
-
-Best Practices for the FAQ:
-
-- Keep the answers Non-Technical. The FAQ should be targeted to non-geeks.
-- This FAQ is not the authoritative document. Provide a short answer and a link to learn more.
-
-Format should be:
 ## Overview
-Details about FAQ page
-
-### Question
-Answer (Include links to settings/developers/supported hardware etc)
-
- --->
-
-## Overview
-
-### What is Meshtastic?
-
-Meshtastic is the most awesome long range, low power communications service on the planet earth! That's not even an exaggeration!
 
 ### Where can I get additional help, ask questions, or bond with the Meshtastic community?
 
@@ -226,4 +205,4 @@ A list of available modules is available [here](/docs/settings/moduleconfig).
 
 ### I'd like to write a module. How do I get started?
 
-API documentation for creating modules is available [here](/docs/developers/firmware/module-api).
+API documentation for creating modules is available [here](/docs/development/firmware/module-api).

docs/about/introduction.mdx

@@ -1,7 +1,7 @@
 ---
 title: Introduction
-sidebar_label: About
-slug: /about
+sidebar_label: Introduction
+slug: /introduction
 sidebar_position: 1
 ---
 
@@ -14,7 +14,7 @@ Meshtastic® is a project that enables you to use inexpensive LoRa radios as a l
 - No phone required for node to node communication.
 - Encrypted communication
 - Excellent battery life (LoRa radios have a very low power draw)
-- Send and recieve text messages between members of the mesh
+- Send and receive text messages between members of the mesh
 - Enable optional GPS based location features
 - And more!
 
@@ -27,7 +27,7 @@ The radios automatically rebroadcast messages they receive in order to create a
 Radios can be paired to a single phone so that your friends and family are able to address a message to your specific radio. Each device supports a connection from a single user at a time.
 
 <!--- FIXME: too technical for intro ?
-When you send a message on your Meshtastic companion app, it is relayed to the radio using bluetooth. That message is then broadcast by the radio three times over a certain interval in order to create redundancy for lost packets.
+When you send a message on your Meshtastic companion app, it is relayed to the radio using Bluetooth. That message is then broadcast by the radio three times over a certain interval in order to create redundancy for lost packets.
 
 When a receiving radio captures a packet, it checks to see if it has heard that message before. If it has it ignores the message. If it hasn't heard the message, it will rebroadcast it at a certain interval three times.
 

docs/developers/api.mdx

@@ -1,36 +0,0 @@
----
-id: api
-title: APIs
-sidebar_label: APIs
----
-
-## General
-
-:::note
-
-Currently there are three methods of interfacing with devices: `HTTP`, `BLE`, and `Serial`.
-
-Whilst each method has it's own ways sending and receiving data, the underlying protobuf transport medium remains the same.
-:::
-
-## HTTP
-
-### Endpoints
-
-#### `PUT` /api/v1/toradio
-
-#### `GET` /api/v1/fromradio&all=`boolean`
-
-## BLE
-
-:::important
-UUID for the service: `6ba1b218-15a8-461f-9fa8-5dcae273eafd`
-:::
-
-## Serial
-
-:::important
-
-You can communicate with devices with a baud rate of `921600`bps
-
-:::

docs/developers/documentation/github.mdx

@@ -1,14 +0,0 @@
----
-id: github
-title: GitHub
-sidebar_label: GitHub
----
-
-## Overview
-
-All of Meshtastic's code and documentation is hosted on GitHub. If you would like to contribute to the project, having a GitHub account is an important step to doing so.
-
-## Set up GitHub account
-
-- Go to [github.com](https://github.com)
-- Click `Sign Up`

docs/development/_category_.yml

@@ -1,6 +1,5 @@
-
 position: 6 # float position is supported
-label: 'Developers'
+label: Development
 collapsible: true # make the category collapsible
 link:
   type: generated-index

docs/development/android/_category_.yml

@@ -1,5 +1,4 @@
-
-position: 3 # float position is supported
+position: 2 # float position is supported
 label: 'Android'
 collapsible: true # make the category collapsible
 link:

docs/development/documentation/github.mdx

@@ -1,16 +1,25 @@
 ---
-id: readmes
-title: README Structure
-sidebar_label: READMEs
+id: github
+title: GitHub
+sidebar_label: GitHub
 ---
 
-## Outline
+## Overview
+
+All of Meshtastic's code and documentation is hosted on GitHub. If you would like to contribute to the project, having a GitHub account is an important step to doing so.
+
+## Set up GitHub account
+
+- Go to [github.com](https://github.com)
+- Click `Sign Up`
+
+
+## README Template
 
 All Meshtastic developers should follow this convention when writing a README for a repository.
 
 Repobeats images can be generated at [repobeats.axiom.co](https://repobeats.axiom.co/)
 
-
 ```markdown
 # Repo name
 
@@ -28,7 +37,6 @@ A description about the project
 
 **[Documentation/API Reference](https://example.com)**
 
-
 ## Stats
 
 <!--Repobeats image here-->

docs/development/documentation/publish.mdx

@@ -1,7 +1,7 @@
 ---
 id: publish
-title: Publishing Meshtastic
-sidebar_label: Publishing Meshtastic
+title: Publishing Meshtastic.org
+sidebar_label: Publish Meshtastic.org
 ---
 
 This document is a WIP.

docs/development/firmware/_category_.yml

@@ -1,7 +1,7 @@
-
 position: 1 # float position is supported
-label: 'Firmware'
+label: Firmware
 collapsible: true # make the category collapsible
 link:
   type: generated-index
-  title: Firmware
+  title: Firmware
+  slug: /firmware

docs/development/firmware/module-api.mdx

@@ -48,7 +48,7 @@ A number of [key services](http://github.com/meshtastic/firmware/tree/master/src
 
 The easiest way to get started is:
 
-- [Build and install](/docs/developers/firmware/build) the standard codebase from GitHub.
+- [Build and install](/docs/development/firmware/build) the standard codebase from GitHub.
 - Copy [src/modules/ReplyModule.\*](http://github.com/meshtastic/firmware/tree/master/src/modules/ReplyModule.cpp) into src/modules/YourModule.*. Then change the port number from *PortNum_REPLY_APP* to *PortNum_PRIVATE_APP\*.
 - Edit moduless/Moduless.cpp:setupModules() to add a call to create an instance of your module (see comment at head of that function)
 - Rebuild with your new messaging goodness and install on the device
@@ -72,7 +72,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 publicly
-- **1024-66559** Are reserved for use by IP tunneling (see [here](/docs/developers/firmware/portnum) for more information)
+- **1024-66559** Are reserved for use by IP tunneling (see [here](/docs/development/firmware/portnum) for more information)
 
 All other values are reserved.
 

docs/development/firmware/port-numbers.mdx

@@ -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/development/protobuf-api#portnumsproto)

docs/development/protobuf-api.mdx

@@ -1,9 +1,11 @@
 ---
-id: api
+id: protobuf-api
 title: Protobuf API Reference
-sidebar_label: API
+sidebar_label: Protobuf Reference
 ---
 
+<!-- THIS PAGE IS AUTOGENERATED FROM ./scripts/gen-proto-docs.sh DO NOT EDIT -->
+
 
 ## admin.proto
 
@@ -1140,6 +1142,7 @@ To match the old style filenames, _ is converted to -, p is converted to .
 | `LILYGO_TBEAM_S3_CORE` | `12` | New T-BEAM with ESP32-S3 CPU |
 | `RAK11200` | `13` | RAK WisBlock ESP32 core: https://docs.rakwireless.com/Product-Categories/WisBlock/RAK11200/Overview/ |
 | `NANO_G1` | `14` | B&Q Consulting Nano Edition G1: https://uniteng.com/wiki/doku.php?id=meshtastic:nano |
+| `TLORA_V2_1_1P8` | `15` | TODO: REPLACE |
 | `STATION_G1` | `25` | B&Q Consulting Station Edition G1: https://uniteng.com/wiki/doku.php?id=meshtastic:station |
 | `LORA_RELAY_V1` | `32` | Less common/prototype boards listed here (needs one more byte over the air) |
 | `NRF52840DK` | `33` | TODO: REPLACE |

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

@@ -15,7 +15,7 @@ Make sure not to power the radio on without first attaching the antenna! You cou
 For ESP32 devices if the device already has a version of Meshtastic installed using the OTA firmware upgrade tool in the Android app is the friendliest path for users. OTA firmware updates are not yet available on Apple platforms.
 
 If your ESP32 device does not have Meshtastic pre-installed flashing
-Before you flash your device start by verifiying connectivity with the device being flashed. Outlined below are steps that can be taken to verify connectivity and, if necessary, to install the appropriate drivers. If you end up needing to install drivers be sure to reboot your computer afterwards to verify the installation is complete.
+Before you flash your device start by verifying connectivity with the device being flashed. Outlined below are steps that can be taken to verify connectivity and, if necessary, to install the appropriate drivers. If you end up needing to install drivers be sure to reboot your computer afterwards to verify the installation is complete.
 
 :::note
 The [T-Beam 0.7](/docs/hardware/supported/tbeam#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.

docs/getting-started/flashing-firmware/esp32/external-serial-adapter.mdx

@@ -21,7 +21,7 @@ Make sure not to power the radio on without first attaching the antenna! You cou
 Situations that may require usage an external USB to Serial Adapter:
 * Due to the chip shortage, recently purchased devices such as the TTGO T-Beam may come with legacy or non-standard USB to Serial adapter chips that are unreliable in some cases. 
 * Certain devices might have defective USB to Serial chip.
-* Certain devices, such as the [Hydra](https://github.com/Hydra-Designs/project-hydra-meshtastic-pcb) (Meshtastic-diy target).
+* Certain devices, such as the [Hydra](https://github.com/Hydra-Designs/project-hydra-meshtastic-pcb) (Meshtastic-DIY target).
 
 ### USB Serial Adapters
 
@@ -36,7 +36,7 @@ Plug the adapter into your computer without connecting it to any devices yet. En
 ### Connecting Adapter to the Device
 
 :::info
-There are multiple ways to connect the pins of the adapter to the target device: pressing jumpers against contacts, using pogo pin jigs, etc. This tutorial features offset dupont headers soldered onto the operative gpio pins and connected via jumpers.
+There are multiple ways to connect the pins of the adapter to the target device: pressing jumpers against contacts, using pogo pin jigs, etc. This tutorial features offset dupont headers soldered onto the operative GPIO pins and connected via jumpers.
 :::
 Disconnect your USB to Serial Adapter from the computer before starting this process. 
 
@@ -59,17 +59,17 @@ Example using the Meshtastic Flasher
 ![image](https://user-images.githubusercontent.com/9000580/168447086-313e0649-1bfe-4ccb-b891-0f56059d8063.png)
 
 After flashing the device is complete, reset your device (via the RST button if available).
-If you have the meshastic python cli installed, you can run `meshatstic --noproto` to connect the device again over the adapter and view the serial output to confirm meshtastic installed correctly.
+If you have the Meshtastic Python CLI installed, you can run `meshtastic --noproto` to connect the device again over the adapter and view the serial output to confirm Meshtastic installed correctly.
 ![image](https://user-images.githubusercontent.com/9000580/168447159-71a6546a-f487-4bc2-86c1-4c489b2a8975.png)
 
 
 ### Troubleshooting
 
-In the Mesthastic Flasher, device detection may not work when using the external USB to Serial adapter. You might need to manually select the correct device type from the dropdown.
+In the Meshtastic Flasher, device detection may not work when using the external USB to Serial adapter. You might need to manually select the correct device type from the drop-down.
 
 ![image](https://user-images.githubusercontent.com/9000580/168447197-206f7e14-debe-4b6a-bb2a-7647418075e4.png)
 
-Sometimes you might receive an error for COM port permission in the Mestastic Flasher or the manual device install scripts, this can be caused by a number of different issues. 
+Sometimes you might receive an error for COM port permission in the Meshtastic Flasher or the manual device install scripts, this can be caused by a number of different issues. 
 
 You might need to run the process as an administrator, check to ensure software like Cura isn't monopolizing COM ports, or reboot. 
 ![image](https://user-images.githubusercontent.com/9000580/168447232-1a3af39b-e3cc-44b9-bc3a-32843a9e6f1f.png)

docs/getting-started/flashing-firmware/esp32/index.mdx

@@ -7,9 +7,7 @@ sidebar_position: 2
 
 ## Flashing Method for ESP32 Devices
 
-We recommend using the following methods for flashing ESP32 devices:
-
-1. The [Web-based installer](https://flasher.meshtastic.org) requires either Chrome or Edge broswers but is an excellent choice for quickly flashing devices.
+1. The [Web-based installer](https://flasher.meshtastic.org) requires either Chrome or Edge browsers but is an excellent choice for quickly flashing devices.
 2. The [Python Flasher](/docs/software/python/flasher) does a lot under the hood to prevent you from needing to use the terminal. It also allows you to configure your device.
 3. The [CLI Script](/docs/getting-started/flashing-firmware/esp32/cli-script) is considered the "manual process" for flashing firmware.
 4. Flashing your device using an [external serial adapter](/docs/getting-started/flashing-firmware/esp32/external-serial-adapter) should only be attempted as a last resort if no other method has been successful.

docs/getting-started/flashing-firmware/esp32/python-flasher.mdx

@@ -1,10 +1,10 @@
 ---
 id: meshtastic-flasher-esp32
-title: Using Python Meshtastic Flasher
+title: Using Meshtastic Python Flasher
 sidebar_label: Python Flasher
 sidebar_position: 2
 ---
 
-import MFlasher from '../../../software/python/meshtastic-flasher.mdx' 
+import MFlasher from '../../../software/python/flasher.mdx' 
 
 <MFlasher components={props.components} />

docs/getting-started/flashing-firmware/esp32/web-flasher.mdx

@@ -5,5 +5,8 @@ sidebar_label: Web Flasher (recommended)
 sidebar_position: 1
 ---
 
+## Web Flasher
 
-The [Web-based Installer](https://flasher.meshtastic.org) requires Chrome or Edge browser.
+1. Plug in your device
+2. Visit [flasher.meshtastic.org](https://flasher.meshtastic.org) _\*requires Chrome or Edge browser_
+3. Follow the instructions

docs/getting-started/flashing-firmware/nrf52/drag-n-drop.mdx

@@ -12,9 +12,7 @@ import TabItem from '@theme/TabItem';
 Before flashing confirm that you have [RAK4631](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK4631/) and not a [RAK4631-R](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK4631-R/) If this is not the case, fear not. The hardware is identical but requires changing the bootloader. Instructions on how to do this are located [here](/docs/getting-started/flashing-firmware/nrf52/#convert-rak4631-r-to-rak4631).
 :::
 
-The NRF52 based devices (LilyGO T-Echo, RAK Wisblock 4631) have the easiest firmware upgrade process. No driver or software install is required on any platform.
-
-Download and unzip the latest frimware from [Meshtastic Downloads](https://meshtastic.org/downloads).
+Download and unzip the latest firmware from [Meshtastic Downloads](https://meshtastic.org/downloads).
 
 1. Connect your device to your computer with a data USB cable.
 2. Double click the reset button on your device (this will put it into bootloader mode) 

docs/getting-started/flashing-firmware/nrf52/index.mdx

@@ -7,22 +7,18 @@ sidebar_position: 2
 
 ## Flashing Methods for NRF52 Devices
 
-If you have RAK NRF based devices or a LilyGO T-Echo
+The NRF52 based devices have the easiest firmware upgrade process. No driver or software install is required on any platform.
 
 1. The [drag and drop](/docs/getting-started/flashing-firmware/nrf52/drag-n-drop) firmware installation is considered the "manual process" and recommended as the easiest solution.
 2. The [Python Flasher](/docs/software/python/flasher) application does a lot under the hood to prevent you from needing to use the terminal. It also allows you to configure your device.
 
 ## Convert RAK4631-R to RAK4631
 
-The RAK4631-R is just the same as the RAK4631 in terms of hardware, the only difference is the bootloader it is shipped with.
+The only difference between the _RAK4631-R_ (RUI3) and the _RAK4631_ (Arduino) is the bootloader it is shipped with - the hardware is the same.
 
-The RAK4631-R is shipped with the RUI3 bootloader, the RAK4631 with the Arduino bootloader.
+Meshtastic requires the Arduino bootloader on RAK WisBlock NRF52-based boards. The process of converting the bootloader only needs to be performed once.
 
-Running Meshtastic on RAK WisBlock NRF52-based boards relies on the Arduino bootloader.
-
-The process of converting the bootloader only needs to be performed once.
-
-This conversion requires the use of either a [DAPLink](https://daplink.io/) or [J-Link](https://www.segger.com/products/debug-probes/j-link/). The most reasonably priced and avaliable is the [RAKDAP1](https://store.rakwireless.com/products/daplink-tool).
+This conversion requires the use of either a [DAPLink](https://daplink.io/) or [J-Link](https://www.segger.com/products/debug-probes/j-link/). The most reasonably priced and available is the [RAKDAP1](https://store.rakwireless.com/products/daplink-tool).
 
 1. Install [Python](https://www.python.org/downloads/)
 2. Install [pyOCD](https://pyocd.io/)

docs/getting-started/flashing-firmware/nrf52/python-flasher.mdx

@@ -1,10 +1,10 @@
 ---
 id: meshtastic-flasher-nrf52
-title: Using Python Meshtastic Flasher
+title: Using Meshtastic Python Flasher
 sidebar_label: Python Flasher
 sidebar_position: 2
 ---
 
-import MFlasher from '../../../software/python/meshtastic-flasher.mdx' 
+import MFlasher from '../../../software/python/flasher.mdx' 
 
 <MFlasher components={props.components} />

docs/getting-started/index.mdx

@@ -1,5 +1,4 @@
 ---
-id: overview
 title: Getting Started
 sidebar_label: Getting Started
 slug: /getting-started
@@ -10,13 +9,13 @@ import Link from '@docusaurus/Link';
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-## Identify your Hardware
+## Identify Hardware
 
-The first order of business in getting started is determining what type of hardware you will be working with. Meshtastic currently supports devices with either of the two Microcontroller Units (MCU):
+The first order of business in getting started is determining what type of hardware you will be working with. Meshtastic currently supports devices with either of the two Micro-Controller Units (MCU):
 
 ### ESP32
 
-The ESP32 is older and consumes more power than the nrf52, but is equiped with both WiFi and Bluetooth. Supported ESP32 devices:
+The ESP32 is older and consumes more power than the nrf52, but is equipped with both WiFi and Bluetooth. Supported ESP32 devices:
 
 - LILYGO® TTGO T-Beam
 - LILYGO® TTGO Lora
@@ -25,33 +24,33 @@ The ESP32 is older and consumes more power than the nrf52, but is equiped with b
 
 ### NRF52
 
-The NRF52 is much more power effecient than the esp32 and easier to update, but is only equiped Bluetooth. Supported NRF52 devices:
+The NRF52 is much more power efficient than the esp32 and easier to update, but is only equipped with Bluetooth. Supported NRF52 devices:
 
 - RAK WisBlock
 - LILYGO® TTGO T-Echo
 
 :::info
-If your device is not listed above, please review our [supported hardware](/docs/category/supported-hardware) devices to determine which MCU your device has or contact us in [Discord](https://discord.gg/ktMAKGBnBs) with any questions.
+If your device is not listed above, please review our [supported hardware](/docs/supported-hardware) devices to determine which MCU your device has or contact us in [Discord](https://discord.gg/ktMAKGBnBs) with any questions.
 :::
 
-## Connect your device
+## Connect Device
 
-:::danger
-Stop! Never power on the radio without attaching an antenna! (it could damage the radio chip)
+:::danger STOP! Put the power cable down!
+Never power on the radio without attaching an antenna! _it could damage the radio chip._
 :::
 
 Prior to connecting your Meshtastic device to the computer, you should perform the following basic checks.
 
 ### Verify data cable
 
-Some cables only provide _charging_, verify that your cable is also capable of _transfering data_ before proceeding. 
+Some cables only provide _charging_, verify that your cable is also capable of _transferring data_ before proceeding. 
 
 There is no definitive way to determine the difference in cables if you aren't willing to pull it apart. Trying out a few cables will be the best way to verify.
 
 Once you've located a working data cable, [install the correct serial driver](#install-serial-drivers) and [test for driver installation](#test-for-driver-installation).
 
 
-### Install Serial Drivers
+### Install serial drivers
 
 <div className="indexCtasBody">
   <Link target="_blank"
@@ -62,7 +61,7 @@ Once you've located a working data cable, [install the correct serial driver](#i
   </Link>
 </div>
 
-### Test for driver installation
+### Test driver installation
 
 You can verify that you have a proper data cable (rather than a charge-only type cable) and that the appropriate drivers for your system are installed by performing the following test: 
 
@@ -120,7 +119,7 @@ If you do not see your device:
 2. You may need to [install the USB serial driver](/docs/getting-started/serial-drivers)).
 :::
 
-## Flashing Firmware
+## Flash Firmware
 
 ### ESP32
 
@@ -135,7 +134,7 @@ If you do not see your device:
 
 ### NRF52
 
-For RAK4631 users, if you have a RAK4631-R (the RUI3 bootloader version of the RAK4631), please [convert to the Arduino bootloader](/docs/getting-started/flashing-firmware/nrf52/#convert-rak4631-r-to-rak4631)
+For RAK4631 users, if you have a RAK4631-R (the RUI3 bootloader version of the RAK4631), you must [convert it to use the Arduino bootloader](/docs/getting-started/flashing-firmware/nrf52/#convert-rak4631-r-to-rak4631)
 
 <div className="indexCtasBody">
   <Link target="_blank"
@@ -148,8 +147,6 @@ For RAK4631 users, if you have a RAK4631-R (the RUI3 bootloader version of the R
 
 ## Use Meshtastic
 
-There are many ways to interact with and use Meshtastic, please visit the [Software](/docs/software) page for more information.
-
 ### with mobile apps
   - [Android](/docs/software/android/)
   - [Apple](/docs/software/apple/)
@@ -161,3 +158,5 @@ There are many ways to interact with and use Meshtastic, please visit the [Softw
 ### over the internet with MQTT
   - [MQTT](/docs/software/mqtt/)
 
+There are many ways to interact with and use Meshtastic, please visit the [Software](/docs/software) page for more information.
+

docs/getting-started/serial-drivers/index.old

@@ -1,83 +0,0 @@
----
-id: serial-drivers
-title: Installing Serial Drivers
-sidebar_label: Install Serial Drivers
-sidebar_position: 1
----
-
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
-:::caution
-Make sure not to power the radio on without first attaching the antenna! You could damage the radio chip!
-:::
-
-Prior to connecting your Meshtastic device to the computer, you should perform the following basic checks.
-
-## Verify data cable
-
-Verify that you have a **data cable** and _not_ a **charging _only_ cable** before proceeding. There is no definitive way to determine the difference in cables if you aren't willing to pull it apart. Trying out a few cables will be the best way to verify.
-
-Once you've located a working data cable, [test for driver installation](/docs/getting-started/serial-drivers/#test-for-driver-installation) to see if you need to install a driver to communicate with your device.
-
-If you know you have installed the correct driver, the following step can be used to check if you have a proper data cable.
-
-## Test for driver installation
-
-You can verify that you have a proper data cable (rather than a charge-only type cable) and that the appropriate drivers for your system are installed by performing the following test: 
-
-_select your operating system below_
-
-<Tabs
-groupId="operating-system"
-defaultValue="linux"
-values={[
-{label: 'Linux', value: 'linux'},
-{label: 'macOS', value: 'macos'},
-{label: 'Windows', value: 'windows'},
-]}>
-<TabItem value="linux">
-
-1. Connect your Meshtastic device to your USB port
-2. Open a **Terminal** and enter the following command:
-
-  ```shell
-  lsusb
-  ```
-3. You should see something like: 
-
-  ```shell
-  ID xxxx:xxxx Silicon Labs CP210x UART Bridge
-  # or
-  ID xxxx:xxxx QinHeng Electronics USB Single Serial
-  # or
-  FIXME (WISBLOCK OUTPUT)
-  ```
-
-</TabItem>
-<TabItem value="macos">
-
-1. Navigate to `Apple Menu  > About This Mac > System Report... > Hardware > USB`. 
-2. You should see similar to one of the following entries:
-  - `CP210X USB to UART Bridge Controller`
-  - `CH9102 USB to UART Bridge Controller`
-  - `WisCore RAK4631 Board`
-
-</TabItem>
-<TabItem value="windows">
-
-1. Navigate to `Device Manager > Ports (COM & LPT)`
-2. You should see similar to one of the following entries:
-  - `Silicon Labs CP210X USB to UART Bridge (COM5)`
-  - `Silicon Labs CH9102 USB to UART Bridge (COM5)`
-  - `FIXME (WISBLOCK OUTPUT)`
-
-</TabItem>
-</Tabs>
-
-If you can see your device, you are ready to flash the firmware. Skip to the [Flashing Firmware](/docs/getting-started/flashing-firmware/) section.
-
-If you do not see your device after performing the check:
-
-1. You may be using a charging-only cable.
-2. You may need to install the USB serial driver corrosponding to your device ([ESP32](/docs/getting-started/serial-drivers/installing-esp32-serial-drivers) or [NRF52](/docs/getting-started/serial-drivers/installing-nrf52-serial-drivers)).

docs/getting-started/serial-drivers/serial-drivers-esp32.mdx

@@ -2,6 +2,7 @@
 id: installing-esp32-serial-drivers
 title: ESP32 Serial Drivers
 sidebar_label: ESP32 Drivers
+#pagination_next: /docs/getting-started
 sidebar_position: 1
 ---
 

docs/hardware/_category_.yml

@@ -1,6 +1,6 @@
-position: 3 # float position is supported
-label: 'Hardware'
-collapsible: true # make the category collapsible
+label: Hardware
+collapsible: true
+position: 3
 link:
   type: generated-index
   title: Hardware

docs/hardware/antennas.mdx

@@ -1,53 +0,0 @@
----
-id: lora-antenna
-title: LoRa Antenna Selection
-sidebar_label: LoRa Antennas
-sidebar_position: 2
----
-
-The stock antennas provided with the T-Beam and other boards usually come from 'mixed bags'. They may not have been designed or tuned for your given frequency range, and they may not be of a quality design.
-
-Matching an antenna to the transceiver frequency is important, as is choosing an appropriate design.
-
-The antennas's design will affect:
-
-- Efficiency - The proportion of the signal which leaves the antenna
-- Direction in which the signal is transmitted
-- Interference by horizontal or vertical polarization
-- Amount of signal which is reflected back to the device itself
-
-:::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.
-:::
-
-## Important considerations
-
-### What transmission frequency are you using?
-- Devices on another frequency will not be able to interact with yours.
-- 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 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 or attenuated.
-
-### Does my Meshtastic device have the right power range, impedance, and connector for the aerial?
-- For the LoRa devices, it should be 50 Ohm impedance with SMA connector. Many antennas will be recommended for LoRa use in their technical details.
-- By contrast, a close range, contactless Personal Area Network antenna, or a huge aerial at the end of length of coax designed for a 100W transmitter, are not going to be operable.
-
-
-### Cost, quality, and supply service?
-- The perfect aerial on paper, sourced from the other side of the world with mixed reviews, doesn't compare to a local supplier who has spent time carefully collating all of the aerial data-sheets for comparison _and_ holds stock immediately available. Personally, I prefer to pay significantly more for a time saving, quality service.
-
-### How close will the antenna be to my Meshtastic device?
-- Most cables will significantly degrade the signal strength over any significant distance. It is often more effective to place a node outside, than to have it indoors with the antenna outside. (The exception might be if there is extreme heat, cold, or humidity, and if the shortest possible low loss cable is used. Still, a proper enclosure should mitigate bad weather.)
-
-## Terminology / references
-
-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 Spiess (the 'guy with the Swiss accent').

docs/hardware/enclosures/3dprinted.mdx

@@ -0,0 +1,8 @@
+---
+id: 3dprinted-enclosure
+title: 3D Printed Enclosures
+sidebar_label: 3D Printed
+sidebar_position: 1
+---
+
+... WIP

docs/hardware/enclosures/_category_.yml

@@ -0,0 +1,7 @@
+label: Enclosures
+collapsible: true
+position: 3
+link:
+  type: generated-index
+  title: Enclosures
+  slug: enclosures

docs/hardware/peripheral/_category_.yml

@@ -0,0 +1,7 @@
+label: Peripherals
+collapsible: true
+position: 2
+link:
+  type: generated-index
+  title: Peripherals
+  slug: peripherals

docs/hardware/peripheral/antennas/_category_.yml

@@ -0,0 +1,7 @@
+label: Antennas
+collapsible: true
+position: 1
+link:
+  type: generated-index
+  title: Antennas
+  slug: antenna

docs/hardware/peripheral/antennas/lora-antennas.mdx

@@ -0,0 +1,61 @@
+---
+id: lora-antenna
+title: LoRa Antenna Selection
+sidebar_label: LoRa Antennas
+sidebar_position: 2
+---
+
+The stock antennas provided with the T-Beam and other boards usually come from 'mixed bags'. They may not have been designed or tuned for your given frequency range, and they may not be of a quality design.
+
+Matching an antenna to the transceiver frequency is important, as is choosing an appropriate design.
+
+The antenna's design will affect:
+
+- Efficiency - The proportion of the signal which leaves the antenna
+- Direction in which the signal is transmitted
+- Interference by horizontal or vertical polarization
+- Amount of signal which is reflected back to the device itself
+
+:::caution
+While the LoRa devices we use for Meshtastic are relatively low power radios, care should be taken _not_ to operate any radio transmission device without an antenna or with a poorly matched antenna. Un-transmitted radio signal reflected back to the transmitter can damage the device.
+:::
+
+## Important considerations
+
+### What transmission frequency are you using?
+
+Devices on another frequency will not be able to interact with yours. 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 antenna will transmit over significantly greater distance than an omni-directional antenna. However, it must be pointed at its target - so it is not optimal for mobile use. 
+
+A tuned half-wave whip antenna 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 antenna is permanently positioned against a building, signal transmitted towards the wall will be largely lost or attenuated.
+
+### Does my Meshtastic device have the right power range, impedance, and connector for the antenna?
+
+For the LoRa devices, it should be 50 Ohm impedance with SMA connector. Many antennas will be recommended for LoRa use in their technical details.
+
+In contrast, a close range, contact-less Personal Area Network antenna, or a huge antenna at the end of length of coax designed for a 100W transmitter, are not going to be operable.
+
+### Cost, quality, and supply service?
+
+The perfect antenna on paper, sourced from the other side of the world with mixed reviews, doesn't compare to a local supplier who has spent time carefully collating all of the antenna data-sheets for comparison _and_ holds stock immediately available. Personally, I prefer to pay significantly more for a time saving, quality service.
+
+### How close will the antenna be to my Meshtastic device?
+
+Most cables will significantly degrade the signal strength over any significant distance. It is often more effective to place a node outside than to have it indoors with the antenna outside. The exception might be if there is extreme heat, cold, or humidity, and if the shortest possible low loss cable is used. 
+
+Still, a proper enclosure should mitigate bad weather.
+
+## Terminology / references
+
+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 Spiess (the 'guy with the Swiss accent').

docs/hardware/supported/_category_.yml

@@ -1,7 +1,7 @@
-
-position: 1 # float position is supported
-label: 'Supported Hardware'
-collapsible: true # make the category collapsible
+label: 'Supported Devices'
+collapsible: true
+position: 1
 link:
   type: generated-index
-  title: Supported Hardware
+  title: Supported Devices
+  slug: supported-hardware

docs/hardware/supported/lora.mdx

@@ -20,7 +20,7 @@ values={[
 ]}>
 <TabItem value="v1">
 
-- ESP32 - Wifi & Bluetooth
+- ESP32 - WiFi & Bluetooth
 - SX1276 - LoRa Transceiver
 - Frequency options:
   - 868 MHz
@@ -30,17 +30,15 @@ values={[
 - Reset and Program switches
 - No GPS
 
-
 - Firmware file: `firmware-tlora-v1-1.x.x.bin`
 - [Purchase link](https://www.aliexpress.com/item/32840238513.html)
 
-
 [<img alt="LILYGO® TTGO Lora V1" src="/img/hardware/lora-v1.png" style={{zoom:'25%'}} />](/img/hardware/lora-v1.png)
 
 </TabItem>
 <TabItem value="v1.3">
 
-- ESP32 - Wifi & Bluetooth
+- ESP32 - WiFi & Bluetooth
 - SX127x - LoRa Transceiver
 - Frequency options:
   - 868 MHz
@@ -61,7 +59,7 @@ values={[
 </TabItem>
 <TabItem value="v2.0">
 
-- ESP32 - Wifi & Bluetooth
+- ESP32 - WiFi & Bluetooth
 - SX127x - LoRa Transceiver
 - Frequency options:
   - 433 MHz
@@ -83,7 +81,7 @@ values={[
 </TabItem>
 <TabItem value="v2.1">
 
-- ESP32 - Wifi & Bluetooth
+- ESP32 - WiFi & Bluetooth
 - SX127x - LoRa Transceiver
 - Frequency options:
   - 433 MHz
@@ -99,7 +97,6 @@ values={[
 - Firmware file: `firmware-tlora-v2-1-1.6-1.x.x.bin`
 - [Purchase link](https://www.aliexpress.com/item/32915894264.html)
 
-
 <br />
 
 :::warning

docs/hardware/supported/nano-g1.mdx

@@ -7,7 +7,7 @@ sidebar_position: 4
 
 The Nano G1 is the first dedicated hardware to be designed from scratch purely for Meshtastic by Neil Hao. It has been designed to be small and compact with the inclusion of a high quality internal PCB antenna.
 
-Only the US 915 Mhz version is available currently. There should be an EU 868 Mhz version available in the future.
+Only the US 915 MHz version is available currently. There should be an EU 868 MHz version available in the future.
 
 ### Features
 
@@ -15,10 +15,10 @@ Only the US 915 Mhz version is available currently. There should be an EU 868 Mh
 - ESP32 WROOM microprocessor - WiFi & Bluetooth
 - Semtech SX1276 - LoRa Transceiver
 - Frequency options:
-  - 915 Mhz
+  - 915 MHz
 - Additional ultra-low noise amplifier to improve LoRa receiver sensitivity
 - ATGM336H-5N-71 Whole Constellation Positioning and Navigation Module (Supports GPS, BDS and GLONASS)
-- Built in 915Mhz Lora PCB Antenna (VSWR <=1.5 @ 915 Mhz)
+- Built in 915Mhz Lora PCB Antenna (VSWR <=1.5 @ 915 MHz)
 - User button
 - 1.3 inch OLED screen
 - Buzzer

docs/hardware/supported/rak4631.mdx

@@ -38,7 +38,6 @@ values={[
 - I<sup>2</sup>C, UART, GPIOs and analog input accessible with solder contacts
 - Micro USB port for debugging and power
 
-
 Further information on the RAK5005-O can be found on the [RAK Documentation Center](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK5005-O/Overview/#product-description).
 
 It may be possible to add a user button using the [13002 IO module](https://store.rakwireless.com/collections/wisblock-interface/products/adapter-module-rak13002).
@@ -46,7 +45,6 @@ It may be possible to add a user button using the [13002 IO module](https://stor
 - [Update the bootloader](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK4631/Quickstart/#updating-the-bootloader) on first use! This can be done easily with [Meshtastic-flasher](https://github.com/meshtastic/Meshtastic-gui-installer).
 - Firmware for 5005 base board: [`firmware-rak4631-1.x.x.uf2`](/downloads) 
 
-
   <img
     alt="RAK4631 5005"
     src="/img/hardware/rak4631_5005.png"
@@ -88,7 +86,7 @@ It is currently not possible to add a user button to this board.
 [RAK19001](https://store.rakwireless.com/products/rak19001-wisblock-dual-io-base-board) - WisBlock Dual IO Base Board
 
 :::caution
-This board should work with the RAK5005-O firmware, however this is currently uncomfirmed.
+This board should work with the RAK5005-O firmware, however this is currently unconfirmed.
 :::
 
 - Reset and user definable buttons
@@ -115,7 +113,7 @@ It may be possible to add a user button using the [13002 IO module](https://stor
 This is an upgrade to the original RAK5005-O base board.
 
 :::caution
-This board should work with the RAK5005-O firmware, however this is currently uncomfirmed.
+This board should work with the RAK5005-O firmware, however this is currently unconfirmed.
 :::
 
 - Reset button 
@@ -228,7 +226,7 @@ values={[
 ]}>
 <TabItem value="OLED">
 
-The [RAK1921 OLED display](https://store.rakwireless.com/products/rak1921-oled-display-panel) is a 0.96 inch monocrome display.
+The [RAK1921 OLED display](https://store.rakwireless.com/products/rak1921-oled-display-panel) is a 0.96 inch monochrome display.
 
 - 0.96 inch OLED display
 - Resolution 128 x 64 pixels
@@ -252,7 +250,7 @@ The [RAK1400 EPD module](https://store.rakwireless.com/products/wisblock-epd-mod
 - Occupies the IO Port of a Wisblock Base
 
 
-- Firmware for 5005 with RAK14000 epaper: [`firmware-rak4631_eink-1.3.x.uf2`](/downloads)
+- Firmware for 5005 with RAK14000 e-paper: [`firmware-rak4631_eink-1.3.x.uf2`](/downloads)
 
   <img
     alt="RAK4631 5005 14000"
@@ -282,7 +280,7 @@ values={[
 To add a GPS to the RAK5005-O base board, you need the [RAK1910 GPS sensor](https://store.rakwireless.com/collections/wisblock-sensor/products/rak1910-max-7q-gnss-location-sensor). It is supported on slot A of the 5005 board via UART.
 
 - uBlox MAX-7Q GPS module
-- GPS and GLONASS satelite support
+- GPS and GLONASS satellite support
 
 
 Further information on the RAK1910 can be found on the [RAK Documentation Center](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK1910/Overview/#product-description).
@@ -290,7 +288,7 @@ Further information on the RAK1910 can be found on the [RAK Documentation Center
 To add a GPS to the RAK19003 base board, you need the [RAK12500 GPS sensor](https://store.rakwireless.com/products/wisblock-gnss-location-module-rak12500). It is supported via I<sup>2</sup>C on slot B for firmware versions 1.49 and above.
 
 - uBlox Zoe-M8Q GNSS receiver
-- GPS, GLONASS, QZSS and BeiDou satelite support
+- GPS, GLONASS, QZSS and BeiDou satellite support
 
 
 Further information on the RAK12500 can be found on the [RAK Documentation Center](https://docs.rakwireless.com/Product-Categories/WisBlock/RAK12500/Overview/#product-description).
@@ -305,7 +303,7 @@ Further information on the RAK18001 can be found on the [RAK Documentation Cente
 </TabItem>
 <TabItem value="IO">
 
-The [RAK13002 IO Module](https://store.rakwireless.com/collections/wisblock-interface/products/adapter-module-rak13002) can be used to, amongst other things, add a user button to the RAK base boards (excluding the RAK19003 Mini base board). It features a number of different interface options:
+The [RAK13002 IO Module](https://store.rakwireless.com/collections/wisblock-interface/products/adapter-module-rak13002) can be used to, among other things, add a user button to the RAK base boards (excluding the RAK19003 Mini base board). It features a number of different interface options:
 
 - 2x I<sup>2</sup>C interfaces
 - 2x UART interfaces

docs/hardware/supported/station-g1.mdx

@@ -7,7 +7,7 @@ sidebar_position: 3
 
 The Station G1 is the first dedicated hardware to be designed from scratch purely for Meshtastic Licensed (HAM) Operation by Neil Hao. It has been designed to be small and compact with the inclusion of 35dBm high power PA.
 
-Only the US 915 Mhz version is available currently. There should be an EU 433 Mhz version available in the future.
+Only the US 915 MHz version is available currently. There should be an EU 433 MHz version available in the future.
 
 ### Features
 
@@ -15,7 +15,7 @@ Only the US 915 Mhz version is available currently. There should be an EU 433 Mh
 - ESP32 WROOM microprocessor - WiFi & Bluetooth
 - Semtech SX1262  - LoRa Transceiver
 - Frequency options:
-  - 915 Mhz
+  - 915 MHz
 - Additional 35dBm Lora Power Amplifier to boost the transmit power
 - User button
 - 1.3 inch OLED screen

docs/hardware/supported/tbeam.mdx

@@ -19,10 +19,11 @@ values={[
 {label: 'T-Beam with M8N & SX1262', value: 'sx1262'},
 {label: 'T-Beam v0.7', value:'0.7'}
 ]}>
+
 <TabItem value="1.1">
 
-- Meshtastic pre-installed
-- ESP32 - Wifi & Bluetooth
+- Meshtastic preinstalled
+- ESP32 - WiFi & Bluetooth
 - SX1276 - LoRa Transceiver
 - Frequency options:
   - 433 MHz
@@ -34,6 +35,7 @@ values={[
 - Power, Program and Reset switches
 - **Comes with 0.96 inch OLED display (some soldering required to assemble)**
 
+
 - Firmware file: `firmware-tbeam-1.x.x.bin`
 - [Purchase link](https://www.aliexpress.com/item/4001178678568.html)
 
@@ -42,9 +44,10 @@ values={[
 [<img alt="LILYGO® TTGO T-Beam v1.1 pinmap" src="/img/hardware/t-beam_v1.1_pinmap.webp" style={{zoom:'35%'}} />](/img/hardware/t-beam_v1.1_pinmap.webp)
 
 </TabItem>
+
 <TabItem value="m8n">
 
-- ESP32 - Wifi & Bluetooth
+- ESP32 - WiFi & Bluetooth
 - SX1276 - LoRa Transceiver
 - Frequency options:
   - 433 MHz
@@ -66,7 +69,7 @@ values={[
 </TabItem>
 <TabItem value="sx1262">
 
-- ESP32 - Wifi & Bluetooth
+- ESP32 - WiFi & Bluetooth
 - **SX1262 - LoRa Transceiver - improved performance**
 - Frequency options:
   - 433 MHz
@@ -94,7 +97,7 @@ This is an earlier version of the T-Beam board, and due to changes in the design
 `firmware-tbeam0.7-1.x.x.bin` is the correct firmware. `firmware-tbeam-1.x.x.bin` is incompatible. For all other T-Beam boards `firmware-tbeam-1.x.x.bin` is the correct selection.
 :::
 
-- ESP32 - Wifi & Bluetooth
+- ESP32 - WiFi & Bluetooth
 - SX1276 - LoRa Transceiver
 - Frequency options:
   - 433 MHz  

docs/hardware/supported/techo.mdx

@@ -5,7 +5,7 @@ sidebar_label: LILYGO® T-Echo
 sidebar_position: 2
 ---
 
-The T-Echo is the latest device to be release by LILYGO® supporting a low power consumption microcontroller.
+The T-Echo is the latest device to be release by LILYGO® supporting a low power consumption micro-controller.
 
 ### Features
 
@@ -18,7 +18,6 @@ The T-Echo is the latest device to be release by LILYGO® supporting a low power
 - Optional BME280 - Humidity and Pressure Sensor
 - Comes with a case and battery
 
-### Resources
 
 - Firmware file: `firmware-t-echo-2.x.x.uf2`
 - [Purchase link](https://www.aliexpress.com/item/1005002842456390.html)

docs/legal/index.mdx

@@ -10,7 +10,7 @@ sidebar_position: 9
 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 ;-)
-- The encryption implementation is good but see this list of [caveats](/docs/developers/firmware/encryption#summary-of-strengthsweaknesses-of-our-current-implementation) to determine risks you might face.
+- The encryption implementation is good but see this list of [caveats](/docs/mesh/encryption#summary-of-strengthsweaknesses-of-our-current-implementation) to determine risks you might face.
 
 ## Legal FAQ
 

docs/mesh/_category_.yml

@@ -0,0 +1,7 @@
+label: Mesh
+collapsible: true
+position: 5
+link:
+  type: generated-index
+  title: The Mesh
+  slug: /settings

docs/mesh/device/_category_.yml

@@ -0,0 +1,7 @@
+label: Device
+collapsible: true
+position: 1
+link:
+  type: generated-index
+  title: Device
+  slug: /device

docs/mesh/device/config/bluetooth.mdx

@@ -1,19 +1,20 @@
 ---
 id: bluetooth
 title: Bluetooth Settings
+slug: /settings/config/bluetooth
 sidebar_label: Bluetooth
 ---
 
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-The bluetooth config options are: Enabled, Pairing Mode and Fixed PIN Value.  Bluetooth config uses an admin message sending a `Config.Bluetooth` protobuf.
+The Bluetooth config options are: Enabled, Pairing Mode and Fixed PIN Value.  Bluetooth config uses an admin message sending a `Config.Bluetooth` protobuf.
 
 ## Bluetooth Config Values
 
 ### Enabled
 
-Enables bluetooth
+Enables Bluetooth
 
 ### Pairing Mode
 
@@ -49,13 +50,13 @@ Bluetooth module config is not available for Android.
 <TabItem value="apple">
 
 :::info
-All bluetooth config values are available on iOS, iPadOS and macOS at Settings > Radio Configuration > Position.
+All Bluetooth config values are available on iOS, iPadOS and macOS at Settings > Radio Configuration > Position.
 :::
 
 </TabItem>
 <TabItem value="cli">
 
-All bluetooth module config options are available in the python CLI. Example commands are below:
+All Bluetooth module config options are available in the python CLI. Example commands are below:
 
 |          Setting          |  Acceptable Values  | Default |
 | :-----------------------: | :-----------------: | :-----: |
@@ -76,7 +77,7 @@ meshtastic --set bluetooth.fixed_pin 111111
   <TabItem value="web">
 
 :::info
-All bluetooth module config options are available for the Web UI.
+All Bluetooth module config options are available for the Web UI.
 :::
 
   </TabItem>

docs/mesh/device/config/channels.mdx

@@ -1,6 +1,7 @@
 ---
 id: channels
 title: Channel Configuration
+slug: /settings/config/channels
 sidebar_label: Channels
 ---
 
@@ -37,7 +38,7 @@ _Indexing_ can not be modified.
 | 7 | 8 | `DISABLED` | User defined |
 
 :::note
-You can **not** have `DISABLED` channels inbetween active channels such as `PRIMARY` and `SECONDARY`. Active channels must be consecutive.
+You can **not** have `DISABLED` channels in-between active channels such as `PRIMARY` and `SECONDARY`. Active channels must be consecutive.
 :::
 
 ### Role
@@ -49,14 +50,14 @@ Each channel is assigned one of 3 roles:
 	- Only one primary channel can exist and can not be disabled.
 	- Direct messages are only available on this channel.
 2. `SECONDARY` or `2`
-	- Can modify the encryption key (psk).
+	- Can modify the encryption key (PSK).
 3. `DISABLED` or `0` 
 	- The channel is no longer available for use.
 	- The channel settings are set to default.
 
 ## Channel Settings Values
 
-The Channel Settings options are: ID, Name, PSK, Downlink Enabled, and Uplink Enabled. Channel settings are embeded in the `Channel` protobuf as a `ChannelSettings` protobuf and sent as an admin message.
+The Channel Settings options are: ID, Name, PSK, Downlink Enabled, and Uplink Enabled. Channel settings are embedded in the `Channel` protobuf as a `ChannelSettings` protobuf and sent as an admin message.
 
 :::note
 The full globally unique ID will be constructed from the Name and ID (`<name>.<id>`) where ID is base36 encoded. Assuming that the number of Meshtastic users is below 20K (true for a long time) the chance of this 64 bit random number colliding with anyone else is super low. The penalty for collision is low as well.

docs/mesh/device/config/device.mdx

@@ -1,6 +1,7 @@
 ---
 id: device
 title: Device Configuration
+slug: /settings/config/device
 sidebar_label: Device
 ---
 

docs/mesh/device/config/display.mdx

@@ -1,6 +1,7 @@
 ---
 id: display
 title: Display Configuration
+slug: /settings/config/display
 sidebar_label: Display
 ---
 

docs/mesh/device/config/index.mdx

@@ -0,0 +1,21 @@
+---
+id: config
+title: Configuration
+sidebar_label: Config
+slug: /settings/config
+sidebar_position: 2
+---
+
+There are several config sections in the Meshtastic firmware, these are broken out so they can be sent as small admin messages over the mesh.
+
+| Name | Description |
+|:----:|:-----------:|
+| [Bluetooth](/docs/settings/config/bluetooth) | Bluetooth config options are: Enabled, Pairing Mode and Fixed PIN. |
+| [Channels](/docs/settings/config/channels) | Channels config options are: Index, Role and Settings. |
+| [Device](/docs/settings/config/device) | Device config options are: Device Role, Serial Output, Debug Log and Factory Reset. |
+| [Display](/docs/settings/config/display)  | Display config options are: Screen On Duration, Auto Carousel Interval, Always Point North, and GPS Format. |
+| [LoRa](/docs/settings/config/lora) | The LoRa config options are: Region, Modem Preset, Max Hops, Transmit Power, Bandwidth, Spread Factor, Coding Rate, Frequency Offset, Transmit Disabled and Ignore Incoming Array. |
+| [Network](/docs/settings/config/network) | Network config options are: WiFi Enabled, WiFi SSID, WiFi PSK, WiFi Mode and NTP Server. |
+| [Position](/docs/settings/config/position) | Position config options are: GPS Enabled, GPS Update Interval, GPS Attempt Time, Fixed Position, Smart Broadcast, Broadcast Interval and Position Packet Flags.  |
+| [Power](/docs/settings/config/power) | Power config options are: Charge Current, Power Saving, Shutdown after losing power, ADC Multiplier Override Wait Bluetooth Interval, Mesh Super Deep Sleep Timeout, Super Deep Sleep Interval, Light Sleep Interval and Minimum Wake Interval. |
+| [User](/docs/settings/config/user) | The user config options are: Long Name, Short Name, and Is Licensed |

docs/mesh/device/config/lora.mdx

@@ -1,6 +1,7 @@
 ---
 id: lora
 title: LoRa Configuration
+slug: /settings/config/lora
 sidebar_label: LoRa
 ---
 
@@ -114,14 +115,14 @@ LoRa config commands are available in the python CLI. Example commands are below
 <TabItem value="flasher">
 
 :::info
-No lora config options are available in the Flasher.
+No LoRa config options are available in the Flasher.
 :::
 
   </TabItem>
   <TabItem value="web">
 
 :::info
-All lora config options are available in the Web UI.
+All LoRa config options are available in the Web UI.
 :::
 
   </TabItem>

docs/mesh/device/config/network.mdx

@@ -1,6 +1,7 @@
 ---
 id: network
 title: Network Configuration
+slug: /settings/config/network
 sidebar_label: Network
 ---
 
@@ -10,7 +11,7 @@ import TabItem from '@theme/TabItem';
 The Network config options are: WiFi Enabled, WiFi SSID, WiFi PSK, and NTP Server. Network config uses an admin message sending a `Config.Network` protobuf.
 
 :::info
-Enabling WiFi will disable bluetooth. Only one connection method will work at a time.
+Enabling WiFi will disable Bluetooth. Only one connection method will work at a time.
 :::
 
 ESP32 devices have the ability to connect to WiFi as a client. SoftAP mode is not supported by the Meshtastic firmware.

docs/mesh/device/config/position.mdx

@@ -1,6 +1,7 @@
 ---
 id: position
 title: Position Configuration
+slug: /settings/config/position
 sidebar_label: Position
 ---
 

docs/mesh/device/config/power.mdx

@@ -1,6 +1,7 @@
 ---
 id: power
 title: Power Configuration
+slug: /settings/config/power
 sidebar_label: Power
 ---
 

docs/mesh/device/config/user.mdx

@@ -1,6 +1,7 @@
 ---
 id: user
 title: User Configuration
+slug: /settings/config/user
 sidebar_label: User
 ---
 
@@ -13,7 +14,7 @@ The user config options are: Long Name, Short Name, and Is Licensed. User config
 
 ### Long Name
 
-A personalised name for your device.
+A personalized name for your device.
 
 Auto-generated by default.
 
@@ -81,7 +82,6 @@ meshtastic --set-owner-short  'NODE'
 meshtastic  --set-ham 'CALLSIGN'
 ```
 
-
 </TabItem>
 
 <TabItem value="flasher">

docs/mesh/device/device-api.mdx

@@ -1,18 +1,18 @@
 ---
 id: device-api
-title: Bluetooth/serial/TCP protocol API
-sidebar_label: Device API
+title: Device API (Serial/TCP/BLE)
+sidebar_label: Interface
 ---
 
-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 [module API](module-api) documentation instead.
+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 [module API](/docs/development/firmware/module-api) 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 designed 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
 
 This protocol is **almost** identical when it is deployed over BLE, Serial/USB, or TCP (our three currently supported transports for connecting to phone/PC). Most of this document is in terms of the original BLE version, but this section describes the small changes when this API is exposed over a Streaming (non datagram) transport. The streaming version has the following changes:
 
-- We assume the stream is reliable (though the protocol will resynchronize if bytes are lost or corrupted). i.e. we do not include CRCs or error correction codes.
+- We assume the stream is reliable (though the protocol will re-synchronize if bytes are lost or corrupted). i.e. we do not include CRCs or error correction codes.
 - Packets always have a four byte header (described below) prefixed before each packet. This header provides framing characters and length.
 - The stream going towards the radio is only a series of ToRadio packets (with the extra 4 byte headers)
 - The stream going towards the PC is a stream of FromRadio packets (with the 4 byte headers), or if the receiver state machine does not see valid header bytes it can (optionally) print those bytes as the debug console from the radio. This allows the device to emit regular serial debugging messages (which can be understood by a terminal program) but also switch to a more structured set of protobufs once it sees that the PC client has sent a protobuf towards it.
@@ -26,7 +26,8 @@ The 4 byte header is constructed to both provide framing and to not look line 'n
 
 The receiver will validate length and if >512 it will assume the packet is corrupted and return to looking for START1. While looking for START1 any other characters are printed as "debug output". For small example implementation of this reader see the python implementation.
 
-## MeshBluetoothService (the BLE API)
+
+## Bluetooth (MeshBluetoothService)
 
 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.
 

docs/mesh/device/moduleconfig/canned-message.mdx

@@ -1,6 +1,7 @@
 ---
 id: canned-message
 title: Canned Message Module Configuration
+slug: /settings/moduleconfig/canned-message
 sidebar_label: Canned Message
 ---
 
@@ -61,11 +62,11 @@ GPIO Pin Value (1-39) For encoder Press port
 
 ### Input Broker Event Clockwise
 
-Generate the rotary cloockwise event.
+Generate the rotary clockwise event.
 
 ### Input Broker Event Counter Clockwise
 
-Generate the rotary counter cloockwise event.
+Generate the rotary counter clockwise event.
 
 ### Input Broker Event Press
 

docs/mesh/device/moduleconfig/external-notification.mdx

@@ -1,6 +1,7 @@
 ---
 id: external-notification
 title: External Notification Module Configuration
+slug: /settings/moduleconfig/external-notification
 sidebar_label: External Notification
 ---
 
@@ -32,7 +33,7 @@ Specifies whether the external circuit is triggered when the device's GPIO is lo
 Specifies the GPIO that your external circuit is attached to on the device.
 
 :::info
-on ESP32 based boards, GPIOs 34 to 39 are GPIs – input only pins. These pins don’t have internal pull-up or pull-down resistors. They can’t be used as outputs, so you can NOT use these pins as outputs.
+On ESP32 based boards, GPIOs 34 to 39 are GPIs – input only pins. These pins do not have internal pull-up or pull-down resistors. They can not be used as outputs, so you can NOT use these pins as outputs.
 :::
 
 ### How long monitored GPIO is triggered
@@ -69,7 +70,7 @@ All external notification module config options are available on iOS, iPadOS and
 </TabItem>
 <TabItem value="cli">
 
-All external noftification module config options are available in the python CLI. Example commands are below:
+All external notification module config options are available in the python CLI. Example commands are below:
 
 |         Setting                |    Acceptable Values     | Default |
 | :----------------------------: | :----------------------: | :-----: |
@@ -90,7 +91,7 @@ meshtastic --set external_notification.alert_bell true
 meshtastic --set external_notification.alert_bell false
 ```
 
-```shell title="Set GPIO active high / low (defalut of false is low)"
+```shell title="Set GPIO active high / low (default of false is low)"
 meshtastic --set external_notification.active false
 meshtastic --set external_notification.active true
 ```

docs/mesh/device/moduleconfig/index.mdx

@@ -0,0 +1,18 @@
+---
+id: module-config
+title: Module Configuration
+sidebar_label: Module Config
+slug: /settings/moduleconfig
+sidebar_position: 3
+---
+
+Modules are included in the firmware and allow users to extend the functionality of their mesh or device.
+
+| Name | Description |
+|:----:|:-----------:|
+| [Canned Message](/docs/settings/moduleconfig/canned-message) | Set a number of predefined messages to send out directly from the device with the use of an input device like a rotary encoder. |
+| [External Notification](/docs/settings/moduleconfig/external-notification) | Incoming messages are able to alert you using circuits you attach to the device (LEDs, Buzzers, etc) |
+| [MQTT](/docs/settings/moduleconfig/mqtt) | Forward packets along to an MQTT server. This allows users on the local mesh to communicate with users on another mesh over the internet. |
+| [Range Test](/docs/settings/moduleconfig/range-test) | Send messages with GPS location at an interval to test the distance your devices can communicate. Requires (at least) one device set up as a sender and one as a receiver. The receiver(s) will log all incoming messages to a CSV. |
+| [Serial Module](/docs/settings/moduleconfig/serial) | Send messages across the mesh by sending strings over a serial port. |
+| [Telemetry](/docs/settings/moduleconfig/telemetry) | Attach sensors to the device and transmit readings on a regular interval to the mesh. |

docs/mesh/device/moduleconfig/mqtt.mdx

@@ -1,6 +1,7 @@
 ---
 id: mqtt
 title: MQTT Module Configuration
+slug: /settings/moduleconfig/mqtt
 sidebar_label: MQTT
 ---
 
@@ -25,15 +26,15 @@ The server to use for MQTT. If not set, the default server public will be used.
 
 ### Username
 
-MQTT Server username to use (most useful for a custom MQTT server). If using a custom server, this will be honoured even if empty. If using the default public server, this will only be honoured if set, otherwise the device will use the default username.
+MQTT Server username to use (most useful for a custom MQTT server). If using a custom server, this will be honored even if empty. If using the default public server, this will only be honored if set, otherwise the device will use the default username.
 
 ### Password
 
-MQTT password to use (most useful for a custom MQTT server). If using a custom server, this will be honoured even if empty. If using the default server, this will only be honoured if set, otherwise the device will use the default password
+MQTT password to use (most useful for a custom MQTT server). If using a custom server, this will be honored even if empty. If using the default server, this will only be honored if set, otherwise the device will use the default password
 
 ### Encryption Enabled
 
-Whether to send encrypted or decrypted packets to MQTT. This parameter is only honoured if you also set server (the default official mqtt.meshtastic.org server can handle encrypted packets) Decrypted packets may be useful for external systems that want to consume meshtastic packets.
+Whether to send encrypted or decrypted packets to MQTT. This parameter is only honored if you also set server (the default official mqtt.meshtastic.org server can handle encrypted packets) Decrypted packets may be useful for external systems that want to consume meshtastic packets.
 
 ### JSON Enabled
 

docs/mesh/device/moduleconfig/range-test.mdx

@@ -1,6 +1,7 @@
 ---
 id: range-test
 title: Range Test Module Configuration
+slug: /settings/moduleconfig/range-test
 sidebar_label: Range Test
 ---
 
@@ -107,7 +108,7 @@ Be sure to turn off either the module configured as a sender or the device where
 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.
 
 :::note
-Leaving this module on can slow down your mesh. Currently, the messages are sent using the same `TEXT_MESSAGE_APP` [port that all other messages](/docs/developers/protobufs/api#portnumsproto) are sent on.
+Leaving this module on can slow down your mesh. Currently, the messages are sent using the same `TEXT_MESSAGE_APP` [port that all other messages](/docs/development/protobuf-api#portnumsproto) are sent on.
 :::
 
 ### Accessing your CSV

docs/mesh/device/moduleconfig/serial.mdx

@@ -1,6 +1,7 @@
 ---
 id: serial
 title: Serial Module Configuration
+slug: /settings/moduleconfig/serial
 sidebar_label: Serial
 ---
 

docs/mesh/device/moduleconfig/telemetry.mdx

@@ -1,17 +1,18 @@
 ---
 id: telemetry
 title: Telemetry Module Configuration
+slug: /settings/moduleconfig/telemetry
 sidebar_label: Telemetry
 ---
 
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-The Telemetry Module provides two types of data over the mesh.  Device metrics (Battery Level, Voltage, Channel Utilization and Airtime) from your meshtastic device and Environement Metrics from attached I2C sensors.
+The Telemetry Module provides two types of data over the mesh.  Device metrics (Battery Level, Voltage, Channel Utilization and Airtime) from your meshtastic device and Environment Metrics from attached I2C sensors.
 
-Supported sensors connected to the I2C bus of the device will be automattically detected at startup. Environement Telemetry must be enabled for them to be instrumented and their readings sent over the mesh.
+Supported sensors connected to the I2C bus of the device will be automatically detected at startup. Environment Telemetry must be enabled for them to be instrumented and their readings sent over the mesh.
 
-The telemetry module config options are: Device Metrics Update Interval, Environment Metrics Update Interval, Environement Telemetry Enabled, Show on Device Screen, and Display Fahrenheit.
+The telemetry module config options are: Device Metrics Update Interval, Environment Metrics Update Interval, Environment Telemetry Enabled, Show on Device Screen, and Display Fahrenheit.
 
 ### Currently Supported Sensor Types
 
@@ -178,7 +179,7 @@ And examine the serial logs for Telemetry diagnostic information.
 
 ### Environment Metrics
 
-The environment metrics in the telemetry module supports a limited amount of fields as they are stored in memory on the device.  Support for sensors that provide one or more of the following fields can potentially be added to the main firmare provided there is a GPL licensed library for us to include to support it, and the libary size is not prohibitive.
+The environment metrics in the telemetry module supports a limited amount of fields as they are stored in memory on the device.  Support for sensors that provide one or more of the following fields can potentially be added to the main firmware provided there is a GPL licensed library for us to include to support it, and the library size is not prohibitive.
 
 * Temperature 
 * Relative Humidity

docs/mesh/encryption.mdx

@@ -1,6 +1,6 @@
 ---
 id: encryption
-title: Meshtastic encryption
+title: Meshtastic Encryption
 sidebar_label: Encryption
 ---
 

docs/mesh/mesh-alg.mdx

@@ -1,23 +1,24 @@
 ---
 id: mesh-alg
-title: Mesh broadcast algorithm
-sidebar_label: Mesh algorithm
+title: Mesh Broadcast Algorithm
+sidebar_label: Mesh Algorithm
+sidebar_position: 1
 ---
 
 ## Current Algorithm
 
-The routing protocol for Meshtastic is really quite simple (and suboptimal). If you want to test its theoretical performance, you can have a look at the [simulator](https://github.com/GUVWAF/Meshtasticator). The protocol is heavily influenced by the mesh routing algorithm used in [RadioHead](https://www.airspayce.com/mikem/arduino/RadioHead) (which was used in very early versions of this project). It has four conceptual layers.
+The routing protocol for Meshtastic is really quite simple (and sub-optimal). If you want to test its theoretical performance, you can have a look at the [simulator](https://github.com/GUVWAF/Meshtasticator). The protocol is heavily influenced by the mesh routing algorithm used in [RadioHead](https://www.airspayce.com/mikem/arduino/RadioHead) (which was used in very early versions of this project). It has four conceptual layers.
 
 ### 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/protobufs) pervasively. For purposes of this document you mostly only
-need to consider the MeshPacket and Subpacket message types.
+need to consider the MeshPacket and Sub-packet message types.
 
 ### Layer 0: LoRa Radio
 
 All data is converted into LoRa symbols which are sent to the radio for transmission. The details are described elsewhere, but it is worth noting that in addition to the converted packet bytes described below, there is also a preamble sent at the start of any data packet.
 
-This preamble allows receiving radios to synchronize clocks and start framing. We use a preable length of 32, which is longer than the minimum preamble length of 8, to maximize the amount of time the LoRa receivers can stay asleep, which dramatically lowers power consumption.
+This preamble allows receiving radios to synchronize clocks and start framing. We use a preamble length of 32, which is longer than the minimum preamble length of 8, to maximize the amount of time the LoRa receivers can stay asleep, which dramatically lowers power consumption.
 
 ### Layer 1: Unreliable Zero Hop Messaging
 
@@ -45,15 +46,15 @@ This layer is conventional non-reliable LoRa packet transmission. The transmitte
 
 - **Packet Header:** is described directly by the `PacketHeader` class in the C++ source code. But indirectly it matches the first portion of the `MeshPacket` protobuf definition. Note that the packet header is not encoded using a protobuf, but is sent as raw bytes. This both saves airtime and allows receiving radio hardware to optionally filter packets before waking the main CPU.
 
-- **Packet Header - NodeIDs:** are constructed from the bottom four bytes of the MAC address 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.
+- **Packet Header - NodeIDs:** are constructed from the bottom four bytes of the MAC address 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 de-facto guaranteed unique for each vendor. The bottom 3 bytes are guaranteed unique by that vendor.
 
 - **Packet Header - Unique ID:** The ID is a large, 32 bit ID to ensure there is enough unique state to protect an encrypted payload from attack.
 
-- **Payload:** An encrypted and packed protobuf encoding of the SubPacket protobuf. Only the SubPacket is encrypted, while headers are not. This allows the option of eventually allowing nodes to route packets without knowing anything about the encrypted payload. For more information, see the [encryption](/docs/developers/firmware/encryption) and [protobufs](/docs/developers/protobufs/api) documentation. Any data past the maximum length is truncated.
+- **Payload:** An encrypted and packed protobuf encoding of the SubPacket protobuf. Only the SubPacket is encrypted, while headers are not. This allows the option of eventually allowing nodes to route packets without knowing anything about the encrypted payload. For more information, see the [encryption](/docs/mesh/encryption) and [protobufs](/docs/development/protobuf-api) documentation. Any data past the maximum length is truncated.
 
 #### Carrier-Sense Multiple Access with Collision Avoidance (CSMA/CA)
 
-Meshtastic adopts CSMA/CA, similar as to what is used in Wi-Fi. This means that all transmitters must perform Channel Activity Detection (CAD) before attempting to transmit. If the channel is considered busy, the node will wait until it is not anymore. Since once the channel becomes idle multiple nodes might want to start transmitting, a node has to wait a random multiple of slot times. The slot time is the time needed to reliably perform CAD. The amount of slot times to wait is randomly picked from a contention window (CW), which size depends on the current channel utilization. The contention window is larger for a higher channel utilization, in order to limit the chance of collisions.
+Meshtastic adopts CSMA/CA, similar as to what is used in WiFi. This means that all transmitters must perform Channel Activity Detection (CAD) before attempting to transmit. If the channel is considered busy, the node will wait until it is not anymore. Since once the channel becomes idle multiple nodes might want to start transmitting, a node has to wait a random multiple of slot times. The slot time is the time needed to reliably perform CAD. The amount of slot times to wait is randomly picked from a contention window (CW), which size depends on the current channel utilization. The contention window is larger for a higher channel utilization, in order to limit the chance of collisions.
 
 ### Layer 2: Reliable Zero Hop Messaging
 
@@ -64,15 +65,15 @@ The default messaging provided by Layer 1 is extended by setting the `WantAck` f
 > This packet is being sent as a reliable message, we would prefer it to arrive at the destination. We would like to receive an ACK packet in response.
 >
 > 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) 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 hear anyone rebroadcast our packet, we will timeout and retransmit, using the regular resend logic.
+> packet (because naive flooding algorithm). If it hears that, the odds (given typical LoRa topology) 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 hear anyone rebroadcast our packet, we will timeout and re-transmit, using the regular resend logic.
 
-If a transmitting node does not receive an ACK (or NAK) packet after a certain expiration time, it will use Layer 1 to attempt a 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). The retransmission expiration time is based on the maximum time it would take to receive an (implicit) ACK, taking the airtime of the sent packet and any processing delay into account.
+If a transmitting node does not receive an ACK (or NAK) packet after a certain expiration time, it will use Layer 1 to attempt a re-transmission of the sent packet. A reliable packet (at this 'zero hop' level) will be resent a maximum of three times. If no ACK or NAK has been received by then the local node will internally generate a NAK (either for local consumption or use by higher layers of the protocol). The re-transmission expiration time is based on the maximum time it would take to receive an (implicit) ACK, taking the airtime of the sent packet and any processing delay into account.
 
 ### Layer 3: (Naive) Flooding for Multi-Hop Messaging
 
-Given our use-case for the initial release, most of our protocol is built around [flooding](<https://en.wikipedia.org/wiki/Flooding_(computer_networking)>). The implementation is currently 'naive' and doesn't try to optimize flooding, except by abandoning retransmission once a node has seen a nearby receiver ACK the packet it's trying to flood. This means that up to N retransmissions of a packet could occur in an N node mesh.
+Given our use-case for the initial release, most of our protocol is built around [flooding](<https://en.wikipedia.org/wiki/Flooding_(computer_networking)>). The implementation is currently 'naive' and doesn't try to optimize flooding, except by abandoning re-transmission once a node has seen a nearby receiver ACK the packet it's trying to flood. This means that up to N re-transmissions of a packet could occur in an N node mesh.
 
-If any mesh node sees a packet with a HopLimit other than zero, it will decrement that HopLimit and attempt retransmission on behalf of the original sending node. In order to promote letting nodes that are further away flood the message, such that the message eventually reaches farther, the contention window (see Layer 1) for a flooding message depends on the Signal-to-Noise Ratio (SNR) of the received packet. The CW size is small for a low SNR, such that nodes that are further away are more likely to flood first and closer nodes that hear this will refrain from flooding.
+If any mesh node sees a packet with a HopLimit other than zero, it will decrement that HopLimit and attempt re-transmission on behalf of the original sending node. In order to promote letting nodes that are further away flood the message, such that the message eventually reaches farther, the contention window (see Layer 1) for a flooding message depends on the Signal-to-Noise Ratio (SNR) of the received packet. The CW size is small for a low SNR, such that nodes that are further away are more likely to flood first and closer nodes that hear this will refrain from flooding.
 
 ### Example
 

docs/mesh/radio-settings.mdx

@@ -5,7 +5,7 @@ sidebar_label: Radio Settings
 ---
 
 We use the same channel maps as LoRaWAN (though this is not LoRaWAN).
-(Note, not the same channel map as TTN for US frequences.)
+(Note, not the same channel map as TTN for US frequencies.)
 
 ![freq table](/img/LoRa-Frequency-Bands.jpg)
 
@@ -69,7 +69,7 @@ We have six predefined channels. These are the most common settings and have bee
 | Long Range / Slow   | Long Slow        | 0.13 kbps | 12 / 4096    | 4/8         | 125       | 154dB       |
 | Very Long Range - Slow   | Very Long Slow       | 0.04 kbps | 12 / 4096    | 4/8         | 31.25       | ???dB       |
 
-Note: 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. Data-rate in this table is actual measured but doesn't count mesh overhead, hops and retransmissions.
+Note: 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. Data-rate in this table is actual measured but doesn't count mesh overhead, hops and re-transmissions.
 
 ### Custom Settings
 

docs/settings/config/index.mdx

@@ -1,20 +0,0 @@
----
-id: config
-title: Configuration Sections
-sidebar_label: Config Sections
-sidebar_position: 1
----
-
-There are several config sections in the Meshtastic firmware, these are broken out so they can be sent as small admin messages over the mesh.
-
-| Name | Description |
-|:----:|:-----------:|
-| [Bluetooth](bluetooth) | Bluetooth config options are: Enabled, Pairing Mode and Fixed PIN. |
-| [Channels](channels) | Channels config options are: Index, Role and Settings. |
-| [Device](device) | Device config options are: Device Role, Serial Output, Debug Log and Factory Reset. |
-| [Display](display)  | Display config options are: Screen On Duration, Auto Carousel Interval, Always Point North, and GPS Format. |
-| [LoRa](lora) | The LoRa config options are: Region, Modem Preset, Max Hops, Transmit Power, Bandwidth, Spread Factor, Coding Rate, Frequency Offset, Transmit Disabled and Ignore Incoming Array. |
-| [Network](network) | Network config options are: WiFi Enabled, WiFi SSID, WiFi PSK, WiFi Mode and NTP Server. |
-| [Position](position) | Position config options are: GPS Enabled, GPS Update Interval, GPS Attempt Time, Fixed Position, Smart Broadcast, Broadcast Interval and Position Packet Flags.  |
-| [Power](power) | Power config options are: Charge Current, Power Saving, Shutdown after losing power, ADC Multiplier Override Wait Bluetooth Interval, Mesh Super Deep Sleep Timeout, Super Deep Sleep Interval, Light Sleep Interval and Minimum Wake Interval. |
-| [User](user) | The user config options are: Long Name, Short Name, and Is Licensed |

docs/settings/index.mdx

@@ -1,37 +0,0 @@
----
-title: Device Settings
-sidebar_label: Device Settings
-slug: /settings
-sidebar_position: 5
----
-
-import Tabs from '@theme/Tabs';
-import TabItem from '@theme/TabItem';
-
-Configuration for Meshtastic devices has been completely overhauled in version 1.3.
-
-In order to facilitate a more stable admin channel for remote management of nodes we have broken our large monolithic config structure into six sections that can be saved individually, protecting our precious mesh bandwidth.
-
-Default settings values are prefered whenever possible as they consume no bandwidth when sent over the mesh.
-
-## [Config Sections](settings/config)
-
-Meshtastic config is broken into several sections:
-[Bluetooth](settings/config/bluetooth),
-[Device](settings/config/device),
-[Display](settings/config/display),
-[LoRa](settings/config/lora),
-[Network](settings/config/network),
-[Position](settings/config/position),
-[Power](settings/config/power) and
-[User](settings/config/user).
-
-## [Module Config](settings/moduleconfig)
-
-Meshtastic includes the following modules:
-[Canned Messages](settings/moduleconfig/canned-message),
-[External Notification](settings/moduleconfig/external-notification),
-[MQTT](settings/moduleconfig/mqtt),
-[Range Test](settings/moduleconfig/range-test),
-[Serial](settings/moduleconfig/serial), and
-[Telemetry (sensors)](settings/moduleconfig/telemetry).

docs/settings/moduleconfig/index.mdx

@@ -1,17 +0,0 @@
----
-id: module-config
-title: Module Configuration
-sidebar_label: Module Config
-sidebar_position: 2
----
-
-Modules are included in the firmware and allow users to extend the functionality of their mesh or device.
-
-| Name | Description |
-|:----:|:-----------:|
-| [Canned Message](canned-message) | Set a number of predefined messages to send out directly from the device with the use of an input device like a rotary encoder. |
-| [External Notification](external-notification) | Incoming messages are able to alert you using circuits you attach to the device (LEDs, Buzzers, etc) |
-| [MQTT](mqtt) | Forward packets along to an MQTT server. This allows users on the local mesh to communicate with users on another mesh over the internet. |
-| [Range Test](range-test) | Send messages with GPS location at an interval to test the distance your devices can communicate. Requires (at least) one device set up as a sender and one as a receiver. The receiver(s) will log all incoming messages to a CSV. |
-| [Serial Module](serial) | Send messages across the mesh by sending strings over a serial port. |
-| [Telemetry](telemetry) | Attach sensors to the device and transmit readings on a regular interval to the mesh. |

docs/software/_category_.yml

@@ -1,7 +1,6 @@
-
-position: 4 # float position is supported
 label: Software
-collapsible: true # make the category collapsible
+collapsible: true
+position: 4
 link:
   type: generated-index
   title: Software

docs/software/apple/index.mdx

@@ -7,7 +7,7 @@ sidebar_position: 2
 
 The Meshtastic Apple Apps are currently available in TestFlight as public betas with a projected App Store release November of 2022.
 
-There are lesss than 1000 remaining beta spaces available and there are no codes.
+There are less than 1000 remaining beta spaces available and there are no codes.
 
 iOS 16 is required and you can sign up by opening the following link on any iOS, iPadOS  device with TestFlight installed.
 

docs/software/device/Index.mdx

@@ -25,7 +25,7 @@ A number of devices have buttons that can be used to interact with the firmware.
   - 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).
   - 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
 
@@ -49,8 +49,8 @@ The final page shows current battery voltage and percent charge, as well as noti
 
 ![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)
+![WiFi page](/img/screen/mesh-wifi.jpg)
 
 With a further press of the program button, the screen will cycle round to the message page.

docs/software/device/critical-faults.mdx

@@ -7,7 +7,7 @@ sidebar_label: Critical error codes
 The device might report these fault codes on the screen, but it will also be outputted on the device serial output. If you encounter a fault code, please post on the forum and we'll try to help.
 
 :::note
-This table is derived from the [protobufs](/docs/developers/protobufs/api#criticalerrorcode)
+This table is derived from the [protobufs](/docs/development/protobuf-api#criticalerrorcode)
 :::
 
 | Name                | Number | Description                                                                                                             |

docs/software/device/remote-admin.mdx

@@ -139,7 +139,7 @@ Completed getting preferences
 For further reading, I recommend starting out with [Meshtastic-python](/docs/software/python/cli/) if you haven't already gone through this (hopefully you have since you are reading this). But for a full reference to the settings you can change, please see:
 
 [Settings Overview](/docs/settings) and
-[Complete list of user settings in Protobufs](/docs/developers/protobufs/api#radioconfiguserpreferences)
+[Complete list of user settings in Protobufs](/docs/development/protobuf-api#radioconfiguserpreferences)
 
 ## Areas for future development
 

docs/software/linux-native.mdx

@@ -1,7 +1,8 @@
 ---
-id: linux-native-application
-title: Linux native application
-sidebar_label: Linux native application
+id: linux-native
+title: Linux Native Application
+sidebar_label: Linux Native
+sidebar_position: 9
 ---
 
 The device software can also run on a native Linux machine thanks to the [Portduino framework](https://github.com/geeksville/framework-portduino).
@@ -15,7 +16,7 @@ For instructions on how to use it, see the [interactive simulator](https://githu
 ## Usage with a Linux machine {#usage-with-a-linux-machine}
 
 The easiest way of building the native application is using Visual Studio Code with the PlatformIO extension.
-See the instructions for creating such a building environment [here](/docs/developers/Firmware/build).
+See the instructions for creating such a building environment [here](/docs/development/firmware/build).
 
 Then after opening the firmware repository in Visual Studio Code, simply click on the PlatformIO extension in the left bar, select native and click on 'Build'.
 This will generate the binary file 'program' which you can find in `.pio/build/native/`.

docs/software/mqtt/index.mdx

@@ -7,7 +7,7 @@ sidebar_position: 4
 
 ## Bridging networks
 
-Meshtastic networks in different locations beyond the reach of LoRa can be easily bridged together using MQTT. The simplest option is to connect your mesh to the official Meshtastic MQTT broker. This makes your devices appear on the world map, and provides a copy of your mesh traffic, translated into JSON. All you have to do to join the public MQTT server is to Enable MQTT and set uplink and downlink on the channels that you want to share over MQTT. The default device configuration using the public MQTT Server is encrypted.
+Meshtastic networks in different locations beyond the reach of LoRa can be easily bridged together using MQTT. The simplest option is to connect your mesh to the official Meshtastic MQTT broker. This makes your devices appear on the world map, and provides a copy of your mesh traffic, translated into JSON. All you have to do to join the public MQTT server is to Enable MQTT and set Uplink and Downlink on the channels that you want to share over MQTT. The default device configuration using the public MQTT Server is encrypted.
 
 You can also share channel settings with a remote network. If you use the default meshtastic MQTT server, packets are always encrypted. If you use a custom MQTT broker (ie set `mqtt.address`), the `mqtt.encryption_enabled` setting applies, which by default is false. You can also specify your own private MQTT broker and specify authentication for that broker to bridge several mesh networks together, via the internet (or just a local IP network).
 
@@ -40,7 +40,7 @@ The payload is a raw protobuf. Looking at the MQTT traffic with a program like `
 	ShortFast	!937bed1c
 ```
 
-Packets from the following [port numbers](/docs/developers/Firmware/portnum) are serialized to JSON and then forwarded to the `msh/2/json/CHANNELID/DEVICEID` topic: `TEXT_MESSAGE_APP`, `ENVIRONMENTAL_MEASUREMENT_APP`, `NODEINFO_APP` and `POSITION_APP`.
+Packets from the following [port numbers](/docs/development/firmware/portnum) are serialized to JSON and then forwarded to the `msh/2/json/CHANNELID/DEVICEID` topic: `TEXT_MESSAGE_APP`, `ENVIRONMENTAL_MEASUREMENT_APP`, `NODEINFO_APP` and `POSITION_APP`.
 
 An example of a received `NODEINFO_APP` message:
 
@@ -102,7 +102,7 @@ If the channelid 'well known'/public it could be decrypted by a web service (if
 
 #### Service Envelope
 
-The payload published on mesh/... will always be wrapped in a [ServiceEnvelope protobuf](/docs/developers/protobufs/api#serviceenvelope).
+The payload published on mesh/... will always be wrapped in a [ServiceEnvelope protobuf](/docs/development/protobuf-api#serviceenvelope).
 
 ServiceEnvelope will include the message, and full information about arrival time, who forwarded it, source channel, source mesh id, etc...
 
@@ -112,7 +112,7 @@ The unique ID for a node. A hex string that starts with an ! symbol.
 
 #### USERID
 
-A user ID string. This string is either a user ID if known or a nodeid to simply deliver the message to whoever the local user is of a particular device (i.e. person who might see the screen). FIXME, see what riot.im uses and perhaps use that convention? Or use the signal +phone number convention? Or the email addr?
+A user ID string. This string is either a user ID if known or a nodeid to simply deliver the message to whoever the local user is of a particular device (i.e. person who might see the screen). FIXME, see what riot.im uses and perhaps use that convention? Or use the signal +phone number convention? Or the email address?
 
 #### CHANNELID
 
@@ -120,7 +120,7 @@ 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.
 
@@ -139,13 +139,13 @@ An existing public [MQTT broker](https://mosquitto.org) will be the default for
 
 1. install mqtt server
 
-```
+```sh
 brew install mosquitto
 ```
 
 2. start the mqtt server
 
-```
+```sh
 brew services restart mosquitto
 ```
 
@@ -153,13 +153,13 @@ brew services restart mosquitto
 
 Note: this will wait until you press control-c (publish a message, see below)
 
-```
+```sh
 mosquitto_sub -t test/hello
 ```
 
 4. In another window, publish a message to that topic:
 
-```
+```sh
 mosquitto_pub -h localhost -q 0 -t test/hello -m 'yo!'
 ```
 
@@ -173,7 +173,7 @@ allow_anonymous true
 
 6. Restart the service:
 
-```
+```sh
 brew services restart mosquitto
 ```
 
@@ -183,7 +183,7 @@ brew services restart mosquitto
 
 Here is an example publish message in python:
 
-```
+```python
 #!/usr/bin/env python3
 import paho.mqtt.client as mqtt
 from random import randrange, uniform
@@ -201,7 +201,7 @@ while True:
 
 Here is example subscribe in python:
 
-```
+```python
 #!/usr/bin/env python3
 
 import paho.mqtt.client as paho
@@ -228,8 +228,9 @@ if __name__ == '__main__':
 
 ### Using MQTT with Node-RED
 
-Below is a valid json envelope for information sent by MQTT to a device for broadcast onto the mesh.
- ```
+Below is a valid JSON envelope for information sent by MQTT to a device for broadcast onto the mesh.
+
+ ```json
  {
    "sender":"whatever you want to be the SENDER",
    "type":"sendtext",
@@ -240,17 +241,17 @@ Below is a valid json envelope for information sent by MQTT to a device for broa
 Node-RED is a free cross-platform programming tool for wiring together hardware, APIs, and online services developed originally by IBM for IOT. It is widely used for home automation by many non-professional programmers and runs well on Pi's. Node-red has many plug-in modules written by the community. I will use this platform as a practical example on how to interface with the MQTT features of Meshtastic. Everything can be done from GUI's without using command line.
 
 Step one: use http://client.meshtastic.org/ one of the Apple apps or the CLI to connect to your device and adjust these settings.
-Enable and enter network ssid/psk. Settings--> Device Config--> Network; Save.
+Enable and enter network SSID/PSK. Settings--> Device Config--> Network; Save.
 Set MQTT server address. Settings--> Module Config--> MQTT config; Verify Encryption Enabled is OFF. Turn JSON Output Enabled ON. Save.
-Go to Channel Editor and set uplink and downling enabled to True. Save.
+Go to Channel Editor and set Uplink and Downlink enabled to True. Save.
 
-Step two: if you don't want to depend on JSON decoding on the device, you can decode the proto messages off-device. To do that you will need to get the .proto files from https://github.com/meshtastic/protobufs. They function as a schema and are required for decoding in Node-RED. Save the files where the node-RED application can access them and note the file path of the "mqtt.proto" file.
+Step two: if you don't want to depend on JSON decoding on the device, you can decode the protobuf messages off-device. To do that you will need to get the .proto files from https://github.com/meshtastic/protobufs. They function as a schema and are required for decoding in Node-RED. Save the files where the node-RED application can access them and note the file path of the "mqtt.proto" file.
 
-Step three: install Node-RED plug-ins to your node-RED application for an embedded mqqt server and a protobuf decoder.
+Step three: install Node-RED plug-ins to your node-RED application for an embedded MQQT server and a protobuf decoder.
 https://flows.nodered.org/node/node-red-contrib-aedes
 https://flows.nodered.org/node/node-red-contrib-protobuf
 
-Drag, drop, and wire the nodes like this. For this example, I ran node-RED on a Windows machine. Note that file paths might be specified differently on different platforms. MQTT server wild cards are usually the same. A "+" is a single level wildcard for a specific topic level. A "#" is a multiple level wildcard that can be used at the end of a topic filter. The debug messages shown are what happens when the inject button sends a json message with a topic designed to be picked up by the specified Meshtastic device and then having it rebroadcast the message.
+Drag, drop, and wire the nodes like this. For this example, I ran node-RED on a Windows machine. Note that file paths might be specified differently on different platforms. MQTT server wild cards are usually the same. A "+" is a single level wildcard for a specific topic level. A "#" is a multiple level wildcard that can be used at the end of a topic filter. The debug messages shown are what happens when the inject button sends a JSON message with a topic designed to be picked up by the specified Meshtastic device and then having it rebroadcast the message.
 
 [<img src="/documents/mqtt/NodeRedTwo.jpg" style={{zoom:'50%'}} />](/documents/mqtt/NodeRedTwo.jpg)
 [<img src="/documents/mqtt/NodeRedThree.jpg" style={{zoom:'50%'}} />](/documents/mqtt/NodeRedThree.jpg)
@@ -260,7 +261,7 @@ The aedes broker must be set up on the same flow as the other nodes. By activati
 [<img src="/documents/mqtt/Broker1.jpg" style={{zoom:'50%'}} />](/documents/mqtt/Broker1.jpg)
 Receiving a json mqqt message is very simple.
 [<img src="/documents/mqtt/Consume.jpg" style={{zoom:'50%'}} />](/documents/mqtt/Consume.jpg)
-Injecting a json message to be sent by a device is also very simple. You do need the correct enevelope.
+Injecting a json message to be sent by a device is also very simple. You do need the correct envelope.
 [<img src="/documents/mqtt/Inject.jpg" style={{zoom:'50%'}} />](/documents/mqtt/Inject.jpg)
 Forwarding a text message from one device, through a broker, to another broker/device/channel would look like this.
 [<img src="/documents/mqtt/Forward.jpg" style={{zoom:'50%'}} />](/documents/mqtt/Forward.jpg)

docs/software/other/_category_.yml

@@ -1,8 +0,0 @@
-
-position: 9 # float position is supported
-label: Other
-collapsible: true # make the category collapsible
-link:
-  type: generated-index
-  title: Other
-  slug: /software/other

docs/software/python/cli/cli.mdx

@@ -95,7 +95,7 @@ meshtastic --get lora.region
 
 Sets a preferences field.
 
-Configuration values are described in this section: [Configuration Sections](https://meshtastic.org/docs/settings/config/)
+Configuration values are described in this section: [Configuration Sections](https://meshtastic.org/docs/mesh/device/config/)
 
 **Usage**
 

docs/software/python/cli/development.mdx

@@ -8,43 +8,41 @@ sidebar_label: Development
 
 We use the Visual Studio Code (VScode) default python formatting conventions (autopep8). So if you use that IDE you should be able to use "Format Document" and not generate unrelated diffs. If you use some other editor, please do not change formatting on lines you have not changed yourself.
 
-If you need to build a new release you will need:
 
-```
+### Building
+
+**To build a new release**
+
+```sh
 apt install pandoc
 sudo pip3 install markdown pdoc3 webencodings pyparsing twine autopep8 pylint pytest pytest-cov
 ```
 
-For development, you will probably want to run:
+**For development**
 
-```
+```sh
 pip3 install -r requirements.txt
 ```
 
-To lint, run:
+### Linting
 
-```
+```sh
 pylint meshtastic
 ```
+### Testing
 
-To test, first install this code locally, then run pytest:
+**Install and run pytest**
 
-```
+- For more verbosity, add `-v` or even `-vv` 
+
+```sh
 pip3 install .
-pytest
-```
-
-Possible options for testing:
-
-- For more verbosity, add "-v" or even "-vv" like this:
-
-```
 pytest -vv
 ```
 
 **Run just unit tests**
 
-```
+```sh
 pytest
 # or (more verbosely)
 pytest -m unit
@@ -54,34 +52,36 @@ make
 
 **Run just integration tests**
 
-```
+```sh
 pytest -m int
 ```
 
 **Run the smoke test with only one device connected serially (aka smoke1)**
 
-```
+```sh
 pytest -m smoke1
 ```
 
-CAUTION: Running smoke1 will reset values on the device, including the region to 1 (US).
+:::caution
+Running `smoke1` will reset values on the device, including the region to 1 (US).
 Be sure to hit the reset button on the device after the test is completed.
+:::
 
 **Run the smoke test with only two device connected serially (aka smoke2)**
 
-```
+```sh
 pytest -m smoke2
 ```
 
 **Run the wifi smoke test**
 
-```
+```sh
 pytest -m smokewifi
 ```
 
 **Run a specific test**
 
-```
+```sh
 pytest -msmoke1 meshtastic/tests/test_smoke1.py::test_smoke1_info
 
 # or to run a specific smoke2 test
@@ -91,13 +91,13 @@ pytest -m smoke2 meshtastic/tests/test_smoke2.py::test_smoke2_info
 pytest -m smokewifi meshtastic/tests/test_smoke_wifi.py::test_smokewifi_info
 ```
 
-**Add another classification of tests such as "unit" or "smoke1"**
+**Add another classification of tests such as `unit` or `smoke1`**
 
 See [pytest.ini](https://github.com/meshtastic/Meshtastic-python/blob/master/pytest.ini).
 
 **To see the unit test code coverage**
 
-```
+```sh
 pytest --cov=meshtastic
 # or if want html coverage report
 pytest --cov-report html --cov=meshtastic
@@ -107,17 +107,17 @@ make cov
 
 **To see slowest unit tests, you can run**
 
-```
+```sh
 pytest --durations=0
 # or
 make slow
 ```
 
-**Generate the Python API documentation** 
+### Generate the Python API documentation
 
 Pre-generated: [API documentation](https://python.meshtastic.org)
 
-```
+```sh
 bin/regen-docs.sh
 ```
 

docs/software/python/cli/uses.mdx

@@ -45,7 +45,7 @@ meshtastic --set network.wifi_ssid mywifissid --set network.wifi_psk mywifipsw -
 ```
 
 :::note
-For a full list of preferences which can be set (and their documentation) can be found in the [protobufs](/docs/developers/protobufs/api#radioconfiguserpreferences).
+For a full list of preferences which can be set (and their documentation) can be found in the [protobufs](/docs/development/protobuf-api#radioconfiguserpreferences).
 :::
 
 ### Changing channel settings

docs/software/web/index.mdx

@@ -37,13 +37,13 @@ You can accessing your device over HTTP after you set up and enabled the [Client
 
 Bluetooth support is governed by the availability of the [Web Bluetooth API](https://web.dev/bluetooth) as illustrated blow, support is primarily available in Chromium browsers
 
-![Web Bluetooth compatability matrix](https://caniuse.bitsofco.de/image/web-bluetooth.png)
+![Web Bluetooth compatibility matrix](https://caniuse.bitsofco.de/image/web-bluetooth.png)
 
 ### Serial (USB)
 
 The method with the least platform support, uses the [Web Serial API](https://web.dev/serial) allows us to connect directly to a Meshtastic node over USB, accessing it directly within your browser.
 
-![Web Serial compatability matrix](https://caniuse.bitsofco.de/image/web-serial.png)
+![Web Serial compatibility matrix](https://caniuse.bitsofco.de/image/web-serial.png)
 
 ## Updating
 

docs/software/web/partitions.mdx

@@ -53,7 +53,7 @@ Requires: [Python](https://www.python.org) and [esptool.py](https://github.com/e
 
 ### Visual Studio & PlatformIO
 
-There is also the method of using the Visual Studio IDE. This requires having Visual Studio and PlatformIO installed, along with having cloned the firmware code as per the [build instructions](/docs/developers/firmware/build). After loading the project in Visual Studio, select the PlatformIO alien icon, then find the appropriate device, and then click the Erase Flash command.
+There is also the method of using the Visual Studio IDE. This requires having Visual Studio and PlatformIO installed, along with having cloned the firmware code as per the [build instructions](/docs/development/firmware/build). After loading the project in Visual Studio, select the PlatformIO alien icon, then find the appropriate device, and then click the Erase Flash command.
 
 ![Erasing the flash using PlatformIO in Visual Studio Code](/img/platformio-erase.png)
 

docusaurus.config.js

@@ -20,9 +20,6 @@ const config = {
       content:
         '🎉 Meshtastic 2.0 Has Now Launched! Check it Out <a href="/2.0">Here</a> 🎉',
     },
-    colorMode: {
-      respectPrefersColorScheme: true,
-    },
     docs: {
       sidebar: {
         autoCollapseCategories: true,
@@ -39,32 +36,39 @@ const config = {
       items: [
         {
           label: 'Docs',
+          to: 'docs/introduction',
+        },
+        {
+          label: 'Config',
+          to: 'docs/device',
+        },
+        {
+          label: 'Downloads',
+          to: 'downloads',
+        },
+        {
+          label: 'About',
+          position: 'right',
           items: [
             {
               label: 'Getting Started',
               to: 'docs/getting-started',
             },
             {
-              label: 'Configuration',
-              to: 'docs/settings',
+              label: 'Contributing',
+              to: 'docs/contributing',
             },
             {
-              label: 'Hardware',
-              to: 'docs/hardware',
-            },
-            {
-              label: 'Software',
-              to: 'docs/software',
-            },
-            {
-              label: 'Developers',
-              to: 'docs/developers',
+              label: 'FAQs',
+              to: 'docs/faq',
             },
           ],
         },
         {
-          label: 'Downloads',
-          to: 'downloads',
+          href: 'https://github.com/meshtastic',
+          position: 'right',
+          className: 'header-github-link',
+          'aria-label': 'GitHub repository',
         },
       ],
     },
@@ -78,6 +82,9 @@ const config = {
       contextualSearch: false,
       searchPagePath: 'search',
     },
+    colorMode: {
+      respectPrefersColorScheme: true,
+    },
   },
   plugins: [
     () => {

protobuf.tmpl

@@ -1,9 +1,11 @@
 ---
-id: api
+id: protobuf-api
 title: Protobuf API Reference
-sidebar_label: API
+sidebar_label: Protobuf Reference
 ---
 
+<!-- THIS PAGE IS AUTOGENERATED FROM ./scripts/gen-proto-docs.sh DO NOT EDIT -->
+
 {{range .Files}}
 ## {{.Name}}
 {{if .Messages}}