syntax = "proto3"; /** 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 */ option java_package = "com.geeksville.mesh"; option java_outer_classname = "MeshProtos"; option optimize_for = LITE_RUNTIME; import "portnums.proto"; /** a gps position */ message Position { /** The new preferred location encoding, divide by 1e-7 to get degrees in * floating point */ sint32 latitude_i = 7; sint32 longitude_i = 8; /** In meters above MSL */ int32 altitude = 3; /** 1-100 (0 means not provided) */ int32 battery_level = 4; /// 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 fixed32 time = 9; } // a data message to forward to an external app (or possibly also be consumed // internally in the case of CLEAR_TEXT and CLEAR_READACK) message Data { // formerly named typ and of type Type PortNum portnum = 1; bytes payload = 2; // required } /* 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 node db) * 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 */ message User { // a globally unique ID string for this user. In the case of // Signal that would mean +16504442323, for the default macaddr // derived id it would be !<6 hexidecimal bytes> string id = 1; // A full name for this user, i.e. "Kevin Hester" string long_name = 2; // A VERY short name, ideally two characters. Suitable // for a tiny OLED screen string short_name = 3; // This is the addr of the radio. Not populated by the // phone, but added by the esp32 when broadcasting bytes macaddr = 4; } /// A message used in our Dynamic Source Routing protocol (RFC 4728 based) message RouteDiscovery { /** The list of nodes this packet has visited so far */ repeated int32 route = 2; } enum RouteError { NONE = 0; // Our node doesn't have a route to the requested destination anymore. NO_ROUTE = 1; // We received a nak while trying to forward on your behalf GOT_NAK = 2; TIMEOUT = 3; } // 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 { // Only one of the following fields can be populated at a time oneof payload { /// Prior to 1.20 positions were communicated as a special payload type, now they are GPS_POSITION_APP Data Position position = 1 [deprecated = true]; Data data = 3; /// Prior to 1.20 positions were communicated as a special payload type, now they are MESH_USERINFO_APP User user = 4 [deprecated = true]; /** A route request going from the requester */ RouteDiscovery route_request = 6; /** A route reply */ RouteDiscovery route_reply = 7; /** A failure in a routed message */ RouteError route_error = 13; } // 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 // its position). // Note: that if you set this on a broadcast you will receive many replies. bool want_response = 5; oneof ack { /** 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. */ uint32 success_id = 10; /** This is a nak, we failed to deliver this message. */ uint32 fail_id = 11; } /** The address of the destination node. This field is is filled in by the mesh radio device software, applicaiton layer software should never need it. RouteDiscovery messages _must_ populate this. Other message types might need to if they are doing multihop routing. */ uint32 dest = 9; /** The address of the original sender for this message. This field should _only_ be populated for reliable multihop packets (to keep packets small). */ uint32 source = 12; /** Only used in route_error messages. Indicates the original message ID that this message is reporting failure on. */ uint32 original_id = 2; } // A full packet sent/received over the mesh // Note: For simplicity reasons (and that we want to keep over the radio packets // very small, we now assume that there is only _one_ SubPacket in each // MeshPacket). message MeshPacket { /** 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. */ uint32 from = 1; /** The (immediate) destination for this packet. If we are using routing, the final destination will be in payload.dest FIXME - really should be fixed32 instead, this encoding only hurts the ble link though. */ uint32 to = 2; /** If set, this indicates the index in the secondary_channels table that this packet was sent/received on. If unset, packet was on the primary channel. */ uint32 channel_index = 4; /** 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. */ oneof payload { SubPacket decoded = 3; bytes encrypted = 8; } /** 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. */ uint32 id = 6; /// 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) fixed32 rx_time = 9; /// *Never* sent over the radio links. Set during reception to indicate the /// SNR /// of this packet. Used to collect statistics on current link waulity. float rx_snr = 7; /** If unset treated as zero (no fowarding, send to adjacent nodes only) 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. */ uint32 hop_limit = 10; /** 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 packet (because naive flooding algoritm). If it hears that the odds (given 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 */ bool want_ack = 11; } /// Shared constants between device and phone enum Constants { // First enum must be zero, and we are just using this enum to // pass int constants between two very different environments Unused = 0; /** From mesh.options note: this payload length is ONLY the bytes that are sent inside of the radiohead packet Data.payload max_size:240 */ DATA_PAYLOAD_LEN = 240; } /** Full settings (center freq, spread factor, pre-shared secret key etc...) needed to configure a radio for speaking on a particlar channel This information can be encoded as a QRcode/url so that other users can configure their radio to join the same channel. A note aboute how channel names are shown to users: channelname-Xy poundsymbol is a prefix used to indicate this is a channel name (idea from @professr). Where X is a letter from A-Z (base 26) representing a hash of the PSK for this channel - so that if the user changes anything about the channel (which does force a new PSK) this letter will also change. Thus preventing user confusion if two friends try to type in a channel name of "BobsChan" and then can't talk because their PSKs will be different. The PSK is hashed into this letter by "0x41 + [xor all bytes of the psk ] modulo 26" This also allows the option of someday if people have the PSK off (zero), the users COULD type in a channel name and be able to talk. Y is a lower case letter from a-z that represents the channel 'speed' settings (for some future definition of speed) */ message ChannelSettings { /** If zero then, use default max legal continuous power (ie. something that won't burn out the radio hardware) In most cases you should use zero here. */ int32 tx_power = 1; /** Standard predefined channel settings Note: these mappings must match ModemConfigChoice in the device code. */ enum ModemConfig { Bw125Cr45Sf128 = 0 ; // < Bw = 125 kHz, Cr = 4/5, Sf = 128chips/symbol, CRC // < on. Medium range // The english default channel name for this setting is "Medium" Bw500Cr45Sf128 = 1; // < Bw = 500 kHz, Cr = 4/5, Sf = 128chips/symbol, CRC // < on. Fast+short range // The english default channel name for this setting is "ShortFast" Bw31_25Cr48Sf512 = 2; // < Bw = 31.25 kHz, Cr = 4/8, Sf = 512chips/symbol, ///< CRC on. Slow+long range // The english default channel name for this setting is "LongAlt" Bw125Cr48Sf4096 = 3; // < Bw = 125 kHz, Cr = 4/8, Sf = 4096chips/symbol, CRC // < on. Slow+long range **This is the default channel settting** // The english default channel name for this setting is "LongSlow" // If old applications try to set the name to "Default" we will change it to "LongSlow" } // Note: This is the 'old' mechanism for specifying channel parameters. // Either modem_config or bandwidth/spreading/coding will be specified - NOT // BOTH. As a heuristic: If bandwidth is specified, do not use modem_config. // Because protobufs take ZERO space when the value is zero this works out // nicely. // This value is replaced by bandwidth/spread_factor/coding_rate. If you'd // like to experiment with other options add them to MeshRadio.cpp in the // device code. ModemConfig modem_config = 3; /** Bandwidth in MHz Certain bandwidth numbers are 'special' and will be converted to the appropriate floating point value: 31 -> 31.25MHz */ uint32 bandwidth = 6; /** A number from 7 to 12. Indicates number of chirps per symbol as 1< 512 bytes (to big for BLE) */ repeated ChannelSettings secondary_channels = 12; } /** Debug output from the device. To minimize the size of records inside the device code, if a time/source/level is not set on the message it is assumed to be a contuinuation 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. */ message LogRecord { /** Log levels, chosen to match python logging conventions. */ enum Level { UNSET = 0; CRITICAL = 50; ERROR = 40; WARNING = 30; INFO = 20; DEBUG = 10; TRACE = 5; } string message = 1; /** Seconds since 1970 - or 0 for unknown/unset */ fixed32 time = 2; /** Usually based on thread name - if known */ string source = 3; /** Not yet set */ Level level = 4; } // 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? it will sit in that // descriptor until consumed by the phone, at which point the next item in the // FIFO will be populated. message FromRadio { // The packet num, used to allow the phone to request missing read packets // from the FIFO, see our bluetooth docs uint32 num = 1; oneof variant { MeshPacket packet = 2; // Tells the phone what our node number is, can be -1 if we've not yet // joined a mesh. MyNodeInfo my_info = 3; // One packet is sent for each node in the on radio DB // starts over with the first node in our DB NodeInfo node_info = 4; // In rev1 this was the radio BLE characteristic RadioConfig radio = 6; // set to send debug console output over our protobuf stream LogRecord log_record = 7; // 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 uint32 config_complete_id = 8; // 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. bool rebooted = 9; // One of the secondary channels, they are all sent during config download ChannelSettings secondary_channel = 10; } } // packets/commands to the radio will be written (reliably) to the toRadio // characteristic. Once the write completes the phone can assume it is handled. message ToRadio { oneof variant { MeshPacket packet = 1; // send this packet on the mesh /** 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. */ uint32 want_config_id = 100; // set the radio provisioning for this node RadioConfig set_radio = 101; // Set the owner for this node User set_owner = 102; } }