diff --git a/docs/about/overview/encryption.mdx b/docs/about/overview/encryption.mdx index fd1f1085..d86bdb42 100644 --- a/docs/about/overview/encryption.mdx +++ b/docs/about/overview/encryption.mdx @@ -67,7 +67,7 @@ The current implementation provides optional confidentiality to members of a con - Pairing from client-to-device is by: - direct USB cable - BT pairing -- Devices are 'promiscuous' and will pair with any near-by client. Network confidentiality requires physical protextion of all nodes. +- Devices are 'promiscuous' and will pair with any near-by client. Network confidentiality requires physical protection of all nodes. ### Phase 2 - Strong device and client identity @@ -75,9 +75,9 @@ The current implementation provides optional confidentiality to members of a con - Know who sent a message (strong binding of messages to a particular node and/or terminal device) - This would be an optional feature for a message -- Optionaly enforce identity based restrictions on some actions performed at nodes and/or clients +- Optionally enforce identity based restrictions on some actions performed at nodes and/or clients - Optional support of strong pairing of a client to a device/node and restrict ability to manage and receive messages based on the pairing. - - The BT paring and the cryptographic paring are separate (to simplify pahse 1 deployment and testing) + - The BT paring and the cryptographic paring are separate (to simplify phase 1 deployment and testing) - Above features should be architected to be ‘cryptographically strong’ and algorithm agile. **Phase 2 Proposed mechanisms:** @@ -93,7 +93,7 @@ The current implementation provides optional confidentiality to members of a con Wrapped data to contain any of the existing message types. - initial ‘cipher suite’ **only** signs a message - new signed/authenticated messages to: - - device->client: provide ownership status of device (owner is identifed by a public key) + - device->client: provide ownership status of device (owner is identified by a public key) - client->device: set owner key (must be existing device owner or owner null) - any->all. Broadcast public key and associated info (crude initial key distribution) diff --git a/docs/configuration/device-config/channels.mdx b/docs/configuration/device-config/channels.mdx index 1ef1d670..dccbd1bb 100644 --- a/docs/configuration/device-config/channels.mdx +++ b/docs/configuration/device-config/channels.mdx @@ -192,7 +192,7 @@ meshtastic --ch-set psk base64:puavdd7vtYJh8NUVWgxbsoG2u9Sdqc54YvMLs+KNcMA= --ch ``` :::tip -Use this to copy and paste the `base64` encoded (single channel) key from the meshtastic --info command. Please dont use the omnibus (all channels) code here, it is not a valid key. +Use this to copy and paste the `base64` encoded (single channel) key from the meshtastic --info command. Please don't use the omnibus (all channels) code here, it is not a valid key. ::: ```shell title="Disable encryption on PRIMARY channel" diff --git a/docs/configuration/module-config/audio.mdx b/docs/configuration/module-config/audio.mdx index ffe6e6b6..9fb49009 100644 --- a/docs/configuration/module-config/audio.mdx +++ b/docs/configuration/module-config/audio.mdx @@ -53,7 +53,7 @@ The GPIO to use for the DIN signal in the I2S interface. The GPIO to use for the SCK signal in the I2S interface. :::info What is this? -These Pins comprise an I2S digital audio interface. Meshtastic uses it in monoaural mode. The software will use the logical 'LEFT' Stereo channel for the microphone and the logical 'RIGHT' Stereo channel for the speaker, so configure your breakouts accordingly. Audio is Half-Duplex, so we can re-use part of the pins for a bi-directional configuration. There's **no** default pin assigment, setting these is mandatory. +These Pins comprise an I2S digital audio interface. Meshtastic uses it in monoaural mode. The software will use the logical 'LEFT' Stereo channel for the microphone and the logical 'RIGHT' Stereo channel for the speaker, so configure your breakouts accordingly. Audio is Half-Duplex, so we can re-use part of the pins for a bi-directional configuration. There's **no** default pin assignment, setting these is mandatory. ::: ## Audio Module Config Client Availability diff --git a/docs/development/device/client-api.mdx b/docs/development/device/client-api.mdx index 0f225e57..24e1f46a 100644 --- a/docs/development/device/client-api.mdx +++ b/docs/development/device/client-api.mdx @@ -38,7 +38,7 @@ Typical flow when a phone connects to the device should be the following (if you - There are only three relevant endpoints (and they have built in BLE documentation - so use a BLE tool of your choice to watch them): FromRadio, FromNum (sends notifies when new data is available in FromRadio) and ToRadio - SetMTU size to 512 - Write a ToRadio.startConfig protobuf to the "ToRadio" endpoint - this tells the radio you are a new connection and you need the entire NodeDB sent down. -- Read repeatedly from the "FromRadio" endpoint. Each time you read you will get back a FromRadio protobuf (see Meshtatastic-protobuf). Keep reading from this endpoint until you get back and empty buffer. +- Read repeatedly from the "FromRadio" endpoint. Each time you read you will get back a FromRadio protobuf (see Meshtastic-protobuf). Keep reading from this endpoint until you get back and empty buffer. - See below for the expected sequence for your initial download. - After the initial download, you should subscribe for BLE "notify" on the "FromNum" endpoint. If a notification arrives, that means there are now one or more FromRadio packets waiting inside FromRadio. Read from FromRadio until you get back an empty packet. - Any time you want to send packets to the radio, you should write a ToRadio packet into ToRadio. diff --git a/docs/development/device/module-api.mdx b/docs/development/device/module-api.mdx index 036c7905..01832c4c 100644 --- a/docs/development/device/module-api.mdx +++ b/docs/development/device/module-api.mdx @@ -5,7 +5,7 @@ sidebar_label: Module API sidebar_position: 3 --- -The purpose of this tutorial is for writing new core modules that can be ran on a device. In most cases, it is best to start with utilizing the serial module rather than creating a new one. However, if you're interested in creating a new core functionality from scratch, then building a module would be appropriate. +The purpose of this tutorial is for writing new core modules that can be run on a device. In most cases, it is best to start with utilizing the serial module rather than creating a new one. However, if you're interested in creating a new core functionality from scratch, then building a module would be appropriate. ## Key concepts @@ -71,7 +71,7 @@ The easiest way to get started is: cp src/modules/ReplyModule.* src/modules/YourModule.* ``` 3. Change the port number from `PortNum_REPLY_APP` to `PortNum_PRIVATE_APP`. -4. Edit the `setupModules()` function located at `modules/Moduless.cpp` to add a call to create an instance of your module (see comment at head of that function). +4. Edit the `setupModules()` function located at `modules/Modules.cpp` to add a call to create an instance of your module (see comment at head of that function). 5. Rebuild with your new module and install on the device. 6. Use the [Meshtastic Python CLI tool](https://github.com/meshtastic/Meshtastic-python) to send a packet to your board, for example: - `meshtastic --dest 1234 --sendping` where _1234_ is another mesh node to send the ping to. diff --git a/docs/development/firmware/oled-guide.mdx b/docs/development/firmware/oled-guide.mdx index df26cd67..4a814d4e 100644 --- a/docs/development/firmware/oled-guide.mdx +++ b/docs/development/firmware/oled-guide.mdx @@ -10,7 +10,7 @@ sidebar_label: OLED Localization Please note that the used font file format differs from common Adafruit GFX. 2. Update the `customFontTableLookup` function in `Screen.h` 1. To map the double-byte UTF-8 code to the corresponding extended ASCII character of the desired codepage update the `customFontTableLookup` function in the `Screen.h` file. - 2. Modify the `switch (last)` statement: use left byte from UTF-8 code in the `case` label to map charachter's right byte to its extended ASCII code by specifying an offset. + 2. Modify the `switch (last)` statement: use left byte from UTF-8 code in the `case` label to map character's right byte to its extended ASCII code by specifying an offset. 3. Define language and font in `Screen.cpp` ```c diff --git a/docs/development/reference/github.mdx b/docs/development/reference/github.mdx index 06db1853..4411398f 100644 --- a/docs/development/reference/github.mdx +++ b/docs/development/reference/github.mdx @@ -49,7 +49,7 @@ A description about the project - + ### Compatibility ``` diff --git a/docs/software/python-cli/installation.mdx b/docs/software/python-cli/installation.mdx index 31968e59..ffa63540 100644 --- a/docs/software/python-cli/installation.mdx +++ b/docs/software/python-cli/installation.mdx @@ -15,7 +15,7 @@ The [Meshtastic-python repo](https://github.com/meshtastic/Meshtastic-python) an If you wish to view the code or contribute to development of the python library or the command line interface, please visit the Meshtastic python [GitHub page](https://github.com/meshtastic/Meshtastic-python). -There are standalone executables for Windows and Ubuntu if you do not want to install python and/or the python libraries required to run the mestastic CLI tool. See [Standalone](#standalone) for more information. +There are standalone executables for Windows and Ubuntu if you do not want to install python and/or the python libraries required to run the meshtastic CLI tool. See [Standalone](#standalone) for more information. Installation can also be easily done through the [Python package installer pip](https://pypi.org/project/meshtastic): :::note @@ -190,7 +190,7 @@ Wifi connection is currently under development and may not be working properly j ``` - Upgrade pip and installed meshtastic and some of its dependencies ```shell - pip install --upgrade pip pygatt pytap2 wheel mesthtastic + pip install --upgrade pip pygatt pytap2 wheel meshtastic ``` :::note