From 0cd66bf5277352783697ee81fb34b0ee735aee2a Mon Sep 17 00:00:00 2001 From: Sacha Weatherstone Date: Sun, 13 Dec 2020 19:19:41 +1100 Subject: [PATCH 01/32] Fix comment formatting --- mesh.proto | 1276 +++++++++++++++++++++++------------------ notused/future.proto | 44 +- portnums.proto | 119 ++-- remote_hardware.proto | 66 ++- 4 files changed, 863 insertions(+), 642 deletions(-) diff --git a/mesh.proto b/mesh.proto index d87965e..ab6ca9e 100644 --- a/mesh.proto +++ b/mesh.proto @@ -1,27 +1,23 @@ 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 - -*/ +/* + * 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"; @@ -29,26 +25,35 @@ option optimize_for = LITE_RUNTIME; import "portnums.proto"; -/** a gps position -*/ +/* + * a gps position + */ message Position { - /** The new preferred location encoding, divide by 1e-7 to get degrees in - * floating point */ + /* + * 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 */ + /* + * In meters above MSL + */ int32 altitude = 3; - /** 1-100 (0 means not provided) */ + /* + * 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 + /* + * 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; } @@ -56,372 +61,418 @@ message Position { // internally in the case of CLEAR_TEXT and CLEAR_READACK) message Data { - // formerly named typ and of type Type + /* + * Formerly named typ and of type Type + */ PortNum portnum = 1; - bytes payload = 2; // required + /* + * Required + */ + bytes payload = 2; } -/* 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 - -*/ +/* + * 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 + */ 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> + /* + * 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" + /* + * 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 + /* + * 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 + /* + * 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) +/* + * A message used in our Dynamic Source Routing protocol (RFC 4728 based) + */ message RouteDiscovery { - /** - The list of nodes this packet has visited so far + /* + * 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. + /* + * 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 + /* + * 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) +/* + * 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 + /* + * 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 + /* + * 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 + /* + * 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 - */ + /* + * A route request going from the requester + */ RouteDiscovery route_request = 6; - /** - A route reply - */ + /* + * A route reply + */ RouteDiscovery route_reply = 7; - /** - A failure in a routed message - */ + /* + * 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. + /* + * 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. + */ 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. - */ + /* + * 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. + /* + * 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. - */ + /* + * 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). - */ + /* + * 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. - */ + /* + * 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). +/* + * 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. - */ + /* + * 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. - */ + /* + * 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; - /** - 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. - */ + /* + * 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. - */ + /* + * 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) + /* + * 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. + /* + * *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. - */ + /* + * 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 - */ + /* + * 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 +/* + * 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 + /* + * 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 - */ + /* + * 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) -*/ +/* + * 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. - */ + /* + * 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. - */ + /* + * 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(7) = 128chips/symbol, CRC - // < on. Default medium range (5.469 kbps) - Bw500Cr45Sf128 = 1; // < Bw = 500 kHz, Cr = 4/5, Sf(7) = 128chips/symbol, CRC - // < on. Fast+short range (21.875 kbps) + /* + * < Bw = 125 kHz, Cr = 4/5, Sf(7) = 128chips/symbol, CRC + * < on. Default medium range (5.469 kbps) + */ + Bw125Cr45Sf128 = 0; - Bw31_25Cr48Sf512 = 2; // < Bw = 31.25 kHz, Cr = 4/8, Sf(9) = 512chips/symbol, - ///< CRC on. Slow+long range (275 bps) - - Bw125Cr48Sf4096 = 3; // < Bw = 125 kHz, Cr = 4/8, Sf(12) = 4096chips/symbol, CRC - // < on. Slow+long range (183 bps) + /* + * < Bw = 500 kHz, Cr = 4/5, Sf(7) = 128chips/symbol, CRC + * < on. Fast+short range (21.875 kbps) + */ + Bw500Cr45Sf128 = 1; + + /* + * < Bw = 31.25 kHz, Cr = 4/8, Sf(9) = 512chips/symbol, + * < CRC on. Slow+long range (275 bps) + */ + Bw31_25Cr48Sf512 = 2; + + /* + * < Bw = 125 kHz, Cr = 4/8, Sf(12) = 4096chips/symbol, CRC + * < on. Slow+long range (183 bps) + */ + Bw125Cr48Sf4096 = 3; } - /// 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. + /* + * 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 [deprecated = true]; - /** - Bandwidth in MHz - Certain bandwidth numbers are 'special' and will be converted to the - appropriate floating point value: 31 -> 31.25MHz - */ + /* + * 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<= 256. To simplify initial development and testing you can use "PRIVATE_APP" - in your code without needing to rebuild protobuf files (via bin/regin_protos.sh) */ + /* + * Private applications should use portnums >= 256. To simplify initial development and testing you can use "PRIVATE_APP" + * in your code without needing to rebuild protobuf files (via bin/regin_protos.sh) + */ PRIVATE_APP = 256; - /** 1024-66559 Are reserved for use by IP tunneling (see FIXME for more information) */ + /* + * 1024-66559 Are reserved for use by IP tunneling (see FIXME for more information) + */ IP_TUNNEL_APP = 1024; } \ No newline at end of file diff --git a/remote_hardware.proto b/remote_hardware.proto index 02f53ef..eef3471 100644 --- a/remote_hardware.proto +++ b/remote_hardware.proto @@ -4,49 +4,65 @@ option java_package = "com.geeksville.mesh"; option java_outer_classname = "RemoteHardware"; option optimize_for = LITE_RUNTIME; -/** A example app to show off the plugin system. This message is used for REMOTE_HARDWARE_APP PortNums. - -Also provides easy remote access to any GPIO. - -In the future other remote hardware operations can be added based on user interest -(i.e. serial output, spi/i2c input/output). - -FIXME - currently this feature is turned on by default which is dangerous because no security yet (beyond the -channel mechanism). It should be off by default and then protected based on some TBD mechanism (a special channel -once multichannel support is included?) -*/ +/* A example app to show off the plugin system. This message is used for REMOTE_HARDWARE_APP PortNums. + * + * Also provides easy remote access to any GPIO. + * + * In the future other remote hardware operations can be added based on user interest (i.e. serial output, spi/i2c input/output). + * + * FIXME - currently this feature is turned on by default which is dangerous because no security yet (beyond the channel mechanism). + * It should be off by default and then protected based on some TBD mechanism (a special channel once multichannel support is included?) + */ message HardwareMessage { enum Type { - /** Unset/unused */ + + /* + * Unset/unused + */ UNSET = 0; - /** Set gpio gpios based on gpio_mask/gpio_value */ + /* + * Set gpio gpios based on gpio_mask/gpio_value + */ WRITE_GPIOS = 1; - /** We are now interested in watching the gpio_mask gpios. If the selected gpios change, please broadcast - GPIOS_CHANGED. - - Will implicitly change the gpios requested to be INPUT gpios. - */ + /* + * We are now interested in watching the gpio_mask gpios. + * If the selected gpios change, please broadcast GPIOS_CHANGED. + * + * Will implicitly change the gpios requested to be INPUT gpios. + */ WATCH_GPIOS = 2; - /** The gpios listed in gpio_mask have changed, the new values are listed in gpio_value */ + /* + * The gpios listed in gpio_mask have changed, the new values are listed in gpio_value + */ GPIOS_CHANGED = 3; - /** Read the gpios specified in gpio_mask, send back a READ_GPIOS_REPLY reply with gpio_value populated */ + /* + * Read the gpios specified in gpio_mask, send back a READ_GPIOS_REPLY reply with gpio_value populated + */ READ_GPIOS = 4; - /** A reply to READ_GPIOS. gpio_mask and gpio_value will be populated */ + /* + * A reply to READ_GPIOS. gpio_mask and gpio_value will be populated + */ READ_GPIOS_REPLY = 5; } - /** What type of HardwareMessage is this? */ + /* + * What type of HardwareMessage is this? + */ Type typ = 1; - /** What gpios are we changing. Not used for all MessageTypes, see MessageType for details */ + /* + * What gpios are we changing. Not used for all MessageTypes, see MessageType for details + */ uint64 gpio_mask = 2; - /** For gpios that were listed in gpio_mask as valid, what are the signal levels for those gpios. - Not used for all MessageTypes, see MessageType for details */ + /* + * For gpios that were listed in gpio_mask as valid, what are the signal levels for those gpios. + * Not used for all MessageTypes, see MessageType for details + */ uint64 gpio_value = 3; } From e7ab73e2a9f74b67a0e57eb58fe59f4d22a9c706 Mon Sep 17 00:00:00 2001 From: Kevin Hester Date: Sun, 27 Dec 2020 10:55:13 +0800 Subject: [PATCH 02/32] Clean up LogRecord --- docs/docs.md | 60 +++++++++++++++++++++++++++++++++++++--------------- mesh.options | 3 +++ mesh.proto | 33 +++++++++++++++++++++++++---- 3 files changed, 75 insertions(+), 21 deletions(-) diff --git a/docs/docs.md b/docs/docs.md index cc03cbf..51571fd 100644 --- a/docs/docs.md +++ b/docs/docs.md @@ -6,9 +6,9 @@ - [mesh.proto](#mesh.proto) - [ChannelSettings](#.ChannelSettings) - [Data](#.Data) - - [DebugString](#.DebugString) - [DeviceState](#.DeviceState) - [FromRadio](#.FromRadio) + - [LogRecord](#.LogRecord) - [MeshPacket](#.MeshPacket) - [MyNodeInfo](#.MyNodeInfo) - [NodeInfo](#.NodeInfo) @@ -24,6 +24,7 @@ - [Constants](#.Constants) - [GpsOperation](#.GpsOperation) - [LocationSharing](#.LocationSharing) + - [LogRecord.Level](#.LogRecord.Level) - [RegionCode](#.RegionCode) - [RouteError](#.RouteError) @@ -120,21 +121,6 @@ internally in the case of CLEAR_TEXT and CLEAR_READACK) - - -### DebugString -Debug output from the device - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| message | [string](#string) | | | - - - - - - ### DeviceState @@ -182,7 +168,7 @@ FIFO will be populated. | my_info | [MyNodeInfo](#MyNodeInfo) | | Tells the phone what our node number is, can be -1 if we've not yet joined a mesh. | | node_info | [NodeInfo](#NodeInfo) | | One packet is sent for each node in the on radio DB starts over with the first node in our DB | | radio | [RadioConfig](#RadioConfig) | | In rev1 this was the radio BLE characteristic | -| debug_string | [DebugString](#DebugString) | | set to send debug console output over our protobuf stream | +| log_record | [LogRecord](#LogRecord) | | set to send debug console output over our protobuf stream | | config_complete_id | [uint32](#uint32) | | 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 | | rebooted | [bool](#bool) | | 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. | | secondary_channel | [ChannelSettings](#ChannelSettings) | | One of the secondary channels, they are all sent during config download | @@ -192,6 +178,29 @@ FIFO will be populated. + + +### LogRecord +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. + + +| Field | Type | Label | Description | +| ----- | ---- | ----- | ----------- | +| message | [string](#string) | | | +| time | [fixed32](#fixed32) | | Seconds since 1970 - or 0 for unknown/unset | +| source | [string](#string) | | Usually based on thread name - if known | +| level | [LogRecord.Level](#LogRecord.Level) | | Not yet set | + + + + + + ### MeshPacket @@ -508,6 +517,23 @@ How our location is shared with other nodes (or the local phone) + + +### LogRecord.Level +Log levels, chosen to match python logging conventions. + +| Name | Number | Description | +| ---- | ------ | ----------- | +| UNSET | 0 | | +| CRITICAL | 50 | | +| ERROR | 40 | | +| WARNING | 30 | | +| INFO | 20 | | +| DEBUG | 10 | | +| TRACE | 5 | | + + + ### RegionCode diff --git a/mesh.options b/mesh.options index 3c09977..2492e18 100644 --- a/mesh.options +++ b/mesh.options @@ -45,6 +45,9 @@ # Max of three ignored nodes for our testing *UserPreferences.ignore_incoming max_count:3 +*LogRecord.message max_size:64 +*LogRecord.source max_size:8 + # MyMessage.name max_size:40 # or fixed_length or fixed_count, or max_count diff --git a/mesh.proto b/mesh.proto index f1fef18..64832dc 100644 --- a/mesh.proto +++ b/mesh.proto @@ -816,11 +816,36 @@ message DeviceState { repeated ChannelSettings secondary_channels = 12; } -/// Debug output from the device -message DebugString { +/** 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; - // eventually we might add source and level + /** 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 @@ -848,7 +873,7 @@ message FromRadio { RadioConfig radio = 6; // set to send debug console output over our protobuf stream - DebugString debug_string = 7; + LogRecord log_record = 7; // sent as true once the device has finished sending all of the // responses to want_config From 72f29307090c0283ec197e322a0cc784ae8337e9 Mon Sep 17 00:00:00 2001 From: Kevin Hester Date: Sun, 27 Dec 2020 10:55:59 +0800 Subject: [PATCH 03/32] update docs --- docs/docs.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/docs.md b/docs/docs.md index 51571fd..1c629f6 100644 --- a/docs/docs.md +++ b/docs/docs.md @@ -339,7 +339,7 @@ see sw-design.md for more information on these preferences | wifi_ap_mode | [bool](#bool) | | If set, the node will operate as an AP (and DHCP server), otherwise it will be a station | | region | [RegionCode](#RegionCode) | | The region code for my radio (US, CN, EU433, etc...) | | is_router | [bool](#bool) | | Are we operating as a router. Changes behavior in the following ways: The device will only sleep for critically low battery level (i.e. always tries to stay alive for the mesh) In the future routing decisions will preferentially route packets through nodes with this attribute (because assumed good line of sight) | -| is_low_power | [bool](#bool) | | If set, we are powered from a low-current source (i.e. solar), so even if it looks like we have power flowing in we should try to minimize power consumption as much as possible. Often combined with is_router. | +| is_low_power | [bool](#bool) | | If set, we are powered from a low-current source (i.e. solar), so even if it looks like we have power flowing in we should try to minimize power consumption as much as possible. YOU DO NOT NEED TO SET THIS IF YOU'VE set is_router (it is implied in that case). | | fixed_position | [bool](#bool) | | If set, this node is at a fixed position. We will generate GPS position updates at the regular interval, but use whatever the last lat/lon/alt we have for the node. The lat/lon/alt can be set by an internal GPS or with the help of the app. | | factory_reset | [bool](#bool) | | This setting is never saved to disk, but if set, all device settings will be returned to factory defaults. (Region, serial number etc... will be preserved) | | debug_log_enabled | [bool](#bool) | | By default we turn off logging as soon as an API client connects (to keep shared serial link quiet). Set this to true to leave the debug log outputting even when API is active. | @@ -603,7 +603,6 @@ master table. PortNums should be assigned in the following range: 64-127 Registered 3rd party apps, send in a pull request that adds a new entry to portnums.proto to register your application 256-511 Use one of these portnums for your private applications that you don't want to register publically -1024-66559 Are reserved for use by IP tunneling (see FIXME for more information) All other values are reserved. @@ -620,8 +619,8 @@ This change is backwards compatible by treating the legacy OPAQUE/CLEAR_TEXT val | POSITION_APP | 3 | The built-in position messaging app. See Position for details on the message sent to this port number. | | NODEINFO_APP | 4 | The built-in user info app. See User for details on the message sent to this port number. | | REPLY_APP | 32 | Provides a 'ping' service that replies to any packet it receives. Also this serves as a small example plugin. | +| IP_TUNNEL_APP | 33 | Used for the python IP tunnel feature | | PRIVATE_APP | 256 | Private applications should use portnums >= 256. To simplify initial development and testing you can use "PRIVATE_APP" in your code without needing to rebuild protobuf files (via bin/regin_protos.sh) | -| IP_TUNNEL_APP | 1024 | 1024-66559 Are reserved for use by IP tunneling (see FIXME for more information) | From 9a7d8a03cb051eb42787d4a06836b109677d8ef1 Mon Sep 17 00:00:00 2001 From: Kevin Hester Date: Sun, 27 Dec 2020 11:07:58 +0800 Subject: [PATCH 04/32] move error code defs to .proto so that other platforms can easily parse --- docs/docs.md | 23 ++++++++++++++++++++++- mesh.proto | 29 ++++++++++++++++++++++++++++- 2 files changed, 50 insertions(+), 2 deletions(-) diff --git a/docs/docs.md b/docs/docs.md index 1c629f6..ff2a1a5 100644 --- a/docs/docs.md +++ b/docs/docs.md @@ -22,6 +22,7 @@ - [ChannelSettings.ModemConfig](#.ChannelSettings.ModemConfig) - [Constants](#.Constants) + - [CriticalErrorCode](#.CriticalErrorCode) - [GpsOperation](#.GpsOperation) - [LocationSharing](#.LocationSharing) - [LogRecord.Level](#.LogRecord.Level) @@ -246,7 +247,7 @@ Sent to the phone in response to WantNodes. | region | [string](#string) | | 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. | | hw_model | [string](#string) | | TBEAM, HELTEC, etc... | | firmware_version | [string](#string) | | 0.0.5 etc... | -| error_code | [uint32](#uint32) | | An error message we'd like to report back to the mothership through / analytics. 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) a numeric error code to go with error message, zero / means no error | +| error_code | [CriticalErrorCode](#CriticalErrorCode) | | An error message we'd like to report back to the mothership through / analytics. 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) a numeric error code to go with error message, zero / means no error | | error_address | [uint32](#uint32) | | A numeric error address (nonzero if available) | | error_count | [uint32](#uint32) | | The total number of errors this node has ever encountered (well - since / the last time we discarded preferences) | | packet_id_bits | [uint32](#uint32) | | How many bits are used for the packetid. If zero it is assumed we use eight bit packetids Old device loads (older that 0.6.5 do not populate this field, but all newer loads do). | @@ -488,6 +489,26 @@ Shared constants between device and phone + + +### CriticalErrorCode +Error codes for critical errors + +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. + +| Name | Number | Description | +| ---- | ------ | ----------- | +| None | 0 | | +| TxWatchdog | 1 | A software bug was detected while trying to send lora | +| SleepEnterWait | 2 | A software bug was detected on entry to sleep | +| NoRadio | 3 | No Lora radio hardware could be found | +| Unspecified | 4 | Not normally used | +| UBloxInitFailed | 5 | We failed while configuring a UBlox GPS | +| NoAXP192 | 6 | This board was expected to have a power management chip and it is missing or broken | + + + ### GpsOperation diff --git a/mesh.proto b/mesh.proto index 2ba394a..f07da44 100644 --- a/mesh.proto +++ b/mesh.proto @@ -681,6 +681,33 @@ message NodeInfo { uint32 next_hop = 5; } +/** Error codes for critical errors + * + * 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. + */ +enum CriticalErrorCode { + None = 0; + + /// A software bug was detected while trying to send lora + TxWatchdog = 1; + + /// A software bug was detected on entry to sleep + SleepEnterWait = 2; + + /// No Lora radio hardware could be found + NoRadio = 3; + + /// Not normally used + Unspecified = 4; + + /// We failed while configuring a UBlox GPS + UBloxInitFailed = 5; + + /// This board was expected to have a power management chip and it is missing or broken + NoAXP192 = 6; +} + /** Unique local debugging info for this node @@ -725,7 +752,7 @@ message MyNodeInfo { /// field will be cleared after the phone reads MyNodeInfo (i.e. it will only /// be reported once) a numeric error code to go with error message, zero /// means no error - uint32 error_code = 7; + CriticalErrorCode error_code = 7; /// A numeric error address (nonzero if available) uint32 error_address = 8; From 323b814f4392ae0f9c42a0f14557c6b9333efce3 Mon Sep 17 00:00:00 2001 From: Kevin Hester Date: Sun, 27 Dec 2020 13:07:46 +0800 Subject: [PATCH 05/32] add InvalidRadioSetting critical fault in support of https://github.com/meshtastic/Meshtastic-device/issues/577 --- docs/docs.md | 1 + mesh.proto | 16 ++++++++++------ 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/docs/docs.md b/docs/docs.md index ff2a1a5..5400f54 100644 --- a/docs/docs.md +++ b/docs/docs.md @@ -506,6 +506,7 @@ post on the meshtastic.discourse.group and we'll try to help. | Unspecified | 4 | Not normally used | | UBloxInitFailed | 5 | We failed while configuring a UBlox GPS | | NoAXP192 | 6 | This board was expected to have a power management chip and it is missing or broken | +| InvalidRadioSetting | 7 | The channel tried to set a radio setting which is not supported by this chipset, radio comms settings are now undefined. | diff --git a/mesh.proto b/mesh.proto index f07da44..c53d2e5 100644 --- a/mesh.proto +++ b/mesh.proto @@ -689,23 +689,27 @@ message NodeInfo { enum CriticalErrorCode { None = 0; - /// A software bug was detected while trying to send lora + // A software bug was detected while trying to send lora TxWatchdog = 1; - /// A software bug was detected on entry to sleep + // A software bug was detected on entry to sleep SleepEnterWait = 2; - /// No Lora radio hardware could be found + // No Lora radio hardware could be found NoRadio = 3; - /// Not normally used + // Not normally used Unspecified = 4; - /// We failed while configuring a UBlox GPS + // We failed while configuring a UBlox GPS UBloxInitFailed = 5; - /// This board was expected to have a power management chip and it is missing or broken + // This board was expected to have a power management chip and it is missing or broken NoAXP192 = 6; + + // The channel tried to set a radio setting which is not supported by this chipset, + // radio comms settings are now undefined. + InvalidRadioSetting = 7; } /** From 5a23071d2363725ca954562f00bfca0d5717ca79 Mon Sep 17 00:00:00 2001 From: Kevin Hester Date: Mon, 28 Dec 2020 13:12:14 +0800 Subject: [PATCH 06/32] move device only code into a separate file --- deviceonly.options | 11 +++++ deviceonly.proto | 50 +++++++++++++++++++++++ docs/docs.md | 100 ++++++++++++++++++++++++++++----------------- mesh.options | 8 ---- mesh.proto | 99 ++++++++++++++++++++------------------------ 5 files changed, 169 insertions(+), 99 deletions(-) create mode 100644 deviceonly.options create mode 100644 deviceonly.proto diff --git a/deviceonly.options b/deviceonly.options new file mode 100644 index 0000000..e8fb491 --- /dev/null +++ b/deviceonly.options @@ -0,0 +1,11 @@ +# options for nanopb +# https://jpa.kapsi.fi/nanopb/docs/reference.html#proto-file-options + +# FIXME pick a higher number someday? or do dynamic alloc in nanopb? +*DeviceState.node_db max_count:32 + +# FIXME - max_count is actually 32 but we save/load this as one long string of preencoded MeshPacket bytes - not a big array in RAM +*DeviceState.receive_queue max_count:1 + +*DeviceState.secondary_channels max_count:4 + diff --git a/deviceonly.proto b/deviceonly.proto new file mode 100644 index 0000000..c08982c --- /dev/null +++ b/deviceonly.proto @@ -0,0 +1,50 @@ +syntax = "proto3"; + +option java_package = "com.geeksville.mesh"; +option java_outer_classname = "MeshProtos"; +option optimize_for = LITE_RUNTIME; + +import "mesh.proto"; + +// This message is never sent over the wire, but it is used for serializing DB +// state to flash in the device code +// FIXME, since we write this each time we enter deep sleep (and have infinite +// flash) it would be better to use some sort of append only data structure for +// the receive queue and use the preferences store for the other stuff +message DeviceState { + RadioConfig radio = 1; + + /// Read only settings/info about this node + MyNodeInfo my_node = 2; + + /// My owner info + User owner = 3; + + repeated NodeInfo node_db = 4; + + /// Received packets saved for delivery to the phone + repeated MeshPacket receive_queue = 5; + + /** A version integer used to invalidate old save files when we make + incompatible changes This integer is set at build time and is private to + NodeDB.cpp in the device code. */ + uint32 version = 8; + + // We keep the last received text message (only) stored in the device flash, + // so we can show it on the screen. Might be null + MeshPacket rx_text_message = 7; + + // Used only during development. Indicates developer is testing and changes + // should never be saved to flash. + bool no_save = 9; + + // Some GPSes seem to have bogus settings from the factory, so we always do + // one factory reset + bool did_gps_reset = 11; + + /** Secondary channels are only used for encryption/decryption/authentication purposes. Their radio settings (freq etc) + are ignored, only psk is used. + Note: this is not kept inside of RadioConfig because that would make ToRadio/FromRadio worse case > 512 bytes (to big for BLE) + */ + repeated ChannelSettings secondary_channels = 12; + } \ No newline at end of file diff --git a/docs/docs.md b/docs/docs.md index 5400f54..0195f4a 100644 --- a/docs/docs.md +++ b/docs/docs.md @@ -3,10 +3,12 @@ ## Table of Contents +- [deviceonly.proto](#deviceonly.proto) + - [DeviceState](#.DeviceState) + - [mesh.proto](#mesh.proto) - [ChannelSettings](#.ChannelSettings) - [Data](#.Data) - - [DeviceState](#.DeviceState) - [FromRadio](#.FromRadio) - [LogRecord](#.LogRecord) - [MeshPacket](#.MeshPacket) @@ -41,6 +43,50 @@ + +

Top

+ +## deviceonly.proto + + + + + +### DeviceState +This message is never sent over the wire, but it is used for serializing DB +state to flash in the device code +FIXME, since we write this each time we enter deep sleep (and have infinite +flash) it would be better to use some sort of append only data structure for +the receive queue and use the preferences store for the other stuff + + +| Field | Type | Label | Description | +| ----- | ---- | ----- | ----------- | +| radio | [RadioConfig](#RadioConfig) | | | +| my_node | [MyNodeInfo](#MyNodeInfo) | | Read only settings/info about this node | +| owner | [User](#User) | | My owner info | +| node_db | [NodeInfo](#NodeInfo) | repeated | | +| receive_queue | [MeshPacket](#MeshPacket) | repeated | Received packets saved for delivery to the phone | +| version | [uint32](#uint32) | | A version integer used to invalidate old save files when we make incompatible changes This integer is set at build time and is private to NodeDB.cpp in the device code. | +| rx_text_message | [MeshPacket](#MeshPacket) | | We keep the last received text message (only) stored in the device flash, so we can show it on the screen. Might be null | +| no_save | [bool](#bool) | | Used only during development. Indicates developer is testing and changes should never be saved to flash. | +| did_gps_reset | [bool](#bool) | | Some GPSes seem to have bogus settings from the factory, so we always do one factory reset | +| secondary_channels | [ChannelSettings](#ChannelSettings) | repeated | Secondary channels are only used for encryption/decryption/authentication purposes. Their radio settings (freq etc) are ignored, only psk is used. Note: this is not kept inside of RadioConfig because that would make ToRadio/FromRadio worse case > 512 bytes (to big for BLE) | + + + + + + + + + + + + + + +

Top

@@ -74,6 +120,7 @@ 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). @@ -88,6 +135,11 @@ 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) +FIXME: Add description of multi-channel support and how primary vs secondary channels +are used. +FIXME: explain how apps use channels for security. explain how remote settings and +remote gpio are managed as an example + | Field | Type | Label | Description | | ----- | ---- | ----- | ----------- | @@ -99,6 +151,9 @@ Y is a lower case letter from a-z that represents the channel 'speed' se | channel_num | [uint32](#uint32) | | A channel number between 1 and 13 (or whatever the max is in the current region). If ZERO then the rule is "use the old channel name hash based algoritm to derive the channel number") If using the hash algorithm the channel number will be: hash(channel_name) % NUM_CHANNELS (Where num channels depends on the regulatory region). NUM_CHANNELS_US is 13, for other values see MeshRadio.h in the device code. hash a string into an integer - djb2 by Dan Bernstein. - http://www.cse.yorku.ca/~oz/hash.html unsigned long hash(char *str) { unsigned long hash = 5381; int c; while ((c = *str++) != 0) hash = ((hash << 5) + hash) + (unsigned char) c; return hash; } | | psk | [bytes](#bytes) | | A simple preshared key for now for crypto. Must be either 0 bytes (no crypto), 16 bytes (AES128), or 32 bytes (AES256) A special shorthand is used for 1 byte long psks. These psks should be treated as only minimally secure, because they are listed in this source code. Those bytes are mapped using the following scheme: 0 = No crypto 1 = The special default channel key: {0xd4, 0xf1, 0xbb, 0x3a, 0x20, 0x29, 0x07, 0x59, 0xf0, 0xbc, 0xff, 0xab, 0xcf, 0x4e, 0x69, 0xbf} 2 through 10 = The default channel key, except with 1 through 9 added to the last byte | | name | [string](#string) | | A SHORT name that will be packed into the URL. Less than 12 bytes. Something for end users to call the channel If this is the empty string it is assumed that this channel is the special (minimially secure) "Default" channel. In user interfaces it should be rendered as a local language translation of "X". For channel_num hashing empty string will be treated as "X". Where "X" is selected based on the english words listed above for ModemConfig | +| id | [fixed32](#fixed32) | | Used to construct a globally unique channel ID. The full globally unique ID will be: "name.id" where ID is shown as base36. Assuming that the number of meshtastic users is below 20K (true for a long time) the chance of this 64 bit random number colliding with anyone else is super low. And the penalty for collision is low as well, it just means that anyone trying to decrypt channel messages might need to try multiple candidate channels. Any time a non wire compatible change is made to a channel, this field should be regenerated. There are a small number of 'special' globally known (and fairly) insecure standard channels. Those channels do not have a numeric id included in the settings, but instead it is pulled from a table of well known IDs. (see Well Known Channels FIXME) | +| uplink_enabled | [bool](#bool) | | If true, messages on the mesh will be sent to the *public* internet by any gateway ndoe | +| downlink_enabled | [bool](#bool) | | If true, messages seen on the internet will be forwarded to the local mesh. | @@ -122,36 +177,6 @@ internally in the case of CLEAR_TEXT and CLEAR_READACK) - - -### DeviceState -This message is never sent over the wire, but it is used for serializing DB -state to flash in the device code -FIXME, since we write this each time we enter deep sleep (and have infinite -flash) it would be better to use some sort of append only data structure for -the receive queue and use the preferences store for the other stuff - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| radio | [RadioConfig](#RadioConfig) | | | -| my_node | [MyNodeInfo](#MyNodeInfo) | | Read only settings/info about this node | -| owner | [User](#User) | | My owner info | -| node_db | [NodeInfo](#NodeInfo) | repeated | | -| receive_queue | [MeshPacket](#MeshPacket) | repeated | Received packets saved for delivery to the phone | -| version | [uint32](#uint32) | | A version integer used to invalidate old save files when we make incompatible changes This integer is set at build time and is private to NodeDB.cpp in the device code. | -| rx_text_message | [MeshPacket](#MeshPacket) | | We keep the last received text message (only) stored in the device flash, so we can show it on the screen. Might be null | -| no_save | [bool](#bool) | | Used only during development. Indicates developer is testing and changes should never be saved to flash. | -| did_gps_reset | [bool](#bool) | | Some GPSes seem to have bogus settings from the factory, so we always do one factory reset | -| secondary_channels | [ChannelSettings](#ChannelSettings) | repeated | Secondary channels are only used for encryption/decryption/authentication purposes. Their radio settings (freq etc) are ignored, only psk is used. - -Note: this is not kept inside of RadioConfig because that would make ToRadio/FromRadio worse case > 512 bytes (to big for BLE) | - - - - - - ### FromRadio @@ -172,7 +197,7 @@ FIFO will be populated. | log_record | [LogRecord](#LogRecord) | | set to send debug console output over our protobuf stream | | config_complete_id | [uint32](#uint32) | | 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 | | rebooted | [bool](#bool) | | 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. | -| secondary_channel | [ChannelSettings](#ChannelSettings) | | One of the secondary channels, they are all sent during config download | +| channel | [ChannelSettings](#ChannelSettings) | | One of the channels, they are all sent during config download The first channel is the "primary" channel all other channels are secondary channels The primary channel is also sent as part of RadioConfig (which is deprecated, but to support older clients) | @@ -215,7 +240,7 @@ MeshPacket). | ----- | ---- | ----- | ----------- | | from | [uint32](#uint32) | | 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. | | to | [uint32](#uint32) | | 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. | -| channel_index | [uint32](#uint32) | | 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. | +| channel_index | [uint32](#uint32) | | 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. 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. | | decoded | [SubPacket](#SubPacket) | | | | encrypted | [bytes](#bytes) | | | | id | [uint32](#uint32) | | 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. | @@ -310,7 +335,7 @@ set for behavior of their node | Field | Type | Label | Description | | ----- | ---- | ----- | ----------- | | preferences | [RadioConfig.UserPreferences](#RadioConfig.UserPreferences) | | | -| channel_settings | [ChannelSettings](#ChannelSettings) | | | +| channel_settings | [ChannelSettings](#ChannelSettings) | | The preferred way to find channel settings is now in FromRadio. | @@ -379,12 +404,12 @@ inside a radio packet (because from/to are broken out by the comms library) | Field | Type | Label | Description | | ----- | ---- | ----- | ----------- | -| position | [Position](#Position) | | Prior to 1.20 positions were communicated as a special payload type, now they are GPS_POSITION_APP Data | | data | [Data](#Data) | | | -| user | [User](#User) | | Prior to 1.20 positions were communicated as a special payload type, now they are MESH_USERINFO_APP | -| route_request | [RouteDiscovery](#RouteDiscovery) | | A route request going from the requester | +| route_request | [RouteDiscovery](#RouteDiscovery) | | A route request going from the requester FIXME - these route messages should be moved into regular data packets and use the regular on device plugin mechanism. | | route_reply | [RouteDiscovery](#RouteDiscovery) | | A route reply | | route_error | [RouteError](#RouteError) | | A failure in a routed message | +| position | [Position](#Position) | | Prior to 1.20 positions were communicated as a special payload type, now they are GPS_POSITION_APP Data | +| user | [User](#User) | | Prior to 1.20 positions were communicated as a special payload type, now they are MESH_USERINFO_APP | | want_response | [bool](#bool) | | 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. | | success_id | [uint32](#uint32) | | 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. | | fail_id | [uint32](#uint32) | | This is a nak, we failed to deliver this message. | @@ -410,6 +435,7 @@ characteristic. Once the write completes the phone can assume it is handled. | want_config_id | [uint32](#uint32) | | 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. | | set_radio | [RadioConfig](#RadioConfig) | | set the radio provisioning for this node | | set_owner | [User](#User) | | Set the owner for this node | +| set_channel | [ChannelSettings](#ChannelSettings) | | Set channels (using the new API). The first sent channel is assumed to be channel index 0 the "primary channel". Following records are secondary channels. | diff --git a/mesh.options b/mesh.options index 2492e18..9f0ec88 100644 --- a/mesh.options +++ b/mesh.options @@ -7,14 +7,6 @@ *User.long_name max_size:40 *User.short_name max_size:5 -# FIXME pick a higher number someday? or do dynamic alloc in nanopb? -*DeviceState.node_db max_count:32 - -# FIXME - max_count is actually 32 but we save/load this as one long string of preencoded MeshPacket bytes - not a big array in RAM -*DeviceState.receive_queue max_count:1 - -*DeviceState.secondary_channels max_count:4 - *RouteDiscovery.route max_count:8 # FIXME, max out based on total SubPacket size And do fragmentation and reassembly (for larger payloads) at the Android layer, not the esp32 layer. diff --git a/mesh.proto b/mesh.proto index c53d2e5..5bb080a 100644 --- a/mesh.proto +++ b/mesh.proto @@ -138,16 +138,12 @@ 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 + FIXME - these route messages should be moved into regular data packets and use the regular on + device plugin mechanism. */ RouteDiscovery route_request = 6; @@ -160,6 +156,12 @@ message SubPacket { A failure in a routed message */ RouteError route_error = 13; + + // Prior to 1.20 positions were communicated as a special payload type, now they are GPS_POSITION_APP Data + Position position = 1 [deprecated = true]; + + // Prior to 1.20 positions were communicated as a special payload type, now they are MESH_USERINFO_APP + User user = 4 [deprecated = true]; } // Not normally used, but for testing a sender can request that recipient @@ -232,6 +234,8 @@ message MeshPacket { /** 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. + 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. */ uint32 channel_index = 4; @@ -321,6 +325,7 @@ enum Constants { 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). @@ -334,6 +339,11 @@ 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) + +FIXME: Add description of multi-channel support and how primary vs secondary channels +are used. +FIXME: explain how apps use channels for security. explain how remote settings and +remote gpio are managed as an example */ message ChannelSettings { @@ -428,8 +438,24 @@ message ChannelSettings { // channel. In user interfaces it should be rendered as a local language translation of "X". For channel_num // hashing empty string will be treated as "X". // Where "X" is selected based on the english words listed above for ModemConfig - // string name = 5; + + // Used to construct a globally unique channel ID. The full globally unique ID will be: "name.id" + // where ID is shown as base36. Assuming that the number of meshtastic users is below 20K (true for a long time) + // the chance of this 64 bit random number colliding with anyone else is super low. And the penalty for + // collision is low as well, it just means that anyone trying to decrypt channel messages might need to + // try multiple candidate channels. + // Any time a non wire compatible change is made to a channel, this field should be regenerated. + // There are a small number of 'special' globally known (and fairly) insecure standard channels. + // Those channels do not have a numeric id included in the settings, but instead it is pulled from + // a table of well known IDs. (see Well Known Channels FIXME) + fixed32 id = 10; + + // If true, messages on the mesh will be sent to the *public* internet by any gateway ndoe + bool uplink_enabled = 16; + + // If true, messages seen on the internet will be forwarded to the local mesh. + bool downlink_enabled = 17; } /** @@ -617,7 +643,9 @@ message RadioConfig { } UserPreferences preferences = 1; - ChannelSettings channel_settings = 2; + + // The preferred way to find channel settings is now in FromRadio. + ChannelSettings channel_settings = 2 [ deprecated = true ]; } /** @@ -804,50 +832,6 @@ message MyNodeInfo { /// FIXME - add more useful debugging state (queue depths etc) } -// This message is never sent over the wire, but it is used for serializing DB -// state to flash in the device code -// FIXME, since we write this each time we enter deep sleep (and have infinite -// flash) it would be better to use some sort of append only data structure for -// the receive queue and use the preferences store for the other stuff -message DeviceState { - RadioConfig radio = 1; - - /// Read only settings/info about this node - MyNodeInfo my_node = 2; - - /// My owner info - User owner = 3; - - repeated NodeInfo node_db = 4; - - /// Received packets saved for delivery to the phone - repeated MeshPacket receive_queue = 5; - - /** A version integer used to invalidate old save files when we make - incompatible changes This integer is set at build time and is private to - NodeDB.cpp in the device code. */ - uint32 version = 8; - - // We keep the last received text message (only) stored in the device flash, - // so we can show it on the screen. Might be null - MeshPacket rx_text_message = 7; - - // Used only during development. Indicates developer is testing and changes - // should never be saved to flash. - bool no_save = 9; - - // Some GPSes seem to have bogus settings from the factory, so we always do - // one factory reset - bool did_gps_reset = 11; - - /** Secondary channels are only used for encryption/decryption/authentication purposes. Their radio settings (freq etc) - are ignored, only psk is used. - - Note: this is not kept inside of RadioConfig because that would make ToRadio/FromRadio worse case > 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 @@ -918,8 +902,11 @@ message FromRadio { // console. bool rebooted = 9; - // One of the secondary channels, they are all sent during config download - ChannelSettings secondary_channel = 10; + // One of the channels, they are all sent during config download + // The first channel is the "primary" channel all other channels are secondary channels + // The primary channel is also sent as part of RadioConfig (which is deprecated, but to support + // older clients) + ChannelSettings channel = 10; } } @@ -945,6 +932,10 @@ message ToRadio { // Set the owner for this node User set_owner = 102; + + // Set channels (using the new API). The first sent channel is assumed to be channel + // index 0 the "primary channel". Following records are secondary channels. + ChannelSettings set_channel = 103; } } From a66504ed6404ed967799e8b4441e4a2adbe62660 Mon Sep 17 00:00:00 2001 From: Kevin Hester Date: Mon, 28 Dec 2020 13:34:14 +0800 Subject: [PATCH 07/32] work on mqtt/multichannel --- apponly.proto | 23 +++++++++++++++++++++++ deviceonly.proto | 2 +- docs/docs.md | 36 ++++++++++++++++++++++++++++++++++++ 3 files changed, 60 insertions(+), 1 deletion(-) create mode 100644 apponly.proto diff --git a/apponly.proto b/apponly.proto new file mode 100644 index 0000000..4f02a22 --- /dev/null +++ b/apponly.proto @@ -0,0 +1,23 @@ +syntax = "proto3"; + +option java_package = "com.geeksville.mesh"; +option java_outer_classname = "AppOnly"; +option optimize_for = LITE_RUNTIME; + +import "mesh.proto"; + +/** +This message wraps a MeshPacket with extra metadata about the sender and how it arrived. +*/ +message ServiceEnvelope { + /** The (probably encrypted) packet */ + MeshPacket packet = 1; + + /** The global channel ID it was sent on */ + string channel_id = 2; + + /** The sending mesh. FIXME, is this necessary? can we use this to authenticate/prevent fake + nodeid impersonation for senders - i.e. use mesh id (which is authenticated) + local node id as + the globally trusted nodenum */ + string mesh_id = 3; +} \ No newline at end of file diff --git a/deviceonly.proto b/deviceonly.proto index c08982c..a8f615c 100644 --- a/deviceonly.proto +++ b/deviceonly.proto @@ -1,7 +1,7 @@ syntax = "proto3"; option java_package = "com.geeksville.mesh"; -option java_outer_classname = "MeshProtos"; +option java_outer_classname = "DeviceOnly"; option optimize_for = LITE_RUNTIME; import "mesh.proto"; diff --git a/docs/docs.md b/docs/docs.md index 0195f4a..afd80f7 100644 --- a/docs/docs.md +++ b/docs/docs.md @@ -3,6 +3,9 @@ ## Table of Contents +- [apponly.proto](#apponly.proto) + - [ServiceEnvelope](#.ServiceEnvelope) + - [deviceonly.proto](#deviceonly.proto) - [DeviceState](#.DeviceState) @@ -43,6 +46,39 @@ + +

Top

+ +## apponly.proto + + + + + +### ServiceEnvelope +This message wraps a MeshPacket with extra metadata about the sender and how it arrived. + + +| Field | Type | Label | Description | +| ----- | ---- | ----- | ----------- | +| packet | [MeshPacket](#MeshPacket) | | The (probably encrypted) packet | +| channel_id | [string](#string) | | The global channel ID it was sent on | +| mesh_id | [string](#string) | | The sending mesh. FIXME, is this necessary? can we use this to authenticate/prevent fake nodeid impersonation for senders - i.e. use mesh id (which is authenticated) + local node id as the globally trusted nodenum | + + + + + + + + + + + + + + +

Top

From 3e492ad2d5319a9d5aa464cf180f9fe2ab107cfb Mon Sep 17 00:00:00 2001 From: Kevin Hester Date: Mon, 28 Dec 2020 14:38:51 +0800 Subject: [PATCH 08/32] doc updates --- apponly.proto | 6 +++--- deviceonly.options | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/apponly.proto b/apponly.proto index 4f02a22..533f9ca 100644 --- a/apponly.proto +++ b/apponly.proto @@ -16,8 +16,8 @@ message ServiceEnvelope { /** The global channel ID it was sent on */ string channel_id = 2; - /** The sending mesh. FIXME, is this necessary? can we use this to authenticate/prevent fake - nodeid impersonation for senders - i.e. use mesh id (which is authenticated) + local node id as + /** The sending gateway. Can we use this to authenticate/prevent fake + nodeid impersonation for senders? - i.e. use gateway/mesh id (which is authenticated) + local node id as the globally trusted nodenum */ - string mesh_id = 3; + string gateway_id = 3; } \ No newline at end of file diff --git a/deviceonly.options b/deviceonly.options index e8fb491..10f8818 100644 --- a/deviceonly.options +++ b/deviceonly.options @@ -7,5 +7,5 @@ # FIXME - max_count is actually 32 but we save/load this as one long string of preencoded MeshPacket bytes - not a big array in RAM *DeviceState.receive_queue max_count:1 -*DeviceState.secondary_channels max_count:4 +*DeviceState.secondary_channels max_count:7 From dfe7bc1217a00c23eecb9dfcf1d56fe95ebddc3b Mon Sep 17 00:00:00 2001 From: Kevin Hester Date: Wed, 30 Dec 2020 12:24:39 +0800 Subject: [PATCH 09/32] doc updates --- docs/docs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs.md b/docs/docs.md index afd80f7..6df00a3 100644 --- a/docs/docs.md +++ b/docs/docs.md @@ -63,7 +63,7 @@ This message wraps a MeshPacket with extra metadata about the sender and how it | ----- | ---- | ----- | ----------- | | packet | [MeshPacket](#MeshPacket) | | The (probably encrypted) packet | | channel_id | [string](#string) | | The global channel ID it was sent on | -| mesh_id | [string](#string) | | The sending mesh. FIXME, is this necessary? can we use this to authenticate/prevent fake nodeid impersonation for senders - i.e. use mesh id (which is authenticated) + local node id as the globally trusted nodenum | +| gateway_id | [string](#string) | | The sending gateway. Can we use this to authenticate/prevent fake nodeid impersonation for senders? - i.e. use gateway/mesh id (which is authenticated) + local node id as the globally trusted nodenum | From 04bc6b41a44a40f09193e0e27b8976d91f09d360 Mon Sep 17 00:00:00 2001 From: Jm Casler Date: Tue, 12 Jan 2021 21:53:16 -0800 Subject: [PATCH 10/32] SerialPlugin using port 64 --- portnums.proto | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/portnums.proto b/portnums.proto index 422b6ca..a81fa84 100644 --- a/portnums.proto +++ b/portnums.proto @@ -72,7 +72,17 @@ enum PortNum { /** Used for the python IP tunnel feature */ IP_TUNNEL_APP = 33; + /** Provides a hardware serial interface to send and receive from the Meshtastic network. + Connect to the RX/TX pins of a device with 38400 8N1. Packets received from the Meshtastic + network is forwarded to the RX pin while sending a packet to TX will go out to the Mesh + network. Maximum packet size of 240 bytes. + + Plugin is disabled by default can be turned on by setting SERIALPLUGIN_ENABLED = 1 in + SerialPlugh.cpp. + */ + SERIAL_APP = 64; + /** Private applications should use portnums >= 256. To simplify initial development and testing you can use "PRIVATE_APP" in your code without needing to rebuild protobuf files (via bin/regin_protos.sh) */ PRIVATE_APP = 256; - } \ No newline at end of file + } From 4c62d8e53696074d7c368518afd9d564df374fcf Mon Sep 17 00:00:00 2001 From: Jm Casler Date: Tue, 12 Jan 2021 21:54:16 -0800 Subject: [PATCH 11/32] Update portnums.proto --- portnums.proto | 3 +++ 1 file changed, 3 insertions(+) diff --git a/portnums.proto b/portnums.proto index a81fa84..f02a253 100644 --- a/portnums.proto +++ b/portnums.proto @@ -79,6 +79,9 @@ enum PortNum { Plugin is disabled by default can be turned on by setting SERIALPLUGIN_ENABLED = 1 in SerialPlugh.cpp. + + Maintained by Jm Casler (MC Hamster) : jm@casler.org + */ SERIAL_APP = 64; From 4f9da902e224b7fdc608b2b19b41818738e4f3e4 Mon Sep 17 00:00:00 2001 From: Paul Mandal Date: Fri, 15 Jan 2021 21:03:21 -0700 Subject: [PATCH 12/32] Add portnum definition for ATAK Forwarder --- portnums.proto | 3 +++ 1 file changed, 3 insertions(+) diff --git a/portnums.proto b/portnums.proto index f02a253..62f03e5 100644 --- a/portnums.proto +++ b/portnums.proto @@ -88,4 +88,7 @@ enum PortNum { /** Private applications should use portnums >= 256. To simplify initial development and testing you can use "PRIVATE_APP" in your code without needing to rebuild protobuf files (via bin/regin_protos.sh) */ PRIVATE_APP = 256; + + /** ATAK Forwarder Plugin https://github.com/paulmandal/atak-forwarder */ + ATAK_FORWARDER = 257; } From 0977dfd8943b7d615f9f9719472c76fff0143016 Mon Sep 17 00:00:00 2001 From: Jm Casler Date: Sat, 16 Jan 2021 14:49:58 -0800 Subject: [PATCH 13/32] #615 - Allow rate for tbeam battery charger to be configurable --- mesh.proto | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/mesh.proto b/mesh.proto index 5bb080a..21fd8f3 100644 --- a/mesh.proto +++ b/mesh.proto @@ -482,6 +482,30 @@ enum RegionCode { // Add new regions here } +/** + Sets the charge control current of devices with a battery charger that can be + configured. This is passed into the axp power management chip like on the tbeam. +*/ +enum ChargeCurrent { + Unset = 0; + 100MA = 1; + 190MA = 2; + 280MA = 3; + 360MA = 4; + 450MA = 5; + 550MA = 6; + 630MA = 7; + 700MA = 8; + 780MA = 9; + 880MA = 10; + 960MA = 11; + 1000MA = 12; + 1080MA = 13; + 1160MA = 14; + 1240MA = 15; + 1320MA = 16; +} + /** How the GPS hardware in this unit is operated. @@ -565,6 +589,9 @@ message RadioConfig { /// The region code for my radio (US, CN, EU433, etc...) RegionCode region = 15; + /** Sets the current of the battery charger */ + ChargeCurrent charge_current = 16; + /** Are we operating as a router. Changes behavior in the following ways: The device will only sleep for critically low battery level (i.e. always tries to stay alive for the mesh) From ff4ff06d5ee7d5c63d2dd1b7f2c5f8e29a36be11 Mon Sep 17 00:00:00 2001 From: Jm Casler Date: Sat, 16 Jan 2021 15:02:38 -0800 Subject: [PATCH 14/32] Added preferences for the serialplugin --- mesh.proto | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/mesh.proto b/mesh.proto index 21fd8f3..1fdf386 100644 --- a/mesh.proto +++ b/mesh.proto @@ -667,6 +667,18 @@ message RadioConfig { router.cpp) */ repeated uint32 ignore_incoming = 103; + + /** + Preferences for the SerialPlugin + + FIXME - Move this out of UserPreferences and into a section for plugin configuration. + */ + bool serialplugin_enabled = 120; + bool serialplugin_echo = 121; + uint32 serialplugin_rxd = 122; + uint32 serialplugin_txd = 123; + uint32 serialplugin_timeout = 124; + } UserPreferences preferences = 1; From e2c9b17241925fb9e60d9b6c05b89cc5915d5cdd Mon Sep 17 00:00:00 2001 From: Jm Casler Date: Sat, 16 Jan 2021 20:42:01 -0800 Subject: [PATCH 15/32] Fix to ChargeCurrent. --- mesh.proto | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/mesh.proto b/mesh.proto index 1fdf386..42eaed3 100644 --- a/mesh.proto +++ b/mesh.proto @@ -488,22 +488,22 @@ enum RegionCode { */ enum ChargeCurrent { Unset = 0; - 100MA = 1; - 190MA = 2; - 280MA = 3; - 360MA = 4; - 450MA = 5; - 550MA = 6; - 630MA = 7; - 700MA = 8; - 780MA = 9; - 880MA = 10; - 960MA = 11; - 1000MA = 12; - 1080MA = 13; - 1160MA = 14; - 1240MA = 15; - 1320MA = 16; + MA100 = 1; + MA190 = 2; + MA280 = 3; + MA360 = 4; + MA450 = 5; + MA550 = 6; + MA630 = 7; + MA700 = 8; + MA780 = 9; + MA880 = 10; + MA960 = 11; + MA1000 = 12; + MA1080 = 13; + MA1160 = 14; + MA1240 = 15; + MA1320 = 16; } /** From 855da8701edbb19818069ad8545d5b9f030bb33f Mon Sep 17 00:00:00 2001 From: Jm Casler Date: Sat, 16 Jan 2021 20:45:10 -0800 Subject: [PATCH 16/32] Fix unset in ChargeCurrent --- mesh.proto | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mesh.proto b/mesh.proto index 42eaed3..066b547 100644 --- a/mesh.proto +++ b/mesh.proto @@ -487,7 +487,7 @@ enum RegionCode { configured. This is passed into the axp power management chip like on the tbeam. */ enum ChargeCurrent { - Unset = 0; + MAUnset = 0; MA100 = 1; MA190 = 2; MA280 = 3; From fa9bb79f2a13f3646b99b67e294f9f98ac8c5cde Mon Sep 17 00:00:00 2001 From: Sacha Weatherstone Date: Sun, 17 Jan 2021 17:50:35 +1100 Subject: [PATCH 17/32] final formatting fix --- apponly.proto | 22 ++++++++++------ deviceonly.proto | 59 ++++++++++++++++++++++++++++--------------- mesh.proto | 24 +++++++++++------- remote_hardware.proto | 2 +- 4 files changed, 68 insertions(+), 39 deletions(-) diff --git a/apponly.proto b/apponly.proto index 533f9ca..007b9ae 100644 --- a/apponly.proto +++ b/apponly.proto @@ -6,18 +6,24 @@ option optimize_for = LITE_RUNTIME; import "mesh.proto"; -/** -This message wraps a MeshPacket with extra metadata about the sender and how it arrived. -*/ +/* + * This message wraps a MeshPacket with extra metadata about the sender and how it arrived. + */ message ServiceEnvelope { - /** The (probably encrypted) packet */ + /* + * The (probably encrypted) packet + */ MeshPacket packet = 1; - /** The global channel ID it was sent on */ + /* + * The global channel ID it was sent on + */ string channel_id = 2; - /** The sending gateway. Can we use this to authenticate/prevent fake - nodeid impersonation for senders? - i.e. use gateway/mesh id (which is authenticated) + local node id as - the globally trusted nodenum */ + /* + * The sending gateway. Can we use this to authenticate/prevent fake + * nodeid impersonation for senders? - i.e. use gateway/mesh id (which is authenticated) + local node id as + * the globally trusted nodenum + */ string gateway_id = 3; } \ No newline at end of file diff --git a/deviceonly.proto b/deviceonly.proto index a8f615c..9c6d6e8 100644 --- a/deviceonly.proto +++ b/deviceonly.proto @@ -6,45 +6,62 @@ option optimize_for = LITE_RUNTIME; import "mesh.proto"; -// This message is never sent over the wire, but it is used for serializing DB -// state to flash in the device code -// FIXME, since we write this each time we enter deep sleep (and have infinite -// flash) it would be better to use some sort of append only data structure for -// the receive queue and use the preferences store for the other stuff +/* + * This message is never sent over the wire, but it is used for serializing DB + * state to flash in the device code + * FIXME, since we write this each time we enter deep sleep (and have infinite + * flash) it would be better to use some sort of append only data structure for + * the receive queue and use the preferences store for the other stuff + */ message DeviceState { RadioConfig radio = 1; - /// Read only settings/info about this node + /* + * Read only settings/info about this node + */ MyNodeInfo my_node = 2; - /// My owner info + /* + * My owner info + */ User owner = 3; repeated NodeInfo node_db = 4; - /// Received packets saved for delivery to the phone + /* + * Received packets saved for delivery to the phone + */ repeated MeshPacket receive_queue = 5; - /** A version integer used to invalidate old save files when we make - incompatible changes This integer is set at build time and is private to - NodeDB.cpp in the device code. */ + /* + * A version integer used to invalidate old save files when we make + * incompatible changes This integer is set at build time and is private to + * NodeDB.cpp in the device code. + */ uint32 version = 8; - // We keep the last received text message (only) stored in the device flash, - // so we can show it on the screen. Might be null + /* + * We keep the last received text message (only) stored in the device flash, + * so we can show it on the screen. + * Might be null + */ MeshPacket rx_text_message = 7; - // Used only during development. Indicates developer is testing and changes - // should never be saved to flash. + /* + * Used only during development. Indicates developer is testing and changes + * should never be saved to flash. + */ bool no_save = 9; - // Some GPSes seem to have bogus settings from the factory, so we always do - // one factory reset + /* + * Some GPSes seem to have bogus settings from the factory, so we always do one factory reset. + */ bool did_gps_reset = 11; - /** Secondary channels are only used for encryption/decryption/authentication purposes. Their radio settings (freq etc) - are ignored, only psk is used. - Note: this is not kept inside of RadioConfig because that would make ToRadio/FromRadio worse case > 512 bytes (to big for BLE) - */ + /* + * Secondary channels are only used for encryption/decryption/authentication purposes. Their radio settings (freq etc) + * are ignored, only psk is used. + * Note: this is not kept inside of RadioConfig because that would make ToRadio/FromRadio worse case > 512 bytes (to big for BLE) + */ repeated ChannelSettings secondary_channels = 12; } \ No newline at end of file diff --git a/mesh.proto b/mesh.proto index bc8d86f..a6953c8 100644 --- a/mesh.proto +++ b/mesh.proto @@ -57,8 +57,10 @@ message Position { 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) +/* + * 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 { /* @@ -181,10 +183,14 @@ message SubPacket { */ RouteError route_error = 13; - // Prior to 1.20 positions were communicated as a special payload type, now they are GPS_POSITION_APP Data + /* + * Prior to 1.20 positions were communicated as a special payload type, now they are GPS_POSITION_APP Data + */ Position position = 1 [deprecated = true]; - // Prior to 1.20 positions were communicated as a special payload type, now they are MESH_USERINFO_APP + /* + * Prior to 1.20 positions were communicated as a special payload type, now they are MESH_USERINFO_APP + */ User user = 4 [deprecated = true]; } @@ -1184,10 +1190,10 @@ message ToRadio { */ User set_owner = 102; - // Set channels (using the new API). The first sent channel is assumed to be channel - // index 0 the "primary channel". Following records are secondary channels. + /* + * Set channels (using the new API). The first sent channel is assumed to be channel + * index 0 the "primary channel". Following records are secondary channels. + */ ChannelSettings set_channel = 103; } -} - - +} \ No newline at end of file diff --git a/remote_hardware.proto b/remote_hardware.proto index eef3471..9162d68 100644 --- a/remote_hardware.proto +++ b/remote_hardware.proto @@ -65,4 +65,4 @@ message HardwareMessage { * Not used for all MessageTypes, see MessageType for details */ uint64 gpio_value = 3; -} +} \ No newline at end of file From c28a4e84940f50799d88c599d0f30478ff617f3b Mon Sep 17 00:00:00 2001 From: Andrew Date: Wed, 20 Jan 2021 10:09:35 -0800 Subject: [PATCH 18/32] Add CriticalErrorCode_TransmitFailed to docs.md --- docs/docs.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/docs.md b/docs/docs.md index 6df00a3..132bd78 100644 --- a/docs/docs.md +++ b/docs/docs.md @@ -569,6 +569,7 @@ post on the meshtastic.discourse.group and we'll try to help. | UBloxInitFailed | 5 | We failed while configuring a UBlox GPS | | NoAXP192 | 6 | This board was expected to have a power management chip and it is missing or broken | | InvalidRadioSetting | 7 | The channel tried to set a radio setting which is not supported by this chipset, radio comms settings are now undefined. | +| TransmitFailed | 8 | Radio transmit hardware failure. We sent data to the radio chip, but it didn't reply with an interrupt. | From f95495987f8ff6569d73b46924134b7682878efa Mon Sep 17 00:00:00 2001 From: Andrew Mark Date: Wed, 20 Jan 2021 10:34:36 -0800 Subject: [PATCH 19/32] Add CriticalError_TransmitFailed to protobufs --- .vscode/settings.json | 3 +++ mesh.proto | 5 +++++ 2 files changed, 8 insertions(+) create mode 100644 .vscode/settings.json diff --git a/.vscode/settings.json b/.vscode/settings.json new file mode 100644 index 0000000..cad7657 --- /dev/null +++ b/.vscode/settings.json @@ -0,0 +1,3 @@ +{ + "cmake.configureOnOpen": false +} \ No newline at end of file diff --git a/mesh.proto b/mesh.proto index 066b547..f159209 100644 --- a/mesh.proto +++ b/mesh.proto @@ -777,6 +777,11 @@ enum CriticalErrorCode { // The channel tried to set a radio setting which is not supported by this chipset, // radio comms settings are now undefined. InvalidRadioSetting = 7; + + // Radio transmit hardware failure. We sent data to the radio chip, but it didn't + // reply with an interrupt. + TransmitFailed = 8; + } /** From 55757b5deaf4516a6db6b5d4356c75f01f94c053 Mon Sep 17 00:00:00 2001 From: Jm Casler Date: Thu, 21 Jan 2021 19:55:02 -0800 Subject: [PATCH 20/32] Add port number for external notification plugin --- portnums.proto | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/portnums.proto b/portnums.proto index ed43f9c..b07d1c8 100644 --- a/portnums.proto +++ b/portnums.proto @@ -82,15 +82,19 @@ enum PortNum { * Connect to the RX/TX pins of a device with 38400 8N1. Packets received from the Meshtastic * network is forwarded to the RX pin while sending a packet to TX will go out to the Mesh * network. Maximum packet size of 240 bytes. - */ - - /* - * Plugin is disabled by default can be turned on by setting SERIALPLUGIN_ENABLED = 1 in SerialPlugh.cpp - * + * * Maintained by Jm Casler (MC Hamster) : jm@casler.org */ SERIAL_APP = 64; + /* + * Provides a mechanism for external notifications. eg: + * LED, Buzzer, Fog Horn or anything else + * + * Maintained by Jm Casler (MC Hamster) : jm@casler.org + */ + EXTERNAL_NOTIFICATION_APP = 65; + /* * Private applications should use portnums >= 256. * To simplify initial development and testing you can use "PRIVATE_APP" From 5d6dfb2011debc6fbd955bff634d7732dccf63d5 Mon Sep 17 00:00:00 2001 From: Jm Casler Date: Thu, 21 Jan 2021 20:06:53 -0800 Subject: [PATCH 21/32] Configuration for the external notification plugin ... also snuck in a "mode" for the serialplugin --- mesh.proto | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/mesh.proto b/mesh.proto index a6953c8..e0c02ad 100644 --- a/mesh.proto +++ b/mesh.proto @@ -819,7 +819,18 @@ message RadioConfig { uint32 serialplugin_rxd = 122; uint32 serialplugin_txd = 123; uint32 serialplugin_timeout = 124; + uint32 serialplugin_mode = 125; + + /** + Preferences for the ExternalNotificationPlugin + FIXME - Move this out of UserPreferences and into a section for plugin configuration. + */ + bool externalnotificationplugin_enabled = 126; + uint32 externalnotificationplugin_output = 127; + uint32 externalnotificationplugin_output_ms = 128; + uint32 externalnotificationplugin_mode = 129; + } UserPreferences preferences = 1; @@ -1196,4 +1207,4 @@ message ToRadio { */ ChannelSettings set_channel = 103; } -} \ No newline at end of file +} From 451474140addb32b823b29ac4cb662ab37f60c17 Mon Sep 17 00:00:00 2001 From: Jm Casler Date: Sun, 24 Jan 2021 16:37:49 -0800 Subject: [PATCH 22/32] Updating the conf for the ext_notification_plugin --- mesh.proto | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/mesh.proto b/mesh.proto index e0c02ad..6a0fc27 100644 --- a/mesh.proto +++ b/mesh.proto @@ -826,10 +826,12 @@ message RadioConfig { FIXME - Move this out of UserPreferences and into a section for plugin configuration. */ - bool externalnotificationplugin_enabled = 126; - uint32 externalnotificationplugin_output = 127; - uint32 externalnotificationplugin_output_ms = 128; - uint32 externalnotificationplugin_mode = 129; + bool ext_notification_plugin_enabled = 126; + uint32 ext_notification_plugin_output_ms = 127; + uint32 ext_notification_plugin_output = 128; + bool ext_notification_plugin_active = 129; + bool ext_notification_plugin_alert_message = 130; + bool ext_notification_plugin_alert_bell = 131; } From c1ae40f1c70b32bae18aff25e60dcdba513502ce Mon Sep 17 00:00:00 2001 From: Jm Casler Date: Wed, 27 Jan 2021 19:19:34 -0800 Subject: [PATCH 23/32] Update portnums.proto --- portnums.proto | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/portnums.proto b/portnums.proto index b07d1c8..7ffc294 100644 --- a/portnums.proto +++ b/portnums.proto @@ -88,12 +88,11 @@ enum PortNum { SERIAL_APP = 64; /* - * Provides a mechanism for external notifications. eg: - * LED, Buzzer, Fog Horn or anything else + * STORE_REQUEST_APP (Work in Progress) * * Maintained by Jm Casler (MC Hamster) : jm@casler.org */ - EXTERNAL_NOTIFICATION_APP = 65; + STORE_REQUEST_APP = 65; /* * Private applications should use portnums >= 256. From 2e15426fe3eb300dc71668892b5aafe95155530b Mon Sep 17 00:00:00 2001 From: Kevin Hester Date: Fri, 29 Jan 2021 10:11:10 +0800 Subject: [PATCH 24/32] fix formatting --- .vscode/settings.json | 3 + apponly.proto | 22 +- deviceonly.proto | 59 +- mesh.proto | 1475 ++++++++++++++++++++++++----------------- notused/future.proto | 44 +- portnums.proto | 149 +++-- remote_hardware.proto | 68 +- 7 files changed, 1081 insertions(+), 739 deletions(-) create mode 100644 .vscode/settings.json diff --git a/.vscode/settings.json b/.vscode/settings.json new file mode 100644 index 0000000..cad7657 --- /dev/null +++ b/.vscode/settings.json @@ -0,0 +1,3 @@ +{ + "cmake.configureOnOpen": false +} \ No newline at end of file diff --git a/apponly.proto b/apponly.proto index 533f9ca..007b9ae 100644 --- a/apponly.proto +++ b/apponly.proto @@ -6,18 +6,24 @@ option optimize_for = LITE_RUNTIME; import "mesh.proto"; -/** -This message wraps a MeshPacket with extra metadata about the sender and how it arrived. -*/ +/* + * This message wraps a MeshPacket with extra metadata about the sender and how it arrived. + */ message ServiceEnvelope { - /** The (probably encrypted) packet */ + /* + * The (probably encrypted) packet + */ MeshPacket packet = 1; - /** The global channel ID it was sent on */ + /* + * The global channel ID it was sent on + */ string channel_id = 2; - /** The sending gateway. Can we use this to authenticate/prevent fake - nodeid impersonation for senders? - i.e. use gateway/mesh id (which is authenticated) + local node id as - the globally trusted nodenum */ + /* + * The sending gateway. Can we use this to authenticate/prevent fake + * nodeid impersonation for senders? - i.e. use gateway/mesh id (which is authenticated) + local node id as + * the globally trusted nodenum + */ string gateway_id = 3; } \ No newline at end of file diff --git a/deviceonly.proto b/deviceonly.proto index a8f615c..9c6d6e8 100644 --- a/deviceonly.proto +++ b/deviceonly.proto @@ -6,45 +6,62 @@ option optimize_for = LITE_RUNTIME; import "mesh.proto"; -// This message is never sent over the wire, but it is used for serializing DB -// state to flash in the device code -// FIXME, since we write this each time we enter deep sleep (and have infinite -// flash) it would be better to use some sort of append only data structure for -// the receive queue and use the preferences store for the other stuff +/* + * This message is never sent over the wire, but it is used for serializing DB + * state to flash in the device code + * FIXME, since we write this each time we enter deep sleep (and have infinite + * flash) it would be better to use some sort of append only data structure for + * the receive queue and use the preferences store for the other stuff + */ message DeviceState { RadioConfig radio = 1; - /// Read only settings/info about this node + /* + * Read only settings/info about this node + */ MyNodeInfo my_node = 2; - /// My owner info + /* + * My owner info + */ User owner = 3; repeated NodeInfo node_db = 4; - /// Received packets saved for delivery to the phone + /* + * Received packets saved for delivery to the phone + */ repeated MeshPacket receive_queue = 5; - /** A version integer used to invalidate old save files when we make - incompatible changes This integer is set at build time and is private to - NodeDB.cpp in the device code. */ + /* + * A version integer used to invalidate old save files when we make + * incompatible changes This integer is set at build time and is private to + * NodeDB.cpp in the device code. + */ uint32 version = 8; - // We keep the last received text message (only) stored in the device flash, - // so we can show it on the screen. Might be null + /* + * We keep the last received text message (only) stored in the device flash, + * so we can show it on the screen. + * Might be null + */ MeshPacket rx_text_message = 7; - // Used only during development. Indicates developer is testing and changes - // should never be saved to flash. + /* + * Used only during development. Indicates developer is testing and changes + * should never be saved to flash. + */ bool no_save = 9; - // Some GPSes seem to have bogus settings from the factory, so we always do - // one factory reset + /* + * Some GPSes seem to have bogus settings from the factory, so we always do one factory reset. + */ bool did_gps_reset = 11; - /** Secondary channels are only used for encryption/decryption/authentication purposes. Their radio settings (freq etc) - are ignored, only psk is used. - Note: this is not kept inside of RadioConfig because that would make ToRadio/FromRadio worse case > 512 bytes (to big for BLE) - */ + /* + * Secondary channels are only used for encryption/decryption/authentication purposes. Their radio settings (freq etc) + * are ignored, only psk is used. + * Note: this is not kept inside of RadioConfig because that would make ToRadio/FromRadio worse case > 512 bytes (to big for BLE) + */ repeated ChannelSettings secondary_channels = 12; } \ No newline at end of file diff --git a/mesh.proto b/mesh.proto index 5bb080a..68a05c2 100644 --- a/mesh.proto +++ b/mesh.proto @@ -1,27 +1,23 @@ 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 - -*/ +/* + * 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"; @@ -29,446 +25,504 @@ option optimize_for = LITE_RUNTIME; import "portnums.proto"; -/** a gps position -*/ +/* + * a gps position + */ message Position { - /** The new preferred location encoding, divide by 1e-7 to get degrees in - * floating point */ + /* + * 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 */ + /* + * In meters above MSL + */ int32 altitude = 3; - /** 1-100 (0 means not provided) */ + /* + * 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 + /* + * 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) +/* + * 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 + /* + * Formerly named typ and of type Type + */ PortNum portnum = 1; - bytes payload = 2; // required + /* + * Required + */ + bytes payload = 2; } -/* 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 - -*/ +/* + * 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 + */ 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> + /* + * 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" + /* + * 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 + /* + * 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 + /* + * 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) +/* + * A message used in our Dynamic Source Routing protocol (RFC 4728 based) + */ message RouteDiscovery { - /** - The list of nodes this packet has visited so far + /* + * 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. + /* + * 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 + /* + * 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) +/* + * 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 + /* + * Only one of the following fields can be populated at a time + */ oneof payload { Data data = 3; - /** - A route request going from the requester - FIXME - these route messages should be moved into regular data packets and use the regular on - device plugin mechanism. - */ + /* + * A route request going from the requester + * FIXME - these route messages should be moved into regular data packets and use the regular on + * device plugin mechanism. + */ RouteDiscovery route_request = 6; - /** - A route reply - */ + /* + * A route reply + */ RouteDiscovery route_reply = 7; - /** - A failure in a routed message - */ + /* + * A failure in a routed message + */ RouteError route_error = 13; - // Prior to 1.20 positions were communicated as a special payload type, now they are GPS_POSITION_APP Data + /* + * Prior to 1.20 positions were communicated as a special payload type, now they are GPS_POSITION_APP Data + */ Position position = 1 [deprecated = true]; - // Prior to 1.20 positions were communicated as a special payload type, now they are MESH_USERINFO_APP + /* + * Prior to 1.20 positions were communicated as a special payload type, now they are MESH_USERINFO_APP + */ User user = 4 [deprecated = true]; } - // 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. + /* + * 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. + */ 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. - */ + /* + * 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. + /* + * 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. - */ + /* + * 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). - */ + /* + * 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. - */ + /* + * 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). +/* + * 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. - */ + /* + * 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. - */ + /* + * 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. - 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. - */ + /* + * 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. + * 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. + */ 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. - */ + + /* + * 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. - */ + /* + * 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) + /* + * 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. + /* + * *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. - */ + /* + * 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 - */ + /* + * 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 +/* + * 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 + /* + * 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 - */ + /* + * 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) - -FIXME: Add description of multi-channel support and how primary vs secondary channels -are used. -FIXME: explain how apps use channels for security. explain how remote settings and -remote gpio are managed as an example -*/ +/* + * 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) + * + * FIXME: Add description of multi-channel support and how primary vs secondary channels are used. + * FIXME: explain how apps use channels for security. explain how remote settings and + * remote gpio are managed as an example + */ 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. - */ + /* + * 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. - */ + /* + * 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" + + /* + * < Bw = 125 kHz, Cr = 4/5, Sf(7) = 128chips/symbol, CRC + * < on. Default medium range (5.469 kbps) + */ + Bw125Cr45Sf128 = 0; - 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" + /* + * < Bw = 500 kHz, Cr = 4/5, Sf(7) = 128chips/symbol, CRC + * < on. Fast+short range (21.875 kbps) + */ + Bw500Cr45Sf128 = 1; + + /* + * < Bw = 31.25 kHz, Cr = 4/8, Sf(9) = 512chips/symbol, + * < CRC on. Slow+long range (275 bps) + */ + Bw31_25Cr48Sf512 = 2; + + /* + * < Bw = 125 kHz, Cr = 4/8, Sf(12) = 4096chips/symbol, CRC + * < on. Slow+long range (183 bps) + */ + Bw125Cr48Sf4096 = 3; } - // 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. + /* + * 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 - */ + /* + * 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<= 256. To simplify initial development and testing you can use "PRIVATE_APP" - in your code without needing to rebuild protobuf files (via bin/regin_protos.sh) */ + /* + * STORE_REQUEST_APP (Work in Progress) + * + * Maintained by Jm Casler (MC Hamster) : jm@casler.org + */ + STORE_REQUEST_APP = 65; + + /* + * Private applications should use portnums >= 256. + * To simplify initial development and testing you can use "PRIVATE_APP" + * in your code without needing to rebuild protobuf files (via bin/regin_protos.sh) + */ PRIVATE_APP = 256; + + /* + * ATAK Forwarder Plugin https://github.com/paulmandal/atak-forwarder + */ + ATAK_FORWARDER = 257; } diff --git a/remote_hardware.proto b/remote_hardware.proto index 02f53ef..9162d68 100644 --- a/remote_hardware.proto +++ b/remote_hardware.proto @@ -4,49 +4,65 @@ option java_package = "com.geeksville.mesh"; option java_outer_classname = "RemoteHardware"; option optimize_for = LITE_RUNTIME; -/** A example app to show off the plugin system. This message is used for REMOTE_HARDWARE_APP PortNums. - -Also provides easy remote access to any GPIO. - -In the future other remote hardware operations can be added based on user interest -(i.e. serial output, spi/i2c input/output). - -FIXME - currently this feature is turned on by default which is dangerous because no security yet (beyond the -channel mechanism). It should be off by default and then protected based on some TBD mechanism (a special channel -once multichannel support is included?) -*/ +/* A example app to show off the plugin system. This message is used for REMOTE_HARDWARE_APP PortNums. + * + * Also provides easy remote access to any GPIO. + * + * In the future other remote hardware operations can be added based on user interest (i.e. serial output, spi/i2c input/output). + * + * FIXME - currently this feature is turned on by default which is dangerous because no security yet (beyond the channel mechanism). + * It should be off by default and then protected based on some TBD mechanism (a special channel once multichannel support is included?) + */ message HardwareMessage { enum Type { - /** Unset/unused */ + + /* + * Unset/unused + */ UNSET = 0; - /** Set gpio gpios based on gpio_mask/gpio_value */ + /* + * Set gpio gpios based on gpio_mask/gpio_value + */ WRITE_GPIOS = 1; - /** We are now interested in watching the gpio_mask gpios. If the selected gpios change, please broadcast - GPIOS_CHANGED. - - Will implicitly change the gpios requested to be INPUT gpios. - */ + /* + * We are now interested in watching the gpio_mask gpios. + * If the selected gpios change, please broadcast GPIOS_CHANGED. + * + * Will implicitly change the gpios requested to be INPUT gpios. + */ WATCH_GPIOS = 2; - /** The gpios listed in gpio_mask have changed, the new values are listed in gpio_value */ + /* + * The gpios listed in gpio_mask have changed, the new values are listed in gpio_value + */ GPIOS_CHANGED = 3; - /** Read the gpios specified in gpio_mask, send back a READ_GPIOS_REPLY reply with gpio_value populated */ + /* + * Read the gpios specified in gpio_mask, send back a READ_GPIOS_REPLY reply with gpio_value populated + */ READ_GPIOS = 4; - /** A reply to READ_GPIOS. gpio_mask and gpio_value will be populated */ + /* + * A reply to READ_GPIOS. gpio_mask and gpio_value will be populated + */ READ_GPIOS_REPLY = 5; } - /** What type of HardwareMessage is this? */ + /* + * What type of HardwareMessage is this? + */ Type typ = 1; - /** What gpios are we changing. Not used for all MessageTypes, see MessageType for details */ + /* + * What gpios are we changing. Not used for all MessageTypes, see MessageType for details + */ uint64 gpio_mask = 2; - /** For gpios that were listed in gpio_mask as valid, what are the signal levels for those gpios. - Not used for all MessageTypes, see MessageType for details */ + /* + * For gpios that were listed in gpio_mask as valid, what are the signal levels for those gpios. + * Not used for all MessageTypes, see MessageType for details + */ uint64 gpio_value = 3; -} +} \ No newline at end of file From c9ad10d7e2f7f465dc477e98d6ec9d3b7059336c Mon Sep 17 00:00:00 2001 From: Kevin Hester Date: Fri, 29 Jan 2021 10:12:45 +0800 Subject: [PATCH 25/32] doc updatez --- docs/docs.md | 198 +++++++++++++++++++++++++++++++++++---------------- 1 file changed, 137 insertions(+), 61 deletions(-) diff --git a/docs/docs.md b/docs/docs.md index 132bd78..3ec0c98 100644 --- a/docs/docs.md +++ b/docs/docs.md @@ -26,6 +26,7 @@ - [User](#.User) - [ChannelSettings.ModemConfig](#.ChannelSettings.ModemConfig) + - [ChargeCurrent](#.ChargeCurrent) - [Constants](#.Constants) - [CriticalErrorCode](#.CriticalErrorCode) - [GpsOperation](#.GpsOperation) @@ -106,7 +107,7 @@ the receive queue and use the preferences store for the other stuff | version | [uint32](#uint32) | | A version integer used to invalidate old save files when we make incompatible changes This integer is set at build time and is private to NodeDB.cpp in the device code. | | rx_text_message | [MeshPacket](#MeshPacket) | | We keep the last received text message (only) stored in the device flash, so we can show it on the screen. Might be null | | no_save | [bool](#bool) | | Used only during development. Indicates developer is testing and changes should never be saved to flash. | -| did_gps_reset | [bool](#bool) | | Some GPSes seem to have bogus settings from the factory, so we always do one factory reset | +| did_gps_reset | [bool](#bool) | | Some GPSes seem to have bogus settings from the factory, so we always do one factory reset. | | secondary_channels | [ChannelSettings](#ChannelSettings) | repeated | Secondary channels are only used for encryption/decryption/authentication purposes. Their radio settings (freq etc) are ignored, only psk is used. Note: this is not kept inside of RadioConfig because that would make ToRadio/FromRadio worse case > 512 bytes (to big for BLE) | @@ -129,8 +130,7 @@ the receive queue and use the preferences store for the other stuff ## mesh.proto Meshtastic protobufs -For more information on protobufs (and tools to use them with the language of -your choice) see +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 @@ -142,11 +142,9 @@ 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 +/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 +Nanopb binaries available here: https://jpa.kapsi.fi/nanopb/download/ use nanopb 0.4.0 @@ -156,9 +154,7 @@ 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 +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 @@ -171,8 +167,7 @@ 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) -FIXME: Add description of multi-channel support and how primary vs secondary channels -are used. +FIXME: Add description of multi-channel support and how primary vs secondary channels are used. FIXME: explain how apps use channels for security. explain how remote settings and remote gpio are managed as an example @@ -205,8 +200,8 @@ internally in the case of CLEAR_TEXT and CLEAR_READACK) | Field | Type | Label | Description | | ----- | ---- | ----- | ----------- | -| portnum | [PortNum](#PortNum) | | formerly named typ and of type Type | -| payload | [bytes](#bytes) | | required | +| portnum | [PortNum](#PortNum) | | Formerly named typ and of type Type | +| payload | [bytes](#bytes) | | Required | @@ -216,11 +211,9 @@ internally in the case of CLEAR_TEXT and CLEAR_READACK) ### FromRadio -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. +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. | Field | Type | Label | Description | @@ -231,7 +224,7 @@ FIFO will be populated. | node_info | [NodeInfo](#NodeInfo) | | One packet is sent for each node in the on radio DB starts over with the first node in our DB | | radio | [RadioConfig](#RadioConfig) | | In rev1 this was the radio BLE characteristic | | log_record | [LogRecord](#LogRecord) | | set to send debug console output over our protobuf stream | -| config_complete_id | [uint32](#uint32) | | 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 | +| config_complete_id | [uint32](#uint32) | | 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. | | rebooted | [bool](#bool) | | 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. | | channel | [ChannelSettings](#ChannelSettings) | | One of the channels, they are all sent during config download The first channel is the "primary" channel all other channels are secondary channels The primary channel is also sent as part of RadioConfig (which is deprecated, but to support older clients) | @@ -268,8 +261,7 @@ emitting multiple records. ### MeshPacket 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). +very small, we now assume that there is only _one_ SubPacket in each MeshPacket). | Field | Type | Label | Description | @@ -279,9 +271,9 @@ MeshPacket). | channel_index | [uint32](#uint32) | | 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. 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. | | decoded | [SubPacket](#SubPacket) | | | | encrypted | [bytes](#bytes) | | | -| id | [uint32](#uint32) | | 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. | -| rx_time | [fixed32](#fixed32) | | 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) | -| rx_snr | [float](#float) | | Never* sent over the radio links. Set during reception to indicate the / SNR / of this packet. Used to collect statistics on current link waulity. | +| id | [uint32](#uint32) | | 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. | +| rx_time | [fixed32](#fixed32) | | 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) | +| rx_snr | [float](#float) | | Never* sent over the radio links. Set during reception to indicate the SNR of this packet. Used to collect statistics on current link waulity. | | hop_limit | [uint32](#uint32) | | 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. | | want_ack | [bool](#bool) | | 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 | @@ -294,23 +286,21 @@ MeshPacket). ### MyNodeInfo 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. | Field | Type | Label | Description | | ----- | ---- | ----- | ----------- | -| my_node_num | [uint32](#uint32) | | 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 | +| my_node_num | [uint32](#uint32) | | 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 | | has_gps | [bool](#bool) | | 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. | | num_channels | [int32](#int32) | | # of legal channels (set at build time in the device flash image) | | region | [string](#string) | | 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. | | hw_model | [string](#string) | | TBEAM, HELTEC, etc... | | firmware_version | [string](#string) | | 0.0.5 etc... | -| error_code | [CriticalErrorCode](#CriticalErrorCode) | | An error message we'd like to report back to the mothership through / analytics. 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) a numeric error code to go with error message, zero / means no error | +| error_code | [CriticalErrorCode](#CriticalErrorCode) | | An error message we'd like to report back to the mothership through analytics. 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 onlybe reported once) a numeric error code to go with error message, zero means no error | | error_address | [uint32](#uint32) | | A numeric error address (nonzero if available) | -| error_count | [uint32](#uint32) | | The total number of errors this node has ever encountered (well - since / the last time we discarded preferences) | +| error_count | [uint32](#uint32) | | The total number of errors this node has ever encountered (well - since the last time we discarded preferences) | | packet_id_bits | [uint32](#uint32) | | How many bits are used for the packetid. If zero it is assumed we use eight bit packetids Old device loads (older that 0.6.5 do not populate this field, but all newer loads do). | | current_packet_id | [uint32](#uint32) | | The current ID this node is using for sending new packets (exposed so that the phone can self assign packet IDs if it wishes by picking packet IDs from the opposite side of the pacekt ID space). Old device loads (older that 0.6.5 do not populate this field, but all newer loads do). FIXME: that we need to expose this is a bit of a mistake. Really the phones should be modeled/treated as 1st class nodes like any other, and the radio connected to the phone just routes like any other. This would allow all sorts of clean/clever routing topologies in the future. | | node_num_bits | [uint32](#uint32) | | How many bits are used for the nodenum. If zero it is assumed we use eight bit nodenums New device loads will user 32 bit nodenum. Old device loads (older that 0.6.5 do not populate this field, but all newer loads do). | @@ -325,6 +315,26 @@ Sent to the phone in response to WantNodes. ### NodeInfo +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 @@ -333,8 +343,14 @@ Full information about a node on the mesh | num | [uint32](#uint32) | | the node number | | user | [User](#User) | | The user info for this node | | position | [Position](#Position) | | This position data will also contain a time last seen | -| snr | [float](#float) | | 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 | -| next_hop | [uint32](#uint32) | | 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. | +| snr | [float](#float) | | 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 | +| next_hop | [uint32](#uint32) | | Returns the last measured frequency error. The LoRa receiver estimates the frequency offset between the receiver centre frequency and that of the received LoRa signal. This function 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 transmitter, the receiver or both. \return The estimated centre frequency 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. | @@ -353,7 +369,7 @@ a gps position | longitude_i | [sint32](#sint32) | | | | altitude | [int32](#int32) | | In meters above MSL | | battery_level | [int32](#int32) | | 1-100 (0 means not provided) | -| time | [fixed32](#fixed32) | | 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 | +| time | [fixed32](#fixed32) | | 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 | @@ -386,7 +402,7 @@ see sw-design.md for more information on these preferences | Field | Type | Label | Description | | ----- | ---- | ----- | ----------- | -| position_broadcast_secs | [uint32](#uint32) | | We should send our position this often (but only if it has changed significantly). Defaults to 15 minutes | +| position_broadcast_secs | [uint32](#uint32) | | We should send our position this often (but only if it has changed significantly) Defaults to 15 minutes | | send_owner_interval | [uint32](#uint32) | | Send our owner info at least this often (also we always send once at boot - to rejoin the mesh) | | wait_bluetooth_secs | [uint32](#uint32) | | Power management state machine option. See https://github.com/meshtastic/Meshtastic-device/blob/master/docs/software/power.md for details. 0 for default of 1 minute | | screen_on_secs | [uint32](#uint32) | | Power management state machine option. See https://github.com/meshtastic/Meshtastic-device/blob/master/docs/software/power.md for details. 0 for default of one minute | @@ -400,6 +416,7 @@ see sw-design.md for more information on these preferences | wifi_password | [string](#string) | | If set, will be use to authenticate to the named wifi | | wifi_ap_mode | [bool](#bool) | | If set, the node will operate as an AP (and DHCP server), otherwise it will be a station | | region | [RegionCode](#RegionCode) | | The region code for my radio (US, CN, EU433, etc...) | +| charge_current | [ChargeCurrent](#ChargeCurrent) | | Sets the current of the battery charger | | is_router | [bool](#bool) | | Are we operating as a router. Changes behavior in the following ways: The device will only sleep for critically low battery level (i.e. always tries to stay alive for the mesh) In the future routing decisions will preferentially route packets through nodes with this attribute (because assumed good line of sight) | | is_low_power | [bool](#bool) | | If set, we are powered from a low-current source (i.e. solar), so even if it looks like we have power flowing in we should try to minimize power consumption as much as possible. YOU DO NOT NEED TO SET THIS IF YOU'VE set is_router (it is implied in that case). | | fixed_position | [bool](#bool) | | If set, this node is at a fixed position. We will generate GPS position updates at the regular interval, but use whatever the last lat/lon/alt we have for the node. The lat/lon/alt can be set by an internal GPS or with the help of the app. | @@ -407,9 +424,29 @@ see sw-design.md for more information on these preferences | debug_log_enabled | [bool](#bool) | | By default we turn off logging as soon as an API client connects (to keep shared serial link quiet). Set this to true to leave the debug log outputting even when API is active. | | location_share | [LocationSharing](#LocationSharing) | | How our location is shared with other nodes (or the local phone) | | gps_operation | [GpsOperation](#GpsOperation) | | How the GPS hardware in this unit is operated. Note: This is independent of how our location is shared with other devices. For that see LocationSharing | -| gps_update_interval | [uint32](#uint32) | | How often should we try to get GPS position (in seconds) when we are in GpsOpMobile mode? or zero for the default of once every 120 seconds or a very large value (maxint) to update only once at boot. | +| gps_update_interval | [uint32](#uint32) | | How often should we try to get GPS position (in seconds) when we are in GpsOpMobile mode? or zero for the default of once every 30 seconds or a very large value (maxint) to update only once at boot. | | gps_attempt_time | [uint32](#uint32) | | How long should we try to get our position during each gps_update_interval attempt? (in seconds) Or if zero, use the default of 30 seconds. If we don't get a new gps fix in that time, the gps will be put into sleep until the next gps_update_rate window. | -| ignore_incoming | [uint32](#uint32) | repeated | For testing it is useful sometimes to force a node to never listen to particular other nodes (simulating radio out of range). All nodenums listed in ignore_incoming will have packets they send droped on receive (by router.cpp) | +| ignore_incoming | [uint32](#uint32) | repeated | If true, radio should not try to be smart about what packets to queue to the phone bool keep_all_packets = 101; + +If true, we will try to capture all the packets sent on the mesh, not just the ones destined to our node. bool promiscuous_mode = 102; + +For testing it is useful sometimes to force a node to never listen to particular other nodes (simulating radio out of range). All nodenums listed in ignore_incoming will have packets they send droped on receive (by router.cpp) | +| serialplugin_enabled | [bool](#bool) | | Preferences for the SerialPlugin + +FIXME - Move this out of UserPreferences and into a section for plugin configuration. | +| serialplugin_echo | [bool](#bool) | | | +| serialplugin_rxd | [uint32](#uint32) | | | +| serialplugin_txd | [uint32](#uint32) | | | +| serialplugin_timeout | [uint32](#uint32) | | | +| serialplugin_mode | [uint32](#uint32) | | | +| ext_notification_plugin_enabled | [bool](#bool) | | Preferences for the ExternalNotificationPlugin + +FIXME - Move this out of UserPreferences and into a section for plugin configuration. | +| ext_notification_plugin_output_ms | [uint32](#uint32) | | | +| ext_notification_plugin_output | [uint32](#uint32) | | | +| ext_notification_plugin_active | [bool](#bool) | | | +| ext_notification_plugin_alert_message | [bool](#bool) | | | +| ext_notification_plugin_alert_bell | [bool](#bool) | | | @@ -446,7 +483,7 @@ inside a radio packet (because from/to are broken out by the comms library) | route_error | [RouteError](#RouteError) | | A failure in a routed message | | position | [Position](#Position) | | Prior to 1.20 positions were communicated as a special payload type, now they are GPS_POSITION_APP Data | | user | [User](#User) | | Prior to 1.20 positions were communicated as a special payload type, now they are MESH_USERINFO_APP | -| want_response | [bool](#bool) | | 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. | +| want_response | [bool](#bool) | | 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. | | success_id | [uint32](#uint32) | | 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. | | fail_id | [uint32](#uint32) | | This is a nak, we failed to deliver this message. | | dest | [uint32](#uint32) | | 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. | @@ -461,8 +498,8 @@ inside a radio packet (because from/to are broken out by the comms library) ### ToRadio -packets/commands to the radio will be written (reliably) to the toRadio -characteristic. Once the write completes the phone can assume it is handled. +packets/commands to the radio will be written (reliably) to the toRadio characteristic. +Once the write completes the phone can assume it is handled. | Field | Type | Label | Description | @@ -482,15 +519,12 @@ characteristic. Once the write completes the phone can assume it is handled. ### User 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) +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) +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: @@ -512,7 +546,7 @@ A few nodenums are reserved and will never be requested: | Field | Type | Label | Description | | ----- | ---- | ----- | ----------- | -| id | [string](#string) | | 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> | +| id | [string](#string) | | 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> | | long_name | [string](#string) | | A full name for this user, i.e. "Kevin Hester" | | short_name | [string](#string) | | A VERY short name, ideally two characters. Suitable for a tiny OLED screen | | macaddr | [bytes](#bytes) | | This is the addr of the radio. Not populated by the phone, but added by the esp32 when broadcasting | @@ -532,10 +566,38 @@ Note: these mappings must match ModemConfigChoice in the device code. | Name | Number | Description | | ---- | ------ | ----------- | -| Bw125Cr45Sf128 | 0 | < Bw = 125 kHz, Cr = 4/5, Sf = 128chips/symbol, CRC | -| Bw500Cr45Sf128 | 1 | < Bw = 500 kHz, Cr = 4/5, Sf = 128chips/symbol, CRC | -| Bw31_25Cr48Sf512 | 2 | < Bw = 31.25 kHz, Cr = 4/8, Sf = 512chips/symbol, | -| Bw125Cr48Sf4096 | 3 | < Bw = 125 kHz, Cr = 4/8, Sf = 4096chips/symbol, CRC | +| Bw125Cr45Sf128 | 0 | < Bw = 125 kHz, Cr = 4/5, Sf(7) = 128chips/symbol, CRC < on. Default medium range (5.469 kbps) | +| Bw500Cr45Sf128 | 1 | < Bw = 500 kHz, Cr = 4/5, Sf(7) = 128chips/symbol, CRC < on. Fast+short range (21.875 kbps) | +| Bw31_25Cr48Sf512 | 2 | < Bw = 31.25 kHz, Cr = 4/8, Sf(9) = 512chips/symbol, < CRC on. Slow+long range (275 bps) | +| Bw125Cr48Sf4096 | 3 | < Bw = 125 kHz, Cr = 4/8, Sf(12) = 4096chips/symbol, CRC < on. Slow+long range (183 bps) | + + + + + +### ChargeCurrent +Sets the charge control current of devices with a battery charger that can be +configured. This is passed into the axp power management chip like on the tbeam. + +| Name | Number | Description | +| ---- | ------ | ----------- | +| MAUnset | 0 | | +| MA100 | 1 | | +| MA190 | 2 | | +| MA280 | 3 | | +| MA360 | 4 | | +| MA450 | 5 | | +| MA550 | 6 | | +| MA630 | 7 | | +| MA700 | 8 | | +| MA780 | 9 | | +| MA880 | 10 | | +| MA960 | 11 | | +| MA1000 | 12 | | +| MA1080 | 13 | | +| MA1160 | 14 | | +| MA1240 | 15 | | +| MA1320 | 16 | | @@ -569,7 +631,7 @@ post on the meshtastic.discourse.group and we'll try to help. | UBloxInitFailed | 5 | We failed while configuring a UBlox GPS | | NoAXP192 | 6 | This board was expected to have a power management chip and it is missing or broken | | InvalidRadioSetting | 7 | The channel tried to set a radio setting which is not supported by this chipset, radio comms settings are now undefined. | -| TransmitFailed | 8 | Radio transmit hardware failure. We sent data to the radio chip, but it didn't reply with an interrupt. | +| TransmitFailed | 8 | Radio transmit hardware failure. We sent data to the radio chip, but it didn't reply with an interrupt. | @@ -577,12 +639,14 @@ post on the meshtastic.discourse.group and we'll try to help. ### GpsOperation How the GPS hardware in this unit is operated. - Note: This is independent of how our location is shared with other devices. For that see LocationSharing | Name | Number | Description | | ---- | ------ | ----------- | | GpsOpUnset | 0 | This is treated as GpsOpMobile - it is the default settting | +| GpsOpStationary | 1 | Note: This mode was removed, because it is identical go GpsOpMobile with a gps_update_rate of once per day + +This node is mostly stationary, we should try to get location only once per day, Once we have that position we should turn the GPS to sleep mode This is the recommendated configuration for stationary 'router' nodes | | GpsOpMobile | 2 | This node is mobile and we should get GPS position at a rate governed by gps_update_rate | | GpsOpTimeOnly | 3 | We should only use the GPS to get time (no location data should be acquired/stored) Once we have the time we treat gps_update_interval as MAXINT (i.e. sleep forever) | | GpsOpDisabled | 4 | GPS is always turned off - this mode is not recommended - use GpsOpTimeOnly instead | @@ -685,8 +749,7 @@ If you are making a new app using meshtastic, please send in a pull request to a master table. PortNums should be assigned in the following range: 0-63 Core Meshtastic use, do not use for third party apps -64-127 Registered 3rd party apps, send in a pull request that adds a new entry to portnums.proto to -register your application +64-127 Registered 3rd party apps, send in a pull request that adds a new entry to portnums.proto to register your application 256-511 Use one of these portnums for your private applications that you don't want to register publically All other values are reserved. @@ -699,13 +762,28 @@ This change is backwards compatible by treating the legacy OPAQUE/CLEAR_TEXT val | Name | Number | Description | | ---- | ------ | ----------- | | UNKNOWN_APP | 0 | Deprecated: do not use in new code (formerly called OPAQUE) A message sent from a device outside of the mesh, in a form the mesh does not understand NOTE: This must be 0, because it is documented in IMeshService.aidl to be so | -| TEXT_MESSAGE_APP | 1 | a simple UTF-8 text message, which even the little micros in the mesh can understand and show on their screen eventually in some circumstances even signal might send messages in this form (see below) Formerly called CLEAR_TEXT | -| REMOTE_HARDWARE_APP | 2 | Reserved for built-in GPIO/example app. See remote_hardware.proto/HardwareMessage for details on the message sent/received to this port number | +| TEXT_MESSAGE_APP | 1 | A simple UTF-8 text message, which even the little micros in the mesh can understand and show on their screen eventually in some circumstances even signal might send messages in this form (see below) Formerly called CLEAR_TEXT | +| REMOTE_HARDWARE_APP | 2 | A message receive acknowledgement, sent in cleartext - allows radio to show user that a message has been read by the recipient, optional + +Note: this concept has been removed for now. Once READACK is implemented, use the new packet type/port number stuff? + +@exclude + +CLEAR_READACK = 2; + +Reserved for built-in GPIO/example app. See remote_hardware.proto/HardwareMessage for details on the message sent/received to this port number | | POSITION_APP | 3 | The built-in position messaging app. See Position for details on the message sent to this port number. | | NODEINFO_APP | 4 | The built-in user info app. See User for details on the message sent to this port number. | | REPLY_APP | 32 | Provides a 'ping' service that replies to any packet it receives. Also this serves as a small example plugin. | | IP_TUNNEL_APP | 33 | Used for the python IP tunnel feature | +| SERIAL_APP | 64 | Provides a hardware serial interface to send and receive from the Meshtastic network. Connect to the RX/TX pins of a device with 38400 8N1. Packets received from the Meshtastic network is forwarded to the RX pin while sending a packet to TX will go out to the Mesh network. Maximum packet size of 240 bytes. + +Maintained by Jm Casler (MC Hamster) : jm@casler.org | +| STORE_REQUEST_APP | 65 | STORE_REQUEST_APP (Work in Progress) + +Maintained by Jm Casler (MC Hamster) : jm@casler.org | | PRIVATE_APP | 256 | Private applications should use portnums >= 256. To simplify initial development and testing you can use "PRIVATE_APP" in your code without needing to rebuild protobuf files (via bin/regin_protos.sh) | +| ATAK_FORWARDER | 257 | ATAK Forwarder Plugin https://github.com/paulmandal/atak-forwarder | @@ -730,12 +808,10 @@ A example app to show off the plugin system. This message is used for REMOTE_HAR Also provides easy remote access to any GPIO. -In the future other remote hardware operations can be added based on user interest -(i.e. serial output, spi/i2c input/output). +In the future other remote hardware operations can be added based on user interest (i.e. serial output, spi/i2c input/output). -FIXME - currently this feature is turned on by default which is dangerous because no security yet (beyond the -channel mechanism). It should be off by default and then protected based on some TBD mechanism (a special channel -once multichannel support is included?) +FIXME - currently this feature is turned on by default which is dangerous because no security yet (beyond the channel mechanism). +It should be off by default and then protected based on some TBD mechanism (a special channel once multichannel support is included?) | Field | Type | Label | Description | From 9837b5bb01ab8824a66fbb2ccab8613bcaf87ed5 Mon Sep 17 00:00:00 2001 From: Sacha Weatherstone Date: Tue, 2 Feb 2021 21:19:47 +1100 Subject: [PATCH 26/32] Fix formatting --- mesh.proto | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/mesh.proto b/mesh.proto index 68a05c2..3eb8b5b 100644 --- a/mesh.proto +++ b/mesh.proto @@ -959,8 +959,10 @@ enum CriticalErrorCode { */ InvalidRadioSetting = 7; - // Radio transmit hardware failure. We sent data to the radio chip, but it didn't - // reply with an interrupt. + /* + * Radio transmit hardware failure. We sent data to the radio chip, but it didn't + * reply with an interrupt. + */ TransmitFailed = 8; } From 8b9207aa5d50a97b07bab99f35627038d83b04a0 Mon Sep 17 00:00:00 2001 From: Sacha Weatherstone Date: Tue, 2 Feb 2021 21:22:25 +1100 Subject: [PATCH 27/32] Make oneOf property naming consistant --- mesh.proto | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/mesh.proto b/mesh.proto index 3eb8b5b..ce26602 100644 --- a/mesh.proto +++ b/mesh.proto @@ -162,7 +162,7 @@ message SubPacket { /* * Only one of the following fields can be populated at a time */ - oneof payload { + oneof payloadVariant { Data data = 3; @@ -201,7 +201,7 @@ message SubPacket { */ bool want_response = 5; - oneof ack { + oneof ackVariant { /* * This packet is a requested acknoledgement indicating that we have received * the specified message ID. This packet type can be used both for immediate @@ -281,7 +281,7 @@ message MeshPacket { * The numeric IDs for these fields were selected to keep backwards compatibility with old applications. */ - oneof payload { + oneof payloadVariant { SubPacket decoded = 3; bytes encrypted = 8; } @@ -1128,7 +1128,7 @@ message FromRadio { */ uint32 num = 1; - oneof variant { + oneof payloadVariant { MeshPacket packet = 2; @@ -1181,7 +1181,7 @@ message FromRadio { */ message ToRadio { - oneof variant { + oneof payloadVariant { /* * send this packet on the mesh From 923e650abd99368d160c62168040f2df55a71164 Mon Sep 17 00:00:00 2001 From: Jm Casler Date: Fri, 5 Feb 2021 17:56:17 -0800 Subject: [PATCH 28/32] Update portnums.proto --- portnums.proto | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/portnums.proto b/portnums.proto index 7ffc294..2151a22 100644 --- a/portnums.proto +++ b/portnums.proto @@ -88,11 +88,11 @@ enum PortNum { SERIAL_APP = 64; /* - * STORE_REQUEST_APP (Work in Progress) + * STORE_FORWARD_APP (Work in Progress) * * Maintained by Jm Casler (MC Hamster) : jm@casler.org */ - STORE_REQUEST_APP = 65; + STORE_FORWARD_APP = 65; /* * Private applications should use portnums >= 256. From fcda45a3cc5f559477a037fd504f54b8d63b5663 Mon Sep 17 00:00:00 2001 From: Kevin Hester Date: Sun, 7 Feb 2021 09:45:08 +0800 Subject: [PATCH 29/32] add NO_INTERFACE error reason in support of https://github.com/meshtastic/Meshtastic-device/issues/677 --- mesh.proto | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/mesh.proto b/mesh.proto index 68a05c2..eead5ab 100644 --- a/mesh.proto +++ b/mesh.proto @@ -136,8 +136,9 @@ message RouteDiscovery { repeated int32 route = 2; } -enum RouteError { +enum ErrorReason { + /** This message is not a failure */ NONE = 0; /* @@ -151,6 +152,9 @@ enum RouteError { GOT_NAK = 2; TIMEOUT = 3; + + /* No suitable interface could be found for delivering this packet */ + NO_INTERFACE = 4; } /* @@ -179,9 +183,10 @@ message SubPacket { RouteDiscovery route_reply = 7; /* - * A failure in a routed message + * 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). */ - RouteError route_error = 13; + ErrorReason error_reason = 13; /* * Prior to 1.20 positions were communicated as a special payload type, now they are GPS_POSITION_APP Data From 106f4bfdebe277ab0b86d2b8c950ab78a35b0654 Mon Sep 17 00:00:00 2001 From: Kevin Hester Date: Sun, 7 Feb 2021 10:05:41 +0800 Subject: [PATCH 30/32] add MAX_RETRANSMIT error code --- mesh.proto | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/mesh.proto b/mesh.proto index eead5ab..cc2a217 100644 --- a/mesh.proto +++ b/mesh.proto @@ -136,9 +136,13 @@ message RouteDiscovery { repeated int32 route = 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). + */ enum ErrorReason { - /** This message is not a failure */ + /* This message is not a failure */ NONE = 0; /* @@ -155,6 +159,9 @@ enum ErrorReason { /* No suitable interface could be found for delivering this packet */ NO_INTERFACE = 4; + + /* We reached the max retransmission count (typically for naive flood routing) */ + MAX_RETRANSMIT = 5; } /* From 8e5d7d1189bf13a547049136cfcca1a24314df06 Mon Sep 17 00:00:00 2001 From: Jm Casler Date: Sat, 6 Feb 2021 20:39:38 -0800 Subject: [PATCH 31/32] Add configurations for RangeTestPlugin & StoreForwardPlugin --- mesh.proto | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/mesh.proto b/mesh.proto index cc2a217..88a78c7 100644 --- a/mesh.proto +++ b/mesh.proto @@ -845,6 +845,21 @@ message RadioConfig { bool ext_notification_plugin_alert_message = 130; bool ext_notification_plugin_alert_bell = 131; + /** + Preferences for the RangeTestPlugin + + FIXME - Move this out of UserPreferences and into a section for plugin configuration. + */ + bool range_test_plugin_enabled = 132; + bool range_test_plugin_sender = 133; + + /** + Preferences for the StoreForwardPlugin + + FIXME - Move this out of UserPreferences and into a section for plugin configuration. + */ + bool store_forward_plugin_enabled = 136; + bool store_forward_plugin_records = 137; } UserPreferences preferences = 1; From 29f4bc5a8092c1454db2103739f33b208942dfbc Mon Sep 17 00:00:00 2001 From: Jm Casler Date: Sat, 6 Feb 2021 21:42:17 -0800 Subject: [PATCH 32/32] Changes for range_test_plugin and store_forward_plugin --- mesh.proto | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/mesh.proto b/mesh.proto index 88a78c7..5c1b4d7 100644 --- a/mesh.proto +++ b/mesh.proto @@ -851,7 +851,8 @@ message RadioConfig { FIXME - Move this out of UserPreferences and into a section for plugin configuration. */ bool range_test_plugin_enabled = 132; - bool range_test_plugin_sender = 133; + uint32 range_test_plugin_sender = 133; + bool range_test_plugin_save = 134; /** Preferences for the StoreForwardPlugin @@ -859,7 +860,7 @@ message RadioConfig { FIXME - Move this out of UserPreferences and into a section for plugin configuration. */ bool store_forward_plugin_enabled = 136; - bool store_forward_plugin_records = 137; + uint32 store_forward_plugin_records = 137; } UserPreferences preferences = 1;