You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The radio will store a small amount of packets (around 30) in its memory for when it's not connected to a client app. If it's full, it will replace the oldest packets with newly incoming text messages only.
On some devices, there is a lot more available memory, and it would be useful to be able to dedicate a large amount to storing messages while the paired device (phone) is disconnected. Consider the case of a Meshtastic device in an ideal location for receiving messages, but the phone user needing to be able to travel away from that location for hours or days. In my location, messages begin to roll off after 10-20 minutes it seems, and if there was a burst of traffic, it could be even faster. In cases like this, even a small interruption in Bluetooth could mean lost messages.
Since there is no theoretical limit to how large a message memory/storage pool could be, I recommend a numerical entry box with something like, "How much memory to use for messages?" and units of KB (and MB?). This would also be a great use of the SD card where messages could be appended to plaintext log files (one file per channel or DM) as well as logged in a structured format like JSON.
The text was updated successfully, but these errors were encountered:
Controlling queue size based on user config values is very problematic at best, especially when you consider that we have a myriad of devices on different platforms with different amounts of memory available. My suggestion would be to place a custom macro in your variant and control it via that in a custom compiled firmware.
Platform
ESP32
Description
Per the documentation:
On some devices, there is a lot more available memory, and it would be useful to be able to dedicate a large amount to storing messages while the paired device (phone) is disconnected. Consider the case of a Meshtastic device in an ideal location for receiving messages, but the phone user needing to be able to travel away from that location for hours or days. In my location, messages begin to roll off after 10-20 minutes it seems, and if there was a burst of traffic, it could be even faster. In cases like this, even a small interruption in Bluetooth could mean lost messages.
Since there is no theoretical limit to how large a message memory/storage pool could be, I recommend a numerical entry box with something like, "How much memory to use for messages?" and units of KB (and MB?). This would also be a great use of the SD card where messages could be appended to plaintext log files (one file per channel or DM) as well as logged in a structured format like JSON.
The text was updated successfully, but these errors were encountered: