2020-03-02 17:47:10 +00:00
|
|
|
|
syntax = "proto3";
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* Meshtastic protobufs
|
|
|
|
|
*
|
|
|
|
|
* For more information on protobufs (and tools to use them with the language of your choice) see
|
|
|
|
|
* https://developers.google.com/protocol-buffers/docs/proto3
|
|
|
|
|
*
|
|
|
|
|
* We are not placing any of these defs inside a package, because if you do the
|
|
|
|
|
* resulting nanopb version is super verbose package mesh.
|
|
|
|
|
*
|
|
|
|
|
* Protobuf build instructions:
|
|
|
|
|
*
|
|
|
|
|
* To build java classes for reading writing:
|
|
|
|
|
* protoc -I=. --java_out /tmp mesh.proto
|
|
|
|
|
*
|
|
|
|
|
* To generate Nanopb c code:
|
|
|
|
|
* /home/kevinh/packages/nanopb-0.4.0-linux-x86/generator-bin/protoc --nanopb_out=/tmp -I=app/src/main/proto mesh.proto
|
|
|
|
|
*
|
|
|
|
|
* Nanopb binaries available here: https://jpa.kapsi.fi/nanopb/download/ use nanopb 0.4.0
|
|
|
|
|
*/
|
2020-03-02 17:47:10 +00:00
|
|
|
|
|
2020-12-04 10:32:18 +00:00
|
|
|
|
option java_package = "com.geeksville.mesh";
|
|
|
|
|
option optimize_for = LITE_RUNTIME;
|
|
|
|
|
|
|
|
|
|
import "portnums.proto";
|
|
|
|
|
|
2021-02-27 05:43:36 +00:00
|
|
|
|
option java_outer_classname = "MeshProtos";
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* a gps position
|
|
|
|
|
*/
|
2020-03-02 17:47:10 +00:00
|
|
|
|
message Position {
|
2021-03-02 04:44:29 +00:00
|
|
|
|
/* The old (pre 1.2) position encoding sent lat/lon as sint32s in field 7,8.
|
|
|
|
|
Do not use to prevent confusing old apps */
|
|
|
|
|
reserved 7, 8;
|
2020-05-04 14:43:15 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* The new preferred location encoding, divide by 1e-7 to get degrees
|
|
|
|
|
* in floating point
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2021-02-16 07:41:05 +00:00
|
|
|
|
sfixed32 latitude_i = 1;
|
2021-01-29 02:11:10 +00:00
|
|
|
|
|
2021-02-16 07:41:05 +00:00
|
|
|
|
sfixed32 longitude_i = 2;
|
2020-05-04 14:43:15 +00:00
|
|
|
|
|
2021-02-23 03:42:40 +00:00
|
|
|
|
/* This is a special 'small' position update for lat/lon. It encodes a signed 16 bit latitude in the upper
|
|
|
|
|
2 bytes, and a signed longitude in the lower 16 bits. It is not currently implemented, but can be added in an
|
|
|
|
|
automatically backwards compatible way later. Note: ONLY microlatlon OR latitude_i, longitude_i are populated in any particular
|
|
|
|
|
position. A microdelta is always relative to the last received full position.
|
|
|
|
|
|
|
|
|
|
fixed32 microlatlon = 3; */
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* In meters above MSL
|
|
|
|
|
*/
|
2020-03-24 20:12:25 +00:00
|
|
|
|
int32 altitude = 3;
|
2020-07-06 05:09:43 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* 1-100 (0 means not provided)
|
|
|
|
|
*/
|
2020-07-06 05:09:43 +00:00
|
|
|
|
int32 battery_level = 4;
|
2020-03-24 20:12:25 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* This is usually not sent over the mesh (to save space), but it is sent
|
|
|
|
|
* from the phone so that the local device can set its RTC If it is sent over
|
|
|
|
|
* the mesh (because there are devices on the mesh without GPS), it will only
|
|
|
|
|
* be sent by devices which has a hardware GPS clock.
|
|
|
|
|
* seconds since 1970
|
|
|
|
|
*/
|
2021-02-23 23:15:20 +00:00
|
|
|
|
fixed32 time = 9;
|
2020-03-02 17:47:10 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* Broadcast when a newly powered mesh node wants to find a node num it can use
|
|
|
|
|
* Sent from the phone over bluetooth to set the user id for the owner of this node.
|
|
|
|
|
* Also sent from nodes to each other when a new node signs on (so all clients can have this info)
|
|
|
|
|
*
|
|
|
|
|
* The algorithm is as follows:
|
|
|
|
|
* when a node starts up, it broadcasts their user and the normal flow is for all
|
|
|
|
|
* other nodes to reply with their User as well (so the new node can build its nodedb)
|
|
|
|
|
* If a node ever receives a User (not just the first broadcast) message where
|
|
|
|
|
* the sender node number equals our node number, that indicates a collision has
|
|
|
|
|
* occurred and the following steps should happen:
|
|
|
|
|
*
|
|
|
|
|
* If the receiving node (that was already in the mesh)'s macaddr is LOWER than the
|
|
|
|
|
* new User who just tried to sign in: it gets to keep its nodenum. We send a
|
|
|
|
|
* broadcast message of OUR User (we use a broadcast so that the other node can
|
|
|
|
|
* receive our message, considering we have the same id - it also serves to let
|
|
|
|
|
* observers correct their nodedb) - this case is rare so it should be okay.
|
|
|
|
|
*
|
|
|
|
|
* If any node receives a User where the macaddr is GTE than their local macaddr,
|
|
|
|
|
* they have been vetoed and should pick a new random nodenum (filtering against
|
|
|
|
|
* whatever it knows about the nodedb) and rebroadcast their User.
|
|
|
|
|
*
|
|
|
|
|
* A few nodenums are reserved and will never be requested:
|
|
|
|
|
* 0xff - broadcast
|
|
|
|
|
* 0 through 3 - for future use
|
|
|
|
|
*/
|
2020-03-02 17:47:10 +00:00
|
|
|
|
message User {
|
2020-12-04 22:15:03 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* A globally unique ID string for this user. In the case of
|
|
|
|
|
* Signal that would mean +16504442323, for the default macaddr
|
2021-02-08 04:21:31 +00:00
|
|
|
|
* derived id it would be !<8 hexidecimal bytes>
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2021-02-23 23:15:20 +00:00
|
|
|
|
string id = 1;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* A full name for this user, i.e. "Kevin Hester"
|
|
|
|
|
*/
|
2021-02-23 23:15:20 +00:00
|
|
|
|
string long_name = 2;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* A VERY short name, ideally two characters. Suitable for a tiny OLED screen
|
|
|
|
|
*/
|
2021-02-23 23:15:20 +00:00
|
|
|
|
string short_name = 3;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* This is the addr of the radio. Not populated by the phone,
|
|
|
|
|
* but added by the esp32 when broadcasting
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2021-02-23 23:15:20 +00:00
|
|
|
|
bytes macaddr = 4;
|
2020-03-02 17:47:10 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* A message used in our Dynamic Source Routing protocol (RFC 4728 based)
|
|
|
|
|
*/
|
2020-04-17 16:48:14 +00:00
|
|
|
|
message RouteDiscovery {
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
2021-02-17 05:05:46 +00:00
|
|
|
|
* The list of nodenums this packet has visited so far
|
2020-04-17 16:48:14 +00:00
|
|
|
|
*/
|
2021-02-17 05:05:46 +00:00
|
|
|
|
repeated fixed32 route = 2;
|
2020-04-17 16:48:14 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-02-17 05:05:46 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* A Routing control Data packet handled by the routing plugin
|
|
|
|
|
*/
|
|
|
|
|
message Routing {
|
|
|
|
|
|
|
|
|
|
/*
|
2021-02-07 02:05:41 +00:00
|
|
|
|
* A failure in delivering a message (usually used for routing control messages, but might be provided in addition to ack.fail_id to provide
|
|
|
|
|
* details on the type of failure).
|
|
|
|
|
*/
|
2021-02-17 05:05:46 +00:00
|
|
|
|
enum Error {
|
2021-01-29 02:11:10 +00:00
|
|
|
|
|
2021-02-17 05:05:46 +00:00
|
|
|
|
/* This message is not a failure */
|
|
|
|
|
NONE = 0;
|
2020-05-23 22:39:38 +00:00
|
|
|
|
|
2021-02-17 05:05:46 +00:00
|
|
|
|
/*
|
|
|
|
|
* Our node doesn't have a route to the requested destination anymore.
|
|
|
|
|
*/
|
|
|
|
|
NO_ROUTE = 1;
|
2020-05-23 22:39:38 +00:00
|
|
|
|
|
2021-02-17 05:05:46 +00:00
|
|
|
|
/*
|
|
|
|
|
* We received a nak while trying to forward on your behalf
|
|
|
|
|
*/
|
|
|
|
|
GOT_NAK = 2;
|
|
|
|
|
|
|
|
|
|
TIMEOUT = 3;
|
2020-05-24 00:38:49 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
2021-02-22 03:14:29 +00:00
|
|
|
|
* No suitable interface could be found for delivering this packet
|
|
|
|
|
*/
|
2021-02-17 05:05:46 +00:00
|
|
|
|
NO_INTERFACE = 4;
|
2021-02-07 01:45:08 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
2021-02-22 04:16:03 +00:00
|
|
|
|
* We reached the max retransmission count (typically for naive flood routing)
|
|
|
|
|
*/
|
2021-02-17 05:05:46 +00:00
|
|
|
|
MAX_RETRANSMIT = 5;
|
2021-02-22 04:16:03 +00:00
|
|
|
|
|
|
|
|
|
/* No suitable channel was found for sending this packet (i.e. was requested channel index disabled?) */
|
|
|
|
|
NO_CHANNEL = 6;
|
|
|
|
|
|
|
|
|
|
/* The packet was too big for sending (exceeds interface MTU after encoding) */
|
|
|
|
|
TOO_LARGE = 7;
|
2021-02-17 05:05:46 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
oneof variant {
|
|
|
|
|
/*
|
|
|
|
|
* A route request going from the requester
|
|
|
|
|
*/
|
|
|
|
|
RouteDiscovery route_request = 1;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* A route reply
|
|
|
|
|
*/
|
|
|
|
|
RouteDiscovery route_reply = 2;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* A failure in delivering a message (usually used for routing control messages, but might be provided
|
|
|
|
|
* in addition to ack.fail_id to provide details on the type of failure).
|
|
|
|
|
*/
|
|
|
|
|
Error error_reason = 3;
|
2021-02-07 02:05:41 +00:00
|
|
|
|
|
2021-02-26 12:30:04 +00:00
|
|
|
|
/* Deprecated - this has been replced with error_reason == NONE && request_id != 0
|
|
|
|
|
* This is an ack.
|
2021-02-17 05:05:46 +00:00
|
|
|
|
* This packet is a requested acknoledgement indicating that we have received
|
|
|
|
|
* the specified message ID. This packet type can be used both for immediate
|
|
|
|
|
* (0 hops) messages or can be routed through multiple hops if dest is set.
|
|
|
|
|
* Note: As an optimization, recipients can _also_ populate a field in payload
|
|
|
|
|
* if they think the recipient would appreciate that extra state.
|
2021-02-26 12:30:04 +00:00
|
|
|
|
|
2021-02-17 05:05:46 +00:00
|
|
|
|
fixed32 success_id = 4;
|
2021-02-26 12:30:04 +00:00
|
|
|
|
*/
|
2021-02-17 05:05:46 +00:00
|
|
|
|
|
2021-02-26 12:30:04 +00:00
|
|
|
|
/* Deprecated - this has been replced with error_reason !== NONE && request_id != 0
|
2021-02-17 05:05:46 +00:00
|
|
|
|
* This is a nak, we failed to deliver this message.
|
|
|
|
|
fixed32 fail_id = 5;
|
2021-02-26 12:30:04 +00:00
|
|
|
|
*/
|
|
|
|
|
}
|
2020-05-23 22:39:38 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-02-17 05:05:46 +00:00
|
|
|
|
/* (Formerly called SubPacket)
|
2021-01-29 02:11:10 +00:00
|
|
|
|
* 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)
|
|
|
|
|
*/
|
2021-02-17 05:05:46 +00:00
|
|
|
|
message Data {
|
2020-03-24 20:12:25 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
2021-02-17 05:05:46 +00:00
|
|
|
|
* Formerly named typ and of type Type
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2021-02-17 05:05:46 +00:00
|
|
|
|
PortNum portnum = 1;
|
2020-05-11 22:40:04 +00:00
|
|
|
|
|
2021-02-17 05:05:46 +00:00
|
|
|
|
/*
|
|
|
|
|
* Required
|
|
|
|
|
*/
|
|
|
|
|
bytes payload = 2;
|
2020-04-17 16:48:14 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* 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 it's position).
|
|
|
|
|
* Note: that if you set this on a broadcast you will receive many replies.
|
|
|
|
|
*/
|
2021-02-17 08:17:18 +00:00
|
|
|
|
bool want_response = 3;
|
2020-04-17 16:48:14 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* The address of the destination node.
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* This field is is filled in by the mesh radio device software, application
|
2021-01-29 02:11:10 +00:00
|
|
|
|
* layer software should never need it.
|
|
|
|
|
* RouteDiscovery messages _must_ populate this. Other message types might need
|
|
|
|
|
* to if they are doing multihop routing.
|
|
|
|
|
*/
|
2021-02-17 08:17:18 +00:00
|
|
|
|
fixed32 dest = 4;
|
2020-05-23 22:39:38 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* The address of the original sender for this message.
|
|
|
|
|
* This field should _only_ be populated for reliable multihop packets (to keep
|
|
|
|
|
* packets small).
|
|
|
|
|
*/
|
2021-02-17 08:17:18 +00:00
|
|
|
|
fixed32 source = 5;
|
2021-02-26 12:30:04 +00:00
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Only used in routing or response messages. Indicates the original message ID that
|
|
|
|
|
* this message is reporting failure on. (formerly called original_id)
|
|
|
|
|
*/
|
|
|
|
|
fixed32 request_id = 6;
|
2020-03-02 17:47:10 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
2021-02-17 08:17:18 +00:00
|
|
|
|
* A packet envelope sent/received over the mesh
|
2021-02-21 04:59:22 +00:00
|
|
|
|
* only payloadVariant is sent in the payload portion of the LORA packet.
|
|
|
|
|
* The other fields are either not sent at all, or sent in the special 16 byte LORA header.
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2020-03-02 17:47:10 +00:00
|
|
|
|
message MeshPacket {
|
2020-04-17 16:48:14 +00:00
|
|
|
|
|
2021-02-23 23:15:20 +00:00
|
|
|
|
/* The priority of this message for sending. Higher priorities are sent first
|
|
|
|
|
(when managing the transmit queue).
|
|
|
|
|
This field is never sent over the air, it is only used internally inside of a local device node.
|
|
|
|
|
API clients (either on the local node or connected directly to the node)
|
|
|
|
|
can set this parameter if necessary.
|
2021-02-11 10:59:05 +00:00
|
|
|
|
|
|
|
|
|
(values must be <= 127 to keep protobuf field to one byte in size.
|
2021-02-12 02:29:00 +00:00
|
|
|
|
|
|
|
|
|
Detailed background on this field:
|
|
|
|
|
|
2021-02-23 23:15:20 +00:00
|
|
|
|
I noticed a funny side effect of lora being so slow: Usually when making
|
|
|
|
|
a protocol there isn’t much need to use message priority to change the order
|
|
|
|
|
of transmission (because interfaces are fairly fast).
|
|
|
|
|
But for lora where packets can take a few seconds each, it is very important
|
|
|
|
|
to make sure that critical packets are sent ASAP.
|
|
|
|
|
In the case of meshtastic that means we want to send protocol acks as soon as possible
|
|
|
|
|
(to prevent unneeded retransmissions), we want routing messages to be sent next,
|
|
|
|
|
then messages marked as reliable and finally ‘background’ packets like periodic position updates.
|
|
|
|
|
|
|
|
|
|
So I bit the bullet and implemented a new (internal - not sent over the air)
|
|
|
|
|
field in MeshPacket called ‘priority’.
|
|
|
|
|
And the transmission queue in the router object is now a priority queue.
|
2021-02-11 10:59:05 +00:00
|
|
|
|
*/
|
|
|
|
|
enum Priority {
|
|
|
|
|
/* Treated as Priority.DEFAULT */
|
|
|
|
|
UNSET = 0;
|
|
|
|
|
|
|
|
|
|
MIN = 1;
|
|
|
|
|
|
2021-02-23 23:15:20 +00:00
|
|
|
|
/* Background position updates are sent with very low priority -
|
|
|
|
|
* if the link is super congested they might not go out at all */
|
2021-02-11 10:59:05 +00:00
|
|
|
|
BACKGROUND = 10;
|
|
|
|
|
|
2021-02-12 01:39:35 +00:00
|
|
|
|
/* This priority is used for most messages that don't have a priority set */
|
2021-02-11 10:59:05 +00:00
|
|
|
|
DEFAULT = 64;
|
|
|
|
|
|
2021-02-23 23:15:20 +00:00
|
|
|
|
/* If priority is unset but the message is marked as want_ack,
|
|
|
|
|
* assume it is important and use a slightly higher priority */
|
2021-02-12 01:39:35 +00:00
|
|
|
|
RELIABLE = 70;
|
|
|
|
|
|
2021-02-23 23:15:20 +00:00
|
|
|
|
/* Ack/naks are sent with very high priority to ensure that retransmission
|
|
|
|
|
* stops as soon as possible */
|
2021-02-11 10:59:05 +00:00
|
|
|
|
ACK = 120;
|
|
|
|
|
|
|
|
|
|
MAX = 127;
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* The sending node number.
|
|
|
|
|
* Note: Our crypto implementation uses this field as well. See
|
|
|
|
|
* docs/software/crypto.md for details.
|
|
|
|
|
* FIXME - really should be fixed32 instead, this encoding only hurts the ble link though.
|
|
|
|
|
*/
|
2021-02-17 05:05:46 +00:00
|
|
|
|
fixed32 from = 1;
|
2020-04-17 16:48:14 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
2021-02-11 10:59:05 +00:00
|
|
|
|
* The (immediatSee Priority description for more details.y should be fixed32 instead, this encoding only
|
2021-01-29 02:11:10 +00:00
|
|
|
|
* hurts the ble link though.
|
|
|
|
|
*/
|
2021-02-17 05:05:46 +00:00
|
|
|
|
fixed32 to = 2;
|
2020-03-24 20:12:25 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
2021-02-22 04:16:03 +00:00
|
|
|
|
* (Usually) If set, this indicates the index in the secondary_channels table that this packet
|
2021-01-29 02:11:10 +00:00
|
|
|
|
* was sent/received on. If unset, packet was on the primary channel.
|
|
|
|
|
* A particular node might know only a subset of channels in use on the mesh. Therefore channel_index
|
|
|
|
|
* is inherently a local concept and meaningless to send between nodes.
|
2021-02-22 04:16:03 +00:00
|
|
|
|
*
|
|
|
|
|
* Very briefly, while sending and receiving deep inside the device Router code, this field instead
|
|
|
|
|
* contains the 'channel hash' instead of the index. This 'trick' is only used while the payloadVariant is
|
|
|
|
|
* an 'encrypted'.
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2021-02-22 04:16:03 +00:00
|
|
|
|
uint32 channel = 3;
|
2021-01-29 02:11:10 +00:00
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Internally to the mesh radios we will route SubPackets encrypted per
|
|
|
|
|
* docs/software/crypto.md. However, when a particular node has the correct
|
|
|
|
|
* key to decode a particular packet, it will decode the payload into a SubPacket protobuf structure.
|
|
|
|
|
* Software outside of the device nodes will never encounter a packet where
|
|
|
|
|
* "decoded" is not populated (i.e. any encryption/decryption happens before reaching the applications)
|
|
|
|
|
* The numeric IDs for these fields were selected to keep backwards compatibility with old applications.
|
|
|
|
|
*/
|
|
|
|
|
|
2021-02-02 10:22:25 +00:00
|
|
|
|
oneof payloadVariant {
|
2021-02-21 04:59:22 +00:00
|
|
|
|
Data decoded = 4;
|
|
|
|
|
bytes encrypted = 5;
|
2020-05-10 02:06:45 +00:00
|
|
|
|
}
|
2020-03-24 20:12:25 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* 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).
|
|
|
|
|
* Note: Our crypto implementation uses this id as well. See docs/software/crypto.md for details.
|
|
|
|
|
* FIXME - really should be fixed32 instead, this encoding only
|
|
|
|
|
* hurts the ble link though.
|
|
|
|
|
*/
|
2021-02-17 05:05:46 +00:00
|
|
|
|
fixed32 id = 6;
|
2020-04-30 19:34:49 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* The time this message was received by the esp32 (secs since 1970). Note:
|
|
|
|
|
* this field is _never_ sent on the radio link itself (to save space) Times
|
|
|
|
|
* are typically not sent over the mesh, but they will be added to any Packet
|
|
|
|
|
* (chain of SubPacket) sent to the phone (so the phone can know exact time of reception)
|
|
|
|
|
*/
|
2021-02-21 04:59:22 +00:00
|
|
|
|
fixed32 rx_time = 7;
|
2020-05-11 22:40:04 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* *Never* sent over the radio links. Set during reception to indicate the SNR
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* of this packet. Used to collect statistics on current link quality.
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2021-02-21 04:59:22 +00:00
|
|
|
|
float rx_snr = 8;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* If unset treated as zero (no forwarding, send to adjacent nodes only)
|
2021-02-21 04:59:22 +00:00
|
|
|
|
* if 1, allow hopping through one node, etc...
|
|
|
|
|
* For our usecase real world topologies probably have a max of about 3.
|
|
|
|
|
* This field is normally placed into a few of bits in the header.
|
|
|
|
|
*/
|
2020-05-12 20:34:44 +00:00
|
|
|
|
uint32 hop_limit = 10;
|
2021-02-21 04:59:22 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* This packet is being sent as a reliable message, we would prefer it to arrive
|
|
|
|
|
* at the destination. We would like to receive a ack packet in response.
|
|
|
|
|
* Broadcasts messages treat this flag specially: Since acks for broadcasts would
|
|
|
|
|
* rapidly flood the channel, the normal ack behavior is suppressed. Instead,
|
|
|
|
|
* the original sender listens to see if at least one node is rebroadcasting this
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* packet (because naive flooding algorithm). If it hears that the odds (given
|
2021-01-29 02:11:10 +00:00
|
|
|
|
* typical LoRa topologies) the odds are very high that every node should
|
|
|
|
|
* eventually receive the message. So FloodingRouter.cpp generates an implicit
|
|
|
|
|
* ack which is delivered to the original sender. If after some time we don't
|
|
|
|
|
* hear anyone rebroadcast our packet, we will timeout and retransmit, using the regular resend logic.
|
|
|
|
|
* Note: This flag is normally sent in a flag bit in the header when sent over the wire
|
2021-02-21 04:59:22 +00:00
|
|
|
|
*/
|
2020-05-19 17:27:02 +00:00
|
|
|
|
bool want_ack = 11;
|
2021-02-11 10:59:05 +00:00
|
|
|
|
|
|
|
|
|
/* The priority of this message for sending.
|
|
|
|
|
See MeshPacket.Priority description for more details.
|
|
|
|
|
*/
|
|
|
|
|
Priority priority = 12;
|
2020-03-02 17:47:10 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* Shared constants between device and phone
|
|
|
|
|
*/
|
2020-03-02 17:47:10 +00:00
|
|
|
|
enum Constants {
|
2020-11-21 00:39:38 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* First enum must be zero, and we are just using this enum to
|
|
|
|
|
* pass int constants between two very different environments
|
|
|
|
|
*/
|
2020-12-04 22:15:03 +00:00
|
|
|
|
Unused = 0;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* From mesh.options
|
|
|
|
|
* note: this payload length is ONLY the bytes that are sent inside of the radiohead packet
|
|
|
|
|
* Data.payload max_size:240
|
|
|
|
|
*/
|
2020-11-21 00:39:38 +00:00
|
|
|
|
DATA_PAYLOAD_LEN = 240;
|
2020-03-02 17:47:10 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* The bluetooth to device link:
|
|
|
|
|
*
|
|
|
|
|
* Old BTLE protocol docs from TODO, merge in above and make real docs...
|
|
|
|
|
*
|
|
|
|
|
* use protocol buffers, and NanoPB
|
|
|
|
|
*
|
|
|
|
|
* messages from device to phone:
|
|
|
|
|
* POSITION_UPDATE (..., time)
|
|
|
|
|
* TEXT_RECEIVED(from, text, time)
|
|
|
|
|
* OPAQUE_RECEIVED(from, payload, time) (for signal messages or other applications)
|
|
|
|
|
*
|
|
|
|
|
* messages from phone to device:
|
|
|
|
|
* SET_MYID(id, human readable long, human readable short) (send down the unique ID
|
|
|
|
|
* string used for this node, a human readable string shown for that id, and a very
|
|
|
|
|
* short human readable string suitable for oled screen) SEND_OPAQUE(dest, payload)
|
|
|
|
|
* (for signal messages or other applications) SEND_TEXT(dest, text) Get all
|
|
|
|
|
* nodes() (returns list of nodes, with full info, last time seen, loc, battery
|
|
|
|
|
* level etc) SET_CONFIG (switches device to a new set of radio params and
|
|
|
|
|
* preshared key, drops all existing nodes, force our node to rejoin this new group)
|
|
|
|
|
*
|
|
|
|
|
* Full information about a node on the mesh
|
|
|
|
|
*/
|
|
|
|
|
message NodeInfo {
|
2020-03-02 17:47:10 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* the node number
|
|
|
|
|
*/
|
|
|
|
|
uint32 num = 1;
|
2020-03-02 17:47:10 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* The user info for this node
|
|
|
|
|
*/
|
|
|
|
|
User user = 2;
|
2020-03-24 20:12:25 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* This position data will also contain a time last seen
|
|
|
|
|
*/
|
2020-03-24 20:12:25 +00:00
|
|
|
|
Position position = 3;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* Returns the Signal-to-noise ratio (SNR) of the last received message,
|
|
|
|
|
* as measured by the receiver. Return SNR of the last received message in dB
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2020-04-30 19:34:49 +00:00
|
|
|
|
float snr = 7;
|
2020-03-24 20:12:25 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* Returns the last measured frequency error.
|
|
|
|
|
* The LoRa receiver estimates the frequency offset between the receiver
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* center frequency and that of the received LoRa signal. This function
|
2021-01-29 02:11:10 +00:00
|
|
|
|
* returns the estimates offset (in Hz) of the last received message.
|
|
|
|
|
* Caution: this measurement is not absolute, but is measured relative to the
|
|
|
|
|
* local receiver's oscillator. Apparent errors may be due to the
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* transmitter, the receiver or both. \return The estimated center frequency
|
2021-01-29 02:11:10 +00:00
|
|
|
|
* offset in Hz of the last received message.
|
|
|
|
|
* int32 frequency_error = 6;
|
|
|
|
|
*
|
|
|
|
|
* enum RouteState {
|
|
|
|
|
* Invalid = 0;
|
|
|
|
|
* Discovering = 1;
|
|
|
|
|
* Valid = 2;
|
|
|
|
|
* }
|
|
|
|
|
*
|
|
|
|
|
* Not needed?
|
|
|
|
|
* RouteState route = 4;
|
|
|
|
|
*
|
|
|
|
|
* Our current preferred node node for routing - might be the same as num if
|
|
|
|
|
* we are adjacent Or zero if we don't yet know a route to this node.
|
|
|
|
|
*/
|
2020-05-11 22:40:04 +00:00
|
|
|
|
uint32 next_hop = 5;
|
2020-03-02 17:47:10 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-02-23 23:15:20 +00:00
|
|
|
|
/** Error codes for critical errors
|
2020-12-27 03:07:58 +00:00
|
|
|
|
*
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* The device might report these fault codes on the screen.
|
|
|
|
|
* If you encounter a fault code, please post on the meshtastic.discourse.group
|
|
|
|
|
* and we'll try to help.
|
2020-12-27 03:07:58 +00:00
|
|
|
|
*/
|
|
|
|
|
enum CriticalErrorCode {
|
|
|
|
|
None = 0;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* A software bug was detected while trying to send lora
|
|
|
|
|
*/
|
2020-12-27 03:07:58 +00:00
|
|
|
|
TxWatchdog = 1;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* A software bug was detected on entry to sleep
|
|
|
|
|
*/
|
2020-12-27 03:07:58 +00:00
|
|
|
|
SleepEnterWait = 2;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* No Lora radio hardware could be found
|
|
|
|
|
*/
|
2020-12-27 03:07:58 +00:00
|
|
|
|
NoRadio = 3;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* Not normally used
|
|
|
|
|
*/
|
2020-12-27 03:07:58 +00:00
|
|
|
|
Unspecified = 4;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* We failed while configuring a UBlox GPS
|
|
|
|
|
*/
|
2020-12-27 03:07:58 +00:00
|
|
|
|
UBloxInitFailed = 5;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* This board was expected to have a power management chip and it is missing or broken
|
|
|
|
|
*/
|
2020-12-27 03:07:58 +00:00
|
|
|
|
NoAXP192 = 6;
|
2020-12-27 05:07:46 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* The channel tried to set a radio setting which is not supported by this chipset,
|
|
|
|
|
* radio comms settings are now undefined.
|
|
|
|
|
*/
|
2020-12-27 05:07:46 +00:00
|
|
|
|
InvalidRadioSetting = 7;
|
2020-12-27 03:07:58 +00:00
|
|
|
|
|
2021-02-02 10:19:47 +00:00
|
|
|
|
/*
|
|
|
|
|
* Radio transmit hardware failure. We sent data to the radio chip, but it didn't
|
|
|
|
|
* reply with an interrupt.
|
|
|
|
|
*/
|
2021-01-29 02:11:10 +00:00
|
|
|
|
TransmitFailed = 8;
|
2020-03-02 17:47:10 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
}
|
2020-03-02 17:47:10 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* Unique local debugging info for this node
|
|
|
|
|
* Note: we don't include position or the user info, because that will come in the
|
|
|
|
|
* Sent to the phone in response to WantNodes.
|
|
|
|
|
*/
|
2020-03-02 17:47:10 +00:00
|
|
|
|
message MyNodeInfo {
|
2021-01-29 02:11:10 +00:00
|
|
|
|
|
|
|
|
|
/*
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* Tells the phone what our node number is, default starting value is
|
|
|
|
|
* lowbyte of macaddr, but it will be fixed if that is already in use
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2020-05-22 03:30:56 +00:00
|
|
|
|
uint32 my_node_num = 1;
|
2020-03-24 20:12:25 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* Note: this bool no longer means "we have our own GPS".
|
|
|
|
|
* Because gps_operation is more advanced, but we'd like old phone apps
|
|
|
|
|
* to keep working. So for legacy reasons we set this flag as follows:
|
|
|
|
|
* if false it would be great if the phone can help provide gps coordinates.
|
|
|
|
|
* If true we don't need location assistance from the phone.
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2020-03-24 20:12:25 +00:00
|
|
|
|
bool has_gps = 2;
|
2020-03-02 17:47:10 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
2021-02-16 07:41:05 +00:00
|
|
|
|
* # of frequencies that can be used (set at build time in the device flash image). Note: this is different from max_channels, this field
|
|
|
|
|
* is telling the # of frequency bands this node can use. (old name was num_channels)
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2021-02-16 07:41:05 +00:00
|
|
|
|
uint32 num_bands = 3;
|
2020-03-02 17:47:10 +00:00
|
|
|
|
|
2021-02-16 07:41:05 +00:00
|
|
|
|
/* The maximum number of 'software' channels that can be set on this node.
|
|
|
|
|
*/
|
|
|
|
|
uint32 max_channels = 15;
|
|
|
|
|
|
|
|
|
|
/* Deprecated! ONLY USED IN DEVICE CODE (for upgrading old 1.0 firmwares) DO NOT READ ELSEWHERE.
|
2021-01-29 02:11:10 +00:00
|
|
|
|
* The region code for my radio (US, CN, etc...)
|
|
|
|
|
* Note: This string is deprecated. The 1.0 builds populate it based on the
|
|
|
|
|
* flashed firmware name. But for newer builds this string will be unpopulated
|
|
|
|
|
* (missing/null). For those builds you should instead look at the new
|
|
|
|
|
* read/write region enum in UserSettings
|
|
|
|
|
* The format of this string was 1.0-US or 1.0-CN etc.. Or empty string if unset.
|
|
|
|
|
*/
|
2021-02-15 09:11:36 +00:00
|
|
|
|
string region = 4 [deprecated = true];
|
2020-03-02 17:47:10 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* TBEAM, HELTEC, etc...
|
|
|
|
|
*/
|
2020-03-24 20:12:25 +00:00
|
|
|
|
string hw_model = 5;
|
2020-03-03 14:54:14 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* 0.0.5 etc...
|
|
|
|
|
*/
|
2020-03-24 20:12:25 +00:00
|
|
|
|
string firmware_version = 6;
|
2020-03-03 14:54:14 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* An error message we'd like to report back to the mothership through analytics.
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* It indicates a serious bug occurred on the device, the device coped with it,
|
|
|
|
|
* but we still want to tell the devs about the bug.
|
|
|
|
|
* This field will be cleared after the phone reads MyNodeInfo
|
|
|
|
|
* (i.e. it will only be reported once)
|
2021-01-29 02:11:10 +00:00
|
|
|
|
* a numeric error code to go with error message, zero means no error
|
|
|
|
|
*/
|
|
|
|
|
CriticalErrorCode error_code = 7;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* A numeric error address (nonzero if available)
|
|
|
|
|
*/
|
2020-03-24 20:12:25 +00:00
|
|
|
|
uint32 error_address = 8;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* The total number of errors this node has ever encountered
|
|
|
|
|
* (well - since the last time we discarded preferences)
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2020-03-24 20:22:16 +00:00
|
|
|
|
uint32 error_count = 9;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* How long before we consider a message abandoned and we can clear our
|
|
|
|
|
* caches of any messages in flight Normally quite large to handle the worst case
|
|
|
|
|
* message delivery time, 5 minutes. Formerly called FLOOD_EXPIRE_TIME in the
|
|
|
|
|
* device code
|
|
|
|
|
*/
|
2020-05-31 02:04:33 +00:00
|
|
|
|
uint32 message_timeout_msec = 13;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* The minimum app version that can talk to this device. Phone/PC apps should
|
|
|
|
|
* compare this to their build number and if too low tell the user they must
|
|
|
|
|
* update their app
|
|
|
|
|
*/
|
2020-06-03 20:56:54 +00:00
|
|
|
|
uint32 min_app_version = 14;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* FIXME - add more useful debugging state (queue depths etc)
|
|
|
|
|
*/
|
2020-03-02 17:47:10 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/* Debug output from the device.
|
|
|
|
|
*
|
|
|
|
|
* To minimize the size of records inside the device code, if a time/source/level is not set
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* on the message it is assumed to be a continuation of the previously sent message.
|
|
|
|
|
* This allows the device code to use fixed maxlen 64 byte strings for messages,
|
|
|
|
|
* and then extend as needed by emitting multiple records.
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2020-12-27 02:55:13 +00:00
|
|
|
|
message LogRecord {
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* Log levels, chosen to match python logging conventions.
|
|
|
|
|
*/
|
2020-12-27 02:55:13 +00:00
|
|
|
|
enum Level {
|
|
|
|
|
UNSET = 0;
|
|
|
|
|
CRITICAL = 50;
|
|
|
|
|
ERROR = 40;
|
|
|
|
|
WARNING = 30;
|
|
|
|
|
INFO = 20;
|
|
|
|
|
DEBUG = 10;
|
|
|
|
|
TRACE = 5;
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-20 23:15:52 +00:00
|
|
|
|
string message = 1;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* Seconds since 1970 - or 0 for unknown/unset
|
|
|
|
|
*/
|
2020-12-27 02:55:13 +00:00
|
|
|
|
fixed32 time = 2;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* Usually based on thread name - if known
|
|
|
|
|
*/
|
2020-12-27 02:55:13 +00:00
|
|
|
|
string source = 3;
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* Not yet set
|
|
|
|
|
*/
|
2020-12-27 02:55:13 +00:00
|
|
|
|
Level level = 4;
|
2020-04-20 23:15:52 +00:00
|
|
|
|
}
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* Packets from the radio to the phone will appear on the fromRadio characteristic.
|
|
|
|
|
* It will support READ and NOTIFY. When a new packet arrives the device will BLE notify?
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* It will sit in that descriptor until consumed by the phone,
|
|
|
|
|
* at which point the next item in the FIFO will be populated.
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2020-03-02 17:47:10 +00:00
|
|
|
|
message FromRadio {
|
2021-01-29 02:11:10 +00:00
|
|
|
|
|
2021-02-17 05:05:46 +00:00
|
|
|
|
/* In the <1.2 versions packet had ID 2, to prevent confusing old apps with our new packets, we've changed */
|
|
|
|
|
reserved 2;
|
2021-03-02 03:45:16 +00:00
|
|
|
|
/* In the <1.2 versions nodeinfo had ID 4, to prevent confusing old apps with our new packets, we've changed */
|
|
|
|
|
reserved 6;
|
2021-02-17 05:05:46 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
2021-02-23 23:15:20 +00:00
|
|
|
|
* The packet num, used to allow the phone to request missing read packets from the FIFO,
|
|
|
|
|
* see our bluetooth docs
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2020-03-24 20:12:25 +00:00
|
|
|
|
uint32 num = 1;
|
|
|
|
|
|
2021-02-02 10:22:25 +00:00
|
|
|
|
oneof payloadVariant {
|
2021-01-29 02:11:10 +00:00
|
|
|
|
|
2021-02-17 05:05:46 +00:00
|
|
|
|
MeshPacket packet = 11;
|
2020-03-24 20:12:25 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* Tells the phone what our node number is, can be -1 if we've not yet joined a mesh.
|
2021-03-02 03:45:16 +00:00
|
|
|
|
* NOTE: This ID must not change - to keep (minimal) compatibility with <1.2 version of android apps.
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2020-04-20 23:15:52 +00:00
|
|
|
|
MyNodeInfo my_info = 3;
|
2020-03-24 20:12:25 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* One packet is sent for each node in the on radio DB
|
2021-03-02 03:45:16 +00:00
|
|
|
|
* starts over with the first node in our DB
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2021-03-02 04:44:29 +00:00
|
|
|
|
NodeInfo node_info = 4;
|
2020-04-20 23:15:52 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* set to send debug console output over our protobuf stream
|
|
|
|
|
*/
|
2020-12-27 02:55:13 +00:00
|
|
|
|
LogRecord log_record = 7;
|
2020-04-20 23:15:52 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* sent as true once the device has finished sending all of the responses to want_config
|
|
|
|
|
* recipient should check if this ID matches our original request nonce, if
|
|
|
|
|
* not, it means your config responses haven't started yet.
|
2021-03-02 03:45:16 +00:00
|
|
|
|
* NOTE: This ID must not change - to keep (minimal) compatibility with <1.2 version of android apps.
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2020-04-21 02:31:09 +00:00
|
|
|
|
uint32 config_complete_id = 8;
|
2020-04-29 00:34:06 +00:00
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* Sent to tell clients the radio has just rebooted. Set to true if present.
|
|
|
|
|
* Not used on all transports, currently just used for the serial console.
|
2021-03-02 03:45:16 +00:00
|
|
|
|
* NOTE: This ID must not change - to keep (minimal) compatibility with <1.2 version of android apps.
|
2021-01-29 02:11:10 +00:00
|
|
|
|
*/
|
2020-04-29 00:34:06 +00:00
|
|
|
|
bool rebooted = 9;
|
2020-03-24 20:12:25 +00:00
|
|
|
|
}
|
2020-03-02 17:47:10 +00:00
|
|
|
|
}
|
2021-02-16 07:41:05 +00:00
|
|
|
|
|
|
|
|
|
|
2021-01-29 02:11:10 +00:00
|
|
|
|
/*
|
|
|
|
|
* packets/commands to the radio will be written (reliably) to the toRadio characteristic.
|
|
|
|
|
* Once the write completes the phone can assume it is handled.
|
|
|
|
|
*/
|
2020-03-02 17:47:10 +00:00
|
|
|
|
message ToRadio {
|
|
|
|
|
|
2021-03-02 03:45:16 +00:00
|
|
|
|
/* In the <1.2 versions packet had ID 2, to prevent confusing old apps with our new packets, we've changed.
|
|
|
|
|
101-103 were used for set_radio, set_owner, set_channel
|
|
|
|
|
*/
|
|
|
|
|
reserved 1, 101, 102, 103;
|
2021-02-16 07:41:05 +00:00
|
|
|
|
|
2021-02-02 10:22:25 +00:00
|
|
|
|
oneof payloadVariant {
|
2021-01-29 02:11:10 +00:00
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* send this packet on the mesh
|
|
|
|
|
*/
|
2021-02-17 05:05:46 +00:00
|
|
|
|
MeshPacket packet = 2;
|
2021-01-29 02:11:10 +00:00
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* phone wants radio to send full node db to the phone, This is
|
|
|
|
|
* typically the first packet sent to the radio when the phone gets a
|
|
|
|
|
* bluetooth connection. The radio will respond by sending back a
|
|
|
|
|
* MyNodeInfo, a owner, a radio config and a series of
|
|
|
|
|
* FromRadio.node_infos, and config_complete
|
|
|
|
|
* the integer you write into this field will be reported back in the
|
|
|
|
|
* config_complete_id response this allows clients to never be confused by
|
|
|
|
|
* a stale old partially sent config.
|
|
|
|
|
*/
|
2020-04-21 02:31:09 +00:00
|
|
|
|
uint32 want_config_id = 100;
|
2021-02-21 06:03:13 +00:00
|
|
|
|
}
|
|
|
|
|
}
|