Bump to 1.2.50

Support for replies and tap backs

.devcontainer/Dockerfile

@@ -0,0 +1,11 @@
+# See here for image contents: https://github.com/microsoft/vscode-dev-containers/tree/v0.162.0/containers/ubuntu/.devcontainer/base.Dockerfile
+
+# [Choice] Ubuntu version: bionic, focal
+ARG VARIANT="focal"
+FROM mcr.microsoft.com/vscode/devcontainers/base:0-${VARIANT}
+
+# [Optional] Uncomment this section to install additional OS packages.
+RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
+     && apt-get -y install python3-distutils python3-pip
+RUN pip3 install platformio meshtastic adafruit-nrfutil
+RUN wget https://github.com/protocolbuffers/protobuf/releases/download/v3.15.8/protoc-3.15.8-linux-x86_64.zip -O /tmp/protoc.zip && cd /tmp && unzip protoc.zip && chmod a+x bin/protoc && cp bin/protoc /usr/local/bin

.devcontainer/devcontainer.json

@@ -0,0 +1,32 @@
+// For format details, see https://aka.ms/devcontainer.json. For config options, see the README at:
+// https://github.com/microsoft/vscode-dev-containers/tree/v0.162.0/containers/ubuntu
+{
+	"name": "Ubuntu",
+	"build": {
+		"dockerfile": "Dockerfile",
+		// Update 'VARIANT' to pick an Ubuntu version: focal, bionic
+		"args": { "VARIANT": "focal" }
+	},
+
+	// Set *default* container specific settings.json values on container create.
+	"settings": { 
+		"terminal.integrated.shell.linux": "/bin/bash"
+	},
+
+	// Add the IDs of extensions you want installed when the container is created.
+	"extensions": [
+        "platformio.platformio-ide",
+        "xaver.clang-format"
+		],
+
+	// Use 'forwardPorts' to make a list of ports inside the container available locally.
+	// "forwardPorts": [],
+
+	// Use 'postCreateCommand' to run commands after the container is created.
+	// "postCreateCommand": "uname -a",
+
+	// Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
+	"remoteUser": "vscode",
+
+	"postCreateCommand": "git submodule update --init"
+}

.github/actions/initbuild/action.yml

@@ -0,0 +1,39 @@
+name: 'Common init'
+
+# WARNING due to https://github.com/actions/runner/issues/646
+# this code can't work - must copy and paste into workflows for now because 'uses' is not supported
+runs:
+  using: "composite"
+  steps:
+    - name: Setup Python
+      uses: actions/setup-python@v2
+      with:
+        python-version: 3.x
+
+    - name: Cache python libs
+      uses: actions/cache@v1
+      id: cache-pip # needed in if test
+      with:
+        path: ~/.cache/pip
+        key: ${{ runner.os }}-pip
+
+    - name: Upgrade python tools
+      # We actually want to run this every time
+      # if: steps.cache-pip.outputs.cache-hit != 'true'
+      run: |
+        python -m pip install --upgrade pip
+        pip install -U platformio meshtastic adafruit-nrfutil
+
+    # Don't cache for now because I want to be lazy with portuino updates githashes
+    # - name: Cache platformio
+    #  uses: actions/cache@v1
+    #  id: cache-platformio # needed in if test
+    #  with:
+    #    path: ~/.platformio
+    #    key: ${{ runner.os }}-platformio
+
+    - name: Upgrade platformio
+      run: |
+        pio upgrade
+
+

.github/pull_request_template.md

@@ -7,7 +7,7 @@
   is appreciated." This will allow other devs to potentially save you time by not accidentially duplicating work etc...
 - Please do not check in files that don't have real changes
 - Please do not reformat lines that you didn't have to change the code on
-- We recommend using the [Visual Studio Code](https://platformio.org/install/ide?install=vscode) editor,
+- We recommend using the [Visual Studio Code](https://platformio.org/install/ide?install=vscode) editor and the 'clang-format' extension,
   because automatically follows our indentation rules and it's auto reformatting will not cause spurious changes to lines.
 - If your PR fixes a bug, mention "fixes #bugnum" somewhere in your pull request description.
 - If your other co-developers have comments on your PR please tweak as needed.

.github/workflows/main.yml

@@ -1,21 +1,106 @@
 name: Continuous Integration
 on:
-  - push
+  # Triggers the workflow on push or pull request events but only for the master branch
-  - pull_request
+  push:
+    branches: [ master ]
+  pull_request:
+    branches: [ master ]
 
 jobs:
-  main:
+  # setup:
-    name: Main
+  # runs-on: ubuntu-latest
+  # steps:
+  
+  # - name: Startup
+  #   run: echo "No action setup currently needed, skipping..."
+
+  ci-build:
+    # needs: setup
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@master
+
-      - name: Setup Python
+    - name: Checkout code
-        uses: actions/setup-python@master
+      uses: actions/checkout@v2
-        with:
+      with:
-          python-version: 3.x
+        submodules: 'recursive'
-      - name: Install Platform IO
+
-        run: |
+    - name: Setup Python
-          python -m pip install --upgrade pip
+      uses: actions/setup-python@v2
-          pip install -U platformio
+      with:
-      - name: Build
+        python-version: 3.x
-        run: platformio run
+
+    - name: Cache python libs
+      uses: actions/cache@v1
+      id: cache-pip # needed in if test
+      with:
+        path: ~/.cache/pip
+        key: ${{ runner.os }}-pip
+
+    #- name: Install linux apt packages
+    #  run: |
+    #    sudo apt-get install -y libgpiod-dev
+
+    - name: Upgrade python tools
+      # We actually want to run this every time
+      # if: steps.cache-pip.outputs.cache-hit != 'true'
+      run: |
+        python -m pip install --upgrade pip
+        pip install -U platformio meshtastic adafruit-nrfutil
+
+    # - name: Cache platformio
+    #  uses: actions/cache@v1
+    #  id: cache-platformio # needed in if test
+    #  with:
+    #    path: ~/.platformio
+    #    key: ${{ runner.os }}-platformio
+
+    - name: Upgrade platformio
+      run: |
+        pio upgrade
+
+    - name: Pull web ui
+      uses: dsaltares/fetch-gh-release-asset@master
+      with:
+        repo: "meshtastic/meshtastic-web"
+        file: "build.tar"
+        target: "build.tar"
+        token: ${{ secrets.GITHUB_TOKEN }}
+
+    - name: Unpack web ui
+      run: |
+        tar -xf build.tar -C data/static
+        rm build.tar
+
+    # We now run integration test before other build steps (to quickly see runtime failures)
+    - name: Build for native
+      run: platformio run -e native
+    - name: Integration test
+      run: |
+        .pio/build/native/program &
+        sleep 20 # 5 seconds was not enough
+        echo "Simulator started, launching python test..."
+        python3 -c 'from meshtastic.test import testSimulator; testSimulator()'
+
+    # - name: Build for tbeam
+    #   run: platformio run -e tbeam
+    # - name: Build for heltec
+    #   run: platformio run -e heltec
+    # - name: Build for wisblock RAK4631
+    #   run: platformio run -e rak4631
+
+    - name: Build everything
+      run: bin/build-all.sh
+
+    - name: Store binaries as an artifact
+      uses: actions/upload-artifact@v2
+      with:
+        name: built
+        path: release/archive/firmware-*.zip
+        retention-days: 30
+
+    - name: Store debugging elf files as an artifact
+      uses: actions/upload-artifact@v2
+      with:
+        name: debug-elfs
+        path: release/archive/elfs-*.zip
+        retention-days: 7

.github/workflows/release.yml

@@ -0,0 +1,93 @@
+name: Make Release
+on:
+  # Can optionally take parameters from the github UI, more info here https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/#:~:text=You%20can%20now%20create%20workflows,the%20workflow%20is%20run%20on.
+  # workflow_dispatch:
+  #  inputs:
+
+  # Only want to run if version.properties is bumped in master
+  push:
+    branches:
+      - master
+    paths:
+    - 'version.properties'
+
+jobs:
+  release-build:
+    runs-on: ubuntu-latest
+    steps:
+
+    - name: Checkout code
+      uses: actions/checkout@v2
+      with:
+        submodules: 'recursive'
+
+    - name: Setup Python
+      uses: actions/setup-python@v2
+      with:
+        python-version: 3.x
+        
+    # Will be available in steps.version.outputs.version	
+    - name: Get release version string
+      run: echo "::set-output name=version::$(./bin/buildinfo.py long)"
+      id: version
+    # Note: we don't use caches on release builds because we don't want to accidentally not have a virgin build machine
+
+    - name: Upgrade python tools
+      # We actually want to run this every time
+      # if: steps.cache-pip.outputs.cache-hit != 'true'
+      run: |
+        python -m pip install --upgrade pip
+        pip install -U platformio meshtastic adafruit-nrfutil
+
+    - name: Upgrade platformio
+      run: |
+        pio upgrade
+
+    - name: Pull web ui
+      uses: dsaltares/fetch-gh-release-asset@master
+      with:
+        repo: "meshtastic/meshtastic-web"
+        file: "build.tar"
+        target: "build.tar"
+        token: ${{ secrets.GITHUB_TOKEN }}
+
+    - name: Unpack web ui
+      run: |
+        tar -xf build.tar -C data/static
+        rm build.tar
+
+    - name: Build everything
+      run: bin/build-all.sh
+
+    - name: Create release
+      uses: actions/create-release@v1
+      id: create_release
+      with:
+        draft: true
+        prerelease: true
+        release_name: ${{ steps.version.outputs.version }} alpha
+        tag_name: v${{ steps.version.outputs.version }}
+        body: |
+          Autogenerated by github action, developer should edit as required before publishing...
+      env:
+        GITHUB_TOKEN: ${{ github.token }}
+
+    - name: Add bins to release
+      uses: actions/upload-release-asset@v1
+      env:
+        GITHUB_TOKEN: ${{ github.token }}
+      with:
+        upload_url: ${{ steps.create_release.outputs.upload_url }}
+        asset_path: release/archive/firmware-${{ steps.version.outputs.version }}.zip
+        asset_name: firmware-${{ steps.version.outputs.version }}.zip
+        asset_content_type: application/zip
+
+    - name: Add debug elfs to release
+      uses: actions/upload-release-asset@v1
+      env:
+        GITHUB_TOKEN: ${{ github.token }}
+      with:
+        upload_url: ${{ steps.create_release.outputs.upload_url }}
+        asset_path: release/archive/elfs-${{ steps.version.outputs.version }}.zip
+        asset_name: debug-elfs-${{ steps.version.outputs.version }}.zip
+        asset_content_type: application/zip

.gitignore

@@ -9,11 +9,17 @@ main/credentials.h
 !.vscode/extensions.json
 *.code-workspace
 
+.idea
+
 .DS_Store
 Thumbs.db
 .autotools
 .built
 .context
 .cproject
-.idea/*
 .vagrant
+nanopb*
+flash.uf2
+cmake-build*
+__pycache__
+

.gitlab-ci.yml

@@ -0,0 +1,50 @@
+image: python:latest
+
+variables:
+  # make sure GitLab check out submodules
+  GIT_SUBMODULE_STRATEGY: recursive
+
+stages:
+  - buildall
+  - upload
+
+build:
+  stage: buildall
+
+  before_script:
+    # we need zip later for packaging
+    - "apt update;apt -y install zip"
+    - "pip install -U platformio"
+
+  script:
+    # clean up residues from previous run
+    - rm -rf release
+    - bin/build-all.sh
+
+  # This is for my local environment, if your runners are tagged differently, modify or remove  
+  tags:
+    - dockerized
+
+  # The files which are to be made available in GitLab
+  artifacts:
+    paths:
+      - release/archive/firmware*.zip
+
+
+upload:
+  image: curlimages/curl:latest
+
+  stage: upload
+
+  script:
+    - |
+      PACKAGE_REGISTRY_URL="${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/${CI_PROJECT_NAME}/master"
+      cd release/archive
+      for f in *.zip; do
+      curl --header "JOB-TOKEN: ${CI_JOB_TOKEN}" --upload-file ${f} ${PACKAGE_REGISTRY_URL}/${f}
+      done
+      echo 'Package uploaded!'
+      
+  # This is for my local environment, if your runners are tagged differently, modify or remove
+  tags:
+    - dockerized  

.gitmodules

@@ -4,3 +4,6 @@
 [submodule "sdk-nrfxlib"]
 	path = sdk-nrfxlib
 	url = https://github.com/nrfconnect/sdk-nrfxlib.git
+[submodule "design"]
+	path = design
+	url = https://github.com/meshtastic/meshtastic-design.git

.vscode/extensions.json

@@ -2,6 +2,7 @@
     // See http://go.microsoft.com/fwlink/?LinkId=827846
     // for the documentation about the extensions.json format
     "recommendations": [
-        "platformio.platformio-ide"
+        "platformio.platformio-ide",
+        "xaver.clang-format"
     ]
 }

.vscode/settings.json

@@ -47,13 +47,20 @@
         "memory_resource": "cpp",
         "optional": "cpp",
         "string_view": "cpp",
-        "cassert": "cpp"
+        "cassert": "cpp",
+        "iterator": "cpp",
+        "shared_mutex": "cpp",
+        "iostream": "cpp",
+        "esp_nimble_hci.h": "c"
     },
     "cSpell.words": [
         "Blox",
+        "EINK",
         "HFSR",
         "Meshtastic",
         "NEMAGPS",
+        "NMEAGPS",
+        "RDEF",
         "Ublox",
         "bkpt",
         "cfsr",
@@ -62,5 +69,14 @@
         "protobufs",
         "wifi"
     ],
-    "C_Cpp.dimInactiveRegions": true
+    "C_Cpp.dimInactiveRegions": true,
+    "cmake.configureOnOpen": true,
+    "protoc": {
+        "compile_on_save": false,
+        "compile_all_path": "/home/kevinh/development/meshtastic/meshtastic-esp32/proto",
+        "options": [
+            "--java_out=/tmp",
+            "-I=/home/kevinh/development/meshtastic/meshtastic-esp32/proto"
+        ]
+    }
 }

CMakeLists.txt

@@ -0,0 +1,36 @@
+# !!! WARNING !!! AUTO-GENERATED FILE, PLEASE DO NOT MODIFY IT AND USE
+# https://docs.platformio.org/page/projectconf/section_env_build.html#build-flags
+#
+# If you need to override existing CMake configuration or add extra,
+# please create `CMakeListsUser.txt` in the root of project.
+# The `CMakeListsUser.txt` will not be overwritten by PlatformIO.
+
+cmake_minimum_required(VERSION 3.13)
+set(CMAKE_SYSTEM_NAME Generic)
+set(CMAKE_C_COMPILER_WORKS 1)
+set(CMAKE_CXX_COMPILER_WORKS 1)
+
+project("meshtastic-esp32" C CXX)
+
+include(CMakeListsPrivate.txt)
+
+if(EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/CMakeListsUser.txt)
+include(CMakeListsUser.txt)
+endif()
+
+include_directories("$ENV{HOME}/.platformio/packages/framework-portduino")
+include_directories("/usr/include")
+
+add_custom_target(
+    Production ALL
+    COMMAND platformio -c clion run "$<$<NOT:$<CONFIG:All>>:-e${CMAKE_BUILD_TYPE}>"
+    WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
+)
+
+add_custom_target(
+    Debug ALL
+    COMMAND platformio -c clion run --target debug "$<$<NOT:$<CONFIG:All>>:-e${CMAKE_BUILD_TYPE}>"
+    WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
+)
+
+add_executable(Z_DUMMY_TARGET ${SRC_LIST})

README.md

@@ -1,200 +1,11 @@
 # Meshtastic-device
+[![Open in Visual Studio Code](https://open.vscode.dev/badges/open-in-vscode.svg)](https://open.vscode.dev/meshtastic/Meshtastic-device)
+## This repository contains the device firmware used in the [Meshtastic](https://meshtastic.org) project.
 
-This is the device side code for the [meshtastic.org](https://www.meshtastic.org) project.
+Update Instructions
 
-![Continuous Integration](https://github.com/meshtastic/Meshtastic-esp32/workflows/Continuous%20Integration/badge.svg)
+[For ESP32 devices click here](https://meshtastic.org/docs/getting-started/flashing-esp32)
 
-Meshtastic™ is a project that lets you use
+[For nRF52 devices click here](https://meshtastic.org/docs/getting-started/flashing-nrf52)
-inexpensive GPS mesh radios as an extensible, super long battery life mesh GPS communicator. These radios are great for hiking, skiing, paragliding -
-essentially any hobby where you don't have reliable internet access. Each member of your private mesh can always see the location and distance of all other
-members and any text messages sent to your group chat.
 
-The radios automatically create a mesh to forward packets as needed, so everyone in the group can receive messages from even the furthest member. The radios
+For developer information and specific building instructions, please see the [developer doccumentation](https://meshtastic.org/docs/developers)
-will optionally work with your phone, but no phone is required.
-
-Typical time between recharging the radios should be about eight days.
-
-This project is is currently in beta-testing - if you have questions please [join our discussion forum](https://meshtastic.discourse.group/).
-
-This software is 100% open source and developed by a group of hobbyist experimenters. No warranty is provided, if you'd like to improve it - we'd love your help. Please post in the chat.
-
-## Supported hardware
-
-We currently support three models of radios.
-
-- TTGO T-Beam (usually the recommended choice)
-  - [T-Beam V1.1 w/ NEO-6M - special Meshtastic version](https://www.aliexpress.com/item/4001178678568.html) (Includes built-in OLED display and they have **preinstalled** the meshtastic software)
-  - [T-Beam V1.0 w/ NEO-M8N](https://www.aliexpress.com/item/33047631119.html) (slightly better GPS)
-  - [T-Beam V0.7 w/ NEO-6M](https://www.aliexpress.com/item/4000574335430.html) (will work but **you must use the tbeam0.7 firmware ** - but the T-Beam V1.0 or later are better!)
-  - 3D printable cases
-    - [T-Beam V0](https://www.thingiverse.com/thing:3773717)
-    - [T-Beam V1](https://www.thingiverse.com/thing:3830711)
-
-- [TTGO LORA32](https://www.aliexpress.com/item/4000211331316.html) - No GPS
-
-  - 3D printable case
-    - [TTGO LORA32 v1](https://www.thingiverse.com/thing:3385109)
-
-- [Heltec LoRa 32](https://heltec.org/project/wifi-lora-32/) - No GPS
-  - [3D Printable case](https://www.thingiverse.com/thing:3125854)
-
-**Make sure to get the frequency for your country**
-
-- US/JP/AU/NZ/CA - 915MHz
-- CN - 470MHz
-- EU - 868MHz, 433MHz
-- full list of LoRa frequencies per region is available [here](https://www.thethingsnetwork.org/docs/lorawan/frequencies-by-country.html)
-
-Getting a version that includes a screen is optional, but highly recommended.
-
-## Firmware Installation
-
-Prebuilt binaries for the supported radios are available in our [releases](https://github.com/meshtastic/Meshtastic-esp32/releases). Your initial installation has to happen over USB from your Mac, Windows or Linux PC. Once our software is installed, all future software updates happen over bluetooth from your phone.
-
-Be **very careful** to install the correct load for your board. In particular the popular 'T-BEAM' radio from TTGO is not called 'TTGO-Lora' (that is a different board). So don't install the 'TTGO-Lora' build on a TBEAM, it won't work correctly.
-
-Please post comments on our [group chat](https://meshtastic.discourse.group/) if you have problems or successes.
-
-### Installing from a GUI - Windows and Mac
-
-1. Download and unzip the latest Meshtastic firmware [release](https://github.com/meshtastic/Meshtastic-esp32/releases).
-2. Download [ESPHome Flasher](https://github.com/esphome/esphome-flasher/releases) (either x86-32bit Windows or x64-64 bit Windows).
-3. Connect your radio to your USB port and open ESPHome Flasher.
-4. If your board is not showing under Serial Port then you likely need to install the drivers for the CP210X serial chip. In Windows you can check by searching “Device Manager” and ensuring the device is shown under “Ports”.
-5. If there is an error, download the drivers [here](https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers), then unzip and run the Installer application.
-6. In ESPHome Flasher, refresh the serial ports and select your board.
-7. Browse to the previously downloaded firmware and select the correct firmware based on the board type, country and frequency.
-8. Select Flash ESP.
-9. Once complete, “Done! Flashing is complete!” will be shown.
-10. Debug messages sent from the Meshtastic device can be viewed with a terminal program such as [PuTTY](https://www.putty.org/) (Windows only). Within PuTTY, click “Serial”, enter the “Serial line” com port (can be found at step 4), enter “Speed” as 921600, then click “Open”.
-
-### Installing from a commandline
-
-These instructions currently require a few commmand lines, but it should be pretty straightforward.
-
-1. Install "pip". Pip is the python package manager we use to get the esptool installer app. Instructions [here](https://www.makeuseof.com/tag/install-pip-for-python/). If you are using OS-X, see these [special instructions](docs/software/install-OSX.md).
-2. Run "pip install --upgrade esptool" to get esptool installed on your machine.
-3. Connect your radio to your USB port.
-4. Confirm that your device is talking to your PC by running "esptool.py chip_id". The Heltec build also works on the TTGO LORA32 radio. You should see something like:
-
-```
-mydir$ esptool.py chip_id
-esptool.py v2.6
-Found 2 serial ports
-Serial port /dev/ttyUSB0
-Connecting....
-Detecting chip type... ESP32
-Chip is ESP32D0WDQ6 (revision 1)
-Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
-MAC: 24:6f:28:b5:36:71
-Uploading stub...
-Running stub...
-Stub running...
-Warning: ESP32 has no Chip ID. Reading MAC instead.
-MAC: 24:6f:28:b5:36:71
-Hard resetting via RTS pin...
-```
-
-5. cd into the directory where the release zip file was expanded.
-6. Install the correct firmware for your board with `device-install.sh firmware-_board_-_country_.bin`.
-   - Example: `./device-install.sh firmware-HELTEC-US-0.0.3.bin`.
-7. To update run `device-update.sh firmware-_board_-_country_.bin`
-   - Example: `./device-update.sh firmware-HELTEC-US-0.0.3.bin`.
-
-Note: If you have previously installed meshtastic, you don't need to run this full script instead just run `esptool.py --baud 921600 write_flash 0x10000 firmware-_board_-_country_-_version_.bin`. This will be faster, also all of your current preferences will be preserved.
-
-You should see something like this:
-
-```
-kevinh@kevin-server:~/development/meshtastic/meshtastic-esp32/release/latest$ ./device-install.sh firmware-TBEAM-US-0.1.8.bin
-Trying to flash firmware-TBEAM-US-0.1.8.bin, but first erasing and writing system information
-esptool.py v2.6
-Found 2 serial ports
-Serial port /dev/ttyUSB0
-Connecting........____
-Detecting chip type... ESP32
-Chip is ESP32D0WDQ6 (revision 1)
-Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
-MAC: 24:6f:28:b2:01:6c
-Uploading stub...
-Running stub...
-Stub running...
-Changing baud rate to 921600
-Changed.
-Erasing flash (this may take a while)...
-Chip erase completed successfully in 6.1s
-Hard resetting via RTS pin...
-esptool.py v2.6
-Found 2 serial ports
-Serial port /dev/ttyUSB0
-Connecting.......
-Detecting chip type... ESP32
-Chip is ESP32D0WDQ6 (revision 1)
-Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
-MAC: 24:6f:28:b2:01:6c
-Uploading stub...
-Running stub...
-Stub running...
-Changing baud rate to 921600
-Changed.
-Configuring flash size...
-Auto-detected Flash size: 4MB
-Flash params set to 0x0220
-Compressed 61440 bytes to 11950...
-Wrote 61440 bytes (11950 compressed) at 0x00001000 in 0.2 seconds (effective 3092.4 kbit/s)...
-Hash of data verified.
-
-Leaving...
-Hard resetting via RTS pin...
-esptool.py v2.6
-Found 2 serial ports
-Serial port /dev/ttyUSB0
-Connecting.....
-Detecting chip type... ESP32
-Chip is ESP32D0WDQ6 (revision 1)
-Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
-MAC: 24:6f:28:b2:01:6c
-Uploading stub...
-Running stub...
-Stub running...
-Changing baud rate to 921600
-Changed.
-Configuring flash size...
-Auto-detected Flash size: 4MB
-Compressed 1223568 bytes to 678412...
-Wrote 1223568 bytes (678412 compressed) at 0x00010000 in 10.7 seconds (effective 912.0 kbit/s)...
-Hash of data verified.
-
-Leaving...
-Hard resetting via RTS pin...
-```
-
-7. The board will boot and show the Meshtastic logo.
-8. Please post a comment on our chat so we know if these instructions worked for you ;-). If you find bugs/have-questions post there also - we will be rapidly iterating over the next few weeks.
-
-# Meshtastic Android app
-
-The companion (optional) Meshtastic Android app is [here](https://play.google.com/store/apps/details?id=com.geeksville.mesh&referrer=utm_source%3Dgithub-dev-readme). You can also download it on Google Play.
-
-# Python API
-
-We offer a [python API](https://github.com/meshtastic/Meshtastic-python) that makes it easy to use these devices to provide mesh networking for your custom projects.
-
-# Development
-
-We'd love to have you join us on this merry little project. Please see our [development documents](./docs/software/sw-design.md) and [join us in our discussion forum](https://meshtastic.discourse.group/).
-
-# Credits
-
-This project is run by volunteers. Past contributors include:
-
-- @astro-arphid: Added support for 433MHz radios in europe.
-- @claesg: Various documentation fixes and 3D print enclosures
-- @girtsf: Lots of improvements
-- @spattinson: Fixed interrupt handling for the AXP192 part
-
-# IMPORTANT DISCLAIMERS AND FAQ
-
-For a listing of currently missing features and a FAQ click [here](docs/faq.md).
-
-Copyright 2019 Geeksville Industries, LLC. GPL V3 Licensed.

bin/build-all.sh

@@ -2,14 +2,15 @@
 
 set -e
 
-source bin/version.sh
+VERSION=`bin/buildinfo.py long`
+SHORT_VERSION=`bin/buildinfo.py short`
 
-COUNTRIES="US EU433 EU865 CN JP"
+BOARDS_ESP32="tlora-v2 tlora-v1 tlora_v1_3 tlora-v2-1-1.6 tbeam heltec-v2.0 heltec-v2.1 tbeam0.7 meshtastic-diy-v1"
-#COUNTRIES=US
+#BOARDS_ESP32=tbeam
-#COUNTRIES=CN
 
-BOARDS="tlora-v2 tlora-v1 tlora-v2-1-1.6 tbeam heltec tbeam0.7"
+# FIXME note nrf52840dk build is for some reason only generating a BIN file but not a HEX file nrf52840dk-geeksville is fine
-#BOARDS=tbeam
+BOARDS_NRF52="rak4631_5005 rak4631_19003 t-echo"
+#BOARDS_NRF52=""
 
 OUTDIR=release/latest
 
@@ -18,25 +19,48 @@ ARCHIVEDIR=release/archive
 
 rm -f $OUTDIR/firmware*
 
-mkdir -p $OUTDIR/bins $OUTDIR/elfs
+mkdir -p $OUTDIR/bins $ARCHIVEDIR
-rm -f $OUTDIR/bins/*
+rm -r $OUTDIR/bins/* || true
+mkdir -p $OUTDIR/bins/universal $OUTDIR/elfs/universal
 
 # build the named environment and copy the bins to the release directory
-function do_build {
+function do_build() {
-    ENV_NAME=$1
+	BOARD=$1
-    echo "Building for $ENV_NAME with $PLATFORMIO_BUILD_FLAGS"
+	isNrf=$3
-    SRCBIN=.pio/build/$ENV_NAME/firmware.bin
+	
-    SRCELF=.pio/build/$ENV_NAME/firmware.elf
+    echo "Building for $BOARD with $PLATFORMIO_BUILD_FLAGS"
-    rm -f $SRCBIN 
+    rm -f .pio/build/$BOARD/firmware.*
 
     # The shell vars the build tool expects to find
-    export HW_VERSION="1.0-$COUNTRY"
     export APP_VERSION=$VERSION
-    export COUNTRY
 
-    pio run --jobs 4 --environment $ENV_NAME # -v
+    # Are we building a universal/regionless rom?
-    cp $SRCBIN $OUTDIR/bins/firmware-$ENV_NAME-$COUNTRY-$VERSION.bin
+    export HW_VERSION="1.0"
-    cp $SRCELF $OUTDIR/elfs/firmware-$ENV_NAME-$COUNTRY-$VERSION.elf
+    basename=universal/firmware-$BOARD-$VERSION
+
+    pio run --environment $BOARD # -v
+    SRCELF=.pio/build/$BOARD/firmware.elf
+    cp $SRCELF $OUTDIR/elfs/$basename.elf
+
+    if [ "$isNrf" = "false" ]
+    then
+        echo "Copying ESP32 bin file"
+        SRCBIN=.pio/build/$BOARD/firmware.bin
+        cp $SRCBIN $OUTDIR/bins/$basename.bin
+    else
+        echo "Generating NRF52 uf2 file"
+        SRCHEX=.pio/build/$BOARD/firmware.hex
+        bin/uf2conv.py $SRCHEX -c -o $OUTDIR/bins/$basename.uf2 -f 0xADA52840
+    fi
+}
+
+function do_boards() {
+	declare boards=$1
+	declare isNrf=$2
+	for board in $boards; do
+		# Build universal
+		do_build $board "" "$isNrf" 
+	done
 }
 
 # Make sure our submodules are current
@@ -45,14 +69,23 @@ git submodule update
 # Important to pull latest version of libs into all device flavors, otherwise some devices might be stale
 platformio lib update 
 
-for COUNTRY in $COUNTRIES; do 
+do_boards "$BOARDS_ESP32" "false"
-    for BOARD in $BOARDS; do
+do_boards "$BOARDS_NRF52" "true"
-        do_build $BOARD
+
-    done
+pio run --environment native
-done
+cp .pio/build/native/program $OUTDIR/bins/universal/meshtasticd_linux_amd64
+
+echo "Building SPIFFS for ESP32 targets"
+pio run --environment tbeam -t buildfs
+cp .pio/build/tbeam/spiffs.bin $OUTDIR/bins/universal/spiffs-$VERSION.bin
 
 # keep the bins in archive also
-cp $OUTDIR/bins/firmware* $OUTDIR/elfs/firmware* $ARCHIVEDIR
+cp $OUTDIR/bins/universal/spiffs* $OUTDIR/bins/universal/firmware* $OUTDIR/elfs/universal/firmware* $ARCHIVEDIR
+
+echo Updating android bins $OUTDIR/forandroid
+rm -rf $OUTDIR/forandroid
+mkdir -p $OUTDIR/forandroid
+cp -a $OUTDIR/bins/universal/*.bin $OUTDIR/forandroid/
 
 cat >$OUTDIR/curfirmwareversion.xml <<XML
 <?xml version="1.0" encoding="utf-8"?>
@@ -62,11 +95,16 @@ release.  It is used by the android app for forcing software updates.  Do not ed
 Generated by bin/buildall.sh -->
 
 <resources>
-    <string name="cur_firmware_version">$VERSION</string>
+    <string name="cur_firmware_version" translatable="false">$VERSION</string>
+    <string name="short_firmware_version" translatable="false">$SHORT_VERSION</string>
 </resources>
 XML
 
+echo Generating $ARCHIVEDIR/firmware-$VERSION.zip
 rm -f $ARCHIVEDIR/firmware-$VERSION.zip
-zip --junk-paths $ARCHIVEDIR/firmware-$VERSION.zip $OUTDIR/bins/firmware-*-$VERSION.* images/system-info.bin bin/device-install.sh bin/device-update.sh
+zip --junk-paths $ARCHIVEDIR/firmware-$VERSION.zip $ARCHIVEDIR/spiffs-$VERSION.bin $OUTDIR/bins/universal/firmware-*-$VERSION.* $OUTDIR/bins/universal/meshtasticd* images/system-info.bin bin/device-install.* bin/device-update.*
+echo Generating $ARCHIVEDIR/elfs-$VERSION.zip
+rm -f $ARCHIVEDIR/elfs-$VERSION.zip
+zip --junk-paths $ARCHIVEDIR/elfs-$VERSION.zip $OUTDIR/elfs/universal/firmware-*-$VERSION.* 
 
 echo BUILT ALL

bin/buildinfo.py

@@ -0,0 +1,9 @@
+#!/usr/bin/env python3
+import configparser
+import sys
+from readprops import readProps
+
+
+verObj = readProps('version.properties')
+propName = sys.argv[1]
+print(f"{verObj[propName]}")

bin/device-install.bat

@@ -0,0 +1,42 @@
+@ECHO OFF
+
+set PYTHON=python
+
+goto GETOPTS
+:HELP
+echo Usage: %~nx0 [-h] [-p ESPTOOL_PORT] [-P PYTHON] [-f FILENAME^|FILENAME]
+echo Flash image file to device, but first erasing and writing system information
+echo.
+echo     -h               Display this help and exit
+echo     -p ESPTOOL_PORT  Set the environment variable for ESPTOOL_PORT.  If not set, ESPTOOL iterates all ports (Dangerrous).
+echo     -P PYTHON        Specify alternate python interpreter to use to invoke esptool. (Default: %PYTHON%)
+echo     -f FILENAME      The .bin file to flash.  Custom to your device type and region.
+goto EOF
+
+:GETOPTS
+if /I "%1"=="-h" goto HELP
+if /I "%1"=="--help" goto HELP
+if /I "%1"=="-F" set "FILENAME=%2" & SHIFT
+if /I "%1"=="-p" set ESPTOOL_PORT=%2 & SHIFT
+if /I "%1"=="-P" set PYTHON=%2 & SHIFT
+SHIFT
+IF NOT "__%1__"=="____" goto GETOPTS
+
+IF "__%FILENAME%__" == "____" (
+    echo "Missing FILENAME"
+	goto HELP
+)
+IF EXIST %FILENAME% (
+    echo Trying to flash update %FILENAME%, but first erasing and writing system information"
+	%PYTHON% -m esptool --baud 921600 erase_flash
+	%PYTHON% -m esptool --baud 921600 write_flash 0x1000 system-info.bin
+    for %%f in (spiffs-*.bin) do (
+        %PYTHON% -m esptool --baud 921600 write_flash 0x00390000 %%f
+    )
+	%PYTHON% -m esptool --baud 921600 write_flash 0x10000 %FILENAME%
+) else (
+    echo "Invalid file: %FILENAME%"
+	goto HELP
+)
+
+:EOF

bin/device-install.sh

@@ -1,11 +1,58 @@
-#!/bin/bash
+#!/bin/sh
+
+PYTHON=${PYTHON:-$(which python3 python|head -n 1)}
 
 set -e
 
-FILENAME=$1
+# Usage info
+show_help() {
+cat << EOF
+Usage: $(basename $0) [-h] [-p ESPTOOL_PORT] [-P PYTHON] [-f FILENAME|FILENAME]
+Flash image file to device, but first erasing and writing system information"
 
-echo "Trying to flash $FILENAME, but first erasing and writing system information"
+    -h               Display this help and exit
-esptool.py --baud 921600 erase_flash
+    -p ESPTOOL_PORT  Set the environment variable for ESPTOOL_PORT.  If not set, ESPTOOL iterates all ports (Dangerrous).
-esptool.py --baud 921600 write_flash 0x1000 system-info.bin
+    -P PYTHON        Specify alternate python interpreter to use to invoke esptool. (Default: "$PYTHON")
-esptool.py --baud 921600 write_flash 0x10000 $FILENAME
+    -f FILENAME      The .bin file to flash.  Custom to your device type and region.
+EOF
+}
 
+
+while getopts ":hp:P:f:" opt; do
+    case "${opt}" in
+        h)
+            show_help
+            exit 0
+            ;;
+        p)  export ESPTOOL_PORT=${OPTARG}
+	    ;;
+        P)  PYTHON=${OPTARG}
+            ;;
+        f)  FILENAME=${OPTARG}
+            ;;
+        *)
+ 	    echo "Invalid flag."
+            show_help >&2
+            exit 1
+            ;;
+    esac
+done
+shift "$((OPTIND-1))"
+
+[ -z "$FILENAME" -a -n "$1" ] && {
+    FILENAME=$1
+    shift
+}
+
+if [ -f "${FILENAME}" ]; then
+	echo "Trying to flash ${FILENAME}, but first erasing and writing system information"
+	$PYTHON -m esptool  erase_flash
+	$PYTHON -m esptool  write_flash 0x1000 system-info.bin
+	$PYTHON -m esptool  write_flash 0x00390000 spiffs-*.bin
+	$PYTHON -m esptool  write_flash 0x10000 ${FILENAME}
+else
+	echo "Invalid file: ${FILENAME}"
+	show_help
+fi
+
+exit 0

bin/device-update.bat

@@ -0,0 +1,39 @@
+@ECHO OFF
+
+set PYTHON=python
+
+goto GETOPTS
+:HELP
+echo Usage: %~nx0 [-h] [-p ESPTOOL_PORT] [-P PYTHON] [-f FILENAME^|FILENAME]
+echo Flash image file to device, leave existing system intact.
+echo.
+echo     -h               Display this help and exit
+echo     -p ESPTOOL_PORT  Set the environment variable for ESPTOOL_PORT.  If not set, ESPTOOL iterates all ports (Dangerrous).
+echo     -P PYTHON        Specify alternate python interpreter to use to invoke esptool. (Default: %PYTHON%)
+echo     -f FILENAME      The .bin file to flash.  Custom to your device type and region.
+goto EOF
+
+:GETOPTS
+if /I "%1"=="-h" goto HELP
+if /I "%1"=="--help" goto HELP
+if /I "%1"=="-F" set "FILENAME=%2" & SHIFT
+if /I "%1"=="-p" set ESPTOOL_PORT=%2 & SHIFT
+if /I "%1"=="-P" set PYTHON=%2 & SHIFT
+SHIFT
+IF NOT "__%1__"=="____" goto GETOPTS
+
+IF "__%FILENAME%__" == "____" (
+    echo "Missing FILENAME"
+	goto HELP
+)
+IF EXIST %FILENAME% (
+    echo Trying to flash update %FILENAME%
+    %PYTHON% -m esptool --baud 921600 write_flash 0x10000 %FILENAME%
+    echo Erasing the otadata partition, which will turn off flash flippy-flop and force the first image to be used
+    %PYTHON% -m esptool --baud 921600 erase_region 0xe000 0x2000
+) else (
+    echo "Invalid file: %FILENAME%"
+	goto HELP
+)
+
+:EOF

bin/device-update.sh

@@ -1,8 +1,55 @@
-#!/bin/bash
+#!/bin/sh
 
-set -e
+PYTHON=${PYTHON:-$(which python3 python|head -n 1)}
 
-FILENAME=$1
+# Usage info
+show_help() {
+cat << EOF
+Usage: $(basename $0) [-h] [-p ESPTOOL_PORT] [-P PYTHON] [-f FILENAME|FILENAME]
+Flash image file to device, leave existing system intact."
 
-echo "Trying to update $FILENAME"
+    -h               Display this help and exit
-esptool.py --baud 921600 write_flash 0x10000 $FILENAME
+    -p ESPTOOL_PORT  Set the environment variable for ESPTOOL_PORT.  If not set, ESPTOOL iterates all ports (Dangerrous).
+    -P PYTHON        Specify alternate python interpreter to use to invoke esptool. (Default: "$PYTHON")
+    -f FILENAME      The .bin file to flash.  Custom to your device type and region.
+EOF
+}
+
+
+while getopts ":hp:P:f:" opt; do
+    case "${opt}" in
+        h)
+            show_help
+            exit 0
+            ;;
+        p)  export ESPTOOL_PORT=${OPTARG}
+	    ;;
+        P)  PYTHON=${OPTARG}
+            ;;
+        f)  FILENAME=${OPTARG}
+            ;;
+        *)
+ 	    echo "Invalid flag."
+            show_help >&2
+            exit 1
+            ;;
+    esac
+done
+shift "$((OPTIND-1))"
+
+[ -z "$FILENAME" -a -n "$1" ] && {
+    FILENAME=$1
+    shift
+}
+
+if [ -f "${FILENAME}" ]; then
+	echo "Trying to flash update ${FILENAME}."
+	$PYTHON -m esptool --baud 921600 write_flash 0x10000 ${FILENAME}
+	echo "Erasing the otadata partition, which will turn off flash flippy-flop and force the first image to be used"
+	$PYTHON -m esptool --baud 921600 erase_region 0xe000 0x2000
+else
+	echo "Invalid file: ${FILENAME}"
+	show_help
+fi
+
+exit 0

bin/exception_decoder.py

@@ -241,7 +241,7 @@ def print_addr(name, value, resolver):
 def print_stack_full(lines, resolver):
     print("stack:")
     for line in lines:
-        print(line.offset + ":")
+        print(str(line.offset) + ":")
         for content in line.content:
             print("  " + resolver.resolve_stack_addr(content))
 

bin/gen-images.sh

@@ -0,0 +1,19 @@
+
+
+set -e 
+
+# regen the design bins first
+cd design
+bin/generate-pngs.sh
+cd ..
+
+# assumes 50 wide, 28 high
+convert design/logo/png/Mesh_Logo_Black_Small.png -background white -alpha Background src/graphics/img/icon.xbm
+
+inkscape --batch-process -o images/compass.png -w 48 -h 48 images/location_searching-24px.svg
+convert compass.png -background white -alpha Background src/graphics/img/compass.xbm
+
+inkscape --batch-process -o images/face.png -w 13 -h 13 images/face-24px.svg
+
+inkscape --batch-process -o images/pin.png -w 13 -h 13 images/room-24px.svg
+convert pin.png -background white -alpha Background src/graphics/img/pin.xbm

bin/install-bootloader.sh

@@ -0,0 +1,35 @@
+# You probably don't want to use this script, it programs a custom bootloader build onto a nrf52 board
+
+set -e 
+
+# dependencies
+# apt install srecord
+
+BOOTDIR=/home/kevinh/development/meshtastic/Adafruit_nRF52_Bootloader
+BOARD=othernet_ppr1
+BOOTVER=0.3.2
+BOOTNUM=128
+BOOTSHA=gc01b9ea
+SDCODE=s113
+SDVER=7.2.0
+PROJ=ppr1
+
+# FIXME for nRF52840 use 0xff000, for nRF52833 use 0x7f000
+BOOTSET=0x7f000
+
+nrfjprog --eraseall -f nrf52
+
+# this generates an intel hex file that can be programmed into a NRF52 to tell the adafruit bootloader that the current app image is valid
+# Bootloader settings are at BOOTLOADER_SETTINGS (rw) : ORIGIN = 0xFF000, LENGTH = 0x1000
+# first 4 bytes should be 0x01 to indicate valid app image
+# second 4 bytes should be 0x00 to indicate no CRC required for image
+echo "01 00 00 00 00 00 00 00" | xxd -r -p - >/tmp/bootconf.bin
+srec_cat /tmp/bootconf.bin -binary -offset $BOOTSET -output /tmp/bootconf.hex -intel   
+
+echo Generating merged hex file from .pio/build/$PROJ/firmware.hex
+mergehex -o ${BOARD}_full.hex -m $BOOTDIR/_build/build-$BOARD/${BOARD}_bootloader-$BOOTVER-$BOOTNUM-$BOOTSHA-dirty_${SDCODE}_$SDVER.hex .pio/build/$PROJ/firmware.hex /tmp/bootconf.hex
+
+echo Telling bootloader app region is valid and telling CPU to run
+nrfjprog --program ${BOARD}_full.hex -f nrf52 --reset
+
+# nrfjprog --readuicr /tmp/uicr.hex; objdump -s /tmp/uicr.hex | less

bin/install-eink.sh

@@ -0,0 +1,24 @@
+# You probably don't want to use this script, it programs a custom bootloader build onto a nrf52 board
+
+set -e 
+
+BOOTDIR=/home/kevinh/development/meshtastic/Adafruit_nRF52_Bootloader
+
+nrfjprog --eraseall -f nrf52
+
+# to get tool run "sudo apt-get install srecord"
+
+# this generates an intel hex file that can be programmed into a NRF52 to tell the adafruit bootloader that the current app image is valid
+# Bootloader settings are at BOOTLOADER_SETTINGS (rw) : ORIGIN = 0xFF000, LENGTH = 0x1000
+# first 4 bytes should be 0x01 to indicate valid app image
+# second 4 bytes should be 0x00 to indicate no CRC required for image
+echo "01 00 00 00 00 00 00 00" | xxd -r -p - >/tmp/bootconf.bin
+srec_cat /tmp/bootconf.bin -binary -offset 0xff000 -output /tmp/bootconf.hex -intel   
+
+echo Generating merged hex file 
+mergehex -m $BOOTDIR/_build/build-ttgo_eink/ttgo_eink_bootloader-0.3.2-213-gf67f592-dirty_s140_6.1.1.hex .pio/build/eink/firmware.hex /tmp/bootconf.hex -o ttgo_eink_full.hex
+
+echo Telling bootloader app region is valid and telling CPU to run
+nrfjprog --program ttgo_eink_full.hex -f nrf52 --reset
+
+# nrfjprog --readuicr /tmp/uicr.hex; objdump -s /tmp/uicr.hex | less

bin/mqtt-listen.sh

@@ -0,0 +1,3 @@
+
+mosquitto_sub -h mqtt.meshtastic.org -v -t \$SYS/\# -t msh/+/stat/\# -t msh/+/json/\#
+# mosquitto_sub -h test.mosquitto.org -v -t mesh/\# -F "%j"

bin/mqtt-send-status.sh

@@ -0,0 +1 @@
+mosquitto_pub -h mqtt.meshtastic.org -u meshdev -P large4cats -t msh/1/stat/FakeNode -m online -d

bin/native-gdbserver.sh

@@ -0,0 +1,3 @@
+set -e
+pio run --environment native
+gdbserver --once localhost:2345 .pio/build/native/program "$@"

bin/native-run.sh

@@ -0,0 +1,3 @@
+set -e
+pio run --environment native
+.pio/build/native/program "$@"

bin/nrf52832-gdbserver.sh

@@ -1,3 +1,3 @@
 
 
-JLinkGDBServerCLExe -if SWD -select USB -port 2331 -device NRF52840_XXAA
+JLinkGDBServerCLExe -if SWD -select USB -port 2331 -device NRF52832_XXAA

bin/nrf52833-gdbserver.sh

@@ -0,0 +1,3 @@
+
+
+JLinkGDBServerCLExe -if SWD -select USB -port 2331 -device NRF52833_XXAA

bin/nrf52840-gdbserver.sh

@@ -1,3 +1,3 @@
 
 
-JLinkGDBServerCLExe -if SWD -select USB -port 2331 -device NRF52832_XXAA
+JLinkGDBServerCLExe -if SWD -select USB -port 2331 -device NRF52840_XXAA -SuppressInfoUpdateFW -DisableAutoUpdateFW -rtos GDBServer/RTOSPlugin_FreeRTOS

bin/platformio-custom.py

@@ -0,0 +1,20 @@
+
+
+import subprocess
+import configparser
+import traceback
+import sys
+from readprops import readProps
+
+Import("projenv")
+
+prefsLoc = projenv["PROJECT_DIR"] + "/version.properties"
+verObj = readProps(prefsLoc)
+print("Using meshtastic platform-custom.py, firmare version " + verObj['long'])
+# print("path is" + ','.join(sys.path))
+
+# General options that are passed to the C and C++ compilers
+projenv.Append(CCFLAGS=[
+    "-DAPP_VERSION=" + verObj['long'],
+    "-DAPP_VERSION_SHORT=" + verObj['short']    
+])

bin/program-1.0-tbeam.sh

@@ -0,0 +1,3 @@
+esptool.py --baud 921600 write_flash 0x10000 release/archive/old/firmware-tbeam-EU865-1.0.0.bin
+echo "Erasing the otadata partition, which will turn off flash flippy-flop and force the first image to be used"
+esptool.py --baud 921600 erase_region 0xe000 0x2000

bin/program-1.1-tbeam.sh

@@ -0,0 +1 @@
+esptool.py --baud 921600 write_flash 0x10000 release/archive/old/firmware-tbeam-1.1.50.bin

bin/program-release-tbeam.sh

@@ -1,6 +1,8 @@
 
 set -e
 
-source bin/version.sh
+VERSION=`bin/buildinfo.py`
+FILENAME=release/latest/bins/universal/firmware-tbeam-$VERSION.bin
 
-esptool.py --baud 921600 write_flash 0x10000 release/latest/bins/firmware-tbeam-US-$VERSION.bin
+echo Installing $FILENAME
+esptool.py --baud 921600 write_flash 0x10000 $FILENAME

bin/program-release-universal.sh

@@ -0,0 +1,6 @@
+
+set -e
+
+source bin/version.sh
+
+esptool.py --baud 921600 write_flash 0x10000 release/latest/bins/universal/firmware-tbeam-$VERSION.bin

bin/promote-release.sh

@@ -0,0 +1,15 @@
+set -e 
+
+echo "This script is only for developers who are publishing new builds on github.  Most users don't need it"
+
+VERSION=`bin/buildinfo.py long`
+
+# Must have a V prefix to trigger github
+git tag "v${VERSION}"
+
+# Commented out per https://github.com/meshtastic/Meshtastic-device/issues/947
+#git push root "v${VERSION}" # push the tag
+
+git push origin "v${VERSION}" # push the tag
+
+echo "Tag ${VERSION} pushed to github, github actions should now be building the draft release.  If it seems good, click to publish it"

bin/qspi-flash-test.sh

@@ -0,0 +1,6 @@
+# You probably don't need this - it is a basic test of the serial flash on the TTGO eink board
+
+nrfjprog --qspiini nrf52/ttgo_eink_qpsi.ini --qspieraseall
+nrfjprog --qspiini nrf52/ttgo_eink_qpsi.ini --memwr 0x12000000 --val 0xdeadbeef --verify
+nrfjprog --qspiini nrf52/ttgo_eink_qpsi.ini --readqspi spi.hex
+objdump -s spi.hex | less

bin/readprops.py

@@ -0,0 +1,37 @@
+
+
+import subprocess
+import configparser
+import traceback
+import sys
+
+
+def readProps(prefsLoc):
+    """Read the version of our project as a string"""
+
+    config = configparser.RawConfigParser()
+    config.read(prefsLoc)
+    version = dict(config.items('VERSION'))
+    verObj = dict(short = "{}.{}.{}".format(version["major"], version["minor"], version["build"]),
+        long = "unset")
+
+    # Try to find current build SHA if if the workspace is clean.  This could fail if git is not installed
+    try:
+        sha = subprocess.check_output(
+            ['git', 'rev-parse', '--short', 'HEAD']).decode("utf-8").strip()
+        isDirty = subprocess.check_output(
+            ['git', 'diff', 'HEAD']).decode("utf-8").strip()
+        suffix = sha
+        if isDirty:
+            # short for 'dirty', we want to keep our verstrings source for protobuf reasons
+            suffix = sha + "-d"
+        verObj['long'] = "{}.{}.{}.{}".format(
+            version["major"], version["minor"], version["build"], suffix)
+    except:
+        # print("Unexpected error:", sys.exc_info()[0])
+        # traceback.print_exc()
+        verObj['long'] = verObj['short']
+
+    # print("firmare version " + verStr)
+    return verObj
+# print("path is" + ','.join(sys.path))

bin/regen-protos.bat

@@ -0,0 +1 @@
+cd proto && ..\nanopb-0.4.4\generator-bin\protoc.exe --nanopb_out=-v:..\src\mesh\generated -I=..\proto *.proto

bin/regen-protos.sh

@@ -1,6 +1,15 @@
 #!/bin/bash
 
-echo "This script requires https://jpa.kapsi.fi/nanopb/download/ version 0.4.1"
+set -e
+
+echo "This script requires https://jpa.kapsi.fi/nanopb/download/ version 0.4.4 to be located in the"
+echo "meshtastic-device root directory if the following step fails, you should download the correct"
+echo "prebuilt binaries for your computer into nanopb-0.4.4"
+
 # the nanopb tool seems to require that the .options file be in the current directory!
 cd proto
-../../nanopb-0.4.1-linux-x86/generator-bin/protoc --nanopb_out=-v:../src/mesh -I=../proto mesh.proto
+../nanopb-0.4.4/generator-bin/protoc --nanopb_out=-v:../src/mesh/generated -I=../proto *.proto
+
+#echo "Regenerating protobuf documentation - if you see an error message"
+#echo "you can ignore it unless doing a new protobuf release to github."
+#bin/regen-docs.sh

bin/run-both.sh

@@ -0,0 +1,13 @@
+set -e 
+
+TARG=tbeam
+
+pio run -e $TARG
+
+echo uploading to usb1
+pio run --upload-port /dev/ttyUSB1 -t upload -e $TARG &
+
+echo uploading to usb0
+pio run --upload-port /dev/ttyUSB0 -t upload -e $TARG &
+
+wait

bin/test-simulator.sh

@@ -0,0 +1,9 @@
+set -e
+
+echo "Starting simulator"
+.pio/build/native/program &
+sleep 20 # 5 seconds was not enough
+
+echo "Simulator started, launching python test..."
+python3 -c 'from meshtastic.test import testSimulator; testSimulator()'
+

bin/uf2-convert.bat

@@ -0,0 +1,2 @@
+@echo off
+if [%1]==[] (echo "Please specify a platformio NRF target (i.e. rak4631) as the first argument.") else (python3 .\bin\uf2conv.py .\.pio\build\%1\firmware.hex -c -o .\.pio\build\%1\firmware.uf2 -f 0xADA52840)

bin/uf2conv.py

@@ -0,0 +1,314 @@
+#!/usr/bin/env python3
+import sys
+import struct
+import subprocess
+import re
+import os
+import os.path
+import argparse
+
+
+UF2_MAGIC_START0 = 0x0A324655 # "UF2\n"
+UF2_MAGIC_START1 = 0x9E5D5157 # Randomly selected
+UF2_MAGIC_END    = 0x0AB16F30 # Ditto
+
+families = {
+    'SAMD21': 0x68ed2b88,
+    'SAML21': 0x1851780a,
+    'SAMD51': 0x55114460,
+    'NRF52': 0x1b57745f,
+    'STM32F0': 0x647824b6,
+    'STM32F1': 0x5ee21072,
+    'STM32F2': 0x5d1a0a2e,
+    'STM32F3': 0x6b846188,
+    'STM32F4': 0x57755a57,
+    'STM32F7': 0x53b80f00,
+    'STM32G0': 0x300f5633,
+    'STM32G4': 0x4c71240a,
+    'STM32H7': 0x6db66082,
+    'STM32L0': 0x202e3a91,
+    'STM32L1': 0x1e1f432d,
+    'STM32L4': 0x00ff6919,
+    'STM32L5': 0x04240bdf,
+    'STM32WB': 0x70d16653,
+    'STM32WL': 0x21460ff0,
+    'ATMEGA32': 0x16573617,
+    'MIMXRT10XX': 0x4FB2D5BD
+}
+
+INFO_FILE = "/INFO_UF2.TXT"
+
+appstartaddr = 0x2000
+familyid = 0x0
+
+
+def is_uf2(buf):
+    w = struct.unpack("<II", buf[0:8])
+    return w[0] == UF2_MAGIC_START0 and w[1] == UF2_MAGIC_START1
+
+def is_hex(buf):
+    try:
+        w = buf[0:30].decode("utf-8")
+    except UnicodeDecodeError:
+        return False
+    if w[0] == ':' and re.match(b"^[:0-9a-fA-F\r\n]+$", buf):
+        return True
+    return False
+
+def convert_from_uf2(buf):
+    global appstartaddr
+    numblocks = len(buf) // 512
+    curraddr = None
+    outp = b""
+    for blockno in range(numblocks):
+        ptr = blockno * 512
+        block = buf[ptr:ptr + 512]
+        hd = struct.unpack(b"<IIIIIIII", block[0:32])
+        if hd[0] != UF2_MAGIC_START0 or hd[1] != UF2_MAGIC_START1:
+            print("Skipping block at " + ptr + "; bad magic")
+            continue
+        if hd[2] & 1:
+            # NO-flash flag set; skip block
+            continue
+        datalen = hd[4]
+        if datalen > 476:
+            assert False, "Invalid UF2 data size at " + ptr
+        newaddr = hd[3]
+        if curraddr == None:
+            appstartaddr = newaddr
+            curraddr = newaddr
+        padding = newaddr - curraddr
+        if padding < 0:
+            assert False, "Block out of order at " + ptr
+        if padding > 10*1024*1024:
+            assert False, "More than 10M of padding needed at " + ptr
+        if padding % 4 != 0:
+            assert False, "Non-word padding size at " + ptr
+        while padding > 0:
+            padding -= 4
+            outp += b"\x00\x00\x00\x00"
+        outp += block[32 : 32 + datalen]
+        curraddr = newaddr + datalen
+    return outp
+
+def convert_to_carray(file_content):
+    outp = "const unsigned char bindata[] __attribute__((aligned(16))) = {"
+    for i in range(len(file_content)):
+        if i % 16 == 0:
+            outp += "\n"
+        outp += "0x%02x, " % ord(file_content[i])
+    outp += "\n};\n"
+    return outp
+
+def convert_to_uf2(file_content):
+    global familyid
+    datapadding = b""
+    while len(datapadding) < 512 - 256 - 32 - 4:
+        datapadding += b"\x00\x00\x00\x00"
+    numblocks = (len(file_content) + 255) // 256
+    outp = b""
+    for blockno in range(numblocks):
+        ptr = 256 * blockno
+        chunk = file_content[ptr:ptr + 256]
+        flags = 0x0
+        if familyid:
+            flags |= 0x2000
+        hd = struct.pack(b"<IIIIIIII",
+            UF2_MAGIC_START0, UF2_MAGIC_START1,
+            flags, ptr + appstartaddr, 256, blockno, numblocks, familyid)
+        while len(chunk) < 256:
+            chunk += b"\x00"
+        block = hd + chunk + datapadding + struct.pack(b"<I", UF2_MAGIC_END)
+        assert len(block) == 512
+        outp += block
+    return outp
+
+class Block:
+    def __init__(self, addr):
+        self.addr = addr
+        self.bytes = bytearray(256)
+
+    def encode(self, blockno, numblocks):
+        global familyid
+        flags = 0x0
+        if familyid:
+            flags |= 0x2000
+        hd = struct.pack("<IIIIIIII",
+            UF2_MAGIC_START0, UF2_MAGIC_START1,
+            flags, self.addr, 256, blockno, numblocks, familyid)
+        hd += self.bytes[0:256]
+        while len(hd) < 512 - 4:
+            hd += b"\x00"
+        hd += struct.pack("<I", UF2_MAGIC_END)
+        return hd
+
+def convert_from_hex_to_uf2(buf):
+    global appstartaddr
+    appstartaddr = None
+    upper = 0
+    currblock = None
+    blocks = []
+    for line in buf.split('\n'):
+        if line[0] != ":":
+            continue
+        i = 1
+        rec = []
+        while i < len(line) - 1:
+            rec.append(int(line[i:i+2], 16))
+            i += 2
+        tp = rec[3]
+        if tp == 4:
+            upper = ((rec[4] << 8) | rec[5]) << 16
+        elif tp == 2:
+            upper = ((rec[4] << 8) | rec[5]) << 4
+            assert (upper & 0xffff) == 0
+        elif tp == 1:
+            break
+        elif tp == 0:
+            addr = upper | (rec[1] << 8) | rec[2]
+            if appstartaddr == None:
+                appstartaddr = addr
+            i = 4
+            while i < len(rec) - 1:
+                if not currblock or currblock.addr & ~0xff != addr & ~0xff:
+                    currblock = Block(addr & ~0xff)
+                    blocks.append(currblock)
+                currblock.bytes[addr & 0xff] = rec[i]
+                addr += 1
+                i += 1
+    numblocks = len(blocks)
+    resfile = b""
+    for i in range(0, numblocks):
+        resfile += blocks[i].encode(i, numblocks)
+    return resfile
+
+def to_str(b):
+    return b.decode("utf-8")
+
+def get_drives():
+    drives = []
+    if sys.platform == "win32":
+        r = subprocess.check_output(["wmic", "PATH", "Win32_LogicalDisk",
+                                     "get", "DeviceID,", "VolumeName,",
+                                     "FileSystem,", "DriveType"])
+        for line in to_str(r).split('\n'):
+            words = re.split('\s+', line)
+            if len(words) >= 3 and words[1] == "2" and words[2] == "FAT":
+                drives.append(words[0])
+    else:
+        rootpath = "/media"
+        if sys.platform == "darwin":
+            rootpath = "/Volumes"
+        elif sys.platform == "linux":
+            tmp = rootpath + "/" + os.environ["USER"]
+            if os.path.isdir(tmp):
+                rootpath = tmp
+        for d in os.listdir(rootpath):
+            drives.append(os.path.join(rootpath, d))
+
+
+    def has_info(d):
+        try:
+            return os.path.isfile(d + INFO_FILE)
+        except:
+            return False
+
+    return list(filter(has_info, drives))
+
+
+def board_id(path):
+    with open(path + INFO_FILE, mode='r') as file:
+        file_content = file.read()
+    return re.search("Board-ID: ([^\r\n]*)", file_content).group(1)
+
+
+def list_drives():
+    for d in get_drives():
+        print(d, board_id(d))
+
+
+def write_file(name, buf):
+    with open(name, "wb") as f:
+        f.write(buf)
+    print("Wrote %d bytes to %s" % (len(buf), name))
+
+
+def main():
+    global appstartaddr, familyid
+    def error(msg):
+        print(msg)
+        sys.exit(1)
+    parser = argparse.ArgumentParser(description='Convert to UF2 or flash directly.')
+    parser.add_argument('input', metavar='INPUT', type=str, nargs='?',
+                        help='input file (HEX, BIN or UF2)')
+    parser.add_argument('-b' , '--base', dest='base', type=str,
+                        default="0x2000",
+                        help='set base address of application for BIN format (default: 0x2000)')
+    parser.add_argument('-o' , '--output', metavar="FILE", dest='output', type=str,
+                        help='write output to named file; defaults to "flash.uf2" or "flash.bin" where sensible')
+    parser.add_argument('-d' , '--device', dest="device_path",
+                        help='select a device path to flash')
+    parser.add_argument('-l' , '--list', action='store_true',
+                        help='list connected devices')
+    parser.add_argument('-c' , '--convert', action='store_true',
+                        help='do not flash, just convert')
+    parser.add_argument('-D' , '--deploy', action='store_true',
+                        help='just flash, do not convert')
+    parser.add_argument('-f' , '--family', dest='family', type=str,
+                        default="0x0",
+                        help='specify familyID - number or name (default: 0x0)')
+    parser.add_argument('-C' , '--carray', action='store_true',
+                        help='convert binary file to a C array, not UF2')
+    args = parser.parse_args()
+    appstartaddr = int(args.base, 0)
+
+    if args.family.upper() in families:
+        familyid = families[args.family.upper()]
+    else:
+        try:
+            familyid = int(args.family, 0)
+        except ValueError:
+            error("Family ID needs to be a number or one of: " + ", ".join(families.keys()))
+
+    if args.list:
+        list_drives()
+    else:
+        if not args.input:
+            error("Need input file")
+        with open(args.input, mode='rb') as f:
+            inpbuf = f.read()
+        from_uf2 = is_uf2(inpbuf)
+        ext = "uf2"
+        if args.deploy:
+            outbuf = inpbuf
+        elif from_uf2:
+            outbuf = convert_from_uf2(inpbuf)
+            ext = "bin"
+        elif is_hex(inpbuf):
+            outbuf = convert_from_hex_to_uf2(inpbuf.decode("utf-8"))
+        elif args.carray:
+            outbuf = convert_to_carray(inpbuf)
+            ext = "h"
+        else:
+            outbuf = convert_to_uf2(inpbuf)
+        print("Converting to %s, output size: %d, start address: 0x%x" %
+              (ext, len(outbuf), appstartaddr))
+        if args.convert or ext != "uf2":
+            drives = []
+            if args.output == None:
+                args.output = "flash." + ext
+        else:
+            drives = get_drives()
+
+        if args.output:
+            write_file(args.output, outbuf)
+        else:
+            if len(drives) == 0:
+                error("No drive to deploy.")
+        for d in drives:
+            print("Flashing %s (%s)" % (d, board_id(d)))
+            write_file(d + "/NEW.UF2", outbuf)
+
+
+if __name__ == "__main__":
+    main()

bin/upload-to-bootloader.sh

@@ -0,0 +1,8 @@
+set -e
+
+echo "building for t-echo"
+pio run --environment t-echo
+
+echo "Converting to uf2 for NRF52 Adafruit bootloader - double tap on the reset button to force bootloader entry"
+bin/uf2conv.py .pio/build/t-echo/firmware.hex -f 0xADA52840
+cp flash.uf2 /media/kevinh/FTH*BOOT/

bin/upload-to-rak4631.sh

@@ -0,0 +1,5 @@
+set -e
+
+echo "Converting to uf2 for NRF52 Adafruit bootloader"
+bin/uf2conv.py .pio/build/rak4631/firmware.hex -f 0xADA52840
+cp flash.uf2 /media/kevinh/FTH*BOOT/

bin/version.sh

@@ -1,3 +0,0 @@
-
-
-export VERSION=0.8.1

bin/view-map.sh

@@ -0,0 +1,2 @@
+echo using amap tool to display memory map
+amap .pio/build/output.map

boards/eink0.1.json

@@ -0,0 +1,61 @@
+{
+  "build": {
+    "arduino": {
+      "ldscript": "nrf52840_s140_v6.ld"
+    },
+    "core": "nRF5",
+    "cpu": "cortex-m4",
+    "extra_flags": "-DARDUINO_NRF52840_TTGO_EINK -DNRF52840_XXAA",
+    "f_cpu": "64000000L",
+    "hwids": [
+      [
+        "0x239A",
+        "0x4405"
+      ]
+    ],
+    "usb_product": "TTGO_eink",
+    "mcu": "nrf52840",
+    "variant": "eink0.1",
+    "variants_dir": "variants",
+    "bsp": {
+      "name": "adafruit"
+    },
+    "softdevice": {
+      "sd_flags": "-DS140",
+      "sd_name": "s140",
+      "sd_version": "6.1.1",
+      "sd_fwid": "0x00B6"
+    },
+    "bootloader": {
+      "settings_addr": "0xFF000"
+    }
+  },
+  "connectivity": [
+    "bluetooth"
+  ],
+  "debug": {
+    "jlink_device": "nRF52840_xxAA",
+    "onboard_tools": [
+      "jlink"
+    ],
+    "svd_path": "nrf52840.svd"
+  },
+  "frameworks": [
+    "arduino"
+  ],
+  "name": "TTGO eink (Adafruit BSP)",
+  "upload": {
+    "maximum_ram_size": 248832,
+    "maximum_size": 815104,
+    "require_upload_port": true,
+    "speed": 115200,
+    "protocol": "jlink",
+    "protocols": [
+      "jlink",
+      "nrfjprog",
+      "stlink"
+    ]
+  },
+  "url": "FIXME",
+  "vendor": "TTGO"
+}

boards/lora-relay-v1.json

@@ -0,0 +1,46 @@
+{
+  "build": {
+    "arduino": {
+      "ldscript": "nrf52840_s140_v6.ld"
+    },
+    "core": "nRF5",
+    "cpu": "cortex-m4",
+    "extra_flags": "-DARDUINO_NRF52840_LORA_RELAY_V1 -DNRF52840_XXAA",
+    "f_cpu": "64000000L",
+    "hwids": [["0x239A", "0x4404"]],
+    "usb_product": "LORA_RELAY",
+    "mcu": "nrf52840",
+    "variant": "lora_relay_v1",
+    "variants_dir": "variants",
+    "bsp": {
+      "name": "adafruit"
+    },
+    "softdevice": {
+      "sd_flags": "-DS140",
+      "sd_name": "s140",
+      "sd_version": "6.1.1",
+      "sd_fwid": "0x00B6"
+    },
+    "bootloader": {
+      "settings_addr": "0xFF000"
+    }
+  },
+  "connectivity": ["bluetooth"],
+  "debug": {
+    "jlink_device": "nRF52840_xxAA",
+    "onboard_tools": ["jlink"],
+    "svd_path": "nrf52840.svd"
+  },
+  "frameworks": ["arduino"],
+  "name": "Meshtastic Lora Relay V1 (Adafruit BSP)",
+  "upload": {
+    "maximum_ram_size": 248832,
+    "maximum_size": 815104,
+    "require_upload_port": true,
+    "speed": 115200,
+    "protocol": "jlink",
+    "protocols": ["jlink", "nrfjprog", "stlink"]
+  },
+  "url": "https://github.com/BigCorvus/SX1262-LoRa-BLE-Relay",
+  "vendor": "BigCorvus"
+}

boards/lora-relay-v2.json

@@ -0,0 +1,46 @@
+{
+  "build": {
+    "arduino": {
+      "ldscript": "nrf52840_s140_v6.ld"
+    },
+    "core": "nRF5",
+    "cpu": "cortex-m4",
+    "extra_flags": "-DARDUINO_NRF52840_LORA_RELAY_V2 -DNRF52840_XXAA",
+    "f_cpu": "64000000L",
+    "hwids": [["0x239A", "0x4406"]],
+    "usb_product": "LORA_RELAY",
+    "mcu": "nrf52840",
+    "variant": "lora_relay_v2",
+    "variants_dir": "variants",
+    "bsp": {
+      "name": "adafruit"
+    },
+    "softdevice": {
+      "sd_flags": "-DS140",
+      "sd_name": "s140",
+      "sd_version": "6.1.1",
+      "sd_fwid": "0x00B6"
+    },
+    "bootloader": {
+      "settings_addr": "0xFF000"
+    }
+  },
+  "connectivity": ["bluetooth"],
+  "debug": {
+    "jlink_device": "nRF52840_xxAA",
+    "onboard_tools": ["jlink"],
+    "svd_path": "nrf52840.svd"
+  },
+  "frameworks": ["arduino"],
+  "name": "Meshtastic Lora Relay V1 (Adafruit BSP)",
+  "upload": {
+    "maximum_ram_size": 248832,
+    "maximum_size": 815104,
+    "require_upload_port": true,
+    "speed": 115200,
+    "protocol": "jlink",
+    "protocols": ["jlink", "nrfjprog", "stlink"]
+  },
+  "url": "https://github.com/BigCorvus/SX1262-LoRa-BLE-Relay",
+  "vendor": "BigCorvus"
+}

boards/lora_isp4520.json

@@ -0,0 +1,48 @@
+{
+  "build": {
+    "arduino": {
+      "ldscript": "nrf52832_s132_v6.ld"
+    },
+    "core": "nRF5",
+    "cpu": "cortex-m4",
+    "extra_flags": "-DNRF52832_XXAA -DNRF52",
+    "f_cpu": "64000000L",
+    "mcu": "nrf52832",
+    "variant": "lora_isp4520",
+    "bsp": {
+      "name": "adafruit"
+    },
+    "softdevice": {
+      "sd_flags": "-DS132",
+      "sd_name": "s132",
+      "sd_version": "6.1.1",
+      "sd_fwid": "0x00B7"
+    }
+  },
+  "connectivity": [
+    "bluetooth"
+  ],
+  "debug": {
+    "jlink_device": "nRF52832_xxAA",
+    "svd_path": "nrf52.svd"
+  },
+  "frameworks": [
+    "arduino"
+  ],
+  "name": "lora ISP4520",
+  "upload": {
+    "maximum_ram_size": 65536,
+    "maximum_size": 524288,
+    "require_upload_port": true,
+    "speed": 115200,
+    "protocol": "nrfutil",
+    "protocols": [
+      "jlink",
+      "nrfjprog",
+      "nrfutil",
+      "stlink"
+    ]
+  },
+  "url": "",
+  "vendor": "PsiSoft"
+}

boards/nrf52840_dk.json

@@ -0,0 +1,47 @@
+{
+    "build": {
+      "arduino": {
+        "ldscript": "nrf52840_s140_v6.ld"
+      },
+      "core": "nRF5",
+      "cpu": "cortex-m4",
+      "extra_flags": "-DARDUINO_NRF52840_PCA10056 -DNRF52840_XXAA",
+      "f_cpu": "64000000L",
+      "hwids": [["0x239A", "0x4404"]],
+      "usb_product": "nrf52840dk",
+      "mcu": "nrf52840",
+      "variant": "pca10056",
+      "variants_dir": "variants",
+      "bsp": {
+        "name": "adafruit"
+      },
+      "softdevice": {
+        "sd_flags": "-DS140",
+        "sd_name": "s140",
+        "sd_version": "6.1.1",
+        "sd_fwid": "0x00B6"
+      },
+      "bootloader": {
+        "settings_addr": "0xFF000"
+      }
+    },
+    "connectivity": ["bluetooth"],
+    "debug": {
+      "jlink_device": "nRF52840_xxAA",
+      "onboard_tools": ["jlink"],
+      "svd_path": "nrf52840.svd"
+    },
+    "frameworks": ["arduino"],
+    "name": "A modified NRF52840-DK devboard (Adafruit BSP)",
+    "upload": {
+      "maximum_ram_size": 248832,
+      "maximum_size": 815104,
+      "require_upload_port": true,
+      "speed": 115200,
+      "protocol": "jlink",
+      "protocols": ["jlink", "nrfjprog", "stlink"]
+    },
+    "url": "https://meshtastic.org/",
+    "vendor": "Nordic Semi"
+  }
+  

boards/nrf52840_dk_modified.json

@@ -1,14 +1,14 @@
 {
   "build": {
     "arduino": {
-      "ldscript": "nrf52840_s140_v6.ld"
+      "ldscript": "nrf52840_s113_v7.ld"
     },
     "core": "nRF5",
     "cpu": "cortex-m4",
     "extra_flags": "-DARDUINO_NRF52840_PCA10056 -DNRF52840_XXAA",
     "f_cpu": "64000000L",
     "hwids": [["0x239A", "0x4404"]],
-    "usb_product": "SimPPR",
+    "usb_product": "nrf52840dk",
     "mcu": "nrf52840",
     "variant": "pca10056-rc-clock",
     "variants_dir": "variants",

boards/ppr1.json

@@ -0,0 +1,46 @@
+{
+  "build": {
+    "arduino": {
+      "ldscript": "nrf52833_s113_v7.ld"
+    },
+    "core": "nRF5",
+    "cpu": "cortex-m4",
+    "extra_flags": "-DARDUINO_NRF52833_PPR -DNRF52833_XXAA",
+    "f_cpu": "64000000L",
+    "hwids": [["0x239A", "0x4406"]],
+    "usb_product": "PPR",
+    "mcu": "nrf52833",
+    "variant": "ppr",
+    "variants_dir": "variants",
+    "bsp": {
+      "name": "adafruit"
+    },
+    "softdevice": {
+      "sd_flags": "-DS113",
+      "sd_name": "s113",
+      "sd_version": "7.2.0",
+      "sd_fwid": "0x00b6"
+    },
+    "bootloader": {
+      "settings_addr": "0xFF000"
+    }
+  },
+  "connectivity": ["bluetooth"],
+  "debug": {
+    "jlink_device": "nRF52833_xxAA",
+    "onboard_tools": ["jlink"],
+    "svd_path": "nrf52833.svd"
+  },
+  "frameworks": ["arduino"],
+  "name": "Meshtastic PPR1 (Adafruit BSP)",
+  "upload": {
+    "maximum_ram_size": 248832,
+    "maximum_size": 815104,
+    "require_upload_port": true,
+    "speed": 115200,
+    "protocol": "jlink",
+    "protocols": ["jlink", "nrfjprog", "stlink"]
+  },
+  "url": "https://meshtastic.org/",
+  "vendor": "Othernet"
+}

boards/rak815.json

@@ -0,0 +1,55 @@
+{
+  "build": {
+    "arduino":{
+      "ldscript": "nrf52832_s132_v6.ld"
+    },
+    "core": "nRF5",
+    "cpu": "cortex-m4",
+    "extra_flags": "-DNRF52832_XXAA -DNRF52",
+    "f_cpu": "64000000L",
+    "hwids": [
+      [
+        "0x10c4",
+        "0xea60"
+      ]
+    ],
+    "usb_product": "RAK815",
+    "mcu": "nrf52832",
+    "variant": "rak815",
+    "bsp": {
+      "name": "adafruit"
+    },
+    "softdevice": {
+      "sd_flags": "-DS132",
+      "sd_name": "s132",
+      "sd_version": "6.1.1",
+      "sd_fwid": "0x00B7"
+    }
+  },
+  "connectivity": [
+    "bluetooth"
+  ],
+  "debug": {
+    "jlink_device": "nRF52832_xxAA",
+    "svd_path": "nrf52.svd"
+  },
+  "frameworks": [
+    "arduino"
+  ],
+  "name": "RAK RAK815",
+  "upload": {
+    "maximum_ram_size": 65536,
+    "maximum_size": 524288,
+    "require_upload_port": true,
+    "speed": 115200,
+    "protocol": "nrfutil",
+    "protocols": [
+      "jlink",
+      "nrfjprog",
+      "nrfutil",
+      "stlink"
+    ]
+  },
+  "url": "https://store.rakwireless.com/products/rak815-hybrid-location-tracker",
+  "vendor": "RAK"
+}

boards/t-echo.json

@@ -0,0 +1,64 @@
+{
+  "build": {
+    "arduino": {
+      "ldscript": "nrf52840_s140_v6.ld"
+    },
+    "core": "nRF5",
+    "cpu": "cortex-m4",
+    "extra_flags": "-DARDUINO_NRF52840_TTGO_EINK -DNRF52840_XXAA",
+    "f_cpu": "64000000L",
+    "hwids": [
+      [
+        "0x239A",
+        "0x4405"
+      ]
+    ],
+    "usb_product": "TTGO_eink",
+    "mcu": "nrf52840",
+    "variant": "t-echo",
+    "variants_dir": "variants",
+    "bsp": {
+      "name": "adafruit"
+    },
+    "softdevice": {
+      "sd_flags": "-DS140",
+      "sd_name": "s140",
+      "sd_version": "6.1.1",
+      "sd_fwid": "0x00B6"
+    },
+    "bootloader": {
+      "settings_addr": "0xFF000"
+    }
+  },
+  "connectivity": [
+    "bluetooth"
+  ],
+  "debug": {
+    "jlink_device": "nRF52840_xxAA",
+    "onboard_tools": [
+      "jlink"
+    ],
+    "svd_path": "nrf52840.svd"
+  },
+  "frameworks": [
+    "arduino"
+  ],
+  "name": "TTGO eink (Adafruit BSP)",
+    "upload": {
+      "maximum_ram_size": 248832,
+      "maximum_size": 815104,
+      "speed": 115200,
+      "protocol": "nrfutil",
+      "protocols": [
+          "jlink",
+          "nrfjprog",
+          "nrfutil",
+          "stlink"
+      ],
+      "use_1200bps_touch": true,
+      "require_upload_port": true,
+      "wait_for_upload_port": true
+  },
+  "url": "FIXME",
+  "vendor": "TTGO"
+}

boards/wiscore_rak4600.json

@@ -0,0 +1,71 @@
+{
+  "build": {
+    "arduino": {
+      "ldscript": "nrf52832_s132_v6.ld"
+    },
+    "core": "nRF5",
+    "cpu": "cortex-m4",
+    "extra_flags": "-DNRF52832_XXAA -DNRF52",
+    "f_cpu": "64000000L",
+    "hwids": [
+      [
+        "0x239A",
+        "0x8029"
+      ],
+      [
+        "0x239A",
+        "0x0029"
+      ],
+      [
+        "0x239A",
+        "0x002A"
+      ],
+      [
+        "0x239A",
+        "0x802A"
+      ]
+    ],
+    "usb_product": "Feather nRF52832 Express",
+    "mcu": "nrf52832",
+    "variant": "WisCore_RAK4600_Board",
+    "bsp": {
+      "name": "adafruit"
+    },
+    "softdevice": {
+      "sd_flags": "-DS132",
+      "sd_name": "s132",
+      "sd_version": "6.1.1",
+      "sd_fwid": "0x00B7"
+    },
+    "zephyr": {
+      "variant": "nrf52_adafruit_feather"
+    }
+  },
+  "connectivity": [
+    "bluetooth"
+  ],
+  "debug": {
+    "jlink_device": "nRF52832_xxAA",
+    "svd_path": "nrf52.svd"
+  },
+  "frameworks": [
+    "arduino",
+    "zephyr"
+  ],
+  "name": "Adafruit Bluefruit nRF52832 Feather",
+  "upload": {
+    "maximum_ram_size": 65536,
+    "maximum_size": 524288,
+    "require_upload_port": true,
+    "speed": 115200,
+    "protocol": "nrfutil",
+    "protocols": [
+      "jlink",
+      "nrfjprog",
+      "nrfutil",
+      "stlink"
+    ]
+  },
+  "url": "https://www.adafruit.com/product/3406",
+  "vendor": "Adafruit"
+}

boards/wiscore_rak4631.json

@@ -0,0 +1,72 @@
+{
+    "build": {
+        "arduino": {
+            "ldscript": "nrf52840_s140_v6.ld"
+        },
+        "core": "nRF5",
+        "cpu": "cortex-m4",
+        "extra_flags": "-DARDUINO_NRF52840_FEATHER -DNRF52840_XXAA",
+        "f_cpu": "64000000L",
+        "hwids": [
+            [
+                "0x239A",
+                "0x8029"
+            ],
+            [
+                "0x239A",
+                "0x0029"
+            ],
+            [
+                "0x239A",
+                "0x002A"
+            ],
+            [
+                "0x239A",
+                "0x802A"
+            ]
+        ],
+        "usb_product": "WisCore RAK4631 Board",
+        "mcu": "nrf52840",
+        "variant": "WisCore_RAK4631_Board",
+        "bsp": {
+            "name": "adafruit"
+        },
+        "softdevice": {
+            "sd_flags": "-DS140",
+            "sd_name": "s140",
+            "sd_version": "6.1.1",
+            "sd_fwid": "0x00B6"
+        },
+        "bootloader": {
+            "settings_addr": "0xFF000"
+        }
+    },
+    "connectivity": [
+        "bluetooth"
+    ],
+    "debug": {
+        "jlink_device": "nRF52840_xxAA",
+        "svd_path": "nrf52840.svd"
+    },
+    "frameworks": [
+        "arduino"
+    ],
+    "name": "WisCore RAK4631 Board",
+    "upload": {
+        "maximum_ram_size": 248832,
+        "maximum_size": 815104,
+        "speed": 115200,
+        "protocol": "nrfutil",
+        "protocols": [
+            "jlink",
+            "nrfjprog",
+            "nrfutil",
+            "stlink"
+        ],
+        "use_1200bps_touch": true,
+        "require_upload_port": true,
+        "wait_for_upload_port": true
+    },
+    "url": "https://www.rakwireless.com",
+    "vendor": "RAKwireless"
+}

docs/.well-known/assetlinks.json

@@ -1,9 +0,0 @@
-[{
-  "relation": ["delegate_permission/common.handle_all_urls"],
-  "target": {
-    "namespace": "android_app",
-    "package_name": "com.geeksville.mesh",
-    "sha256_cert_fingerprints":
-    ["D0:05:E7:8B:D2:1B:FA:94:56:1D:6B:90:EB:53:07:1A:74:4F:D9:C2:6F:13:87:6A:D9:17:4F:C2:59:48:02:9D", "42:17:52:DC:57:40:38:B5:6B:86:61:1C:2F:47:DB:2B:0F:A2:EA:59:E1:18:9C:AA:90:8D:37:D6:CD:40:0E:BB", "A9:3B:45:65:68:C1:75:DB:08:00:A0:9F:06:77:7F:89:2D:81:24:32:AD:B8:A3:DF:73:BC:3E:7F:06:C8:0C:6D"]
-  }
-}]

docs/CNAME

@@ -1 +0,0 @@
-www.meshtastic.org

docs/README.md

@@ -1,85 +0,0 @@
-# What is Meshtastic?
-
-Meshtastic™ is a project that lets you use
-inexpensive (\$30 ish) GPS radios as an extensible, long battery life, secure, mesh GPS communicator. These radios are great for hiking, skiing, paragliding - essentially any hobby where you don't have reliable internet access. Each member of your private mesh can always see the location and distance of all other members and any text messages sent to your group chat.
-
-The radios automatically create a mesh to forward packets as needed, so everyone in the group can receive messages from even the furthest member. The radios will optionally work with your phone, but no phone is required.
-
-Note: Questions after reading this? See our new [forum](https://meshtastic.discourse.group/).
-
-### Uses
-
-- Outdoor sports where cellular coverage is limited. (Hiking, Skiing, Boating, Paragliding, Gliders etc..)
-- Applications where closed source GPS communicators just won't cut it (it is easy to add features for glider pilots etc...)
-- Secure long-range communication within groups without depending on cellular providers
-- Finding your lost kids ;-)
-- Through our [python API](https://pypi.org/project/meshtastic/) use these inexpensive radios to easily add mesh networking to your own projects.
-
-[![Youtube video demo](desk-video-screenshot.png)](https://www.youtube.com/watch?v=WlNbMbVZlHI "Meshtastic early demo")
-
-### Features
-
-Not all of these features are fully implemented yet - see **important** disclaimers below. But they should be in by the time we decide to call this project beta (three months?)
-
-- Very long battery life (should be about eight days with the beta software)
-- Built in GPS and [LoRa](https://en.wikipedia.org/wiki/LoRa) radio, but we manage the radio automatically for you
-- Long range - a few miles per node but each node will forward packets as needed
-- Secure - channels are encrypted by AES256 (But see important disclaimers below wrt this feature)
-- Shows direction and distance to all members of your channel
-- Directed or broadcast text messages for channel members
-- Open and extensible codebase supporting multiple hardware vendors - no lock in to one vendor
-- Communication API for bluetooth devices (such as our Android app) to use the mesh. An iOS application is in the works. And [Meshtastic-python](https://pypi.org/project/meshtastic/) provides access from desktop computers.
-- Very easy sharing of private secured channels. Just share a special link or QR code with friends and they can join your encrypted mesh
-
-This project is currently in beta testing but it is fairly stable and feature complete - if you have questions please [join our discussion forum](https://meshtastic.discourse.group/).
-
-This software is 100% open source and developed by a group of hobbyist experimenters. No warranty is provided, if you'd like to improve it - we'd love your help. Please post in the [forum](https://meshtastic.discourse.group/).
-
-### Beginner's Guide
-
-For an detailed walk-through aimed at beginners, we recommend [meshtastic.letstalkthis.com](https://meshtastic.letstalkthis.com/).
-
-# Updates
-
-Note: Updates are happening almost daily, only major updates are listed below. For more details see our forum.
-
-- 06/24/2020 - 0.7.x Now with over 1000 android users, over 600 people using the radios and translated into 13 languages. Fairly stable and we are working through bugs to get to 1.0.
-- 06/04/2020 - 0.6.7 Beta releases of both the application and the device code are released. Features are fairly solid now with a sizable number of users.
-- 04/28/2020 - 0.6.0 [Python API](https://pypi.org/project/meshtastic/) released. Makes it easy to use meshtastic devices as "zero config / just works" mesh transport adapters for other projects.
-- 04/20/2020 - 0.4.3 Pretty solid now both for the android app and the device code. Many people have donated translations and code. Probably going to call it a beta soon.
-- 03/03/2020 - 0.0.9 of the Android app and device code is released. Still an alpha but fairly functional.
-- 02/25/2020 - 0.0.4 of the Android app is released. This is a very early alpha, see below to join the alpha-testers group.
-- 02/23/2020 - 0.0.4 release. Still very bleeding edge but much closer to the final power management, a charged T-BEAM should run for many days with this load. If you'd like to try it, we'd love your feedback. Click [here](https://github.com/meshtastic/Meshtastic-esp32/blob/master/README.md) for instructions.
-- 02/20/2020 - Our first alpha release (0.0.3) of the radio software is ready brave early people.
-
-## Meshtastic Android app
-
-Our Android application is available here:
-
-[![Download at https://play.google.com/store/apps/details?id=com.geeksville.mesh](https://play.google.com/intl/en_us/badges/static/images/badges/en_badge_web_generic.png)](https://play.google.com/store/apps/details?id=com.geeksville.mesh&referrer=utm_source%3Dgithub-homepage)
-
-The link above will return older more stable releases. We would prefer if you join our alpha-test group, because the application is rapidly improving. Three steps to opt-in to the alpha- test:
-
-1. Join [this Google group](https://groups.google.com/forum/#!forum/meshtastic-alpha-testers) with the account you use in Google Play.
-2. Go to this [URL](https://play.google.com/apps/testing/com.geeksville.mesh) to opt-in to the alpha test.
-3. If you encounter any problems or have questions, post in our [forum](https://meshtastic.discourse.group/) and we'll help.
-
-If you'd like to help with development, the source code is [on github](https://github.com/meshtastic/Meshtastic-Android).
-
-## Supported hardware
-
-We currently support two brands of radios. The [TTGO T-Beam](https://www.aliexpress.com/item/4001178678568.html) and the [Heltec LoRa 32](https://heltec.org/project/wifi-lora-32/). Most people should buy the T-Beam and a 18650 battery (total cost less than \$35). Also, the version of the T-Beam we link to is shipped with Meshtastic **preinstalled** by TTGO, so you don't have to install it yourself.
-
-Make sure to buy the frequency range which is legal for your country. For the USA, you should buy the 915MHz version. Getting a version that include a screen is optional, but highly recommended.
-
-Instructions for installing prebuilt firmware can be found [here](https://github.com/meshtastic/Meshtastic-esp32/blob/master/README.md).
-
-For a nice printable cases:
-
-1. TTGO T-Beam V0 see this [design](https://www.thingiverse.com/thing:3773717) by [bsiege](https://www.thingiverse.com/bsiege).
-2. TTGO T_Beam V1 see this [design](https://www.thingiverse.com/thing:3830711) by [rwanrooy](https://www.thingiverse.com/rwanrooy) or this [remix](https://www.thingiverse.com/thing:3949330) by [8ung](https://www.thingiverse.com/8ung)
-3. Heltec Lora32 see this [design](https://www.thingiverse.com/thing:3125854) by [ornotermes](https://www.thingiverse.com/ornotermes).
-
-# IMPORTANT DISCLAIMERS AND FAQ
-
-For a listing of currently missing features and a FAQ click [here](faq.md).

docs/_config.yml

@@ -1,8 +0,0 @@
-theme: jekyll-theme-cayman
-
-title: Meshtastic
-description: An opensource hiking, pilot, skiing, Signal-App-extending GPS mesh communicator
-google_analytics: G-DRZ5H5EXHV
-
-include: [".well-known"]
-

docs/editing-this-site.md

@@ -1,10 +0,0 @@
-If you'd like to edit this website and test it locally:
-
-Not yet implemented:
-Per https://help.github.com/en/github/working-with-github-pages/testing-your-github-pages-site-locally-with-jekyll
-
-* follow instructions here: https://jekyllrb.com/docs/installation/ubuntu/
-* run "run-locally.sh"
-* view webpages at localhost:4000
-
-The template seems to come from here: https://github.com/pages-themes/cayman

docs/faq.md

@@ -1,34 +0,0 @@
-# Disclaimers
-
-This project is still pretty young but moving at a pretty good pace. Not all features are fully implemented in the current alpha builds.
-Most of these problems should be solved by the beta release (within three months):
-
-- 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](software/crypto.md#summary-of-strengthsweaknesses-of-our-current-implementation) to determine risks you might face.
-- A number of (straightforward) software work items have to be completed before battery life matches our measurements, currently battery life is about three days. Join us on chat if you want the spreadsheet of power measurements/calculations.
-- The Android API needs to be documented better
-- No one has written an iOS app yet. But some good souls [are talking about it](https://github.com/meshtastic/Meshtastic-esp32/issues/14) ;-)
-
-For more details see the [device software TODO](https://github.com/meshtastic/Meshtastic-esp32/blob/master/docs/software/TODO.md) or the [Android app TODO](https://github.com/meshtastic/Meshtastic-Android/blob/master/TODO.md).
-
-# FAQ
-
-If you have a question missing from this faq, please [ask in our discussion forum](https://meshtastic.discourse.group/). And if you are feeling extra generous send in a pull-request for this faq.md with whatever we answered ;-).
-
-## Q: Which of the various supported radios should I buy?
-
-Basically you just need the radio + (optional but recommended) battery. The TBEAM is usually better because it has gps and huge battery socket. The Heltec is basically the same hardware but without the GPS (the phone provides position data to the radio in that case, so the behavior is similar - but it does burn some battery in the phone). Also the battery for the Heltec can be smaller.
-
-In addition to Aliexpress, (banggood.com) usually has stock and faster shipping, or Amazon. If buying a TBEAM, make sure to buy a version that includes the OLED screen - this project doesn't absolutely require the screen, but we use it if is installed.
-
-@claesg has added links to various 3D printable cases, you can see them at (www.meshtastic.org).
-
-## Q: Do you have plans to commercialize this project
-
-Nope. though if some other person/group wanted to use this software and a more customized device we think that would be awesome (as long as they obey the GPL license).
-
-## Q: Does this project use patented algorithms?
-
-(Kindly borrowed from the geeks at [ffmpeg](http://ffmpeg.org/legal.html))
-
-We do not know, we are not lawyers so we are not qualified to answer this. Also we have never read patents to implement any part of this, so even if we were qualified we could not answer it as we do not know what is patented. Furthermore the sheer number of software patents makes it impossible to read them all so no one (lawyer or not) could answer such a question with a definite no. We are merely geeks experimenting on a fun and free project.

docs/hardware/cubecell-TODO.md

@@ -1,6 +0,0 @@
-
-https://heltec-automation-docs.readthedocs.io/en/latest/cubecell/index.html
-
-https://github.com/HelTecAutomation/ASR650x-Arduino?utm_source=platformio.org&utm_medium=docs
-
-* Either portfreertos or make not theaded versions of Lock, WorkerThread, Queue (probably the latter).

docs/privacy.md

@@ -1,11 +0,0 @@
-# Meshtastic privacy policy
-
-We don't collect any personal identifying information.  
-
-If you have opted-in to analytics (thank you - that helps us know what things we need to improve), we'll receive anonymized information about user behavior.  i.e. which screens you used in the app etc...  We never
-capture usernames, the contents of your texts or your location.
-
-This is an open-source project run by hobbyists and we try to be completely transparent.  If you have questions on this policy, please file [a github issue](https://github.com/meshtastic/meshtastic-esp32/issues) and we'll reply/clarify/correct.
-
-Keep being awesome!
-

docs/radio-settings.md

@@ -1,30 +0,0 @@
-# Radio settings
-
-We use the same channel maps as LoRaWAN (though this is not LoRaWAN).
-
-![freq table](images/LoRa-Frequency-Bands.jpg)
-
-See [this site](https://www.rfwireless-world.com/Tutorials/LoRa-channels-list.html) for more information.
-
-## LoRaWAN Europe Frequency Band
-
-The maximum power allowed is +14dBM.
-
-### 433 MHz
-
-There are eight channels defined with a 0.2 MHz gap between them.
-Channel zero starts at 433.175 MHz
-
-### 870 MHz
-
-There are eight channels defined with a 0.3 MHz gap between them.
-Channel zero starts at 865.20 MHz
-
-## LoRaWAN for North America
-
-LoRaWAN defines 64, 125 kHz channels from 902.3 to 914.9 MHz increments.
-
-The maximum output power for North America is +30 dBM.
-
-The band is from 902 to 928 MHz. It mentions channel number and its respective channel frequency. All the 13 channels are separated by 2.16 MHz with respect to the adjacent channels.  
-Channel zero starts at 903.08 MHz center frequency.

docs/software/TODO.md

@@ -1,63 +0,0 @@
-# Geeksville's current work queue
-
-You probably don't care about this section - skip to the next one.
-
-# Medium priority
-
-Items to complete before 1.0.
-
-# Post 1.0 ideas
-
-- finish DSR for unicast
-- check fcc rules on duty cycle. we might not need to freq hop. https://www.sunfiretesting.com/LoRa-FCC-Certification-Guide/ . Might need to add enforcement for europe though.
-- make a no bluetooth configured yet screen - include this screen in the loop if the user hasn't yet paired
-- if radio params change fundamentally, discard the nodedb
-- re-enable the bluetooth battery level service on the T-BEAM
-- provide generalized (but slow) internet message forwarding service if one of our nodes has internet connectivity (MQTT) [ Not a requirement but a personal interest ]
-
-# Low priority ideas
-
-Items after the first final candidate release.
-
-- dynamic frequency scaling could save a lot of power on ESP32, but it seems to corrupt uart (even with ref_tick set correctly)
-- Change back to using a fixed sized MemoryPool rather than MemoryDynamic (see bug #149)
-- scan to find channels with low background noise? (Use CAD mode of the RF95 to automatically find low noise channels)
-- If the phone doesn't read fromradio mailbox within X seconds, assume the phone is gone and we can stop queing location msgs
-  for it (because it will redownload the nodedb when it comes back)
-- add frequency hopping, dependent on the gps time, make the switch moment far from the time anyone is going to be transmitting
-- assign every "channel" a random shared 8 bit sync word (per 4.2.13.6 of datasheet) - use that word to filter packets before even checking CRC. This will ensure our CPU will only wake for packets on our "channel"
-- the BLE stack is leaking about 200 bytes each time we go to light sleep
-- use fuse bits to store the board type and region. So one load can be used on all boards
-- Don't store position packets in the to phone fifo if we are disconnected. The phone will get that info for 'free' when it
-  fetches the fresh nodedb.
-- Use the RFM95 sequencer to stay in idle mode most of the time, then automatically go to receive mode and automatically go from transmit to receive mode. See 4.2.8.2 of manual.
-- Use fixed32 for node IDs, packetIDs, successid, failid, and lat/lon - will require all nodes to be updated, but make messages slightly smaller.
-- add "store and forward" support for messages, or move to the DB sync model. This would allow messages to be eventually delivered even if nodes are out of contact at the moment.
-- use variable length Strings in protobufs (instead of current fixed buffers). This would save lots of RAM
-- use BLEDevice::setPower to lower our BLE transmit power - extra range doesn't help us, it costs amps and it increases snoopability
-- make a HAM build: just a new frequency list, a bool to say 'never do encryption' and use hte callsign as that node's unique id. -from Girts
-- don't forward redundant pings or ping responses to the phone, it just wastes phone battery
-- don't send location packets if we haven't moved significantly
-- scrub default radio config settings for bandwidth/range/speed
-- show radio and gps signal strength as an image
-- only BLE advertise for a short time after the screen is on and button pressed - to save power and prevent people for sniffing for our BT app.
-- make mesh aware network timing state machine (sync wake windows to gps time) - this can save LOTS of battery
-- split out the software update utility so other projects can use it. Have the appload specify the URL for downloads.
-- read the PMU battery fault indicators and blink/led/warn user on screen
-- discard very old nodedb records (> 1wk)
-- handle millis() rollover in GPS.getTime - otherwise we will break after 50 days
-- report esp32 device code bugs back to the mothership via android
-- change BLE bonding to something more secure. see comment by pSecurity->setAuthenticationMode(ESP_LE_AUTH_BOND)
-
-Changes related to wifi support on ESP32:
-
-- iram space: https://esp32.com/viewtopic.php?t=8460
-- set https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/external-ram.html spi ram bss
-- figure out if iram or bluetooth classic caused ble problems
-- post bug on esp32-arduino with BLE bug findings
-
-# Spinoff project ideas
-
-- an open source version of https://www.burnair.ch/skynet/
-- a paragliding app like http://airwhere.co.uk/
-- How do avalanche beacons work? Could this do that as well? possibly by using beacon mode feature of the RF95?

docs/software/bluetooth-api.md

@@ -1,107 +0,0 @@
-# Bluetooth API
-
-The Bluetooth API is design to have only a few characteristics and most 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.
-
-## A note on MTU sizes
-
-This device will work with any MTU size, but it is highly recommended that you call your phone's "setMTU function to increase MTU to 512 bytes" as soon as you connect to a service. This will dramatically improve performance when reading/writing packets.
-
-## 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.
-
-For a reference implementation of a client that uses this service see [RadioInterfaceService](https://github.com/meshtastic/Meshtastic-Android/blob/master/app/src/main/java/com/geeksville/mesh/service/RadioInterfaceService.kt).
-
-Typical flow when a phone connects to the device should be the following (if you want to watch this flow from the python app just run "meshtastic --debug --info" - the flow over BLE is identical):
-
-- 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.
-- 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.
-
-Expected sequence for initial download:
-
-- After your send startConfig, you will receive a series of FromRadio packets. The sequence of these packets will be as follows (but you are best not counting on this, instead just update your model for whatever packet you receive - based on looking at the type)
-- Read a RadioConfig from "radio" - used to get the channel and radio settings
-- Read a User from "user" - to get the username for this node
-- Read a MyNodeInfo from "mynode" to get information about this local device
-- Write an empty record to "nodeinfo" to restart the nodeinfo reading state machine
-- Read a series of NodeInfo packets to build the phone's copy of the current NodeDB for the mesh
-- Read a endConfig packet that indicates that the entire state you need has been sent.
-- Read a series of MeshPackets until it returns empty to get any messages that arrived for this node while the phone was away
-
-For definitions (and documentation) on FromRadio, ToRadio, MyNodeInfo, NodeInfo and User protocol buffers see [mesh.proto](https://github.com/meshtastic/Meshtastic-protobufs/blob/master/mesh.proto)
-
-UUID for the service: 6ba1b218-15a8-461f-9fa8-5dcae273eafd
-
-Each characteristic is listed as follows:
-
-UUID
-Properties
-Description (including human readable name)
-
-8ba2bcc2-ee02-4a55-a531-c525c5e454d5
-read
-fromradio - contains a newly received FromRadio packet destined towards the phone (up to MAXPACKET bytes per packet).
-After reading the esp32 will put the next packet in this mailbox. If the FIFO is empty it will put an empty packet in this
-mailbox.
-
-f75c76d2-129e-4dad-a1dd-7866124401e7
-write
-toradio - write ToRadio protobufs to this characteristic to send them (up to MAXPACKET len)
-
-ed9da18c-a800-4f66-a670-aa7547e34453
-read,notify,write
-fromnum - the current packet # in the message waiting inside fromradio, if the phone sees this notify it should read messages
-until it catches up with this number.
-
-The phone can write to this register to go backwards up to FIXME packets, to handle the rare case of a fromradio packet was dropped after the esp32 callback was called, but before it arrives at the phone. If the phone writes to this register the esp32 will discard older packets and put the next packet >= fromnum in fromradio.
-When the esp32 advances fromnum, it will delay doing the notify by 100ms, in the hopes that the notify will never actally need to be sent if the phone is already pulling from fromradio.
-
-Note: that if the phone ever sees this number decrease, it means the esp32 has rebooted.
-
-Re: queue management
-Not all messages are kept in the fromradio queue (filtered based on SubPacket):
-
-- only the most recent Position and User messages for a particular node are kept
-- all Data SubPackets are kept
-- No WantNodeNum / DenyNodeNum messages are kept
-  A variable keepAllPackets, if set to true will suppress this behavior and instead keep everything for forwarding to the phone (for debugging)
-
-## Protobuf API
-
-On connect, you should send a want_config_id protobuf to the device. This will cause the device to send its node DB and radio config via the fromradio endpoint. After sending the full DB, the radio will send a want_config_id to indicate it is done sending the configuration.
-
-## Other bluetooth services
-
-This document focuses on the core mesh service, but it is worth noting that the following other Bluetooth services are also
-provided by the device.
-
-### BluetoothSoftwareUpdate
-
-The software update service. For a sample function that performs a software update using this API see [startUpdate](https://github.com/meshtastic/Meshtastic-Android/blob/master/app/src/main/java/com/geeksville/mesh/service/SoftwareUpdateService.kt).
-
-SoftwareUpdateService UUID cb0b9a0b-a84c-4c0d-bdbb-442e3144ee30
-
-Characteristics
-
-| UUID                                 | properties  | description                                                                                                       |
-| ------------------------------------ | ----------- | ----------------------------------------------------------------------------------------------------------------- |
-| e74dd9c0-a301-4a6f-95a1-f0e1dbea8e1e | write,read  | total image size, 32 bit, write this first, then read read back to see if it was acceptable (0 mean not accepted) |
-| e272ebac-d463-4b98-bc84-5cc1a39ee517 | write       | data, variable sized, recommended 512 bytes, write one for each block of file                                     |
-| 4826129c-c22a-43a3-b066-ce8f0d5bacc6 | write       | crc32, write last - writing this will complete the OTA operation, now you can read result                         |
-| 5e134862-7411-4424-ac4a-210937432c77 | read,notify | result code, readable but will notify when the OTA operation completes                                            |
-| GATT_UUID_SW_VERSION_STR/0x2a28      | read        | We also implement these standard GATT entries because SW update probably needs them:                              |
-| GATT_UUID_MANU_NAME/0x2a29           | read        |                                                                                                                   |
-| GATT_UUID_HW_VERSION_STR/0x2a27      | read        |                                                                                                                   |
-
-### DeviceInformationService
-
-Implements the standard BLE contract for this service (has software version, hardware model, serial number, etc...)
-
-### BatteryLevelService
-
-Implements the standard BLE contract service, provides battery level in a way that most client devices should automatically understand (i.e. it should show in the bluetooth devices screen automatically)

docs/software/build-instructions.md

@@ -1,22 +0,0 @@
-# Build instructions
-
-This project uses the simple PlatformIO build system. You can use the IDE, but for brevity
-in these instructions I describe use of their command line tool.
-
-1. Purchase a suitable radio (see above)
-2. Install [PlatformIO](https://platformio.org/platformio-ide)
-3. Download this git repo and cd into it
-4. Run `git submodule update --init --recursive` to pull in dependencies this project needs.
-5. If you are outside the USA, run "export COUNTRY=EU865" (or whatever) to set the correct frequency range for your country. Options are provided for `EU433`, `EU865`, `CN`, `JP` and `US` (default). Pull-requests eagerly accepted for other countries.
-6. Plug the radio into your USB port
-7. Type `pio run --environment XXX -t upload` (This command will fetch dependencies, build the project and install it on the board via USB). For XXX, use the board type you have (either `tbeam`, `heltec`, `ttgo-lora32-v1`, `ttgo-lora32-v2`).
-8. Platform IO also installs a very nice VisualStudio Code based IDE, see their [tutorial](https://docs.platformio.org/en/latest/tutorials/espressif32/arduino_debugging_unit_testing.html) if you'd like to use it.
-
-## Decoding stack traces
-
-If you get a crash, you can decode the addresses from the `Backtrace:` line:
-
-1. Save the `Backtrace: 0x....` line to a file, e.g., `backtrace.txt`.
-2. Run `bin/exception_decoder.py backtrace.txt` (this uses symbols from the
-   last `firmware.elf`, so you must be running the same binary that's still in
-   your `.pio/build` directory).

docs/software/crypto.md

@@ -1,51 +0,0 @@
-# Encryption in Meshtastic
-
-Cryptography is tricky, so we've tried to 'simply' apply standard crypto solutions to our implementation. However,
-the project developers are not cryptography experts. Therefore we ask two things:
-
-- If you are a cryptography expert, please review these notes and our questions below. Can you help us by reviewing our
-  notes below and offering advice? We will happily give as much or as little credit as you wish ;-).
-- Consider our existing solution 'alpha' and probably fairly secure against a not particularly aggressive adversary
-(but we can't yet make a more confident statement).
-
-## Summary of strengths/weaknesses of our current implementation
-
-Based on comments from reviewers (see below), here's some tips for usage of these radios.  So you can know the level of protection offered:
-
-* It is pretty likely that the AES256 security is implemented 'correctly' and an observer will not be able to decode your messages.
-* Warning: If an attacker is able to get one of the radios in their position, they could either a) extract the channel key from that device or b) use that radio to listen to new communications.
-* Warning: If an attacker is able to get the "Channel QR code/URL" that you share with others - that attacker could then be able to read any messages sent on the channel (either tomorrow or in the past - if they kept a raw copy of those broadcast packets)
-
-Possible future areas of work (if there is enough interest - post in our [forum](https://meshtastic.discourse.group) if you want this):
-
-1. Optionally requiring users to provide a PIN to regain access to the mesh.  This could be based on: intentionally locking the device, time since last use, or any member could force all members to reauthenticate,
-2. Until a device reauthenticates, any other access via BLE or USB would be blocked (this would protect against attackers who are not prepared to write custom software to extract and reverse engineer meshtastic flash memory)
-3. Turning on read-back protection in the device fuse-bits (this would extend protection in #2 to block all but **extremely** advanced attacks involving chip disassembly)
-4. Time limiting keys used for message transmission and automatically cycling them on a schedule.  This would protect past messages from being decoded even if an attacker learns the current key.
-
-### Notes for reviewers
-
-If you are reviewing our implementation, this is a brief statement of our method.
-
-- We do all crypto at the SubPacket (payload) level only, so that all meshtastic nodes will route for others - even those channels which are encrypted with a different key.
-- Mostly based on reading [Wikipedia](<https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_(CTR)>) and using the modes the ESP32 provides support for in hardware.
-- We use AES256-CTR as a stream cypher (with zero padding on the last BLOCK) because it is well supported with hardware acceleration.
-- Our AES key is 128 or 256 bits, shared as part of the 'Channel' specification.
-- The node number concatenated with the packet number is used as the NONCE. This nonce will be stored in flash in the device and should essentially never repeat. If the user makes a new 'Channel' (i.e. picking a new random 256 bit key), the packet number will start at zero. 
-- The packet number is sent in cleartext with each packet. The node number can be derived from the "from" field of each packet. (Cleartext is acceptable because it merely provides IV for each encryption run)
-- Each 16 byte BLOCK for a packet has an incrementing COUNTER. COUNTER starts at zero for the first block of each packet.
-- The IV for each block is constructed by concatenating the NONCE as the upper 96 bits of the IV and the COUNTER as the bottom 32 bits. Since our packets are small counter portion will really never be higher than 32 (five bits).
-
-## Comments from reviewer #1
-
-This reviewer is a cryptography professional, but would like to remain anonymous. We thank them for their comments ;-):
-
-I'm assuming that meshtastic is being used to hike in places where someone capable is trying to break it - like you were going to walk around DefCon using these. I spent about an hour reviewing the encryption, and have the following notes:
-
-* The write-up isn't quite as clear as the code.
-* The code is using AES-CTR mode correctly to ensure confidentiality.
-* The comment for initNonce really covers the necessary information.
-* I think the bigger encryption question is "what does the encryption need to do"? As it stands, an attacker who has yet to capture any of the devices cannot reasonably capture text or location data. An attacker who captures any device in the channel/mesh can read everything going to that device, everything stored on that device, and any other communication within the channel that they captured in encrypted form. If that capability basically matches your expectations, it is suitable for whatever adventures this was intended for, then, based on information publicly available or widely disclosed, the encryption is good. If those properties are distressing (like, device history is deliberately limited and you don't want a device captured today to endanger the information sent over the channel yesterday) we could talk about ways to achieve that (most likely synchronizing time and replacing the key with its own SHA256 every X hours, and ensuring the old key is not retained unnecessarily).
-* Two other things to keep in mind are that AES-CTR does not itself provide authenticity (e.g. an attacker can flip bits in replaying data and scramble the resulting plaintext), and that the current scheme gives some hints about transmission in the size. So, if you worry about an adversary deliberately messing-up messages or knowing the length of a text message, it looks like those might be possible.
-
-I'm guessing that the network behaves somewhat like a store-and-forward network - or, at least, that the goal is to avoid establishing a two-way connection to transmit data. I'm afraid I haven't worked with mesh networks much, but remember studying them briefly in school about ten years ago.

docs/software/esp32-arduino-build-notes.md

@@ -1,16 +0,0 @@
-# esp32-arduino build instructions
-
-We build our own custom version of esp32-arduino, in order to get some fixes we've made but haven't yet been merged in master.
-
-These are a set of currently unformatted notes on how to build and install them. Most developers should not care about this, because
-you'll automatically get our fixed libraries.
-
-```
-  last EDF release in arduino is: https://github.com/espressif/arduino-esp32/commit/1977370e6fc069e93ffd8818798fbfda27ae7d99
-  IDF release/v3.3 46b12a560
-  IDF release/v3.3 367c3c09c
-  https://docs.espressif.com/projects/esp-idf/en/release-v3.3/get-started/linux-setup.html
-  kevinh@kevin-server:~/development/meshtastic/esp32-arduino-lib-builder\$ python /home/kevinh/development/meshtastic/esp32-arduino-lib-builder/esp-idf/components/esptool*py/esptool/esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dout --flash_freq 40m --flash_size detect 0x1000 /home/kevinh/development/meshtastic/esp32-arduino-lib-builder/build/bootloader/bootloader.bin
-  cp -a out/tools/sdk/* components/arduino/tools/sdk
-  cp -ar components/arduino/* ~/.platformio/packages/framework-arduinoespressif32@src-fba9d33740f719f712e9f8b07da6ea13/
-```

docs/software/install-OSX.md

@@ -1,27 +0,0 @@
-(Here's some quick tips on installing the device code from OS-X, thanks to @android606)
-
-First time using LoRa for anything, just checking it out.
-
-I bought a T-Beam on eBay, followed the instructions to install the firmware here:
-[https://github.com/meshtastic/Meshtastic-esp32](https://github.com/meshtastic/Meshtastic-esp32)
-
-I'm using a Mac for this, so that might account for differences in the steps to get it working. I just swapped out my SSD last month, I'm using a pretty fresh install of OS X 10.15.3/Catalina.
-
-I got it working fairly smoothly, but there were two hang-ups I thought I'd mention:
-
-1. I am about 0% familiar with Python, so there were some issues getting esptool.py working. Basically, this OS X comes with Python 2.7 and no pip. Pip installed okay, so I used it to install esptool. Esptool appeared to install correctly, but I couldn't get it to work to save my life. Simply typing "esptool.py" doesn't work, and I just don't know enough python to figure out why. For some reason, it installs but isn't in the \$PATH anywhere, and I don't know where it went. Python 2.7 kept giving me warning messages about being old and unsupported, so I figured that might be a hint that I should upgrade.
-
-I ended up doing this:
-
-- brew install pyenv (to install pyenv)
-- pyenv install 3.7.7 (to install and select python 3.7.7)
-- pyenv global 3.7.7 (to select the new version of python)
-- brew install pip (to install pip3)
-- pip3 install --upgrade esptool (note I specifically had to use "pip3", not "pip")
-
-...then I was able to execute esptool.py
-
-2. esptool.py didn't work though, because the virtual com port wasn't showing up as a device. I had to install a driver from Silicon Labs, which I got here:
-   [driver for the CP210X USB to UART bridge from Silicon Labs](https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers)
-
-After I installed that, esptool.py was completely happy and the firmware loaded right up.

docs/software/mesh-alg.md

@@ -1,168 +0,0 @@
-# Mesh broadcast algorithm
-
-great source of papers and class notes: http://www.cs.jhu.edu/~cs647/
-
-flood routing improvements
-
-- DONE if we don't see anyone rebroadcast our want_ack=true broadcasts, retry as needed.
-
-reliable messaging tasks (stage one for DSR):
-
-- DONE generalize naive flooding
-- DONE add a max hops parameter, use it for broadcast as well (0 means adjacent only, 1 is one forward etc...). Store as three bits in the header.
-- DONE add a 'snoopReceived' hook for all messages that pass through our node.
-- DONE use the same 'recentmessages' array used for broadcast msgs to detect duplicate retransmitted messages.
-- DONE in the router receive path?, send an ack packet if want_ack was set and we are the final destination. FIXME, for now don't handle multihop or merging of data replies with these acks.
-- DONE keep a list of packets waiting for acks
-- DONE for each message keep a count of # retries (max of three). Local to the node, only for the most immediate hop, ignorant of multihop routing.
-- DONE delay some random time for each retry (large enough to allow for acks to come in)
-- DONE once an ack comes in, remove the packet from the retry list and deliver the ack to the original sender
-- DONE after three retries, deliver a no-ack packet to the original sender (i.e. the phone app or mesh router service)
-- DONE test one hop ack/nak with the python framework
-- DONE Do stress test with acks
-
-dsr tasks
-
-- DONE oops I might have broken message reception
-- DONE Don't use broadcasts for the network pings (close open github issue)
-- DONE add ignoreSenders to radioconfig to allow testing different mesh topologies by refusing to see certain senders
-- DONE test multihop delivery with the python framework
-
-optimizations / low priority:
-
-- read this [this](http://pages.cs.wisc.edu/~suman/pubs/nadv-mobihoc05.pdf) paper and others and make our naive flood routing less naive
-- read @cyclomies long email with good ideas on optimizations and reply
-- DONE Remove NodeNum assignment algorithm (now that we use 4 byte node nums)
-- DONE make android app warn if firmware is too old or too new to talk to
-- change nodenums and packetids in protobuf to be fixed32
-- low priority: think more careful about reliable retransmit intervals
-- make ReliableRouter.pending threadsafe
-- bump up PacketPool size for all the new ack/nak/routing packets
-- handle 51 day rollover in doRetransmissions
-- use a priority queue for the messages waiting to send. Send acks first, then routing messages, then data messages, then broadcasts?
-
-when we send a packet
-
-- do "hop by hop" routing
-- when sending, if destnodeinfo.next_hop is zero (and no message is already waiting for an arp for that node), startRouteDiscovery() for that node. Queue the message in the 'waiting for arp queue' so we can send it later when then the arp completes.
-- otherwise, use next_hop and start sending a message (with ack request) towards that node (starting with next_hop).
-
-when we receive any packet
-
-- sniff and update tables (especially useful to find adjacent nodes). Update user, network and position info.
-- if we need to route() that packet, resend it to the next_hop based on our nodedb.
-- if it is broadcast or destined for our node, deliver locally
-- handle routereply/routeerror/routediscovery messages as described below
-- then free it
-
-routeDiscovery
-
-- if we've already passed through us (or is from us), then it ignore it
-- use the nodes already mentioned in the request to update our routing table
-- if they were looking for us, send back a routereply
-- NOT DOING FOR NOW -if max_hops is zero and they weren't looking for us, drop (FIXME, send back error - I think not though?)
-- if we receive a discovery packet, and we don't have next_hop set in our nodedb, we use it to populate next_hop (if needed) towards the requester (after decrementing max_hops)
-- if we receive a discovery packet, and we have a next_hop in our nodedb for that destination we send a (reliable) we send a route reply towards the requester
-
-when sending any reliable packet
-
-- if timeout doing retries, send a routeError (nak) message back towards the original requester. all nodes eavesdrop on that packet and update their route caches.
-
-when we receive a routereply packet
-
-- update next_hop on the node, if the new reply needs fewer hops than the existing one (we prefer shorter paths). fixme, someday use a better heuristic
-
-when we receive a routeError packet
-
-- delete the route for that failed recipient, restartRouteDiscovery()
-- if we receive routeerror in response to a discovery,
-- fixme, eventually keep caches of possible other routes.
-
-TODO:
-
-- optimize our generalized flooding with heuristics, possibly have particular nodes self mark as 'router' nodes.
-
-- DONE reread the radiohead mesh implementation - hop to hop acknowledgement seems VERY expensive but otherwise it seems like DSR
-- DONE read about mesh routing solutions (DSR and AODV)
-- DONE read about general mesh flooding solutions (naive, MPR, geo assisted)
-- DONE reread the disaster radio protocol docs - seems based on Babel (which is AODVish)
-- REJECTED - seems dying - possibly dash7? https://www.slideshare.net/MaartenWeyn1/dash7-alliance-protocol-technical-presentation https://github.com/MOSAIC-LoPoW/dash7-ap-open-source-stack - does the opensource stack implement multihop routing? flooding? their discussion mailing list looks dead-dead
-- update duty cycle spreadsheet for our typical usecase
-
-a description of DSR: https://tools.ietf.org/html/rfc4728 good slides here: https://www.slideshare.net/ashrafmath/dynamic-source-routing
-good description of batman protocol: https://www.open-mesh.org/projects/open-mesh/wiki/BATMANConcept
-
-interesting paper on lora mesh: https://portal.research.lu.se/portal/files/45735775/paper.pdf
-It seems like DSR might be the algorithm used by RadioheadMesh. DSR is described in https://tools.ietf.org/html/rfc4728
-https://en.wikipedia.org/wiki/Dynamic_Source_Routing
-
-broadcast solution:
-Use naive flooding at first (FIXME - do some math for a 20 node, 3 hop mesh. A single flood will require a max of 20 messages sent)
-Then move to MPR later (http://www.olsr.org/docs/report_html/node28.html). Use altitude and location as heursitics in selecting the MPR set
-
-compare to db sync algorithm?
-
-what about never flooding gps broadcasts. instead only have them go one hop in the common case, but if any node X is looking at the position of Y on their gui, then send a unicast to Y asking for position update. Y replies.
-
-If Y were to die, at least the neighbor nodes of Y would have their last known position of Y.
-
-## approach 1
-
-- send all broadcasts with a TTL
-- periodically(?) do a survey to find the max TTL that is needed to fully cover the current network.
-- to do a study first send a broadcast (maybe our current initial user announcement?) with TTL set to one (so therefore no one will rebroadcast our request)
-- survey replies are sent unicast back to us (and intervening nodes will need to keep the route table that they have built up based on past packets)
-- count the number of replies to this TTL 1 attempt. That is the number of nodes we can reach without any rebroadcasts
-- repeat the study with a TTL of 2 and then 3. stop once the # of replies stops going up.
-- it is important for any node to do listen before talk to prevent stomping on other rebroadcasters...
-- For these little networks I bet a max TTL would never be higher than 3?
-
-## approach 2
-
-- send a TTL1 broadcast, the replies let us build a list of the nodes (stored as a bitvector?) that we can see (and their rssis)
-- we then broadcast out that bitvector (also TTL1) asking "can any of ya'll (even indirectly) see anyone else?"
-- if a node can see someone I missed (and they are the best person to see that node), they reply (unidirectionally) with the missing nodes and their rssis (other nodes might sniff (and update their db) based on this reply but they don't have to)
-- given that the max number of nodes in this mesh will be like 20 (for normal cases), I bet globally updating this db of "nodenums and who has the best rssi for packets from that node" would be useful
-- once the global DB is shared, when a node wants to broadcast, it just sends out its broadcast . the first level receivers then make a decision "am I the best to rebroadcast to someone who likely missed this packet?" if so, rebroadcast
-
-## approach 3
-
-- when a node X wants to know other nodes positions, it broadcasts its position with want_replies=true. Then each of the nodes that received that request broadcast their replies (possibly by using special timeslots?)
-- all nodes constantly update their local db based on replies they witnessed.
-- after 10s (or whatever) if node Y notices that it didn't hear a reply from node Z (that Y has heard from recently ) to that initial request, that means Z never heard the request from X. Node Y will reply to X on Z's behalf.
-- could this work for more than one hop? Is more than one hop needed? Could it work for sending messages (i.e. for a msg sent to Z with want-reply set).
-
-## approach 4
-
-look into the literature for this idea specifically.
-
-- don't view it as a mesh protocol as much as a "distributed db unification problem". When nodes talk to nearby nodes they work together
-  to update their nodedbs. Each nodedb would have a last change date and any new changes that only one node has would get passed to the
-  other node. This would nicely allow distant nodes to propogate their position to all other nodes (eventually).
-- handle group messages the same way, there would be a table of messages and time of creation.
-- when a node has a new position or message to send out, it does a broadcast. All the adjacent nodes update their db instantly (this handles 90% of messages I'll bet).
-- Occasionally a node might broadcast saying "anyone have anything newer than time X?" If someone does, they send the diffs since that date.
-- essentially everything in this variant becomes broadcasts of "request db updates for >time X - for _all_ or for a particular nodenum" and nodes sending (either due to request or because they changed state) "here's a set of db updates". Every node is constantly trying to
-  build the most recent version of reality, and if some nodes are too far, then nodes closer in will eventually forward their changes to the distributed db.
-- construct non ambigious rules for who broadcasts to request db updates. ideally the algorithm should nicely realize node X can see most other nodes, so they should just listen to all those nodes and minimize the # of broadcasts. the distributed picture of nodes rssi could be useful here?
-- possibly view the BLE protocol to the radio the same way - just a process of reconverging the node/msgdb database.
-
-# Old notes
-
-FIXME, merge into the above:
-
-good description of batman protocol: https://www.open-mesh.org/projects/open-mesh/wiki/BATMANConcept
-
-interesting paper on lora mesh: https://portal.research.lu.se/portal/files/45735775/paper.pdf
-It seems like DSR might be the algorithm used by RadioheadMesh. DSR is described in https://tools.ietf.org/html/rfc4728
-https://en.wikipedia.org/wiki/Dynamic_Source_Routing
-
-broadcast solution:
-Use naive flooding at first (FIXME - do some math for a 20 node, 3 hop mesh. A single flood will require a max of 20 messages sent)
-Then move to MPR later (http://www.olsr.org/docs/report_html/node28.html). Use altitude and location as heursitics in selecting the MPR set
-
-compare to db sync algorithm?
-
-what about never flooding gps broadcasts. instead only have them go one hop in the common case, but if any node X is looking at the position of Y on their gui, then send a unicast to Y asking for position update. Y replies.
-
-If Y were to die, at least the neighbor nodes of Y would have their last known position of Y.

docs/software/nrf52-TODO.md

@@ -1,226 +0,0 @@
-# NRF52 TODO
-
-
-## RAK815
-
-### Bootloader 
-Installing the adafruit bootloader is optional - I think the stock bootloader will work okay for most.
-
-```
-kevinh@kevin-server:~/development/meshtastic/Adafruit_nRF52_Bootloader$ make BOARD=rak815 flash
-LD rak815_bootloader-0.3.2-111-g9478eb7-dirty.out
-   text	   data	    bss	    dec	    hex	filename
-  20888	   1124	  15006	  37018	   909a	_build/build-rak815/rak815_bootloader-0.3.2-111-g9478eb7-dirty.out
-Create rak815_bootloader-0.3.2-111-g9478eb7-dirty.hex
-Create rak815_bootloader-0.3.2-111-g9478eb7-dirty-nosd.hex
-Flashing: rak815_bootloader-0.3.2-111-g9478eb7-dirty-nosd.hex
-nrfjprog --program _build/build-rak815/rak815_bootloader-0.3.2-111-g9478eb7-dirty-nosd.hex --sectoranduicrerase -f nrf52 --reset
-Parsing hex file.
-Erasing page at address 0x0.
-Erasing page at address 0x74000.
-Erasing page at address 0x75000.
-Erasing page at address 0x76000.
-Erasing page at address 0x77000.
-Erasing page at address 0x78000.
-Erasing page at address 0x79000.
-Erasing UICR flash area.
-Applying system reset.
-Checking that the area to write is not protected.
-Programming device.
-Applying system reset.
-Run.
-```
-
-## Misc work items
-
-RAM investigation.
-nRF52832-QFAA 64KB ram, 512KB flash vs
-nrf52832-QFAB 32KB ram, 512kb flash
-nrf52840 256KB RAM, 1MB flash
-
-platform.json
-
-    "framework-arduinoadafruitnrf52": {
-      "type": "framework",
-      "optional": true,
-      "version": "https://github.com/meshtastic/Adafruit_nRF52_Arduino.git"
-    },
-
-## Initial work items
-
-Minimum items needed to make sure hardware is good.
-
-- DONE set power UICR per https://devzone.nordicsemi.com/f/nordic-q-a/28562/nrf52840-regulator-configuration
-- switch charge controller into / out of performance mode (see 8.3.1 in datasheet)
-- write UC1701 wrapper
-- Test hardfault handler for null ptrs (if one isn't already installed)
-- test my hackedup bootloader on the real hardware
-- Use the PMU driver on real hardware
-- Use new radio driver on real hardware
-- Use UC1701 LCD driver on real hardware. Still need to create at startup and probe on SPI. Make sure SPI is atomic.
-- set vbus voltage per https://infocenter.nordicsemi.com/topic/ps_nrf52840/power.html?cp=4_0_0_4_2
-- test the LEDs
-- test the buttons
-
-## Secondary work items
-
-Needed to be fully functional at least at the same level of the ESP32 boards. At this point users would probably want them.
-
-- DONE get serial API working
-- get full BLE api working
-- make power management/sleep work properly
-- make a settimeofday implementation
-- DONE increase preamble length? - will break other clients? so all devices must update
-- DONE enable BLE DFU somehow
-- report appversion/hwversion in BLE
-- use new LCD driver from screen.cpp. Still need to hook it to a subclass of (poorly named) OLEDDisplay, and override display() to stream bytes out to the screen.
-- we need to enable the external tcxo for the sx1262 (on dio3)?
-- figure out which regulator mode the sx1262 is operating in
-- turn on security for BLE, make pairing work
-- make ble endpoints not require "start config", just have them start in config mode
-- use new PMU to provide battery voltage/% full to app (both bluetooth and screen)
-- do initial power measurements, measure effects of more preamble bits, measure power management and confirm battery life
-- set UICR.CUSTOMER to indicate board model & version
-
-## Items to be 'feature complete'
-
-- check datasheet about sx1262 temperature compensation
-- enable brownout detection and watchdog
-- stop polling for GPS characters, instead stay blocked on read in a thread
-- figure out what the correct current limit should be for the sx1262, currently we just use the default 100
-- put sx1262 in sleepmode when processor gets shutdown (or rebooted), ideally even for critical faults (to keep power draw low). repurpose deepsleep state for this.
-- good power management tips: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/optimizing-power-on-nrf52-designs
-- call PMU set_ADC_CONV(0) during sleep, to stop reading PMU adcs and decrease current draw
-- do final power measurements
-- backport the common PMU API between AXP192 and PmuBQ25703A
-- use the new buttons in the UX
-- currently using soft device SD140, is that ideal?
-- turn on the watchdog timer, require servicing from key application threads
-- nrf52setup should call randomSeed(tbd)
-- implement SYSTEMOFF behavior per https://infocenter.nordicsemi.com/topic/ps_nrf52840/power.html?cp=4_0_0_4_2
-
-## Things to do 'someday'
-
-Nice ideas worth considering someday...
-
-- enable monitor mode debugging (need to use real jlink): https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/monitor-mode-debugging-with-j-link-and-gdbeclipse
-- Improve efficiency of PeriodicTimer by only checking the next queued timer event, and carefully sorting based on schedule
-- make a Mfg Controller and device under test classes as examples of custom app code for third party devs. Make a post about this. Use a custom payload type code. Have device under test send a broadcast with max hopcount of 0 for the 'mfgcontroller' payload type. mfg controller will read SNR and reply. DOT will declare failure/success and switch to the regular app screen.
-- Hook Segger RTT to the nordic logging framework. https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/debugging-with-real-time-terminal
-- Use nordic logging for DEBUG_MSG
-- use the Jumper simulator to run meshes of simulated hardware: https://docs.jumper.io/docs/install.html
-- make/find a multithread safe debug logging class (include remote logging and timestamps and levels). make each log event atomic.
-- turn on freertos stack size checking
-- Currently we use Nordic's vendor ID, which is apparently okay: https://devzone.nordicsemi.com/f/nordic-q-a/44014/using-nordic-vid-and-pid-for-nrf52840 and I just picked a PID of 0x4403
-- Use NRF logger module (includes flash logging etc...) instead of DEBUG_MSG
-- Use "LED softblink" library on NRF52 to do nice pretty "breathing" LEDs. Don't whack LED from main thread anymore.
-- decrease BLE xmit power "At 0dBm with the DC/DC on, the nRF52832 transmitter draws 5.3mA. Increasing the TX power to +4dBm adds only 2.2mA. Decreasing it to -40 dBm saves only 2.6mA."
-- in addition to the main CPU watchdog, use the PMU watchdog as a really big emergency hammer
-- turn on 'shipping mode' in the PMU when device is 'off' - to cut battery draw to essentially zero
-- make Lorro_BQ25703A read/write operations atomic, current version could let other threads sneak in (once we start using threads)
-- make the segger logbuffer larger, move it to RAM that is preserved across reboots and support reading it out at runtime (to allow full log messages to be included in crash reports). Share this code with ESP32 (use gcc noinit attribute)
-- convert hardfaults/panics/asserts/wd exceptions into fault codes sent to phone
-- stop enumerating all i2c devices at boot, it wastes power & time
-- consider using "SYSTEMOFF" deep sleep mode, without RAM retension. Only useful for 'truly off - wake only by button press' only saves 1.5uA vs SYSTEMON. (SYSTEMON only costs 1.5uA). Possibly put PMU into shipping mode?
-- change the BLE protocol to be more symmetric. Have the phone _also_ host a GATT service which receives writes to
-  'fromradio'. This would allow removing the 'fromnum' mailbox/notify scheme of the current approach and decrease the number of packet handoffs when a packet is received.
-- Using the preceeding, make a generalized 'nrf52/esp32 ble to internet' bridge service. To let nrf52 apps do MQTT/UDP/HTTP POST/HTTP GET operations to web services.
-- lower advertise interval to save power, lower ble transmit power to save power
-- the SX126x class does SPI transfers on a byte by byte basis, which is very ineffecient. Much better to do block writes/reads.
-
-## Old unorganized notes
-
-## Notes on PCA10059 Dongle
-
-- docs: https://infocenter.nordicsemi.com/pdf/nRF52840_Dongle_User_Guide_v1.0.pdf
-
-- Currently using Nordic PCA10059 Dongle hardware
-- https://community.platformio.org/t/same-bootloader-same-softdevice-different-board-different-pins/11411/9
-
-- To make Segger JLink more reliable, turn off its fake filesystem. "JLinkExe MSDDisable" per https://learn.adafruit.com/circuitpython-on-the-nrf52/nrf52840-bootloader
-
-## Done
-
-- DONE add "DFU trigger library" to application load
-- DONE: using this: Possibly use this bootloader? https://github.com/adafruit/Adafruit_nRF52_Bootloader
-- DONE select and install a bootloader (adafruit)
-- DONE get old radio driver working on NRF52
-- DONE basic test of BLE
-- DONE get a debug 'serial' console working via the ICE passthrough feature
-- DONE switch to RadioLab? test it with current radio. https://github.com/jgromes/RadioLib
-- DONE change rx95 to radiolib
-- DONE track rxbad, rxgood, txgood
-- DONE neg 7 error code from receive
-- DONE remove unused sx1262 lib from github
-- at boot we are starting our message IDs at 1, rather we should start them at a random number. also, seed random based on timer. this could be the cause of our first message not seen bug.
-- add a NEMA based GPS driver to test GPS
-- DONE use "variants" to get all gpio bindings
-- DONE plug in correct variants for the real board
-- turn on DFU assistance in the appload using the nordic DFU helper lib call
-- make a new boarddef with a variant.h file. Fix pins in that file. In particular (at least):
-  #define PIN_SPI_MISO (46)
-  #define PIN_SPI_MOSI (45)
-  #define PIN_SPI_SCK (47)
-  #define PIN_WIRE_SDA (26)
-  #define PIN_WIRE_SCL (27)
-- customize the bootloader to use proper button bindings
-- remove the MeshRadio wrapper - we don't need it anymore, just do everything in RadioInterface subclasses.
-- DONE use SX126x::startReceiveDutyCycleAuto to save power by sleeping and briefly waking to check for preamble bits. Change xmit rules to have more preamble bits.
-- scheduleOSCallback doesn't work yet - it is way too fast (causes rapid polling of busyTx, high power draw etc...)
-- find out why we reboot while debugging - it was bluetooth/softdevice
-- make a file system implementation (preferably one that can see the files the bootloader also sees) - preferably https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/master/libraries/InternalFileSytem/examples/Internal_ReadWrite/Internal_ReadWrite.ino else use https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.3.0/lib_fds_usage.html?cp=7_5_0_3_55_3
-- change packet numbers to be 32 bits
-
-```
-
-/*
-per
-https://docs.platformio.org/en/latest/tutorials/nordicnrf52/arduino_debugging_unit_testing.html
-
-ardunino github is here https://github.com/sandeepmistry/arduino-nRF5
-devboard hw docs here:
-https://infocenter.nordicsemi.com/topic/ug_nrf52840_dk/UG/nrf52840_DK/hw_buttons_leds.html?cp=4_0_4_7_6
-
-https://docs.platformio.org/en/latest/boards/nordicnrf52/nrf52840_dk_adafruit.html
-
-must install adafruit bootloader first!
-https://learn.adafruit.com/circuitpython-on-the-nrf52/nrf52840-bootloader
-see link above and turn off jlink filesystem if we see unreliable serial comms
-over USBCDC
-
-adafruit bootloader install commands (from their readme)
-kevinh@kevin-server:~/.platformio/packages/framework-arduinoadafruitnrf52/bootloader$
-nrfjprog -e -f nrf52 Erasing user available code and UICR flash areas. Applying
-system reset.
-kevinh@kevin-server:~/.platformio/packages/framework-arduinoadafruitnrf52/bootloader$
-nrfjprog --program pca10056/pca10056_bootloader-0.3.2_s140_6.1.1.hex -f nrf52
-Parsing hex file.
-Reading flash area to program to guarantee it is erased.
-Checking that the area to write is not protected.
-Programming device.
-kevinh@kevin-server:~/.platformio/packages/framework-arduinoadafruitnrf52/bootloader$
-nrfjprog --reset -f nrf52 Applying system reset. Run.
-
-install jlink tools from here:
-https://www.segger.com/downloads/jlink#J-LinkSoftwareAndDocumentationPack
-
-install nrf tools from here:
-https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Command-Line-Tools/Download#infotabs
-
-examples of turning off the loop call to save power:
-https://learn.adafruit.com/bluefruit-nrf52-feather-learning-guide/advertising-beacon
-
-example of a more complex BLE service:
-https://learn.adafruit.com/bluefruit-nrf52-feather-learning-guide/custom-hrm
-*/
-
-// See g_ADigitalPinMap to see how arduino maps to the real gpio#s - and all in
-// P0
-#define LED1 14
-#define LED2 13
-
-/*
-good led ble demo:
-https://github.com/adafruit/Adafruit_nRF52_Arduino/blob/master/libraries/Bluefruit52Lib/examples/Peripheral/nrf_blinky/nrf_blinky.ino
-*/
-```

docs/software/pinetab.md

@@ -1,27 +0,0 @@
-# Pinetab
-
-These are **preliminary** notes on support for Meshtastic in the Pinetab.
-
-A RF95 is connected via a CS341 USB-SPI chip.
-
-Pin assignments:
-CS0 from RF95 goes to CS0 on CS341
-DIO0 from RF95 goes to INT on CS341
-RST from RF95 goes to RST on CS341
-
-This linux driver claims to provide USB-SPI support: https://github.com/gschorcht/spi-ch341-usb
-Notes here on using that driver: https://www.linuxquestions.org/questions/linux-hardware-18/ch341-usb-to-spi-adaptor-driver-doesn%27t-work-4175622736/
-
-Or if **absolutely** necessary could bitbang: https://www.cnx-software.com/2018/02/16/wch-ch341-usb-to-serial-chip-gets-linux-driver-to-control-gpios-over-usb/
-
-## Task list
-
-* Port meshtastic to build (under platformio) for a poxix target.  spec: no screen, no gpios, sim network interface, posix threads, posix semaphores & queues, IO to the console only
-Use ARM linux: https://platformio.org/platforms/linux_arm
-And  linux native: https://platformio.org/platforms/native
-
-* Test cs341 driver - just test reading/writing a register and detecting interrupts, confirm can see rf95
-* Make a radiolib spi module that targets the cs341 (and builds on linux)
-* use new radiolib module to hook pinebook lora to meshtastic, confirm mesh discovery works
-* Make a subclass of StreamAPI that works as a posix TCP server
-* Use new TCP endpoint from meshtastic-python

docs/software/power.md

@@ -1,92 +0,0 @@
-# Power Management State Machine
-
-i.e. sleep behavior
-
-## Power measurements
-
-Since one of the main goals of this project is long battery life, it is important to consider that in our software/protocol design. Based on initial measurements it seems that the current code should run about three days between charging, and with a bit more software work (see the [TODO list](TODO.md)) a battery life of eight days should be quite doable. Our current power measurements/model is in [this spreadsheet](https://docs.google.com/spreadsheets/d/1ft1bS3iXqFKU8SApU8ZLTq9r7QQEGESYnVgdtvdT67k/edit?usp=sharing).
-
-## States
-
-From lower to higher power consumption.
-
-- Super-deep-sleep (SDS) - everything is off, CPU, radio, bluetooth, GPS. Only wakes due to timer or button press. We enter this mode only after no radio comms for a few hours, used to put the device into what is effectively "off" mode.
-  onEntry: setBluetoothOn(false), call doDeepSleep
-  onExit: (standard bootup code, starts in DARK)
-
-- deep-sleep (DS) - CPU is off, radio is on, bluetooth and GPS is off. Note: This mode is never used currently, because it only saves 1.5mA vs light-sleep
-  (Not currently used)
-
-- light-sleep (LS) - CPU is suspended (RAM stays alive), radio is on, bluetooth is off, GPS is off. Note: currently GPS is not turned
-  off during light sleep, but there is a TODO item to fix this.
-  NOTE: On NRF52 platforms (because CPU current draw is so low), light-sleep state is never used.  
-   onEntry: setBluetoothOn(false), setGPSPower(false), doLightSleep()
-  onIdle: (if we wake because our led blink timer has expired) blink the led then go back to sleep until we sleep for ls_secs
-  onExit: setGPSPower(true), start trying to get gps lock: gps.startLock(), once lock arrives service.sendPosition(BROADCAST)
-
-- No bluetooth (NB) - CPU is running, radio is on, GPS is on but bluetooth is off, screen is off.
-  onEntry: setBluetoothOn(false)
-  onExit:
-
-- running dark (DARK) - Everything is on except screen
-  onEntry: setBluetoothOn(true)
-  onExit:
-
-- full on (ON) - Everything is on
-  onEntry: setBluetoothOn(true), screen.setOn(true)
-  onExit: screen.setOn(false)
-
-- serial API usage (SERIAL) - Screen is on, device doesn't sleep, bluetooth off
-  onEntry: setBluetooth off, screen on
-  onExit:
-
-## Behavior
-
-### events that increase CPU activity
-
-- At cold boot: The initial state (after setup() has run) is DARK
-- While in DARK: if we receive EVENT_BOOT, transition to ON (and show the bootscreen). This event will be sent if we detect we woke due to reset (as opposed to deep sleep)
-- While in LS: Once every position_broadcast_secs (default 15 mins) - the unit will wake into DARK mode and broadcast a "networkPing" (our position) and stay alive for wait_bluetooth_secs (default 30 seconds). This allows other nodes to have a record of our last known position if we go away and allows a paired phone to hear from us and download messages.
-- While in LS: Every send*owner_interval (defaults to 4, i.e. one hour), when we wake to send our position we \_also* broadcast our owner. This lets new nodes on the network find out about us or correct duplicate node number assignments.
-- While in LS/NB/DARK: If the user presses a button (EVENT_PRESS) we go to full ON mode for screen_on_secs (default 30 seconds). Multiple presses keeps resetting this timeout
-- While in LS/NB/DARK: If we receive new text messages (EVENT_RECEIVED_TEXT_MSG), we go to full ON mode for screen_on_secs (same as if user pressed a button)
-- While in LS: while we receive packets on the radio (EVENT_RECEIVED_PACKET) we will wake and handle them and stay awake in NB mode for min_wake_secs (default 10 seconds)
-- While in NB: If we do have packets the phone (EVENT_PACKETS_FOR_PHONE) would want we transition to DARK mode for wait_bluetooth secs.
-- While in DARK/ON: If we receive EVENT_BLUETOOTH_PAIR we transition to ON and start our screen_on_secs timeout
-- While in NB/DARK/ON: If we receive EVENT_NODEDB_UPDATED we transition to ON (so the new screen can be shown)
-- While in DARK: While the phone talks to us over BLE (EVENT_CONTACT_FROM_PHONE) reset any sleep timers and stay in DARK (needed for bluetooth sw update and nice user experience if the user is reading/replying to texts)
-- while in LS/NB/DARK: if SERIAL_CONNECTED, go to serial
-
-### events that decrease cpu activity
-
-- While in SERIAL: if SERIAL_DISCONNECTED, go to NB
-- While in ON: If PRESS event occurs, reset screen_on_secs timer and tell the screen to handle the pess
-- While in ON: If it has been more than screen_on_secs since a press, lower to DARK
-- While in DARK: If time since last contact by our phone exceeds phone_timeout_secs (15 minutes), we transition down into NB mode
-- While in DARK or NB: If nothing above is forcing us to stay in a higher mode (wait_bluetooth_secs, min_wake_secs) we will lower down to LS state
-- While in LS: If either phone_sds_timeout_secs (default 2 hr) or mesh_sds_timeout_secs (default 2 hr) are exceeded we will lower into SDS mode for sds_secs (default 1 yr) (or a button press). (Note: phone_sds_timeout_secs is currently disabled for now, because most users
-  are using without a phone)
-- Any time we enter LS mode: We stay in that until an interrupt, button press or other state transition. Every ls_secs (default 1 hr) and let the arduino loop() run one iteration (FIXME, not sure if we need this at all), and then immediately reenter lightsleep mode on the CPU.
-
-TODO: Eventually these scheduled intervals should be synchronized to the GPS clock, so that we can consider leaving the lora receiver off to save even more power.
-TODO: In NB mode we should put cpu into light sleep any time we really aren't that busy (without declaring LS state) - i.e. we should leave GPS on etc...
-
-# Low power consumption tasks
-
-General ideas to hit the power draws our spreadsheet predicts. Do the easy ones before beta, the last 15% can be done after 1.0.
-
-- don't even power on the gps until someone else wants our position, just stay in lora deep sleep until press or rxpacket (except for once an hour updates)
-- (possibly bad idea - better to have lora radio always listen - check spreadsheet) have every node wake at the same tick and do their position syncs then go back to deep sleep
-- lower BT announce interval to save battery
-- change to use RXcontinuous mode and config to drop packets with bad CRC (see section 6.4 of datasheet) - I think this is already the case
-- have mesh service run in a thread that stays blocked until a packet arrives from the RF95
-- platformio sdkconfig CONFIG_PM and turn on modem sleep mode
-- keep cpu 100% in deepsleep until irq from radio wakes it. Then stay awake for 30 secs to attempt delivery to phone.
-- use https://lastminuteengineers.com/esp32-sleep-modes-power-consumption/ association sleep pattern to save power - but see https://github.com/espressif/esp-idf/issues/2070 and https://esp32.com/viewtopic.php?f=13&t=12182 it seems with BLE on the 'easy' draw people are getting is 80mA
-- stop using loop() instead use a job queue and let cpu sleep
-- measure power consumption and calculate battery life assuming no deep sleep
-- do lowest sleep level possible where BT still works during normal sleeping, make sure cpu stays in that mode unless lora rx packet happens, bt rx packet happens or button press happens
-- optionally do lora messaging only during special scheduled intervals (unless nodes are told to go to low latency mode), then deep sleep except during those intervals - before implementing calculate what battery life would be with this feature
-- see section 7.3 of https://cdn.sparkfun.com/assets/learn_tutorials/8/0/4/RFM95_96_97_98W.pdf and have hope radio wake only when a valid packet is received. Possibly even wake the ESP32 from deep sleep via GPIO.
-- never enter deep sleep while connected to USB power (but still go to other low power modes)
-- when main cpu is idle (in loop), turn cpu clock rate down and/or activate special sleep modes. We want almost everything shutdown until it gets an interrupt.

docs/software/ramusage-nrf52.txt

@@ -1,202 +0,0 @@
-23K + messages
-+ heap of 70ish packets, 300ish bytes per packet: 20KB
-+ 14KB soft device RAM 
-
-With max length Data inside the packet
-Size of NodeInfo 104
-Size of SubPacket 272
-Size of MeshPacket 304
-
-If Data was smaller: for 70 data packets we would save 7KB.  We would need to make SubPacket.data and MeshPacket.encrypted into "type:FT_POINTER" - variably sized mallocs
-Size of NodeInfo 104
-Size of SubPacket 96
-Size of MeshPacket 292 (could have been much smaller but I forgot to shrink MeshPacket.encrypted)
-
-therefore: 
-a) we should store all ToPhone message queued messages compressed as protobufs (since they will become that anyways)
-b) shrink packet pool size because none of that storage will be used for ToPhone packets
-c) don't allocate any storage in RAM for the tophone messages we save inside device state, instead just use nanopb callbacks to save/load those
-d) a smarter MeshPacket in memory representation would save about 7KB of RAM.  call pb_release before freeing each freshly malloced MeshPacket
-
-- nrf52 free memory https://learn.adafruit.com/bluefruit-nrf52-feather-learning-guide/hathach-memory-map
-
-2000790c 00003558 B devicestate  // 16KB
-2000b53c 00001000 b _cache_buffer // 4KB flash filesystem support 
-20003b1c 000006b0 B console
-2000d5f4 00000400 b vApplicationGetTimerTaskMemory::uxTimerTaskStack
-2000da04 00000400 b _acUpBuffer
-2000c558 0000036c B Bluefruit
-2000c8d8 00000358 b _cdcd_itf
-2000e54c 00000258 B _midid_itf
-2000d0dc 00000200 b ucStaticTimerQueueStorage.9390
-2000e044 00000200 b _mscd_buf
-2000e284 000001cc b _vendord_itf
-2000d410 00000190 b vApplicationGetIdleTaskMemory::uxIdleTaskStack
-2000374c 0000016c D __global_locale
-2000de48 0000012c B USBDevice
-2000afa4 00000100 b Router::send(_MeshPacket*)::bytes
-2000aea4 00000100 b Router::perhapsDecode(_MeshPacket*)::bytes
-200039b0 000000f4 B powerFSM
-20004258 000000f0 B screen
-2000cd7c 000000c4 b _dcd
-2000cc68 000000c0 b _usbd_qdef_buf
-2000b3c4 000000bc B Wire
-2000cef4 000000a8 B Serial2
-2000ce4c 000000a8 B Serial1
-2000e498 000000a8 B _SEGGER_RTT
-2000b498 000000a4 B InternalFS
-2000dfb8 0000008c b _hidd_itf
-2000b260 00000088 b meshtastic::normalFrames
-2000cfdc 00000064 b pxReadyTasksLists
-2000b340 00000060 b meshtastic::drawTextMessageFrame(OLEDDisplay*, OLEDDisplayUiState*, short, short)::tempBuf
-200036ec 00000060 d impure_data
-2000b104 00000060 B bledfu
-2000b0a4 00000060 B blebas
-20003684 00000058 D _usbd_qdef
-200038c0 00000058 d tzinfo
-2000d5a0 00000054 b vApplicationGetTimerTaskMemory::xTimerTaskTCB
-2000d3bc 00000054 b vApplicationGetIdleTaskMemory::xIdleTaskTCB
-2000d308 00000050 b xStaticTimerQueue.9389
-2000b1f4 00000050 B hrmc
-2000b1a4 00000050 B bslc
-20004360 0000004c B service
-2000d374 00000048 b m_cb
-2000df74 00000042 b _desc_str
-2000cd3c 00000040 b _usbd_ctrl_buf
-20004214 00000040 B realRouter
-2000e244 00000040 b _mscd_itf
-2000b164 00000040 B bledis
-20003634 00000038 d _InternalFSConfig
-2000cc30 00000031 b _usbd_dev
-2000398c 00000020 B periodicScheduler
-2000cfa4 00000020 b callbacksInt
-2000de10 0000001f b fw_str.13525
-20003974 00000018 b object.9934
-2000ae68 00000018 B nodeDB
-2000366c 00000018 d _cache
-2000b314 00000014 b meshtastic::drawNodeInfo(OLEDDisplay*, OLEDDisplayUiState*, short, short)::signalStr
-2000b300 00000014 b meshtastic::drawNodeInfo(OLEDDisplay*, OLEDDisplayUiState*, short, short)::lastStr
-2000b2ec 00000014 b meshtastic::drawNodeInfo(OLEDDisplay*, OLEDDisplayUiState*, short, short)::distStr
-200041e0 00000014 b getDeviceName()::name
-2000d0b8 00000014 b xTasksWaitingTermination
-2000d0a4 00000014 b xSuspendedTaskList
-2000d08c 00000014 b xPendingReadyList
-2000d06c 00000014 b xDelayedTaskList2
-2000d058 00000014 b xDelayedTaskList1
-2000d2f0 00000014 b xActiveTimerList2
-2000d2dc 00000014 b xActiveTimerList1
-2000b480 00000014 B SPI
-2000c8c4 00000014 B Serial
-2000cd28 00000014 b _ctrl_xfer
-2000de30 00000011 b serial_str.13534
-2000c544 00000010 b BLEAdvertising::_start(unsigned short, unsigned short)::gap_adv
-20003614 00000010 d meshtastic::btPIN
-2000434c 00000010 b sendOwnerPeriod
-2000ae8c 00000010 b staticPool
-2000e484 00000010 B xQueueRegistry
-20003b04 00000010 B stateSERIAL
-20003af4 00000010 B stateSDS
-20003ae4 00000010 B stateON
-20003ad4 00000010 B stateNB
-20003ac4 00000010 B stateLS
-20003ab4 00000010 B stateDARK
-20003aa4 00000010 B stateBOOT
-200041f8 00000010 B ledPeriodic
-2000b244 00000010 B hrms
-2000d9f4 00000010 b _acDownBuffer
-2000b3b8 0000000c B preflightSleep
-20004208 0000000c B powerStatus
-2000e540 0000000c B nrf_nvic_state
-2000b3ac 0000000c B notifySleep
-2000b3a0 0000000c B notifyDeepSleep
-2000e463 0000000b b __tzname_std
-2000e458 0000000b b __tzname_dst
-2000b338 00000008 b meshtastic::estimatedHeading(double, double)::oldLon
-2000b330 00000008 b meshtastic::estimatedHeading(double, double)::oldLat
-200041d0 00000008 b zeroOffsetSecs
-2000ae80 00000008 b spiSettings
-200038b8 00000008 D _tzname
-20003b14 00000008 B noopPrint
-2000cfc4 00000008 b channelMap
-2000cf9c 00000008 b callbackDeferred
-200043ac 00000006 b ourMacAddr
-2000435c 00000004 b MeshService::onGPSChanged(void*)::lastGpsSend
-2000b32c 00000004 b meshtastic::estimatedHeading(double, double)::b
-2000b328 00000004 b meshtastic::drawNodeInfo(OLEDDisplay*, OLEDDisplayUiState*, short, short)::simRadian
-2000362c 00000004 d meshtastic::Screen::setup()::bootFrames
-20003628 00000004 d meshtastic::Screen::handleStartBluetoothPinScreen(unsigned long)::btFrames
-200039ac 00000004 b onEnter()::lastPingMs
-2000ae9c 00000004 b generatePacketId()::i
-2000ae88 00000004 B RadioLibInterface::instance
-2000b2e8 00000004 b meshtastic::nodeIndex
-20003610 00000004 d meshtastic::targetFramerate
-2000c554 00000004 B BLEService::lastService
-200041cc 00000004 b timeStartMsec
-200036dc 00000004 d sbrk_heap_top
-2000d364 00000004 b _loopHandle
-2000c540 00000004 b guard variable for BLEAdvertising::_start(unsigned short, unsigned short)::gap_adv
-2000d0d0 00000004 b xYieldPending
-2000d35c 00000004 b xTimerTaskHandle
-2000d358 00000004 b xTimerQueue
-2000d0cc 00000004 b xTickCount
-2000d0a0 00000004 b xSchedulerRunning
-2000d088 00000004 b xNumOfOverflows
-2000d084 00000004 b xNextTaskUnblockTime
-2000d304 00000004 b xLastTime.9343
-2000d080 00000004 b xIdleTaskHandle
-2000d054 00000004 b uxTopReadyPriority
-2000d050 00000004 b uxTaskNumber
-2000d04c 00000004 b uxSchedulerSuspended
-2000d048 00000004 b uxPendedTicks
-2000d044 00000004 b uxDeletedTasksWaitingCleanUp
-2000d040 00000004 b uxCurrentNumberOfTasks
-2000d360 00000004 b uxCriticalNesting
-2000cc64 00000004 b _usbd_q
-2000e478 00000004 B _timezone
-200036e0 00000004 D SystemCoreClock
-2000c53c 00000004 b _sem
-2000d0d8 00000004 b pxOverflowTimerList
-2000cfd8 00000004 b pxOverflowDelayedTaskList
-2000cfd4 00000004 b pxDelayedTaskList
-2000d0d4 00000004 b pxCurrentTimerList
-2000cfd0 00000004 B pxCurrentTCB
-2000e470 00000004 b prev_tzenv
-2000360c 00000004 D preftmp
-20003608 00000004 D preffile
-2000b25c 00000004 B nrf52Bluetooth
-2000d370 00000004 b m_usbevt_handler
-2000d36c 00000004 b m_sleepevt_handler
-2000d368 00000004 b m_pofwarn_handler
-2000e454 00000004 B __malloc_sbrk_start
-2000e450 00000004 B __malloc_free_list
-2000e480 00000004 B MAIN_MonCnt
-2000e47c 00000004 b initial_env
-200036e8 00000004 D _impure_ptr
-200041d8 00000004 B gps
-2000e7a4 00000004 B errno
-20003918 00000004 D environ
-2000cfcc 00000004 b enabled
-2000ae64 00000004 B displayedNodeNum
-2000e474 00000004 B _daylight
-2000b254 00000004 B crypto
-2000ce44 00000004 B count_duration
-2000de0c 00000004 b _cb_task
-2000de08 00000004 b _cb_queue
-2000de04 00000004 b _cb_qdepth
-2000de44 00000004 B bootloaderVersion
-200041f5 00000001 b ledBlinker()::ledOn
-20003604 00000001 d loop::showingBootScreen
-200041f4 00000001 b loop::wasPressed
-2000b494 00000001 b DefaultFontTableLookup(unsigned char)::LASTCHAR
-2000aea0 00000001 b generatePacketId()::didInit
-20003624 00000001 d meshtastic::prevFrame
-2000b258 00000001 b bleOn
-200041dc 00000001 B timeSetFromGPS
-20004348 00000001 B ssd1306_found
-2000ce49 00000001 B pin_sound
-2000e494 00000001 B nrfx_power_irq_enabled
-2000ce48 00000001 B no_stop
-20003630 00000001 D neo6M
-2000ce40 00000001 b _initialized
-200036e4 00000001 D __fdlib_version
-20003970 00000001 b completed.9929

docs/software/sw-design.md

@@ -1,9 +0,0 @@
-This is a mini design doc for developing the meshtastic software.
-
-* [Build instructions](build-instructions.md)
-* [TODO](TODO.md) - read this if you are looking for things to do (or curious about currently missing features)
-* Our [project board](https://github.com/orgs/meshtastic/projects/1) - shows what things we are currently working on and remaining work items for the current release.
-* [Power Management](power.md)
-* [Mesh algorithm](mesh-alg.md)
-* [Bluetooth API](bluetooth-api.md) and porting guide for new clients (iOS, python, etc...)
-* TODO: how to port the device code to a new device.

geeksville-private/TODO.md

@@ -0,0 +1,353 @@
+# Geeksville's current work queue
+
+You probably don't care about this section - skip to the next one.
+
+* usb lora dongle from pine64, add end user instructions
+* measure rak4630 power draw and turn off power for GPS most of the time.  We should be able to run on the small solar panel.
+* turn on watchdog reset if app hangs on nrf52 or esp32
+* pine64 solar boards
+* for the matrix gateway?  recommended by @sam-uk https://github.com/matrix-org/coap-proxy
+* figure our wss for mqtt.meshtastic - use cloudflare? 2052 ws, 2053 crypt
+* ask for vercel access
+* finish plan for riot.im
+* turn on setTx(timeout) and   state = setDioIrqParams(SX126X_IRQ_TX_DONE | SX126X_IRQ_TIMEOUT, SX126X_IRQ_TX_DONE | SX126X_IRQ_TIMEOUT); in sx1262 code
+* NO add rak4600 support (with rf95 radio and limited ram)
+* store esp32 crashes to flash (and 64KB coredump partition) - https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/core_dump.html
+* If more nodes appear than the nodedb can hold, delete oldest entries from DB
+* send debug info 'in-band'
+* DONE @luxonn reports that after a while the android app stops showing new messages
+* DONE release android APK - fix recent 1.2.28 crash report
+* DONE remote admin busted? 
+* DONE check android code - @havealoha comments about odd sleep behavior
+* ABANDONED test github actions locally on linux
+* DONE fix github actions per sasha tip
+* tell ttgo to preinstall new bins
+* DONE sendtext busted in portduino, due to bytetime calculations
+* remove linux dependency in native build
+* DONE tcp stream problem in python+pordtuino, server thinks client dropped when client DID NOT DROP
+* DONE TCP mode for android, localhost is at 10.0.2.2
+* DONE make sure USB still works in android
+* add license to portduino and make announcement
+* DONE naks are being dropped (though enqueuedLocal) sometimes before phone/PC gets them
+* DONE have android fill in if local GPS has poor signal
+* optionally restrict position sends to a named channel
+* release to beta and amazon
+* add reference counting to mesh packets
+* allow multiple simultanteous phoneapi connections
+* DONE split position.time and last_heard
+* DONE update android app to use last_heard
+* DONE turn off bluetooth interface ENTIRELY while using serial API (was python client times out on connect sometimes)
+* DONE gps assistance from phone not working?
+* DONE test latest firmware update with is_router
+* DONE firmware OTA updates of is_router true nodes fails?
+* DONE add UI in android app to reset to defaults https://github.com/meshtastic/Meshtastic-Android/issues/263 
+* DONE TEST THIS! changing channels requires a reboot to take effect https://github.com/meshtastic/Meshtastic-device/issues/752 
+* DONE bug report with remote info request timing out
+* DONE retest channel changing in android (using sim?)
+* DONE move remote admin doc from forum into git
+* DONE check crashlytics
+* DONE ask for a documentation czar
+* DONE timestamps on oled screen are wrong - don't seem to be updating based on message rx (actually: this is expected behavior when no node on the mesh has GPS time)
+* DONE add ch-del
+* DONE channel hash suffixes are wrong on android
+* DONE before next relase: test empty channel sets on android
+* DONE channel sharing in android
+* DONE test 1.0 firmware update on android
+* DONE test 1.1 firmwhttps://github.com/meshtastic/Meshtastic-Android/issues/271are update on android
+* DONE test 1.2.10 firmware update on android
+* DONE test link sharing on android
+* FIXED? luxon bug report - seeing rx acks for nodes that are not on the network
+* DONE release py
+* DONE show GPS time only if we know what global time is
+* DONE android should always provide time to nodes - so that it is easier for the mesh to learn the current time
+
+## Multichannel support
+
+* DONE cleanup the external notification and serial plugins
+* non ack version of stress test fails sometimes!
+* tx fault test has a bug #734 - * turn off fault 8: https://github.com/meshtastic/Meshtastic-device/issues/734
+* DONE move device types into an enum in nodeinfo
+* DONE fix android to use new device types for firmware update
+* nrf52 should preserve local time across reset
+* cdcacm bug on nrf52: emittx thinks it emitted but client sees nothing.  works again later
+* nrf52: segger logs have errors in formatting that should be impossible (because not going through serial, try stalling on segger)
+* DONE call RouterPlugin for *all* packets - not just Router packets
+* DONE generate channel hash from the name of the channel+the psk (not just one or the other)
+* DONE send a hint that can be used to select which channel to try and hash against with each message
+* DONE remove deprecated
+* DONE fix setchannel in phoneapi.cpp
+* DONE set mynodeinfo.max_channels
+* DONE set mynodeinfo.num_bands (formerly num_channels)
+* DONE fix sniffing of non Routing packets
+* DONE enable remote setttings access by moving settings operations into a regular plugin (move settings ops out of PhoneAPI)
+* DONE move portnum up?
+* DONE remove region specific builds from the firmware
+* DONE test single channel without python
+* DONE Use "default" for name if name is empty
+* DONE fix python data packet receiving (nothing showing in log?)
+* DONE implement 'get channels' Admin plugin operation
+* DONE use get-channels from python
+* DONE use get channels & get settings from android
+* DONE use set-channel from python
+* DONE make settings changes from python work
+* DONE pthon should stop fetching channels once we've reached our first empty channel definition (hasSettings == true)
+* DONE add check for old devices with new API library
+* DONE release python api
+* DONE release protobufs
+* DONE release to developers
+* DONE fix setch-fast in python tool
+* age out pendingrequests in the python API
+* DONE stress test channel download from python, sometimes it seems like we don't get all replies, bug was due to simultaneous android connection
+* DONE combine acks and responses in a single message if possible (do routing plugin LAST and drop ACK if someone else has already replied)
+* DONE don't send packets we received from the phone BACK TOWARDS THE PHONE (possibly use fromnode 0 for packets the phone sends?)
+* DONE fix 1.1.50 android debug panel display
+* DONE test android channel setting
+* DONE release to users
+* DONE warn in android app about unset regions
+* DONE use set-channel from android
+* DONE add gui in android app for setting region
+* DONE clean up python channel usage
+* DONE use bindToChannel to limit admin access for remote nodes
+* DONE move channels and radio config out of device settings
+* DONE test remote info and remote settings changes
+* make python tests more exhaustive
+* DONE pick default random admin key
+* exclude admin channels from URL?
+* make a way to share just secondary channels via URL
+* generalize the concept of "shortstrings" use it for both PSKs and well known channel names.  Possibly use a ShortString class.
+* use single byte 'well known' channel names for admin, gpio, etc...
+* use presence of gpio channel to enable gpio ops, same for serial etc...
+* DONE restrict gpio & serial & settings operations to the admin channel (unless local to the current node)
+* DONE add channel restrictions for plugins (and restrict routing plugin to the "control" channel)
+* stress test multi channel
+* DONE investigate @mc-hamster report of heap corruption
+* DONE use set-user from android
+* untrusted users should not be allowed to provide bogus times (via position broadcasts) to the rest of the mesh.  Invent a new lowest quality notion of UntrustedTime.
+* use portuino TCP connection to debug with python API
+* document the relationship between want_response (indicating remote node received it) and want_ack (indicating that this message should be sent reliably - and also get acks from the first rx node and naks if it is never delivered)
+* DONE android should stop fetching channels once we've reached our first empty channel definition (hasSettings == true)
+* DONE warn in python api if we are too new to talk to the device code
+* DONE make a post warning about 1.2, telling how to stay on old android & python clients.  link to this from the android dialog message and python version warning.
+* DONE "FIXME - move the radioconfig/user/channel READ operations into SettingsMessage as well"
+* DONE scrub protobufs to make sure they are absoloute minimum wiresize (in particular Data, ChannelSets and positions)
+* DONE change syncword (now ox2b)
+* allow chaning packets in single transmission - to increase airtime efficiency and amortize packet overhead
+* DONE move most parts of meshpacket into the Data packet, so that we can chain multiple Data for sending when they all have a common destination and key.
+* when selecting a MeshPacket for transmit, scan the TX queue for any Data packets we can merge together as a WirePayload.  In the low level send/rx code expand that into multiple MeshPackets as needed (thus 'hiding' from MeshPacket that over the wire we send multiple datapackets
+* DONE confirm we are still calling the plugins for messages inbound from the phone (or generated locally)
+* DONE confirm we are still multi hop routing flood broadcasts
+* DONE confirm we are still doing resends on unicast reliable packets
+* add history to routed packets: https://meshtastic.discourse.group/t/packet-source-tracking/2764/2
+* add support for full DSR unicast delivery
+* DONE move acks into routing
+* DONE make all subpackets different versions of data
+* DONE move routing control into a data packet
+* have phoneapi done via plugin (will allow multiple simultaneous API clients - stop disabling BLE while using phone API)
+* use reference counting and dynamic sizing for meshpackets. - use https://docs.microsoft.com/en-us/cpp/cpp/how-to-create-and-use-shared-ptr-instances?view=msvc-160 (already used in arduino)
+* let multiple PhoneAPI endpoints work at once
+* allow multiple simultaneous bluetooth connections (create the bluetooth phoneapi instance dynamically based on client id)
+* DONE figure out how to add micro_delta to position, make it so that phone apps don't need to understand it?
+* only send battery updates a max of once a minute
+* DONE add python channel selection for sending
+* DONE record recevied channel in meshpacket
+* test remote settings operations (confirm it works 3 hops away)
+* DONE make a primaryChannel global and properly maintain it when the phone sends setChannel
+* DONE move setCrypto call into packet send and packet decode code
+* implement 'small location diffs' change
+* move battery level out of position? 
+* consider "A special exception (FIXME, not sure if this is a good idea) - packets that arrive on the local interface 
+  are allowed on any channel (this lets the local user do anything)."  Probably by adding a "secure_local_interface" settings bool.
+* DOUBLE CHECK android app can still upgrade 1.1 and 1.0 loads
+ 
+For app cleanup:
+
+* don't store redundant User admin or position broadcasts in the ToPhone queue (only keep one per sending node per proto type, and only most recent)
+* use structured logging to kep logs in ram.  Also send logs as packets to api clients
+* DONE writeup nice python options docs (common cases, link to protobuf docs)
+* have android app link to user manual
+* DONE only do wantReplies once per packet type, if we change network settings force it again
+* update positions and nodeinfos based on packets we just merely witness on the mesh.  via isPromsciousPort bool, remove sniffing
+* DONE make device build always have a valid version
+* DONE do fixed position bug https://github.com/meshtastic/Meshtastic-device/issues/536
+* DONE check build guide
+* DONE write devapi user guide
+* DONE update android code: https://developer.android.com/topic/libraries/view-binding/migration
+* DONE test GPIO watch
+* DONE set --set-chan-fast, --set-chan-default
+* writeup docs on gpio 
+* DONE make python ping command
+* DONE make hello world example service
+* DONE have python tool check max packet size before sending to device
+* DONE if request was sent reliably, send reply reliably
+* DONE require a recent python api to talk to these new device loads
+* DONE require a recent android app to talk to these new device loads
+* DONE fix handleIncomingPosition
+* DONE move want_replies handling into plugins
+* DONE on android for received positions handle either old or new positions / user messages
+* DONE on android side send old or new positions as needed / user messages
+* DONE test python side handle new position/user messages
+* DONE make a gpio example. --gpiowrb 4 1, --gpiord 0x444, --gpiowatch 0x3ff
+* DONE fix position sending to use new plugin
+* DONE Add SinglePortNumPlugin - as the new most useful baseclass
+* DONE move positions into regular data packets (use new app framework)
+* DONE move user info into regular data packets (use new app framework)
+* DONE test that positions, text messages and user info still work
+* DONE test that position, text messages and user info work properly with new android app and old device code
+* DONE do UDP tunnel
+* DONE fix the RTC drift bug
+* move python ping functionality into device, reply with rxsnr info
+* use channels for gpio security https://github.com/meshtastic/Meshtastic-device/issues/104
+* MeshPackets for sending should be reference counted so that API clients would have the option of checking sent status (would allow removing the nasty 30 sec timer in gpio watch sending)
+
+For high speed/lots of devices/short range tasks:
+
+- When guessing numhops for sending: if I've heard from many local (0 hop neighbors) decrease hopcount by 2 rather than 1. 
+This should nicely help 'router' nodes do the right thing when long range, or if there are many local nodes for short range.
+- fix timeouts/delays to be based on packet length at current radio settings
+
+* update faq with antennas https://meshtastic.discourse.group/t/range-test-ideas-requested/738/2
+* update faq on recommended android version and phones
+* add help link inside the app, reference a page on the wiki
+* turn on amazon reviews support
+* add a tablet layout (with map next to messages) in the android app
+
+# Completed
+
+## eink 1.0
+
+* DONE check email of reported issues
+* DONE turn off vbus driving (in bootloader)
+* new battery level sensing
+* current draw no good
+* DONE: fix backlight
+* DONE - USB is busted because of power enable mode?
+* test CPU voltage? something is bad with RAM (removing eink module does not help)
+* test that board leaves bootloader always
+* test USB - works in bootloader
+* test LEDs
+* Test BME280
+* test gps
+* check GPS fast locking
+* tested! dlora
+* test eink backlight
+* tested! eink
+* test buttons
+* test battery charging
+* test serial flash
+* send updated app and bootloader image
+* OHH BME280!  THAT IS GREAT!
+* make new screen work, ask for datasheet
+* say I think you could ship this
+* leds seem busted
+* fix hw_model: "nrf52unknown"
+* use larger icon for meshtastic logo
+* send email about variants & faster flash programming - https://github.com/geeksville/Meshtastic-esp32/commit/f110225173a77326aac029321cdb6491bfa640f6
+* send PR for bootloader
+* fix nrf52 time/date
+* send new master bin file
+* send email about low power mode problems
+* support new flash chip in appload, possibly use low power mode
+* swbug! stuck busy tx occurred!
+  
+# Old docs to merge
+
+MESH RADIO PROTOCOL
+
+Old TODO notes on the mesh radio protocol, merge into real docs someday...
+
+for each named group we have a pre-shared key known by all group members and
+wrapped around the device. you can only be in one group at a time (FIXME?!) To
+join the group we read a qr code with the preshared key and ParamsCodeEnum. that
+gets sent via bluetooth to the device.  ParamsCodeEnum maps to a set of various
+radio params (regulatory region, center freq, SF, bandwidth, bitrate, power
+etc...) so all members of the mesh can have their radios set the same way.
+
+once in that group, we can talk between 254 node numbers.
+to get our node number (and announce our presence in the channel) we pick a
+random node number and broadcast as that node with WANT-NODENUM(my globally
+unique name).  If anyone on the channel has seen someone _else_ using that name
+within the last 24 hrs(?) they reply with DENY-NODENUM. Note: we might receive
+multiple denies.  Note: this allows others to speak up for some other node that
+might be saving battery right now. Any time we hear from another node (for any
+message type), we add that node number to the unpickable list.  To dramatically
+decrease the odds a node number we request is already used by someone. If no one
+denies within TBD seconds, we assume that we have that node number.  As long as
+we keep talking to folks at least once every 24 hrs, others should remember we
+have it.
+
+Once we have a node number we can broadcast POSITION-UPDATE(my globally unique
+name, lat, lon, alt, amt battery remaining).  All receivers will use this to a)
+update the mapping of who is at what node nums, b) the time of last rx, c)
+position.  If we haven't heard from that node in a while we reply to that node
+(only) with our current POSITION_UPDATE state - so that node (presumably just
+rejoined the network) can build a map of all participants.
+
+We will periodically broadcast POSITION-UPDATE as needed based on distance moved
+or a periodic minimum heartbeat.
+
+If user wants to send a text they can SEND_TEXT(dest user, short text message).
+Dest user is a node number, or 0xff for broadcast.
+
+# Medium priority
+
+Items to complete before 1.0.
+
+# Post 1.0 ideas
+
+- finish DSR for unicast
+- check fcc rules on duty cycle. we might not need to freq hop. https://www.sunfiretesting.com/LoRa-FCC-Certification-Guide/ . Might need to add enforcement for europe though.
+- make a no bluetooth configured yet screen - include this screen in the loop if the user hasn't yet paired
+- if radio params change fundamentally, discard the nodedb
+- re-enable the bluetooth battery level service on the T-BEAM
+- provide generalized (but slow) internet message forwarding service if one of our nodes has internet connectivity (MQTT) [ Not a requirement but a personal interest ]
+
+# Low priority ideas
+
+Items after the first final candidate release.
+
+- implement nimble battery level service
+- Nimble implement device info service remaining fields (hw version etc)
+- Turn on RPA addresses for the device side in Nimble
+- Try to teardown less of the Nimble protocol stack across sleep
+- dynamic frequency scaling could save a lot of power on ESP32, but it seems to corrupt uart (even with ref_tick set correctly)
+- Change back to using a fixed sized MemoryPool rather than MemoryDynamic (see bug #149)
+- scan to find channels with low background noise? (Use CAD mode of the RF95 to automatically find low noise channels)
+- If the phone doesn't read fromradio mailbox within X seconds, assume the phone is gone and we can stop queing location msgs
+  for it (because it will redownload the nodedb when it comes back)
+- add frequency hopping, dependent on the gps time, make the switch moment far from the time anyone is going to be transmitting
+- assign every "channel" a random shared 8 bit sync word (per 4.2.13.6 of datasheet) - use that word to filter packets before even checking CRC. This will ensure our CPU will only wake for packets on our "channel"
+- the BLE stack is leaking about 200 bytes each time we go to light sleep
+- use fuse bits to store the board type and region. So one load can be used on all boards
+- Don't store position packets in the to phone fifo if we are disconnected. The phone will get that info for 'free' when it
+  fetches the fresh nodedb.
+- Use the RFM95 sequencer to stay in idle mode most of the time, then automatically go to receive mode and automatically go from transmit to receive mode. See 4.2.8.2 of manual.
+- Use fixed32 for node IDs, packetIDs, successid, failid, and lat/lon - will require all nodes to be updated, but make messages slightly smaller.
+- add "store and forward" support for messages, or move to the DB sync model. This would allow messages to be eventually delivered even if nodes are out of contact at the moment.
+- use variable length Strings in protobufs (instead of current fixed buffers). This would save lots of RAM
+- use BLEDevice::setPower to lower our BLE transmit power - extra range doesn't help us, it costs amps and it increases snoopability
+- make a Ham build: just a new frequency list, a bool to say 'never do encryption' and use the callsign as that node's unique id. -from Girts
+- don't forward redundant pings or ping responses to the phone, it just wastes phone battery
+- don't send location packets if we haven't moved significantly
+- scrub default radio config settings for bandwidth/range/speed
+- show radio and gps signal strength as an image
+- only BLE advertise for a short time after the screen is on and button pressed - to save power and prevent people for sniffing for our BT app.
+- make mesh aware network timing state machine (sync wake windows to gps time) - this can save LOTS of battery
+- split out the software update utility so other projects can use it. Have the appload specify the URL for downloads.
+- read the PMU battery fault indicators and blink/led/warn user on screen
+- discard very old nodedb records (> 1wk)
+- handle millis() rollover in GPS.getTime - otherwise we will break after 50 days
+- report esp32 device code bugs back to the mothership via android
+- change BLE bonding to something more secure. see comment by pSecurity->setAuthenticationMode(ESP_LE_AUTH_BOND)
+
+Changes related to wifi support on ESP32:
+
+- iram space: https://esp32.com/viewtopic.php?t=8460
+- set https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/external-ram.html spi ram bss
+- figure out if iram or bluetooth classic caused ble problems
+- post bug on esp32-arduino with BLE bug findings
+
+# Spinoff project ideas
+
+- an open source version of https://www.burnair.ch/skynet/
+- a paragliding app like http://airwhere.co.uk/
+- How do avalanche beacons work? Could this do that as well? possibly by using beacon mode feature of the RF95?

geeksville-private/bl602.md

@@ -0,0 +1,25 @@
+
+* nutcracker https://www.pine64.org/2020/10/28/nutcracker-challenge-blob-free-wifi-ble/
+* https://github.com/pine64/bl_iot_sdk
+* https://github.com/pine64/bl602-docs / https://pine64.github.io/bl602-docs/
+* https://github.com/pine64/ArduinoCore-bouffalo 
+
+
+cd ~/packages
+git clone --recursive https://github.com/pine64/bl_iot_sdk
+
+https://github.com/spacemeowx2/blflash/releases
+
+
+# FIXME or BL604
+cd bl_iot_sdk
+export BL60X_SDK_PATH=/home/kevinh/packages/bl_iot_sdk
+export CONFIG_CHIP_NAME=BL602
+cd customer_app/bl602_boot2
+make
+
+* todo run hello world on hardware (check for bl604 vs bl602 first)
+* build/run in the crummy arduino environment
+* build in platformio
+
+https://lupyuen.github.io/articles/lorawan2

geeksville-private/pine64.md

@@ -0,0 +1,51 @@
+# Notes on the pine64 lora board
+
+like before but sx1262 based?
+
+Since both DIO3 and DIO2 not apply to PINE64 LoRa situation, I will wire SX1262 INT [DIO1] pin, contact to CS341F pin 7 INT#  and pin 5.
+
+FIX ch341 GPIO access from linux
+RF95 packet RX seems busted FIX FIRST
+
+USE ch341 devboard if needed
+
+SX1262 BUSY seems to come out on pin 15 of the RFM90 HOPE module.  The 'footprint' seems rotated on the pine64 board schematic and that becomes pin 7 on U4 which is "DIO5" on that schematic.  Which goes to pin 8 on the CH341F, which that datasheet calls "IN3"
+
+FIXME - see if possible to read BUSY from "IN3"?
+
+on a ch341a
+ *  - Pin 15 (D0/CS0  ) as input/output/CS (CH341_PIN_MODE_IN/CH341_PIN_MODE_OUT/CH341_PIN_MODE_CS) (confirm hooked to CS)
+ *  - Pin 16 (D1/CS1  ) as input/output/CS (CH341_PIN_MODE_IN/CH341_PIN_MODE_OUT/CH341_PIN_MODE_CS)
+ *  - Pin 17 (D2/CS2  ) as input/output/CS (CH341_PIN_MODE_IN/CH341_PIN_MODE_OUT/CH341_PIN_MODE_CS)
+ *  - Pin 19 (D4/DOUT2) as input/output    (CH341_PIN_MODE_IN/CH341_PIN_MODE_OUT) / gpio4 in linux driver / (FIXME: confirm hooked to IRQ also?)
+ *  - Pin 21 (D6/DIN2 ) as input           (CH341_PIN_MODE_IN) / called RTS when in UART mode
+
+## ch341-driver
+
+driver busted in 5.11 kernels (rf95 init fails).  5.8.0 is okay, 5.8.18 is okay. fails on 5.10.31, 5.9.16 is okay.  Therefore breakage happened in 5.10 kernels!  Possibly not really breakage, possibly just sloppy caching or something that is more easily caught with modern threading.
+
+cs_change is not being set on the way into the driver!
+
+## gpio
+
+the new GPIO interface https://embeddedbits.org/new-linux-kernel-gpio-user-space-interface/
+
+~/development/meshtastic/meshtastic-esp32$ gpiodetect
+gpiochip0 [INT34BB:00] (312 lines)
+gpiochip1 [ch341] (2 lines)
+~/development/meshtastic/meshtastic-esp32$ gpioinfo 1
+gpiochip1 - 2 lines:
+	line   0:      "gpio4"       unused   input  active-high 
+	line   1:      "gpio5"       unused   input  active-high 
+gpiofind gpio4
+gpiochip1 0
+
+DO NOT "apt install libgpiod-dev" It doesn't work with kernels newer than about 5.8.  Instead build and install from source: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
+
+## Send in patch
+Fix drivers/spi/spi.c transfer_once
+
+read about spi: https://elinux.org/images/2/20/Whats_going_on_with_SPI--mark_brown.pdf
+
+https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html 
+git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git