lower cpu freq to 80MHz

README.md

@@ -11,7 +11,7 @@ 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 pre-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 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 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.  
 

TODO.md

@@ -1,4 +1,5 @@
 # High priority
+
 Items to complete before the first alpha release.
 
 * retest BLE software update for both board types
@@ -7,8 +8,10 @@ Items to complete before the first alpha release.
 * send note about Adafruit Clue
 * send note to the guy who designed the cases
 * update the prebuilt bins for different regulatory regions
+* remeasure wake time power draws now that we run CPU down at 80MHz
 
 # Medium priority
+
 Items to complete before the first beta release.
 
 * leave lora receiver always on
@@ -84,6 +87,7 @@ all else fails could always use the stock radiohead solution - though super inef
 * 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
@@ -92,9 +96,12 @@ other node.  This would nicely allow distant nodes to propogate their position t
 * 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?
 
 # 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 ;-) )
 
 * make an install script to let novices install software on their boards
@@ -113,6 +120,7 @@ until the phone pulls those packets.  Ever so often power on bluetooth just so w
 * share channel settings over Signal (or qr code) by embedding an an URL which is handled by the MeshUtil app.
 
 # Low priority
+
 Items after the first final candidate release.
 
 * make a no bluetooth configured yet screen - include this screen in the loop if the user hasn't yet paired

docs/README.md

@@ -67,7 +67,7 @@ This project is still pretty young but moving at a pretty good pace.  Not all fe
 Most of these problems should be solved by the beta release:
 
 * 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 on power measurements.
+* 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 

src/main.ino

@@ -60,6 +60,16 @@ esp_sleep_source_t wakeCause; // the reason we booted this time
 // Application
 // -----------------------------------------------------------------------------
 
+/**
+ * Control CPU core speed (80MHz vs 240MHz)
+ * 
+ * We leave CPU at full speed during init, but once loop is called switch to low speed (for a 50% power savings)
+ * 
+ */
+void setCPUFast(bool on) {
+  setCpuFrequencyMhz(on ? 240 : 80);
+}
+
 void doDeepSleep(uint64_t msecToWake)
 {
   DEBUG_MSG("Entering deep sleep for %llu seconds\n", msecToWake / 1000);
@@ -157,6 +167,8 @@ void doDeepSleep(uint64_t msecToWake)
  * enable modem sleep mode as needed and available.  Should lower our CPU current draw to an average of about 20mA.
  * 
  * per https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/power_management.html
+ * 
+ * supposedly according to https://github.com/espressif/arduino-esp32/issues/475 this is already done in arduino
  */
 void enableModemSleep()
 {
@@ -412,7 +424,8 @@ void setup()
     serve->getAdvertising()->start();
   }
 
-  enableModemSleep();
+  // enableModemSleep();
+  setCPUFast(false);
 }
 
 uint32_t ledBlinker()