From af5e3a0e02f53f8c3fd8cd625a8c45742d0182bd Mon Sep 17 00:00:00 2001 From: geeksville Date: Mon, 24 Feb 2020 08:47:02 -0800 Subject: [PATCH] TODO updates - back to Android app for now --- TODO.md | 21 ++++++++++++--------- docs/README.md | 5 +++-- 2 files changed, 15 insertions(+), 11 deletions(-) diff --git a/TODO.md b/TODO.md index b72abe10c..f15230148 100644 --- a/TODO.md +++ b/TODO.md @@ -1,19 +1,22 @@ # High priority -Items to complete before the first alpha release. +Items to complete soon (next couple of alpha releases). -* 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 meshS) -* if the phone doesn't read fromradio mailbox within X seconds, assume the phone is gone and we can stop queing location msgs +* stay awake while charging +* check gps battery voltage + +* 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. -F95::canSleep say no if we are busy receiving a message - * retest BLE software update for both board types * send note about Adafruit Clue +* report on wikifactory * send note to the guy who designed the cases * remeasure wake time power draws now that we run CPU down at 80MHz @@ -21,12 +24,11 @@ F95::canSleep say no if we are busy receiving a message Items to complete before the first beta release. +* 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) -* sync wake windows to gps time * 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) -* leave lora receiver always on * 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 @@ -47,7 +49,7 @@ Items to complete before the first beta release. * How do avalanche beacons work? Could this do that as well? possibly by using beacon mode feature of the RF95? * use std::map 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 +* add frequency hopping, dependent on the gps time, make the switch moment far from the time anyone is going to be transmitting * publish update articles on the web # Pre-beta priority @@ -176,3 +178,4 @@ Items after the first final candidate release. * don't enter NB state if we've recently talked to the phone (to prevent breaking syncing or bluetooth sw update) * have sw update prevent BLE sleep * manually delete characteristics/descs +* leave lora receiver always on \ No newline at end of file diff --git a/docs/README.md b/docs/README.md index 1358cd367..6c4db3817 100644 --- a/docs/README.md +++ b/docs/README.md @@ -34,9 +34,10 @@ This project is currently in early alpha - if you have questions please join our 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). -# Update 1 +# Updates -* 02/20/2020 - Our first alpha release of the radio software is ready for early users. 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/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. ## Meshtastic Android app Soon our (optional) companion Android application will be released here: