Closed tropho23 closed 8 months ago
Edited content to fix Github's annoying "add a glitter badge!" formatting tips, ugh
On what channel and frequency will this beacon be sent out? If the primary channel is encrypted the beacon may not be heart as well as e.g. LongFast with default encryption. Or is it sent out on all channels in the list (round-robin)?
On what channel and frequency will this beacon be sent out? If the primary channel is encrypted the beacon may not be heart as well as e.g. LongFast with default encryption. Or is it sent out on all channels in the list (round-robin)?
Great question, I had not thought of that. Given the intent of this feature I recommend all channels, if that seems reasonable and can be done.
Edited to add use case 3, lost animal locator.
On what channel and frequency will this beacon be sent out? If the primary channel is encrypted the beacon may not be heart as well as e.g. LongFast with default encryption. Or is it sent out on all channels in the list (round-robin)?
Great question, I had not thought of that. Given the intent of this feature I recommend all channels, if that seems reasonable and can be done.
Could be very detrimental to battery life though to do round-robin broadcasts on devices with multiple channels. This one requires some thought. Let's get the initial message broadcast going on the same settings and then iterate from there.
Platform
NRF52, ESP32
Description
I propose a new role: _Lost_andFound. The idea behind this role is to address "SOS beacon" requests users have had, and to add new functionality not present in any of the current roles.
I also propose a new admin message that can change a device's role to this new _lost_andfound one, so it can be done remotely via the mesh, to support one of two new use cases.
Use case 1: If a device is in Client mode, and either the person using it or the device itself is lost, remotely changing the device's role to _Lost_andFound will cause it to begin sending location packet updates at a configurable period of time (perhaps with a 1 minute default period) Either the device's onboard GPS module, the user's phone position data, or the last known position will be broadcast to the mesh with a canned message stating "I'm lost! Current pos: lat/long". This would satisfy users' request for an SOS feature, without necessarily characterizing it as a rescue feature but implementing a similar function.
Use case 1 modifier: Allow remote nodes, ideally only ones authorized to send admin messages, to change a remote device's role back to Client when the device in question is located, or to counter accidental or deliberate beacon spamming.
Use case 2: Same as use case 1, but the user manually changes their device role to _Lost_andFound. There should eventually be an easier way to do this besides changing the role in the current mobile app settings, such as a new app setting entry that has a single button labeled "Enable Lost & Found Beacon" that is not buried within app/device settings. It would ideally require user confirmation, perhaps even twice ("Are you really sure?") before activation to avoid accidental spamming of the mesh. Also some disclaimer that this does NOT alert search and rescue organizations, only other mesh devices would be necessary to avoid confusion.
Use case 3: Animal tracker, such as for a lost dog wearing a Meshtastic device with Tracker role configured. Same as use case 1 above, where the animal's owner would remotely set the device role to _lost_andfound to help locate the lost animal.
Use case 1/2/3 enabler: Include a configurable _Lost_andFound role beacon period, with a reasonable default such as 1-3 minutes.
Use case 1/2/3 modifier: Include a setting for messages sent when there is no change in position for # (configurable) minutes; e.g. "(node name) No movement for # minutes", to advertise the node and/or user have not moved. Perhaps could rely on smart broadcast's movement distance threshold?