Merge pull request #328 from geeksville/master

for 0.9.2

.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,
+  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

@@ -9,6 +9,8 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@master
+      - name: Checkout submodules
+        uses: textbook/git-checkout-submodule-action@master
       - name: Setup Python
         uses: actions/setup-python@master
         with:
@@ -17,5 +19,8 @@ jobs:
         run: |
           python -m pip install --upgrade pip
           pip install -U platformio
+      - name: Install extra python tools
+        run: |
+          pip install -U adafruit-nrfutil
       - name: Build
-        run: platformio run
+        run: platformio run -e tbeam -e heltec -e lora-relay-v1

.gitignore

@@ -6,6 +6,16 @@ main/credentials.h
 .vscode/*
 !.vscode/settings.json
 !.vscode/tasks.json
-!.vscode/launch.json
 !.vscode/extensions.json
-*.code-workspace
+*.code-workspace
+
+.DS_Store
+Thumbs.db
+.autotools
+.built
+.context
+.cproject
+.idea/*
+.vagrant
+
+flash.uf2

.gitmodules

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

.vscode/launch.json

@@ -1,32 +0,0 @@
-// AUTOMATICALLY GENERATED FILE. PLEASE DO NOT MODIFY IT MANUALLY
-
-// PIO Unified Debugger
-//
-// Documentation: https://docs.platformio.org/page/plus/debugging.html
-// Configuration: https://docs.platformio.org/page/projectconf/section_env_debug.html
-
-{
-    "version": "0.2.0",
-    "configurations": [
-        {
-            "type": "platformio-debug",
-            "request": "launch",
-            "name": "PIO Debug",
-            "executable": "/home/kevinh/development/meshtastic/meshtastic-esp32/.pio/build/tbeam/firmware.elf",
-            "toolchainBinDir": "/home/kevinh/.platformio/packages/toolchain-xtensa32/bin",
-            "preLaunchTask": {
-                "type": "PlatformIO",
-                "task": "Pre-Debug"
-            },
-            "internalConsoleOptions": "openOnSessionStart"
-        },
-        {
-            "type": "platformio-debug",
-            "request": "launch",
-            "name": "PIO Debug (skip Pre-Debug)",
-            "executable": "/home/kevinh/development/meshtastic/meshtastic-esp32/.pio/build/tbeam/firmware.elf",
-            "toolchainBinDir": "/home/kevinh/.platformio/packages/toolchain-xtensa32/bin",
-            "internalConsoleOptions": "openOnSessionStart"
-        }
-    ]
-}

.vscode/settings.json

@@ -47,11 +47,21 @@
         "memory_resource": "cpp",
         "optional": "cpp",
         "string_view": "cpp",
-        "cassert": "cpp"
+        "cassert": "cpp",
+        "iterator": "cpp"
     },
     "cSpell.words": [
+        "Blox",
+        "HFSR",
         "Meshtastic",
+        "NEMAGPS",
+        "Ublox",
+        "bkpt",
+        "cfsr",
         "descs",
-        "protobufs"
-    ]
+        "ocrypto",
+        "protobufs",
+        "wifi"
+    ],
+    "C_Cpp.dimInactiveRegions": 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"
+		}
+	]
+}

README.md

@@ -1,10 +1,10 @@
-# Meshtastic-esp32
+# Meshtastic-device
 
 This is the device side code for the [meshtastic.org](https://www.meshtastic.org) project.
 
 ![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,20 +14,49 @@ 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. The [TTGO T-Beam](https://www.aliexpress.com/item/4000119152086.html), [TTGO LORA32](https://www.banggood.com/LILYGO-TTGO-LORA32-868Mhz-SX1276-ESP32-Oled-Display-bluetooth-WIFI-Lora-Development-Module-Board-p-1248652.html?cur_warehouse=UK) and the [Heltec LoRa 32](https://heltec.org/project/wifi-lora-32/). Most users should buy the T-Beam and an 18650 battery (total cost less than \$35). Make sure to buy the frequency range which is legal for your country (915MHz for US/JP/AU/NZ, 470MHz for CN, 433MHz and 870MHz for EU). Getting a version that includes a screen is optional, but highly recommended.
+We currently support three models of radios.
 
-See (meshtastic.org) for 3D printable cases.
+- 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 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)
+    - [T-Beam V1](https://www.thingiverse.com/thing:3830711)
+  - Laser-cut cases
+    - [T-Beam V1](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)
+
+**Make sure to get the frequency for your country**
+
+- US/JP/AU/NZ/CA - 915MHz
+- CN - 470MHz
+- EU - 868MHz, 433MHz
+- full list of LoRa frequencies per region is available [here](https://www.thethingsnetwork.org/docs/lorawan/frequencies-by-country.html)
+
+Getting a version that includes a screen is optional, but highly recommended.
 
 ## Firmware Installation
 
 Prebuilt binaries for the supported radios are available in our [releases](https://github.com/meshtastic/Meshtastic-esp32/releases). Your initial installation has to happen over USB from your Mac, Windows or Linux PC. Once our software is installed, all future software updates happen over bluetooth from your phone.
 
+Be **very careful** to install the correct load for your board. In particular the popular 'T-BEAM' radio from TTGO is not called 'TTGO-Lora' (that is a different board). So don't install the 'TTGO-Lora' build on a TBEAM, it won't work correctly.
+
 Please post comments on our [group chat](https://meshtastic.discourse.group/) if you have problems or successes.
 
 ### Installing from a GUI - Windows and Mac
@@ -35,12 +64,13 @@ Please post comments on our [group chat](https://meshtastic.discourse.group/) if
 1. Download and unzip the latest Meshtastic firmware [release](https://github.com/meshtastic/Meshtastic-esp32/releases).
 2. Download [ESPHome Flasher](https://github.com/esphome/esphome-flasher/releases) (either x86-32bit Windows or x64-64 bit Windows).
 3. Connect your radio to your USB port and open ESPHome Flasher.
-4. If your board is not showing under Serial Port then you likely need to install the drivers for the CP210X serial chip. In Windows you can check by searching “Device Manager” and ensuring the device is shown under “Ports”. 
-5. If there is an error, download the drivers [here](https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers), then unzip and run the Installer application. 
+4. If your board is not showing under Serial Port then you likely need to install the drivers for the CP210X serial chip. In Windows you can check by searching “Device Manager” and ensuring the device is shown under “Ports”.
+5. If there is an error, download the drivers [here](https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers), then unzip and run the Installer application.
 6. In ESPHome Flasher, refresh the serial ports and select your board.
 7. Browse to the previously downloaded firmware and select the correct firmware based on the board type, country and frequency.
 8. Select Flash ESP.
-9. Once finished, the terminal should start displaying debug messages including the Bluetooth passphrase when you try connect from your phone (handy if you don’t have a screen).
+9. Once complete, “Done! Flashing is complete!” will be shown.
+10. Debug messages sent from the Meshtastic device can be viewed with a terminal program such as [PuTTY](https://www.putty.org/) (Windows only). Within PuTTY, click “Serial”, enter the “Serial line” com port (can be found at step 4), enter “Speed” as 921600, then click “Open”.
 
 ### Installing from a commandline
 
@@ -70,9 +100,12 @@ 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". For instance "./device-install.sh firmware-HELTEC-US-0.0.3.bin".
+6. Install the correct firmware for your board with `device-install.sh firmware-_board_-_country_.bin`.
+   - Example: `./device-install.sh firmware-HELTEC-US-0.0.3.bin`.
+7. To update run `device-update.sh firmware-_board_-_country_.bin`
+   - Example: `./device-update.sh firmware-HELTEC-US-0.0.3.bin`.
 
-Note: If you have previously installed meshtastic, you don't need to run this full script instead just run "esptool.py --baud 921600 write*flash 0x10000 firmware-\_board*-_country_.bin". This will be faster, also all of your current preferences will be preserved.
+Note: If you have previously installed meshtastic, you don't need to run this full script instead just run `esptool.py --baud 921600 write_flash 0x10000 firmware-_board_-_country_-_version_.bin`. This will be faster, also all of your current preferences will be preserved.
 
 You should see something like this:
 
@@ -143,14 +176,13 @@ Hard resetting via RTS pin...
 7. The board will boot and show the Meshtastic logo.
 8. Please post a comment on our chat so we know if these instructions worked for you ;-). If you find bugs/have-questions post there also - we will be rapidly iterating over the next few weeks.
 
-## Meshtastic Android app
+# Meshtastic Android app
 
-The source code for the (optional) Meshtastic Android app is [here](https://github.com/meshtastic/Meshtastic-Android).
+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.
 
-Alpha test builds are current available by opting into our alpha test group. See (www.meshtastic.org) for instructions.
+# Python API
 
-After our rate of change slows a bit, we will make beta builds available here (without needing to join the alphatest group):
-[![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)
+We offer a [python API](https://github.com/meshtastic/Meshtastic-python) that makes it easy to use these devices to provide mesh networking for your custom projects.
 
 # Development
 

bin/build-all.sh

@@ -6,6 +6,14 @@ source bin/version.sh
 
 COUNTRIES="US EU433 EU865 CN JP"
 #COUNTRIES=US
+#COUNTRIES=CN
+
+BOARDS_ESP32="tlora-v2 tlora-v1 tlora-v2-1-1.6 tbeam heltec tbeam0.7"
+
+# FIXME note nrf52840dk build is for some reason only generating a BIN file but not a HEX file nrf52840dk-geeksville is fine
+BOARDS_NRF52="lora-relay-v1"
+BOARDS="$BOARDS_ESP32 $BOARDS_NRF52"
+#BOARDS=tbeam
 
 OUTDIR=release/latest
 
@@ -19,28 +27,41 @@ rm -f $OUTDIR/bins/*
 
 # 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 
-    pio run --environment $ENV_NAME # -v
-    cp $SRCBIN $OUTDIR/bins/firmware-$ENV_NAME-$COUNTRY-$VERSION.bin
-    cp $SRCELF $OUTDIR/elfs/firmware-$ENV_NAME-$COUNTRY-$VERSION.elf
+    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 $BOARD # -v
+    SRCELF=.pio/build/$BOARD/firmware.elf
+    cp $SRCELF $OUTDIR/elfs/firmware-$BOARD-$COUNTRY-$VERSION.elf
 }
 
+# Make sure our submodules are current
+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
 
-    HWVERSTR="1.0-$COUNTRY"
-    COMMONOPTS="-DAPP_VERSION=$VERSION -DHW_VERSION_$COUNTRY -DHW_VERSION=$HWVERSTR -Wall -Wextra -Wno-missing-field-initializers -Isrc -Os -DAXP_DEBUG_PORT=Serial"
+    echo "Copying ESP32 bin files"
+    for BOARD in $BOARDS_ESP32; do
+        SRCBIN=.pio/build/$BOARD/firmware.bin
+        cp $SRCBIN $OUTDIR/bins/firmware-$BOARD-$COUNTRY-$VERSION.bin
+    done
 
-    export PLATFORMIO_BUILD_FLAGS="$COMMONOPTS"
-
-    #do_build "tbeam0.7"
-    do_build "ttgo-lora32-v2"
-    do_build "ttgo-lora32-v1"
-    do_build "tbeam"
-    do_build "heltec"
+    echo "Generating NRF52 uf2 files"
+    for BOARD in $BOARDS_NRF52; do
+        SRCHEX=.pio/build/$BOARD/firmware.hex
+        bin/uf2conv.py $SRCHEX -c -o $OUTDIR/bins/firmware-$BOARD-$COUNTRY-$VERSION.uf2 -f 0xADA52840
+    done
 done
 
 # keep the bins in archive also
@@ -59,6 +80,6 @@ Generated by bin/buildall.sh -->
 XML
 
 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
+zip --junk-paths $ARCHIVEDIR/firmware-$VERSION.zip $OUTDIR/bins/firmware-*-$VERSION.* images/system-info.bin bin/device-install.sh bin/device-update.sh
 
-echo BUILT ALL
+echo BUILT ALL

bin/device-install.sh

@@ -1,11 +1,45 @@
-#!/bin/bash
+#!/bin/sh
 
-set -e
+# Usage info
+show_help() {
+cat << EOF
+Usage: ${0##*/} [-h] [-p ESPTOOL_PORT] [-f FILENAME]
+Flash image file to device, but first erasing and writing system information"
 
-FILENAME=$1
+    -h               Display this help and exit
+    -p ESPTOOL_PORT  Set the environment variable for ESPTOOL_PORT.  If not set, ESPTOOL iterates all ports (Dangerrous).
+    -f FILENAME         The .bin file to flash.  Custom to your device type and region.
+EOF
+}
 
-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
 
+while getopts ":h:p:f:" opt; do
+    case "${opt}" in
+        h)
+            show_help
+            exit 0
+            ;;
+        p)  export ESPTOOL_PORT=${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"
+	esptool.py --baud 921600 erase_flash
+	esptool.py --baud 921600 write_flash 0x1000 system-info.bin
+	esptool.py --baud 921600 write_flash 0x10000 ${FILENAME}
+else
+	echo "Invalid file: ${FILENAME}"
+	show_help
+fi
+
+exit 0

bin/device-update.sh

@@ -0,0 +1,43 @@
+#!/bin/sh
+
+# Usage info
+show_help() {
+cat << EOF
+Usage: ${0##*/} [-h] [-p ESPTOOL_PORT] -f FILENAME
+Flash image file to device, leave existing system intact."
+
+    -h               Display this help and exit
+    -p ESPTOOL_PORT  Set the environment variable for ESPTOOL_PORT.  If not set, ESPTOOL iterates all ports (Dangerrous).
+    -f FILENAME         The .bin file to flash.  Custom to your device type and region.
+EOF
+}
+
+
+while getopts ":h:p:f:" opt; do
+    case "${opt}" in
+        h)
+            show_help
+            exit 0
+            ;;
+        p)  export ESPTOOL_PORT=${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}."
+	esptool.py --baud 921600 write_flash 0x10000 ${FILENAME}
+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/nrf52-console.sh

@@ -0,0 +1,4 @@
+
+
+# JLinkRTTViewer
+JLinkRTTClient

bin/nrf52832-gdbserver.sh

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

bin/nrf52840-gdbserver.sh

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

bin/regen-protos.sh

@@ -3,4 +3,4 @@
 echo "This script requires https://jpa.kapsi.fi/nanopb/download/ version 0.4.1"
 # 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 -I=../proto mesh.proto
+../../nanopb-0.4.1-linux-x86/generator-bin/protoc --nanopb_out=-v:../src/mesh -I=../proto mesh.proto

bin/start-terminal0.sh

@@ -1 +1 @@
-pio device monitor -b 115200
+pio device monitor -b 921600

bin/start-terminal1.sh

@@ -1 +1 @@
-pio device monitor -p /dev/ttyUSB1 -b 115200
+pio device monitor -p /dev/ttyUSB1 -b 921600

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-v1/firmware.hex -f 0xADA52840
+# cp flash.uf2 /media/kevinh/FTH*BOOT/

bin/version.sh

@@ -1,3 +1,3 @@
 
 
-export VERSION=0.4.2
+export VERSION=0.9.2

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/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

@@ -0,0 +1,46 @@
+{
+  "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-rc-clock",
+    "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/ppr.json

@@ -0,0 +1,46 @@
+{
+  "build": {
+    "arduino": {
+      "ldscript": "nrf52840_s140_v6.ld"
+    },
+    "core": "nRF5",
+    "cpu": "cortex-m4",
+    "extra_flags": "-DARDUINO_NRF52840_PPR -DNRF52840_XXAA",
+    "f_cpu": "64000000L",
+    "hwids": [["0x239A", "0x4403"]],
+    "usb_product": "PPR",
+    "mcu": "nrf52840",
+    "variant": "ppr",
+    "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 PPR (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"
+}

docs/README.md

@@ -1,7 +1,7 @@
 # What is Meshtastic?
 
-Meshtastic is a project that lets you use
-inexpensive (\$30 ish) GPS 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.
+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.
 
@@ -13,6 +13,7 @@ Note: Questions after reading this? See our new [forum](https://meshtastic.disco
 - Applications where closed source GPS communicators just won't cut it (it is easy to add features for glider pilots etc...)
 - Secure long-range communication within groups without depending on cellular providers
 - Finding your lost kids ;-)
+- Through our [python API](https://pypi.org/project/meshtastic/) use these inexpensive radios to easily add mesh networking to your own projects.
 
 [![Youtube video demo](desk-video-screenshot.png)](https://www.youtube.com/watch?v=WlNbMbVZlHI "Meshtastic early demo")
 
@@ -23,21 +24,29 @@ Not all of these features are fully implemented yet - see **important** disclaim
 - 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/).
+
 # Updates
 
-Note: Updates are happening almost daily, only major updates are listed below. For more details see our chat, github releases or the Android alpha tester emails.
+Note: Updates are happening almost daily, only major updates are listed below. For more details see our forum.
 
+- 06/24/2020 - 0.7.x Now with over 1000 android users, over 600 people using the radios and translated into 13 languages. Fairly stable and we are working through bugs to get to 1.0.
+- 06/04/2020 - 0.6.7 Beta releases of both the application and the device code are released. Features are fairly solid now with a sizable number of users.
+- 04/28/2020 - 0.6.0 [Python API](https://pypi.org/project/meshtastic/) released. Makes it easy to use meshtastic devices as "zero config / just works" mesh transport adapters for other projects.
+- 04/20/2020 - 0.4.3 Pretty solid now both for the android app and the device code. Many people have donated translations and code. Probably going to call it a beta soon.
 - 03/03/2020 - 0.0.9 of the Android app and device code is released. Still an alpha but fairly functional.
 - 02/25/2020 - 0.0.4 of the Android app is released. This is a very early alpha, see below to join the alpha-testers group.
 - 02/23/2020 - 0.0.4 release. Still very bleeding edge but much closer to the final power management, a charged T-BEAM should run for many days with this load. If you'd like to try it, we'd love your feedback. Click [here](https://github.com/meshtastic/Meshtastic-esp32/blob/master/README.md) for instructions.
@@ -45,11 +54,11 @@ Note: Updates are happening almost daily, only major updates are listed below. F
 
 ## Meshtastic Android app
 
-Once out of alpha the companion Android application will be released here:
+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)
 
-But if you want the bleeding edge app now, we'd love to have your help testing. Three steps to opt-in to the alpha- test:
+The link above will return older more stable releases. We would prefer if you join our alpha-test group, because the application is rapidly improving. Three steps to opt-in to the alpha- test:
 
 1. Join [this Google group](https://groups.google.com/forum/#!forum/meshtastic-alpha-testers) with the account you use in Google Play.
 2. Go to this [URL](https://play.google.com/apps/testing/com.geeksville.mesh) to opt-in to the alpha test.
@@ -57,10 +66,13 @@ But if you want the bleeding edge app now, we'd love to have your help testing.
 
 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).
 

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/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 ;-)
-- Encryption is turned off for now
+- 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/software/TODO.md

@@ -1,207 +1,82 @@
-# 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.
+Nimble tasks:
 
-- remeasure wake time power draws now that we run CPU down at 80MHz
+- readerror.txt stress test bug
+- started RPA long test, jul 22 6pm
+- implement nimble software update api
+- update to latest bins, test OTA again (measure times) and then checkin bins
+- do alpha release
 
-# AXP192 tasks
-
-- 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
+* update protocol description per cyclomies email thread
+* 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
 
 # Medium priority
 
-Items to complete before the first beta release.
+Items to complete before 1.0.
 
-- 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
-- add basic crypto - https://github.com/chegewara/esp32-mbedtls-aes-test/blob/master/main/main.c https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation - use ECB at first (though it is shit) because it doesn't require us to send 16 bytes of IV with each packet. Then OFB per example. Possibly do this crypto at the data payload level only, so that all of the packet routing metadata
-  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
+# Post 1.0 ideas
 
-# Pre-beta priority
-
-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)
+- 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
-- reneable the bluetooth battery level service on the T-BEAM, because we can read battery level there
+- re-enable the bluetooth battery level service on the T-BEAM
+- provide generalized (but slow) internet message forwarding service if one of our nodes has internet connectivity (MQTT) [ Not a requirement but a personal interest ]
+
+# Low priority ideas
+
+Items after the first final candidate release.
+
+- implement nimble battery level service
+- Nimble implement device info service remaining fields (hw version etc)
+- Turn on RPA addresses for the device side in Nimble
+- Try to teardown less of the Nimble protocol stack across sleep
+- dynamic frequency scaling could save a lot of power on ESP32, but it seems to corrupt uart (even with ref_tick set correctly)
+- Change back to using a fixed sized MemoryPool rather than MemoryDynamic (see bug #149)
+- scan to find channels with low background noise? (Use CAD mode of the RF95 to automatically find low noise channels)
+- If the phone doesn't read fromradio mailbox within X seconds, assume the phone is gone and we can stop queing location msgs
+  for it (because it will redownload the nodedb when it comes back)
+- add frequency hopping, dependent on the gps time, make the switch moment far from the time anyone is going to be transmitting
+- assign every "channel" a random shared 8 bit sync word (per 4.2.13.6 of datasheet) - use that word to filter packets before even checking CRC. This will ensure our CPU will only wake for packets on our "channel"
+- the BLE stack is leaking about 200 bytes each time we go to light sleep
+- use fuse bits to store the board type and region. So one load can be used on all boards
+- Don't store position packets in the to phone fifo if we are disconnected. The phone will get that info for 'free' when it
+  fetches the fresh nodedb.
+- Use the RFM95 sequencer to stay in idle mode most of the time, then automatically go to receive mode and automatically go from transmit to receive mode. See 4.2.8.2 of manual.
+- Use fixed32 for node IDs, packetIDs, successid, failid, and lat/lon - will require all nodes to be updated, but make messages slightly smaller.
+- add "store and forward" support for messages, or move to the DB sync model. This would allow messages to be eventually delivered even if nodes are out of contact at the moment.
+- use variable length Strings in protobufs (instead of current fixed buffers). This would save lots of RAM
+- use BLEDevice::setPower to lower our BLE transmit power - extra range doesn't help us, it costs amps and it increases snoopability
+- make a HAM build: just a new frequency list, a bool to say 'never do encryption' and use hte callsign as that node's unique id. -from Girts
+- don't forward redundant pings or ping responses to the phone, it just wastes phone battery
+- don't send location packets if we haven't moved significantly
+- scrub default radio config settings for bandwidth/range/speed
+- show radio and gps signal strength as an image
+- only BLE advertise for a short time after the screen is on and button pressed - to save power and prevent people for sniffing for our BT app.
+- make mesh aware network timing state machine (sync wake windows to gps time) - this can save LOTS of battery
+- split out the software update utility so other projects can use it. Have the appload specify the URL for downloads.
+- read the PMU battery fault indicators and blink/led/warn user on screen
+- discard very old nodedb records (> 1wk)
+- handle millis() rollover in GPS.getTime - otherwise we will break after 50 days
+- report esp32 device code bugs back to the mothership via android
+- change BLE bonding to something more secure. see comment by pSecurity->setAuthenticationMode(ESP_LE_AUTH_BOND)
+
+Changes related to wifi support on ESP32:
+
+- iram space: https://esp32.com/viewtopic.php?t=8460
+- set https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/external-ram.html spi ram bss
+- figure out if iram or bluetooth classic caused ble problems
+- post bug on esp32-arduino with BLE bug findings
 
 # Spinoff project ideas
 
 - an open source version of https://www.burnair.ch/skynet/
 - a paragliding app like http://airwhere.co.uk/
-- 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

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/bluetooth-api.md

@@ -1,110 +0,0 @@
-# Bluetooth API
-
-The Bluetooth API is design to have only a few characteristics and most polymorphism comes from the flexible set of Google Protocol Buffers which are sent over the wire.  We use protocol buffers extensively both for the bluetooth API and for packets inside the mesh or when providing packets to other applications on the phone.
-
-## A note on MTU sizes
-
-This device will work with any MTU size, but it is highly recommended that you call your phone's "setMTU function to increase MTU to 512 bytes" as soon as you connect to a service.  This will dramatically improve performance when reading/writing packets.
-
-## MeshBluetoothService 
-
-This is the main bluetooth service for the device and provides the API your app should use to get information about the mesh, send packets or provision the radio.  
-
-For a reference implementation of a client that uses this service see [RadioInterfaceService](https://github.com/meshtastic/Meshtastic-Android/blob/master/app/src/main/java/com/geeksville/mesh/service/RadioInterfaceService.kt).  Typical flow when 
-a phone connects to the device should be the following:
-
-* SetMTU size to 512
-* 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 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"
-
-For definitions (and documentation) on FromRadio, ToRadio, MyNodeInfo, NodeInfo and User  protocol buffers see [mesh.proto](https://github.com/meshtastic/Meshtastic-protobufs/blob/master/mesh.proto)
-
-UUID for the service: 6ba1b218-15a8-461f-9fa8-5dcae273eafd
-
-Each characteristic is listed as follows:
-
-UUID
-Properties
-Description (including human readable name)
-
-8ba2bcc2-ee02-4a55-a531-c525c5e454d5
-read
-fromradio - contains a newly received FromRadio packet destined towards the phone (up to MAXPACKET bytes per packet).
-After reading the esp32 will put the next packet in this mailbox.  If the FIFO is empty it will put an empty packet in this
-mailbox.
-
-f75c76d2-129e-4dad-a1dd-7866124401e7
-write
-toradio - write ToRadio protobufs to this characteristic to send them (up to MAXPACKET len)
-
-ed9da18c-a800-4f66-a670-aa7547e34453
-read,notify,write
-fromnum - the current packet # in the message waiting inside fromradio, if the phone sees this notify it should read messages
-until it catches up with this number.
-
-The phone can write to this register to go backwards up to FIXME packets, to handle the rare case of a fromradio packet was dropped after the esp32 callback was called, but before it arrives at the phone.  If the phone writes to this register the esp32 will discard older packets and put the next packet >= fromnum in fromradio.
-When the esp32 advances fromnum, it will delay doing the notify by 100ms, in the hopes that the notify will never actally need to be sent if the phone is already pulling from fromradio.
-
-Note: that if the phone ever sees this number decrease, it means the esp32 has rebooted.
-
-ea9f3f82-8dc4-4733-9452-1f6da28892a2
-read
-mynode - read this to access a MyNodeInfo protobuf
-
-d31e02e0-c8ab-4d3f-9cc9-0b8466bdabe8
-read, write
-nodeinfo - read this to get a series of NodeInfos (ending with a null empty record), write to this to restart the read statemachine that returns all the node infos
-
-b56786c8-839a-44a1-b98e-a1724c4a0262
-read,write
-radio - read/write this to access a RadioConfig protobuf
-
-6ff1d8b6-e2de-41e3-8c0b-8fa384f64eb6
-read,write
-owner - read/write this to access a User protobuf
-
-Re: queue management
-Not all messages are kept in the fromradio queue (filtered based on SubPacket):
-* only the most recent Position and User messages for a particular node are kept
-* all Data SubPackets are kept
-* No WantNodeNum / DenyNodeNum messages are kept
-A variable keepAllPackets, if set to true will suppress this behavior and instead keep everything for forwarding to the phone (for debugging)
-
-
-## Other bluetooth services
-
-This document focuses on the core mesh service, but it is worth noting that the following other Bluetooth services are also
-provided by the device.
-
-### BluetoothSoftwareUpdate
-
-The software update service.  For a sample function that performs a software update using this API see [startUpdate](https://github.com/meshtastic/Meshtastic-Android/blob/master/app/src/main/java/com/geeksville/mesh/service/SoftwareUpdateService.kt).
-
-SoftwareUpdateService UUID cb0b9a0b-a84c-4c0d-bdbb-442e3144ee30
-
-Characteristics
-
-| UUID                                 | properties       | description|
-|--------------------------------------|------------------|------------|
-| e74dd9c0-a301-4a6f-95a1-f0e1dbea8e1e | write,read       | total image size, 32 bit, write this first, then read read back to see if it was acceptable (0 mean not accepted) |
-| e272ebac-d463-4b98-bc84-5cc1a39ee517 | write            | data, variable sized, recommended 512 bytes, write one for each block of file |
-| 4826129c-c22a-43a3-b066-ce8f0d5bacc6 | write            | crc32, write last - writing this will complete the OTA operation, now you can read result |
-| 5e134862-7411-4424-ac4a-210937432c77 | read,notify      | result code, readable but will notify when the OTA operation completes |
-| GATT_UUID_SW_VERSION_STR/0x2a28 | read | We also implement these standard GATT entries because SW update probably needs them: |
-| GATT_UUID_MANU_NAME/0x2a29 | read | |
-| GATT_UUID_HW_VERSION_STR/0x2a27 | read | |
-
-### DeviceInformationService
-
-Implements the standard BLE contract for this service (has software version, hardware model, serial number, etc...)
-
-### BatteryLevelService
-
-Implements the standard BLE contract service, provides battery level in a way that most client devices should automatically understand (i.e. it should show in the bluetooth devices screen automatically)

docs/software/build-instructions.md

@@ -1,15 +1,31 @@
 # 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.
 
-1. Purchase a suitable radio (see above)
+## GUI
+1. Purchase a suitable [radio](https://github.com/meshtastic/Meshtastic-device/wiki/Hardware-Information).
+2. Install [PlatformIO](https://platformio.org/platformio-ide).
+3. Click the PlatformIO icon on the side bar. ![platformio icon](https://user-images.githubusercontent.com/47490997/89482668-77c7ea00-d7ee-11ea-8785-5faf8ff99800.png)
+4. 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) 
+5. Select a file location to save the repo.
+6. Once loaded, open the `platformio.ini` file. 
+7. 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).
+8. Click the PlatformIO icon on the side bar. Under `Project Tasks` you can now build or upload.
+
+## 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
 

docs/software/crypto.md

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

docs/software/device-api.md

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

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

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

docs/software/mesh-alg.md

@@ -1,19 +1,163 @@
 # Mesh broadcast algorithm
 
-FIXME - instead look for standard solutions. this approach seems really suboptimal, because too many nodes will try to rebroast. If
-all else fails could always use the stock Radiohead solution - though super inefficient.
+## Current algorithm
+
+The routing protocol for Meshtastic is really quite simple (and suboptimal). It is heavily influenced by the mesh routing algorithm used in [Radiohead](https://www.airspayce.com/mikem/arduino/RadioHead/) (which was used in very early versions of this project). It has four conceptual layers.
+
+### A note about protocol buffers
+
+Because we want our devices to work across various vendors and implementations, we use [Protocol Buffers](https://github.com/meshtastic/Meshtastic-protobufs) pervasively. For information on how the protocol buffers are used wrt API clients see [sw-design](sw-design.md), for purposes of this document you mostly only
+need to consider the MeshPacket and Subpacket message types.
+
+### Layer 1: Non reliable zero hop messaging
+
+This layer is conventional non-reliable lora packet transmission. The transmitted packet has the following representation on the ether:
+
+- A 32 bit LORA preamble (to allow receiving radios to synchronize clocks and start framing). We use a longer than minimum (8 bit) preamble to maximize the amount of time the LORA receivers can stay asleep, which dramatically lowers power consumption.
+
+After the preamble the 16 byte packet header is transmitted. This header is described directly by the PacketHeader class in the C++ source code. But indirectly it matches the first portion of the "MeshPacket" protobuf definition. But notably: this portion of the packet is sent directly as the following 16 bytes (rather than using the protobuf encoding). We do this to both save airtime and to allow receiving radio hardware the option of filtering packets before even waking the main CPU.
+
+- to (4 bytes): the unique NodeId of the destination (or 0xffffffff for NodeNum_BROADCAST)
+- from (4 bytes): the unique NodeId of the sender)
+- id (4 bytes): the unique (wrt the sending node only) packet ID number for this packet. We use a large (32 bit) packet ID to ensure there is enough unique state to protect any encrypted payload from attack.
+- flags (4 bytes): Only a few bits are are currently used - 3 bits for for the "HopLimit" (see below) and 1 bit for "WantAck"
+
+After the packet header the actual packet is placed onto the the wire. These bytes are merely the encrypted packed protobuf encoding of the SubPacket protobuf. A full description of our encryption is available in [crypto](crypto.md). It is worth noting that only this SubPacket is encrypted, headers are not. Which leaves open the option of eventually allowing nodes to route packets without knowing the keys used to encrypt.
+
+NodeIds are constructed from the bottom four bytes of the macaddr of the bluetooth address. Because the OUI is assigned by the IEEE and we currently only support a few CPU manufacturers, the upper byte is defacto guaranteed unique for each vendor. The bottom 3 bytes are guaranteed unique by that vendor.
+
+To prevent collisions all transmitters will listen before attempting to send. If they hear some other node transmitting, they will reattempt transmission in x milliseconds. This retransmission delay is random between FIXME and FIXME (these two numbers are currently hardwired, but really should be scaled based on expected packet transmission time at current channel settings).
+
+### Layer 2: Reliable zero hop messaging
+
+This layer adds reliable messaging between the node and its immediate neighbors (only).
+
+The default messaging provided by layer-1 is extended by setting the "want-ack" flag in the MeshPacket protobuf. If want-ack is set the following documentation from mesh.proto applies:
+
+"""This packet is being sent as a reliable message, we would prefer it to arrive
+at the destination. We would like to receive a ack packet in response.
+
+Broadcasts messages treat this flag specially: Since acks for broadcasts would
+rapidly flood the channel, the normal ack behavior is suppressed. Instead,
+the original sender listens to see if at least one node is rebroadcasting this
+packet (because naive flooding algorithm). If it hears that the odds (given
+typical LoRa topologies) the odds are very high that every node should
+eventually receive the message. So FloodingRouter.cpp generates an implicit
+ack which is delivered to the original sender. If after some time we don't
+hear anyone rebroadcast our packet, we will timeout and retransmit, using the
+regular resend logic."""
+
+If a transmitting node does not receive an ACK (or a NAK) packet within FIXME milliseconds, it will use layer-1 to attempt a retransmission of the sent packet. A reliable packet (at this 'zero hop' level) will be resent a maximum of three times. If no ack or nak has been received by then the local node will internally generate a nak (either for local consumption or use by higher layers of the protocol).
+
+### Layer 3: (Naive) flooding for multi-hop messaging
+
+Given our use-case for the initial release, most of our protocol is built around [flooding](<https://en.wikipedia.org/wiki/Flooding_(computer_networking)>). The implementation is currently 'naive' - i.e. it doesn't try to optimize flooding other than abandoning retransmission once we've seen a nearby receiver has acked the packet. Therefore, for each source packet up to N retransmissions might occur (if there are N nodes in the mesh).
+
+Each node in the mesh, if it sees a packet on the ether with HopLimit set to a value other than zero, it will decrement that HopLimit and attempt retransmission on behalf of the original sending node.
+
+### Layer 4: DSR for multi-hop unicast messaging
+
+This layer is not yet fully implemented (and not yet used). But eventually (if we stay with our own transport rather than switching to QMesh or Reticulum)
+we will use conventional DSR for unicast messaging. Currently (even when not requiring 'broadcasts') we send any multi-hop unicasts as 'broadcasts' so that we can
+leverage our (functional) flooding implementation. This is suboptimal but it is a very rare use-case, because the odds are high that most nodes (given our small networks and 'hiking' use case) are within a very small number of hops. When any node witnesses an ack for a packet, it will realize that it can abandon its own
+broadcast attempt for that packet.
+
+## Misc notes on remaining tasks
+
+This section is currently poorly formatted, it is mostly a mere set of todo lists and notes for @geeksville during his initial development. After release 1.0 ideas for future optimization include:
+
+- Make flood-routing less naive (because we have GPS and radio signal strength as heuristics to avoid redundant retransmissions)
+- If nodes have been user marked as 'routers', preferentially do flooding via those nodes
+- Fully implement DSR to improve unicast efficiency (or switch to QMesh/Reticulum as these projects mature)
 
 great source of papers and class notes: http://www.cs.jhu.edu/~cs647/
 
+flood routing improvements
+
+- DONE if we don't see anyone rebroadcast our want_ack=true broadcasts, retry as needed.
+
+reliable messaging tasks (stage one for DSR):
+
+- DONE generalize naive flooding
+- DONE add a max hops parameter, use it for broadcast as well (0 means adjacent only, 1 is one forward etc...). Store as three bits in the header.
+- DONE add a 'snoopReceived' hook for all messages that pass through our node.
+- DONE use the same 'recentmessages' array used for broadcast msgs to detect duplicate retransmitted messages.
+- DONE in the router receive path?, send an ack packet if want_ack was set and we are the final destination. FIXME, for now don't handle multihop or merging of data replies with these acks.
+- DONE keep a list of packets waiting for acks
+- DONE for each message keep a count of # retries (max of three). Local to the node, only for the most immediate hop, ignorant of multihop routing.
+- DONE delay some random time for each retry (large enough to allow for acks to come in)
+- DONE once an ack comes in, remove the packet from the retry list and deliver the ack to the original sender
+- DONE after three retries, deliver a no-ack packet to the original sender (i.e. the phone app or mesh router service)
+- DONE test one hop ack/nak with the python framework
+- DONE Do stress test with acks
+
+dsr tasks
+
+- DONE oops I might have broken message reception
+- DONE Don't use broadcasts for the network pings (close open github issue)
+- DONE add ignoreSenders to radioconfig to allow testing different mesh topologies by refusing to see certain senders
+- DONE test multihop delivery with the python framework
+
+optimizations / low priority:
+
+- read this [this](http://pages.cs.wisc.edu/~suman/pubs/nadv-mobihoc05.pdf) paper and others and make our naive flood routing less naive
+- read @cyclomies long email with good ideas on optimizations and reply
+- DONE Remove NodeNum assignment algorithm (now that we use 4 byte node nums)
+- DONE make android app warn if firmware is too old or too new to talk to
+- change nodenums and packetids in protobuf to be fixed32
+- low priority: think more careful about reliable retransmit intervals
+- make ReliableRouter.pending threadsafe
+- bump up PacketPool size for all the new ack/nak/routing packets
+- handle 51 day rollover in doRetransmissions
+- use a priority queue for the messages waiting to send. Send acks first, then routing messages, then data messages, then broadcasts?
+
+when we send a packet
+
+- do "hop by hop" routing
+- when sending, if destnodeinfo.next_hop is zero (and no message is already waiting for an arp for that node), startRouteDiscovery() for that node. Queue the message in the 'waiting for arp queue' so we can send it later when then the arp completes.
+- otherwise, use next_hop and start sending a message (with ack request) towards that node (starting with next_hop).
+
+when we receive any packet
+
+- sniff and update tables (especially useful to find adjacent nodes). Update user, network and position info.
+- if we need to route() that packet, resend it to the next_hop based on our nodedb.
+- if it is broadcast or destined for our node, deliver locally
+- handle routereply/routeerror/routediscovery messages as described below
+- then free it
+
+routeDiscovery
+
+- if we've already passed through us (or is from us), then it ignore it
+- use the nodes already mentioned in the request to update our routing table
+- if they were looking for us, send back a routereply
+- NOT DOING FOR NOW -if max_hops is zero and they weren't looking for us, drop (FIXME, send back error - I think not though?)
+- if we receive a discovery packet, and we don't have next_hop set in our nodedb, we use it to populate next_hop (if needed) towards the requester (after decrementing max_hops)
+- if we receive a discovery packet, and we have a next_hop in our nodedb for that destination we send a (reliable) we send a route reply towards the requester
+
+when sending any reliable packet
+
+- if timeout doing retries, send a routeError (nak) message back towards the original requester. all nodes eavesdrop on that packet and update their route caches.
+
+when we receive a routereply packet
+
+- update next_hop on the node, if the new reply needs fewer hops than the existing one (we prefer shorter paths). fixme, someday use a better heuristic
+
+when we receive a routeError packet
+
+- delete the route for that failed recipient, restartRouteDiscovery()
+- if we receive routeerror in response to a discovery,
+- fixme, eventually keep caches of possible other routes.
+
 TODO:
 
-- DONE reread the radiohead mesh implementation - hop to hop acknoledgement seems VERY expensive but otherwise it seems like DSR
+- optimize our generalized flooding with heuristics, possibly have particular nodes self mark as 'router' nodes.
+
+- DONE reread the radiohead mesh implementation - hop to hop acknowledgement seems VERY expensive but otherwise it seems like DSR
 - DONE read about mesh routing solutions (DSR and AODV)
 - DONE read about general mesh flooding solutions (naive, MPR, geo assisted)
 - DONE reread the disaster radio protocol docs - seems based on Babel (which is AODVish)
-- possibly dash7? https://www.slideshare.net/MaartenWeyn1/dash7-alliance-protocol-technical-presentation https://github.com/MOSAIC-LoPoW/dash7-ap-open-source-stack - does the opensource stack implement multihop routing? flooding? their discussion mailing list looks dead-dead
+- REJECTED - seems dying - possibly dash7? https://www.slideshare.net/MaartenWeyn1/dash7-alliance-protocol-technical-presentation https://github.com/MOSAIC-LoPoW/dash7-ap-open-source-stack - does the opensource stack implement multihop routing? flooding? their discussion mailing list looks dead-dead
 - update duty cycle spreadsheet for our typical usecase
-- generalize naive flooding on top of radiohead or disaster.radio? (and fix radiohead to use my new driver)
 
 a description of DSR: https://tools.ietf.org/html/rfc4728 good slides here: https://www.slideshare.net/ashrafmath/dynamic-source-routing
 good description of batman protocol: https://www.open-mesh.org/projects/open-mesh/wiki/BATMANConcept
@@ -72,24 +216,3 @@ look into the literature for this idea specifically.
   build the most recent version of reality, and if some nodes are too far, then nodes closer in will eventually forward their changes to the distributed db.
 - construct non ambigious rules for who broadcasts to request db updates. ideally the algorithm should nicely realize node X can see most other nodes, so they should just listen to all those nodes and minimize the # of broadcasts. the distributed picture of nodes rssi could be useful here?
 - possibly view the BLE protocol to the radio the same way - just a process of reconverging the node/msgdb database.
-
-# Old notes
-
-FIXME, merge into the above:
-
-
-good description of batman protocol: https://www.open-mesh.org/projects/open-mesh/wiki/BATMANConcept
-
-interesting paper on lora mesh: https://portal.research.lu.se/portal/files/45735775/paper.pdf
-It seems like DSR might be the algorithm used by RadioheadMesh. DSR is described in https://tools.ietf.org/html/rfc4728
-https://en.wikipedia.org/wiki/Dynamic_Source_Routing
-
-broadcast solution:
-Use naive flooding at first (FIXME - do some math for a 20 node, 3 hop mesh. A single flood will require a max of 20 messages sent)
-Then move to MPR later (http://www.olsr.org/docs/report_html/node28.html). Use altitude and location as heursitics in selecting the MPR set
-
-compare to db sync algorithm?
-
-what about never flooding gps broadcasts. instead only have them go one hop in the common case, but if any node X is looking at the position of Y on their gui, then send a unicast to Y asking for position update. Y replies.
-
-If Y were to die, at least the neighbor nodes of Y would have their last known position of Y.

docs/software/nrf52-TODO.md

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

docs/software/pinetab.md

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

docs/software/power.md

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

docs/software/rak815.md

@@ -0,0 +1,6 @@
+# RAK815
+
+Notes on trying to get the RAK815 working with meshtastic.
+
+good tutorial: https://www.hackster.io/naresh-krish/getting-started-with-rak815-tracker-module-and-arduino-1c7bc9
+(includes software serial link - possibly useful for GPS)

docs/software/ramusage-nrf52.txt

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

docs/software/read-error.txt

@@ -0,0 +1,148 @@
+nimble stress test error (private notes for @geeksville)
+
+findings:
+only happens when stress testing multiple sleepwake cycles?
+failed packets all have initial mbuflen of zero (should be 1)
+restarting the connection on phone sometimes (but not always) fixes it (is the larger config nonce pushing packet size up too large?)
+- packets >= 79 bytes (FromRadio) cause INVALID_OFFSET (7) gatt errors to be sent to the app
+- some packets are missing
+
+theory:
+some sort of leak in mbuf storage during unfortunately timed sleep shutdowns
+
+
+device side
+
+
+connection updated; status=0 handle=0 our_ota_addr_type=0 our_ota_addr=00:24:62:ab:dd:df
+ our_id_addr_type=0 our_id_addr=00:24:62:ab:dd:df
+ peer_ota_addr_type=0 peer_ota_addr=00:7c:d9:5c:ba:2e
+ peer_id_addr_type=0 peer_id_addr=00:7c:d9:5c:ba:2e
+ conn_itvl=36 conn_latency=0 supervision_timeout=500 encrypted=1 authenticated=1 bonded=1
+
+BLE fromRadio called
+getFromRadio, !available
+toRadioWriteCb data 0x3ffc3d72, len 4
+Trigger powerFSM 9
+Transition powerFSM transition=Contact from phone, from=DARK to=DARK
+Client wants config, nonce=6864
+Reset nodeinfo read pointer
+toRadioWriteCb data 0x3ffc3d72, len 4
+Trigger powerFSM 9
+Transition powerFSM transition=Contact from phone, from=DARK to=DARK
+Client wants config, nonce=6863
+Reset nodeinfo read pointer
+BLE fromRadio called
+getFromRadio, state=2
+encoding toPhone packet to phone variant=3, 50 bytes
+BLE fromRadio called
+getFromRadio, state=3
+encoding toPhone packet to phone variant=6, 83 bytes
+BLE fromRadio called
+getFromRadio, state=4
+Sending nodeinfo: num=0xabdddf38, lastseen=1595606850, id=!2462abdddf38, name=Bob b
+encoding toPhone packet to phone variant=4, 67 bytes
+BLE fromRadio called
+getFromRadio, state=4
+Sending nodeinfo: num=0x28b200b4, lastseen=1595606804, id=!246f28b200b4, name=Unknown 00b4
+encoding toPhone packet to phone variant=4, 80 bytes
+BLE fromRadio called
+getFromRadio, state=4
+Sending nodeinfo: num=0xabf84098, lastseen=1593680756, id=!2462abf84098, name=bx n
+encoding toPhone packet to phone variant=4, 72 bytes
+BLE fromRadio called
+getFromRadio, state=4
+Sending nodeinfo: num=0x83f0d8e5, lastseen=1594686931, id=!e8e383f0d8e5, name=Unknown d8e5
+encoding toPhone packet to phone variant=4, 64 bytes
+BLE fromRadio called
+getFromRadio, state=4
+Sending nodeinfo: num=0xd1dc7764, lastseen=1595602082, id=!f008d1dc7764, name=dg
+encoding toPhone packet to phone variant=4, 52 bytes
+BLE fromRadio called
+getFromRadio, state=4
+Sending nodeinfo: num=0xd1dc7828, lastseen=1595598298, id=!f008d1dc7828, name=ryan 
+encoding toPhone packet to phone variant=4, 54 bytes
+BLE fromRadio called
+getFromRadio, state=4
+Done sending nodeinfos
+getFromRadio, state=5
+
+
+
+phone side
+
+2020-07-24 09:11:00.642 6478-6545/com.geeksville.mesh W/com.geeksville.mesh.service.BluetoothInterface: Attempting reconnect
+2020-07-24 09:11:00.642 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: connect
+2020-07-24 09:11:00.642 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: connect
+2020-07-24 09:11:00.643 6478-6545/com.geeksville.mesh D/BluetoothGatt: connect() - device: 24:62:AB:DD:DF:3A, auto: false
+2020-07-24 09:11:00.643 6478-6545/com.geeksville.mesh D/BluetoothGatt: registerApp()
+2020-07-24 09:11:00.643 6478-6545/com.geeksville.mesh D/BluetoothGatt: registerApp() - UUID=026baf7f-d2de-43f1-961f-4e00e04c6fbb
+2020-07-24 09:11:00.645 6478-27868/com.geeksville.mesh D/BluetoothGatt: onClientRegistered() - status=0 clientIf=4
+2020-07-24 09:11:01.022 6478-27868/com.geeksville.mesh D/BluetoothGatt: onClientConnectionState() - status=0 clientIf=4 device=24:62:AB:DD:DF:3A
+2020-07-24 09:11:01.022 6478-27868/com.geeksville.mesh I/com.geeksville.mesh.service.SafeBluetooth: new bluetooth connection state 2, status 0
+2020-07-24 09:11:01.023 6478-27868/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work connect is completed, resuming status=0, res=kotlin.Unit
+2020-07-24 09:11:01.023 6478-6545/com.geeksville.mesh I/com.geeksville.mesh.service.BluetoothInterface: Connected to radio!
+2020-07-24 09:11:01.023 6478-6545/com.geeksville.mesh D/BluetoothGatt: refresh() - device: 24:62:AB:DD:DF:3A
+2020-07-24 09:11:01.526 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: discover
+2020-07-24 09:11:01.526 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: discover
+2020-07-24 09:11:01.526 6478-6545/com.geeksville.mesh D/BluetoothGatt: discoverServices() - device: 24:62:AB:DD:DF:3A
+2020-07-24 09:11:01.829 6478-27868/com.geeksville.mesh D/BluetoothGatt: onConnectionUpdated() - Device=24:62:AB:DD:DF:3A interval=6 latency=0 timeout=500 status=0
+2020-07-24 09:11:02.008 6478-27868/com.geeksville.mesh D/BluetoothGatt: onSearchComplete() = Device=24:62:AB:DD:DF:3A Status=0
+2020-07-24 09:11:02.009 6478-27868/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work discover is completed, resuming status=0, res=kotlin.Unit
+2020-07-24 09:11:02.009 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: Discovered services!
+2020-07-24 09:11:02.095 6478-27868/com.geeksville.mesh D/BluetoothGatt: onConnectionUpdated() - Device=24:62:AB:DD:DF:3A interval=36 latency=0 timeout=500 status=0
+2020-07-24 09:11:03.010 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.RadioInterfaceService: Broadcasting connection=true
+2020-07-24 09:11:03.012 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
+2020-07-24 09:11:03.012 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
+2020-07-24 09:11:03.012 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Received broadcast com.geeksville.mesh.CONNECT_CHANGED
+2020-07-24 09:11:03.012 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: onConnectionChanged=CONNECTED
+2020-07-24 09:11:03.012 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Starting config nonce=6878
+2020-07-24 09:11:03.013 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: queuing 4 bytes to f75c76d2-129e-4dad-a1dd-7866124401e7 *** sending start config
+2020-07-24 09:11:03.013 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: writeC f75c76d2-129e-4dad-a1dd-7866124401e7
+2020-07-24 09:11:03.015 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Received broadcast com.geeksville.mesh.CONNECT_CHANGED
+2020-07-24 09:11:03.015 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: onConnectionChanged=CONNECTED
+2020-07-24 09:11:03.015 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Starting config nonce=6877
+2020-07-24 09:11:03.016 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: device sleep timeout cancelled
+2020-07-24 09:11:03.016 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: queuing 4 bytes to f75c76d2-129e-4dad-a1dd-7866124401e7
+2020-07-24 09:11:03.016 6478-6545/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: writeC f75c76d2-129e-4dad-a1dd-7866124401e7
+2020-07-24 09:11:03.130 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: writeC f75c76d2-129e-4dad-a1dd-7866124401e7
+2020-07-24 09:11:03.132 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5 is completed, resuming status=0, res=android.bluetooth.BluetoothGattCharacteristic@556a315
+2020-07-24 09:11:03.132 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: Done reading from radio, fromradio is empty
+2020-07-24 09:11:03.132 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: starting setNotify(ed9da18c-a800-4f66-a670-aa7547e34453, true) *** start notify
+2020-07-24 09:11:03.132 6478-19966/com.geeksville.mesh D/BluetoothGatt: setCharacteristicNotification() - uuid: ed9da18c-a800-4f66-a670-aa7547e34453 enable: true
+2020-07-24 09:11:03.133 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: writeD  
+2020-07-24 09:11:03.220 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: writeC f75c76d2-129e-4dad-a1dd-7866124401e7
+2020-07-24 09:11:03.221 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work writeC f75c76d2-129e-4dad-a1dd-7866124401e7 is completed, resuming status=0, res=android.bluetooth.BluetoothGattCharacteristic@2d2062a
+2020-07-24 09:11:03.221 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: write of 4 bytes completed
+2020-07-24 09:11:03.221 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
+2020-07-24 09:11:03.310 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: writeD
+2020-07-24 09:11:03.311 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work writeC f75c76d2-129e-4dad-a1dd-7866124401e7 is completed, resuming status=0, res=android.bluetooth.BluetoothGattCharacteristic@2d2062a
+2020-07-24 09:11:03.311 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: write of 4 bytes completed
+2020-07-24 09:11:03.400 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
+2020-07-24 09:11:03.402 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work writeD is completed, resuming status=0, res=android.bluetooth.BluetoothGattDescriptor@fc99c1b
+2020-07-24 09:11:03.402 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Notify enable=true completed
+2020-07-24 09:11:03.769 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5 is completed, resuming status=0, res=android.bluetooth.BluetoothGattCharacteristic@556a315
+2020-07-24 09:11:03.769 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: Received 80 bytes from radio **** received an 80 byte fromradio.  Why did we miss three previous reads?
+2020-07-24 09:11:03.774 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
+2020-07-24 09:11:03.774 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
+2020-07-24 09:11:03.774 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Received broadcast com.geeksville.mesh.RECEIVE_FROMRADIO
+2020-07-24 09:11:03.776 6478-6478/com.geeksville.mesh E/com.geeksville.mesh.service.MeshService: Invalid Protobuf from radio, len=80 (exception Protocol message had invalid UTF-8.)
+2020-07-24 09:11:03.776 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Received broadcast com.geeksville.mesh.RECEIVE_FROMRADIO
+2020-07-24 09:11:03.776 6478-6478/com.geeksville.mesh E/com.geeksville.mesh.service.MeshService: Invalid Protobuf from radio, len=80 (exception Protocol message had invalid UTF-8.)
+2020-07-24 09:11:04.031 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5 is completed, resuming status=0, res=android.bluetooth.BluetoothGattCharacteristic@556a315
+2020-07-24 09:11:04.031 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.BluetoothInterface: Received 52 bytes from radio *** received 52 bytes - where did the previous two read results go?
+2020-07-24 09:11:04.033 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: Enqueuing work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
+2020-07-24 09:11:04.033 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth$BluetoothContinuation: Starting work: readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
+2020-07-24 09:11:04.034 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Received broadcast com.geeksville.mesh.RECEIVE_FROMRADIO
+2020-07-24 09:11:04.035 6478-6478/com.geeksville.mesh E/com.geeksville.mesh.service.MeshService: Invalid Protobuf from radio, len=52 (exception While parsing a protocol message, the input ended unexpectedly in the middle of a field.  This could mean either that the input has been truncated or that an embedded message misreported its own length.)
+2020-07-24 09:11:04.036 6478-6478/com.geeksville.mesh D/com.geeksville.mesh.service.MeshService: Received broadcast com.geeksville.mesh.RECEIVE_FROMRADIO
+2020-07-24 09:11:04.036 6478-6478/com.geeksville.mesh E/com.geeksville.mesh.service.MeshService: Invalid Protobuf from radio, len=52 (exception While parsing a protocol message, the input ended unexpectedly in the middle of a field.  This could mean either that the input has been truncated or that an embedded message misreported its own length.)
+2020-07-24 09:11:04.210 6478-19966/com.geeksville.mesh D/com.geeksville.mesh.service.SafeBluetooth: work readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5 is completed, resuming status=7, res=android.bluetooth.BluetoothGattCharacteristic@556a315 *** read failed
+2020-07-24 09:11:04.211 6478-19966/com.geeksville.mesh W/com.geeksville.mesh.service.BluetoothInterface: Scheduling reconnect because error during doReadFromRadio - disconnecting, Bluetooth status=7 while doing readC 8ba2bcc2-ee02-4a55-a531-c525c5e454d5
+2020-07-24 09:11:04.211 6478-6545/com.geeksville.mesh W/com.geeksville.mesh.service.BluetoothInterface: Forcing disconnect and hopefully device will comeback (disabling forced refresh)
+2020-07-24 09:11:04.211 6478-6545/com.geeksville.mesh I/com.geeksville.mesh.service.SafeBluetooth: Closing our GATT connection
+2020-07-24 09:11:04.211 6478-6545/com.geeksville.mesh D/BluetoothGatt: cancelOpen() - device: 24:62:AB:DD:DF:3A
+2020-07-24 09:11:04.214 6478-19966/com.geeksville.mesh D/BluetoothGatt: onClientConnectionState() - status=0 clientIf=4 device=24:62:AB:DD:DF:3A
+2020-07-24 09:11:04.215 6478-19966/com.geeksville.mesh I/com.geeksville.mesh.service.SafeBluetooth: new bluetooth connection state 0, status 0
+2020-07-24 09:11:04.215 6478-19966/com.geeksville.mesh I/com.geeksville.mesh.service.SafeBluetooth: Got disconnect because we are shutting down, closing gatt
+2020-07-24 09:11:04.215 6478-19966/com.geeksville.mesh D/BluetoothGatt: close()

gdbinit

@@ -0,0 +1,19 @@
+
+# Setup Monitor Mode Debugging
+# Per .platformio/packages/framework-arduinoadafruitnrf52-old/cores/nRF5/linker/nrf52840_s140_v6.ld
+# our appload starts at 0x26000
+# Disable for now because our version on board doesn't support monitor mode debugging
+# mon exec SetMonModeDebug=1
+# mon exec SetMonModeVTableAddr=0x26000
+
+# echo setting RTTAddr
+# eval "monitor exec SetRTTAddr %p", &_SEGGER_RTT
+
+# the jlink debugger seems to want a pause after reset before we tell it to start running
+define restart
+  echo Restarting
+  monitor reset 
+  shell sleep 1
+  cont 
+end
+

lib/BluetoothOTA/src/BluetoothSoftwareUpdate.cpp

@@ -1,158 +0,0 @@
-#include "BluetoothUtil.h"
-#include "BluetoothSoftwareUpdate.h"
-#include "configuration.h"
-#include <esp_gatt_defs.h>
-#include <BLE2902.h>
-#include <Arduino.h>
-#include <Update.h>
-#include <CRC32.h>
-#include "CallbackCharacteristic.h"
-
-CRC32 crc;
-uint32_t rebootAtMsec = 0; // If not zero we will reboot at this time (used to reboot shortly after the update completes)
-
-class TotalSizeCharacteristic : public CallbackCharacteristic
-{
-public:
-    TotalSizeCharacteristic()
-        : CallbackCharacteristic("e74dd9c0-a301-4a6f-95a1-f0e1dbea8e1e", BLECharacteristic::PROPERTY_WRITE | BLECharacteristic::PROPERTY_READ)
-    {
-    }
-
-    void onWrite(BLECharacteristic *c)
-    {
-        BLEKeepAliveCallbacks::onWrite(c);
-
-        // Check if there is enough to OTA Update
-        uint32_t len = getValue32(c, 0);
-        crc.reset();
-        bool canBegin = Update.begin(len);
-        DEBUG_MSG("Setting update size %u, result %d\n", len, canBegin);
-        if (!canBegin)
-            // Indicate failure by forcing the size to 0
-            c->setValue(0UL);
-        else {
-            // This totally breaks abstraction to up up into the app layer for this, but quick hack to make sure we only
-            // talk to one service during the sw update.
-            //DEBUG_MSG("FIXME, crufty shutdown of mesh bluetooth for sw update.");
-            //void stopMeshBluetoothService();
-            //stopMeshBluetoothService();
-        }
-    }
-};
-
-class DataCharacteristic : public CallbackCharacteristic
-{
-public:
-    DataCharacteristic()
-        : CallbackCharacteristic(
-              "e272ebac-d463-4b98-bc84-5cc1a39ee517", BLECharacteristic::PROPERTY_WRITE)
-    {
-    }
-
-    void onWrite(BLECharacteristic *c)
-    {
-        BLEKeepAliveCallbacks::onWrite(c);
-
-        std::string value = c->getValue();
-        uint32_t len = value.length();
-        uint8_t *data = c->getData();
-        // DEBUG_MSG("Writing %u\n", len);
-        crc.update(data, len);
-        Update.write(data, len);
-    }
-};
-
-static BLECharacteristic *resultC;
-
-class CRC32Characteristic : public CallbackCharacteristic
-{
-public:
-    CRC32Characteristic()
-        : CallbackCharacteristic(
-              "4826129c-c22a-43a3-b066-ce8f0d5bacc6", BLECharacteristic::PROPERTY_WRITE)
-    {
-    }
-
-    void onWrite(BLECharacteristic *c)
-    {
-        BLEKeepAliveCallbacks::onWrite(c);
-
-        uint32_t expectedCRC = getValue32(c, 0);
-        DEBUG_MSG("expected CRC %u\n", expectedCRC);
-
-        uint8_t result = 0xff;
-
-        // Check the CRC before asking the update to happen.
-        if (crc.finalize() != expectedCRC)
-        {
-            DEBUG_MSG("Invalid CRC!\n");
-            result = 0xe0; // FIXME, use real error codes
-        }
-        else
-        {
-            if (Update.end())
-            {
-                DEBUG_MSG("OTA done, rebooting in 5 seconds!\n");
-                rebootAtMsec = millis() + 5000;
-            }
-            else
-            {
-                DEBUG_MSG("Error Occurred. Error #: %d\n", Update.getError());
-            }
-            result = Update.getError();
-        }
-        assert(resultC);
-        resultC->setValue(&result, 1);
-        resultC->notify();
-    }
-};
-
-
-
-void bluetoothRebootCheck()
-{
-    if (rebootAtMsec && millis() > rebootAtMsec)
-        ESP.restart();
-}
-
-/*
-See bluetooth-api.md
-
- */
-BLEService *createUpdateService(BLEServer *server, std::string hwVendor, std::string swVersion, std::string hwVersion)
-{
-    // Create the BLE Service
-    BLEService *service = server->createService(BLEUUID("cb0b9a0b-a84c-4c0d-bdbb-442e3144ee30"), 25, 0);
-
-    assert(!resultC);
-    resultC = new BLECharacteristic("5e134862-7411-4424-ac4a-210937432c77", BLECharacteristic::PROPERTY_READ | BLECharacteristic::PROPERTY_NOTIFY);
-
-    addWithDesc(service, new TotalSizeCharacteristic, "total image size");
-    addWithDesc(service, new DataCharacteristic, "data");
-    addWithDesc(service, new CRC32Characteristic, "crc32");
-    addWithDesc(service, resultC, "result code");
-
-    resultC->addDescriptor(addBLEDescriptor(new BLE2902())); // Needed so clients can request notification
-
-    BLECharacteristic *swC = new BLECharacteristic(BLEUUID((uint16_t)ESP_GATT_UUID_SW_VERSION_STR), BLECharacteristic::PROPERTY_READ);
-    swC->setValue(swVersion);
-    service->addCharacteristic(addBLECharacteristic(swC));
-
-    BLECharacteristic *mfC = new BLECharacteristic(BLEUUID((uint16_t)ESP_GATT_UUID_MANU_NAME), BLECharacteristic::PROPERTY_READ);
-    mfC->setValue(hwVendor);
-    service->addCharacteristic(addBLECharacteristic(mfC));
-
-    BLECharacteristic *hwvC = new BLECharacteristic(BLEUUID((uint16_t)ESP_GATT_UUID_HW_VERSION_STR), BLECharacteristic::PROPERTY_READ);
-    hwvC->setValue(hwVersion);
-    service->addCharacteristic(addBLECharacteristic(hwvC));
-
-    return service;
-}
-
-void destroyUpdateService()
-{
-    assert(resultC);
-
-    resultC = NULL;
-}

lib/BluetoothOTA/src/BluetoothSoftwareUpdate.h

@@ -1,8 +0,0 @@
-#pragma once
-
-#include <Arduino.h>
-
-BLEService *createUpdateService(BLEServer* server, std::string hwVendor, std::string swVersion, std::string hwVersion);
-
-void destroyUpdateService();
-void bluetoothRebootCheck();

lib/BluetoothOTA/src/BluetoothUtil.cpp

@@ -1,312 +0,0 @@
-#include "BluetoothUtil.h"
-#include "BluetoothSoftwareUpdate.h"
-#include <esp_gatt_defs.h>
-#include <BLE2902.h>
-#include <Arduino.h>
-#include <Update.h>
-#include "configuration.h"
-
-SimpleAllocator btPool;
-
-/**
- * Create standard device info service
- **/
-BLEService *createDeviceInfomationService(BLEServer *server, std::string hwVendor, std::string swVersion, std::string hwVersion = "")
-{
-  BLEService *deviceInfoService = server->createService(BLEUUID((uint16_t)ESP_GATT_UUID_DEVICE_INFO_SVC));
-
-  BLECharacteristic *swC = new BLECharacteristic(BLEUUID((uint16_t)ESP_GATT_UUID_SW_VERSION_STR), BLECharacteristic::PROPERTY_READ);
-  BLECharacteristic *mfC = new BLECharacteristic(BLEUUID((uint16_t)ESP_GATT_UUID_MANU_NAME), BLECharacteristic::PROPERTY_READ);
-  // BLECharacteristic SerialNumberCharacteristic(BLEUUID((uint16_t) ESP_GATT_UUID_SERIAL_NUMBER_STR), BLECharacteristic::PROPERTY_READ);
-
-  /*
-	 * Mandatory characteristic for device info service?
-	 
-	BLECharacteristic *m_pnpCharacteristic = m_deviceInfoService->createCharacteristic(ESP_GATT_UUID_PNP_ID, BLECharacteristic::PROPERTY_READ);
-
-    uint8_t sig, uint16_t vid, uint16_t pid, uint16_t version;
-	uint8_t pnp[] = { sig, (uint8_t) (vid >> 8), (uint8_t) vid, (uint8_t) (pid >> 8), (uint8_t) pid, (uint8_t) (version >> 8), (uint8_t) version };
-	m_pnpCharacteristic->setValue(pnp, sizeof(pnp));
-    */
-  swC->setValue(swVersion);
-  deviceInfoService->addCharacteristic(addBLECharacteristic(swC));
-  mfC->setValue(hwVendor);
-  deviceInfoService->addCharacteristic(addBLECharacteristic(mfC));
-  if (!hwVersion.empty())
-  {
-    BLECharacteristic *hwvC = new BLECharacteristic(BLEUUID((uint16_t)ESP_GATT_UUID_HW_VERSION_STR), BLECharacteristic::PROPERTY_READ);
-    hwvC->setValue(hwVersion);
-    deviceInfoService->addCharacteristic(addBLECharacteristic(hwvC));
-  }
-  //SerialNumberCharacteristic.setValue("FIXME");
-  //deviceInfoService->addCharacteristic(&SerialNumberCharacteristic);
-
-  // m_manufacturerCharacteristic = m_deviceInfoService->createCharacteristic((uint16_t) 0x2a29, BLECharacteristic::PROPERTY_READ);
-  // m_manufacturerCharacteristic->setValue(name);
-
-  /* add these later?
-    ESP_GATT_UUID_SYSTEM_ID
-    */
-
-  // caller must call service->start();
-  return deviceInfoService;
-}
-
-bool _BLEClientConnected = false;
-
-class MyServerCallbacks : public BLEServerCallbacks
-{
-  void onConnect(BLEServer *pServer)
-  {
-    _BLEClientConnected = true;
-  };
-
-  void onDisconnect(BLEServer *pServer)
-  {
-    _BLEClientConnected = false;
-  }
-};
-
-#define MAX_DESCRIPTORS 32
-#define MAX_CHARACTERISTICS 32
-
-static BLECharacteristic *chars[MAX_CHARACTERISTICS];
-static size_t numChars;
-static BLEDescriptor *descs[MAX_DESCRIPTORS];
-static size_t numDescs;
-
-/// Add a characteristic that we will delete when we restart
-BLECharacteristic *addBLECharacteristic(BLECharacteristic *c)
-{
-  assert(numChars < MAX_CHARACTERISTICS);
-  chars[numChars++] = c;
-  return c;
-}
-
-/// Add a characteristic that we will delete when we restart
-BLEDescriptor *addBLEDescriptor(BLEDescriptor *c)
-{
-  assert(numDescs < MAX_DESCRIPTORS);
-  descs[numDescs++] = c;
-
-  return c;
-}
-
-// Help routine to add a description to any BLECharacteristic and add it to the service
-// We default to require an encrypted BOND for all these these characterstics
-void addWithDesc(BLEService *service, BLECharacteristic *c, const char *description)
-{
-  c->setAccessPermissions(ESP_GATT_PERM_READ_ENCRYPTED | ESP_GATT_PERM_WRITE_ENCRYPTED);
-
-  BLEDescriptor *desc = new BLEDescriptor(BLEUUID((uint16_t)ESP_GATT_UUID_CHAR_DESCRIPTION), strlen(description) + 1);
-  assert(desc);
-  desc->setAccessPermissions(ESP_GATT_PERM_READ_ENCRYPTED | ESP_GATT_PERM_WRITE_ENCRYPTED);
-  desc->setValue(description);
-  c->addDescriptor(desc);
-  service->addCharacteristic(c);
-  addBLECharacteristic(c);
-  addBLEDescriptor(desc);
-}
-
-static BLECharacteristic *batteryLevelC;
-
-/**
- * Create a battery level service
- */
-BLEService *createBatteryService(BLEServer *server)
-{
-  // Create the BLE Service
-  BLEService *pBattery = server->createService(BLEUUID((uint16_t)0x180F));
-
-  batteryLevelC = new BLECharacteristic(BLEUUID((uint16_t)ESP_GATT_UUID_BATTERY_LEVEL), BLECharacteristic::PROPERTY_READ | BLECharacteristic::PROPERTY_NOTIFY);
-
-  addWithDesc(pBattery, batteryLevelC, "Percentage 0 - 100");
-  batteryLevelC->addDescriptor(addBLEDescriptor(new BLE2902())); // Needed so clients can request notification
-
-  // I don't think we need to advertise this
-  // server->getAdvertising()->addServiceUUID(pBattery->getUUID());
-  pBattery->start();
-
-  return pBattery;
-}
-
-/**
- * Update the battery level we are currently telling clients.
- * level should be a pct between 0 and 100
- */
-void updateBatteryLevel(uint8_t level)
-{
-  // Pretend to update battery levels - fixme do elsewhere
-  if (batteryLevelC)
-  {
-    batteryLevelC->setValue(&level, 1);
-    batteryLevelC->notify();
-  }
-}
-
-void dumpCharacteristic(BLECharacteristic *c)
-{
-  std::string value = c->getValue();
-
-  if (value.length() > 0)
-  {
-    DEBUG_MSG("New value: ");
-    for (int i = 0; i < value.length(); i++)
-      DEBUG_MSG("%c", value[i]);
-
-    DEBUG_MSG("\n");
-  }
-}
-
-/** converting endianness pull out a 32 bit value */
-uint32_t getValue32(BLECharacteristic *c, uint32_t defaultValue)
-{
-  std::string value = c->getValue();
-  uint32_t r = defaultValue;
-
-  if (value.length() == 4)
-    r = value[0] | (value[1] << 8UL) | (value[2] << 16UL) | (value[3] << 24UL);
-
-  return r;
-}
-
-class MySecurity : public BLESecurityCallbacks
-{
- protected:
-  bool onConfirmPIN(uint32_t pin)
-  {
-    Serial.printf("onConfirmPIN %u\n", pin);
-    return false;
-  }
-
-  uint32_t onPassKeyRequest()
-  {
-    Serial.println("onPassKeyRequest");
-    return 123511; // not used
-  }
-
-  void onPassKeyNotify(uint32_t pass_key)
-  {
-    Serial.printf("onPassKeyNotify %u\n", pass_key);
-    startCb(pass_key);
-  }
-
-  bool onSecurityRequest()
-  {
-    Serial.println("onSecurityRequest");
-    return true;
-  }
-
-  void onAuthenticationComplete(esp_ble_auth_cmpl_t cmpl)
-  {
-    if (cmpl.success)
-    {
-      uint16_t length;
-      esp_ble_gap_get_whitelist_size(&length);
-      Serial.printf(" onAuthenticationComplete -> success size: %d\n", length);
-    }
-    else
-    {
-      Serial.printf("onAuthenticationComplete -> fail %d\n", cmpl.fail_reason);
-    }
-
-    // Remove our custom PIN request screen.
-    stopCb();
-  }
-
- public:
-  StartBluetoothPinScreenCallback startCb;
-  StopBluetoothPinScreenCallback stopCb;
-};
-
-BLEServer *pServer;
-
-BLEService *pDevInfo, *pUpdate;
-
-void deinitBLE()
-{
-  assert(pServer);
-
-  pServer->getAdvertising()->stop();
-
-  destroyUpdateService();
-
-  pUpdate->stop();
-  pDevInfo->stop();
-  pUpdate->stop(); // we delete them below
-
-  // First shutdown bluetooth
-  BLEDevice::deinit(false);
-
-  // do not delete this - it is dynamically allocated, but only once - statically in BLEDevice
-  // delete pServer->getAdvertising();
-
-  delete pUpdate;
-  delete pDevInfo;
-  delete pServer;
-
-  batteryLevelC = NULL; // Don't let anyone generate bogus notifies
-
-  for (int i = 0; i < numChars; i++)
-    delete chars[i];
-  numChars = 0;
-
-  for (int i = 0; i < numDescs; i++)
-    delete descs[i];
-  numDescs = 0;
-
-  btPool.reset();
-}
-
-BLEServer *initBLE(
-    StartBluetoothPinScreenCallback startBtPinScreen,
-    StopBluetoothPinScreenCallback stopBtPinScreen,
-    std::string deviceName, std::string hwVendor, std::string swVersion, std::string hwVersion)
-{
-  BLEDevice::init(deviceName);
-  BLEDevice::setEncryptionLevel(ESP_BLE_SEC_ENCRYPT);
-
-  /*
-   * Required in authentication process to provide displaying and/or input passkey or yes/no butttons confirmation
-   */
-  static MySecurity mySecurity;
-  mySecurity.startCb = startBtPinScreen;
-  mySecurity.stopCb = stopBtPinScreen;
-  BLEDevice::setSecurityCallbacks(&mySecurity);
-
-  // Create the BLE Server
-  pServer = BLEDevice::createServer();
-  static MyServerCallbacks myCallbacks;
-  pServer->setCallbacks(&myCallbacks);
-
-  pDevInfo = createDeviceInfomationService(pServer, hwVendor, swVersion, hwVersion);
-
-  // We now let users create the battery service only if they really want (not all devices have a battery)
-  // BLEService *pBattery = createBatteryService(pServer);
-
-  pUpdate = createUpdateService(pServer, hwVendor, swVersion, hwVersion); // We need to advertise this so our android ble scan operation can see it
-
-  // It seems only one service can be advertised - so for now don't advertise our updater
-  // pServer->getAdvertising()->addServiceUUID(pUpdate->getUUID());
-
-  // start all our services (do this after creating all of them)
-  pDevInfo->start();
-  pUpdate->start();
-
-  // FIXME turn on this restriction only after the device is paired with a phone
-  // advert->setScanFilter(false, true); // We let anyone scan for us (FIXME, perhaps only allow that until we are paired with a phone and configured) but only let whitelist phones connect
-
-  static BLESecurity security; // static to avoid allocs
-  BLESecurity *pSecurity = &security;
-  pSecurity->setCapability(ESP_IO_CAP_OUT);
-  pSecurity->setAuthenticationMode(ESP_LE_AUTH_REQ_SC_BOND);
-  pSecurity->setInitEncryptionKey(ESP_BLE_ENC_KEY_MASK | ESP_BLE_ID_KEY_MASK);
-
-  return pServer;
-}
-
-// Called from loop
-void loopBLE()
-{
-  bluetoothRebootCheck();
-}

lib/BluetoothOTA/src/BluetoothUtil.h

@@ -1,39 +0,0 @@
-#pragma once
-
-#include <functional>
-
-#include <Arduino.h>
-#include <BLEDevice.h>
-#include <BLEServer.h>
-#include <BLEUtils.h>
-#include "SimpleAllocator.h"
-
-// Now handled by BluetoothUtil.cpp
-// BLEService *createDeviceInfomationService(BLEServer* server, uint8_t sig, uint16_t vid, uint16_t pid, uint16_t version);
-
-// Help routine to add a description to any BLECharacteristic and add it to the service
-void addWithDesc(BLEService *service, BLECharacteristic *c, const char *description);
-
-void dumpCharacteristic(BLECharacteristic *c);
-
-/** converting endianness pull out a 32 bit value */
-uint32_t getValue32(BLECharacteristic *c, uint32_t defaultValue);
-
-// TODO(girts): create a class for the bluetooth utils helpers?
-using StartBluetoothPinScreenCallback = std::function<void(uint32_t pass_key)>;
-using StopBluetoothPinScreenCallback = std::function<void(void)>;
-
-void loopBLE();
-BLEServer *initBLE(
-    StartBluetoothPinScreenCallback startBtPinScreen, StopBluetoothPinScreenCallback stopBtPinScreen,
-    std::string devName, std::string hwVendor, std::string swVersion, std::string hwVersion = "");
-void deinitBLE();
-
-/// Add a characteristic that we will delete when we restart
-BLECharacteristic *addBLECharacteristic(BLECharacteristic *c);
-
-/// Add a characteristic that we will delete when we restart
-BLEDescriptor *addBLEDescriptor(BLEDescriptor *c);
-
-/// Any bluetooth objects you allocate _must_ come from this pool if you want to be able to call deinitBLE()
-extern SimpleAllocator btPool;

lib/BluetoothOTA/src/CallbackCharacteristic.h

@@ -1,33 +0,0 @@
-#pragma once
-#include "PowerFSM.h" // FIXME - someday I want to make this OTA thing a separate lb at at that point it can't touch this
-#include "BLECharacteristic.h"
-
-/**
- * This mixin just lets the power management state machine know the phone is still talking to us
- */
-class BLEKeepAliveCallbacks : public BLECharacteristicCallbacks
-{
-public:
-    void onRead(BLECharacteristic *c)
-    {
-        powerFSM.trigger(EVENT_CONTACT_FROM_PHONE);
-    }
-
-    void onWrite(BLECharacteristic *c)
-    {
-        powerFSM.trigger(EVENT_CONTACT_FROM_PHONE);
-    }
-};
-
-/**
- * A characterstic with a set of overridable callbacks
- */
-class CallbackCharacteristic : public BLECharacteristic, public BLEKeepAliveCallbacks
-{
-public:
-    CallbackCharacteristic(const char *uuid, uint32_t btprops)
-        : BLECharacteristic(uuid, btprops)
-    {
-        setCallbacks(this);
-    }
-};

lib/nanopb/include/pb.h

@@ -11,7 +11,7 @@
  *****************************************************************/
 
 /* Enable support for dynamically allocated fields */
-/* #define PB_ENABLE_MALLOC 1 */
+#define PB_ENABLE_MALLOC 1
 
 /* Define this if your CPU / compiler combination does not support
  * unaligned memory access to packed structures. */

linker/esp32.extram.bss.ld

@@ -0,0 +1,18 @@
+/* This section is only included if CONFIG_SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY
+   is set, to link some sections to BSS in PSRAM */
+
+SECTIONS
+{
+   /* external memory bss, from any global variable with EXT_RAM_ATTR attribute*/
+  .ext_ram.bss (NOLOAD) :
+  {
+    _ext_ram_bss_start = ABSOLUTE(.);
+    *(.ext_ram.bss*)
+    *libnet80211.a:(.dynsbss .sbss .sbss.* .gnu.linkonce.sb.* .scommon .sbss2.* .gnu.linkonce.sb2.* .dynbss .bss .bss.* .share.mem .gnu.linkonce.b.* COMMON)
+    *libpp.a:(.dynsbss .sbss .sbss.* .gnu.linkonce.sb.* .scommon .sbss2.* .gnu.linkonce.sb2.* .dynbss .bss .bss.* .share.mem .gnu.linkonce.b.* COMMON)
+    *liblwip.a:(.dynsbss .sbss .sbss.* .gnu.linkonce.sb.* .scommon .sbss2.* .gnu.linkonce.sb2.* .dynbss .bss .bss.* .share.mem .gnu.linkonce.b.* COMMON)
+    *libbt.a:(EXCLUDE_FILE (libbtdm_app.a) .dynsbss .sbss .sbss.* .gnu.linkonce.sb.* .scommon .sbss2.* .gnu.linkonce.sb2.* .dynbss .bss .bss.* .share.mem .gnu.linkonce.b.* COMMON)
+    . = ALIGN(4);
+    _ext_ram_bss_end = ABSOLUTE(.);
+  } > extern_ram_seg
+}

linker/nrf52840_s140_sim832.ld

@@ -0,0 +1,46 @@
+/* Linker script to configure memory regions. 
+
+geeksville: modified this to simulate a nrf52832 but with a sd140 soft device.  So I can 
+see how the memory footprint works on this lower end CPU.  Note: to work with sd140 in my bootloader 
+I need to start ram at 0x6000 (instead of the correct 0x3600 for sd132) - so I have less
+RAM available than on a real 832.
+*/
+
+SEARCH_DIR(.)
+GROUP(-lgcc -lc -lnosys)
+
+MEMORY
+{
+  FLASH (rx)     : ORIGIN = 0x26000, LENGTH = 0x6D000 - 0x26000
+  /* FLASH (rx)     : ORIGIN = 0x26000, LENGTH = 0xED000 - 0x26000 */
+
+  /* SRAM required by S132 depend on
+   * - Attribute Table Size
+   * - Vendor UUID count
+   * - Max ATT MTU
+   * - Concurrent connection peripheral + central + secure links
+   * - Event Len, HVN queue, Write CMD queue
+   */ 
+  /* RAM (rwx) :  ORIGIN = 0x20003600, LENGTH = 0x20010000 - 0x20003600 */
+  RAM (rwx) :  ORIGIN = 0x20006000, LENGTH = 0x20010000 - 0x20006000
+}
+ 
+SECTIONS
+{
+  . = ALIGN(4);
+  .svc_data :
+  {
+    PROVIDE(__start_svc_data = .);
+    KEEP(*(.svc_data))
+    PROVIDE(__stop_svc_data = .);
+  } > RAM
+  
+  .fs_data :
+  {
+    PROVIDE(__start_fs_data = .);
+    KEEP(*(.fs_data))
+    PROVIDE(__stop_fs_data = .);
+  } > RAM
+} INSERT AFTER .data;
+
+INCLUDE "nrf52_common.ld"

platformio.ini

@@ -9,15 +9,20 @@
 ; https://docs.platformio.org/page/projectconf.html
 
 [platformio]
-default_envs = tbeam
+default_envs = tbeam # lora-relay-v1
 
 [common]
-; default to a US frequency range, change it as needed for your region and hardware (CN, JP, EU433, EU865)
-hw_version = US
+; common is not currently used
 
+; REQUIRED environment variables - if not set the specified default will be sued
+; The following environment variables must be set in the shell if you'd like to override them.
+; They are used in this ini file as systenv.VARNAME, so in your shell do export "VARNAME=fish"
+; COUNTRY (default US), i.e. "export COUNTRY=EU865"
+; APP_VERSION (default emptystring)
+; HW_VERSION (default emptystring)
 
 [env]
-platform = espressif32
+
 framework = arduino
 
 ; customize the partition table
@@ -26,14 +31,10 @@ board_build.partitions = partition-table.csv
 
 ; note: we add src to our include search path so that lmic_project_config can override
 ; FIXME: fix lib/BluetoothOTA dependency back on src/ so we can remove -Isrc
-build_flags = -Wno-missing-field-initializers -Isrc -Isrc/rf95 -Os -Wl,-Map,.pio/build/output.map -DAXP_DEBUG_PORT=Serial -DHW_VERSION_${common.hw_version}
-
-; not needed included in ttgo-t-beam board file
-; also to use PSRAM https://docs.platformio.org/en/latest/platforms/espressif32.html#external-ram-psram
-;  -DBOARD_HAS_PSRAM
-;  -mfix-esp32-psram-cache-issue
-
-; -DLOG_LOCAL_LEVEL=ESP_LOG_DEBUG -DCORE_DEBUG_LEVEL=ARDUHAL_LOG_LEVEL_DEBUG
+build_flags = -Wno-missing-field-initializers -Isrc -Isrc/mesh -Isrc/gps -Ilib/nanopb/include -Os -Wl,-Map,.pio/build/output.map 
+  -DHW_VERSION_${sysenv.COUNTRY}
+  -DAPP_VERSION=${sysenv.APP_VERSION}
+  -DHW_VERSION=${sysenv.HW_VERSION}
 
 ; leave this commented out to avoid breaking Windows
 ;upload_port = /dev/ttyUSB0
@@ -42,7 +43,8 @@ build_flags = -Wno-missing-field-initializers -Isrc -Isrc/rf95 -Os -Wl,-Map,.pio
 ; the default is esptool
 ; upload_protocol = esp-prog
 
-monitor_speed = 115200
+; monitor_speed = 115200
+monitor_speed = 921600
 
 # debug_tool = esp-prog
 # debug_port = /dev/ttyACM0
@@ -59,20 +61,38 @@ debug_tool = jlink
 lib_deps =
   https://github.com/meshtastic/esp8266-oled-ssd1306.git ; ESP8266_SSD1306 
   SPI
-  ; 1260 ; OneButton - not used yet
+  1260 ; OneButton library for non-blocking button debounce
   1202 ; CRC32, explicitly needed because dependency is missing in the ble ota update lib
   Wire ; explicitly needed here because the AXP202 library forgets to add it
   https://github.com/meshtastic/arduino-fsm.git 
   https://github.com/meshtastic/SparkFun_Ublox_Arduino_Library.git
+  https://github.com/meshtastic/RadioLib.git#d6b12f7eb0a06bd2414c79b437b25d377e3f603f
+  https://github.com/meshtastic/TinyGPSPlus.git 
+  https://github.com/meshtastic/AXP202X_Library.git#8404abb6d4b486748636bc6ad72d2a47baaf5460
 
 ; Common settings for ESP targes, mixin with extends = esp32_base
 [esp32_base]
+platform = espressif32
 src_filter = 
-  ${env.src_filter} -<bare/>
+  ${env.src_filter} -<nrf52/>
 upload_speed = 921600
 debug_init_break = tbreak setup
 build_flags =
-  ${env.build_flags} -Wall -Wextra
+  ${env.build_flags} -Wall -Wextra -Isrc/esp32 -mfix-esp32-psram-cache-issue -lnimble -std=c++11 
+  -DLOG_LOCAL_LEVEL=ESP_LOG_DEBUG -DCORE_DEBUG_LEVEL=ARDUHAL_LOG_LEVEL_DEBUG
+  -DAXP_DEBUG_PORT=Serial
+# Hmm - this doesn't work yet
+# board_build.ldscript = linker/esp32.extram.bss.ld
+lib_ignore = segger_rtt
+platform_packages =
+    framework-arduinoespressif32 @ https://github.com/meshtastic/arduino-esp32.git#1adba3f11ca8406ac0a704d151697b572058b53d
+
+; not needed included in ttgo-t-beam board file
+; also to use PSRAM https://docs.platformio.org/en/latest/platforms/espressif32.html#external-ram-psram
+;  -DBOARD_HAS_PSRAM
+;  -mfix-esp32-psram-cache-issue
+
+; -DLOG_LOCAL_LEVEL=ESP_LOG_DEBUG -DCORE_DEBUG_LEVEL=ARDUHAL_LOG_LEVEL_DEBUG
 
 ; The 1.0 release of the TBEAM board
 [env:tbeam]
@@ -80,49 +100,134 @@ extends = esp32_base
 board = ttgo-t-beam
 lib_deps =
   ${env.lib_deps}
-  AXP202X_Library
 build_flags = 
   ${esp32_base.build_flags} -D TBEAM_V10
 
 ; The original TBEAM board without the AXP power chip and a few other changes
 ; Note: I've heard reports this didn't work.  Disabled until someone with a 0.7 can test and debug.
-;[env:tbeam0.7]
-;extends = esp32_base
-;board = ttgo-t-beam
-;build_flags = 
-;  ${esp32_base.build_flags} -D TBEAM_V07
+[env:tbeam0.7]
+extends = esp32_base
+board = ttgo-t-beam
+build_flags = 
+  ${esp32_base.build_flags} -D TBEAM_V07
 
 [env:heltec]
 ;build_type = debug ; to make it possible to step through our jtag debugger 
 extends = esp32_base
 board = heltec_wifi_lora_32_V2
 
-[env:ttgo-lora32-v1]
+[env:tlora-v1]
 extends = esp32_base
 board = ttgo-lora32-v1
 build_flags = 
-  ${esp32_base.build_flags} -D TTGO_LORA_V1
+  ${esp32_base.build_flags} -D TLORA_V1
 
 ; note: the platformio definition for lora32-v2 seems stale, it is missing a pins_arduino.h file, therefore I don't think it works
-[env:ttgo-lora32-v2]
+[env:tlora-v2]
 extends = esp32_base
 board = ttgo-lora32-v1
 build_flags = 
-  ${esp32_base.build_flags} -D TTGO_LORA_V2
+  ${esp32_base.build_flags} -D TLORA_V2
 
-
-; This is a temporary build target to test turning off particular hardare bits in the build (to improve modularity)
-[env:bare]
-platform = nordicnrf52
-board = nrf52840_dk_adafruit ; nicer than nrf52840_dk - more full gpio mappings
-framework = arduino
-debug_tool = jlink
+[env:tlora-v2-1-1.6]
+extends = esp32_base
+board = ttgo-lora32-v1
 build_flags = 
-  ${env.build_flags} -D BARE_BOARD -Wno-unused-variable -Isrc/bare
+  ${esp32_base.build_flags} -D TLORA_V2_1_16
+
+; The Heltec Cubecell plus 
+; IMPORTANT NOTE: This target doesn't yet work and probably won't ever work.  I'm keeping it around for now.
+; For more details see my post in the forum.
+[env:cubecellplus]
+platform = https://github.com/HelTecAutomation/platform-asrmicro650x.git ; we use top-of-tree because stable version has too many bugs - asrmicro650x
+board = cubecell_board_plus
+; FIXME, bug in cubecell arduino - they are supposed to set ARDUINO
+build_flags = ${env.build_flags} -DARDUINO=100 -Isrc/cubecell
 src_filter = 
-  ${env.src_filter} -<esp32/>
+  ${env.src_filter} -<esp32/> -<nrf52/>
+  
+; Common settings for NRF52 based targets
+[nrf52_base]
+; Instead of the standard nordicnrf52 platform, we use our fork which has our added variant files
+; platform = nordicnrf52
+platform = https://github.com/meshtastic/platform-nordicnrf52.git#62d185fe61b6c84c554046106529b4fd8f155e2c
+debug_tool = jlink
+build_type = debug ; I'm debugging with ICE a lot now
+; note: liboberon provides the AES256 implementation for NRF52 (though not using the hardware acceleration of the NRF52840 - FIXME)
+build_flags = 
+  ${env.build_flags} -Wno-unused-variable 
+  -Isrc/nrf52 
+  -Isdk-nrfxlib/crypto/nrf_oberon/include -Lsdk-nrfxlib/crypto/nrf_oberon/lib/cortex-m4/hard-float/ -lliboberon_3.0.3 
+;-DCFG_DEBUG=3
+src_filter = 
+  ${env.src_filter} -<esp32/> -<nimble/>
 lib_ignore =
   BluetoothOTA
+monitor_port = /dev/ttyACM1
+
+debug_extra_cmds =
+  source gdbinit
+
+; after programming the flash, reset the initial PC
+; debug_load_cmds = load
+
+; Set initial breakpoint (defaults to main)
+debug_init_break =
+;debug_init_break = tbreak loop
+;debug_init_break = tbreak Reset_Handler
+
+; The NRF52840-dk development board
+; Note: By default no lora device is created for this build - it uses a simulated interface
+[env:nrf52840dk]
+extends = nrf52_base
+board = nrf52840_dk
+
+; The NRF52840-dk development board, but @geeksville's board - which has a busted oscilliator 
+[env:nrf52840dk-geeksville]
+extends = nrf52_base
+board = nrf52840_dk_modified
+# add our variants files to the include and src paths
+build_flags = ${nrf52_base.build_flags} -Ivariants/pca10056-rc-clock
+src_filter = ${nrf52_base.src_filter} +<../variants/pca10056-rc-clock>
+
+; Note: By default no lora device is created for this build - it uses a simulated interface
+[env:feather_nrf52832]
+extends = nrf52_base
+board = adafruit_feather_nrf52832
+
+[env:rak815]
+extends = nrf52_base
+board = rak815
+debug_tool = jlink
+upload_protocol = jlink
+monitor_port = /dev/ttyUSB0
+; this board's serial chip can only run at 115200, not faster
+monitor_speed = 115200 
+
+# For experimenting with RAM sizes
+# board_build.ldscript = linker/nrf52840_s140_sim832.ld
+
+; The PPR board
+[env:ppr]
+extends = nrf52_base
+board = ppr
 lib_deps = 
   ${env.lib_deps}
-monitor_port = /dev/ttyACM1
+  UC1701
+
+; The https://github.com/BigCorvus/SX1262-LoRa-BLE-Relay board by @BigCorvus
+[env:lora-relay-v1]
+extends = nrf52_base
+board = lora-relay-v1
+# add our variants files to the include and src paths
+build_flags = ${nrf52_base.build_flags} -Ivariants/lora_relay_v1
+src_filter = ${nrf52_base.src_filter} +<../variants/lora_relay_v1>
+lib_deps = 
+  ${env.lib_deps}
+  SparkFun BQ27441 LiPo Fuel Gauge Arduino Library
+  TFT_eSPI
+  # Adafruit ST7735 and ST7789 Library
+
+
+
+

release/.gitignore

@@ -1,4 +1,5 @@
 *.elf
 *.bin
 *.map
-*.zip
+*.zip
+*.uf2

src/BluetoothCommon.cpp

@@ -0,0 +1,12 @@
+#include "BluetoothCommon.h"
+
+// NRF52 wants these constants as byte arrays
+// Generated here https://yupana-engineering.com/online-uuid-to-c-array-converter - but in REVERSE BYTE ORDER
+const uint8_t MESH_SERVICE_UUID_16[16u] = {0xfd, 0xea, 0x73, 0xe2, 0xca, 0x5d, 0xa8, 0x9f,
+                                           0x1f, 0x46, 0xa8, 0x15, 0x18, 0xb2, 0xa1, 0x6b};
+const uint8_t TORADIO_UUID_16[16u] = {0xe7, 0x01, 0x44, 0x12, 0x66, 0x78, 0xdd, 0xa1,
+                                      0xad, 0x4d, 0x9e, 0x12, 0xd2, 0x76, 0x5c, 0xf7};
+const uint8_t FROMRADIO_UUID_16[16u] = {0xd5, 0x54, 0xe4, 0xc5, 0x25, 0xc5, 0x31, 0xa5,
+                                        0x55, 0x4a, 0x02, 0xee, 0xc2, 0xbc, 0xa2, 0x8b};
+const uint8_t FROMNUM_UUID_16[16u] = {0x53, 0x44, 0xe3, 0x47, 0x75, 0xaa, 0x70, 0xa6,
+                                      0x66, 0x4f, 0x00, 0xa8, 0x8c, 0xa1, 0x9d, 0xed};

src/BluetoothCommon.h

@@ -0,0 +1,20 @@
+#pragma once
+
+#include <Arduino.h>
+
+/**
+ * Common lib functions for all platforms that have bluetooth
+ */
+
+#define MESH_SERVICE_UUID "6ba1b218-15a8-461f-9fa8-5dcae273eafd"
+
+#define TORADIO_UUID "f75c76d2-129e-4dad-a1dd-7866124401e7"
+#define FROMRADIO_UUID "8ba2bcc2-ee02-4a55-a531-c525c5e454d5"
+#define FROMNUM_UUID "ed9da18c-a800-4f66-a670-aa7547e34453"
+
+// NRF52 wants these constants as byte arrays
+// Generated here https://yupana-engineering.com/online-uuid-to-c-array-converter - but in REVERSE BYTE ORDER
+extern const uint8_t MESH_SERVICE_UUID_16[], TORADIO_UUID_16[16u], FROMRADIO_UUID_16[], FROMNUM_UUID_16[];
+
+/// Given a level between 0-100, update the BLE attribute
+void updateBatteryLevel(uint8_t level);

src/GPS.cpp

@@ -1,222 +0,0 @@
-
-#include "GPS.h"
-#include "configuration.h"
-#include "time.h"
-#include <assert.h>
-#include <sys/time.h>
-
-#ifdef GPS_RX_PIN
-HardwareSerial _serial_gps(GPS_SERIAL_NUM);
-#else
-// Assume NRF52
-// Uart _serial_gps(GPS_SERIAL_NUM);
-#endif
-
-bool timeSetFromGPS; // We try to set our time from GPS each time we wake from sleep
-
-GPS gps;
-
-// stuff that really should be in in the instance instead...
-static uint32_t
-    timeStartMsec; // Once we have a GPS lock, this is where we hold the initial msec clock that corresponds to that time
-static uint64_t zeroOffsetSecs; // GPS based time in secs since 1970 - only updated once on initial lock
-
-static bool wantNewLocation = true;
-
-GPS::GPS() : PeriodicTask() {}
-
-void GPS::setup()
-{
-    readFromRTC(); // read the main CPU RTC at first
-
-#ifdef GPS_RX_PIN
-    _serial_gps.begin(GPS_BAUDRATE, SERIAL_8N1, GPS_RX_PIN, GPS_TX_PIN);
-    // _serial_gps.setRxBufferSize(1024); // the default is 256
-    // ublox.enableDebugging(Serial);
-
-    // note: the lib's implementation has the wrong docs for what the return val is
-    // it is not a bool, it returns zero for success
-    isConnected = ublox.begin(_serial_gps);
-
-    // try a second time, the ublox lib serial parsing is buggy?
-    if (!isConnected)
-        isConnected = ublox.begin(_serial_gps);
-
-    if (isConnected) {
-        DEBUG_MSG("Connected to GPS successfully, TXpin=%d\n", GPS_TX_PIN);
-
-        bool factoryReset = false;
-        bool ok;
-        if (factoryReset) {
-            // It is useful to force back into factory defaults (9600baud, NEMA to test the behavior of boards that don't have
-            // GPS_TX connected)
-            ublox.factoryReset();
-            delay(2000);
-            isConnected = ublox.begin(_serial_gps);
-            DEBUG_MSG("Factory reset success=%d\n", isConnected);
-            if (isConnected) {
-                ublox.assumeAutoPVT(true, true); // Just parse NEMA for now
-            }
-        } else {
-            ok = ublox.setUART1Output(COM_TYPE_UBX, 500); // Use native API
-            assert(ok);
-            ok = ublox.setNavigationFrequency(1, 500); // Produce 4x/sec to keep the amount of time we stall in getPVT low
-            assert(ok);
-            // ok = ublox.setAutoPVT(false); // Not implemented on NEO-6M
-            // assert(ok);
-            // ok = ublox.setDynamicModel(DYN_MODEL_BIKE); // probably PEDESTRIAN but just in case assume bike speeds
-            // assert(ok);
-            ok = ublox.powerSaveMode(); // use power save mode
-            assert(ok);
-        }
-        ok = ublox.saveConfiguration(2000);
-        assert(ok);
-    } else {
-        // Some boards might have only the TX line from the GPS connected, in that case, we can't configure it at all.  Just
-        // assume NEMA at 9600 baud.
-        DEBUG_MSG("ERROR: No bidirectional GPS found, hoping that it still might work\n");
-
-        // tell lib, we are expecting the module to send PVT messages by itself to our Rx pin
-        // you can set second parameter to "false" if you want to control the parsing and eviction of the data (need to call
-        // checkUblox cyclically)
-        ublox.assumeAutoPVT(true, true);
-    }
-#endif
-}
-
-void GPS::readFromRTC()
-{
-    struct timeval tv; /* btw settimeofday() is helpfull here too*/
-
-    if (!gettimeofday(&tv, NULL)) {
-        uint32_t now = millis();
-
-        DEBUG_MSG("Read RTC time as %ld (cur millis %u) valid=%d\n", tv.tv_sec, now, timeSetFromGPS);
-        timeStartMsec = now;
-        zeroOffsetSecs = tv.tv_sec;
-    }
-}
-
-/// If we haven't yet set our RTC this boot, set it from a GPS derived time
-void GPS::perhapsSetRTC(const struct timeval *tv)
-{
-    if (!timeSetFromGPS) {
-        timeSetFromGPS = true;
-        DEBUG_MSG("Setting RTC %ld secs\n", tv->tv_sec);
-#ifndef NO_ESP32
-        settimeofday(tv, NULL);
-#else
-        assert(0);
-#endif
-        readFromRTC();
-    }
-}
-
-#include <time.h>
-
-// for the time being we need to rapidly read from the serial port to prevent overruns
-void GPS::loop()
-{
-    PeriodicTask::loop();
-}
-
-uint32_t GPS::getTime()
-{
-    return ((millis() - timeStartMsec) / 1000) + zeroOffsetSecs;
-}
-
-uint32_t GPS::getValidTime()
-{
-    return timeSetFromGPS ? getTime() : 0;
-}
-
-/// Returns true if we think the board can enter deep or light sleep now (we might be trying to get a GPS lock)
-bool GPS::canSleep()
-{
-    return true; // we leave GPS on during sleep now, so sleep is okay !wantNewLocation;
-}
-
-/// Prepare the GPS for the cpu entering deep or light sleep, expect to be gone for at least 100s of msecs
-void GPS::prepareSleep()
-{
-    if (isConnected)
-        ublox.powerOff();
-}
-
-void GPS::doTask()
-{
-#ifdef GPS_RX_PIN
-    uint8_t fixtype = 3; // If we are only using the RX pin, assume we have a 3d fix
-
-    if (isConnected) {
-        // Consume all characters that have arrived
-
-        // getPVT automatically calls checkUblox
-        ublox.checkUblox(); // See if new data is available. Process bytes as they come in.
-
-        // If we don't have a fix (a quick check), don't try waiting for a solution)
-        // Hmmm my fix type reading returns zeros for fix, which doesn't seem correct, because it is still sptting out positions
-        // turn off for now
-        // fixtype = ublox.getFixType();
-        DEBUG_MSG("fix type %d\n", fixtype);
-    }
-
-    // DEBUG_MSG("sec %d\n", ublox.getSecond());
-    // DEBUG_MSG("lat %d\n", ublox.getLatitude());
-
-    // any fix that has time
-    if (!timeSetFromGPS && ublox.getT()) {
-        struct timeval tv;
-
-        /* Convert to unix time
-The Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970
-(midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z).
-*/
-        struct tm t;
-        t.tm_sec = ublox.getSecond();
-        t.tm_min = ublox.getMinute();
-        t.tm_hour = ublox.getHour();
-        t.tm_mday = ublox.getDay();
-        t.tm_mon = ublox.getMonth() - 1;
-        t.tm_year = ublox.getYear() - 1900;
-        t.tm_isdst = false;
-        time_t res = mktime(&t);
-        tv.tv_sec = res;
-        tv.tv_usec = 0; // time.centisecond() * (10 / 1000);
-
-        DEBUG_MSG("Got time from GPS month=%d, year=%d, unixtime=%ld\n", t.tm_mon, t.tm_year, tv.tv_sec);
-        if (t.tm_year < 0 || t.tm_year >= 300)
-            DEBUG_MSG("Ignoring invalid GPS time\n");
-        else
-            perhapsSetRTC(&tv);
-    }
-
-    if ((fixtype >= 3 && fixtype <= 4) && ublox.getP()) // rd fixes only
-    {
-        // we only notify if position has changed
-        latitude = ublox.getLatitude() * 1e-7;
-        longitude = ublox.getLongitude() * 1e-7;
-        altitude = ublox.getAltitude() / 1000; // in mm convert to meters
-        DEBUG_MSG("new gps pos lat=%f, lon=%f, alt=%d\n", latitude, longitude, altitude);
-
-        hasValidLocation = (latitude != 0) || (longitude != 0); // bogus lat lon is reported as 0,0
-        if (hasValidLocation) {
-            wantNewLocation = false;
-            notifyObservers(NULL);
-            // ublox.powerOff();
-        }
-    } else // we didn't get a location update, go back to sleep and hope the characters show up
-        wantNewLocation = true;
-#endif
-
-    // Once we have sent a location once we only poll the GPS rarely, otherwise check back every 1s until we have something over
-    // the serial
-    setPeriod(hasValidLocation && !wantNewLocation ? 30 * 1000 : 10 * 1000);
-}
-
-void GPS::startLock()
-{
-    DEBUG_MSG("Looking for GPS lock\n");
-    wantNewLocation = true;
-    setPeriod(1);
-}

src/GPS.h

@@ -1,57 +0,0 @@
-#pragma once
-
-#include "Observer.h"
-#include "PeriodicTask.h"
-#include "SparkFun_Ublox_Arduino_Library.h"
-#include "sys/time.h"
-
-/**
- * A gps class that only reads from the GPS periodically (and FIXME - eventually keeps the gps powered down except when reading)
- *
- * When new data is available it will notify observers.
- */
-class GPS : public PeriodicTask, public Observable<void *>
-{
-    SFE_UBLOX_GPS ublox;
-
-  public:
-    double latitude, longitude;
-    uint32_t altitude;
-    bool isConnected; // Do we have a GPS we are talking to
-
-    GPS();
-
-    /// Return time since 1970 in secs.  Until we have a GPS lock we will be returning time based at zero
-    uint32_t getTime();
-
-    /// Return time since 1970 in secs.  If we don't have a GPS lock return zero
-    uint32_t getValidTime();
-
-    void setup();
-
-    virtual void loop();
-
-    virtual void doTask();
-
-    /// If we haven't yet set our RTC this boot, set it from a GPS derived time
-    void perhapsSetRTC(const struct timeval *tv);
-
-    /// Returns true if we think the board can enter deep or light sleep now (we might be trying to get a GPS lock)
-    bool canSleep();
-
-    /// Prepare the GPS for the cpu entering deep or light sleep, expect to be gone for at least 100s of msecs
-    void prepareSleep();
-
-    /// Restart our lock attempt - try to get and broadcast a GPS reading ASAP
-    void startLock();
-
-    /// Returns ture if we have acquired GPS lock.
-    bool hasLock() const { return hasValidLocation; }
-
-  private:
-    void readFromRTC();
-
-    bool hasValidLocation = false; // default to false, until we complete our first read
-};
-
-extern GPS gps;

src/GPSStatus.h

@@ -0,0 +1,126 @@
+#pragma once
+#include <Arduino.h>
+#include "Status.h"
+#include "configuration.h"
+
+namespace meshtastic {
+
+    /// Describes the state of the GPS system.
+    class GPSStatus : public Status
+    {
+
+       private:
+        CallbackObserver<GPSStatus, const GPSStatus *> statusObserver = CallbackObserver<GPSStatus, const GPSStatus *>(this, &GPSStatus::updateStatus);
+
+        bool hasLock = false; // default to false, until we complete our first read
+        bool isConnected = false; // Do we have a GPS we are talking to
+        int32_t latitude = 0, longitude = 0; // as an int mult by 1e-7 to get value as double
+        int32_t altitude = 0;
+        uint32_t dop = 0; // Diminution of position; PDOP where possible (UBlox), HDOP otherwise (TinyGPS) in 10^2 units (needs scaling before use)
+        uint32_t heading = 0;
+        uint32_t numSatellites = 0;
+
+       public:
+
+        GPSStatus() {
+            statusType = STATUS_TYPE_GPS;
+        }
+        GPSStatus( bool hasLock, bool isConnected, int32_t latitude, int32_t longitude, int32_t altitude, uint32_t dop, uint32_t heading, uint32_t numSatellites ) : Status()
+        {
+            this->hasLock = hasLock;
+            this->isConnected = isConnected;
+            this->latitude = latitude;
+            this->longitude = longitude;
+            this->altitude = altitude;
+            this->dop = dop;
+            this->heading = heading;
+            this->numSatellites = numSatellites;
+        }
+        GPSStatus(const GPSStatus &);
+        GPSStatus &operator=(const GPSStatus &);
+
+        void observe(Observable<const GPSStatus *> *source)
+        {
+            statusObserver.observe(source);
+        }
+
+        bool getHasLock() const
+        { 
+            return hasLock; 
+        }
+
+        bool getIsConnected() const
+        { 
+            return isConnected; 
+        }
+
+        int32_t getLatitude() const
+        { 
+            return latitude; 
+        }
+
+        int32_t getLongitude() const
+        { 
+            return longitude;
+        }
+
+        int32_t getAltitude() const
+        { 
+            return altitude; 
+        }
+
+        uint32_t getDOP() const
+        { 
+            return dop; 
+        }
+
+        uint32_t getHeading() const
+        {
+            return heading;
+        }
+
+        uint32_t getNumSatellites() const
+        {
+            return numSatellites;
+        }
+
+        bool matches(const GPSStatus *newStatus) const
+        {
+            return (
+                newStatus->hasLock != hasLock ||
+                newStatus->isConnected != isConnected ||
+                newStatus->latitude != latitude ||
+                newStatus->longitude != longitude ||
+                newStatus->altitude != altitude ||
+                newStatus->dop != dop ||
+                newStatus->heading != heading ||
+                newStatus->numSatellites != numSatellites
+            );
+        }
+        int updateStatus(const GPSStatus *newStatus) {
+            // Only update the status if values have actually changed
+            bool isDirty;
+            {
+                isDirty = matches(newStatus);
+                initialized = true; 
+                hasLock = newStatus->hasLock;
+                isConnected = newStatus->isConnected;
+                latitude = newStatus->latitude;
+                longitude = newStatus->longitude;
+                altitude = newStatus->altitude;
+                dop = newStatus->dop;
+                heading = newStatus->heading;
+                numSatellites = newStatus->numSatellites;
+            }
+            if(isDirty) {
+                DEBUG_MSG("New GPS pos lat=%f, lon=%f, alt=%d, pdop=%f, heading=%f, sats=%d\n", latitude * 1e-7, longitude * 1e-7, altitude, dop * 1e-2, heading * 1e-5, numSatellites);
+                onNewStatus.notifyObservers(this);
+            }
+            return 0;
+        }
+
+    };
+
+}
+
+extern meshtastic::GPSStatus *gpsStatus;

src/MeshRadio.cpp

@@ -1,125 +0,0 @@
-#include "error.h"
-#include <SPI.h>
-#include <assert.h>
-
-#include "MeshRadio.h"
-#include "MeshService.h"
-#include "NodeDB.h"
-#include "configuration.h"
-#include "sleep.h"
-#include <pb_decode.h>
-#include <pb_encode.h>
-
-/**
- * ## LoRaWAN for North America
-
-LoRaWAN defines 64, 125 kHz channels from 902.3 to 914.9 MHz increments.
-
-The maximum output power for North America is +30 dBM.
-
-The band is from 902 to 928 MHz. It mentions channel number and its respective channel frequency. All the 13 channels are
-separated by 2.16 MHz with respect to the adjacent channels. Channel zero starts at 903.08 MHz center frequency.
-*/
-
-/// Sometimes while debugging it is useful to set this false, to disable rf95 accesses
-bool useHardware = true;
-
-MeshRadio::MeshRadio() // , manager(radioIf)
-{
-    myNodeInfo.num_channels = NUM_CHANNELS;
-
-    // Can't print strings this early - serial not setup yet
-    // DEBUG_MSG("Set meshradio defaults name=%s\n", channelSettings.name);
-}
-
-bool MeshRadio::init()
-{
-    if (!useHardware)
-        return true;
-
-    DEBUG_MSG("Starting meshradio init...\n");
-
-    configChangedObserver.observe(&service.configChanged);
-    preflightSleepObserver.observe(&preflightSleep);
-    notifyDeepSleepObserver.observe(&notifyDeepSleep);
-
-#ifdef RESET_GPIO
-    pinMode(RESET_GPIO, OUTPUT); // Deassert reset
-    digitalWrite(RESET_GPIO, HIGH);
-
-    // pulse reset
-    digitalWrite(RESET_GPIO, LOW);
-    delay(10);
-    digitalWrite(RESET_GPIO, HIGH);
-    delay(10);
-#endif
-
-    radioIf.setThisAddress(
-        nodeDB.getNodeNum()); // Note: we must do this here, because the nodenum isn't inited at constructor time.
-
-    if (!radioIf.init()) {
-        DEBUG_MSG("LoRa radio init failed\n");
-        DEBUG_MSG("Uncomment '#define SERIAL_DEBUG' in RH_RF95.cpp for detailed debug info\n");
-        return false;
-    }
-
-    // not needed - defaults on
-    // rf95.setPayloadCRC(true);
-
-    reloadConfig();
-
-    return true;
-}
-
-/** hash a string into an integer
- *
- * djb2 by Dan Bernstein.
- * http://www.cse.yorku.ca/~oz/hash.html
- */
-unsigned long hash(char *str)
-{
-    unsigned long hash = 5381;
-    int c;
-
-    while ((c = *str++) != 0)
-        hash = ((hash << 5) + hash) + (unsigned char)c; /* hash * 33 + c */
-
-    return hash;
-}
-
-int MeshRadio::reloadConfig(void *unused)
-{
-    radioIf.setModeIdle(); // Need to be idle before doing init
-
-    // Set up default configuration
-    // No Sync Words in LORA mode.
-    radioIf.setModemConfig(
-        (RH_RF95::ModemConfigChoice)channelSettings.modem_config); // Radio default
-                                                                   //    setModemConfig(Bw125Cr48Sf4096); // slow and reliable?
-    // rf95.setPreambleLength(8);           // Default is 8
-
-    // Defaults after init are 434.0MHz, modulation GFSK_Rb250Fd250, +13dbM
-    int channel_num = hash(channelSettings.name) % NUM_CHANNELS;
-    float center_freq = CH0 + CH_SPACING * channel_num;
-    if (!radioIf.setFrequency(center_freq)) {
-        DEBUG_MSG("setFrequency failed\n");
-        assert(0); // fixme panic
-    }
-
-    // Defaults after init are 434.0MHz, 13dBm, Bw = 125 kHz, Cr = 4/5, Sf = 128chips/symbol, CRC on
-
-    // The default transmitter power is 13dBm, using PA_BOOST.
-    // If you are using RFM95/96/97/98 modules which uses the PA_BOOST transmitter pin, then
-    // you can set transmitter powers from 5 to 23 dBm:
-    // FIXME - can we do this?  It seems to be in the Heltec board.
-    radioIf.setTxPower(channelSettings.tx_power, false);
-
-    DEBUG_MSG("Set radio: name=%s, config=%u, ch=%d, txpower=%d\n", channelSettings.name, channelSettings.modem_config,
-              channel_num, channelSettings.tx_power);
-
-    // Done with init tell radio to start receiving
-    radioIf.setModeRx();
-
-    return 0;
-}
-

src/MeshRadio.h

@@ -1,104 +0,0 @@
-#pragma once
-
-#include "CustomRF95.h"
-#include "MemoryPool.h"
-#include "MeshTypes.h"
-#include "Observer.h"
-#include "PointerQueue.h"
-#include "configuration.h"
-#include "mesh.pb.h"
-
-// US channel settings
-#define CH0_US 903.08f      // MHz
-#define CH_SPACING_US 2.16f // MHz
-#define NUM_CHANNELS_US 13
-
-// EU433 channel settings
-#define CH0_EU433 433.175f    // MHz
-#define CH_SPACING_EU433 0.2f // MHz
-#define NUM_CHANNELS_EU433 8
-
-// EU865 channel settings
-#define CH0_EU865 865.2f      // MHz
-#define CH_SPACING_EU865 0.3f // MHz
-#define NUM_CHANNELS_EU865 10
-
-// CN channel settings
-#define CH0_CN 470.0f      // MHz
-#define CH_SPACING_CN 2.0f // MHz FIXME, this is just a guess for 470-510
-#define NUM_CHANNELS_CN 20
-
-// JP channel settings
-#define CH0_JP 920.0f      // MHz
-#define CH_SPACING_JP 0.5f // MHz FIXME, this is just a guess for 920-925
-#define NUM_CHANNELS_JP 10
-
-// FIXME add defs for other regions and use them here
-#ifdef HW_VERSION_US
-#define CH0 CH0_US
-#define CH_SPACING CH_SPACING_US
-#define NUM_CHANNELS NUM_CHANNELS_US
-#elif defined(HW_VERSION_EU433)
-#define CH0 CH0_EU433
-#define CH_SPACING CH_SPACING_EU433
-#define NUM_CHANNELS NUM_CHANNELS_EU433
-#elif defined(HW_VERSION_EU865)
-#define CH0 CH0_EU865
-#define CH_SPACING CH_SPACING_EU865
-#define NUM_CHANNELS NUM_CHANNELS_EU865
-#elif defined(HW_VERSION_CN)
-#define CH0 CH0_CN
-#define CH_SPACING CH_SPACING_CN
-#define NUM_CHANNELS NUM_CHANNELS_CN
-#elif defined(HW_VERSION_JP)
-#define CH0 CH0_JP
-#define CH_SPACING CH_SPACING_JP
-#define NUM_CHANNELS NUM_CHANNELS_JP
-#else
-#error "HW_VERSION not set"
-#endif
-
-/**
- * A raw low level interface to our mesh.  Only understands nodenums and bytes (not protobufs or node ids)
- */
-class MeshRadio
-{
-  public:
-    // Kinda ugly way of selecting different radio implementations, but soon this MeshRadio class will be going away
-    // entirely.  At that point we can make things pretty.
-#ifdef RF95_IRQ_GPIO
-    CustomRF95
-        radioIf; // the raw radio interface - for now I'm leaving public - because this class is shrinking to be almost nothing
-#else
-    SimRadio radioIf;
-#endif
-
-    /** pool is the pool we will alloc our rx packets from
-     * rxDest is where we will send any rx packets, it becomes receivers responsibility to return packet to the pool
-     */
-    MeshRadio();
-
-    bool init();
-
-  private:
-    CallbackObserver<MeshRadio, void *> configChangedObserver =
-        CallbackObserver<MeshRadio, void *>(this, &MeshRadio::reloadConfig);
-
-    CallbackObserver<MeshRadio, void *> preflightSleepObserver =
-        CallbackObserver<MeshRadio, void *>(this, &MeshRadio::preflightSleepCb);
-
-    CallbackObserver<MeshRadio, void *> notifyDeepSleepObserver =
-        CallbackObserver<MeshRadio, void *>(this, &MeshRadio::notifyDeepSleepDb);
-
-    /// The radioConfig object just changed, call this to force the hw to change to the new settings
-    int reloadConfig(void *unused = NULL);
-
-    /// Return 0 if sleep is okay
-    int preflightSleepCb(void *unused = NULL) { return radioIf.canSleep() ? 0 : 1; }
-
-    int notifyDeepSleepDb(void *unused = NULL)
-    {
-        radioIf.sleep();
-        return 0;
-    }
-};

src/MeshTypes.h

@@ -1,19 +0,0 @@
-#pragma once
-
-// low level types
-
-#include "MemoryPool.h"
-#include "mesh.pb.h"
-#include <Arduino.h>
-
-typedef uint8_t NodeNum;
-typedef uint8_t PacketId; // A packet sequence number
-
-#define NODENUM_BROADCAST 255
-#define ERRNO_OK 0
-#define ERRNO_UNKNOWN 32 // pick something that doesn't conflict with RH_ROUTER_ERROR_UNABLE_TO_DELIVER
-
-typedef int ErrorCode;
-
-/// Alloc and free packets to our global, ISR safe pool
-extern MemoryPool<MeshPacket> packetPool;

src/NodeStatus.h

@@ -0,0 +1,83 @@
+#pragma once
+#include <Arduino.h>
+#include "Status.h"
+#include "configuration.h"
+
+namespace meshtastic {
+
+    /// Describes the state of the NodeDB system.
+    class NodeStatus : public Status
+    {
+
+       private:
+        CallbackObserver<NodeStatus, const NodeStatus *> statusObserver = CallbackObserver<NodeStatus, const NodeStatus *>(this, &NodeStatus::updateStatus);
+
+        uint8_t numOnline = 0;
+        uint8_t numTotal = 0;
+
+        uint8_t lastNumTotal = 0;
+
+       public:
+        bool forceUpdate = false;
+
+        NodeStatus() {
+            statusType = STATUS_TYPE_NODE;
+        }
+        NodeStatus( uint8_t numOnline, uint8_t numTotal, bool forceUpdate = false ) : Status()
+        {
+            this->forceUpdate = forceUpdate;
+            this->numOnline = numOnline;
+            this->numTotal = numTotal;
+        }
+        NodeStatus(const NodeStatus &);
+        NodeStatus &operator=(const NodeStatus &);
+
+        void observe(Observable<const NodeStatus *> *source)
+        {
+            statusObserver.observe(source);
+        }
+
+        uint8_t getNumOnline() const
+        { 
+            return numOnline; 
+        }
+
+        uint8_t getNumTotal() const
+        { 
+            return numTotal; 
+        }
+
+        uint8_t getLastNumTotal() const
+        {
+            return lastNumTotal;
+        }
+
+        bool matches(const NodeStatus *newStatus) const
+        {
+            return (
+                newStatus->getNumOnline() != numOnline ||
+                newStatus->getNumTotal() != numTotal
+            );
+        }
+        int updateStatus(const NodeStatus *newStatus) {
+            // Only update the status if values have actually changed
+            lastNumTotal = numTotal;
+            bool isDirty;
+            {
+                isDirty = matches(newStatus);
+                initialized = true; 
+                numOnline = newStatus->getNumOnline();
+                numTotal = newStatus->getNumTotal();
+            }
+            if(isDirty || newStatus->forceUpdate) {
+                DEBUG_MSG("Node status update: %d online, %d total\n", numOnline, numTotal);            
+                onNewStatus.notifyObservers(this);
+            }
+            return 0;
+        }
+
+    };
+
+}
+
+extern meshtastic::NodeStatus *nodeStatus;

src/OSTimer.cpp

@@ -0,0 +1,49 @@
+#include "OSTimer.h"
+#include "configuration.h"
+
+/**
+ * Schedule a callback to run.  The callback must _not_ block, though it is called from regular thread level (not ISR)
+ *
+ * NOTE! xTimerPend... seems to ignore the time passed in on ESP32 and on NRF52
+ * The reason this didn't work is bcause xTimerPednFunctCall really isn't a timer function at all - it just means run the callback
+ * from the timer thread the next time you have spare cycles.
+ *
+ * @return true if successful, false if the timer fifo is too full.
+
+bool scheduleOSCallback(PendableFunction callback, void *param1, uint32_t param2, uint32_t delayMsec)
+{
+    return xTimerPendFunctionCall(callback, param1, param2, pdMS_TO_TICKS(delayMsec));
+} */
+
+#ifndef NO_ESP32
+
+// Super skanky quick hack to use hardware timers of the ESP32
+static hw_timer_t *timer;
+static PendableFunction tCallback;
+static void *tParam1;
+static uint32_t tParam2;
+
+static void IRAM_ATTR onTimer()
+{
+    (*tCallback)(tParam1, tParam2);
+}
+
+bool scheduleHWCallback(PendableFunction callback, void *param1, uint32_t param2, uint32_t delayMsec)
+{
+    if (!timer) {
+        timer = timerBegin(0, 80, true); // one usec per tick (main clock is 80MhZ on ESP32)
+        assert(timer);
+        timerAttachInterrupt(timer, &onTimer, true);
+    }
+
+    tCallback = callback;
+    tParam1 = param1;
+    tParam2 = param2;
+
+    timerAlarmWrite(timer, delayMsec * 1000L, false); // Do not reload, we want it to be a single shot timer
+    timerRestart(timer);
+    timerAlarmEnable(timer);
+    return true;
+}
+
+#endif

src/OSTimer.h

@@ -0,0 +1,8 @@
+#pragma once
+
+#include <Arduino.h>
+
+typedef void (*PendableFunction)(void *pvParameter1, uint32_t ulParameter2);
+
+/// Uses a hardware timer, but calls the handler in _interrupt_ context
+bool scheduleHWCallback(PendableFunction callback, void *param1, uint32_t param2, uint32_t delayMsec);

src/Observer.h

@@ -1,7 +1,7 @@
 #pragma once
 
 #include <Arduino.h>
-
+#include <assert.h>
 #include <list>
 
 template <class T> class Observable;
@@ -14,7 +14,6 @@ template <class T> class Observer
     Observable<T> *observed = NULL;
 
   public:
-
     virtual ~Observer();
 
     void observe(Observable<T> *o);

src/PeriodicTask.cpp

@@ -1,25 +0,0 @@
-#include "PeriodicTask.h"
-#include "Periodic.h"
-
-PeriodicTask::PeriodicTask(uint32_t initialPeriod) : period(initialPeriod) {}
-
-/// call this from loop
-void PeriodicTask::loop()
-{
-    {
-        meshtastic::LockGuard lg(&lock);
-        uint32_t now = millis();
-        if (!period || (now - lastMsec) < period) {
-            return;
-        }
-        lastMsec = now;
-    }
-    // Release the lock in case the task wants to change the period.
-    doTask();
-}
-
-void Periodic::doTask()
-{
-    uint32_t p = callback();
-    setPeriod(p);
-}

src/PeriodicTask.h

@@ -1,39 +0,0 @@
-#pragma once
-
-#include <cstdint>
-
-#include "lock.h"
-
-/**
- * A base class for tasks that want their doTask() method invoked periodically
- *
- * FIXME: currently just syntatic sugar for polling in loop (you must call .loop), but eventually
- * generalize with the freertos scheduler so we can save lots of power by having everything either in
- * something like this or triggered off of an irq.
- */
-class PeriodicTask
-{
-    uint32_t lastMsec = 0;
-    uint32_t period = 1; // call soon after creation
-
-    // Protects the above variables.
-    meshtastic::Lock lock;
-
-  public:
-    virtual ~PeriodicTask() {}
-
-    PeriodicTask(uint32_t initialPeriod = 1);
-
-    /// call this from loop
-    virtual void loop();
-
-    /// Set a new period in msecs (can be called from doTask or elsewhere and the scheduler will cope)
-    void setPeriod(uint32_t p)
-    {
-        meshtastic::LockGuard lg(&lock);
-        period = p;
-    }
-
-  protected:
-    virtual void doTask() = 0;
-};

src/Power.cpp

@@ -0,0 +1,252 @@
+#include "power.h"
+#include "PowerFSM.h"
+#include "main.h"
+#include "sleep.h"
+#include "utils.h"
+
+// FIXME. nasty hack cleanup how we load axp192
+#undef AXP192_SLAVE_ADDRESS
+#include "axp20x.h"
+
+#ifdef TBEAM_V10
+AXP20X_Class axp;
+#endif
+
+bool pmu_irq = false;
+
+Power *power;
+
+/**
+ * If this board has a battery level sensor, set this to a valid implementation
+ */
+static HasBatteryLevel *batteryLevel; // Default to NULL for no battery level sensor
+
+/**
+ * A simple battery level sensor that assumes the battery voltage is attached via a voltage-divider to an analog input
+ */
+class AnalogBatteryLevel : public HasBatteryLevel
+{
+    /**
+     * Battery state of charge, from 0 to 100 or -1 for unknown
+     *
+     * FIXME - use a lipo lookup table, the current % full is super wrong
+     */
+    virtual int getBattPercentage()
+    {
+        float v = getBattVoltage() / 1000;
+
+        if (v < 2.1)
+            return -1;
+
+        return 100 * (v - 3.27) / (4.2 - 3.27);
+    }
+
+    /**
+     * The raw voltage of the batteryin millivolts or NAN if unknown
+     */
+    virtual float getBattVoltage()
+    {
+        return
+#ifdef BATTERY_PIN
+            1000.0 * analogRead(BATTERY_PIN) * 2.0 * (3.3 / 1024.0);
+#else
+            NAN;
+#endif
+    }
+
+    /**
+     * return true if there is a battery installed in this unit
+     */
+    virtual bool isBatteryConnect() { return true; }
+} analogLevel;
+
+bool Power::analogInit()
+{
+#ifdef BATTERY_PIN
+    DEBUG_MSG("Using analog input for battery level\n");
+    adcAttachPin(BATTERY_PIN);
+    // adcStart(BATTERY_PIN);
+    analogReadResolution(10); // Default of 12 is not very linear. Recommended to use 10 or 11 depending on needed resolution.
+    batteryLevel = &analogLevel;
+    return true;
+#else
+    return false;
+#endif
+}
+
+bool Power::setup()
+{
+    bool found = axp192Init();
+
+    if (!found) {
+        found = analogInit();
+    }
+    if (found) {
+        concurrency::PeriodicTask::setup(); // We don't start our periodic task unless we actually found the device
+        setPeriod(1);
+    }
+
+    return found;
+}
+
+/// Reads power status to powerStatus singleton.
+//
+// TODO(girts): move this and other axp stuff to power.h/power.cpp.
+void Power::readPowerStatus()
+{
+    if (batteryLevel) {
+        bool hasBattery = batteryLevel->isBatteryConnect();
+        int batteryVoltageMv = 0;
+        uint8_t batteryChargePercent = 0;
+        if (hasBattery) {
+            batteryVoltageMv = batteryLevel->getBattVoltage();
+            // If the AXP192 returns a valid battery percentage, use it
+            if (batteryLevel->getBattPercentage() >= 0) {
+                batteryChargePercent = batteryLevel->getBattPercentage();
+            } else {
+                // If the AXP192 returns a percentage less than 0, the feature is either not supported or there is an error
+                // In that case, we compute an estimate of the charge percent based on maximum and minimum voltages defined in
+                // power.h
+                batteryChargePercent =
+                    clamp((int)(((batteryVoltageMv - BAT_MILLIVOLTS_EMPTY) * 1e2) / (BAT_MILLIVOLTS_FULL - BAT_MILLIVOLTS_EMPTY)),
+                          0, 100);
+            }
+        }
+
+        // Notify any status instances that are observing us
+        const meshtastic::PowerStatus powerStatus = meshtastic::PowerStatus(
+            hasBattery, batteryLevel->isVBUSPlug(), batteryLevel->isChargeing(), batteryVoltageMv, batteryChargePercent);
+        newStatus.notifyObservers(&powerStatus);
+
+        // If we have a battery at all and it is less than 10% full, force deep sleep
+        if (powerStatus.getHasBattery() && !powerStatus.getHasUSB() && batteryLevel->getBattVoltage() < MIN_BAT_MILLIVOLTS)
+            powerFSM.trigger(EVENT_LOW_BATTERY);
+    }
+}
+
+void Power::doTask()
+{
+    readPowerStatus();
+
+    // Only read once every 20 seconds once the power status for the app has been initialized
+    if (statusHandler && statusHandler->isInitialized())
+        setPeriod(1000 * 20);
+}
+
+/**
+ * Init the power manager chip
+ *
+ * axp192 power
+    DCDC1 0.7-3.5V @ 1200mA max -> OLED // If you turn this off you'll lose comms to the axp192 because the OLED and the axp192
+ share the same i2c bus, instead use ssd1306 sleep mode DCDC2 -> unused DCDC3 0.7-3.5V @ 700mA max -> ESP32 (keep this on!) LDO1
+ 30mA -> charges GPS backup battery // charges the tiny J13 battery by the GPS to power the GPS ram (for a couple of days), can
+ not be turned off LDO2 200mA -> LORA LDO3 200mA -> GPS
+ */
+bool Power::axp192Init()
+{
+#ifdef TBEAM_V10
+    if (axp192_found) {
+        if (!axp.begin(Wire, AXP192_SLAVE_ADDRESS)) {
+            batteryLevel = &axp;
+
+            DEBUG_MSG("AXP192 Begin PASS\n");
+
+            // axp.setChgLEDMode(LED_BLINK_4HZ);
+            DEBUG_MSG("DCDC1: %s\n", axp.isDCDC1Enable() ? "ENABLE" : "DISABLE");
+            DEBUG_MSG("DCDC2: %s\n", axp.isDCDC2Enable() ? "ENABLE" : "DISABLE");
+            DEBUG_MSG("LDO2: %s\n", axp.isLDO2Enable() ? "ENABLE" : "DISABLE");
+            DEBUG_MSG("LDO3: %s\n", axp.isLDO3Enable() ? "ENABLE" : "DISABLE");
+            DEBUG_MSG("DCDC3: %s\n", axp.isDCDC3Enable() ? "ENABLE" : "DISABLE");
+            DEBUG_MSG("Exten: %s\n", axp.isExtenEnable() ? "ENABLE" : "DISABLE");
+            DEBUG_MSG("----------------------------------------\n");
+
+            axp.setPowerOutPut(AXP192_LDO2, AXP202_ON); // LORA radio
+            axp.setPowerOutPut(AXP192_LDO3, AXP202_ON); // GPS main power
+            axp.setPowerOutPut(AXP192_DCDC2, AXP202_ON);
+            axp.setPowerOutPut(AXP192_EXTEN, AXP202_ON);
+            axp.setPowerOutPut(AXP192_DCDC1, AXP202_ON);
+            axp.setDCDC1Voltage(3300); // for the OLED power
+
+            DEBUG_MSG("DCDC1: %s\n", axp.isDCDC1Enable() ? "ENABLE" : "DISABLE");
+            DEBUG_MSG("DCDC2: %s\n", axp.isDCDC2Enable() ? "ENABLE" : "DISABLE");
+            DEBUG_MSG("LDO2: %s\n", axp.isLDO2Enable() ? "ENABLE" : "DISABLE");
+            DEBUG_MSG("LDO3: %s\n", axp.isLDO3Enable() ? "ENABLE" : "DISABLE");
+            DEBUG_MSG("DCDC3: %s\n", axp.isDCDC3Enable() ? "ENABLE" : "DISABLE");
+            DEBUG_MSG("Exten: %s\n", axp.isExtenEnable() ? "ENABLE" : "DISABLE");
+
+            axp.setChargeControlCur(AXP1XX_CHARGE_CUR_1320MA); // actual limit (in HW) on the tbeam is 450mA
+#if 0
+
+      // Not connected
+      //val = 0xfc;
+      //axp._writeByte(AXP202_VHTF_CHGSET, 1, &val); // Set temperature protection
+
+      //not used
+      //val = 0x46;
+      //axp._writeByte(AXP202_OFF_CTL, 1, &val); // enable bat detection
+#endif
+            axp.debugCharging();
+
+#ifdef PMU_IRQ
+            pinMode(PMU_IRQ, INPUT);
+            attachInterrupt(
+                PMU_IRQ, [] { pmu_irq = true; }, FALLING);
+
+            axp.adc1Enable(AXP202_BATT_CUR_ADC1, 1);
+            axp.enableIRQ(AXP202_BATT_REMOVED_IRQ | AXP202_BATT_CONNECT_IRQ | AXP202_CHARGING_FINISHED_IRQ | AXP202_CHARGING_IRQ |
+                              AXP202_VBUS_REMOVED_IRQ | AXP202_VBUS_CONNECT_IRQ | AXP202_PEK_SHORTPRESS_IRQ,
+                          1);
+
+            axp.clearIRQ();
+#endif
+            readPowerStatus();
+        } else {
+            DEBUG_MSG("AXP192 Begin FAIL\n");
+        }
+    } else {
+        DEBUG_MSG("AXP192 not found\n");
+    }
+
+    return axp192_found;
+#else
+    return false;
+#endif
+}
+
+void Power::loop()
+{
+#ifdef PMU_IRQ
+    if (pmu_irq) {
+        pmu_irq = false;
+        axp.readIRQ();
+
+        DEBUG_MSG("pmu irq!\n");
+
+        if (axp.isChargingIRQ()) {
+            DEBUG_MSG("Battery start charging\n");
+        }
+        if (axp.isChargingDoneIRQ()) {
+            DEBUG_MSG("Battery fully charged\n");
+        }
+        if (axp.isVbusRemoveIRQ()) {
+            DEBUG_MSG("USB unplugged\n");
+        }
+        if (axp.isVbusPlugInIRQ()) {
+            DEBUG_MSG("USB plugged In\n");
+        }
+        if (axp.isBattPlugInIRQ()) {
+            DEBUG_MSG("Battery inserted\n");
+        }
+        if (axp.isBattRemoveIRQ()) {
+            DEBUG_MSG("Battery removed\n");
+        }
+        if (axp.isPEKShortPressIRQ()) {
+            DEBUG_MSG("PEK short button press\n");
+        }
+
+        readPowerStatus();
+        axp.clearIRQ();
+    }
+
+#endif
+}

src/PowerFSM.cpp

@@ -5,9 +5,10 @@
 #include "NodeDB.h"
 #include "configuration.h"
 #include "main.h"
-#include "screen.h"
+#include "graphics/Screen.h"
 #include "sleep.h"
 #include "target_specific.h"
+#include "timing.h"
 
 static void sdsEnter()
 {
@@ -15,7 +16,7 @@ static void sdsEnter()
 
   // Don't deepsleep if we have USB power or if the user as pressed a button recently
   // !isUSBPowered <- doesn't work yet because the axp192 isn't letting the battery fully charge when we are awake - FIXME
-  if (millis() - lastPressMs > radioConfig.preferences.mesh_sds_timeout_secs)
+  if (timing::millis() - lastPressMs > radioConfig.preferences.mesh_sds_timeout_secs)
   {
     doDeepSleep(radioConfig.preferences.sds_secs);
   }
@@ -26,60 +27,73 @@ static void sdsEnter()
 
 #include "error.h"
 
+static uint32_t secsSlept;
+
 static void lsEnter()
 {
     DEBUG_MSG("lsEnter begin, ls_secs=%u\n", radioConfig.preferences.ls_secs);
     screen.setOn(false);
+    secsSlept = 0; // How long have we been sleeping this time
 
     DEBUG_MSG("lsEnter end\n");
 }
 
 static void lsIdle()
 {
-    DEBUG_MSG("lsIdle begin ls_secs=%u\n", radioConfig.preferences.ls_secs);
+    // DEBUG_MSG("lsIdle begin ls_secs=%u\n", radioConfig.preferences.ls_secs);
 
 #ifndef NO_ESP32
-    uint32_t secsSlept = 0;
     esp_sleep_source_t wakeCause = ESP_SLEEP_WAKEUP_UNDEFINED;
-    bool reached_ls_secs = false;
 
-    while (!reached_ls_secs) {
+    // Do we have more sleeping to do?
+    if (secsSlept < radioConfig.preferences.ls_secs) {
         // Briefly come out of sleep long enough to blink the led once every few seconds
-        uint32_t sleepTime = 5;
+        uint32_t sleepTime = 30;
 
-        setLed(false); // Never leave led on while in light sleep
-        wakeCause = doLightSleep(sleepTime * 1000LL);
-        if (wakeCause != ESP_SLEEP_WAKEUP_TIMER)
-            break;
+        // If some other service would stall sleep, don't let sleep happen yet
+        if (doPreflightSleep()) {
+            setLed(false); // Never leave led on while in light sleep
+            wakeCause = doLightSleep(sleepTime * 1000LL);
 
-        setLed(true); // briefly turn on led
-        doLightSleep(1);
-        if (wakeCause != ESP_SLEEP_WAKEUP_TIMER)
-            break;
+            if (wakeCause == ESP_SLEEP_WAKEUP_TIMER) {
+                // Normal case: timer expired, we should just go back to sleep ASAP
 
-        secsSlept += sleepTime;
-        reached_ls_secs = secsSlept >= radioConfig.preferences.ls_secs;
-    }
-    setLed(false);
+                setLed(true);                // briefly turn on led
+                wakeCause = doLightSleep(1); // leave led on for 1ms
 
-    if (reached_ls_secs) {
-        // stay in LS mode but let loop check whatever it wants
-        DEBUG_MSG("reached ls_secs, servicing loop()\n");
-    } else {
-        DEBUG_MSG("wakeCause %d\n", wakeCause);
+                secsSlept += sleepTime;
+                // DEBUG_MSG("sleeping, flash led!\n");
+            }
+            if (wakeCause == ESP_SLEEP_WAKEUP_UART) {
+                // Not currently used (because uart triggers in hw have problems)
+                powerFSM.trigger(EVENT_SERIAL_CONNECTED);
+            } else {
+                // We woke for some other reason (button press, uart, device interrupt)
+                // uint64_t status = esp_sleep_get_ext1_wakeup_status();
+                DEBUG_MSG("wakeCause %d\n", wakeCause);
 
 #ifdef BUTTON_PIN
-        bool pressed = !digitalRead(BUTTON_PIN);
+                bool pressed = !digitalRead(BUTTON_PIN);
 #else
-        bool pressed = false;
+                bool pressed = false;
 #endif
-        if (pressed) // If we woke because of press, instead generate a PRESS event.
-        {
-            powerFSM.trigger(EVENT_PRESS);
+                if (pressed) // If we woke because of press, instead generate a PRESS event.
+                {
+                    powerFSM.trigger(EVENT_PRESS);
+                } else {
+                    // Otherwise let the NB state handle the IRQ (and that state will handle stuff like IRQs etc)
+                    powerFSM.trigger(EVENT_WAKE_TIMER);
+                }
+            }
         } else {
-            // Otherwise let the NB state handle the IRQ (and that state will handle stuff like IRQs etc)
-            powerFSM.trigger(EVENT_WAKE_TIMER);
+            // Someone says we can't sleep now, so just save some power by sleeping the CPU for 100ms or so
+            delay(100);
         }
+    } else {
+        // Time to stop sleeping!
+        setLed(false);
+        DEBUG_MSG("reached ls_secs, servicing loop()\n");
+        powerFSM.trigger(EVENT_WAKE_TIMER);
     }
 #endif
 }
@@ -87,7 +101,7 @@ static void lsIdle()
 static void lsExit()
 {
     // setGPSPower(true); // restore GPS power
-    gps.startLock();
+    gps->startLock();
 }
 
 static void nbEnter()
@@ -104,6 +118,12 @@ static void darkEnter()
     screen.setOn(false);
 }
 
+static void serialEnter()
+{
+    setBluetoothEnable(false);
+    screen.setOn(true);
+}
+
 static void onEnter()
 {
     screen.setOn(true);
@@ -111,10 +131,11 @@ static void onEnter()
 
     static uint32_t lastPingMs;
 
-    uint32_t now = millis();
+    uint32_t now = timing::millis();
 
-    if (now - lastPingMs > 60 * 1000) { // if more than a minute since our last press, ask other nodes to update their state
-        service.sendNetworkPing(NODENUM_BROADCAST, true);
+    if (now - lastPingMs > 30 * 1000) { // if more than a minute since our last press, ask other nodes to update their state
+        if (displayedNodeNum)
+            service.sendNetworkPing(displayedNodeNum, true); // Refresh the currently displayed node
         lastPingMs = now;
     }
 }
@@ -132,6 +153,7 @@ State stateSDS(sdsEnter, NULL, NULL, "SDS");
 State stateLS(lsEnter, lsIdle, lsExit, "LS");
 State stateNB(nbEnter, NULL, NULL, "NB");
 State stateDARK(darkEnter, NULL, NULL, "DARK");
+State stateSERIAL(serialEnter, NULL, NULL, "SERIAL");
 State stateBOOT(bootEnter, NULL, NULL, "BOOT");
 State stateON(onEnter, NULL, NULL, "ON");
 Fsm powerFSM(&stateBOOT);
@@ -147,12 +169,20 @@ void PowerFSM_setup()
 
     powerFSM.add_transition(&stateNB, &stateNB, EVENT_RECEIVED_PACKET, NULL, "Received packet, resetting win wake");
 
-    // Handle press events
+    // Handle press events - note: we ignore button presses when in API mode
     powerFSM.add_transition(&stateLS, &stateON, EVENT_PRESS, NULL, "Press");
     powerFSM.add_transition(&stateNB, &stateON, EVENT_PRESS, NULL, "Press");
     powerFSM.add_transition(&stateDARK, &stateON, EVENT_PRESS, NULL, "Press");
     powerFSM.add_transition(&stateON, &stateON, EVENT_PRESS, screenPress, "Press"); // reenter On to restart our timers
 
+    // Handle critically low power battery by forcing deep sleep
+    powerFSM.add_transition(&stateBOOT, &stateSDS, EVENT_LOW_BATTERY, NULL, "LowBat");
+    powerFSM.add_transition(&stateLS, &stateSDS, EVENT_LOW_BATTERY, NULL, "LowBat");
+    powerFSM.add_transition(&stateNB, &stateSDS, EVENT_LOW_BATTERY, NULL, "LowBat");
+    powerFSM.add_transition(&stateDARK, &stateSDS, EVENT_LOW_BATTERY, NULL, "LowBat");
+    powerFSM.add_transition(&stateON, &stateSDS, EVENT_LOW_BATTERY, NULL, "LowBat");
+    powerFSM.add_transition(&stateSERIAL, &stateSDS, EVENT_LOW_BATTERY, NULL, "LowBat");
+
     powerFSM.add_transition(&stateDARK, &stateON, EVENT_BLUETOOTH_PAIR, NULL, "Bluetooth pairing");
     powerFSM.add_transition(&stateON, &stateON, EVENT_BLUETOOTH_PAIR, NULL, "Bluetooth pairing");
 
@@ -165,6 +195,13 @@ void PowerFSM_setup()
     powerFSM.add_transition(&stateDARK, &stateON, EVENT_RECEIVED_TEXT_MSG, NULL, "Received text");
     powerFSM.add_transition(&stateON, &stateON, EVENT_RECEIVED_TEXT_MSG, NULL, "Received text"); // restarts the sleep timer
 
+    powerFSM.add_transition(&stateLS, &stateSERIAL, EVENT_SERIAL_CONNECTED, NULL, "serial API");
+    powerFSM.add_transition(&stateNB, &stateSERIAL, EVENT_SERIAL_CONNECTED, NULL, "serial API");
+    powerFSM.add_transition(&stateDARK, &stateSERIAL, EVENT_SERIAL_CONNECTED, NULL, "serial API");
+    powerFSM.add_transition(&stateON, &stateSERIAL, EVENT_SERIAL_CONNECTED, NULL, "serial API");
+
+    powerFSM.add_transition(&stateSERIAL, &stateNB, EVENT_SERIAL_DISCONNECTED, NULL, "serial disconnect");
+
     powerFSM.add_transition(&stateDARK, &stateDARK, EVENT_CONTACT_FROM_PHONE, NULL, "Contact from phone");
 
     powerFSM.add_transition(&stateNB, &stateDARK, EVENT_PACKET_FOR_PHONE, NULL, "Packet for phone");
@@ -173,10 +210,13 @@ void PowerFSM_setup()
 
     powerFSM.add_timed_transition(&stateDARK, &stateNB, radioConfig.preferences.phone_timeout_secs * 1000, NULL, "Phone timeout");
 
+#ifndef NRF52_SERIES
+    // We never enter light-sleep state on NRF52 (because the CPU uses so little power normally)
     powerFSM.add_timed_transition(&stateNB, &stateLS, radioConfig.preferences.min_wake_secs * 1000, NULL, "Min wake timeout");
 
     powerFSM.add_timed_transition(&stateDARK, &stateLS, radioConfig.preferences.wait_bluetooth_secs * 1000, NULL,
                                   "Bluetooth timeout");
+#endif
 
     powerFSM.add_timed_transition(&stateLS, &stateSDS, radioConfig.preferences.mesh_sds_timeout_secs * 1000, NULL,
                                   "mesh timeout");

src/PowerFSM.h

@@ -13,6 +13,9 @@
 #define EVENT_BLUETOOTH_PAIR 7
 #define EVENT_NODEDB_UPDATED 8     // NodeDB has a big enough change that we think you should turn on the screen
 #define EVENT_CONTACT_FROM_PHONE 9 // the phone just talked to us over bluetooth
+#define EVENT_LOW_BATTERY 10 // Battery is critically low, go to sleep
+#define EVENT_SERIAL_CONNECTED 11
+#define EVENT_SERIAL_DISCONNECTED 12
 
 extern Fsm powerFSM;
 

src/PowerStatus.h

@@ -0,0 +1,103 @@
+#pragma once
+#include <Arduino.h>
+#include "Status.h"
+#include "configuration.h"
+
+namespace meshtastic {
+
+    /// Describes the state of the GPS system.
+    class PowerStatus : public Status
+    {
+
+       private:
+        CallbackObserver<PowerStatus, const PowerStatus *> statusObserver = CallbackObserver<PowerStatus, const PowerStatus *>(this, &PowerStatus::updateStatus);
+
+        /// Whether we have a battery connected
+        bool hasBattery;
+        /// Battery voltage in mV, valid if haveBattery is true
+        int batteryVoltageMv;
+        /// Battery charge percentage, either read directly or estimated
+        uint8_t batteryChargePercent;
+        /// Whether USB is connected
+        bool hasUSB;
+        /// Whether we are charging the battery
+        bool isCharging;
+
+       public:
+
+        PowerStatus() {
+            statusType = STATUS_TYPE_POWER;
+        }
+        PowerStatus( bool hasBattery, bool hasUSB, bool isCharging, int batteryVoltageMv, uint8_t batteryChargePercent ) : Status()
+        {
+            this->hasBattery = hasBattery;
+            this->hasUSB = hasUSB;
+            this->isCharging = isCharging;
+            this->batteryVoltageMv = batteryVoltageMv;
+            this->batteryChargePercent = batteryChargePercent;
+        }
+        PowerStatus(const PowerStatus &);
+        PowerStatus &operator=(const PowerStatus &);
+
+        void observe(Observable<const PowerStatus *> *source)
+        {
+            statusObserver.observe(source);
+        }
+
+        bool getHasBattery() const
+        { 
+            return hasBattery; 
+        }
+
+        bool getHasUSB() const
+        {
+            return hasUSB;
+        }
+
+        bool getIsCharging() const
+        { 
+            return isCharging; 
+        }
+
+        int getBatteryVoltageMv() const
+        { 
+            return batteryVoltageMv; 
+        }
+
+        uint8_t getBatteryChargePercent() const
+        { 
+            return batteryChargePercent;
+        }
+
+        bool matches(const PowerStatus *newStatus) const
+        {
+            return (
+                newStatus->getHasBattery() != hasBattery ||
+                newStatus->getHasUSB() != hasUSB ||
+                newStatus->getBatteryVoltageMv() != batteryVoltageMv
+            );
+        }
+        int updateStatus(const PowerStatus *newStatus) {
+            // Only update the status if values have actually changed
+            bool isDirty;
+            {
+                isDirty = matches(newStatus);
+                initialized = true; 
+                hasBattery = newStatus->getHasBattery();
+                batteryVoltageMv = newStatus->getBatteryVoltageMv();
+                batteryChargePercent = newStatus->getBatteryChargePercent();
+                hasUSB = newStatus->getHasUSB();
+                isCharging = newStatus->getIsCharging();
+            }
+            if(isDirty) {
+                DEBUG_MSG("Battery %dmV %d%%\n", batteryVoltageMv, batteryChargePercent);
+                onNewStatus.notifyObservers(this);
+            }
+            return 0;
+        }
+
+    };
+
+}
+
+extern meshtastic::PowerStatus *powerStatus;

src/RedirectablePrint.cpp

@@ -0,0 +1,13 @@
+#include "RedirectablePrint.h"
+#include <assert.h>
+
+/**
+ * A printer that doesn't go anywhere
+ */
+NoopPrint noopPrint;
+
+void RedirectablePrint::setDestination(Print *_dest)
+{
+    assert(_dest);
+    dest = _dest;
+}

src/RedirectablePrint.h

@@ -0,0 +1,34 @@
+#pragma once
+
+#include <Print.h>
+
+/**
+ * A Printable that can be switched to squirt its bytes to a different sink.
+ * This class is mostly useful to allow debug printing to be redirected away from Serial
+ * to some other transport if we switch Serial usage (on the fly) to some other purpose.
+ */
+class RedirectablePrint : public Print
+{
+    Print *dest;
+
+  public:
+    RedirectablePrint(Print *_dest) : dest(_dest) {}
+
+    /**
+     * Set a new destination
+     */
+    void setDestination(Print *dest);
+
+    virtual size_t write(uint8_t c) { return dest->write(c); }
+};
+
+class NoopPrint : public Print
+{
+  public:
+    virtual size_t write(uint8_t c) { return 1; }
+};
+
+/**
+ * A printer that doesn't go anywhere
+ */
+extern NoopPrint noopPrint;

src/SerialConsole.cpp

@@ -0,0 +1,45 @@
+#include "SerialConsole.h"
+#include "PowerFSM.h"
+#include "configuration.h"
+#include <Arduino.h>
+
+#define Port Serial
+
+SerialConsole console;
+
+SerialConsole::SerialConsole() : StreamAPI(&Port), RedirectablePrint(&Port)
+{
+    canWrite = false; // We don't send packets to our port until it has talked to us first
+    // setDestination(&noopPrint); for testing, try turning off 'all' debug output and see what leaks
+}
+
+/// Do late init that can't happen at constructor time
+void SerialConsole::init()
+{
+    Port.begin(SERIAL_BAUD);
+    StreamAPI::init();
+    emitRebooted();
+}
+
+/**
+ * we override this to notice when we've received a protobuf over the serial
+ * stream.  Then we shunt off debug serial output.
+ */
+void SerialConsole::handleToRadio(const uint8_t *buf, size_t len)
+{
+    // Turn off debug serial printing once the API is activated, because other threads could print and corrupt packets
+    setDestination(&noopPrint);
+    canWrite = true;
+
+    StreamAPI::handleToRadio(buf, len);
+}
+
+/// Hookable to find out when connection changes
+void SerialConsole::onConnectionChanged(bool connected)
+{
+    if (connected) { // To prevent user confusion, turn off bluetooth while using the serial port api
+        powerFSM.trigger(EVENT_SERIAL_CONNECTED);
+    } else {
+        powerFSM.trigger(EVENT_SERIAL_DISCONNECTED);
+    }
+}

src/SerialConsole.h

@@ -0,0 +1,35 @@
+#pragma once
+
+#include "RedirectablePrint.h"
+#include "StreamAPI.h"
+/**
+ * Provides both debug printing and, if the client starts sending protobufs to us, switches to send/receive protobufs
+ * (and starts dropping debug printing - FIXME, eventually those prints should be encapsulated in protobufs).
+ */
+class SerialConsole : public StreamAPI, public RedirectablePrint
+{
+  public:
+    SerialConsole();
+
+    /// Do late init that can't happen at constructor time
+    virtual void init();
+
+    /**
+     * we override this to notice when we've received a protobuf over the serial stream.  Then we shunt off
+     * debug serial output.
+     */
+    virtual void handleToRadio(const uint8_t *buf, size_t len);
+
+    virtual size_t write(uint8_t c)
+    {
+        if (c == '\n') // prefix any newlines with carriage return
+            RedirectablePrint::write('\r');
+        return RedirectablePrint::write(c);
+    }
+
+  protected:
+    /// Hookable to find out when connection changes
+    virtual void onConnectionChanged(bool connected);
+};
+
+extern SerialConsole console;

src/Status.h

@@ -0,0 +1,72 @@
+#pragma once
+
+#include "Observer.h"
+
+// Constants for the various status types, so we can tell subclass instances apart
+#define STATUS_TYPE_BASE 0
+#define STATUS_TYPE_POWER 1
+#define STATUS_TYPE_GPS 2
+#define STATUS_TYPE_NODE 3
+
+
+namespace meshtastic
+{
+
+    // A base class for observable status
+    class Status
+    {
+       protected:
+        // Allows us to observe an Observable
+        CallbackObserver<Status, const Status *> statusObserver = CallbackObserver<Status, const Status *>(this, &Status::updateStatus);
+        bool initialized = false;
+        // Workaround for no typeid support
+        int statusType;
+
+       public:
+        // Allows us to generate observable events
+        Observable<const Status *> onNewStatus;
+
+        // Enable polymorphism ?
+        virtual ~Status() = default;
+        
+        Status() {
+            if (!statusType)
+            {
+                statusType = STATUS_TYPE_BASE;
+            }
+        }
+
+        // Prevent object copy/move
+        Status(const Status &) = delete;
+        Status &operator=(const Status &) = delete;
+
+        // Start observing a source of data
+        void observe(Observable<const Status *> *source)
+        {
+            statusObserver.observe(source);
+        }
+
+        // Determines whether or not existing data matches the data in another Status instance
+        bool matches(const Status *otherStatus) const 
+        {
+            return true;
+        }
+
+        bool isInitialized() const
+        {
+            return initialized;
+        }
+
+        int getStatusType() const
+        {
+            return statusType;
+        }
+
+        // Called when the Observable we're observing generates a new notification
+        int updateStatus(const Status *newStatus) 
+        {
+            return 0;
+        }
+
+    };
+};

src/User_Setup.h

@@ -0,0 +1,339 @@
+// This file is used to set TFT/eInk preferences for the TFT.cpp driver
+
+#include <variant.h>
+
+//                            USER DEFINED SETTINGS
+//   Set driver type, fonts to be loaded, pins used and SPI control method etc
+//
+//   See the User_Setup_Select.h file if you wish to be able to define multiple
+//   setups and then easily select which setup file is used by the compiler.
+//
+//   If this file is edited correctly then all the library example sketches should
+//   run without the need to make any more changes for a particular hardware setup!
+//   Note that some sketches are designed for a particular TFT pixel width/height
+
+
+// ##################################################################################
+//
+// Section 1. Call up the right driver file and any options for it
+//
+// ##################################################################################
+
+// Define STM32 to invoke optimised processor support (only for STM32)
+//#define STM32
+
+// Defining the STM32 board allows the library to optimise the performance
+// for UNO compatible "MCUfriend" style shields
+//#define NUCLEO_64_TFT
+//#define NUCLEO_144_TFT
+
+// STM32 8 bit parallel only:
+// If STN32 Port A or B pins 0-7 are used for 8 bit parallel data bus bits 0-7
+// then this will improve rendering performance by a factor of ~8x
+//#define STM_PORTA_DATA_BUS
+//#define STM_PORTA_DATA_BUS
+
+// Tell the library to use 8 bit parallel mode (otherwise SPI is assumed)
+//#define TFT_PARALLEL_8_BIT
+
+// Display type -  only define if RPi display
+//#define RPI_DISPLAY_TYPE // 20MHz maximum SPI
+
+// Only define one driver, the other ones must be commented out
+//#define ILI9341_DRIVER
+#define ST7735_DRIVER      // Define additional parameters below for this display
+//#define ILI9163_DRIVER     // Define additional parameters below for this display
+//#define S6D02A1_DRIVER
+//#define RPI_ILI9486_DRIVER // 20MHz maximum SPI
+//#define HX8357D_DRIVER
+//#define ILI9481_DRIVER
+//#define ILI9486_DRIVER
+//#define ILI9488_DRIVER     // WARNING: Do not connect ILI9488 display SDO to MISO if other devices share the SPI bus (TFT SDO does NOT tristate when CS is high)
+//#define ST7789_DRIVER      // Full configuration option, define additional parameters below for this display
+//#define ST7789_2_DRIVER    // Minimal configuration option, define additional parameters below for this display
+//#define R61581_DRIVER
+//#define RM68140_DRIVER
+//#define ST7796_DRIVER
+//#define SSD1963_480_DRIVER    // Untested
+//#define SSD1963_800_DRIVER    // Untested
+//#define SSD1963_800ALT_DRIVER // Untested
+
+// Some displays support SPI reads via the MISO pin, other displays have a single
+// bi-directional SDA pin and the library will try to read this via the MOSI line.
+// To use the SDA line for reading data from the TFT uncomment the following line:
+
+// #define TFT_SDA_READ      // This option is for ESP32 ONLY, tested with ST7789 display only
+
+// For ST7789 and ILI9341 ONLY, define the colour order IF the blue and red are swapped on your display
+// Try ONE option at a time to find the correct colour order for your display
+
+//  #define TFT_RGB_ORDER TFT_RGB  // Colour order Red-Green-Blue
+//  #define TFT_RGB_ORDER TFT_BGR  // Colour order Blue-Green-Red
+
+// For M5Stack ESP32 module with integrated ILI9341 display ONLY, remove // in line below
+
+// #define M5STACK
+
+// For ST7789, ST7735 and ILI9163 ONLY, define the pixel width and height in portrait orientation
+#define TFT_WIDTH  80
+// #define TFT_WIDTH  128
+// #define TFT_WIDTH  240 // ST7789 240 x 240 and 240 x 320
+#define TFT_HEIGHT 160
+// #define TFT_HEIGHT 128
+// #define TFT_HEIGHT 240 // ST7789 240 x 240
+// #define TFT_HEIGHT 320 // ST7789 240 x 320
+
+// For ST7735 ONLY, define the type of display, originally this was based on the
+// colour of the tab on the screen protector film but this is not always true, so try
+// out the different options below if the screen does not display graphics correctly,
+// e.g. colours wrong, mirror images, or tray pixels at the edges.
+// Comment out ALL BUT ONE of these options for a ST7735 display driver, save this
+// this User_Setup file, then rebuild and upload the sketch to the board again:
+
+// #define ST7735_INITB
+#define ST7735_GREENTAB
+// #define ST7735_GREENTAB2
+// #define ST7735_GREENTAB3
+// #define ST7735_GREENTAB128    // For 128 x 128 display
+// #define ST7735_GREENTAB160x80 // For 160 x 80 display (BGR, inverted, 26 offset)
+// #define ST7735_REDTAB
+// #define ST7735_BLACKTAB
+// #define ST7735_REDTAB160x80   // For 160 x 80 display with 24 pixel offset
+
+// If colours are inverted (white shows as black) then uncomment one of the next
+// 2 lines try both options, one of the options should correct the inversion.
+
+// #define TFT_INVERSION_ON
+// #define TFT_INVERSION_OFF
+
+
+// ##################################################################################
+//
+// Section 2. Define the pins that are used to interface with the display here
+//
+// ##################################################################################
+
+// If a backlight control signal is available then define the TFT_BL pin in Section 2
+// below. The backlight will be turned ON when tft.begin() is called, but the library
+// needs to know if the LEDs are ON with the pin HIGH or LOW. If the LEDs are to be
+// driven with a PWM signal or turned OFF/ON then this must be handled by the user
+// sketch. e.g. with digitalWrite(TFT_BL, LOW);
+
+#define TFT_BL   ST7735_BACKLIGHT_EN            // LED back-light control pin
+#define TFT_BACKLIGHT_ON HIGH  // Level to turn ON back-light (HIGH or LOW)
+
+
+
+// We must use hardware SPI, a minimum of 3 GPIO pins is needed.
+// Typical setup for ESP8266 NodeMCU ESP-12 is :
+//
+// Display SDO/MISO  to NodeMCU pin D6 (or leave disconnected if not reading TFT)
+// Display LED       to NodeMCU pin VIN (or 5V, see below)
+// Display SCK       to NodeMCU pin D5
+// Display SDI/MOSI  to NodeMCU pin D7
+// Display DC (RS/AO)to NodeMCU pin D3
+// Display RESET     to NodeMCU pin D4 (or RST, see below)
+// Display CS        to NodeMCU pin D8 (or GND, see below)
+// Display GND       to NodeMCU pin GND (0V)
+// Display VCC       to NodeMCU 5V or 3.3V
+//
+// The TFT RESET pin can be connected to the NodeMCU RST pin or 3.3V to free up a control pin
+//
+// The DC (Data Command) pin may be labeled AO or RS (Register Select)
+//
+// With some displays such as the ILI9341 the TFT CS pin can be connected to GND if no more
+// SPI devices (e.g. an SD Card) are connected, in this case comment out the #define TFT_CS
+// line below so it is NOT defined. Other displays such at the ST7735 require the TFT CS pin
+// to be toggled during setup, so in these cases the TFT_CS line must be defined and connected.
+//
+// The NodeMCU D0 pin can be used for RST
+//
+//
+// Note: only some versions of the NodeMCU provide the USB 5V on the VIN pin
+// If 5V is not available at a pin you can use 3.3V but backlight brightness
+// will be lower.
+
+
+// ###### EDIT THE PIN NUMBERS IN THE LINES FOLLOWING TO SUIT YOUR ESP8266 SETUP ######
+
+// For NodeMCU - use pin numbers in the form PIN_Dx where Dx is the NodeMCU pin designation
+#define TFT_CS   ST7735_CS  // Chip select control pin D8
+#define TFT_DC   ST7735_RS  // Data Command control pin
+#define TFT_RST  ST7735_RESET  // Reset pin (could connect to NodeMCU RST, see next line)
+//#define TFT_RST  -1    // Set TFT_RST to -1 if the display RESET is connected to NodeMCU RST or 3.3V
+
+//#define TFT_BL PIN_D1  // LED back-light (only for ST7789 with backlight control pin)
+
+//#define TOUCH_CS PIN_D2     // Chip select pin (T_CS) of touch screen
+
+//#define TFT_WR PIN_D2       // Write strobe for modified Raspberry Pi TFT only
+
+
+// ######  FOR ESP8266 OVERLAP MODE EDIT THE PIN NUMBERS IN THE FOLLOWING LINES  ######
+
+// Overlap mode shares the ESP8266 FLASH SPI bus with the TFT so has a performance impact
+// but saves pins for other functions. It is best not to connect MISO as some displays
+// do not tristate that line wjen chip select is high!
+// On NodeMCU 1.0 SD0=MISO, SD1=MOSI, CLK=SCLK to connect to TFT in overlap mode
+// On NodeMCU V3  S0 =MISO, S1 =MOSI, S2 =SCLK
+// In ESP8266 overlap mode the following must be defined
+
+//#define TFT_SPI_OVERLAP
+
+// In ESP8266 overlap mode the TFT chip select MUST connect to pin D3
+//#define TFT_CS   PIN_D3
+//#define TFT_DC   PIN_D5  // Data Command control pin
+//#define TFT_RST  PIN_D4  // Reset pin (could connect to NodeMCU RST, see next line)
+//#define TFT_RST  -1  // Set TFT_RST to -1 if the display RESET is connected to NodeMCU RST or 3.3V
+
+
+// ###### EDIT THE PIN NUMBERS IN THE LINES FOLLOWING TO SUIT YOUR ESP32 SETUP   ######
+
+// For ESP32 Dev board (only tested with ILI9341 display)
+// The hardware SPI can be mapped to any pins
+
+//#define TFT_MISO 19
+//#define TFT_MOSI 23
+//#define TFT_SCLK 18
+//#define TFT_CS   15  // Chip select control pin
+//#define TFT_DC    2  // Data Command control pin
+//#define TFT_RST   4  // Reset pin (could connect to RST pin)
+//#define TFT_RST  -1  // Set TFT_RST to -1 if display RESET is connected to ESP32 board RST
+
+//#define TOUCH_CS 21     // Chip select pin (T_CS) of touch screen
+
+//#define TFT_WR 22    // Write strobe for modified Raspberry Pi TFT only
+
+// For the M5Stack module use these #define lines
+//#define TFT_MISO 19
+//#define TFT_MOSI 23
+//#define TFT_SCLK 18
+//#define TFT_CS   14  // Chip select control pin
+//#define TFT_DC   27  // Data Command control pin
+//#define TFT_RST  33  // Reset pin (could connect to Arduino RESET pin)
+//#define TFT_BL   32  // LED back-light (required for M5Stack)
+
+// ######       EDIT THE PINs BELOW TO SUIT YOUR ESP32 PARALLEL TFT SETUP        ######
+
+// The library supports 8 bit parallel TFTs with the ESP32, the pin
+// selection below is compatible with ESP32 boards in UNO format.
+// Wemos D32 boards need to be modified, see diagram in Tools folder.
+// Only ILI9481 and ILI9341 based displays have been tested!
+
+// Parallel bus is only supported for the STM32 and ESP32
+// Example below is for ESP32 Parallel interface with UNO displays
+
+// Tell the library to use 8 bit parallel mode (otherwise SPI is assumed)
+//#define TFT_PARALLEL_8_BIT
+
+// The ESP32 and TFT the pins used for testing are:
+//#define TFT_CS   33  // Chip select control pin (library pulls permanently low
+//#define TFT_DC   15  // Data Command control pin - must use a pin in the range 0-31
+//#define TFT_RST  32  // Reset pin, toggles on startup
+
+//#define TFT_WR    4  // Write strobe control pin - must use a pin in the range 0-31
+//#define TFT_RD    2  // Read strobe control pin
+
+//#define TFT_D0   12  // Must use pins in the range 0-31 for the data bus
+//#define TFT_D1   13  // so a single register write sets/clears all bits.
+//#define TFT_D2   26  // Pins can be randomly assigned, this does not affect
+//#define TFT_D3   25  // TFT screen update performance.
+//#define TFT_D4   17
+//#define TFT_D5   16
+//#define TFT_D6   27
+//#define TFT_D7   14
+
+// ######       EDIT THE PINs BELOW TO SUIT YOUR STM32 SPI TFT SETUP        ######
+
+// The TFT can be connected to SPI port 1 or 2
+//#define TFT_SPI_PORT 1 // SPI port 1 maximum clock rate is 55MHz
+//#define TFT_MOSI PA7
+//#define TFT_MISO PA6
+//#define TFT_SCLK PA5
+
+//#define TFT_SPI_PORT 2 // SPI port 2 maximum clock rate is 27MHz
+//#define TFT_MOSI PB15
+//#define TFT_MISO PB14
+//#define TFT_SCLK PB13
+
+// Can use Ardiuno pin references, arbitrary allocation, TFT_eSPI controls chip select
+//#define TFT_CS   D5 // Chip select control pin to TFT CS
+//#define TFT_DC   D6 // Data Command control pin to TFT DC (may be labelled RS = Register Select)
+//#define TFT_RST  D7 // Reset pin to TFT RST (or RESET)
+// OR alternatively, we can use STM32 port reference names PXnn
+//#define TFT_CS   PE11 // Nucleo-F767ZI equivalent of D5
+//#define TFT_DC   PE9  // Nucleo-F767ZI equivalent of D6
+//#define TFT_RST  PF13 // Nucleo-F767ZI equivalent of D7
+
+//#define TFT_RST  -1   // Set TFT_RST to -1 if the display RESET is connected to processor reset
+                        // Use an Arduino pin for initial testing as connecting to processor reset
+                        // may not work (pulse too short at power up?)
+
+// ##################################################################################
+//
+// Section 3. Define the fonts that are to be used here
+//
+// ##################################################################################
+
+// Comment out the #defines below with // to stop that font being loaded
+// The ESP8366 and ESP32 have plenty of memory so commenting out fonts is not
+// normally necessary. If all fonts are loaded the extra FLASH space required is
+// about 17Kbytes. To save FLASH space only enable the fonts you need!
+
+//#define LOAD_GLCD   // Font 1. Original Adafruit 8 pixel font needs ~1820 bytes in FLASH
+//#define LOAD_FONT2  // Font 2. Small 16 pixel high font, needs ~3534 bytes in FLASH, 96 characters
+//#define LOAD_FONT4  // Font 4. Medium 26 pixel high font, needs ~5848 bytes in FLASH, 96 characters
+//#define LOAD_FONT6  // Font 6. Large 48 pixel font, needs ~2666 bytes in FLASH, only characters 1234567890:-.apm
+//#define LOAD_FONT7  // Font 7. 7 segment 48 pixel font, needs ~2438 bytes in FLASH, only characters 1234567890:-.
+//#define LOAD_FONT8  // Font 8. Large 75 pixel font needs ~3256 bytes in FLASH, only characters 1234567890:-.
+//#define LOAD_FONT8N // Font 8. Alternative to Font 8 above, slightly narrower, so 3 digits fit a 160 pixel TFT
+//#define LOAD_GFXFF  // FreeFonts. Include access to the 48 Adafruit_GFX free fonts FF1 to FF48 and custom fonts
+
+// Comment out the #define below to stop the SPIFFS filing system and smooth font code being loaded
+// this will save ~20kbytes of FLASH
+//#define SMOOTH_FONT
+
+
+// ##################################################################################
+//
+// Section 4. Other options
+//
+// ##################################################################################
+
+// Define the SPI clock frequency, this affects the graphics rendering speed. Too
+// fast and the TFT driver will not keep up and display corruption appears.
+// With an ILI9341 display 40MHz works OK, 80MHz sometimes fails
+// With a ST7735 display more than 27MHz may not work (spurious pixels and lines)
+// With an ILI9163 display 27 MHz works OK.
+
+// #define SPI_FREQUENCY   1000000
+// #define SPI_FREQUENCY   5000000
+// #define SPI_FREQUENCY  10000000
+// #define SPI_FREQUENCY  20000000
+#define SPI_FREQUENCY  27000000
+// #define SPI_FREQUENCY  40000000
+// #define SPI_FREQUENCY  55000000 // STM32 SPI1 only (SPI2 maximum is 27MHz)
+// #define SPI_FREQUENCY  80000000
+
+// Optional reduced SPI frequency for reading TFT
+#define SPI_READ_FREQUENCY  20000000
+
+// The XPT2046 requires a lower SPI clock rate of 2.5MHz so we define that here:
+#define SPI_TOUCH_FREQUENCY  2500000
+
+// The ESP32 has 2 free SPI ports i.e. VSPI and HSPI, the VSPI is the default.
+// If the VSPI port is in use and pins are not accessible (e.g. TTGO T-Beam)
+// then uncomment the following line:
+//#define USE_HSPI_PORT
+
+// Comment out the following #define if "SPI Transactions" do not need to be
+// supported. When commented out the code size will be smaller and sketches will
+// run slightly faster, so leave it commented out unless you need it!
+
+// Transaction support is needed to work with SD library but not needed with TFT_SdFat
+// Transaction support is required if other SPI devices are connected.
+
+// Transactions are automatically enabled by the library for an ESP32 (to use HAL mutex)
+// so changing it here has no effect
+
+// #define SUPPORT_TRANSACTIONS

src/bare/SPIFFS.h

@@ -1,3 +0,0 @@
-#pragma once
-
-// FIXME - make a FS abstraction for NRF52

src/bare/main-bare.cpp

@@ -1,6 +0,0 @@
-#include "target_specific.h"
-
-void setBluetoothEnable(bool on)
-{
-    // Do nothing
-}

src/commands.h

@@ -0,0 +1,15 @@
+/**
+ * @brief This class enables on the fly software and hardware setup.
+ *        It will contain all command messages to change internal settings.
+ */
+
+enum class Cmd {
+        INVALID,
+        SET_ON,
+        SET_OFF,
+        ON_PRESS,
+        START_BLUETOOTH_PIN_SCREEN,
+        STOP_BLUETOOTH_PIN_SCREEN,
+        STOP_BOOT_SCREEN,
+        PRINT,
+};

src/concurrency/Lock.cpp

@@ -1,9 +1,7 @@
-#include "lock.h"
-
+#include "Lock.h"
 #include <cassert>
 
-namespace meshtastic
-{
+namespace concurrency {
 
 Lock::Lock()
 {
@@ -22,14 +20,4 @@ void Lock::unlock()
     assert(xSemaphoreGive(handle));
 }
 
-LockGuard::LockGuard(Lock *lock) : lock(lock)
-{
-    lock->lock();
-}
-
-LockGuard::~LockGuard()
-{
-    lock->unlock();
-}
-
-} // namespace meshtastic
+} // namespace concurrency

src/concurrency/Lock.h

@@ -0,0 +1,33 @@
+#pragma once
+
+#include "../freertosinc.h"
+
+namespace concurrency {
+
+/**
+ * @brief Simple wrapper around FreeRTOS API for implementing a mutex lock
+ */
+class Lock
+{
+  public:
+    Lock();
+
+    Lock(const Lock &) = delete;
+    Lock &operator=(const Lock &) = delete;
+
+    /// Locks the lock.
+    //
+    // Must not be called from an ISR.
+    void lock();
+
+    // Unlocks the lock.
+    //
+    // Must not be called from an ISR.
+    void unlock();
+
+  private:
+    SemaphoreHandle_t handle;
+
+};
+
+} // namespace concurrency