release 0.1.6

Root cause seems to be the axp192 interrupt, which on some boards fires
during sleep.  I'm not sure why, but we don't need this yet, so leaving
masked during sleep.

.github/workflows/main.yml

@@ -0,0 +1,19 @@
+name: Continuous Integration
+on: push
+
+jobs:
+  main:
+    name: Main
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@master
+      - name: Setup Python
+        uses: actions/setup-python@master
+        with:
+          python-version: 3.x
+      - name: Install Platform IO
+        run: |
+          python -m pip install --upgrade pip
+          pip install -U platformio
+      - name: Build
+        run: platformio run

.gitmodules

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

.vscode/settings.json

@@ -46,6 +46,7 @@
     },
     "cSpell.words": [
         "Meshtastic",
-        "descs"
+        "descs",
+        "protobufs"
     ]
 }

README.md

@@ -1,6 +1,8 @@
 # Meshtastic-esp32
 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
 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
@@ -11,27 +13,27 @@ 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 chat [![Join the chat at https://gitter.im/Meshtastic/community](https://badges.gitter.im/Meshtastic/community.svg)](https://gitter.im/Meshtastic/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge).
+This project is currently early-alpha, but 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 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 users should buy the T-Beam and a 18650 battery (total cost less than $35).  Make
+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 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.
 
 See (meshtastic.org) for 3D printable cases.
 
 ## Installing the firmware
-Prebuilt binaries for the supported radios is available in our [releases](https://github.com/geeksville/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.
+Prebuilt binaries for the supported radios is 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.
 
 The instructions currently require a few commmand lines, but it should be pretty straightforward.  Please post comments on our group chat if you have problems or successes.  Steps to install:
 
-1. Purchase a radio (see above) with the correct frequencies for your country (915MHz for US or JP, 470MHz for CN, 870MHz for EU).
+1. Purchase a radio (see above) with the correct frequencies for your country (915MHz for US or JP, 470MHz for CN, 433MHz and 870MHz for EU).
 2. Install "pip".  Pip is the python package manager we use to get the esptool installer app.  Instructions [here](https://www.makeuseof.com/tag/install-pip-for-python/).
 3. Run "pip install --upgrade esptool" to get esptool installed on your machine
 4. Connect your radio to your USB port
-5. Confirm that your device is talking to your PC by running "esptool.py chip_id".  You should see something like:
+5. Confirm that your device is talking to your PC by running "esptool.py chip_id".  The Heltec build also works on the TTGO LORA32 radio. You should see something like:
 ```
 mydir$ esptool.py chip_id
 esptool.py v2.6
@@ -76,23 +78,25 @@ Hard resetting via RTS pin...
 8. Please post a comment on our chat so we know if these instructions worked for you ;-).  If you find bugs/have-questions post there also - we will be rapidly iterating over the next few weeks.
 
 ## Meshtastic Android app
-The source code for the (optional) Meshtastic Android app is [here](https://github.com/geeksville/Meshtastic-Android).
-Soon our first alpha release of will be released here:
+The source code for the (optional) Meshtastic Android app is [here](https://github.com/meshtastic/Meshtastic-Android).  
+
+Alpha test builds are current available by opting into our alpha test group.  See (www.meshtastic.org) for instructions.  
+
+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)
 
 # Development
-The following sections are probably only interesting if you want to join us in developing the software.  
 
-## 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).
+We'd love to have you join us on this merry little project.  Please see our [development documents](./docs/software/sw-design.md) and [join us in our discussion forum](https://meshtastic.discourse.group/).
 
-## 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.
+# Credits
 
-1. Purchase a suitable radio (see above)
-2. Install [PlatformIO](https://platformio.org/platformio-ide)
-3. Download this git repo and cd into it
-4. Plug the radio into your USB port
-4. Type "pio run -t upload" (This command will fetch dependencies, build the project and install it on the board via USB)
-5. 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
+This project is run by volunteers.  Past contributors include:
+
+* @astro-arphid: Added support for 433MHz radios in europe.
+* @claesg: Various documentation fixes and 3D print enclosures
+* @girtsf: So far our CI system, but soon lots of device improvements
+
+# IMPORTANT DISCLAIMERS AND FAQ
+
+For a listing of currently missing features and a FAQ click [here](docs/faq.md).

bin/build-all.sh

@@ -4,8 +4,8 @@ set -e
 
 source bin/version.sh
 
-# COUNTRIES="US EU CN JP"
-COUNTRIES=US
+COUNTRIES="US EU433 EU865 CN JP"
+# COUNTRIES=US
 
 SRCMAP=.pio/build/esp32/output.map
 SRCBIN=.pio/build/esp32/firmware.bin
@@ -26,13 +26,13 @@ for COUNTRY in $COUNTRIES; do
     rm -f $SRCBIN $SRCMAP
     pio run # -v
     cp $SRCBIN $OUTDIR/firmware-TBEAM-$COUNTRY-$VERSION.bin
-    cp $SRCMAP $ARCHIVEDIR/firmware-TBEAM-$COUNTRY-$VERSION.map
+    #cp $SRCMAP $ARCHIVEDIR/firmware-TBEAM-$COUNTRY-$VERSION.map
 
     export PLATFORMIO_BUILD_FLAGS="-DHELTEC_LORA32 $COMMONOPTS"
     rm -f $SRCBIN $SRCMAP
     pio run # -v
     cp $SRCBIN $OUTDIR/firmware-HELTEC-$COUNTRY-$VERSION.bin
-    cp $SRCMAP $ARCHIVEDIR/firmware-HELTEC-$COUNTRY-$VERSION.map
+    #cp $SRCMAP $ARCHIVEDIR/firmware-HELTEC-$COUNTRY-$VERSION.map
 done
 
 # keep the bins in archive also
@@ -50,6 +50,7 @@ Generated by bin/buildall.sh -->
 </resources>
 XML
 
+rm -f $ARCHIVEDIR/firmware-$VERSION.zip
 zip $ARCHIVEDIR/firmware-$VERSION.zip $OUTDIR/firmware-*-$VERSION.bin
 
 echo BUILT ALL

bin/program-release-heltec.sh

@@ -3,4 +3,4 @@ set -e
 
 source bin/version.sh
 
-esptool.py --baud 921600 write_flash 0x10000 release/firmware-HELTEC-US-$VERSION.bin
+esptool.py --baud 921600 write_flash 0x10000 release/latest/firmware-HELTEC-US-$VERSION.bin

bin/regen-protos.sh

@@ -1 +1,6 @@
-/home/kevinh/packages/nanopb-0.4.1-linux-x86/generator-bin/protoc --nanopb_out=-v:src -I=../MeshUtil/app/src/main/proto mesh.proto
+#!/bin/bash
+
+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

bin/version.sh

@@ -1,3 +1,3 @@
 
 
-export VERSION=0.0.5
+export VERSION=0.1.6

docs/.well-known/assetlinks.json

@@ -0,0 +1,9 @@
+[{
+  "relation": ["delegate_permission/common.handle_all_urls"],
+  "target": {
+    "namespace": "android_app",
+    "package_name": "com.geeksville.mesh",
+    "sha256_cert_fingerprints":
+    ["D0:05:E7:8B:D2:1B:FA:94:56:1D:6B:90:EB:53:07:1A:74:4F:D9:C2:6F:13:87:6A:D9:17:4F:C2:59:48:02:9D"]
+  }
+}]

docs/README.md

@@ -18,7 +18,7 @@ will optionally work with your phone, but no phone is required.
 [![Youtube video demo](desk-video-screenshot.png)](https://www.youtube.com/watch?v=WlNbMbVZlHI "Meshtastic early demo")
 
 ### Features
-Not all of these features are fully implemented yet - see below.  But they should be in by the time we decide to call this project beta (three months?)
+Not all of these features are fully implemented yet - see **important** disclaimers below.  But they should be in by the time we decide to call this project beta (three months?)
 
 * Very long battery life (should be about eight days with the beta software)
 * Built in GPS and [LoRa](https://en.wikipedia.org/wiki/LoRa) radio, but we manage the radio automatically for you
@@ -28,17 +28,20 @@ Not all of these features are fully implemented yet - see below.  But they shoul
 * 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.
-* Very easy sharing of private secured channels.  Just share a special link or QR code with other users and they can join your encrypted mesh
+* 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 chat [![Join the chat at https://gitter.im/Meshtastic/community](https://badges.gitter.im/Meshtastic/community.svg)](https://gitter.im/Meshtastic/community?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge).
+This project is currently in early alpha - 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](https://gitter.im/Meshtastic/community).  
+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/).
 
 # 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.
+
+* 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/geeksville/Meshtastic-esp32/blob/master/README.md) for instructions.
-* 02/20/2020 - Our first alpha release (0.0.3) of the radio software is ready for early users.  
+* 02/23/2020 - 0.0.4 release.  Still very bleeding edge but much closer to the final power management, a charged T-BEAM should run for many days with this load.  If you'd like to try it, we'd love your feedback.  Click [here](https://github.com/meshtastic/Meshtastic-esp32/blob/master/README.md) for instructions.
+* 02/20/2020 - Our first alpha release (0.0.3) of the radio software is ready brave early people.  
 
 ## Meshtastic Android app
 Once out of alpha the companion Android application will be released here:
@@ -49,32 +52,22 @@ But if you want the bleeding edge app now, we'd love to have your help testing.
 
 1. Join [this Google group](https://groups.google.com/forum/#!forum/meshtastic-alpha-testers) with the account you use in Google Play.
 2. Go to this [URL](https://play.google.com/apps/testing/com.geeksville.mesh) to opt-in to the alpha test.
-3. If you encounter any problems or have questions, post in our gitter chat and we'll help.
+3. If you encounter any problems or have questions, post in our [forum](https://meshtastic.discourse.group/) and we'll help.
 
-If you'd like to help with development, the source code is [on github](https://github.com/geeksville/Meshtastic-Android).
+If you'd like to help with development, the source code is [on github](https://github.com/meshtastic/Meshtastic-Android).
 
 ## Supported hardware
-We currently support two brands of radios.  The [TTGO T-Beam](https://www.aliexpress.com/item/4000119152086.html) and the [Heltec LoRa 32](https://heltec.org/project/wifi-lora-32/).  Most users 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/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.
 
-Instructions for installing prebuilt firmware can be found [here](https://github.com/geeksville/Meshtastic-esp32/blob/master/README.md).
+Instructions for installing prebuilt firmware can be found [here](https://github.com/meshtastic/Meshtastic-esp32/blob/master/README.md).
 
-For a nice TTGO 3D printable case see this [design](https://www.thingiverse.com/thing:3773717) by [bsiege](https://www.thingiverse.com/bsiege).
-For a nice Heltec 3D printable case see this [design](https://www.thingiverse.com/thing:3125854) by [ornotermes](https://www.thingiverse.com/ornotermes).
+For a nice printable cases:
 
-# Disclaimers
+1. TTGO T-Beam V0 see this [design](https://www.thingiverse.com/thing:3773717) by [bsiege](https://www.thingiverse.com/bsiege).
+2. TTGO T_Beam V1 see this [design](https://www.thingiverse.com/thing:3830711) by [rwanrooy](https://www.thingiverse.com/rwanrooy) or this [remix](https://www.thingiverse.com/thing:3949330) by [8ung](https://www.thingiverse.com/8ung)
+3. Heltec Lora32 see this [design](https://www.thingiverse.com/thing:3125854) by [ornotermes](https://www.thingiverse.com/ornotermes).
 
-This project is still pretty young but moving at a pretty good pace.  Not all features are fully implemented in the current alpha builds.
-Most of these problems should be solved by the beta release:
+# IMPORTANT DISCLAIMERS AND FAQ
 
-* 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
-* A number of (straightforward) software work items have to be completed before battery life matches our measurements, currently battery life is about two days.  Join us on chat if you want the spreadsheet of power measurements/calculations.
-* The current Android GUI is pretty ugly still
-* The Android API needs to be documented better
-* The Bluetooth API needs to be documented better 
-* The mesh protocol is turned off for now, currently we only send packets one hop distant
-* No one has written an iOS app yet ;-)
-
-For more details see the [device software TODO](https://github.com/geeksville/Meshtastic-esp32/blob/master/TODO.md) or the [Android app TODO](https://github.com/geeksville/Meshtastic-Android/blob/master/TODO.md).
+For a listing of currently missing features and a FAQ click [here](faq.md).

docs/faq.md

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

docs/mesh-proto.md

@@ -0,0 +1,20 @@
+TODO:
+* reread the radiohead mesh implementation
+* read about general mesh flooding solutions
+* reread the disaster radio protocol docs
+
+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/privacy.md

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

docs/radio-settings.md

@@ -10,6 +10,13 @@ See [this site](https://www.rfwireless-world.com/Tutorials/LoRa-channels-list.ht
 
 The maximum power allowed is +14dBM.
 
+### 433 MHz
+
+There are eight channels defined with a 0.2 MHz gap between them.
+Channel zero starts at 433.175 MHz
+
+### 870 MHz
+
 There are eight channels defined with a 0.3 MHz gap between them.
 Channel zero starts at 865.20 MHz
 

docs/software/TODO.md

@@ -2,88 +2,85 @@
 
 Items to complete soon (next couple of alpha releases).
 
-* text messages are not showing on local screen if screen was on
-
-* The following three items are all the same:
- 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).
- 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)
-
 * 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.
 
-* retest BLE software update for both board types
-* report on wikifactory
-* send note to the guy who designed the cases
+* 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
+
 * remeasure wake time power draws now that we run CPU down at 80MHz
+* add a SF12 transmit option for _super_ long range
+
+# AXP192 tasks
+* "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
 
 # Medium priority
 
 Items to complete before the first beta release.
 
+* Make a FAQ
+* good source of battery/signal/gps icons https://materialdesignicons.com/
+* 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
-* "AXP192 interrupt is not firing, remove this temporary polling of battery state"
-* make mesh aware network timing state machine (sync wake windows to gps time)
-* turn light sleep on aggressively (while lora is on but BLE off)
 * research and implement better mesh algorithm
 * the BLE stack is leaking about 200 bytes each time we go to light sleep
-* use gps sleep mode instead of killing its power (to allow fast position when we wake)
 * 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
-* Use the Periodic class for both position and user periodic broadcasts
-* make debug info screen show real data (including battery level & charging)
-* don't forward redundant pings or ping responses to the phone, it just wastes phone battery
-* don't treat north as up, instead adjust shown bearings for our guess at the users heading (i.e. subtract one from the other)
-* answer to pings (because some other user is looking at our nodeinfo) with our latest 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.
-* use https://platformio.org/lib/show/1260/OneButton if necessary
-* make an about to sleep screen
-* don't send location packets if we haven't moved
-* scrub default radio config settings for bandwidth/range/speed
 * 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
-* override peekAtMessage so we can see any messages that pass through our node (even if not broadcast)?  would that be useful?
-* sendToMesh can currently block for a long time, instead have it just queue a packet for a radio freertos thread
-* How do avalanche beacons work?  Could this do that as well?  possibly by using beacon mode feature of the RF95?
-* 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
 * 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
 
 # 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 ;-) )
 
+* figure out why this fixme is needed: "FIXME, disable wake due to PMU because it seems to fire all the time?"
+* 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
-* 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
 * 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
-* use variable length arduino Strings in protobufs (instead of current fixed buffers)
-* 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/ 
 * make sure main cpu is not woken for packets with bad crc or not addressed to this node - do that in the radio hw
-* enable fast init inside the gps chip
 * triple check fcc compliance
-* pick channel center frequency based on name? "dolphin" would hash to 900Mhz, "cat" to 905MHz etc?  Or is that too opaque?
-* scan to find channels with low background noise?
-* share channel settings over Signal (or qr code) by embedding an an URL which is handled by the MeshUtil app.
+* pick channel center frequency based on channel name? "dolphin" would hash to 900Mhz, "cat" to 905MHz etc?  allows us to hide the concept of channel # from hte user.
+* scan to find channels with low background noise? (Use CAD mode of the RF95 to automatically find low noise channels)
+* make a no bluetooth configured yet screen - include this screen in the loop if the user hasn't yet paired
+* if radio params change fundamentally, discard the nodedb
+* reneable the bluetooth battery level service on the T-BEAM, because we can read battery level there
+
+# 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.
-* Use CAD mode of the RF95 to automatically find low noise channels
 * read the PMU battery fault indicators and blink/led/warn user on screen
-* make a no bluetooth configured yet screen - include this screen in the loop if the user hasn't yet paired
 * 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.
-* if radio params change fundamentally, discard the nodedb
 * 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) 
@@ -93,9 +90,7 @@ Items after the first final candidate release.
 * 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
-* fix GPS.zeroOffset calculation it is wrong
 * handle millis() rollover in GPS.getTime - otherwise we will break after 50 days
-* reneable the bluetooth battery level service on the T-BEAM, because we can read battery level there
 * report esp32 device code bugs back to the mothership via android
 
 # Done
@@ -183,3 +178,26 @@ Items after the first final candidate release.
 * 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

docs/software/bluetooth-api.md

@@ -0,0 +1,110 @@
+# 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

@@ -0,0 +1,16 @@
+# Build instructions
+
+This project uses the simple PlatformIO build system. You can use the IDE, but for brevity
+in these instructions I describe use of their command line tool.
+
+1. Purchase a suitable radio (see above)
+2. Install [PlatformIO](https://platformio.org/platformio-ide)
+3. Download this git repo and cd into it
+4. Edit configuration.h and comment out *one* of the following two lines (depending on which board you are using):
+```
+// #define T_BEAM_V10  
+#define HELTEC_LORA32
+```
+5. Plug the radio into your USB port
+6. Type "pio run -t upload" (This command will fetch dependencies, build the project and install it on the board via USB)
+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

docs/software/mesh-alg.md

@@ -0,0 +1,72 @@
+# 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.
+
+great source of papers and class notes: http://www.cs.jhu.edu/~cs647/
+
+TODO:
+* DONE reread the radiohead mesh implementation - hop to hop acknoledgement 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
+* 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)
+
+good description of batman protocol: https://www.open-mesh.org/projects/open-mesh/wiki/BATMANConcept
+
+interesting paper on lora mesh: https://portal.research.lu.se/portal/files/45735775/paper.pdf
+It seems like  DSR might be the algorithm used by RadioheadMesh.  DSR is described in https://tools.ietf.org/html/rfc4728
+https://en.wikipedia.org/wiki/Dynamic_Source_Routing
+
+broadcast solution:
+Use naive flooding at first (FIXME - do some math for a 20 node, 3 hop mesh.  A single flood will require a max of 20 messages sent)
+Then move to MPR later (http://www.olsr.org/docs/report_html/node28.html).  Use altitude and location as heursitics in selecting the MPR set
+
+compare to db sync algorithm?
+
+what about never flooding gps broadcasts.  instead only have them go one hop in the common case, but if any node X is looking at the position of Y on their gui, then send a unicast to Y asking for position update.  Y replies.
+
+If Y were to die, at least the neighbor nodes of Y would have their last known position of Y.
+
+## approach 1
+
+* send all broadcasts with a TTL
+* periodically(?) do a survey to find the max TTL that is needed to fully cover the current network.
+* to do a study first send a broadcast (maybe our current initial user announcement?) with TTL set to one (so therefore no one will rebroadcast our request)
+* survey replies are sent unicast back to us (and intervening nodes will need to keep the route table that they have built up based on past packets)
+* count the number of replies to this TTL 1 attempt.  That is the number of nodes we can reach without any rebroadcasts
+* repeat the study with a TTL of 2 and then 3.  stop once the # of replies stops going up.
+* it is important for any node to do listen before talk to prevent stomping on other rebroadcasters...
+* For these little networks I bet a max TTL would never be higher than 3?
+
+## approach 2
+
+* send a TTL1 broadcast, the replies let us build a list of the nodes (stored as a bitvector?) that we can see (and their rssis)
+* we then broadcast out that bitvector (also TTL1) asking "can any of ya'll (even indirectly) see anyone else?"
+* if a node can see someone I missed (and they are the best person to see that node), they reply (unidirectionally) with the missing nodes and their rssis (other nodes might sniff (and update their db) based on this reply but they don't have to)
+* given that the max number of nodes in this mesh will be like 20 (for normal cases), I bet globally updating this db of "nodenums and who has the best rssi for packets from that node" would be useful
+* once the global DB is shared, when a node wants to broadcast, it just sends out its broadcast . the first level receivers then make a decision "am I the best to rebroadcast to someone who likely missed this packet?" if so, rebroadcast
+
+## approach 3
+
+* when a node X wants to know other nodes positions, it broadcasts its position with want_replies=true.  Then each of the nodes that received that request broadcast their replies (possibly by using special timeslots?)
+* all nodes constantly update their local db based on replies they witnessed.
+* after 10s (or whatever) if node Y notices that it didn't hear a reply from node Z (that Y has heard from recently ) to that initial request, that means Z never heard the request from X.  Node Y will reply to X on Z's behalf.
+* could this work for more than one hop?  Is more than one hop needed?  Could it work for sending messages (i.e. for a msg sent to Z with want-reply set). 
+
+## approach 4
+
+look into the literature for this idea specifically.
+
+* don't view it as a mesh protocol as much as a "distributed db unification problem".  When nodes talk to nearby nodes they work together
+to update their nodedbs.  Each nodedb would have a last change date and any new changes that only one node has would get passed to the 
+other node.  This would nicely allow distant nodes to propogate their position to all other nodes (eventually).
+* handle group messages the same way, there would be a table of messages and time of creation.
+* when a node has a new position or message to send out, it does a broadcast.  All the adjacent nodes update their db instantly (this handles 90% of messages I'll bet).  
+* Occasionally a node might broadcast saying "anyone have anything newer than time X?"  If someone does, they send the diffs since that date.
+* essentially everything in this variant becomes broadcasts of "request db updates for >time X - for _all_ or for a particular nodenum" and nodes sending (either due to request or because they changed state) "here's a set of db updates".  Every node is constantly trying to
+build the most recent version of reality, and if some nodes are too far, then nodes closer in will eventually forward their changes to the distributed db.
+* construct non ambigious rules for who broadcasts to request db updates.  ideally the algorithm should nicely realize node X can see most other nodes, so they should just listen to all those nodes and minimize the # of broadcasts. the distributed picture of nodes rssi could be useful here?
+* possibly view the BLE protocol to the radio the same way - just a process of reconverging the node/msgdb database.

docs/software/power.md

@@ -1,12 +1,16 @@
-This is a mini design doc for various core behaviors...
+# Power Management State Machine
 
-# Rules for sleep
+i.e. sleep behavior
+
+## Power measurements
+
+Since one of the main goals of this project is long battery life, it is important to consider that in our software/protocol design.  Based on initial measurements it seems that the current code should run about three days between charging, and with a bit more software work (see the [TODO list](TODO.md)) a battery life of eight days should be quite doable.  Our current power measurements/model is in [this spreadsheet](https://docs.google.com/spreadsheets/d/1ft1bS3iXqFKU8SApU8ZLTq9r7QQEGESYnVgdtvdT67k/edit?usp=sharing).
 
 ## States
 
 From lower to higher power consumption.
 
-* Super-deep-sleep (SDS) - everything is off, CPU, radio, bluetooth, GPS.  Only wakes due to timer or button press
+* 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)
 
@@ -53,8 +57,9 @@ off during light sleep, but there is a TODO item to fix this.
 * 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 into LS: If either phone_sds_timeout_secs (default 1 hr) or mesh_sds_timeout_secs (default 1 hr) are exceeded we will lower into SDS mode for sds_secs (default 1 hr) (or a button press).  
-* Any time we enter LS mode: We stay in that mode for ls_secs (default 1 hr) (or until an interrupt, button press)
+* 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...
@@ -78,49 +83,3 @@ General ideas to hit the power draws our spreadsheet predicts.  Do the easy ones
 * 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.
-
-# Mesh broadcast algoritm
-
-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 inefficent.
-
-## approach 1
-
-* send all broadcasts with a TTL
-* periodically(?) do a survey to find the max TTL that is needed to fully cover the current network.
-* to do a study first send a broadcast (maybe our current initial user announcement?) with TTL set to one (so therefore no one will rebroadcast our request)
-* survey replies are sent unicast back to us (and intervening nodes will need to keep the route table that they have built up based on past packets)
-* count the number of replies to this TTL 1 attempt.  That is the number of nodes we can reach without any rebroadcasts
-* repeat the study with a TTL of 2 and then 3.  stop once the # of replies stops going up.
-* it is important for any node to do listen before talk to prevent stomping on other rebroadcasters...
-* For these little networks I bet a max TTL would never be higher than 3?
-
-## approach 2
-
-* send a TTL1 broadcast, the replies let us build a list of the nodes (stored as a bitvector?) that we can see (and their rssis)
-* we then broadcast out that bitvector (also TTL1) asking "can any of ya'll (even indirectly) see anyone else?"
-* if a node can see someone I missed (and they are the best person to see that node), they reply (unidirectionally) with the missing nodes and their rssis (other nodes might sniff (and update their db) based on this reply but they don't have to)
-* given that the max number of nodes in this mesh will be like 20 (for normal cases), I bet globally updating this db of "nodenums and who has the best rssi for packets from that node" would be useful
-* once the global DB is shared, when a node wants to broadcast, it just sends out its broadcast . the first level receivers then make a decision "am I the best to rebroadcast to someone who likely missed this packet?" if so, rebroadcast
-
-## approach 3
-
-* when a node X wants to know other nodes positions, it broadcasts its position with want_replies=true.  Then each of the nodes that received that request broadcast their replies (possibly by using special timeslots?)
-* all nodes constantly update their local db based on replies they witnessed.
-* after 10s (or whatever) if node Y notices that it didn't hear a reply from node Z (that Y has heard from recently ) to that initial request, that means Z never heard the request from X.  Node Y will reply to X on Z's behalf.
-* could this work for more than one hop?  Is more than one hop needed?  Could it work for sending messages (i.e. for a msg sent to Z with want-reply set). 
-
-## approach 4
-
-look into the literature for this idea specifically.
-
-* don't view it as a mesh protocol as much as a "distributed db unification problem".  When nodes talk to nearby nodes they work together
-to update their nodedbs.  Each nodedb would have a last change date and any new changes that only one node has would get passed to the 
-other node.  This would nicely allow distant nodes to propogate their position to all other nodes (eventually).
-* handle group messages the same way, there would be a table of messages and time of creation.
-* when a node has a new position or message to send out, it does a broadcast.  All the adjacent nodes update their db instantly (this handles 90% of messages I'll bet).  
-* Occasionally a node might broadcast saying "anyone have anything newer than time X?"  If someone does, they send the diffs since that date.
-* essentially everything in this variant becomes broadcasts of "request db updates for >time X - for _all_ or for a particular nodenum" and nodes sending (either due to request or because they changed state) "here's a set of db updates".  Every node is constantly trying to
-build the most recent version of reality, and if some nodes are too far, then nodes closer in will eventually forward their changes to the distributed db.
-* construct non ambigious rules for who broadcasts to request db updates.  ideally the algorithm should nicely realize node X can see most other nodes, so they should just listen to all those nodes and minimize the # of broadcasts. the distributed picture of nodes rssi could be useful here?
-* possibly view the BLE protocol to the radio the same way - just a process of reconverging the node/msgdb database.

docs/software/sw-design.md

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

lib/BluetoothOTA/library.json

@@ -2,13 +2,11 @@
   "name": "BluetoothOTA",
   "keywords": "esp32, bluetooth",
   "description": "A BTLE based software OTA update tool",
-  "repository":
-  {
+  "repository": {
     "type": "git",
     "url": "https://github.com/geeksville/fixme.git"
   },
-  "authors":
-  [
+  "authors": [
     {
       "name": "Kevin Hester",
       "email": "kevinh@geeksville.com",
@@ -20,7 +18,15 @@
   "frameworks": "arduino",
   "platforms": "*",
   "dependencies": [
-    { "name": "Update" },
-    { "name": "ESP32 BLE Arduino" }
+    {
+      "name": "Update"
+    },
+    {
+      "name": "ESP32 BLE Arduino"
+    },
+    {
+      "name": "arduino-fsm",
+      "version": "https://github.com/meshtastic/arduino-fsm.git"
+    }
   ]
 }

lib/BluetoothOTA/src/BluetoothSoftwareUpdate.cpp

@@ -117,21 +117,7 @@ void bluetoothRebootCheck()
 }
 
 /*
-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
-
-We also implement the following standard GATT entries because SW update probably needs them:
-
-ESP_GATT_UUID_SW_VERSION_STR/0x2a28
-ESP_GATT_UUID_MANU_NAME/0x2a29
-ESP_GATT_UUID_HW_VERSION_STR/0x2a27
+See bluetooth-api.md
 
  */
 BLEService *createUpdateService(BLEServer *server, std::string hwVendor, std::string swVersion, std::string hwVersion)

lib/BluetoothOTA/src/BluetoothUtil.cpp

@@ -212,7 +212,7 @@ class MySecurity : public BLESecurityCallbacks
     }
 
     // Remove our custom screen
-    screen_set_frames();
+    screen.setFrames();
   }
 };
 

mesh.options

@@ -1 +0,0 @@
-../MeshUtil/app/src/main/proto/mesh.options

mesh.proto

@@ -1 +0,0 @@
-../MeshUtil/app/src/main/proto/mesh.proto

platformio.ini

@@ -21,8 +21,8 @@ framework = arduino
 board_build.partitions = partition-table.csv
 
 ; note: we add src to our include search path so that lmic_project_config can override
-; FIXME fix dependencies on arduino-fsm
-build_flags = -Wall -Wextra -Wno-missing-field-initializers -I.pio/libdeps/esp32/arduino-fsm -Isrc -Os -Wl,-Map,.pio/build/esp32/output.map -DAXP_DEBUG_PORT=Serial 
+; FIXME: fix lib/BluetoothOTA dependency back on src/ so we can remove -Isrc
+build_flags = -Wall -Wextra -Wno-missing-field-initializers -Isrc -Os -Wl,-Map,.pio/build/esp32/output.map -DAXP_DEBUG_PORT=Serial
 
 ; 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
@@ -55,16 +55,18 @@ debug_tool = jlink
 
 debug_init_break = tbreak setup
 
+; Note: some libraries are specified by #ID where there are conflicting library
+; names.
 lib_deps =
-  https://github.com/geeksville/RadioHead.git
-  TinyGPSPlus
-  https://github.com/geeksville/esp8266-oled-ssd1306.git ; ESP8266_SSD1306 
+  https://github.com/meshtastic/RadioHead.git
+  https://github.com/meshtastic/esp8266-oled-ssd1306.git ; ESP8266_SSD1306 
   AXP202X_Library
   SPI
-  OneButton
-  CRC32 ; explicitly needed because dependency is missing in the ble ota update lib
+  ; 1260 ; OneButton - not used yet
+  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/geeksville/arduino-fsm.git 
+  https://github.com/meshtastic/SparkFun_Ublox_Arduino_Library.git
 
 ;[env:tbeam] 
 ;board = ttgo-t-beam

release/latest/curfirmwareversion.xml

@@ -5,5 +5,5 @@ release.  It is used by the android app for forcing software updates.  Do not ed
 Generated by bin/buildall.sh -->
 
 <resources>
-    <string name="cur_firmware_version">0.0.5</string>
+    <string name="cur_firmware_version">0.1.6</string>
 </resources>

src/CustomRF95.cpp

@@ -21,6 +21,7 @@ CustomRF95::CustomRF95(MemoryPool<MeshPacket> &_pool, PointerQueue<MeshPacket> &
 bool CustomRF95::canSleep()
 {
     // We allow initializing mode, because sometimes while testing we don't ever call init() to turn on the hardware
+    DEBUG_MSG("canSleep, mode=%d, isRx=%d, txEmpty=%d, txGood=%d\n", _mode, _isReceiving, txQueue.isEmpty(), _txGood);
     return (_mode == RHModeInitialising || _mode == RHModeIdle || _mode == RHModeRx) && !_isReceiving && txQueue.isEmpty(); 
 }
 

src/GPS.cpp

@@ -4,16 +4,18 @@
 #include <sys/time.h>
 #include "configuration.h"
 
-// stuff that really should be in in the instance instead...
 HardwareSerial _serial_gps(GPS_SERIAL_NUM);
-uint32_t timeStartMsec;  // Once we have a GPS lock, this is where we hold the initial msec clock that corresponds to that time
-uint64_t zeroOffsetSecs; // GPS based time in secs since 1970 - only updated once on initial lock
 
 RTC_DATA_ATTR bool timeSetFromGPS; // We only reset our time once per _boot_ after that point just run from the internal clock (even across sleeps)
 
 GPS gps;
-bool hasValidLocation; // default to false, until we complete our first read
-bool wantNewLocation = true;
+
+// 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 hasValidLocation; // default to false, until we complete our first read
+static bool wantNewLocation = true;
 
 GPS::GPS() : PeriodicTask()
 {
@@ -21,10 +23,64 @@ GPS::GPS() : PeriodicTask()
 
 void GPS::setup()
 {
-    readFromRTC();
+    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
 }
 
@@ -75,20 +131,13 @@ uint32_t GPS::getValidTime()
 /// 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 !wantNewLocation;
+    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()
 {
-    // discard all rx serial bytes so we don't try to parse them when we come back
-    while (_serial_gps.available())
-    {
-        _serial_gps.read();
-    }
-
-    // make the parser bail on whatever it was parsing
-    encode('\n');
+    ublox.powerOff();
 }
 
 void GPS::doTask()
@@ -96,49 +145,68 @@ void GPS::doTask()
 #ifdef GPS_RX_PIN
     // Consume all characters that have arrived
 
-    while (_serial_gps.available())
-    {
-        encode(_serial_gps.read());
-        // DEBUG_MSG("Got GPS response\n");
-    }
+    // getPVT automatically calls checkUblox
+    ublox.checkUblox(); //See if new data is available. Process bytes as they come in.
 
-    if (!timeSetFromGPS && time.isValid() && date.isValid())
+    // DEBUG_MSG("sec %d\n", ublox.getSecond());
+    // DEBUG_MSG("lat %d\n", ublox.getLatitude());
+
+    // If we don't have a fix (a quick check), don't try waiting for a solution)
+    uint8_t fixtype = ublox.getFixType();
+    DEBUG_MSG("fix type %d\n", fixtype);
+
+    // any fix that has time
+    if ((fixtype >= 2 && fixtype <= 5) && !timeSetFromGPS && ublox.getT())
     {
         struct timeval tv;
 
-        DEBUG_MSG("Got time from GPS\n");
+        isConnected = true; // We just received a packet, so we must have a GPS
 
         /* 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 = time.second();
-        t.tm_min = time.minute();
-        t.tm_hour = time.hour();
-        t.tm_mday = date.day();
-        t.tm_mon = date.month() - 1;
-        t.tm_year = date.year() - 1900;
+        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);
+
         perhapsSetRTC(&tv);
     }
-#endif
 
-    if (location.isValid() && location.isUpdated())
-    { // we only notify if position has changed
-        // DEBUG_MSG("new gps pos\n");
-        hasValidLocation = true;
+    if ((fixtype >= 3 && fixtype <= 4) && ublox.getP()) // rd fixes only
+    {
+        // we only notify if position has changed
+        isConnected = true; // We just received a packet, so we must have a GPS
+
+        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();
+            //ublox.powerOff();
+        }
     }
     else // we didn't get a location update, go back to sleep and hope the characters show up
         wantNewLocation = true;
 
-    // Once we have sent a location once we only poll the GPS rarely, otherwise check back every 100ms until we have something over the serial
-    setPeriod(hasValidLocation && !wantNewLocation ? 30 * 1000 : 100);
+#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()
@@ -147,11 +215,3 @@ void GPS::startLock()
     wantNewLocation = true;
     setPeriod(1);
 }
-
-String GPS::getTimeStr()
-{
-    static char t[12]; // used to sprintf for Serial output
-
-    snprintf(t, sizeof(t), "%02d:%02d:%02d", time.hour(), time.minute(), time.second());
-    return t;
-}

src/GPS.h

@@ -1,18 +1,24 @@
 #pragma once
 
-#include <TinyGPS++.h>
 #include "PeriodicTask.h"
 #include "Observer.h"
 #include "sys/time.h"
+#include "SparkFun_Ublox_Arduino_Library.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, public TinyGPSPlus
+class GPS : public PeriodicTask, public Observable
 {
+    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
@@ -21,8 +27,6 @@ public:
     /// Return time since 1970 in secs.  If we don't have a GPS lock return zero
     uint32_t getValidTime();
 
-    String getTimeStr();
-
     void setup();
 
     virtual void loop();
@@ -46,3 +50,4 @@ private:
 };
 
 extern GPS gps;
+

src/MeshBluetoothService.cpp

@@ -190,16 +190,16 @@ public:
         {
             static FromRadio fRadio;
 
-            // Encapsulate as a ToRadio packet
+            // Encapsulate as a FromRadio packet
             memset(&fRadio, 0, sizeof(fRadio));
             fRadio.which_variant = FromRadio_packet_tag;
             fRadio.variant.packet = *mp;
 
-            service.releaseToPool(mp); // we just copied the bytes, so don't need this buffer anymore
-
             size_t numbytes = pb_encode_to_bytes(trBytes, sizeof(trBytes), FromRadio_fields, &fRadio);
             DEBUG_MSG("delivering toPhone packet to phone %d bytes\n", numbytes);
             c->setValue(trBytes, numbytes);
+
+            service.releaseToPool(mp); // we just copied the bytes, so don't need this buffer anymore
         }
     }
 };
@@ -238,60 +238,7 @@ void bluetoothNotifyFromNum(uint32_t newValue)
 BLEService *meshService;
 
 /*
-MeshBluetoothService UUID 6ba1b218-15a8-461f-9fa8-5dcae273eafd
-
-FIXME - notify vs indication for fromradio output.  Using notify for now, not sure if that is best
-FIXME - in the esp32 mesh managment code, occasionally mirror the current net db to flash, so that if we reboot we still have a good guess of users who are out there.
-FIXME - make sure this protocol is guaranteed robust and won't drop packets
-
-"According to the BLE specification the notification length can be max ATT_MTU - 3. The 3 bytes subtracted is the 3-byte header(OP-code (operation, 1 byte) and the attribute handle (2 bytes)).
-In BLE 4.1 the ATT_MTU is 23 bytes (20 bytes for payload), but in BLE 4.2 the ATT_MTU can be negotiated up to 247 bytes."
-
-MAXPACKET is 256? look into what the lora lib uses. FIXME
-
-Characteristics:
-UUID                                 
-properties          
-description
-
-8ba2bcc2-ee02-4a55-a531-c525c5e454d5                                 
-read                
-fromradio - contains a newly received 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 charstic 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.
-
-meshMyNodeCharacteristic("ea9f3f82-8dc4-4733-9452-1f6da28892a2", BLECharacteristic::PROPERTY_READ)
-mynode - read this to access a MyNodeInfo protobuf
-
-meshNodeInfoCharacteristic("d31e02e0-c8ab-4d3f-9cc9-0b8466bdabe8", BLECharacteristic::PROPERTY_WRITE | BLECharacteristic::PROPERTY_READ),
-nodeinfo - read this to get a series of node infos (ending with a null empty record), write to this to restart the read statemachine that returns all the node infos
-
-meshRadioCharacteristic("b56786c8-839a-44a1-b98e-a1724c4a0262", BLECharacteristic::PROPERTY_WRITE | BLECharacteristic::PROPERTY_READ),
-radio - read/write this to access a RadioConfig protobuf
-
-meshOwnerCharacteristic("6ff1d8b6-e2de-41e3-8c0b-8fa384f64eb6", BLECharacteristic::PROPERTY_WRITE | BLECharacteristic::PROPERTY_READ)
-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)
-
+See bluetooth-api.md for documentation.
  */
 BLEService *createMeshBluetoothService(BLEServer *server)
 {
@@ -329,6 +276,14 @@ BLEService *createMeshBluetoothService(BLEServer *server)
     return service;
 }
 
+void stopMeshBluetoothService()
+{
+    assert(meshService);
+    meshService->stop();
+}
+
+
+
 void destroyMeshBluetoothService()
 {
     assert(meshService);
@@ -336,15 +291,3 @@ void destroyMeshBluetoothService()
 
     meshFromNumCharacteristic = NULL;
 }
-
-/**
- * Super skanky FIXME - when we start a software update we force the mesh service to shutdown.
- * If the sw update fails, the user will have to manually reset the board to get things running again.
- */
-void stopMeshBluetoothService()
-{
-    if (meshService)
-        meshService->stop();
-
-    meshFromNumCharacteristic = NULL; // don't try to notify anymore
-}

src/MeshBluetoothService.h

@@ -12,8 +12,4 @@ void destroyMeshBluetoothService();
  */
 void bluetoothNotifyFromNum(uint32_t newValue);
 
-/**
- * Super skanky FIXME - when we start a software update we force the mesh service to shutdown.
- * If the sw update fails, the user will have to manually reset the board to get things running again.
- */
 void stopMeshBluetoothService();

src/MeshRadio.h

@@ -13,17 +13,22 @@
 #define CH_SPACING_US   2.16f // MHz
 #define NUM_CHANNELS_US 13
 
-// EU channel settings
-#define CH0_EU          865.2f // MHz
-#define CH_SPACING_EU   0.3f // MHz
-#define NUM_CHANNELS_EU 10
+// 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
 
-// CN channel settings
+// 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
@@ -33,10 +38,14 @@
 #define CH0 CH0_US
 #define CH_SPACING CH_SPACING_US
 #define NUM_CHANNELS NUM_CHANNELS_US
-#elif defined(HW_VERSION_EU)
-#define CH0 CH0_EU
-#define CH_SPACING CH_SPACING_EU
-#define NUM_CHANNELS NUM_CHANNELS_EU
+#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

src/MeshService.cpp

@@ -9,6 +9,7 @@
 #include "GPS.h"
 #include "screen.h"
 #include "Periodic.h"
+#include "PowerFSM.h"
 
 /*
 receivedPacketQueue - this is a queue of messages we've received from the mesh, which we are keeping to deliver to the phone.
@@ -144,10 +145,12 @@ void MeshService::handleIncomingPosition(MeshPacket *mp)
 
 void MeshService::handleFromRadio(MeshPacket *mp)
 {
+    powerFSM.trigger(EVENT_RECEIVED_PACKET); // Possibly keep the node from sleeping
+
     mp->rx_time = gps.getValidTime(); // store the arrival timestamp for the phone
 
     // If it is a position packet, perhaps set our clock (if we don't have a GPS of our own, otherwise wait for that to work)
-    if(!myNodeInfo.has_gps)
+    if (!myNodeInfo.has_gps)
         handleIncomingPosition(mp);
 
     if (mp->has_payload && mp->payload.which_variant == SubPacket_user_tag)
@@ -323,11 +326,13 @@ void MeshService::onGPSChanged()
     MeshPacket *p = allocForSending();
     p->payload.which_variant = SubPacket_position_tag;
     Position &pos = p->payload.variant.position;
+#if 0
     if (gps.altitude.isValid())
         pos.altitude = gps.altitude.meters();
     pos.latitude = gps.location.lat();
     pos.longitude = gps.location.lng();
     pos.time = gps.getValidTime();
+#endif
 
     // We limit our GPS broadcasts to a max rate
     static uint32_t lastGpsSend;

src/NodeDB.cpp

@@ -21,6 +21,14 @@ MyNodeInfo &myNodeInfo = devicestate.my_node;
 RadioConfig &radioConfig = devicestate.radio;
 ChannelSettings &channelSettings = radioConfig.channel_settings;
 
+/*
+DeviceState versions used to be defined in the .proto file but really only this function cares.  So changed to a 
+#define here.
+*/
+
+#define DEVICESTATE_CUR_VER 2
+#define DEVICESTATE_MIN_VER DEVICESTATE_CUR_VER
+
 #define FS SPIFFS
 
 /** 
@@ -54,9 +62,9 @@ void NodeDB::init()
     radioConfig.preferences.position_broadcast_secs = 15 * 60;
     radioConfig.preferences.wait_bluetooth_secs = 120;
     radioConfig.preferences.screen_on_secs = 30;
-    radioConfig.preferences.mesh_sds_timeout_secs = 60 * 60;
-    radioConfig.preferences.phone_sds_timeout_sec = 60 * 60;
-    radioConfig.preferences.sds_secs = 60 * 60;
+    radioConfig.preferences.mesh_sds_timeout_secs = 2 * 60 * 60;
+    radioConfig.preferences.phone_sds_timeout_sec = 2 * 60 * 60;
+    radioConfig.preferences.sds_secs = 365 * 24 * 60 * 60; // one year
     radioConfig.preferences.ls_secs = 60 * 60;
     radioConfig.preferences.phone_timeout_secs = 15 * 60;
 
@@ -64,6 +72,9 @@ void NodeDB::init()
     // some hardware defaults to have a built in GPS
     myNodeInfo.has_gps = true;
 #endif
+    strncpy(myNodeInfo.region, xstr(HW_VERSION), sizeof(myNodeInfo.region));
+    strncpy(myNodeInfo.firmware_version, xstr(APP_VERSION), sizeof(myNodeInfo.firmware_version));
+    strncpy(myNodeInfo.hw_model, HW_VENDOR, sizeof(myNodeInfo.hw_model));
 
     // Init our blank owner info to reasonable defaults
     esp_efuse_mac_get_default(ourMacAddr);
@@ -144,7 +155,7 @@ void NodeDB::loadFromDisk()
         }
         else
         {
-            if (scratch.version < DeviceState_Version_Minimum)
+            if (scratch.version < DEVICESTATE_MIN_VER)
                 DEBUG_MSG("Warn: devicestate is old, discarding\n");
             else
             {
@@ -173,7 +184,7 @@ void NodeDB::saveToDisk()
 
         //DEBUG_MSG("Presave channel name=%s\n", channelSettings.name);
 
-        devicestate.version = DeviceState_Version_Current;
+        devicestate.version = DEVICESTATE_CUR_VER;
         if (!pb_encode(&stream, DeviceState_fields, &devicestate))
         {
             DEBUG_MSG("Error: can't write protobuf %s\n", PB_GET_ERROR(&stream));

src/PowerFSM.cpp

@@ -25,21 +25,29 @@ static void sdsEnter()
 
 static void lsEnter()
 {
+    DEBUG_MSG("lsEnter begin\n");
+    screen.setOn(false);
+
     while (!service.radio.rf95.canSleep())
         delay(10); // Kinda yucky - wait until radio says say we can shutdown (finished in process sends/receives)
 
     gps.prepareSleep(); // abandon in-process parsing
 
-    if(!isUSBPowered) // FIXME - temp hack until we can put gps in sleep mode, if we have AC when we go to sleep then leave GPS on
-    setGPSPower(false); // kill GPS power
+    //if (!isUSBPowered)      // FIXME - temp hack until we can put gps in sleep mode, if we have AC when we go to sleep then leave GPS on
+    //    setGPSPower(false); // kill GPS power
+
+    DEBUG_MSG("lsEnter end\n");
 }
 
 static void lsIdle()
 {
+    DEBUG_MSG("lsIdle begin ls_secs=%u\n", radioConfig.preferences.ls_secs);
+
     uint32_t secsSlept = 0;
     esp_sleep_source_t wakeCause = ESP_SLEEP_WAKEUP_UNDEFINED;
+    bool reached_ls_secs = false;
 
-    while (secsSlept < radioConfig.preferences.ls_secs)
+    while (!reached_ls_secs)
     {
         // Briefly come out of sleep long enough to blink the led once every few seconds
         uint32_t sleepTime = 5;
@@ -55,21 +63,33 @@ static void lsIdle()
             break;
 
         secsSlept += sleepTime;
+        reached_ls_secs = secsSlept >= radioConfig.preferences.ls_secs;
     }
     setLed(false);
 
-    // Regardless of why we woke (for now) just transition to NB (and that state will handle stuff like IRQs etc)
+    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);
+
+        // Regardless of why we woke just transition to NB (and that state will handle stuff like IRQs etc)
         powerFSM.trigger(EVENT_WAKE_TIMER);
+    }
 }
 
 static void lsExit()
 {
-    setGPSPower(true); // restore GPS power
+    // setGPSPower(true); // restore GPS power
     gps.startLock();
 }
 
 static void nbEnter()
 {
+    screen.setOn(false);
     setBluetoothEnable(false);
 
     // FIXME - check if we already have packets for phone and immediately trigger EVENT_PACKETS_FOR_PHONE
@@ -86,10 +106,7 @@ static void onEnter()
     setBluetoothEnable(true);
 }
 
-static void onExit()
-{
-    screen.setOn(false);
-}
+
 static void wakeForPing()
 {
 }
@@ -103,7 +120,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 stateON(onEnter, NULL, onExit, "ON");
+State stateON(onEnter, NULL, NULL, "ON");
 Fsm powerFSM(&stateDARK);
 
 void PowerFSM_setup()
@@ -147,5 +164,9 @@ void PowerFSM_setup()
 
     powerFSM.add_timed_transition(&stateDARK, &stateLS, radioConfig.preferences.wait_bluetooth_secs * 1000, NULL, "Bluetooth timeout");
 
+    powerFSM.add_timed_transition(&stateLS, &stateSDS, radioConfig.preferences.mesh_sds_timeout_secs * 1000, NULL, "mesh timeout");
+    // removing for now, because some users don't even have phones
+    // powerFSM.add_timed_transition(&stateLS, &stateSDS, radioConfig.preferences.phone_sds_timeout_sec * 1000, NULL, "phone timeout");
+
     powerFSM.run_machine(); // run one interation of the state machine, so we run our on enter tasks for the initial DARK state
 }

src/PowerFSM.h

@@ -1,6 +1,6 @@
 #pragma once 
 
-#include "Fsm.h"
+#include <Fsm.h>
 
 // See sw-design.md for documentation
 

src/configuration.h

@@ -32,18 +32,17 @@ along with this program.  If not, see <http://www.gnu.org/licenses/>.
 // If app version is not specified we assume we are not being invoked by the build script
 #ifndef APP_VERSION
 #define APP_VERSION 0.0.0   // this def normally comes from build-all.sh
-#define HW_VERSION              1.0-US // normally comes from build-all.sh and contains the region code
+#define HW_VERSION 1.0 - US // normally comes from build-all.sh and contains the region code
 #endif
 
-
 // -----------------------------------------------------------------------------
 // Configuration
 // -----------------------------------------------------------------------------
 
 // Select which board is being used. If the outside build environment has sent a choice, just use that
 #if !defined(T_BEAM_V10) && !defined(HELTEC_LORA32)
-// #define T_BEAM_V10  // AKA Rev1 (second board released)
-#define HELTEC_LORA32
+#define T_BEAM_V10  // AKA Rev1 (second board released)
+// #define HELTEC_LORA32
 
 #define HW_VERSION_US // We encode the hardware freq range in the hw version string, so sw update can eventually install the correct build
 #endif
@@ -59,13 +58,15 @@ along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
 #define REQUIRE_RADIO true // If true, we will fail to start if the radio is not found
 
+#define xstr(s) str(s)
+#define str(s) #s
 
 // -----------------------------------------------------------------------------
 // DEBUG
 // -----------------------------------------------------------------------------
 
 #ifdef DEBUG_PORT
-#define DEBUG_MSG(...) DEBUG_PORT.printf( __VA_ARGS__ )
+#define DEBUG_MSG(...) DEBUG_PORT.printf(__VA_ARGS__)
 #else
 #define DEBUG_MSG(...)
 #endif
@@ -107,6 +108,8 @@ along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
 #define BICOLOR_DISPLAY // we have yellow at the top 16 lines
 
+// #define BUTTON_NEED_PULLUP // if set we need to turn on the internal CPU pullup during sleep
+
 #define I2C_SDA 21
 #define I2C_SCL 22
 
@@ -145,7 +148,6 @@ along with this program.  If not, see <http://www.gnu.org/licenses/>.
 #define DIO2_GPIO 34
 #endif
 
-
 // -----------------------------------------------------------------------------
 // AXP192 (Rev1-specific options)
 // -----------------------------------------------------------------------------
@@ -153,4 +155,3 @@ along with this program.  If not, see <http://www.gnu.org/licenses/>.
 // #define AXP192_SLAVE_ADDRESS  0x34 // Now defined in axp20x.h
 #define GPS_POWER_CTRL_CH 3
 #define LORA_POWER_CTRL_CH 2
-

src/main.cpp

@@ -54,9 +54,6 @@ bool axp192_found;
 
 bool bluetoothOn;
 
-#define xstr(s) str(s)
-#define str(s) #s
-
 // -----------------------------------------------------------------------------
 // Application
 // -----------------------------------------------------------------------------
@@ -201,8 +198,6 @@ const char *getDeviceName()
   return name;
 }
 
-
-
 void setup()
 {
 // Debug
@@ -293,6 +288,7 @@ void setBluetoothEnable(bool on)
     else
     {
       // We have to totally teardown our bluetooth objects to prevent leaks
+      stopMeshBluetoothService(); // Must do before shutting down bluetooth
       deinitBLE();
       destroyMeshBluetoothService(); // must do after deinit, because it frees our service
       Serial.printf("Shutdown BT: %u heap size\n", ESP.getFreeHeap());
@@ -345,6 +341,9 @@ void loop()
   // axpDebugOutput.loop();
   loopBLE();
 
+  // for debug printing
+  // service.radio.rf95.canSleep();
+
 #ifdef T_BEAM_V10
   if (axp192_found)
   {

src/mesh.pb.c

@@ -49,7 +49,6 @@ PB_BIND(ToRadio, ToRadio, 2)
 
 
 
-
 #ifndef PB_CONVERT_DOUBLE_FLOAT
 /* On some platforms (such as AVR), double is really float.
  * To be able to encode/decode double on these platforms, you need.

src/mesh.pb.h

@@ -31,12 +31,6 @@ typedef enum _ChannelSettings_ModemConfig {
     ChannelSettings_ModemConfig_Bw125Cr48Sf4096 = 3
 } ChannelSettings_ModemConfig;
 
-typedef enum _DeviceState_Version {
-    DeviceState_Version_Unset = 0,
-    DeviceState_Version_Minimum = 17,
-    DeviceState_Version_Current = 17
-} DeviceState_Version;
-
 /* Struct definitions */
 typedef struct _ChannelSettings {
     int32_t tx_power;
@@ -56,6 +50,9 @@ typedef struct _MyNodeInfo {
     int32_t my_node_num;
     bool has_gps;
     int32_t num_channels;
+    char region[12];
+    char hw_model[12];
+    char firmware_version[12];
 } MyNodeInfo;
 
 typedef struct _Position {
@@ -135,9 +132,9 @@ typedef struct _DeviceState {
     NodeInfo node_db[32];
     pb_size_t receive_queue_count;
     MeshPacket receive_queue[32];
-    DeviceState_Version version;
     bool has_rx_text_message;
     MeshPacket rx_text_message;
+    uint32_t version;
 } DeviceState;
 
 typedef struct _FromRadio {
@@ -169,10 +166,6 @@ typedef struct _ToRadio {
 #define _ChannelSettings_ModemConfig_MAX ChannelSettings_ModemConfig_Bw125Cr48Sf4096
 #define _ChannelSettings_ModemConfig_ARRAYSIZE ((ChannelSettings_ModemConfig)(ChannelSettings_ModemConfig_Bw125Cr48Sf4096+1))
 
-#define _DeviceState_Version_MIN DeviceState_Version_Unset
-#define _DeviceState_Version_MAX DeviceState_Version_Current
-#define _DeviceState_Version_ARRAYSIZE ((DeviceState_Version)(DeviceState_Version_Current+1))
-
 
 /* Initializer values for message structs */
 #define Position_init_default                    {0, 0, 0, 0, 0}
@@ -184,8 +177,8 @@ typedef struct _ToRadio {
 #define RadioConfig_init_default                 {false, RadioConfig_UserPreferences_init_default, false, ChannelSettings_init_default}
 #define RadioConfig_UserPreferences_init_default {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
 #define NodeInfo_init_default                    {0, false, User_init_default, false, Position_init_default, 0, 0}
-#define MyNodeInfo_init_default                  {0, 0, 0}
-#define DeviceState_init_default                 {false, RadioConfig_init_default, false, MyNodeInfo_init_default, false, User_init_default, 0, {NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default}, 0, {MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default}, _DeviceState_Version_MIN, false, MeshPacket_init_default}
+#define MyNodeInfo_init_default                  {0, 0, 0, "", "", ""}
+#define DeviceState_init_default                 {false, RadioConfig_init_default, false, MyNodeInfo_init_default, false, User_init_default, 0, {NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default, NodeInfo_init_default}, 0, {MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default, MeshPacket_init_default}, false, MeshPacket_init_default, 0}
 #define FromRadio_init_default                   {0, 0, {MeshPacket_init_default}}
 #define ToRadio_init_default                     {0, {MeshPacket_init_default}}
 #define Position_init_zero                       {0, 0, 0, 0, 0}
@@ -197,8 +190,8 @@ typedef struct _ToRadio {
 #define RadioConfig_init_zero                    {false, RadioConfig_UserPreferences_init_zero, false, ChannelSettings_init_zero}
 #define RadioConfig_UserPreferences_init_zero    {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
 #define NodeInfo_init_zero                       {0, false, User_init_zero, false, Position_init_zero, 0, 0}
-#define MyNodeInfo_init_zero                     {0, 0, 0}
-#define DeviceState_init_zero                    {false, RadioConfig_init_zero, false, MyNodeInfo_init_zero, false, User_init_zero, 0, {NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero}, 0, {MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero}, _DeviceState_Version_MIN, false, MeshPacket_init_zero}
+#define MyNodeInfo_init_zero                     {0, 0, 0, "", "", ""}
+#define DeviceState_init_zero                    {false, RadioConfig_init_zero, false, MyNodeInfo_init_zero, false, User_init_zero, 0, {NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero, NodeInfo_init_zero}, 0, {MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero, MeshPacket_init_zero}, false, MeshPacket_init_zero, 0}
 #define FromRadio_init_zero                      {0, 0, {MeshPacket_init_zero}}
 #define ToRadio_init_zero                        {0, {MeshPacket_init_zero}}
 
@@ -213,6 +206,9 @@ typedef struct _ToRadio {
 #define MyNodeInfo_my_node_num_tag               1
 #define MyNodeInfo_has_gps_tag                   2
 #define MyNodeInfo_num_channels_tag              3
+#define MyNodeInfo_region_tag                    4
+#define MyNodeInfo_hw_model_tag                  5
+#define MyNodeInfo_firmware_version_tag          6
 #define Position_latitude_tag                    1
 #define Position_longitude_tag                   2
 #define Position_altitude_tag                    3
@@ -255,7 +251,7 @@ typedef struct _ToRadio {
 #define DeviceState_owner_tag                    3
 #define DeviceState_node_db_tag                  4
 #define DeviceState_receive_queue_tag            5
-#define DeviceState_version_tag                  6
+#define DeviceState_version_tag                  8
 #define DeviceState_rx_text_message_tag          7
 #define FromRadio_packet_tag                     2
 #define FromRadio_num_tag                        1
@@ -353,7 +349,10 @@ X(a, STATIC,   SINGULAR, INT32,    frequency_error,   6)
 #define MyNodeInfo_FIELDLIST(X, a) \
 X(a, STATIC,   SINGULAR, INT32,    my_node_num,       1) \
 X(a, STATIC,   SINGULAR, BOOL,     has_gps,           2) \
-X(a, STATIC,   SINGULAR, INT32,    num_channels,      3)
+X(a, STATIC,   SINGULAR, INT32,    num_channels,      3) \
+X(a, STATIC,   SINGULAR, STRING,   region,            4) \
+X(a, STATIC,   SINGULAR, STRING,   hw_model,          5) \
+X(a, STATIC,   SINGULAR, STRING,   firmware_version,   6)
 #define MyNodeInfo_CALLBACK NULL
 #define MyNodeInfo_DEFAULT NULL
 
@@ -363,8 +362,8 @@ X(a, STATIC,   OPTIONAL, MESSAGE,  my_node,           2) \
 X(a, STATIC,   OPTIONAL, MESSAGE,  owner,             3) \
 X(a, STATIC,   REPEATED, MESSAGE,  node_db,           4) \
 X(a, STATIC,   REPEATED, MESSAGE,  receive_queue,     5) \
-X(a, STATIC,   SINGULAR, UENUM,    version,           6) \
-X(a, STATIC,   OPTIONAL, MESSAGE,  rx_text_message,   7)
+X(a, STATIC,   OPTIONAL, MESSAGE,  rx_text_message,   7) \
+X(a, STATIC,   SINGULAR, UINT32,   version,           8)
 #define DeviceState_CALLBACK NULL
 #define DeviceState_DEFAULT NULL
 #define DeviceState_radio_MSGTYPE RadioConfig
@@ -426,8 +425,8 @@ extern const pb_msgdesc_t ToRadio_msg;
 #define RadioConfig_size                         126
 #define RadioConfig_UserPreferences_size         72
 #define NodeInfo_size                            155
-#define MyNodeInfo_size                          24
-#define DeviceState_size                         15021
+#define MyNodeInfo_size                          63
+#define DeviceState_size                         15064
 #define FromRadio_size                           301
 #define ToRadio_size                             295
 

src/screen.cpp

@@ -140,6 +140,7 @@ void drawTextMessageFrame(OLEDDisplay *display, OLEDDisplayUiState *state, int16
 {
     MeshPacket &mp = devicestate.rx_text_message;
     NodeInfo *node = nodeDB.getNode(mp.from);
+    // DEBUG_MSG("drawing text message from 0x%x: %s\n", mp.from, mp.payload.variant.data.payload.bytes);
 
     // Demo for drawStringMaxWidth:
     // with the third parameter you can define the width after which words will be wrapped.
@@ -445,11 +446,17 @@ void drawDebugInfo(OLEDDisplay *display, OLEDDisplayUiState *state, int16_t x, i
 
     // We don't show battery levels yet - for now just lie and show debug info
     static char batStr[20];
-    snprintf(batStr, sizeof(channelStr), "Batt %x%%", (isCharging << 1) + isUSBPowered);
+    snprintf(batStr, sizeof(batStr), "Batt %x%%", (isCharging << 1) + isUSBPowered);
+
+    static char gpsStr[20];
+    if (myNodeInfo.has_gps)
+        snprintf(gpsStr, sizeof(gpsStr), "GPS %d%%", 75); // FIXME, use something based on hdop
+    else
+        gpsStr[0] = '\0'; // Just show emptystring
 
     const char *fields[] = {
         batStr,
-        "GPS 75%",
+        gpsStr,
         usersStr,
         channelStr,
         NULL};
@@ -500,17 +507,21 @@ void Screen::setOn(bool on)
 
     if (on != screenOn)
     {
-        if (on) {
+        if (on)
+        {
+            DEBUG_MSG("Turning on screen\n");
             dispdev.displayOn();
             setPeriod(1); // redraw ASAP
         }
-        else
+        else {
+            DEBUG_MSG("Turning off screen\n");
             dispdev.displayOff();
+        }
         screenOn = on;
     }
 }
 
-static void screen_print(const char *text, uint8_t x, uint8_t y, uint8_t alignment)
+void screen_print(const char *text, uint8_t x, uint8_t y, uint8_t alignment)
 {
     DEBUG_MSG(text);
 
@@ -613,7 +624,6 @@ void Screen::doTask()
         targetFramerate = IDLE_FRAMERATE;
         ui.setTargetFPS(targetFramerate);
     }
-    ui.update();
 
     // While showing the bluetooth pair screen all of our standard screen switching is stopped
     if (!showingBluetooth)
@@ -624,7 +634,7 @@ void Screen::doTask()
             if (millis() > 3 * 1000) // we show the boot screen for a few seconds only
             {
                 showingBootScreen = false;
-                screen_set_frames();
+                setFrames();
             }
         }
         else // standard screen loop handling ehre
@@ -632,13 +642,16 @@ void Screen::doTask()
             // If the # nodes changes, we need to regen our list of screens
             if (nodeDB.updateGUI || nodeDB.updateTextMessage)
             {
-                screen_set_frames();
+                setFrames();
                 nodeDB.updateGUI = false;
                 nodeDB.updateTextMessage = false;
             }
         }
     }
 
+    // This must be after we possibly do screen_set_frames() to ensure we draw the new data
+    ui.update();
+
     // DEBUG_MSG("want fps %d, fixed=%d\n", targetFramerate, ui.getUiState()->frameState);
     // If we are scrolling we need to be called soon, otherwise just 1 fps (to save CPU)
     // We also ask to be called twice as fast as we really need so that any rounding errors still result
@@ -665,7 +678,7 @@ void screen_start_bluetooth(uint32_t pin)
 }
 
 // restore our regular frame list
-void screen_set_frames()
+void Screen::setFrames()
 {
     DEBUG_MSG("showing standard frames\n");
 

src/screen.h

@@ -3,6 +3,7 @@
 #include "PeriodicTask.h"
 
 void screen_print(const char * text);
+void screen_print(const char * text, uint8_t x, uint8_t y, uint8_t alignment);
 
 
 // Show the bluetooth PIN screen
@@ -34,6 +35,10 @@ public:
 
     /// Handle a button press
     void onPress();
+
+    /// Rebuilt our list of screens
+    void setFrames();
+private:
 };
 
 extern Screen screen;

src/sleep.cpp

@@ -28,8 +28,6 @@ esp_sleep_source_t wakeCause; // the reason we booted this time
 #define xstr(s) str(s)
 #define str(s) #s
 
-
-
 // -----------------------------------------------------------------------------
 // Application
 // -----------------------------------------------------------------------------
@@ -84,9 +82,24 @@ void initDeepSleep()
         wakeButtons = ((uint64_t)1) << buttons.gpios[0];
     */
 
-  DEBUG_MSG("booted, wake cause %d (boot count %d)\n", wakeCause, bootCount);
-}
+  // If we booted because our timer ran out or the user pressed reset, send those as fake events
+  const char *reason = "reset"; // our best guess
+  RESET_REASON hwReason = rtc_get_reset_reason(0);
 
+  if (hwReason == RTCWDT_BROWN_OUT_RESET)
+    reason = "brownout";
+
+  if (hwReason == TG0WDT_SYS_RESET)
+    reason = "taskWatchdog";
+
+  if (hwReason == TG1WDT_SYS_RESET)
+    reason = "intWatchdog";
+
+  if (wakeCause == ESP_SLEEP_WAKEUP_TIMER)
+    reason = "timeout";
+
+  DEBUG_MSG("booted, wake cause %d (boot count %d), reset_reason=%s\n", wakeCause, bootCount, reason);
+}
 
 void doDeepSleep(uint64_t msecToWake)
 {
@@ -164,6 +177,10 @@ void doDeepSleep(uint64_t msecToWake)
   // Only GPIOs which are have RTC functionality can be used in this bit map: 0,2,4,12-15,25-27,32-39.
   uint64_t gpioMask = (1ULL << BUTTON_PIN);
 
+#ifdef BUTTON_NEED_PULLUP
+  gpio_pullup_en((gpio_num_t) BUTTON_PIN);
+#endif
+
   // Not needed because both of the current boards have external pullups
   // FIXME change polarity in hw so we can wake on ANY_HIGH instead - that would allow us to use all three buttons (instead of just the first)
   // gpio_pullup_en((gpio_num_t)BUTTON_PIN);
@@ -175,9 +192,6 @@ void doDeepSleep(uint64_t msecToWake)
   esp_deep_sleep_start();                              // TBD mA sleep current (battery)
 }
 
-
-
-
 /**
  * enter light sleep (preserves ram but stops everything about CPU).
  * 
@@ -196,15 +210,20 @@ esp_sleep_wakeup_cause_t doLightSleep(uint64_t sleepMsec) // FIXME, use a more r
   // We want RTC peripherals to stay on
   esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_PERIPH, ESP_PD_OPTION_ON);
 
+#ifdef BUTTON_NEED_PULLUP
+  gpio_pullup_en((gpio_num_t) BUTTON_PIN);
+#endif
+
   gpio_wakeup_enable((gpio_num_t)BUTTON_PIN, GPIO_INTR_LOW_LEVEL); // when user presses, this button goes low
   gpio_wakeup_enable((gpio_num_t)DIO0_GPIO, GPIO_INTR_HIGH_LEVEL); // RF95 interrupt, active high
 #ifdef PMU_IRQ
-  gpio_wakeup_enable((gpio_num_t)PMU_IRQ, GPIO_INTR_HIGH_LEVEL); // pmu irq
+  // FIXME, disable wake due to PMU because it seems to fire all the time?
+  // gpio_wakeup_enable((gpio_num_t)PMU_IRQ, GPIO_INTR_HIGH_LEVEL); // pmu irq
 #endif
   assert(esp_sleep_enable_gpio_wakeup() == ESP_OK);
   assert(esp_sleep_enable_timer_wakeup(sleepUsec) == ESP_OK);
   assert(esp_light_sleep_start() == ESP_OK);
-  //DEBUG_MSG("Exit light sleep\n");
+  //DEBUG_MSG("Exit light sleep b=%d, rf95=%d, pmu=%d\n", digitalRead(BUTTON_PIN), digitalRead(DIO0_GPIO), digitalRead(PMU_IRQ));
   return esp_sleep_get_wakeup_cause();
 }