Merge pull request #780 from geeksville/mqtt

1.2.23 - fix gpio access

.github/ISSUE_TEMPLATE/bug-report-or-feature-proposal.md

@@ -0,0 +1,38 @@
+---
+name: Bug report or feature proposal
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+Please - if you just have a question (i.e. not a bug report or a feature proposal), post in our [forum](https://meshtastic.discourse.group/) instead.
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Device info:**
+ - Device model: [e.g. TBEAM]
+ - Software Version [e.g. 0.7.8]
+
+**Smartphone information (if relevant):**
+ - Device: [e.g. iPhone6]
+ - OS: [e.g. iOS8.1]
+ - App Version [e.g. 0.7.2]
+
+**Additional context**
+Add any other context about the problem here.

.github/pull_request_template.md

@@ -0,0 +1,13 @@
+## Thank you for sending in a pull request, here's some tips to get started!
+
+(Please delete all these tips and replace with your text)
+
+- Before starting on some new big chunk of code, it it is optional but highly recommended to open an issue first
+  to say "hey, I think this idea X should be implemented and I'm starting work on it. My general plan is Y, any feedback
+  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 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

@@ -4,18 +4,36 @@ on:
   - pull_request
 
 jobs:
-  main:
-    name: Main
+  setup:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@master
+      - name: Checkout code
+        uses: actions/checkout@v2
+        with:
+          submodules: true
       - name: Setup Python
-        uses: actions/setup-python@master
+        uses: actions/setup-python@v2
         with:
           python-version: 3.x
-      - name: Install Platform IO
+      - name: Install Platform IO and meshtastic-python
         run: |
           python -m pip install --upgrade pip
-          pip install -U platformio
-      - name: Build
-        run: platformio run
+          pip install -U platformio meshtastic
+      - name: Install extra python tools
+        run: |
+          pip install -U adafruit-nrfutil
+      - name: Build for tbeam
+        run: platformio run -e tbeam
+      - name: Build for heltec
+        run: platformio run -e heltec
+      - name: Build for lora-relay-v1
+        run: platformio run -e lora-relay-v1 
+      - name: Build for native
+        run: platformio run -e native
+      - name: Integration test
+        run: |
+          .pio/build/native/program &
+          sleep 5
+          echo "Simulator started, launching python test..."
+          python3 -c 'from meshtastic.test import testSimulator; testSimulator()'
+

.gitignore

@@ -7,4 +7,16 @@ main/credentials.h
 !.vscode/settings.json
 !.vscode/tasks.json
 !.vscode/extensions.json
-*.code-workspace
+*.code-workspace
+
+.DS_Store
+Thumbs.db
+.autotools
+.built
+.context
+.cproject
+.vagrant
+nanopb*
+flash.uf2
+cmake-build*
+

.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

.idea/codeStyles/Project.xml

@@ -0,0 +1,7 @@
+<component name="ProjectCodeStyleConfiguration">
+  <code_scheme name="Project" version="173">
+    <clangFormatSettings>
+      <option name="ENABLED" value="true" />
+    </clangFormatSettings>
+  </code_scheme>
+</component>

.idea/codeStyles/codeStyleConfig.xml

@@ -0,0 +1,5 @@
+<component name="ProjectCodeStyleConfiguration">
+  <state>
+    <option name="USE_PER_PROJECT_SETTINGS" value="true" />
+  </state>
+</component>

.idea/meshtastic-esp32.iml

@@ -0,0 +1,2 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<module classpath="CMake" type="CPP_MODULE" version="4" />

.idea/misc.xml

@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="CMakeWorkspace" PROJECT_DIR="$PROJECT_DIR$" />
+</project>

.idea/modules.xml

@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="ProjectModuleManager">
+    <modules>
+      <module fileurl="file://$PROJECT_DIR$/.idea/meshtastic-esp32.iml" filepath="$PROJECT_DIR$/.idea/meshtastic-esp32.iml" />
+    </modules>
+  </component>
+</project>

.idea/vcs.xml

@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="VcsDirectoryMappings">
+    <mapping directory="$PROJECT_DIR$" vcs="Git" />
+    <mapping directory="$PROJECT_DIR$/design" vcs="Git" />
+    <mapping directory="$PROJECT_DIR$/proto" vcs="Git" />
+    <mapping directory="$PROJECT_DIR$/sdk-nrfxlib" vcs="Git" />
+  </component>
+</project>

.idea/workspace.xml

@@ -0,0 +1,163 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="CMakeRunConfigurationManager" shouldGenerate="true" shouldDeleteObsolete="true">
+    <generated>
+      <config projectName="meshtastic-esp32" targetName="Debug" />
+      <config projectName="meshtastic-esp32" targetName="Production" />
+      <config projectName="meshtastic-esp32" targetName="Z_DUMMY_TARGET" />
+    </generated>
+  </component>
+  <component name="CMakeSettings">
+    <configurations>
+      <configuration PROFILE_NAME="native" CONFIG_NAME="native" ENABLED="true" />
+    </configurations>
+  </component>
+  <component name="ChangeListManager">
+    <list default="true" id="58922733-b05b-4b90-9655-b9b18914977a" name="Default Changelist" comment="">
+      <change beforePath="$PROJECT_DIR$/.idea/workspace.xml" beforeDir="false" afterPath="$PROJECT_DIR$/.idea/workspace.xml" afterDir="false" />
+      <change beforePath="$PROJECT_DIR$/proto" beforeDir="false" afterPath="$PROJECT_DIR$/proto" afterDir="false" />
+      <change beforePath="$PROJECT_DIR$/proto/docs/docs.md" beforeDir="false" afterPath="$PROJECT_DIR$/proto/docs/docs.md" afterDir="false" />
+      <change beforePath="$PROJECT_DIR$/src/mqtt/MQTT.h" beforeDir="false" afterPath="$PROJECT_DIR$/src/mqtt/MQTT.h" afterDir="false" />
+    </list>
+    <option name="SHOW_DIALOG" value="false" />
+    <option name="HIGHLIGHT_CONFLICTS" value="true" />
+    <option name="HIGHLIGHT_NON_ACTIVE_CHANGELIST" value="false" />
+    <option name="LAST_RESOLUTION" value="IGNORE" />
+  </component>
+  <component name="Git.Settings">
+    <option name="RECENT_GIT_ROOT_PATH" value="$PROJECT_DIR$" />
+  </component>
+  <component name="ProjectId" id="1pmWHw2wau2TbdKvXvmQUB0EUE9" />
+  <component name="ProjectLevelVcsManager" settingsEditedManually="true" />
+  <component name="ProjectViewState">
+    <option name="hideEmptyMiddlePackages" value="true" />
+    <option name="showLibraryContents" value="true" />
+  </component>
+  <component name="PropertiesComponent">
+    <property name="ASKED_ADD_EXTERNAL_FILES" value="true" />
+    <property name="RunOnceActivity.OpenProjectViewOnStart" value="true" />
+    <property name="RunOnceActivity.ShowReadmeOnStart" value="true" />
+    <property name="WebServerToolWindowFactoryState" value="false" />
+    <property name="cf.advertisement.text.overridden" value="true" />
+    <property name="cf.first.check.clang-format" value="false" />
+    <property name="node.js.detected.package.eslint" value="true" />
+    <property name="node.js.detected.package.tslint" value="true" />
+    <property name="node.js.path.for.package.eslint" value="project" />
+    <property name="node.js.path.for.package.tslint" value="project" />
+    <property name="node.js.selected.package.eslint" value="(autodetect)" />
+    <property name="node.js.selected.package.tslint" value="(autodetect)" />
+    <property name="settings.editor.selected.configurable" value="CMakeSettings" />
+  </component>
+  <component name="RunManager" selected="GDB Remote Debug.gdbremote-localhost-2345">
+    <configuration default="true" type="CLion_Remote" version="1" remoteCommand="tcp:localhost:2345" symbolFile="" sysroot="">
+      <debugger kind="GDB" isBundled="true" />
+      <method v="2" />
+    </configuration>
+    <configuration name="gdbremote-localhost-2345" type="CLion_Remote" version="1" remoteCommand="tcp:localhost:2345" symbolFile="" sysroot="">
+      <debugger kind="GDB" isBundled="true" />
+      <method v="2" />
+    </configuration>
+    <configuration name="Z_DUMMY_TARGET" type="CMakeRunConfiguration" factoryName="Application" REDIRECT_INPUT="false" ELEVATE="false" PASS_PARENT_ENVS_2="true" PROJECT_NAME="meshtastic-esp32" TARGET_NAME="Z_DUMMY_TARGET" CONFIG_NAME="native" RUN_TARGET_PROJECT_NAME="meshtastic-esp32" RUN_TARGET_NAME="Z_DUMMY_TARGET">
+      <method v="2">
+        <option name="com.jetbrains.cidr.execution.CidrBuildBeforeRunTaskProvider$BuildBeforeRunTask" enabled="true" />
+      </method>
+    </configuration>
+    <configuration default="true" type="CMakeRunConfiguration" factoryName="Application" REDIRECT_INPUT="false" ELEVATE="false" PASS_PARENT_ENVS_2="true">
+      <method v="2">
+        <option name="com.jetbrains.cidr.execution.CidrBuildBeforeRunTaskProvider$BuildBeforeRunTask" enabled="true" />
+      </method>
+    </configuration>
+    <configuration default="true" type="GradleAppRunConfiguration" factoryName="Application" REDIRECT_INPUT="false" ELEVATE="false" PASS_PARENT_ENVS_2="true">
+      <method v="2">
+        <option name="com.jetbrains.cidr.cpp.gradle.execution.GradleNativeBuildBeforeRunTaskProvider$BuildBeforeRunTask" enabled="true" />
+      </method>
+    </configuration>
+    <configuration name="PlatformIO Debug" type="platformio" factoryName="PlatformIO Debug" REDIRECT_INPUT="false" ELEVATE="false" PASS_PARENT_ENVS_2="true" PROJECT_NAME="meshtastic-esp32" TARGET_NAME="Debug" CONFIG_NAME="native" RUN_TARGET_PROJECT_NAME="meshtastic-esp32" RUN_TARGET_NAME="Debug">
+      <method v="2">
+        <option name="com.jetbrains.cidr.execution.CidrBuildBeforeRunTaskProvider$BuildBeforeRunTask" enabled="true" />
+      </method>
+    </configuration>
+    <configuration name="PlatformIO Upload" type="platformio" factoryName="PlatformIO Upload" REDIRECT_INPUT="false" ELEVATE="false" PASS_PARENT_ENVS_2="true" PROJECT_NAME="meshtastic-esp32" TARGET_NAME="Production" CONFIG_NAME="native" RUN_TARGET_PROJECT_NAME="meshtastic-esp32" RUN_TARGET_NAME="Production">
+      <method v="2">
+        <option name="com.jetbrains.cidr.execution.CidrBuildBeforeRunTaskProvider$BuildBeforeRunTask" enabled="true" />
+      </method>
+    </configuration>
+    <list>
+      <item itemvalue="CMake Application.Z_DUMMY_TARGET" />
+      <item itemvalue="GDB Remote Debug.gdbremote-localhost-2345" />
+      <item itemvalue="PlatformIO.PlatformIO Debug" />
+      <item itemvalue="PlatformIO.PlatformIO Upload" />
+    </list>
+  </component>
+  <component name="SpellCheckerSettings" RuntimeDictionaries="0" Folders="0" CustomDictionaries="0" DefaultDictionary="application-level" UseSingleDictionary="true" transferred="true" />
+  <component name="TaskManager">
+    <task active="true" id="Default" summary="Default task">
+      <changelist id="58922733-b05b-4b90-9655-b9b18914977a" name="Default Changelist" comment="" />
+      <created>1615788661896</created>
+      <option name="number" value="Default" />
+      <option name="presentableId" value="Default" />
+      <updated>1615788661896</updated>
+      <workItem from="1615788663210" duration="6661000" />
+      <workItem from="1615938346019" duration="1208000" />
+      <workItem from="1615971126983" duration="5945000" />
+      <workItem from="1617115374907" duration="357000" />
+      <workItem from="1617115747078" duration="1391000" />
+      <workItem from="1617117632667" duration="307000" />
+      <workItem from="1617160691713" duration="1016000" />
+      <workItem from="1617279002260" duration="1626000" />
+      <workItem from="1617425689081" duration="1896000" />
+      <workItem from="1617437366919" duration="1182000" />
+    </task>
+    <servers />
+  </component>
+  <component name="TypeScriptGeneratedFilesManager">
+    <option name="version" value="3" />
+  </component>
+  <component name="Vcs.Log.Tabs.Properties">
+    <option name="TAB_STATES">
+      <map>
+        <entry key="MAIN">
+          <value>
+            <State />
+          </value>
+        </entry>
+      </map>
+    </option>
+    <option name="oldMeFiltersMigrated" value="true" />
+  </component>
+  <component name="XDebuggerManager">
+    <breakpoint-manager>
+      <breakpoints>
+        <line-breakpoint enabled="true" type="com.jetbrains.cidr.execution.debugger.OCBreakpointType">
+          <url>file://$PROJECT_DIR$/src/mesh/wifi/WiFiServerAPI.cpp</url>
+          <line>53</line>
+          <option name="timeStamp" value="6" />
+        </line-breakpoint>
+        <line-breakpoint enabled="true" type="com.jetbrains.cidr.execution.debugger.OCBreakpointType">
+          <url>file://$PROJECT_DIR$/src/mesh/wifi/WiFiServerAPI.cpp</url>
+          <line>37</line>
+          <option name="timeStamp" value="7" />
+        </line-breakpoint>
+        <line-breakpoint enabled="true" type="com.jetbrains.cidr.execution.debugger.OCBreakpointType">
+          <url>file://$PROJECT_DIR$/src/mqtt/MQTT.cpp</url>
+          <line>84</line>
+          <option name="timeStamp" value="10" />
+        </line-breakpoint>
+        <line-breakpoint enabled="true" type="com.jetbrains.cidr.execution.debugger.OCBreakpointType">
+          <url>file://$PROJECT_DIR$/.pio/libdeps/native/PubSubClient/src/PubSubClient.cpp</url>
+          <line>468</line>
+          <option name="timeStamp" value="11" />
+        </line-breakpoint>
+      </breakpoints>
+    </breakpoint-manager>
+    <watches-manager>
+      <configuration name="CLion_Remote">
+        <watch expression="radioConfig" language="ObjectiveC" />
+      </configuration>
+    </watches-manager>
+  </component>
+  <component name="XSLT-Support.FileAssociations.UIState">
+    <expand />
+    <select />
+  </component>
+</project>

.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,18 +47,36 @@
         "memory_resource": "cpp",
         "optional": "cpp",
         "string_view": "cpp",
-        "cassert": "cpp"
+        "cassert": "cpp",
+        "iterator": "cpp",
+        "shared_mutex": "cpp",
+        "iostream": "cpp"
     },
     "cSpell.words": [
         "Blox",
+        "EINK",
         "HFSR",
         "Meshtastic",
         "NEMAGPS",
+        "NMEAGPS",
+        "RDEF",
         "Ublox",
         "bkpt",
         "cfsr",
         "descs",
         "ocrypto",
-        "protobufs"
-    ]
+        "protobufs",
+        "wifi"
+    ],
+    "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"
+        ]
+    },
+    "editor.formatOnSave": true
 }

.vscode/tasks.json

@@ -0,0 +1,17 @@
+{
+	"version": "2.0.0",
+	"tasks": [
+		{
+			"type": "PlatformIO",
+			"task": "Build",
+			"problemMatcher": [
+				"$platformio"
+			],
+			"group": {
+				"kind": "build",
+				"isDefault": true
+			},
+			"label": "PlatformIO: Build"
+		}
+	]
+}

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

@@ -4,7 +4,7 @@ This is the device side code for the [meshtastic.org](https://www.meshtastic.org
 
 ![Continuous Integration](https://github.com/meshtastic/Meshtastic-esp32/workflows/Continuous%20Integration/badge.svg)
 
-Meshtastic is a project that lets you use
+Meshtastic® is a project that lets you use
 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.
@@ -14,36 +14,58 @@ 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 currently early-alpha, but if you have questions please [join our discussion forum](https://meshtastic.discourse.group/).
+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
-    - [T-Beam V1.0 w/ NEO-M8N](https://www.aliexpress.com/item/33047631119.html) (Recommended)
-    - [T-Beam V1.0 w/ NEO-6M](https://www.aliexpress.com/item/33050391850.html)
-    - 3D printable cases
-      - [T-Beam V0](https://www.thingiverse.com/thing:3773717)
-      - [T-Beam V1](https://www.thingiverse.com/thing:3830711)
+
+- 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.1 w/ NEO-M8N](https://www.aliexpress.com/item/33047631119.html) (slightly better GPS)
+  - [T-Beam V1.1 w/ NEO-M8N /w SX1262](https://www.aliexpress.com/item/4001287221970.html) (slightly better GPS + LoRa)
+    - board labels "TTGO T22_V1.1 20191212"
+  - [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!)
+     - board labels "TTGO T22_V07 20180711"
+  - 3D printable cases
+    - [T-Beam V0](https://www.thingiverse.com/thing:3773717) (GPS and LoRa antenna misaligned if GPS placed as pictured)
+    - [T-Beam V1 (SMA-antenna)](https://www.thingiverse.com/thing:3830711)
+    - [T-Beam V1 (SMA-antenna)](https://www.thingiverse.com/thing:4677388) (Mounting option for larger GPS antenna but LoRa antenna enclosed)
+    - [T-Beam V1 (IPEX-antenna)](https://www.thingiverse.com/thing:4587297) (GPS and LoRa antenna misaligned if GPS placed as pictured)
+    - [T-Beam V1 (IPEX-antenna)](https://www.thingiverse.com/thing:4589651)
+    - [T-Beam V1 (IPEX-antenna)](https://www.thingiverse.com/thing:4619981) (GPS and LoRa antenna misaligned if GPS placed as pictured)
+  - Laser-cut cases
+    - [T-Beam V1 (SMA-antenna)](https://www.thingiverse.com/thing:4552771)
 
 - [TTGO LORA32](https://www.aliexpress.com/item/4000211331316.html) - No GPS
+  - version 2.1
+    - board labels "TTGO T3_V1.6 20180606"
+  - 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)
+  - [Official Heltec case](https://www.aliexpress.com/item/4001050707951.html)
+  - [3D Printable case](https://www.thingiverse.com/thing:3125854)
+  
+Note: The GPS and LoRa stock antennas should be placed in a way, that the GPS antenna faces the sky and the LoRa antenna radiates 360 degrees horizontally. For better GPS reception you might want to [upgrade the GPS antenna](https://meshtastic.discourse.group/t/the-importance-of-gps-antennas-and-request-to-3d-case-documentation-people/1505) and to properly align the antennas you might want to upgrade to a LoRa antenna that can be adjusted to radiate into the right directions.
 
 **Make sure to get the frequency for your country**
-  - US/JP/AU/NZ - 915MHz
-  - CN - 470MHz
-  - EU - 870MHz
-  
+
+- 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
@@ -57,7 +79,7 @@ Please post comments on our [group chat](https://meshtastic.discourse.group/) if
 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”. 
+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
 
@@ -87,10 +109,10 @@ 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`.
+6. Install the correct firmware for your board with `device-install.sh -f firmware-_board_-_country_.bin`.
+   - Example: `./device-install.sh -f firmware-HELTEC-US-0.0.3.bin`.
+7. To update run `device-update.sh -f firmware-_board_-_country_.bin`
+   - Example: `./device-update.sh -f 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.
 
@@ -165,12 +187,7 @@ Hard resetting via RTS pin...
 
 # Meshtastic Android app
 
-The source code for the (optional) Meshtastic Android app is [here](https://github.com/meshtastic/Meshtastic-Android).
-
-Alpha test builds available by opting into our alpha test group. See (www.meshtastic.org) for instructions.
-
-If you don't want to live on the 'bleeding edge' you can opt-in to the beta-test or use the released version:
-[![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%26utm_medium%3Desp32-readme%26utm_campaign%3Dmeshtastic-esp32%2520readme%26anid%3Dadmob&pcampaignid=pcampaignidMKT-Other-global-all-co-prtnr-py-PartBadge-Mar2515-1)
+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
 
@@ -182,7 +199,7 @@ We'd love to have you join us on this merry little project. Please see our [deve
 
 # Credits
 
-This project is run by volunteers. Past contributors include:
+This project is run by volunteers. We are a friendly group and welcome any contribution (code fixes, documentation, features, bug reports etc...).  We try to be good about listing contributor names in release notes, but it has become unwieldy for the main-devs to keep updating the list below and we've neglected it too long.  If you'd like your name included in this list please send a pull request to edit this README and simply add your line yourself.  Thank you very much for your help!
 
 - @astro-arphid: Added support for 433MHz radios in europe.
 - @claesg: Various documentation fixes and 3D print enclosures

bin/build-all.sh

@@ -2,14 +2,13 @@
 
 set -e
 
-source bin/version.sh
+VERSION=`bin/buildinfo.py`
 
-COUNTRIES="US EU433 EU865 CN JP"
-#COUNTRIES=US
-#COUNTRIES=CN
+BOARDS_ESP32="tlora-v2 tlora-v1 tlora_v1_3 tlora-v2-1-1.6 tbeam heltec tbeam0.7"
+#BOARDS_ESP32=tbeam
 
-BOARDS="ttgo-lora32-v2 ttgo-lora32-v1 tbeam heltec"
-#BOARDS=tbeam
+# FIXME note nrf52840dk build is for some reason only generating a BIN file but not a HEX file nrf52840dk-geeksville is fine
+BOARDS_NRF52="lora-relay-v1"
 
 OUTDIR=release/latest
 
@@ -18,25 +17,48 @@ ARCHIVEDIR=release/archive
 
 rm -f $OUTDIR/firmware*
 
-mkdir -p $OUTDIR/bins $OUTDIR/elfs
-rm -f $OUTDIR/bins/*
+mkdir -p $OUTDIR/bins $ARCHIVEDIR
+rm -r $OUTDIR/bins/*
+mkdir -p $OUTDIR/bins/universal $OUTDIR/elfs/universal
 
 # build the named environment and copy the bins to the release directory
-function do_build {
-    ENV_NAME=$1
-    echo "Building for $ENV_NAME with $PLATFORMIO_BUILD_FLAGS"
-    SRCBIN=.pio/build/$ENV_NAME/firmware.bin
-    SRCELF=.pio/build/$ENV_NAME/firmware.elf
-    rm -f $SRCBIN 
+function do_build() {
+	BOARD=$1
+	isNrf=$3
+	
+    echo "Building for $BOARD with $PLATFORMIO_BUILD_FLAGS"
+    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
-    cp $SRCBIN $OUTDIR/bins/firmware-$ENV_NAME-$COUNTRY-$VERSION.bin
-    cp $SRCELF $OUTDIR/elfs/firmware-$ENV_NAME-$COUNTRY-$VERSION.elf
+    # Are we building a universal/regionless rom?
+    export HW_VERSION="1.0"
+    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 +67,20 @@ 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 
-    for BOARD in $BOARDS; do
-        do_build $BOARD
-    done
-done
+do_boards "$BOARDS_ESP32" "false"
+do_boards "$BOARDS_NRF52" "true"
+
+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 +90,12 @@ 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>
 </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.* images/system-info.bin bin/device-install.sh bin/device-update.sh
 
 echo BUILT ALL

bin/build-nightly.sh

@@ -0,0 +1,38 @@
+#!/bin/bash
+source ~/.bashrc
+
+# Meshtastic Nightly Build Script.
+#  McHamster (jm@casler.org)
+#
+# This is the script that is used for the nightly build server.
+#
+# It's probably not useful for most people, but you may want to run your own
+#   nightly builds.
+#
+# The last line of ~/.bashrc contains an inclusion of platformio in the path.
+#   Without this, the build script won't run from the crontab:
+#
+#    export PATH="$HOME/.platformio/penv/bin:$PATH" 
+#
+# The crontab contains:
+#  0 2 * * * cd ~/meshtastic/github/meshtastic && source "~/.bashrc"; ./build-nightly.sh > ~/cronout.txt 2> ~/cronout.txt
+
+cd Meshtastic-device
+
+git pull
+
+bin/build-all.sh
+
+date_stamp=$(date +'%Y-%m-%d')
+
+cd ..
+
+# TODO: Archive the same binaries used by the build-all script.
+#zip -r meshtastic_device_nightly_${date_stamp} Meshtastic-device/release/latest/bins
+cp Meshtastic-device/release/archive/`ls -t ./Meshtastic-device/release/archive/| head -1` meshtastic_device_nightly_${date_stamp}.zip
+
+# Copy the file to the webserver
+scp meshtastic_device_nightly_${date_stamp}.zip jm@10.11.12.20:/volume1/web/meshtastic/nightly_builds/
+
+# Delete the local copy
+rm meshtastic_device_nightly_${date_stamp}.zip

bin/buildinfo.py

@@ -0,0 +1,11 @@
+#!/usr/bin/env python3
+import configparser
+
+config = configparser.RawConfigParser()
+config.read('version.properties')
+
+version = dict(config.items('VERSION'))
+
+verStr = "{}.{}.{}".format(version["major"], version["minor"], version["build"])
+
+print(f"{verStr}")

bin/device-install.sh

@@ -1,11 +1,53 @@
-#!/bin/bash
+#!/bin/sh
+
+PYTHON=${PYTHON:-python3}
 
 set -e
 
-FILENAME=$1
+# Usage info
+show_help() {
+cat << EOF
+Usage: ${0##*/} [-h] [-p ESPTOOL_PORT] [-P PYTHON] [-f 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"
-esptool.py --baud 921600 erase_flash
-esptool.py --baud 921600 write_flash 0x1000 system-info.bin
-esptool.py --baud 921600 write_flash 0x10000 $FILENAME
+    -h               Display this help and exit
+    -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))"
+
+if [ -f "${FILENAME}" ]; then
+	echo "Trying to flash ${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
+	$PYTHON -m esptool --baud 921600 write_flash 0x00390000 spiffs-*.bin
+	$PYTHON -m esptool --baud 921600 write_flash 0x10000 ${FILENAME}
+else
+	echo "Invalid file: ${FILENAME}"
+	show_help
+fi
+
+exit 0

bin/device-update.sh

@@ -1,8 +1,50 @@
-#!/bin/bash
+#!/bin/sh
 
-set -e
+PYTHON=${PYTHON:-python3}
 
-FILENAME=$1
+# Usage info
+show_help() {
+cat << EOF
+Usage: ${0##*/} [-h] [-p ESPTOOL_PORT] [-P PYTHON] -f FILENAME
+Flash image file to device, leave existing system intact."
 
-echo "Trying to update $FILENAME"
-esptool.py --baud 921600 write_flash 0x10000 $FILENAME
+    -h               Display this help and exit
+    -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))"
+
+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/dump-ram-users.sh

@@ -0,0 +1,3 @@
+arm-none-eabi-readelf -s -e .pio/build/nrf52dk/firmware.elf | head -80
+
+nm -CSr --size-sort .pio/build/nrf52dk/firmware.elf  | grep '^200'

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 test.mosquitto.org -v -t mesh/stat/\# -t mesh/json/\#
+# mosquitto_sub -h test.mosquitto.org -v -t mesh/\# -F "%j"

bin/mqtt-send-status.sh

@@ -0,0 +1 @@
+mosquitto_pub -h test.mosquitto.org -t mesh/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

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

bin/platformio-custom.py

@@ -0,0 +1,16 @@
+
+Import("projenv")
+
+import configparser
+prefsLoc = projenv["PROJECT_DIR"] + "/version.properties"
+config = configparser.RawConfigParser()
+config.read(prefsLoc)
+version = dict(config.items('VERSION'))
+verStr = "{}.{}.{}".format(version["major"], version["minor"], version["build"])
+
+print("Using meshtastic platform-custom.py, firmare version " + verStr)
+
+# General options that are passed to the C and C++ compilers
+projenv.Append(CCFLAGS=[
+    "-DAPP_VERSION=" + verStr
+    ])

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/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/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/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,4 @@
+
+echo "Converting to uf2 for NRF52 Adafruit bootloader"
+bin/uf2conv.py .pio/build/lora-relay-v2/firmware.hex -f 0xADA52840
+# cp flash.uf2 /media/kevinh/FTH*BOOT/

bin/version.sh

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

bin/view-map.sh

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

boards/eink.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": "eink",
+    "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/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",
@@ -16,9 +16,9 @@
       "name": "adafruit"
     },
     "softdevice": {
-      "sd_flags": "-DS140",
-      "sd_name": "s140",
-      "sd_version": "6.1.1",
+      "sd_flags": "-DS113",
+      "sd_name": "s113",
+      "sd_version": "7.2.0",
       "sd_fwid": "0x00B6"
     },
     "bootloader": {

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"
+}

data/static/basic.js

@@ -0,0 +1,43 @@
+var meshtasticClient;
+var connectionOne;
+
+
+// Important: the connect action must be called from a user interaction (e.g. button press), otherwise the browsers won't allow the connect
+function connect() {
+
+    // Create new connection
+    var httpconn = new meshtasticjs.IHTTPConnection();
+
+    // Set connection params
+    let sslActive;
+    if (window.location.protocol === 'https:') {
+        sslActive = true;
+    } else {
+        sslActive = false;
+    }
+    let deviceIp = window.location.hostname; // Your devices IP here
+
+
+    // Add event listeners that get called when a new packet is received / state of device changes
+    httpconn.addEventListener('fromRadio', function (packet) { console.log(packet) });
+
+    // Connect to the device async, then send a text message
+    httpconn.connect(deviceIp, sslActive)
+        .then(result => {
+
+            alert('device has been configured')
+            // This gets called when the connection has been established
+            // -> send a message over the mesh network. If no recipient node is provided, it gets sent as a broadcast
+            return httpconn.sendText('meshtastic is awesome');
+
+        })
+        .then(result => {
+
+            // This gets called when the message has been sucessfully sent
+            console.log('Message sent!');
+        })
+
+        .catch(error => { console.log(error); });
+
+}
+

data/static/index.html

@@ -0,0 +1,18 @@
+<!doctype html>
+<html class="no-js" lang="">
+
+<head>
+  <meta charset="utf-8">
+  <title></title>
+
+  <script src="/static/meshtastic.js"></script>
+  <script src="/static/basic.js"></script>
+</head>
+
+<body>
+
+  <button id="connect_button" onclick="connect()">Connect to Meshtastic device</button>
+ 
+</body>
+
+</html>

docs/README.md

@@ -1,13 +1,13 @@
 # What is Meshtastic?
 
-Meshtastic is a project that lets you use
+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
+## 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...)
@@ -17,28 +17,40 @@ Note: Questions after reading this? See our new [forum](https://meshtastic.disco
 
 [![Youtube video demo](desk-video-screenshot.png)](https://www.youtube.com/watch?v=WlNbMbVZlHI "Meshtastic early demo")
 
-### Features
+## 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. So if you have some application that needs long range low power networking, this might work for you.
-- Eventually (within a couple of months) we should have a modified version of Signal that works with this project.
+- 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 early alpha - if you have questions please [join our discussion forum](https://meshtastic.discourse.group/).
+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/).
+
+### Related Groups
+
+Telegram group for **Italy**-based users [t.me/meshtastic_italia](http://t.me/meshtastic_italia) (Italian language, unofficial).<br/>
+Telegram group for **Russian**-based users [t.me/meshtastic_russia](https://t.me/meshtastic_russia) (Russian language, unofficial).
+
 # Updates
 
 Note: Updates are happening almost daily, only major updates are listed below. For more details see our forum.
 
+- 09/14/2020 - 1.0.0 Now with over 1700 android users, over 2000 nodes and translated into 15 languages. This project will always be a "beta" experiment, but now quite usable. We are currently selecting 1.1 features in our discussion forum.
+- 06/24/2020 - 0.7.x Now with over 1000 android users, over 600 people using the radios and translated into 22 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.
@@ -50,7 +62,7 @@ Note: Updates are happening almost daily, only major updates are listed below. F
 
 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%3Dhomepage%26anid%3Dadmob)
+[![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:
 
@@ -60,18 +72,25 @@ The link above will return older more stable releases. We would prefer if you jo
 
 If you'd like to help with development, the source code is [on github](https://github.com/meshtastic/Meshtastic-Android).
 
+The app is also distributed for Amazon Fire devices via the Amazon appstore: [![Amazon appstore link](https://raw.githubusercontent.com/meshtastic/Meshtastic-device/master/images/amazon-fire-button.png)](https://www.amazon.com/Geeksville-Industries-Meshtastic/dp/B08CY9394Q)
+
 ## Supported hardware
 
-We currently support two brands of radios. The [TTGO T-Beam](https://www.aliexpress.com/item/4000119152086.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). 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.
+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:
+For a nice looking 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).
+- 3D 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 (SMA) 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. TTGO T_Beam V1 (IPEX) see this [design](https://www.thingiverse.com/thing:4587297) by [drewsed](https://www.thingiverse.com/drewsed)
+  4. Heltec Lora32 see this [design](https://www.thingiverse.com/thing:3125854) by [ornotermes](https://www.thingiverse.com/ornotermes).
+- Laser-cut cases
+  1. TTGO T_Beam V1 (SMA) see this [design](https://www.thingiverse.com/thing:4552771) by [jefish](https://www.thingiverse.com/jefish)
 
 # IMPORTANT DISCLAIMERS AND FAQ
 

docs/SupportedHardware.md

@@ -0,0 +1,8 @@
+| Vendor  | Product line  | Version  | Board labels  | Notes  | URL |
+|---|---|---|---|---|---|
+| TTGO  | T-Beam  | 0.7  | T22_V07 20180711  | LoRa 433/470MHz *OR* LoRa 868/915MHz , <br/>GPS ublox NEO-6M , <br/>battery holder for Li-Ion 18650  |  [buy](https://www.aliexpress.com/item/4000574335430.html)  |
+| TTGO  | T-Beam  | 1.0  |   |   |  [buy](https://www.aliexpress.com/item/4001178678568.html)  |
+| TTGO  | T-Beam  | 1.1  | T22_V11 20191212 | LoRa 433/470MHz *OR* LoRa 868/915MHz *OR* LoRa 923MHz , <br/>GPS ublox NEO-M8N , <br/>battery holder for Li-Ion 18650  | [buy](https://www.aliexpress.com/item/4001178678568.html) |
+| TTGO  | Lora32  | 2.0  | *missing*  | LoRa 433/470MHz *OR* LoRa 868/915MHz , <br/>OLED SSD1306 , <br/>SD card holder | [buy](https://www.aliexpress.com/item/4000211331316.html) |
+| TTGO  | Lora32  | 2.1  | T3_V1.6 20180606  | LoRa 32 (V2) , <br/>SD card holder | [buy](https://www.aliexpress.com/item/4000119208093.html) |
+| Heltec | Lora 32 | V2  | V2 | LoRa 433/470MHz *OR* LoRa 868/915MHz | [buy](https://heltec.org/project/wifi-lora-32/) |

docs/_config.yml

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

docs/faq.md

@@ -4,7 +4,7 @@ This project is still pretty young but moving at a pretty good pace. Not all fea
 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](software/crypto.md) has not been reviewed by an expert. (Are you an expert? Please help us)
+- 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) ;-)

docs/hardware/corvus.md

@@ -0,0 +1,35 @@
+# Notes on @BigCorvus boards
+
+## Board version 1.1
+
+variant name lora_relay_v1
+
+### Remaining TODOs
+
+- power hold for the ST7735
+- look at example sketch
+- turn on xmit boost
+
+## Recommendations for future boards
+
+@BigCorvus your board is **really** nice. Here's some ideas for the future:
+
+- make the SWDIO header more standard (the small ARM 2x5 micro footprint?) or at least througholes so it is easy to solder a header
+
+## How to program bootloader
+
+Download from here: https://github.com/adafruit/Adafruit_nRF52_Bootloader/releases
+
+```
+nrfjprog -f nrf52 --eraseall
+Erasing user available code and UICR flash areas.
+Applying system reset.
+
+nrfjprog -f nrf52 --program feather_nrf52840_express_bootloader-0.3.2_s140_6.1.1.hex
+Parsing hex file.
+Reading flash area to program to guarantee it is erased.
+Checking that the area to write is not protected.
+Programming device.
+```
+
+Then reboot the board, if all went well it now shows up as a mountable filesystem on your USB bus.

docs/hardware/cubecell-TODO.md

@@ -0,0 +1,6 @@
+
+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/radio-settings.md

@@ -2,13 +2,13 @@
 
 We use the same channel maps as LoRaWAN (though this is not LoRaWAN).
 
-![freq table](images/LoRa-Frequency-Bands.jpg)
+![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.
+The maximum power allowed is +14dBm ERP (Effective Radiated Power, see [this site](https://en.wikipedia.org/wiki/Effective_radiated_power) for more information).
 
 ### 433 MHz
 
@@ -24,7 +24,82 @@ Channel zero starts at 865.20 MHz
 
 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 maximum output power for North America is +30 dBm ERP.
 
 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.
+Channel zero starts at 903.08 MHz center frequency.
+
+## Data-rates
+
+### About
+
+Various data-rates are selectable when configuring a channel and are inversely proportional to the theoretical range of the devices.
+
+Considerations:
+
+* Spreading Factor - How much we "spread" our data over time.
+* * Each step up in Spreading Factor dobules the airtime to transmit.
+* * Each step up in Spreading Factor adds about 2.5db extra link budget.
+* Bandwidth - How big of a slice of the spectrum we use.
+* * Each doubling of the bandwidth is almost 3db less link budget.
+* * Bandwidths less than 31 may be unstable unless you have a high quality Crystal Ossilator.
+* Coding Rate - How much redundency we encode to resist noise.
+* * Increasing coding rate increases reliability while decrasing data-rate.
+* * 4/5 - 1.25x overhead
+* * 4/6 - 1.5x overhead
+* * 4/7 - 1.75x overhead
+* * 4/8 - 2x overhead
+
+
+### Pre-Defined
+
+We have four predefined channels. These are the most common settings and have been proven to work well:
+
+| Channel setting            | Alt Channel Name | Data-rate            | SF / Symbols | Coding Rate | Bandwidth | Link Budget |
+|:---------------------------|:-----------------|:---------------------|:-------------|:------------|:----------|:------------|
+| Short range (but fast)     | Short Fast       | 21.875 kbps          | 7 / 128      | 4/5         | 125       | 134dB       |
+| Medium range (but fast)    | Medium           | 5.469 kbps           | 7 / 128      | 4/5         | 500       | 140dB       |
+| Long range (but slower)    | Long Alt         | 0.275 kbps           | 9 / 512      | 4/8         | 31        | 153dB       |
+| Very long range (but slow) | Long Slow        | 0.183 kbps (default) | 12 / 4096    | 4/8         | 125       | 154dB       |
+
+The link budget used by these calculations assumes a transmit power of 17dBm and an antenna with 0dB gain. Adjust your link budget assumptions based on your actual devices.
+
+### Custom Settings
+
+You may want to select other channels for your usage. The other settings can be set by using the Python API.
+
+> meshtastic --setchan spread_factor 10 --setchan coding_rate 8 --setchan bandwidth 125
+
+After applying the settings, you will need to restart the device. After your device is restarted, it will generate a new crypto key and you will need to share the newly generated QR Code or URL to all your other devices.
+
+Some example settings:
+
+| Data-rate            | SF / Symbols | Coding Rate | Bandwidth | Link Budget | Note |
+|:---------------------|:-------------|:------------|:----------|:------------|:-----|
+| 37.50 kbps           | 6 / 64       | 4/5         | 500       | 129dB       | Fastest possible speed |
+| 3.125 kbps           | 8 / 256      | 4/5         | 125       | 143dB       | |
+| 1.953 kbps           | 8 / 256      | 4/8         | 125       | 143dB       | |
+| 1.343 kbps           | 11 / 2048    | 4/8         | 500       | 145dB       | | 
+| 1.099 kbps           | 9 / 512      | 4/8         | 125       | 146dB       | |
+| 0.814 kbps           | 10 / 1024    | 4/6         | 125       | 149dB       | |
+| 0.610 kbps           | 10 / 1024    | 4/8         | 125       | 149dB       | |
+| 0.488 kbps           | 11 / 2048    | 4/6         | 125       | 152dB       | |
+| 0.336 kbps           | 11 / 2048    | 4/8         | 125       | 152dB       | |
+| 0.073 kbps           | 12 / 4096    | 4/5         | 31        | 160dB       | Twice the range and/or coverage of "Long Slow", low resliance to noise |
+| 0.046 kbps           | 12 / 4096    | 4/8         | 31        | 160dB       | Twice the range and/or coverage of "Long Slow", high resliance to noise |
+
+The link budget used by these calculations assumes a transmit power of 17dBm and an antenna with 0dB gain. Adjust your link budget assumptions based on your actual devices.
+
+These channel settings may have not been tested. Use at your own discression. Share on https://meshtastic.discourse.group with your successes or failure.
+
+## Cryptography
+
+The preshared key used by the devices can be modified.
+
+* 0 = No crypto
+* 1 = Default channel key
+* 2 - 10 = The default channel key, except with 1 through 9 added to the last byte
+
+Use of cryptography can also be modified. To disable cryptography (maybe useful if you have HAM radio license):
+
+> meshtastic --setchan psk 0

docs/software/TODO.md

@@ -1,205 +1,344 @@
-# High priority
+# Geeksville's current work queue
 
-Items to complete soon (next couple of alpha releases).
+You probably don't care about this section - skip to the next one.
 
-- lower wait_bluetooth_secs to 30 seconds once we have the GPS power on (but GPS in sleep mode) across light sleep. For the time
-  being I have it set at 2 minutes to ensure enough time for a GPS lock from scratch.
+## before next release
+
+* DONE android speed settings https://github.com/meshtastic/Meshtastic-Android/issues/271
+* fix heltec battery scaling
+
+* 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 portduino builds to zip
+* 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 the first beta release.
+Items to complete before 1.0.
 
-- Use 32 bits for message IDs
-- Use fixed32 for node IDs
-- Remove the "want node" node number arbitration process
+# 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.
-- possibly switch to https://github.com/SlashDevin/NeoGPS for gps comms
-- good source of battery/signal/gps icons https://materialdesignicons.com/
-- research and implement better mesh algorithm - investigate changing routing to https://github.com/sudomesh/LoRaLayer2 ?
-- check fcc rules on duty cycle. we might not need to freq hop. https://www.sunfiretesting.com/LoRa-FCC-Certification-Guide/
-- use fuse bits to store the board type and region. So one load can be used on all boards
-- the BLE stack is leaking about 200 bytes each time we go to light sleep
-- rx signal measurements -3 marginal, -9 bad, 10 great, -10 means almost unusable. So scale this into % signal strength. preferably as a graph, with an X indicating loss of comms.
-- 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"
-- Note: we do not do address filtering at the chip level, because we might need to route for the mesh
-  is in cleartext (so that nodes will route for other radios that are cryptoed with a key we don't know)
-- add frequency hopping, dependent on the gps time, make the switch moment far from the time anyone is going to be transmitting
-- share channel settings over Signal (or qr code) by embedding an an URL which is handled by the MeshUtil app.
-- publish update articles on the web
+- 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)
 
-# Pre-beta priority
+Changes related to wifi support on ESP32:
 
-During the beta timeframe the following improvements 'would be nice' (and yeah - I guess some of these items count as features, but it is a hobby project ;-) )
-
-- 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)
-- Figure out why the RF95 ISR is never seeing RH_RF95_VALID_HEADER, so it is not protecting our rx packets from getting stomped on by sends
-- fix the frequency error reading in the RF95 RX code (can't do floating point math in an ISR ;-)
-- See CustomRF95::send and fix the problem of dropping partially received packets if we want to start sending
-- make sure main cpu is not woken for packets with bad crc or not addressed to this node - do that in the radio hw
-- triple check fcc compliance
-- pick channel center frequency based on channel name? "dolphin" would hash to 900Mhz, "cat" to 905MHz etc? allows us to hide the concept of channel # from hte user.
-- scan to find channels with low background noise? (Use CAD mode of the RF95 to automatically find low noise channels)
-- 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
-- reneable the bluetooth battery level service on the T-BEAM, because we can read battery level there
+- 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/
-- a version with a solar cell for power, just mounted high to permanently provide routing for nodes in a valley. Someone just pointed me at disaster.radio
 - How do avalanche beacons work? Could this do that as well? possibly by using beacon mode feature of the RF95?
-- provide generalized (but slow) internet message forwarding servie if one of our nodes has internet connectivity
-
-# Low priority
-
-Items after the first final candidate release.
-
-- use variable length arduino Strings in protobufs (instead of current fixed buffers)
-- use BLEDevice::setPower to lower our BLE transmit power - extra range doesn't help us, it costs amps and it increases snoopability
-- make an install script to let novices install software on their boards
-- use std::map<NodeInfo\*, std::string> in node db
-- make a HAM build: yep - that's a great idea. I'll add it to the TODO. should be pretty painless - 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
-- use https://platformio.org/lib/show/1260/OneButton if necessary
-- don't send location packets if we haven't moved
-- scrub default radio config settings for bandwidth/range/speed
-- answer to pings (because some other user is looking at our nodeinfo) with our latest location (not a stale location)
-- 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)
-- 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
-- the AXP debug output says it is trying to charge at 700mA, but the max I've seen is 180mA, so AXP registers probably need to be set to tell them the circuit can only provide 300mAish max. So that the low charge rate kicks in faster and we don't wear out batteries.
-- increase the max charging rate a bit for 18650s, currently it limits to 180mA (at 4V). Work backwards from the 500mA USB limit (at 5V) and let the AXP charge at that rate.
-- discard very old nodedb records (> 1wk)
-- using the genpartitions based table doesn't work on TTGO so for now I stay with my old memory map
-- We let anyone BLE scan for us (FIXME, perhaps only allow that until we are paired with a phone and configured)
-- use two different buildenv flags for ttgo vs lora32. https://docs.platformio.org/en/latest/ide/vscode.html#key-bindings
-- sim gps data for testing nodes that don't have hardware
-- do debug serial logging to android over bluetooth
-- break out my bluetooth OTA software as a seperate library so others can use it
-- Heltec LoRa32 has 8MB flash, use a bigger partition table if needed - TTGO is 4MB but has PSRAM
-- add a watchdog timer
-- handle millis() rollover in GPS.getTime - otherwise we will break after 50 days
-- report esp32 device code bugs back to the mothership via android
-
-# Done
-
-- change the partition table to take advantage of the 4MB flash on the wroom: http://docs.platformio.org/en/latest/platforms/espressif32.html#partition-tables
-- wrap in nice MeshRadio class
-- add mesh send & rx
-- make message send from android go to service, then to mesh radio
-- make message receive from radio go through to android
-- test loopback tx/rx path code without using radio
-- notify phone when rx packets arrive, currently the phone polls at startup only
-- figure out if we can use PA_BOOST - yes, it seems to be on both boards
-- implement new ble characteristics
-- have MeshService keep a node DB by sniffing user messages
-- have a state machine return the correct FromRadio packet to the phone, it isn't always going to be a MeshPacket. Do a notify on fromnum to force the radio to read our state machine generated packets
-- send my_node_num when phone sends WantsNodes
-- have meshservice periodically send location data on mesh (if device has a GPS)
-- implement getCurrentTime() - set based off gps but then updated locally
-- make default owner record have valid usernames
-- message loop between node 0x28 and 0x7c
-- check in my radiolib fixes
-- figure out what is busted with rx
-- send our owner info at boot, reply if we see anyone send theirs
-- add manager layers
-- confirm second device receives that gps message and updates device db
-- send correct hw vendor in the bluetooth info - needed so the android app can update different radio models
-- correctly map nodeids to nodenums, currently we just do a proof of concept by always doing a broadcast
-- add interrupt detach/sleep mode config to lora radio so we can enable deepsleep without panicing
-- make jtag work on second board
-- implement regen owner and radio prefs
-- use a better font
-- make nice screens (boot, about to sleep, debug info (gps signal, #people), latest text, person info - one frame per person on network)
-- turn framerate from ui->state.frameState to 1 fps (or less) unless in transition
-- switch to my gui layout manager
-- make basic gui. different screens: debug, one page for each user in the user db, last received text message
-- make button press cycle between screens
-- save our node db on entry to sleep
-- fix the logo
-- sent/received packets (especially if a node was just reset) have variant of zero sometimes - I think there is a bug (race-condtion?) in the radio send/rx path.
-- DONE dynamic nodenum assignment tasks
-- make jtag debugger id stable: https://askubuntu.com/questions/49910/how-to-distinguish-between-identical-usb-to-serial-adapters
-- reported altitude is crap
-- good tips on which bands might be more free https://github.com/TheThingsNetwork/ttn/issues/119
-- finish power measurements (GPS on during sleep vs LCD on during sleep vs LORA on during sleep) and est battery life
-- make screen sleep behavior work
-- make screen advance only when a new node update arrives, a new text arrives or the user presses a button, turn off screen after a while
-- after reboot, channel number is getting reset to zero! fix!
-- send user and location events much less often
-- send location (or if not available user) when the user wakes the device from display sleep (both for testing and to improve user experience)
-- make real implementation of getNumOnlineNodes
-- very occasionally send our position and user packet based on the schedule in the radio info (if for nothing else so that other nodes update last_seen)
-- show real text info on the text screen
-- apply radio settings from android land
-- cope with nodes that have 0xff or 0x00 as the last byte of their mac
-- allow setting full radio params from android
-- add receive timestamps to messages, inserted by esp32 when message is received but then shown on the phone
-- update build to generate both board types
-- have node info screen show real info (including distance and heading)
-- blink the power led less often
-- have radiohead ISR send messages to RX queue directly, to allow that thread to block until we have something to send
-- move lora rx/tx to own thread and block on IO
-- keep our pseudo time moving forward even if we enter deep sleep (use esp32 rtc)
-- for non GPS equipped devices, set time from phone
-- GUI on oled hangs for a few seconds occasionally, but comes back
-- update local GPS position (but do not broadcast) at whatever rate the GPS is giving it
-- don't send our times to other nodes
-- don't trust times from other nodes
-- draw compass rose based off local walking track
-- add requestResponse optional bool - use for location broadcasts when sending tests
-- post sample video to signal forum
-- support non US frequencies
-- send pr https://github.com/ThingPulse/esp8266-oled-ssd1306 to tell them about this project
-- document rules for sleep wrt lora/bluetooth/screen/gps. also: if I have text messages (only) for the phone, then give a few seconds in the hopes BLE can get it across before we have to go back to sleep.
-- wake from light sleep as needed for our next scheduled periodic task (needed for gps position broadcasts etc)
-- turn bluetooth off based on our sleep policy
-- blink LED while in LS sleep mode
-- scrolling between screens based on press is busted
-- Use Neo-M8M API to put it in sleep mode (on hold until my new boards arrive)
-- update the prebuilt bins for different regulatory regions
-- don't enter NB state if we've recently talked to the phone (to prevent breaking syncing or bluetooth sw update)
-- have sw update prevent BLE sleep
-- manually delete characteristics/descs
-- leave lora receiver always on
-- protobufs are sometimes corrupted after sleep!
-- stay awake while charging
-- check gps battery voltage
-- if a position report includes ground truth time and we don't have time yet, set our clock from that. It is better than nothing.
-- retest BLE software update for both board types
-- report on wikifactory
-- send note to the guy who designed the cases
-- turn light sleep on aggressively (while lora is on but BLE off)
-- Use the Periodic class for both position and user periodic broadcasts
-- don't treat north as up, instead adjust shown bearings for our guess at the users heading (i.e. subtract one from the other)
-- sendToMesh can currently block for a long time, instead have it just queue a packet for a radio freertos thread
-- don't even power on bluetooth until we have some data to send to the android phone. Most of the time we should be sleeping in a lowpower "listening for lora" only mode. Once we have some packets for the phone, then power on bluetooth
-  until the phone pulls those packets. Ever so often power on bluetooth just so we can see if the phone wants to send some packets. Possibly might need ULP processor to help with this wake process.
-- do hibernation mode to get power draw down to 2.5uA https://lastminuteengineers.com/esp32-sleep-modes-power-consumption/
-- fix GPS.zeroOffset calculation it is wrong
-- (needs testing) fixed the following during a plane flight:
-  Have state machine properly enter deep sleep based on loss of mesh and phone comms.
-  Default to enter deep sleep if no LORA received for two hours (indicates user has probably left the mesh).
-- (fixed I think) text messages are not showing on local screen if screen was on
-- add links to todos
-- link to the kanban page
-- add a getting started page
-- finish mesh alg reeval
-- ublox gps parsing seems a little buggy (we shouldn't be sending out read solution commands, the device is already broadcasting them)
-- turn on gps https://github.com/sparkfun/SparkFun_Ublox_Arduino_Library/blob/master/examples/Example18_PowerSaveMode/Example18_PowerSaveMode.ino
-- switch gps to 38400 baud https://github.com/sparkfun/SparkFun_Ublox_Arduino_Library/blob/master/examples/Example11_ResetModule/Example2_FactoryDefaultsviaSerial/Example2_FactoryDefaultsviaSerial.ino
-- Use Neo-M8M API to put it in sleep mode
-- use gps sleep mode instead of killing its power (to allow fast position when we wake)
-- enable fast lock and low power inside the gps chip
-- Make a FAQ
-- add a SF12 transmit option for _super_ long range
-- figure out why this fixme is needed: "FIXME, disable wake due to PMU because it seems to fire all the time?"
-- "AXP192 interrupt is not firing, remove this temporary polling of battery state"
-- make debug info screen show real data (including battery level & charging) - close corresponding github issue
-- remeasure wake time power draws now that we run CPU down at 80MHz

docs/software/android-too-old.md

@@ -0,0 +1,7 @@
+# Your android application needs updating
+
+Hi.
+
+If you've landed here that means your android application is too old for the running device firmware.  Usually our updates are backwards compatible, but about once a year we have a "major protocol update" which requires all apps and devices to update to keep working with that version.  Version 1.2 in March 2021 was one of those updates.
+
+If you have problems/questions please post in our [forum](https://meshtastic.discourse.group) and some nice person will probably help.

docs/software/ant.md

@@ -0,0 +1,14 @@
+# ANT protocol notes
+
+SD340 terms are reasonable for NRF52
+https://www.thisisant.com/developer/components/nrf52832#tab_protocol_stacks_tab
+
+Profiles to implement:
+
+tracker
+https://www.thisisant.com/developer/ant-plus/device-profiles/#4365_tab
+
+ebike
+https://www.thisisant.com/developer/ant-plus/device-profiles/#527_tab
+
+no profile for messaging?

docs/software/build-instructions.md

@@ -1,21 +1,58 @@
 # 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.
+This project uses the simple PlatformIO build system. PlatformIO is an extension to Microsoft VSCode.  Workflows from building from the GUI or from the commandline are listed below.  
 
-1. Purchase a suitable radio (see above)
+If you encounter any problems, please post a question in [our forum](meshtastic.discourse.group).  And when you learn a fix, update these instructions for the next person (i.e. edit this file and send in a [pull-request](https://opensource.com/article/19/7/create-pull-request-github) which we will eagerly merge).
+
+## GUI
+
+1. Purchase a suitable [radio](https://github.com/meshtastic/Meshtastic-device/wiki/Hardware-Information).
+2. Install [Python](https://www.python.org/downloads/).
+3. Install [Git](https://git-scm.com/downloads).
+4. Reboot your computer.
+5. Install [PlatformIO](https://platformio.org/platformio-ide).
+6. Click the PlatformIO icon on the side bar. ![platformio icon](https://user-images.githubusercontent.com/47490997/89482668-77c7ea00-d7ee-11ea-8785-5faf8ff99800.png)
+7. Under `Quick Access, Miscellaneous, Clone Git Project` enter the URL of the Meshtastic repo found [here](https://github.com/meshtastic/Meshtastic-device). ![image](https://user-images.githubusercontent.com/47490997/89483047-4c91ca80-d7ef-11ea-91f4-1d53d4e8acd9.png) 
+8. Select a file location to save the repo.
+9. Once loaded, open the `platformio.ini` file. 
+10. At the line `default_envs` you can change it to the board type you are building for ie. `tlora-v2, tlora-v1, tlora-v2-1-1.6, tbeam, heltec, tbeam0.7` (boards are listed further down in the file).
+11. The hardware can be configured for different countries by adding a definition to the `configuration.h` file. `#define HW_VERSION_US` or `HW_VERSION_EU433, HW_VERSION_EU865, HW_VERSION_CN, HW_VERSION_JP`. Other country settings can be found in `MeshRadio.h`. The default is `HW_VERSION_US`.
+12. Click the PlatformIO icon on the side bar. Under `Project Tasks` you can now build or upload.
+
+Note - To get a clean build you may have to delete the auto-generated file `./.vscode/c_cpp_properties.json`, close and re-open Visual Studio and WAIT until the file is auto-generated before compiling again.
+
+## Command Line
+
+1. Purchase a suitable [radio](https://github.com/meshtastic/Meshtastic-device/wiki/Hardware-Information).
 2. Install [PlatformIO](https://platformio.org/platformio-ide)
-3. Download this git repo and cd into it
-4. If you are outside the USA, edit [platformio.ini](/platformio.ini) to set the correct frequency range for your country. The line you need to change starts with "hw_version" and instructions are provided above that line. Options are provided for EU433, EU835, CN, JP and US. Pull-requests eagerly accepted for other countries.
-5. Plug the radio into your USB port
-6. 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).
-7. 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.
+3. Download this git repo and cd into it:
+
+```
+git clone https://github.com/meshtastic/Meshtastic-device.git
+cd Meshtastic-device
+```
+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 `tlora-v2, tlora-v1, tlora-v2-1-1.6, tbeam, heltec, tbeam0.7`).
+8. Platform IO also installs a very nice VisualStudio Code based IDE, see their [tutorial](https://docs.platformio.org/en/latest/tutorials/espressif32/arduino_debugging_unit_testing.html) if you'd like to use it.
 
 ## Decoding stack traces
 
+### Option 1
+
 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).
+
+### Option 2
+
+You can run the exception decoder to monitor the serial output and decode backtraces in real time.
+
+1. From within PlatformIO, open a new terminal.
+2. At the the terminal, enter:
+   `pio device monitor --port /dev/cu.SLAB_USBtoUART -f esp32_exception_decoder`
+   Replace the value of port with the location of your serial port.

docs/software/channels.md

@@ -0,0 +1,17 @@
+# Multiple channel support
+
+Version 1.2 of the software adds support for "multiple (simultaneous) channels".  The idea behind this feature is that a mesh can allow multiple users/groups to be share common mesh infrastructure.  Even including routing messages for others when no one except that subgroup of users has the encryption keys for their private channel.
+
+### What is the PRIMARY channel
+
+The way this works is that each node keeps a list of channels it knows about.  One of those channels (normally the first 1) is labelled as the "PRIMARY" channel.  The primary channel is the **only** channel that is used to set radio parameters.  i.e. this channel controls things like spread factor, coding rate, bandwidth etc... Indirectly this channel also is used to select the specific frequency that all members of this mesh are talking over.
+
+This channel may or may not have a PSK (encryption).  If you are providing mesh to 'the public' we recommend that you always leave this channel with its default psk.  The default PSK is technically encrypted (and random users sniffing the ether would have to use meshtastic to decode it), but the key is included in the github source code and you should assume any 'attacker' would have it.  But for a 'public' mesh you want this, because it allows anyone using meshtastic in your area to send packets through 'your' mesh.
+
+Note: Older meshtastic applications that don't yet understand multi-channel support will only show the user this channel.  
+
+### How to use SECONDARY channels
+
+Any channel you add after that PRIMARY channel is SECONDARY.  Secondary channels are used only for encyryption and (in the case of some special applications) security.  If you would like to have a private channel over a more public mesh, you probably want to create a SECONDARY channel.  When sharing that URL with your private group you will share the "Complete URL".  The complete URL includes your secondary channel (for encryption) and the primary channel (to provide radio/mesh access).
+
+Secondary channels **must** have a PSK (encryption).

docs/software/crypto.md

@@ -5,36 +5,55 @@ 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 until
-  it is reviewed by someone smarter than us, assume it might have flaws.
+- 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).
 
-## Notes on implementation
+## 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 posession, they could either a) extract the channel key from that device or b) use that radio to listen to new communications.
+* Warning: If an attacker is able to get 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.
-
-Parameters for our CTR implementation:
-
 - Our AES key is 128 or 256 bits, shared as part of the 'Channel' specification.
-- Each SubPacket will be sent as a series of 16 byte BLOCKS.
-- The node number concatenated with the packet number is used as the NONCE. This counter 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.
-- Each 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. Note: since our packets are small counter will really never be higher than 32 (five bits).
+- 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).
 
-```
-You can encrypt separate messages by dividing the nonce_counter buffer in two areas: the first one used for a per-message nonce, handled by yourself, and the second one updated by this function internally.
-For example, you might reserve the first 12 bytes for the per-message nonce, and the last 4 bytes for internal use. In that case, before calling this function on a new message you need to set the first 12 bytes of nonce_counter to your chosen nonce value, the last 4 to 0, and nc_off to 0 (which will cause stream_block to be ignored). That way, you can encrypt at most 2**96 messages of up to 2**32 blocks each with the same key.
+### Details on the nonce encoding
 
-The per-message nonce (or information sufficient to reconstruct it) needs to be communicated with the ciphertext and must be unique. The recommended way to ensure uniqueness is to use a message counter. An alternative is to generate random nonces, but this limits the number of messages that can be securely encrypted: for example, with 96-bit random nonces, you should not encrypt more than 2**32 messages with the same key.
+(For those porting to other architectures)
+Bytes 0-3 of the nonce are the "packet number" in little-endian order
+Bytes 4-7 are currently zero
+Bytes 8-11 are the sending node ID in little-endian order
+Bytes 12-15 are currently zero
 
-Note that for both stategies, sizes are measured in blocks and that an AES block is 16 bytes.
-```
+## Comments from reviewer #1
 
-## Remaining todo
+This reviewer is a cryptography professional, but would like to remain anonymous. We thank them for their comments ;-):
 
-- Make the packet numbers 32 bit
-- Confirm the packet #s are stored in flash across deep sleep (and otherwise in in RAM)
-- Have the app change the crypto key when the user generates a new channel
-- Implement for NRF52 [NRF52](https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.0.0/lib_crypto_aes.html#sub_aes_ctr)
+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/device-api.md

@@ -1,28 +1,52 @@
-# Bluetooth API
+# Bluetooth/serial/TCP protocol 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.
+(This document describes the protocol for external API clients using our devices.  If you are interested in running your own code on the device itself, see the [on-device](plugin-api.md) documentation instead)
 
-## A note on MTU sizes
+The Device API is design to have only a simple stream of ToRadio and FromRadio packets and all polymorphism comes from the flexible set of Google Protocol Buffers which are sent over the wire. We use protocol buffers extensively both for the bluetooth API and for packets inside the mesh or when providing packets to other applications on the phone.
 
-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.
+## Streaming version
 
-## MeshBluetoothService
+This protocol is **almost** identical when it is deployed over BLE, Serial/USB or TCP (our three currently supported transports for connecting to phone/PC). Most of this document is in terms of the original BLE version, but this section describes the small changes when this API is exposed over a Streaming (non datagram) transport. The streaming version has the following changes:
+
+- We assume the stream is reliable (though the protocol will resynchronize if bytes are lost or corrupted). i.e. we do not include CRCs or error correction codes.
+- Packets always have a four byte header (described below) prefixed before each packet. This header provides framing characters and length.
+- The stream going towards the radio is only a series of ToRadio packets (with the extra 4 byte headers)
+- The stream going towards the PC is a stream of FromRadio packets (with the 4 byte headers), or if the receiver state machine does not see valid header bytes it can (optionally) print those bytes as the debug console from the radio. This allows the device to emit regular serial debugging messages (which can be understood by a terminal program) but also switch to a more structured set of protobufs once it sees that the PC client has sent a protobuf towards it.
+
+The 4 byte header is constructed to both provide framing and to not look line 'normal' 7 bit ASCII.
+
+- Byte 0: START1 (0x94)
+- Byte 1: START2 (0xc3)
+- Byte 2: MSB of protobuf length
+- Byte 3: LSB of protobuf length
+
+The receiver will validate length and if >512 it will assume the packet is corrupted and return to looking for START1. While looking for START1 any other characters are printed as "debug output". For small example implementation of this reader see the meshtastic-python implementation.
+
+## MeshBluetoothService (the BLE API)
 
 This is the main bluetooth service for the device and provides the API your app should use to get information about the mesh, send packets or provision the radio.
 
-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:
+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 (and write if incorrect) a User from "user" - to get the username for this node
+- 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 from "nodeinfo" until it returns empty to build the phone's copy of the current NodeDB for the mesh
-- Read from "fromradio" until it returns empty to get any messages that arrived for this node while the phone was away
-- Subscribe to notify on "fromnum" to get notified whenever the device has a new received packet
-- Read that new packet from "fromradio"
-- Whenever the phone has a packet to send write to "toradio"
+- 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)
 
@@ -62,16 +86,20 @@ Not all messages are kept in the fromradio queue (filtered based on SubPacket):
 - 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
+### 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.
+
+### 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
+### Other bluetooth services
 
-This document focuses on the core mesh service, but it is worth noting that the following other Bluetooth services are also
+This document focuses on the core device protocol, but it is worth noting that the following other Bluetooth services are also
 provided by the device.
 
-### BluetoothSoftwareUpdate
+#### 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).
 
@@ -85,14 +113,15 @@ Characteristics
 | 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                                            |
+| 5e134862-7411-4424-ac4a-210937432c67 | write | sets the region for programming, currently only 0 (app) or 100 (spiffs) are defined, if not set app is assumed |
 | 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
+#### DeviceInformationService
 
 Implements the standard BLE contract for this service (has software version, hardware model, serial number, etc...)
 
-### BatteryLevelService
+#### 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/esp32-arduino-build-notes.md

@@ -0,0 +1,29 @@
+# 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/
+  cp -a out/tools/sdk/* components/arduino/tools/sdk
+  cp -ar components/arduino/* ~/.platformio/packages/framework-arduinoespressif32
+  
+  /// @src-fba9d33740f719f712e9f8b07da6ea13/
+
+  or
+
+  cp -ar out/tools/sdk/* ~/.platformio/packages/framework-arduinoespressif32/tools/sdk
+
+```
+
+How to flash new bootloader
+
+```
+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
+```