ooh that’s a good one thanks for pointing it out. I’ll work on it first (because crashes are bad). In the meantime if either you or @Nanovitruvius are able to leave a serial port connected to the remote node I bet it prints out a super useful error message in the tenish lines of text before it reboots. If you happen to see that message, please ping me in the bug (and/or a forum post) and it will make it much easier for me to repro and fix.
opened 12:36AM - 25 May 21 UTC
> Coming back to this again after quite a bit of testing, I have now managed to … identify a somewhat more reproducible way of causing resets on T-beams v1.0 over the air.
A single node running 1.2.30 with one encrypted channel can sit without resets permanently (I tested 23+h without a single reset)
With four nodes on the mesh, all flashed with 1.2.30, I see a reset every ~24 min or so (based on about 25 resets in 10h). These occur even if no messages are actively sent. On the two nodes that have a screen I can see that they often reset almost simultaneously.
I’ve tested this with the nodes nodes connected via bluetooth and not, with and without admin channels enabled.
The most reproducible way has been to have a remote node with an admin channel enabled. A reset is triggered in the remote node when meshtastic —debug is sent to a USB connected node. (one might have to wait a couple of minutes if the remote device is sleeping).
I am unable to reproducibly induce this behaviour if the remote node does not have an admin channel enabled.
I therefore thought the resets occur only if the admin channel is enabled on the remote node, but after reflashing and only activating the primary channel in all nodes, two nodes nevertheless still reset after a few minutes (even without meshtastic —debug) just as I was writing this (both without USB connection, externally powered nodes don’t seem to reset).
It seems whatever is sent periodically in the mesh without user interaction might also be sent when running meshtastic —debug, and that this can cause the resets.
Can anybody else reproduce this? As mentioned previously, I cannot seem reproduce this if the nodes are powered.
...
I can see that, too. Whether it’s a LoRa32 or a T-Beam, powered by battery or via USB, they would eventually reboot. They all have the admin channel configured.
Plus, some nodes (of course it’s always the remote ones!) would eventually freeze, requiring a manual reboot. They would go on one, two or three days, then simply freeze.
from:
https://meshtastic.discourse.group/t/new-device-release-1-2-30-ready-for-alpha-testing/3272/20
1 Like