From 2e15426fe3eb300dc71668892b5aafe95155530b Mon Sep 17 00:00:00 2001 From: Kevin Hester Date: Fri, 29 Jan 2021 10:11:10 +0800 Subject: [PATCH] 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