meshtastic/protobufs
1
0
Fork 0
mirror of https://github.com/meshtastic/protobufs.git synced 2026-04-20 22:13:55 +00:00
Code Issues Projects Releases Packages Wiki Activity

changes as prelude for turning mesh back on

Browse source
This commit is contained in:
geeksville 2020-04-16 17:31:45 -07:00
parent d13d741a98
commit fc4214e34d
1 changed files with 42 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

47
mesh.proto
View file

@ -145,12 +145,14 @@ message User {
// The payload portion fo a packet, this is the actual bytes that are sent
// inside a radio packet (because from/to are broken out by the comms library)
message SubPacket {
oneof variant {
Position position = 1;
Data data = 3;
User user = 4;
}
// Typically only one of the following fields are populated, but there is no
// restriction wrt that
Position position = 1;
Data data = 3;
User user = 4;
// FIXME, add mesh routing payloads
/// Not normally used, but for testing a sender can request that recipient
/// responds in kind (i.e. if it received a position, it should unicast back
@ -184,6 +186,41 @@ message MeshPacket {
/// (chain of SubPacket) sent to the phone (so the phone can know exact time
/// of reception)
uint32 rx_time = 4;
/// Never sent over the radio links. Set during reception to indicate the SNR
/// of this packet. Used to collect statistics on current link waulity.
sint32 rx_snr = 5;
/**
A unique ID for this packet. Always 0 for no-ack packets or non broadcast
packets (and therefore take zero bytes of space). Otherwise a unique ID for
this packet. Useful for flooding algorithms.
ID only needs to be unique on a _per sender_ basis. And it only
needs to be unique for a few minutes (long enough to last for the length of
any ACK or the completion of a mesh broadcast flood).
Rules for broadcasting (listing here for now, will move elsewhere eventually):
If to==BROADCAST and id==0, this is a simple broadcast (0 hops). It will be
sent only by the current node and other nodes will not attempt to rebroadcast
it.
If to==BROADCAST and id!=0, this is a "naive flooding" broadcast. The initial
node will send it on all local interfaces.
When other nodes receive this message, they will
first check if their recentBroadcasts table contains the (from, id) pair that
indicates this message. If so, we've already seen it - so we discard it. If
not, we add it to the table and then resend this message on all interfaces.
When resending we are careful to use the "from" ID of the original sender. Not
our own ID. When resending we pick a random delay between 0 and 10 seconds to
decrease the chance of collisions with transmitters we can not even hear.
Any entries in recentBroadcasts that are older than X seconds (longer than the
max time a flood can take) will be discarded.
*/
uint32 id = 6;
}
/// Shared constants between device and phone