use RTC time for my timestamp (works across deep sleep)

TODO.md

@@ -15,6 +15,7 @@ Items to complete before the first alpha release.
 # Medium priority
 Items to complete before the first beta release.
 
+* for non GPS equipped devices, set time from phone
 * GUI on oled hangs for a few seconds occasionally, but comes back
 * 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
@@ -52,6 +53,27 @@ General ideas to hit the power draws our spreadsheet predicts.  Do the easy ones
 * 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.
+
+## 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
+
 # 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 ;-) )
 
@@ -149,4 +171,5 @@ Items after the first final candidate release.
 * have node info screen show real info (including distance and heading)
 * blink the power led less often
 * have radiohead ISR send messages to RX queue directly, to allow that thread to block until we have something to send
-* move lora rx/tx to own thread and block on IO
+* move lora rx/tx to own thread and block on IO
+* keep our pseudo time moving forward even if we enter deep sleep (use esp32 rtc)

docs/privacy.md

@@ -2,8 +2,8 @@
 
 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 anonomized information about user behavior.  i.e. where you went in the app etc...  We never
-capture usernames, the contents of your texts.
+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.
 

src/GPS.cpp

@@ -1,10 +1,13 @@
 
 #include "GPS.h"
+#include "time.h"
+#include <sys/time.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 zeroOffset;    // GPS based time in millis since 1970 - only updated once on initial lock
+bool timeSetFromGPS; // We only reset our time once per wake
 
 GPS gps;
 
@@ -14,6 +17,17 @@ GPS::GPS() : PeriodicTask(30 * 1000)
 
 void GPS::setup()
 {
+    struct timeval tv; /* btw settimeofday() is helpfull here too*/
+
+    if (!gettimeofday(&tv, NULL))
+    {
+        uint32_t now = millis();
+
+        DEBUG_MSG("Read RTC time as %ld (cur millis %u)\n", tv.tv_sec, now);
+        timeStartMsec = now;
+        zeroOffset = tv.tv_sec * 1000LL + tv.tv_usec / 1000LL;
+    }
+
 #ifdef GPS_RX_PIN
     _serial_gps.begin(GPS_BAUDRATE, SERIAL_8N1, GPS_RX_PIN, GPS_TX_PIN);
 #endif
@@ -30,8 +44,9 @@ void GPS::loop()
         encode(_serial_gps.read());
     }
 
-    if (!timeStartMsec && time.isValid() && date.isValid())
+    if (!timeSetFromGPS && time.isValid() && date.isValid())
     {
+        timeSetFromGPS = true;
         timeStartMsec = millis();
 
         // FIXME, this is a shit not right version of the standard def of unix time!!!
@@ -44,8 +59,9 @@ void GPS::loop()
 #endif
 }
 
-uint64_t GPS::getTime() {
-    return ((uint64_t) millis() - timeStartMsec) + zeroOffset;
+uint64_t GPS::getTime()
+{
+    return ((uint64_t)millis() - timeStartMsec) + zeroOffset;
 }
 
 void GPS::doTask()
@@ -57,7 +73,6 @@ void GPS::doTask()
     }
 }
 
-
 String GPS::getTimeStr()
 {
     static char t[12]; // used to sprintf for Serial output

src/MeshService.cpp

@@ -221,7 +221,7 @@ void MeshService::sendToMesh(MeshPacket *p)
 
     // Note: We might return !OK if our fifo was full, at that point the only option we have is to drop it
     if(radio.send(p) != ERRNO_OK)
-        DEBUG_MSG("Dropped packet because send queue was full!");
+        DEBUG_MSG("Dropped packet because send queue was full!\n");
 }
 
 MeshPacket *MeshService::allocForSending()

src/configuration.h

@@ -66,7 +66,7 @@ along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
 // If not defined, we will wait for lock forever
 
-#define MINWAKE_MSECS           (5 * 60 * 1000) // stay awake a long time (30 mins) for debugging
+#define MINWAKE_MSECS           (10 * 60 * 1000) // stay awake a long time (30 mins) for debugging
 // #define MINWAKE_MSECS           (30 * 1000)  // Wait after every boot for GPS lock (may need longer than 5s because we turned the gps off during deep sleep)
 
 // -----------------------------------------------------------------------------

src/main.ino

@@ -33,6 +33,8 @@
 #include "screen.h"
 #include "NodeDB.h"
 #include "Periodic.h"
+#include "esp32/pm.h"
+#include "esp_pm.h"
 
 #ifdef T_BEAM_V10
 #include "axp20x.h"
@@ -147,8 +149,6 @@ void doDeepSleep(uint64_t msecToWake)
   esp_deep_sleep_start();                              // TBD mA sleep current (battery)
 }
 
-#include "esp32/pm.h"
-#include "esp_pm.h"
 
 /**
  * enable modem sleep mode as needed and available.  Should lower our CPU current draw to an average of about 20mA.