Meshtastic is a relatively new open-source project that allows long range communication between devices using LoRa-based spread spectrum techniques. In Meshtastic, devices form a mesh network where network traffic is relayed between nodes. The low power level requirements allow Meshtastic devices to operate in license-free portions of the spectrum, which allows greater access to the general public because the main cost incurred is purchasing equipment.The typical Meshtastic setup consists of a cell phone running the Meshtastic app and a LoRa radio running the latest Meshtastic firmware. Users can send text messages between phones without the need for a cellular connection. 

In Meshtastic, there is no way to know if packets were successfully delivered to the destination. ACKs may be requested, but are optional. Unfortunately, ACKs are only sent a maximum of one hop in the network so it is possible that the original sender may never know if their message was delivered (the number of hops determines the time to live in the network, and is programmed by the user. While more hops means the message will traverse nodes in the network and potentially reach longer distances). Because Meshtastic is based on a managed flooding [1] technique, ACKs lasting more than one hop may create congestion in high traffic networks; therefore the current Meshtastic source code restricts this feature to a maximum of one hop. Contrast this with IEEE 802.11s, where ACKs may be sent over TCP for reliable message delivery. While Meshtastic is affordable and readily-available, it could benefit from some additional features. 

As Meshtastic is a relatively new project, there are no peer-reviewed papers that directly address the concept of ACKs in a Meshtastic network or compare it against 802.11s.

• Update 1: Feb 21. Research and investigate Meshtastic network and 802.11s

• Update 2: March 7. Complete capture of packets in Meshtastic network 

• Update 3: March 21. Experiment with the Meshtastic simulator

• Presentation: April 4. Present findings and comparison with 802.11s.

• Report: April 11

We successfully flashed firmware version v2.5.20.4c97351 onto the Station G1, an ESP32-based device from Unit Engineering. The G1 is capable of transmitting at +35dBm (3 watts of RF power) and can be powered from a 5VDC USB connection or a 15VDC USB-C connection. Using the Meshtastic command line interface (CLI), we logged all traffic heard by the G1 to a text file over a period of 30 hours. This length of time was necessary because the Meshtastic algorithm limits the amount of communication that can take place, for a few reasons: the 900MHz spectrum is shared with non-Meshtastic devices, and as a result is very crowded; Meshtastic is not designed for real-time (or near real-time) use-cases where rapid updates flood the network with traffic. Some types of Meshtastic packets are only sent every six hours. Therefore, to build a complete picture of the local network, a Meshtastic node should be left on for at least 12 hours. 

The raw log file consists of 6786 lines where groups of lines are identified by their packet type. There are six types of packets:

• RadioIf: Identifies when the LoRa radio is actively transmitting packets to the mesh. Contains details including unique Packet IDs, destination of packet, origin of packet, hop limit, and others. Our measurements indicate these packets are sent regularly every 36 minutes. There are some cases where packets were sent every 540 seconds, which we are currently investigating. 

• DeviceTelemetry: These packets typically would contain data from a sensor or module that is connected to the Meshtastic device. The update interval is configurable by the user. 

• NeighborInfo: Similar to a routing table where each node maintains information about other nodes in the vicinity. Nodes broadcast NeighborInfo packets typically every six hours and will delete neighbors from their table if the node has not sent a NeighborInfo packet in a while. While the interval can be customized by the user, it cannot be set lower than six hours (to avoid congestion). Our measurements indicate these packets were sent every 21600 seconds, or every six hours. 

• AirTime: records the channel usage and helps ensure transmissions do not exceed regulatory limits over a specific period of time. The airtime packets are sent every 60 minutes according to our measurements. 

• NodeInfo: Contains information about the RSSI of other nodes. These packets are sent every three hours. 

• Power: Contains details about the power source of for the Meshtastic device, including battery level, USB status, charging status, and fatal errors such as short circuit condition. 

Because the power status packets do not help build a picture of the network, we made a python script to filter out all 5369 of these packets. Our new logfile consisted of 1417 lines. While this appears to be a highly active network, the logfile is deceiving; each line does not correspond to an individual packet because the device is logging other statistics associated with the packet. The time between packets effectively separates transmissions based on the uptime of the device, in seconds. 

In our original project plan, we aimed to capture and log Meshtastic packets from the local network in Victoria, BC. However, because we acquired hardware quicker than anticipated, we completed this step earlier than expected in our first update. As a result, we amended our second update to focus on modifying the Meshtastic source code to allow multi-hop acknowledgments (ACKs) when nodes wish to receive confirmation that their message was delivered. This is a significant undertaking and will likely continue into update III.

We successfully downloaded the Meshtastic firmware and created our own fork to edit and test, which we uploaded to GitHub as a separate repository: https://github.com/CSC-370-project/source-code. Our first goal was to enable multi-hop ACKs, which are currently unavailable in Meshtastic. To achieve this, we began modifying RoutingModule.cpp and FloodingRouter.cpp to allow acknowledgments to propagate beyond a single hop. After deploying the modified firmware and logging network traffic over a 24-hour period, we confirmed that ACKs successfully traveled multiple hops, improving delivery confirmation without significantly increasing congestion. Moving forward, we will refine the rebroadcasting logic to optimize network performance while maintaining efficiency.

[1] Meshtastic. (n.d.). Mesh algorithm. Meshtastic Documentation. Retrieved February 4, 2025, from https://meshtastic.org/docs/overview/mesh-algo/

[2] A. Ranjitkar and Y. -B. Ko, "Performance Enhancement of IEEE 802.11s Mesh Networks using Aggressive Block Ack Scheme," 2008 International Conference on Information Networking, Busan, Korea (South), 2008, pp. 1-5, doi: 10.1109/ICOIN.2008.4472814. keywords: {Mesh networks;Throughput;Wireless mesh networks;Data communication;Wireless LAN;Communication system control;Degradation;Next generation networking;Availability;Telecommunication network reliability},