MeshTastic Message Algorithm:

[last updated: 2025-12-29]
Disclaimers
MeshTastic home page
----------

• Message structure:
  • The header for a message is unencrypted and contains several key parameters:
    details here: https://meshtastic.org/docs/overview/mesh-algo/
    • Destination NodeID (4 bytes):
      Identifies the intended recipient node (or 0xFFFFFFFF for broadcast).
    • Sender NodeID (4 bytes):
      Identifies the originating node.
    • Packet ID (4 bytes): A unique ID for the message packet.
    • Flags (1 byte):
      Hop Limit (3 bits)
      WantAck (1 bit)
      viaMQTT (1 bit)
      Hop Start - orig hop limit (3 bits)
    • Channel Hash (1 byte): Used to identify the channel, if private channels are being used.
    • Next Hop (newer firmware) used for relaying (1 byte): "A hint for efficient relaying, reducing unnecessary rebroadcasts."
    • Relay Node of Current Transmission (1 byte): [not sure how this is used]
  • Message Payload:
    • The message itself is encrypted.
    • If the message is intended for some specific recipient,
      then its encryption will be the public key of the recipient.
    • If the message is intended for some private channel,
      then it's encryption will be key specific to its intended channel.

  -------------------------

• Channels:
  • Every message sent will be assigned to a channel, and that channel is specified in the message header as shown above.

    Channels can be used to define groups of recipient nodes who can decode a message,
    and any other nodes that receive the message will not be able to decode it,
    (? though presumably they will be able to rebroadcast it...?)

  • If no private channels/groups are defined, a given message will by default to assigned to channel 0
    which by default is an unencrypted channel.
  • Up to 7 additional channels can be defined, with encryption set as desired.
  • Channels are configured with 3 parameters: Index, Role, and Settings
  • See: https://meshtastic.org/docs/configuration/radio/channels/
    for a note about how the primary channel is somehow involved it setting the frequency band of the node
    -------------------
  • Index:
    Integer, 0 to 7
  • Roles:
    • Every channel has a Role defined. A role can be: "Primary" (1), "Secondary" (2), or "Disabled" (0)
    • The default Channel 0 is Primary, and cannot be disabled.
    • At startup, all other channels are Disabled.
    • When you define a channel for some desired group of recipients, its role becomes Secondary, and you can define a custom, private encryption key for it.
    • Active channel designations must be consecutive. That is, you cannot have a disabled channel between two active channels.

    -------------------

  • Channel setting options:
    • There are 4 channel settings: Name, PSK, Downlink Enabled, and Uplink Enabled.
      Uplink and Downlink settings configure behavior dealing with gateways.
      -------------------
    • Name:
      • less than 12 bytes
      • if left blank on the Primary channel, this designates it as the default channel
        (not sure meaning/implication of this ...)
        Common practice is to set channel 0 name to "LongFast" and use it as a 'public' channel.
      • two nodes trying to communicate on a given channel
        must both have the same channel name (and PSK and LoRa frequency) defined for that channel
    • PSK: ("Pre-Shared Key")
      Specifies encryption encode/decode key for the channel.
      Must be either 0 bytes (no encryption), 16 bytes (AES128), or 32 bytes (AES256).
      Hex byte 0x01 for the Primary default channel.

  -------------------------

• Message transmission protocol/algorithm:
  • for more details see: https://meshtastic.org/docs/overview/mesh-algo/
    ----------------------
  • When a message is sent from a given node, if will be received by any number of other nodes in the mesh that are in range.
  • ...? a receiving node will send an acknowledgment ... ?
  • ...? the receiving node will decrement the rebroadcast counter ...?
  • Each of those nodes, if they are not the intended recipient, will rebroadcast the message (if rebroadcast count > 0)
    • Those rebroadcasts will in turn be received by other nodes, even more distant, which in turn will continue to rebroadcast the message until its limit is reached (see explanation elsewhere...), or until the intended recipient receives the message.
      But...
      The receiving node will assess the signal strength of the sending transmission, and will delay re-broadcast for some time, inversely proportional to the signal strength.
      That is, if the signal strength from the sending node is high, the receiving node will delay longer before rebroadcasting.
    • When a message received by a node is rebroadcast, it will send node info, telemetry, non-precise node location, and the message itself.
      If the message is from a private (encrypted) channel, or a DM (also encrypted), then the receiving node will not be able to read the messages, but it will still rebroadcast them.

  --------------------------------

  
  .

  eof