While device is in NB state, app should say "battery saver mode" and it should properly queue outbound packets

[claesg]

Just leaving the phone connected to the t-beam results in it loosing connection.

The app is ver 0.1.2
board is running 0.1.0

Close to the end of the logfile there is

03-08 16:12:57.329 4236 4236 W com.geeksville.mesh.service.MeshService: Abandoning reconnect attempt, due to errors during init: Bluetooth status=1 while doing readC ea9f3f82-8dc4-4733-9452-1f6da28892a2

logcat logfile is attached.

2020-03-08_16:04:21.txt

[geeksville]

@claesg OOH that's a super useful log and I can probably fix this in the next day or two. Also, I can have it show some indication of this problem in the GUI so we can see if my fix works without having to break out logcat.

A few follow up questions first that would help:

1. What board model?
2. Was the board powered by USB only or did it also have a battery? (I'm trying to rule out the bluetooth coprocessor browning-out on startup - a problem I had on a previous ESP32 project)
3. What was the sequence of operations? i.e. board was powered (and running - oled on) and then app was launched or vs versa?
4. Or based on your initial sentence: Was the loss of bluetooth due to the board going to sleep after it woke up. Line 3 here: https://github.com/meshtastic/Meshtastic-esp32/blob/master/docs/software/power.md#events-that-decrease-cpu-activity (though even in this case, the app is always supposed to reconnect when the device wakes periodically)
5. When this happens is it possible for you to capture the serial output from the device? You can do this with "pio device monitor -b 115200"

Thanks so much with helping on this - it is tricky to catch these problems from far away ;-)

[geeksville]

note to self: turn on brown-out detector on ESP32

[claesg]

1. It is a TTGO T-BEAM V1.0 https://www.banggood.com/LILYGO-TTGO-T-Beam-ESP32-433868915923Mhz-WiFi-Wireless-bluetooth-Module-GPS-NEO-6M-SMA-LORA32-18650-Battery-Holder-With-OLED-p-1545070.html?ID=510804&cur_warehouse=UK
2. Battery mounted and powered by usb
3. Just started board and app. Let them connect and leave for 10-15 minutes. Phone turns screen off and locks after 5 minutes and board turns off oled.
4. It could be that the board goes to sleep after 15 minutes. The users-tab said not connected.
5. No problem. I'll try to recreate and get some more logs.

[geeksville]

oh - I bet that might just be expected behavior. I have it set to enter "light sleep state" (LS in that power document) after 15 mins of no comms from the phone. Which might be too aggressive, but my thinking there was: a) it saves enormous amounts of battery b) if anything comes in over the mesh, the device will instantly wake up and then start talking to the phone anyways It may be the real bug you revealed is: When the device is in light sleep, if the user goes to send a text or whatever, the app should buffer it until the next time the device wakes. Also the device should wake and check if the phone needs something over bluetooth more often (every 2 min?) and stay awake long enough to see if the phone needed it (5 secs ish). When in this mode in the phone app don't say "disconnected" but rather "long battery mode". There is already a work item to add a place in the phone gui to let the user change these timeouts.

…

On Sun, Mar 8, 2020 at 10:43 AM claesg ***@***.***> wrote: 1. It is a TTGO T-BEAM V1.0 https://www.banggood.com/LILYGO-TTGO-T-Beam-ESP32-433868915923Mhz-WiFi-Wireless-bluetooth-Module-GPS-NEO-6M-SMA-LORA32-18650-Battery-Holder-With-OLED-p-1545070.html?ID=510804&cur_warehouse=UK 2. Battery mounted and powered by usb 3. Just started board and app. Let them connect and leave for 10-15 minutes. Phone turns screen off and locks after 5 minutes and board turns off oled. 4. It could be that the board goes to sleep after 15 minutes. The users-tab said not connected. 5. No problem. I'll try to recreate and get some more logs. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4?email_source=notifications&email_token=AABXB2KNZH6FUOKE3QBR6RDRGPKMRA5CNFSM4LD2OOU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOE4JXA#issuecomment-596231388>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABXB2JW6BKEAIR2NXZM653RGPKMRANCNFSM4LD2OOUQ> .

[claesg]

Yes, I think you are right. It is expected behaviour. I need to read up on how it is supposed to work.
Looking forward to see the improvements of the gui.

[geeksville]

repurposing this bug for the GUI fixes. work items:

• allow queuing texts while device is in NB state
• don't tell user we are "not connected"
• have device wake every couple of minutes and stay alive a very brief time to see if the phone wants us to wake more fully.
• when phone reconnects to device, don't download the full node db, only get new changes (by writing time of last update into the readpointer, rather than just writing an empty packet)

[spattinson]

I am not sure if my issue is similar or not, I am getting Error: Not connected to radio OR Error: No mesh service. I have collected adb and monitor logs from both nodes. I complete pairing, but I am not sure if its successful. The node logs span a longer time frame. I provide them in case they are any use. I also did the steps suggested for analytics there should be something there too, Xiaomi Mi Mix 2s. Thanks!
logs.zip

[geeksville]

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/pairing-issue-pixel-3a/49/9

[geeksville]

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/android-app-new-releases/78/1

[geeksville]

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/android-disconnects/83/2