What is TAK?​

The Team Awareness Kit (TAK) is a geospatial mapping and situational awareness platform originally developed for the U.S. military. It has since been adopted by first responders, search and rescue teams, disaster relief organizations, and outdoor enthusiasts. TAK applications display team members' positions on a shared map, allow placement of markers and annotations, and support text messaging—all using the Cursor on Target (CoT) protocol.

iTAK and TAK Aware are the two main iOS options for this platform, providing a subset of the same powerful ATAK capabilities on iPhone and iPad.

Why TAK and Meshtastic?​

TAK traditionally relies on network connectivity or dedicated servers. But what happens when you're:

• Deep in the backcountry with no cell service?
• Responding to a disaster where infrastructure is down?
• Operating in remote areas beyond traditional network reach?

This is where Meshtastic shines! Our mesh radios can communicate over long distances without any infrastructure, hopping messages through the network until they reach their destination.

The Challenge: A Tale of Two Platforms​

On Android, integrating Meshtastic with ATAK is straightforward. ATAK's plugin architecture allows the Meshtastic ATAK plugin to hook directly into the app, bridging mesh communication seamlessly. Android users have enjoyed this capability for years.

iOS tells a different story. Apple's sandboxing and app isolation prevent apps from loading external plugins the way Android/ATAK can. This left iOS users without a path to TAK integration—until now.

One does not simply add a plugin to iOS - Boromir

The Solution: TAK Inside the Meshtastic App​

The new TAK integration in Meshtastic iOS creates a bridge between these two worlds:

How It Works​

Our solution was to build a TAK server directly into the Meshtastic iOS app!

When you enable the TAK Server feature, the Meshtastic app spins up a local TAK-compliant server endpoint on your device. iTAK and TAK Aware connect directly to this local server just as they would connect to any cloud-based TAK server—no special configuration or workarounds required from the user's perspective.

Behind the scenes, the integration handles the translation between TAK's CoT XML protocol and Meshtastic's wire-optimized mesh packets. The result is transparent to users, TAK clients simply work, as if connected to a traditional TAK server.

Key Features​

Position Sharing (PLI)​

Your location from TAK is automatically shared across the mesh. Team members running ATAK on Android or TAK clients on other iOS devices will see your position update in real-time on their maps—no cell towers required.

GeoChat Messaging​

Send and receive text messages between TAK clients through the mesh. Whether you're coordinating a search grid or checking in with base camp, messages flow seamlessly across the mesh network into your connected TAK clients.

Markers / Points of Interest​

Drop a marker in iTAK or TAK Aware for a found item, hazard, or rally point—it propagates through the mesh to all connected TAK clients automatically.

Getting Started​

1. Update your node's firmware to the latest version using the Web Flasher
2. Update to the latest Meshtastic iOS app from the App Store
3. Setup your primary channel. This is the channel your node will use to communicate with the mesh network
4. Configure your LoRa configuration settings to a higher bandwidth preset like Short Fast or Short Turbo for optimal performance with TAK integration
5. Configure your TAK settings in the app (Settings → Scroll to the bottom: TAK Server) and start the TAK Server
6. Connect iTAK or TAK Aware to the Meshtastic app's local TAK endpoint by downloading the Data Package from the app and importing it into your TAK client
7. Go off-grid with full situational awareness!

What's Next​

This is just the beginning. We're working on a second iteration of Meshtastic's native TAK protocol layer, bringing even tighter integration and wire optimization to the ecosystem. Stay tuned for more updates as we continue bridging these two powerful platforms.

That’s exactly what Zero-Cost Hops unlocks for your mesh.

TL;DR​

This feature improves message reach by preserving hops remaining between favorited routers.

Why does this matter?​

• The faster presets like SHORT_FAST and SHORT_TURBO trade range for speed. In dense metro deployments that means you can burn through the 7-hops quickly.
• Zero-Cost Hops turns a mesh of well-placed infrastructure routers into a single hop leaving more hops for the first and last mile.
• For well managed networks, this could allow for communication between cities, or even countries, while staying within the 7 hop limit.
• Helps prevent CLIENT_BASE from becoming the last hop of a packet, so messages don’t die on the roof before reaching your indoor nodes.

When Do Zero-Cost Hops Apply?​

A hop is preserved if all of these are true:

1. Node role is ROUTER, ROUTER_LATE, or CLIENT_BASE.
2. Not the very first hop of the packet.
3. Previous relay is in your favorites and is ROUTER or ROUTER_LATE.

Miss any one of those and the hop meter ticks down as usual.

What It Doesn’t Touch​

• CLIENT_BASE rebroadcast rules stay exactly the same. CLIENT_BASE uses from/to, while Zero-Cost Hops uses relay_node.
  • Favoriting a router does not cause CLIENT_BASE nodes to rebroadcast all packets.
• Maximum Hop limit is still 7.

“Favorite” Detection and implementation​

To keep the protobufs small and memory efficient, the node matches the relay_node against your favorites list and verifies the node is infrastructure.

With only 8 bits to work with in relay_node, there is a chance of collisions.

• The odds any one favorite collides with a random node is possible and increases as favorites increase.
• Colliders still need to be within range of the router to matter.
• Deduplication avoids loops.
• Accidental collisions are rare and harmless.

Probability of a collision in a sample environment:

Note: "Total Nodes" is the network size; collision probability is calculated based on the number of favorite routers within range, not all nodes divided by 256. For example, with 1000 total nodes and 6 favorite routers, the chance a random relay_node matches a favorite within range is about 2.3%.

Chances of a collision here is rare.

Two Quick Scenarios​

1. Metro Simple Example Downtown​

Setup

• Routers R1 and R2 use the ROUTER role and are favorited (to each other).
• Sender uses the CLIENT role and wants to chat with a friend in the next town.

Path

CLIENT → R1 → R2 → CLIENT

Hop Route starting at 4 maximum hops

Result: A hop is saved between R1 and R2 leaving an extra hop in case it is needed.

2. Home Base, Hill-Top Backbone​

Setup

• Roof nodes use the CLIENT_BASE role and have favorited the local ROUTER nodes.
• Each hilltop uses the ROUTER role and favorites each other.
• All other nodes use the CLIENT role.

Hop Route starting at 7 maximum hops

This demonstrates the ability to go beyond the 7 hop protocol limit

How to Put It to Work​

1. Assign roles deliberately

   • ROUTER for high mountaintop sites.
   • ROUTER_LATE for filling in the gaps.
   • CLIENT_BASE at home; favorite your handhelds.

2. Curate your favorites
   Mutually favorite all the infrastructure router nodes and add them to your CLIENT_BASE roof node as favorites.

3. Test and trace
   Run a traceroute before/after favoriting. Watch hops vanish.

Safety Nets Still Apply​

• Early/default/late timing is still in effect.
• Packet deduplication works as expected.
• Most impactful with nodes in high places, so abuse is unlikely with well managed networks.

FAQ​

Can I raise the hop limit beyond seven?
Nope, it's still seven. You just get more mileage out of each hop.

Won’t this flood the mesh?
Not likely for well managed networks.

Do I need firmware changes?
Not for clients. Only ROUTER, ROUTER_LATE, and CLIENT_BASE nodes need to be upgraded to at least 2.7.11 to support this feature.

Does CLIENT_BASE count as infrastructure?
For incoming favorited traffic from routers, yes. This avoids messages dying on the roof before reaching your indoor nodes.

Does traceroute still work?
Zero-cost hops have no effect on traceroute other than traceroute itself is limited to 7 hops.

Real-world example​

For Bay Mesh, there are over 700 nodes between Tahoe and San Luis Obispo. With careful placement of routers it is possible to have messages span over 300 miles that can only be accomplished on LoRa using zero-cost hops given the terrain and distance.

Using Meshview hosted by bayme.sh you can see the zero-cost hops in action between San Francisco, San Luis Obispo, and Tahoe.

Ready to Experiment?​

Pick two or three strategic infrastructure nodes and favorite them to each other mutually. Watch as hops are not consumed between the routers. Do the same for your roof CLIENT_BASE node and receive more messages than before.

Happy meshing. May your friends always be within range.

Meshtastic has a large number of device roles, each designed for a different purpose. While the default CLIENT is a good start for simpler meshes without complex obstacles to work around, for larger meshes with more complex routing needs it's important to select the right role to ensure that the overall mesh is robust, does not get overloaded, and ensures the reliable transit of packets to where they need to go.

What is the purpose of ROUTER_LATE?​

ROUTER_LATE is designed as an infrastructure role for serving parts of larger or more complex meshes that do not have visibility to existing ROUTER sites. This could be e.g. a cluster of nodes on the other side of a hill, at the bottom of a canyon, or otherwise blocked by some significant obstacle. It is a mandatory-rebroadcast role, meaning that it will always rebroadcast any packet that it hears (provided that the hop limit for that packet has not been exceeded).

It is intended to be deployed in sites that do not have the very large coverage footprint typically suited to ROUTER nodes. Sites that are critical for reliable passage of traffic, but known to not be optimally sited for serving the overall mesh, should use ROUTER_LATE.

It is not intended as a rooftop node to extend the range of devices inside your house. Using it in this manner may be great for you, but because ROUTER_LATE will rebroadcast every single packet that it can, it can add significantly to the overall airtime use in your area. Too much of this can rapidly lead to a degraded or unusable mesh due to congestion, which causes collisions and packet loss. Please refrain from using infrastructure roles in locations where they are not genuinely warranted, especially on meshes that use a slower modulation (e.g. LONG_FAST).

If you need a rooftop node for some reason, please look into the new CLIENT_BASE role, which is designed for that purpose.

Rebroadcast timing, and how ROUTER_LATE works​

Due to the extremely limited bandwidth available, Meshtastic networks do not utilise complex routing algorithms that rely on additional communication between nodes. There is no equivalent to protocols such as OSPF, BGP etc. from the IP networking world (see here for why). Instead, Meshtastic uses a combination of role selection, random delays, and timing based on the signal strength of a received packet to ensure that any given packet will be more likely to take a more efficient path across the network, while minimising unnecessary rebroadcasts that can add to congestion on the single frequency that is shared by the entire mesh.

Any packet that is received with a remaining hop limit greater than zero is eligible for rebroadcast. Packets with a hop limit of zero are discarded after processing, and are not rebroadcast at all.

Contention Windows​

Meshtastic has three different 'contention windows' in which a packet may be sent. These windows can be best thought of as slices of time since the packet was received. They do not overlap.

With the exception of ROUTER_LATE, all roles will only perform rebroadcasting within the window to which their role relates. ROUTER_LATE is a special case: under normal circumstances, it will behave identically to a CLIENT, and will attempt to rebroadcast within the default contention window, using the same timing behaviour as CLIENT. However, if it hears another node rebroadcasting the packet first (in any prior window), then it will defer its own rebroadcast of that packet to the late contention window instead. Within that late window, it will still use the same timing behaviour as CLIENT.

This has the effect of ensuring that ROUTER_LATE will politely 'give way' to other nodes, thereby preserving the normal routing behaviour of the mesh. Other than the obviously higher airtime used, the impact of deploying a ROUTER_LATE node is identical to as if a CLIENT were deployed at that location.

*CLIENT_BASE will only rebroadcast in the early window if the packet is to or from a favourite node. In all other situations, it will behave the same as a regular CLIENT, and use the normal window.

Random timing and SNR bias​

Within each contention window, a random delay is added before rebroadcasting a packet. That delay is then modified based on the signal-to-noise ratio (SNR) of the packet when it was received, with packets having a worse SNR (which typically corresponds to a worse or more distant link) ending up with a shorter delay, and high quality signals having a longer delay.

The purpose of this is to ensure that, when a packet is heard by multiple other nodes, they mostly do not try to transmit at the same time, and that nodes which are further away are given 'first dibs' at rebroadcasting. While SNR is not an ideal proxy for distance, it does have a rough correlation, and will result - on average - in packets travelling further with each hop than they would using random timing alone.

Rebroadcast cancellation / move to late contention window​

In order to ensure that the single, shared frequency is not overloaded, all roles other than ROUTER, REPEATER, and ROUTER_LATE (and CLIENT_BASE when the packet is to or from a favourite node) will cancel rebroadcasting and discard the packet if they hear another node rebroadcasting it.

ROUTER_LATE will, instead of cancelling its rebroadcast, defer it to the late contention window if it hears another node rebroadcasting the packet.

When packets are dropped​

While ROUTER_LATE will normally rebroadcast everything it hears, there are some specific exceptions:

1. If the packet arrives with a hop limit of zero. These packets are considered to have reached the end of the line, and are not supposed to be passed on any further.
2. If the TX (transmit) queue is full, and another packet arrives that is both eligible for rebroadcast, and has a higher priority than the lowest-priority packet in the TX queue, then the lowest-priority packet in the queue is discarded. This typically happens on busy meshes, or meshes that use a slower modulation configuration. ROUTER_LATE is particularly prone to this, because it stores deferred packets in the TX queue while waiting for the opportunity to transmit them during the late contention window.

Frequently asked questions​

Why can't I use this on my roof?​

Because ROUTER_LATE tries to rebroadcast everything it hears, it adds a notable amount of traffic to the single, shared frequency used by the mesh. This can cause problematic congestion, collisions, and lost packets. If the overall traffic volume gets too high, it can significantly impact the performance of the mesh, sometimes to the point of rendering it unusable.

If you insist on using this role as a roof node anyway, then please closely monitor the ChUtil (shared airtime use) and AirTXUtil (airtime used by just this node) stats on your node. If ChUtil gets higher than 25%, or AirUtilTX higher than around 7-8%, please cease using this role in order to preserve overall functionality of the mesh.

Please note that ROUTER and REPEATER are also unsuitable for rooftop use (in fact, even more so because they preempt other nodes). These roles are intended for very well-sited infrastructure only.

Why did my packet go via a regular CLIENT, instead of the ROUTER_LATE node?​

Because ROUTER_LATE is a 'polite' rebroadcaster, if another CLIENT node is more favourably located at that particular point in time, or simply wins the random timing race, it may rebroadcast the packet first. The ROUTER_LATE will still rebroadcast, but you may not notice, as the packet may have already arrived at its destination via another path first.

Why did my packet go via a ROUTER or REPEATER node, instead of the ROUTER_LATE one in my area?​

ROUTER and REPEATER nodes preempt all other roles for rebroadcasting. If there is one in range, packets will go via that node before anything else. If ROUTER or REPEATER nodes are deployed in suboptimal locations, this can result in hop limits being reached prematurely.

Why can't I see the ROUTER_LATE node in my traceroute result?​

See the two above answers.

Why is traffic via a ROUTER_LATE node slow?​

Because ROUTER_LATE will defer rebroadcasting packets if it hears another node rebroadcasting them first, this can result in additional delays. This is particularly noticeable on slower modulation settings (e.g. LONG_FAST), where such delays can become quite substantial.

Why is traffic that should go via a ROUTER_LATE node going missing?​

The shared frequency used by the mesh in your area is likely busy, and as a result the ROUTER_LATE is dropping low-priority packets when its transmit queue is full.

Note that some operations on the mesh can generate a large number of packets in a very short space of time, so the queue can easily go from empty to full in the space of just a few seconds.

I run a ROUTER or REPEATER in a suboptimal location. Should I change it to ROUTER_LATE?​

If your node must rebroadcast in order for nodes within its coverage area to communicate with the rest of the mesh properly, then use ROUTER_LATE. If this is a rooftop node, please use CLIENT_BASE or CLIENT instead.

My node is the only ROUTER around, but it isn't at 10,000ft altitude. Should I change it to ROUTER_LATE?​

If your node's coverage footprint is genuinely excellent, please keep it as ROUTER. ROUTER will preempt all other roles, and is effectively asserting that it is the best path for all traffic within range.

Please note that ROUTER and REPEATER nodes will cause all rebroadcast roles other than ROUTER, REPEATER, ROUTER_LATE and CLIENT_BASE (for packets to / from favourite nodes only) within their coverage area to cancel their own rebroadcasts - so only deploy ROUTER nodes in locations that are actually properly suited to that behaviour.

My node in $LOCATION can receive, but nobody hears me when I transmit. Should I deploy a ROUTER_LATE to help?​

No. In this case, please deploy a CLIENT node nearby. This node will rebroadcast all packets from those nodes which have not made it out via another path, but will not unnecessarily consume airtime by repeating packets that those clients can already hear just fine.

This scenario is quite common for devices with a compromised internal antenna (e.g. T1000-E).

Should I put a ROUTER_LATE on my vehicle?​

In most situations, no. However it can occasionally be appropriate if your vehicle is serving as a relay for e.g. a hiking party that cannot see the rest of the mesh otherwise, and you need to deploy temporary infrastructure coverage for the area in which they are hiking.

If you do deploy a ROUTER_LATE on your vehicle for such a purpose, please remember to switch it back to a more appropriate role after your temporary activity is done.

If you wish to have a rebroadcasting node on your vehicle specifically to serve your own node while you are inside nearby buildings, please use CLIENT (if you can receive but not transmit) or CLIENT_BASE (if your node needs assistance in both directions).

Will a ROUTER_LATE permanently installed on my vehicle help the mesh?​

No. Please don't do this - ROUTER_LATE is not intended as a mobile role, and using it in that manner will usually cause more problems than it solves.

The goal of this custom firmware and DEF CON deployment was two-fold: to push the boundaries of what Meshtastic can do, and to advance the project by stress-testing it in a large-scale, high-traffic environment. As “real-world” as 2,000 nodes in a convention center in Las Vegas can be, it provided a unique opportunity to see how the system performs under extreme conditions.

True to the DEF CON spirit, attendees put the network through its paces and uncovered bugs across nearly every platform including Android, iOS, firmware, and hardware. These ranged from emoji rendering quirks to full app crashes. What makes this community so valuable is that many of these discoveries came with clear technical descriptions and even proposed solutions, helping us improve Meshtastic for everyone.

Details on This Vulnerability​

During DEF CON, a security researcher replayed modified NodeInfo messages at scale. This technique is only possible when the pre-shared key is known by an attacker. This style of attack is possible against an ad-hoc network like Meshtastic, due to the network operating without a centralized identity authority. This was the first time that this type of attack had been observed on an active Meshtastic network and reported to the project’s development team.

Due to its ad-hoc design, Meshtastic operates using the Trust on First Use (ToFU) model. The first time a device sees a NodeInfo packet from a given peer, it trusts that information. Meshtastic has an additional challenge, that individual nodes are all memory constrained. This means that the Firmware can only keep track of the node information of around 100 nodes at a time. DEF CON had over 2000 nodes present, so an individual node simply cannot retain the entire database.

As more nodes are seen, the old nodes cycle out of the database. When this happens, the firmware can accept and store a spoofed NodeInfo. This is a known limitation, and is mitigated by the favorites system and additional checks via the mobile clients. When a node is marked as a favorite, it is never cycled out of the NodeDB. Nodes are automatically favorited when a DM is sent to that node, or when users share contacts via QR code.

Mobile clients provide one additional layer of protection, by storing a complete copy of the NodeDB. When a new NodeInfo is received with a changed public key, the mobile apps will flag the discrepancy and inform the user via the red warning notice on the interface. This worked as intended on the technical side, but we learned that there is some user-experience work to be done here.

An issue that needs further attention is that Meshtastic channels that use pre-shared keys do not have message verification. An attacker could inject messages that appear to come from other users if they have knowledge of the pre-shared channel key.

Another noted issue is that a spoofed NodeInfo packet, that uses the correct Public Key and Node Number, can overwrite other details of that node on everyone else’s NodeDB. This is how node lists were showing nodes with the Ninja emoji 🥷 , which was a fun and DEF CON-appropriate way to demonstrate.

The demonstration uncovered an additional vulnerability; The Meshtastic firmware stores a copy of its own NodeInfo on its local NodeDB. When a spoofed packet is received that has the local node’s Node Number, that copy can be partially overwritten. The node itself will then display this spoofed information in a connected client. This is limited to fields like the node Longname and Shortname, and a few other metadata elements (not including the public key). However, upon reboot, this data would be re-set to the correct owner information stored in firmware.

A few notes/corrections about some of the research that was released publicly:

1. Public keys are not automatically updated when a new NodeInfo packet is received. They are immutable in the NodeDB for as long as the Node exists in the NodeDB.
2. Direct Messages are encrypted and signed using AES-CCM, based on the public key received on the initial nodeinfo exchange. Unless the attacker has knowledge of a node’s private keys or is able to completely control the initial NodeInfo exchange, there is no currently known technique to intercept and decrypt a 2-way DM conversation.

Addressing Findings​

The corrupted NodeInfo display vulnerability has been addressed via a targeted patch, which prevents packets impersonating the local node being processed by the NodeInfoModule. There’s a whole host of additional hardening fixes coming that will address the broader attack vector, of how a node handles spoofed packets that seem to originate from itself.

Beyond this vulnerability, It was particularly interesting to see the packet spoofing technique deployed in the wild. There are user experience fixes being considered, like the option for the mobile client to re-deploy trusted keys to the locally-connected device.

This year’s DEF CON deployment has brought into focus the need for signed messaging in PSK Channels as well as extended identity verification functionality. This would give Meshtastic users the tools to positively prove that a message was sent by the user it claims. Message signing has long been a goal of the project, but cryptographic signatures are often expensive in both device resources and bandwidth usage. The project is currently making progress on this front and will continue to implement feedback from the community to meet its goals.

Building a Resilient Mesh Ecosystem​

Meshtastic is developed without a singular use case, and the project has been careful to not endorse its use for sensitive communications. The project has bolstered its routing protocols to the point of usability in a 2000+ person mesh, and has moved to focus on other aspects such as security, identity, and the applied cryptography required to meet these new needs. PKI was implemented less than a year ago, and the concept of a large/open/city scale mesh was not the original goal of the project, but one we as a community are excited for and working to better support.

The Meshtastic project appreciates the effort of the researchers and has created some action items to address what was observed:

1. Solicit the help of applied-cryptography professionals to determine the best way to implement a (for example) space-constrained signing schema for various message types.
2. Implement and document a recommended workflow for manual identity verification.
3. Implement and document a centralized VDP so that reporting can be done responsibly.
   1. A VDP with Intigriti was created for this DEF CON and the project will implement a more permanent solution. Also, vulnerability reporting continues to be enabled on the project’s key GitHub repositories.

If you are an applied crypto person with a soft spot for LoRa, come hang out with us on discord.

We're very happy with the outcomes of the Meshtastic DEF CON deployment, and will continue to develop the project to work towards a functional, free, and open source mesh.

TL;DR​

TL;DR: At DEF CON, a researcher demonstrated a way to forge node information under certain conditions, causing downstream issues in channel messaging. Encrypted DMs and private keys were not compromised. The specific issue has already been patched, and the event highlighted areas for future improvements, including user experience, identity verification, and message signing.

Addendum​

Updated 8/18/2025

The attack demonstrated at DEF CON has overlap with issues responsibly reported through GitHub's security advisories, which will become public soon. The fact that Nodes can cycle out of the database is a known limitation of the resource constrained hardware that Meshtastic uses. Our existing protections, such as the favorite system and the expanded node database on mobile clients, were demonstrated as invaluable at DEF CON. That is directly because of researchers that have worked to improve the Meshtastic security model.

This year's DEF CON is the first time such an attack has been demonstrated in the wild against a large public mesh. In an effort to not minimize that demonstration, this blog post unintentionally minimized the existing research around spoofing attacks against NodeInfo and other packet types. This was not done intentionally, and our apologies to the researchers that were inadvertently slighted.

Supporting a wide range of hardware requires a significant amount of resources. This includes developer time for maintenance and bug fixes, GitHub runners to build firmware, server space to store hundreds of binaries, and space in the flasher and documentation. All of these factors contribute to increased complexity, making it harder for users to find the hardware they are looking for.

With new devices actively being developed for Meshtastic by several manufacturers, managing this ecosystem efficiently has become a top priority.

A Collaborative Path Forward​

We’ve been working closely with hardware manufacturers to determine a sustainable strategy for hardware support. These conversations focused on identifying which devices each manufacturer intends to actively support moving forward. This has been a collaborative process, and we appreciate their participation and feedback.

From these discussions, we’ve created a new system that classifies devices into two categories:

• Officially Supported
• Community Supported

Officially Supported Devices​

Devices in this category are those that manufacturers have chosen to support through participation in the Meshtastic Backer and Partner programs. These devices receive official support from the core Meshtastic team and are included in all key tooling: the Web Flasher, documentation, client apps, and other areas.

This list is not static. As manufacturers release new hardware or choose to end support for specific models, the list of officially supported devices may change.

Community Supported Devices​

Devices that are no longer actively supported by the manufacturer or do not have backing through our support programs will move to the Community Supported category.

Here’s what that means:

• Firmware for these devices will continue to be built and made available through GitHub releases.
• The core Meshtastic team will no longer provide direct support for these devices.
• Support will be provided by the community.
• Some devices will be removed from the Web Flasher, though this will happen gradually to give the community time to adjust.
• Devices will be moved to a new Community Supported section in the documentation.
• In the client apps, devices will be labeled as either officially or community supported. Community Supported devices will no longer display device images.

Why This Matters​

We understand this is a significant change, but it is a necessary one. Meshtastic currently supports over 100 devices. While this level of choice is valuable, it has made long-term sustainability difficult. Several hardware partners have already committed to releasing new devices this year, which will only increases the challenge if we do not take steps now to streamline support.

The number of devices impacted by this first transition is relatively small and consists primarily of older or legacy models. However, this list will evolve as we continue collaborating with manufacturers on their upcoming devices. We will do our best to make these transitions clear and manageable for everyone involved.

Thank You​

We appreciate the continued support from our community and hardware partners. This update is part of our ongoing effort to ensure the long-term health and scalability of the Meshtastic project.

What Does Preview Mean?​

As with our previous tech previews, 2.7 is not quite production-ready. We're sharing it now to gather feedback, identify bugs, and make adjustments before final release. If you're a tinkerer, a tester, or just excited to see what's next then go ahead and flash it and let us know how it goes!

What's New in 2.7​

Introducing BaseUI: A Name (and Look) Long Overdue​

For years, the default Meshtastic interface on OLED screens and basic TFTs didn’t have a name. It was just... the UI. But with the rise of more advanced interfaces like MUI and InkHUD, and now with a complete redesign, it’s time it had one of its own: BaseUI.

But don't worry, this isn't just a rebrand, it’s a full revamp! The new BaseUI is more intuitive, more capable, and much easier to navigate across screen sizes and input types giving new life to some of the more basic devices in the Meshtastic ecosystem.

Highlights:

• Set Region & Timezone On-Device: Configure the basics directly on the device now!
• Digital Clock: Shows the current time based on your 12/24-hour preference.
• Favorites: Favorited nodes now appear as a dedicated icon in the menu bar, making it easier to access your most important connections.
• Auto-Hiding Menu Bar with Action Menus: A new menu bar (that hides when not being used) appears at the bottom of the screen when navigating between views making it more intuitive for users to know what each view means. Many menu items also include action menus for quick access to common tasks:
  • Home: Open the action menu to sleep the screen or send a new preset (canned) message.
  • Messages: Open the action menu to dismiss the most recent message or reply using preset (canned) messages.
  • Position: Open the action menu to enable or disable GPS directly on the device.
  • LoRa: Open the action menu to quickly select your LoRa region (Region can be set on freshly flashed/wipe devices as well).
  • System: Open the action menu to enable/disable beeps, or configure them for notifications or system events only.
  • Digital Clock: Open the action menu to set your preferred time zone from a list of the most common options.
  • Favorites: Open the action menu on a favorite node to send a preset (canned) message to it.

Here's a video of the new BaseUI in action:

Huge shout to the team that worked on BaseUI, including @JasonP, @HarukiToreda, @tropho, @jp-bennett, and @thebentern.

Linux Joystick Support​

Meshtastic on Linux, or meshtasticd, now supports joysticks. This feature was added for the Waveshare 1.44" LCD HAT, but should also work with other compatible joystick hats. You can use a joystick to navigate the UI, like BaseUI, on your meshtasticd device.

UI Switching: MUI or BaseUI​

You can now quickly switch between BaseUI and MUI on supported devices. No more separate firmware versions! This flexibility lets you choose the best interface for your needs at any time.

For example, since MUI does not support a concurrent BLE connection, you can switch to BaseUI to connect with the client app and make additional configuration changes not available in MUI, or for any other reason you might prefer the client experience over the standalone MUI interface or if you prefer to run the BaseUI for a specific reason.

Key Verification​

A new "Key Verification" feature has been introduced in the firmware. This allows users to select another node and initiate a verification process which will provide a six-digit code that will be entered into a client, and both devices will receive a confirmation code. This proves these devices are communicating with each other using their respective keys.

Future updates may extend this feature to support re-keying between nodes.

Initial support for this feature has been added in the firmware, but further support in the clients will be needed and is planned for a future release.

Flashing the 2.7 Preview​

Meshtastic 2.7 is available now in the Meshtastic Web Flasher under the "Preview" section.

⚠️ Preview releases may require a full device wipe. Be sure to back up your config and keys before flashing.

Help Us Make It Better​

We’d love your feedback. Whether you're testing on a classic T-Beam, a touchscreen device, or a Linux-native setup—tell us what’s working, what’s not, and what you'd like to see next. Join the conversation on Discord or Reddit, and help shape the final release of 2.7.

These abandoned mining devices can be easily repurposed and transformed into powerful Meshtastic nodes, giving them a new life.

The Rise and Fall of LoRa Crypto Mining​

In the early 2020s, a wave of excitement swept through the technology world as certain projects promised to create wireless networks using LoRa technology by using cryptocurrency mining to incentivize the crowd-sourced formation of that network. Thousands of enthusiasts purchased dedicated mining hardware (essentially LoRa gateways with blockchain capabilities) to participate in building these networks.

Fast forward to today, and many of these miners sit unused due to diminishing returns on mining rewards and the general volatility of cryptocurrency markets or simply loss of interest.

The result? Thousands of perfectly functional devices collecting dust.

The Hardware Gold Mine​

Most LoRa-based miners generally share a common architecture that makes them excellent candidates for conversion:

• Linux-based boards with ample processing power (often based on Raspberry Pi or similar SoCs)
• Adequate power management systems
• Often include Ethernet and/or Wi-Fi connectivity
• Robust enclosures already designed for environmental exposure

While they were built for mining cryptocurrency, these devices contain many of the essential components needed for a linux based Meshtastic node.

Benefits of Conversion​

1. Environmental Impact: Repurposing existing hardware reduces electronic waste and extends the useful life of these devices.
2. Cost Effectiveness: Converting a miner you already own can be significantly cheaper than purchasing a new dedicated Meshtastic device.
3. Robust Hardware: Many mining devices were built with 24/7 outdoor operation in mind and include features that make them ideal for reliable mesh network nodes.

The Problem and the Conversion Process​

The Problem​

The primary issue with converting mining hardware into a Meshtastic node is that the LoRa concentrator modules used in many miners are not compatible with the Meshtastic firmware per se. They are specifically designed for LoRaWAN applications, with a fixed number of channels and predefined bandwidth allocations. However, this problem can be solved by using a different LoRa module that is compatible with the Meshtastic firmware, such as the Semtech SX1262 or LR11XX series.

Conversion Overview​

The conversion process generally involves:

1. Software replacement - Flashing RaspberryPI OS (Lite) to replace the mining software and installing Meshtasticd
2. Hardware modifications - Minor adaptations to support the Meshtastic feature set
3. Configuration - Setting up the node for integration onto the mesh

We'll explore each of these steps in detail.

Step-by-Step Guide: Converting a Miner​

Many miners use a microSD card, but some may have special MMC storage cards. In some cases, the eMMC storage may be preferred due to its robust design.

1. Software Replacement​

• Backup: Before starting, back up any important data from the miner.
• Flash SD/MMC: Image Raspberry Pi OS (Lite) onto the device's storage option. We used Raspberry Pi Imager for ease of use and pre-configuration of network settings.

2. Hardware Modifications​

• Remove the LoRa Concentrator: If the miner has a dedicated LoRa concentrator module, remove it. This may involve desoldering or disconnecting it from the main board.
• Install Compatible LoRa Module: Replace the removed concentrator with a compatible module like the Semtech SX1262 or LR11XX series. Depending on the miner hardware, this may be possible using either a Raspberry Pi HAT or a USB LoRa device (typically using a CH341 chip). In our case, we used an open-source USB device developed by the hardware community: The Mesh Toad.

3. Configuration​

• Power on the device and ensure it boots into the Raspberry Pi OS.
• Connect to the device via SSH.
• Follow the Meshtastic installation guide to install Meshtasticd.
• Once installed, run sudo nano /etc/meshtasticd/config.yaml and set the parameters for your LoRa device, a MAC address or MAC address source, and any other parameters for your setup.
• Run sudo systemctl start meshtasticd to start the Meshtastic daemon.
• Run sudo apt install pipx and pipx install meshtastic to install the Meshtastic CLI.
• Use the Meshtastic CLI to configure the LoRa radio region and set the node name - In this case we ran meshtastic --set lora.region US --set-owner "The People's Node" --set-owner-short "🎈"
• Enjoy your success!

Challenges and Considerations​

While conversion is feasible for many devices, there are some challenges to be aware of:

• Some miners may use proprietary hardware that makes conversion difficult
• This could void the warranty on the product you purchased
• Varying levels of technical expertise required

Summary​

As the hardware landscape continues to evolve, repurposing unused mining hardware for Meshtastic represents a sustainable and practical solution that benefits both individual owners and the broader Meshtastic community.

By breathing new life into these devices, we're not just solving a "miner" problem — we're contributing to a major solution for off-grid communication.

Have you converted a miner to run Meshtastic? Share your experience in the comments!

While LongFast is an excellent general-purpose preset for many users, it may not be the optimal choice for larger or denser meshes. In this post, we will explain why switching to higher bandwidth presets might significantly improve your network's performance.

Understanding LoRa Presets​

Meshtastic devices use LoRa (Long Range) radio to communicate, balancing three key factors: range, speed, and reliability. These factors are controlled through settings like bandwidth, spreading factor, and coding rate, which are conveniently bundled into "presets."

The default preset, LongFast, uses 250 kHz bandwidth with a spreading factor of 11. This configuration provides excellent range out of the box but comes at the cost of relatively slow data transmission (about 1 kbps).

Here's how some of the presets compare on paper:

The Problem with LongFast in Large / Dense Networks​

While LongFast offers great range, it has drawbacks that become increasingly problematic as your mesh grows:

1. Increased Airtime: LongFast messages stay "on the air" longer than some of the faster presets, consuming precious channel time. With slower data rates, each transmission occupies the channel longer, preventing other nodes from transmitting during this window.
2. Higher Collision Probability: When multiple nodes try to transmit in a busy network, the chance of packet collisions increases dramatically with slower presets because each transmission blocks the channel for longer.
3. Reduced Throughput: The combination of the aforementioned factors leads to lower effective throughput across your entire mesh, even though LongFast seems like it should deliver messages reliably. In a larger or denser network, this can result in service interruption and frustrations for users.

Benefits of Higher Bandwidth Presets​

Switching to higher bandwidth presets like MediumSlow, MediumFast, ShortSlow, or even ShortFast offers a number of advantages:

1. Reduced Airtime: Messages are transmitted faster, freeing up the channel for other nodes to communicate.
2. Lower Collision Probability: With shorter transmission times, there's less chance that two nodes will try to transmit simultaneously.
3. Better Scalability: Higher bandwidth presets are designed to handle more nodes and higher message volumes, making them more suitable for larger deployments. In dense networks, the improved throughput often more than compensates for the slightly reduced range, resulting in better overall message delivery.
4. Lower Latency: Messages travel through the mesh more quickly, reducing delays that can be frustrating for users.

SDR Waterfall plot of packets on a few different presets (left to right): LongFast, MediumFast, ShortFast

When Should You Switch?​

You should perhaps consider moving away from LongFast if your mesh has:

• More than 60 nodes, especially if they are in relatively close proximity
• High message volume from many users or automated systems
• An Urban / suburban deployments where maximizing range is less important than throughput
• Experienced message delays or inconsistent delivery due to congestion

Recommended Alternatives​

For Extremely Dense Networks​

ShortFast or ShortSlow - These presets offer the highest data rates, dramatically reducing channel congestion. While the range is shorter, urban deployments typically have nodes close enough together that this might not be a significant problem.

For Dense Urban / Suburban Networks​

MediumFast or MediumSlow - These presets strike an excellent balance between range and speed, offering 3-4 times the data rate of LongFast while still maintaining respectable range.

Making the Change​

Switching presets is straightforward but requires updating all nodes in your mesh:

1. Web UI: Navigate to Radio > LoRa and change the "Modem Preset" dropdown
2. Meshtastic CLI: Use the command meshtastic --set lora.modem_preset MEDIUM_FAST or similar
3. Android/iOS App: Go to Settings > Radio > LoRa > Modem Preset

Remember: All nodes in your mesh should use the same preset in order to remain in the network.

Please review the LoRa Config page for more information.

Real-World Success​

Many larger Meshtastic deployments have seen substantial improvements after switching from LongFast, one of those is the Meshtastic Bay Area Group:

Meshtastic Bay Area Group​

Meshtastic Bay Area Group is a community mesh in the San Francisco Bay Area that switched their preset over to MediumSlow. Here's their testimonial on this change:

Our mesh of over 150 nodes is currently thriving after switching to the MediumSlow preset which has proven to be extremely beneficial. It started as an experiment to escape the saturated default LongFast channel that had a lot of nodes using old firmware or misconfigured nodes spamming the mesh.

Here’s what makes it work:

1. Intentional coordination: Our switch to MediumSlow was carefully planned. Node roles were thoughtfully assigned, timers tuned, and the network structure optimized for coverage and reliability. Regular coordination—on and off the mesh—means issues are quickly identified and resolved. The human layer behind the tech is a key part of our success

2. Less background clutter: MediumSlow isn’t the default preset, so we avoid the legacy traffic clutter from years of LongFast usage. That alone makes a huge difference in network clarity.

3. Modern firmware and best practices across all nodes: Since the migration was recent and deliberate, nearly every device is running up-to-date firmware, reducing bugs and improving consistency. We stick to good practices in settings and attempt to reduce any unnecessary traffic that would not provide a positive impact.

4. Strategic node placement: We reserve router mode for high-elevation nodes, ensuring wide coverage without unnecessary redundancy. Altitude matters—and we use it to our advantage. We sometimes place 2 routers at opposite ends of a given area, to provide high likelihood of line-of-sight.

5. Embrace curiosity and experimentation: We often test limits, run experiments and generally "try things" to learn and test assumptions. This ensures that the mesh performance and behavior is understood and changes are backed by impact and repeatable science.

Wellington Region Mesh (New Zealand)​

This mesh is a medium sized mesh covering several hundred km² of mixed urban, suburban and rural areas across the lower North Island of New Zealand, and part of the top of the South Island. The population is spread throughout complex terrain that can make providing good coverage difficult. We migrated the entire mesh from LONG_FAST to SHORT_FAST over the course of a week, at the end of August 2024.

By Q3 2024, our mesh had grown to over 150 active nodes, and was experiencing significant problems with congestion. We were operating on the default LONG_FAST preset at this time, in order to help encourage adoption, but the amount of traffic on the network was rendering it unusable, with observed channel utilisation peaks at busy sites hitting over 65%. This was largely composed of nodeinfo, location, and telemetry updates from clients. Most features, including text messaging, were extremely unreliable - and bursts of traffic could cause the whole thing to melt down for a while. Our mesh has thankfully never experienced the problems with rogue routers that have been observed elsewhere, due to good (and early) coordination between our high site operators to ensure comprehensive coverage from the start. However, due to our topography, we do require an above-average number of routers in order to ensure that the populated areas are adequately covered, and these routers were competing with each other for the limited airtime.

We started out by temporarily moving a couple of key high sites to SHORT_FAST for a brief two-hour test, in order to get a quick initial idea of how feasible a move to a faster preset was likely to be. We also investigated MEDIUM_FAST, but ultimately decided that SHORT_FAST would be a better bet as a long term decision, provided it was workable. Migrating the mesh seemed likely to be a big job, and we didn't want to have to do it all over again at a later date if we compromised on something that was still too slow to cope with future growth. This initial test went well.

Once the concept was proven, we organised a test day where we moved all key high sites in the region across to SHORT_FAST for 24 hours, in order to allow region-wide experimentation with a fully contiguous mesh. This was advertised in advance via social media, and on the mesh itself. The test day went well, and proved that SHORT_FAST still had a sufficiently good link budget that all but a few very marginal links would continue to work. This also allowed us to verify that our assumptions on the sequencing of high site changes were correct, to ensure that we could do the whole thing via remote admin - thus allowing the migration to be rapidly implemented, and easily able to be rolled back in case of problems.

At the end of August, we initiated a migration of the entire mesh to SHORT_FAST, using the default frequency for that preset (this means that users only needed to change a single setting away from the defaults in order to connect to our mesh). The move was advertised via social media, and aggressive spamming of the LongFast public chat channel with both explanatory text, and a web link to a page with more detailed information about the move and resources where users could obtain assistance. On August 31st, all key high sites were simultaneously moved to SHORT_FAST, and temporary additional LONG_FAST routers were colocated at critical sites so that we could continue to spam the LONG_FAST public channel in order to ensure all users were aware of the change. By the following weekend, almost all users had updated their node settings, and all but two of the temporary LONG_FAST routers were decommissioned. These two were left in place for another three months in order to notice any stragglers who may need a hand - thankfully there were only a handful of these remaining.

Performance on SHORT_FAST has been extremely good, with very reliable performance, including for our longest permanent link (254km between two key high sites). Packets reliably transit across the entire mesh without issue, rapidly. The reduced latency has also made for a much nicer user experience.

One other significant benefit of the faster mode has been the ability to use some of the additional headroom in the channel to better serve urban blackspot areas (obstructed from our main routers by terrain) which were unfeasible to cover prior to the move. From December 2024 onwards, we deployed several ROUTER_LATE nodes to cover these areas - these nodes guarantee that our former black spots now have a path out to the wider mesh, and have proven to be extremely helpful.

Getting others to switch / Dealing with FOMO​

If you're in a community or group where others are still using LongFast, consider sharing your experiences and the benefits you've seen. You can also help them understand the trade-offs involved in switching presets. This can be a great opportunity to educate others about the importance of network optimization and how it can lead to a better experience for everyone. For those who are hesitant to switch, remind them that the default LongFast setting is not a one-size-fits-all solution. Encourage them to experiment with different presets and find what works best for their specific deployment.

Some groups that have switched to a higher-bandwidth preset have left a bot on the LongFast preset to send messages redirecting those who haven't switched yet to the new channel. This allows for a transition and ensures that no one is left out of the new network while they consider the change.

Why doesn't Meshtastic just change the default preset?​

The Meshtastic project initially focused on the original use-case of small private outdoor mesh networks, not the large public meshes that exist today. LongFast remains the default because it offers a good balance of range and speed for many users, particularly beginners and smaller networks. As networks grow larger and denser, however, this preset becomes less optimal for the reasons we've explored above. Changing the default preset would also break discovery of existing nodes, as they would be on different channels. This would lead to confusion and frustration for users who are not aware of the change. For Meshtastic 3.0, we are considering a new default preset that is more suitable for increasingly popular larger networks, but this is still in the works.

So long, LongFast!​

While LongFast is an excellent default setting that balances range and speed for small to medium-sized networks, larger or denser deployments often benefit significantly from switching to higher bandwidth presets.

The slightly reduced theoretical range is usually offset by improved reliability, lower latency, and better overall user experience, especially in scenarios where nodes are relatively close together.

If your mesh has grown beyond a handful of nodes or you're experiencing congestion-related issues, it's worth experimenting with alternative presets to find the optimal configuration for your mesh.

What settings are you using for your mesh? Share your experiences in the comments or on our community forums!

What Does Preview Mean?​

This is a preview release, which means it's not quite ready for general use. Think of it as pre-alpha. We're making it available to gather feedback from the community, uncover any hidden bugs, and thoroughly test everything before the full release. If you're feeling adventurous and want to help us improve the latest features, give it a try! If you'd rather wait for a more polished version, that's okay too. The full release is coming soon.

Key Features in 2.6​

Next-Hop Routing for DMs​

After almost 1.5 years of preparation, implementation, simulations and real-life testing, we’re happy to announce a more efficient routing protocol for direct messages. Since the approach is backwards compatible, you can safely update only part of your mesh, but the more nodes are updated, the more you will benefit from it.

In a previous blog post we have explained why Meshtastic uses a “managed flooding” approach, but we stated that especially for direct messages, an improvement could be made. We’ve also looked into different approaches for routing broadcast messages (see for example this proposal), but it has been proven hard to beat the current method in various topologies, and there is only little that can be done without breaking changes.

In order to implement the new next-hop router for direct messages, several measures had to be taken in order to make it backwards compatible, limit routing control overhead and memory usage. Furthermore, we need to make sure it still works well in real-life conditions, like with mobile nodes, asymmetric links and packet loss that may happen anywhere on the route, especially when traffic increases.

Since we had two unused bytes left in the unencrypted Meshtastic header, we are now using them to denote the current relayer of the packet and the node we think should relay our packet - the next-hop. Initially, a message directed to a single destination will use the managed flooding approach. We’ll then keep track of the node(s) that are trying to relay the packet for us. If upon a successful delivery, a response comes back (e.g., a NodeInfo response, acknowledgment or traceroute) and the node that relays this towards you was also (one of) the node(s) that relayed the original packet, it will be denoted as next-hop from now on. This means that instead of letting all nodes try to relay the packet, only the node for which the next-hop byte matches will. Note that this is determined per hop, so if there is an asymmetric link or a node on older firmware in between, managed flooding will be used on this hop. When a node moves, or RF conditions change, it might be the next-hop is not valid anymore. Therefore, a node will always fall back to managed flooding at the last retransmission attempt if it doesn’t hear its next-hop relay.

Visualization of how next-hop routing for DMs works in Meshtastic.

Special thanks to @GUVWAF for their work on this feature.

Meshtastic UI (MUI): A New Standalone Experience​

After a year of development, including a major tooling change along the way, we are excited to introduce the preview release of Meshtastic UI (MUI), a brand-new interface for standalone Meshtastic devices. MUI provides a seamless touchscreen experience, allowing you to interact with your Meshtastic network without needing a phone app.

This release is the result of 12 months of coding, with 12,000 lines of handwritten code and 50,000 lines of generated code, successfully ported to 10 different devices. MUI is also accessible to a global audience, having been translated into 18 languages.

While this is an exciting milestone, MUI is still in development. We're actively working on adding more features, improving performance, and making everything work even better.

Supported Devices​

MUI is compatible with a range of devices, including:

• Standalone LoRa Devices with ESP32-S3 and a TFT Display: LilyGo T-Deck, Seeed SenseCAP Indicator, unPhone, PICOmputer, Elecrow 5"/7" (experimental)
• CYD-style Devices with ESP32-S3 Connected via Serial to any LoRa Device: T-HMI, Mesh-Tab, "Replicator" (ESP-4848S040), Makerfabs 4"
• Embedded Linux Devices with SPI/I2C and GPIOs: Raspberry Pi, Milk-V, or LuckFox with TFT SPI and LoRa hat
• Linux Native Setups: PC with Meshstick or SIMRadio simulation using X11 MUI

Features​

MUI is packed with powerful tools to make managing your Meshtastic network easier:

• Dashboard Screen - Displays device status at a glance, including new messages, the number of detected nodes, date and time, radio settings, GPS, sound, Wi-Fi, and MQTT. Quick functions are accessible through intuitive icons.
• Node List - View, filter, and highlight nodes in your network.
• Chat Window - Send and receive messages with persistent message history.
• Dynamic Position Map - Pan and zoom with customizable map styles for better network visualization. A starter set of map tiles for Earth is available in three different styles. Simply unzip and transfer the folder to your SD card. The included tiles cover zoom levels 1-6, but if you need higher zoom levels, you will need to download additional tiles. We’ll provide more details on how to do that soon.
• Basic Device Configuration - Quickly set up and adjust basic settings without the need for the Meshtastic app.
• Handy Tools - Includes a mesh scanner, signal meter, traceroute, statistics, and packet log.
• Bluetooth Programming Mode - Easily update and configure devices wirelessly using Bluetooth.

New Meshtastic UI (MUI) interface for standalone devices showing the Map View.

MUI represents a major step forward in Meshtastic's on-device UI, providing a more intuitive and user-friendly experience for standalone devices. We're excited to see how the community uses MUI and look forward to your feedback as we continue to improve and expand its capabilities.

Meshtastic UI can be flashed by toggling the "Meshtastic UI" option in the Meshtastic Web Flasher.

Special thanks to @mverch67 for their work on this feature.

InkHUD​

MUI isn't the only UI we're launching with 2.6! We're also introducing InkHUD, a new heads-up display for Meshtastic e-ink devices. InkHUD is a simple yet powerful interface designed to keep your Meshtastic network at your fingertips. With an always-on, eInk-powered dashboard, it provides real-time network monitoring and useful insights while using minimal power. InkHUD delivers a seamless, at-a-glance experience without the need for a phone app, ensuring you always have the most important information readily available.

New InkHUD interface for Meshtastic e-ink devices.

Special thanks to @todd-herbert for their work on this feature.

Features:

• One-Button Navigation - Easily navigate menus and settings with a simple single-button interface.
• Real-Time Multi-Node Monitoring - Keep track of multiple nodes and network activity at a glance.
• Threaded Message View - Follow conversations directly on the device without having to open your phone app.
• Non-Intrusive Notifications - Get alerts and direct messages without interrupting your current screen.
• Customizable Displays - Choose and arrange the information that matters most with configurable applet and split-screen layouts.
• Persistent Display - Keep key data visible at all times without the energy drain of traditional screens.

Currently Supported Devices for InkHUD:

• Heltec Vision Master E290
• Heltec Vision Master E213
• Heltec Wireless Paper
• LilyGo T-Echo

InkHUD can be flashed by toggling the "InkHUD" option in the Meshtastic Web Flasher.

Other Notable Features​

Improved Device State File Management​

Meshtastic 2.6 introduces a more reliable way to handle device state and node data by separating them into distinct files. Previously, both were stored together, meaning that a single flash memory issue could result in data loss or system instability.

By keeping device state and the node database separate, Meshtastic ensures that essential system data remains intact even if there’s a problem with the node database. This change improves data integrity, reduces the risk of corruption, and makes recovery easier in the event of a filesystem issue or unexpected power loss.

Meshtastic over LAN (UDP) – Now on ESP32​

Meshtastic 2.6 adds support for meshing over a local network (LAN) using UDP, currently available for ESP32 devices on WiFi. This feature allows nodes to communicate over a standard network connection, extending your mesh without relying solely on RF signals. This can be especially useful in locations where RF coverage is limited or when you want to bridge multiple Meshtastic networks over existing infrastructure.

Once enabled, nodes automatically discover and connect to each other over the local network with minimal setup. While this feature is still in the experimental phase, we plan to expand support to additional platforms in future releases. Technical documentation is in progress, and we welcome feedback from the community to help refine it.

Optimized LoRa Slot-Time Calculation​

Meshtastic 2.6 includes improvements to LoRa slot-time calculations, making packet transmission more efficient. By reducing slot time, more slots become available within the same rebroadcast window, lowering the chance of packet collisions and improving overall network performance.

Flash The Meshtastic 2.6 Preview​

🚨 Flashing the 2.6 Preview Requires a Device Wipe: Back Up Your Config/Keys 🚨

Now, because we don't want anyone accidentally flashing this preview release to their devices, we've made it just a little harder to flash... in a fun way! It is available to flash via the Meshtastic Web Flasher but you have to enter the special code first. Now, of course we're not going to tell you the code but it shouldn't be too hard to figure out. Here's a hint:

A new firmware preview, ready to flash—guarded gently by gaming past. Think NES, think Konami's name, enter the legend to unlock your claim.

Don't ruin the fun!

Give Us Your Feedback​

We're excited to hear what you think of Meshtastic 2.6 Preview! If you run into any issues, have questions, or just want to share your thoughts, please join us on the Meshtastic Discord or the Meshtastic Subreddit. Your feedback is invaluable and will help us make the full release even better. Thank you for being a part of the Meshtastic community!

That’s where Meshtastic Designer comes in. This new web-based tool from RAKwireless makes it easy to configure and visualize your WisBlock-based Meshtastic setup before you buy, ensuring you get the right hardware for your specific use case. Whether you’re optimizing for long-range communication, off-grid power, or specialized sensor deployments, Meshtastic Designer helps you configure the right setup with confidence.

Built for the Meshtastic Community​

RAKwireless recognizes that Meshtastic is a powerful tool for data transmission, enabling applications like remote sensor management, environmental monitoring, and innovative off-grid communication networks. For them, the Meshtastic community was the natural starting point for this new tool.

Seeing the projects built by the community, they understood how the flexibility of WisBlock modules has expanded what’s possible within the Meshtastic ecosystem, inspiring countless creative applications. A common example is the deployment of solar-powered nodes for remote, off-grid communication. However, they also recognized the challenges users faced when designing these projects—the trial and error of selecting the right hardware, ensuring compatibility, and optimizing for specific needs.

Meshtastic Designer was created to solve these challenges, making it easier for users to confidently configure WisBlock-based Meshtastic setups without the guesswork. Instead of manually checking compatibility or testing different configurations after you purchase your hardware, you can quickly build and refine your setup before ordering.

How It Works​

Meshtastic Designer walks you through selecting WisBlock modules compatible with Meshtastic, ensuring everything works together. The tool provides a 3D visualization of your setup and gives suggestions for relevant components and highlights any incompatibilities (e.g., sensors not compatible with selected slots).

Once you're happy with your design, you can:

• Share your configuration with others using a link or QR code
• Export your setup details to help assist enclosure design, layout planning, or other customizations
• Purchase the exact WisBlock modules you've selected directly through the tool

For a full breakdown of its features, and how it works, click the image to view RAKwireless’s official blog post

Get Started with Meshtastic Designer​

If you’re looking to build a Meshtastic setup with WisBlock hardware, try Meshtastic Designer today.

Predicting Range ⛰️📡​

Terrain and Why It Matters​

Terrain is the number one limitation for Meshtastic signals. Whether you're trying to chat with friends, plan radio deployments for disaster recovery, or even break records set from the edge of space (range tests), the terrain is ultimately the upper limit on range. The best way to increase it is to move your antenna higher, which can mean using the local terrain or placing nodes on towers. Some of the most impressive mesh networks use both approaches to transmit over long distances, but predicting the expected coverage can still be challenging.

The key is having software that knows the elevation of the terrain around your location and can also simulate effects like signal attenuation through air and scattering by obstacles. Before now, these calculations relied on hard to use software. The terrain datasets were also massive (terabytes of images) and not simple to interpret.

The Meshtastic Site Planner solves these problems by building on SPLAT!, a program written by amateur radio operator John Magliacane (KD2BD). Terrain data is automatically streamed as needed, so you don't need to find and store datasets on your computer. The models, optional settings, and data processing are handled behind a modern web UI that produces beautiful simulation maps showing where your signals can be received.

Radio Waves and Obstacles​

Besides terrain, obstructions like buildings, trees, and even weather can block or weaken radio signals. These obstacles scatter and absorb energy, reducing the strength of the signal before it reaches your receiver. How can you ensure your signal gets through without needing detailed maps of every obstacle?

Fortunately, the Site Planner solves this by allowing you to input the average height of obstructions (called "clutter"). These models use decades of research to forecast how far reliable signals can travel based on environmental conditions. By selecting a reliability threshold (e.g., 90 percent), you can ensure your node has a high likelihood of covering the predicted range.

This approach is widely used in professional radio planning for cell towers, broadcast systems, and microwave internet links. The Meshtastic Site Planner brings this capability to your mesh network. Simply enter the average height of obstacles in your area—such as 10 meters for an urban environment—and the software handles the rest.

By accounting for obstacles, the Site Planner creates realistic coverage maps, helping you optimize placement and ensure consistent connectivity in challenging environments.

Antennas and Sensitivity​

Terrain and obstacles aren't the only factors that limit range—signal strength also fades with distance. Once it becomes too faint, the receiver can't decode it. The Meshtastic Site Planner accounts for these limits, allowing you to create maps tailored to your hardware and channel.

• Receiver Sensitivity: Simulate based on your radio’s threshold for decoding weak signals.
• Antenna Gain: Adjust for different antenna types to see how they affect coverage and range.
• Cable Loss: Account for real-world inefficiencies like signal loss in cables and connectors.

By customizing these parameters, the Site Planner produces accurate, realistic predictions for your specific setup, whether it's a handheld node or a high-power base station.

Using the Link Planner​

The Meshtastic Site Planner is designed for simplicity, making it accessible even if you're not a radio engineer or amateur radio operator. The default settings were carefully chosen to provide accurate predictions for your Meshtastic network right out of the box.

Getting Started​

Using the Meshtastic Site Planner is as easy as:

1. Clicking on the Map: Choose the location of your transmitter by simply clicking on the map.
2. Setting Key Parameters: Enter your antenna height, select the appropriate frequency for your region (see the list here: Meshtastic Radio Settings), and adjust any other settings if needed.
3. Running the Simulation: Hit "Run Simulation," and within seconds, you'll see a color-coded map showing the predicted signal strength over distance.

Visualizing Coverage​

The output map uses colors to indicate signal strength, helping you quickly identify areas with strong or weak coverage. You can fine-tune the simulation by adjusting parameters like transmitter power, antenna gain, and clutter height to reflect your actual deployment conditions.

Simulating Multiple Radios​

One of the powerful new features of the Site Planner is the ability to add multiple radios to your simulation. This allows you to model overlapping coverage areas for larger networks. For example, you can simulate how two Meshtastic radios placed strategically in Calgary, Alberta, Canada, can cover the northern half of the city. By combining their coverage areas, you can ensure seamless connectivity for your mesh network.

Tailored to Your Needs​

Whether you're planning a small, localized deployment or a larger network spanning multiple locations, the Meshtastic Link Planner adapts to your requirements. Adjust settings, test configurations, and visualize the results—all with a few clicks.

With the Site Planner, optimizing your mesh network has never been easier.

Contributions Welcome​

Future releases will include point-to-point link quality estimates, terrain visualization, and presets tailored to specific meshtastic devices. We're actively looking for contributors to help get these implemented, so feel free to send a pull request!

Personalize Your Short Name 🎨​

You can personalize your Meshtastic devices with emojis, making them stand out in a unique and fun way! By default, the Short Name for your device is auto-generated using the last four characters of its MAC address. However, you can customize this Short Name to make it truly yours. Using emojis adds a visually distinctive touch, making it easier to identify your node at a glance!

How It Works 🛠️​

Your Meshtastic device’s Short Name is limited to 4 bytes. Many emojis are a great fit because they use only 1–4 bytes; however, some—such as certain flags or more intricate emojis—exceed the 4-byte limit and won’t work.

Thankfully, most Meshtastic client apps include validation to ensure you don’t accidentally use an emoji that exceeds the 4-byte limit. However, not all clients enforce this restriction directly. Regardless, the protocol enforces a strict 5-byte limit (1 byte for overhead, leaving 4 bytes for the emoji itself). If you attempt to set a larger emoji, either the client app or the firmware will prevent it from being saved.

To customize the Short Name, refer to the User Config documentation for instructions on where to make the change for your preferred client.

Once you’ve saved the changes, your device will appear with your custom emoji Short Name in the client applications.

Why Use Emojis as Your Short Name? ✨​

Customizing your Short Name with emojis isn’t just a quirky feature—it’s a creative way to express the purpose or personality of your device. For instance:

• If your node’s Long Name is “Crichton’s Car”, you could set the Short Name to 🚗.
• Using a node to monitor weather conditions? 🌤️ could be a great choice.
• Setting up a device for a hiking trip? Try 🥾 or 🌲.

This adds both customization and a unique identity, making it easier for others to recognize your device in the network. For example, each emoji can convey the purpose or personality of the node, adding a touch of creativity to your setup.

Get Creative! 🖌️​

The possibilities are endless. You can pick emojis based on:

• Purpose: 📡 for a relay node, 🏠 for a home base station, or 🛶 for boating adventures.
• Travel: 🛫 for air travel, ⛴️ for a cruise, or 🚂 for train adventures.
• Personality: 😎 for a cool vibe, 💡 for an innovative setup, or 🧙 for something magical.

The nodes list becomes much more visually engaging and easier to navigate when each node is represented by a unique emoji. It’s a fun and functional way to distinguish between devices at a glance.

Emoji Short Names and Waypoints on the Map 🗺️​

The fun doesn’t stop at the nodes list! On the Mesh Map, nodes with emoji Short Names stand out, making it easy to quickly identify them at a glance. For nodes without emojis, the alphanumeric Short Name will be displayed instead. Check out the example below to see how emoji Short Names add a visual pop to the map:

In addition to Short Names, waypoints also use emojis, subject to the same 4-byte limit. Waypoints are a great way to mark specific locations on the map, like trailheads, campsites, or meeting points. By assigning an emoji to your waypoint, it becomes both functional and fun to use. For example:

• 🌄 for a hill or sunrise spot.
• 🏞️ for a scenic view.
• 🍔 for a planned lunch spot.

Waypoints are another creative way to make the map uniquely yours, enhancing both usability and personality. Just remember to choose emojis that fit within the 4-byte limit!

Emoji Graphics on OLED Screens 📟​

In addition to displaying emoji Short Names and waypoints on the map, some emojis have XBM graphics support in the firmware and will display directly on Meshtastic devices with OLED screens. This feature adds a unique and expressive way to communicate with nodes.

The following emojis are supported and will display on the OLED screen when sent to a node:

👍 👎 ❓ ‼️ 💩 🤣 👋 🤠 🐭 ☀️ ☔ ☁️ 🌫️ 😈 ♥️
Here's an example of how one is displayed on the OLED:

These icons are perfect for quick and fun interactions, such as confirming receipt of a message, signaling a question, or just having some lighthearted fun with your network.

Share Your Emoji Creations! 💬​

We’d love to see how you’ve embraced emojis in your Meshtastic setup! Whether you’re using emojis in your Short Name like 🚗 or 🏠 to make your nodes stand out, adding waypoints such as 🌄 or 🍔 to mark important spots on the map, or sending fun OLED messages like 👍 or 🤣, there are countless ways to get creative.

Share your unique setups, use cases, and ideas in the comments below. From practical applications to playful touches, we can’t wait to see how you’re making Meshtastic even more expressive and fun! 🌟

Note: While emojis can add a creative touch, not all emojis mentioned in this blog post are guaranteed to be compatible with the 4-byte limitation enforced by the Meshtastic firmware.

When setting up your Meshtastic network, configuring the correct Role for each device can be crucial for optimizing performance and ensuring reliable communication. Conversely, the pitfalls of choosing the incorrect Role can lead to congestion and poor performance on your mesh. In this post, we'll explore why you might choose certain device roles and avoid others.

What is a device Role?​

A device role in Meshtastic defines the primary function of a device within the network. Each role is tailored to specific usage and helps in managing the network and the behavior of the device more efficiently. Here are some of the common device roles to consider:

Client​

The defacto role for devices is the CLIENT role. This is a flexible, general purpose role for devices which should serve the overwhelming majority of use cases. When in doubt about what role you should go with, simply sticking with Client is a safe bet.

Despite the apparent baggage of the term Client in some technological contexts, Clients in Meshtastic do actually repeat / route messages. Unfortunately in the past this has caused some confusion, landing some individuals to incorrectly choose the ROUTER role.

Client Mute​

The CLIENT_MUTE role is similar to the CLIENT role but with one key difference: it does not repeat or route messages. This role is ideal for devices that are intended to be used in areas with high network traffic where additional message routing could cause congestion. By using the CLIENT_MUTE role, you can ensure that the device will only send and receive its own messages without contributing to network traffic.

This role is also highly recommended if you are a mesh enthusiast with multiple devices. Select one of your devices to be a CLIENT or CLIENT_BASE and set the rest to CLIENT_MUTE to keep your airtime usage more responsible.

Client Base​

The CLIENT_BASE role is similar to CLIENT, but has priority in rebroadcasting messages from or to any of its favorited nodes. For mesh enthusiasts with multiple devices, this role is perfect for ensuring all your nearby nodes take full advantage of your stronger, well-positioned attic/roof “base station” node.

If you have an attic/roof node, set this node to CLIENT_BASE. Set your other nodes (typically CLIENT or CLIENT_MUTE) as favorites on the CLIENT_BASE.

Router and Repeater​

The ROUTER role is designed for devices which are intended to primarily route messages to other devices on the mesh. This role is ONLY suitable for stationary devices placed in extremely strategic locations to act as unofficial hubs for routing packets on the mesh. Routers focus on relaying messages from other devices by cutting in line before other nodes have a chance to rebroadcast a message, making them key for extending the range and reliability of your mesh. Additionally Routers always rebroadcast, whereas most other roles potentially choose to forego rebroadcasting if they hear a neighbor rebroadcasting first.

Another default behavior of Routers is that the device tries to save as much power as possible by attempting to sleep as well as send telemetry packets less frequently than other devices on the mesh. This is because they are chiefly tasked with routing others' traffic rather than originating their own messages.

The REPEATER role behaves very similar to ROUTER in terms of becoming a preferred device for routing packets, however it goes a step further by completely turning off any broadcasted traffic such as telemetry. It only responds to other nodes packets instead of originating messages.

What is a strategic location anyway?​

When evaluating strategic locations for these two roles, consider a tower on mountain peak rather than a tall building. By electing a device to become a Router or Repeater, you are making an implicit choice for the entire mesh to prefer that node for rebroadcasts for any direct neighbors. This strategic placement becomes crucial for ensuring that packets can be delivered to the widest possible audience. Using line of sight viewshed survey tools to determine the optimal location is recommended, but selection can best be determined by collecting some real world data on the mesh first.

Why improperly applying Router and Repeater roles is harmful​

If a poor location is chosen for Routers and Repeaters, it can cause a number of issues:

1. Increased rate of packet collisions

Because Routers and Repeaters always rebroadcast, when too many devices are applied with these roles and the devices are direct neighbors, packets will potentially be rebroadcasted at the same time, creating higher noise levels and packet error rates. This frequently culminates in sporadic delivery failures.

2. Decreased overall range

An improperly located router will potentially prematurely hop gobble any packets routing through it. This has the effect of consuming a hop in the routing of a packet before it would be able to reach more strategically located nodes. This can greatly limit range for instance, in the case of many Routers being deployed in a valley consuming all of the available hops before a packet is able to reach its destination through a more strategically node placed on a peak above the valley.

3. Asymmetrical links

Similarly to the issue of decreased range, the same scenario can also result in asymmetrical communication, wherein a subset of the mesh can send messages to a different group, but that group is unable to reach back with responses through the improperly placed Routers' premature consumption of hops before the message is able to deliver. This phenomena can also lead to a reaction of users increasing the hop limit to compensate for the problem, which unfortunately further increases congestion by utilizing more air time.

Sensor​

The SENSOR role is intended for devices which primarily gather and transmit sensor data. These devices still participate in routing messages for other devices, but they prioritize sending their own telemetry data to the network, even in the face of high channel utilization. This role is ideal for environmental monitoring, weather stations, or any application where the device's main function is to collect and report telemetry.

By using the SENSOR role in combination with power.is_power_saving, the device will attempt to sleep between intervals of sending environmental telemetry, significantly extending runtimes for devices utilizing this combination of settings.

Tracker​

The TRACKER role is designed for devices that are primarily used for tracking the location of assets, vehicles, or individuals. Devices in this role periodically send their GPS coordinates to the network via Position packets with a higher priority, allowing for more robust location tracking. Trackers still participate in routing messages, but their main goal is to provide timely location data, even in the face of high channel utilization.

By using the TRACKER role in combination with power.is_power_saving, the device will attempt to sleep between intervals of sending position data, significantly extending runtimes for devices utilizing this combination of settings.

Conclusion​

Choosing the right device role is crucial for the performance and reliability of your Meshtastic network. By understanding the differences between the common roles, you can optimize your network setup to meet your specific needs and ensure efficient communication across all devices. For more technical information about each role, visit the device configuration docs.

This support will be fueled by partnerships with hardware vendors, many that you are familiar with, and some that are new to Meshtastic. In time, high quality devices will bear the Meshtastic seal of approval. Individual devices will be eligible for registration through Meshtastic, providing assurance of genuine hardware, as well as identity and cryptographic key attestation.

Meshtastic Solutions will also serve as a hub for businesses that need custom solutions or expert consultation within the Meshtastic ecosystem. Meshtastic Solutions is open for business for providing engineering, software solutions, and other support for custom use-cases. The first stage of this support is the Backer program, where existing manufacturers can financially support Meshtastic. This will be extended to include a full Partner program, offering in-depth design, close support, and device testing assistance. All with the goal of helping hardware vendors produce the best products possible for Meshtastic.

Meshtastic Solutions is separate from both the Meshtastic open source project, and Meshtastic LLC, the license and trademark holding entity. There will be no drastic changes to the Meshtastic project as a result of this new venture, with the exception of more development and higher quality products and solutions to choose from. This support from Backers and Partners will fuel some long-awaited milestones, including a well-tested Stable firmware release.

We’re looking forward to a stronger Meshtastic ecosystem that continues in the strong open source legacy the project has worked hard to foster. Follow our progress at Meshtastic.com, and feel free to contact us with questions or to discuss business opportunities.

Balancing Encryption with Practical Use​

For many, Meshtastic's encryption is a key part of the appeal. Over the years, the challenge has been finding a balance: implementing strong encryption without excluding low-power IoT platforms or overwhelming LoRa's limited bandwidth. Before version 2.5, encryption relied on a static pre-shared key per channel, which was quite robust. However, it had one notable limitation: Direct Messages (DMs).

DMs were sent using the same shared channel key, which meant that while DMs were theoretically private, they were accessible to anyone on the same channel. The honor system was the only safeguard, particularly since the default Meshtastic setup uses a publicly known encryption key, leaving DMs effectively unencrypted out of the box.

Challenges with Remote Administration​

Remote administration also presented hurdles. The conventional method involved creating an "admin" channel, allowing any node on that channel to be controlled remotely. This approach had drawbacks, notably that nodes open to administering others were also vulnerable to being administered themselves.

Introducing Public Key Cryptography (PKC) to Meshtastic​

In 2022, a user named edinnen proposed a solution with a pull request that introduced a public/private key scheme for DMs. Although the initial feedback was promising, the patch became outdated as time passed. Recently, everything aligned, and we revisited and reworked this patch, making it the foundation of Meshtastic's version 2.5 development.

Our new PKC implementation is now a core feature, providing each node with a unique public key generated at first boot. This key enables secure, encrypted connections between nodes and serves as a unique identifier within the mesh. It also solves the remote administration challenge—nodes can now be identified and authorized as remote administrators through their public keys.

A Major Step Forward in Security​

With this new PKC scheme, Meshtastic offers enhanced encryption for DMs and secure remote administration for difficult-to-reach nodes. While we still caution against relying solely on Meshtastic encryption for life-or-death situations, this update marks a significant advancement in privacy and security for the mesh network.

Technical Deep Dive: The Mechanics of Meshtastic's New Encryption​

At the heart of Meshtastic's new encryption system lies the X25519 elliptic curve Diffie-Hellman key exchange. This process unfolds in two key steps:

1. Key Generation: Upon first boot, each device generates a random private key and derives a corresponding public key using the X25519 algorithm. This public key is then broadcast to the mesh as part of the node's regular announcements.

2. Secure Communication: When a node initiates a Direct Message (DM), it completes the X25519 key exchange by combining its private key with the recipient's public key. This process generates a unique shared secret, which is then used to encrypt the DM. The receiving node can independently derive the same shared secret using its private key and the sender's public key, enabling secure decryption.

Figure 1: Visual representation of Meshtastic's X25519 key exchange process

The encryption scheme employs AES-CCM (Counter with CBC-MAC), which provides both confidentiality and authenticity. A notable feature is the inclusion of a short Message Authentication Code, verifying the sender's identity and ensuring message integrity. To further enhance security, DM messages incorporate an additional 4 bytes of random nonce, effectively preventing potential compromises due to nonce reuse.

Remote administration has also seen significant improvements. Administration messages now include an 8-byte session key, set by the node being administered. This key is included in responses and must be present in any packet attempting to make changes. With a 300-second timeout, this mechanism provides robust protection against replay attacks of captured administration traffic.

Conclusion​

Meshtastic's journey from a simple hiking communication tool to a versatile, secure mesh networking solution showcases the power of community-driven development. The introduction of our new Public Key Cryptography scheme in version 2.5 represents a significant advancement in the platform's security capabilities, addressing long-standing challenges in direct messaging and remote administration.

As we continue to refine and expand Meshtastic's features, we remain committed to balancing robust security with practical usability. While this update significantly enhances the platform's privacy and security, we encourage users to approach encryption with a clear understanding of its strengths and limitations, especially in critical scenarios.

Looking ahead, we're excited about the possibilities this new encryption framework opens up. We invite our community to explore these new features, provide feedback, and continue pushing the boundaries of what's possible with Meshtastic. Together, we're building a more secure and connected future for off-grid communication.

Understanding the Change​

On August 21, 2024, the Meshtastic development team made the decision to remove the ability for users to subscribe to all topics.

Why This Change Was Necessary​

The decision to restrict topic subscriptions was not made lightly. It stemmed from our observations that public mesh maps were now storing and, in some cases, tracking node positions over time. While users may have shared their position with their regional mesh, many might not have been aware that this information was being shared publicly online.

This data, being shared by third parties, raised significant concerns regarding personally identifiable information (PII). We recognized that users were not adequately informed about how their location data could be used, which prompted us to act swiftly.

We believe that while users have a responsibility to protect their information, the project also has a duty to the community to ensure that the services we provide do not contribute to potential privacy issues. This commitment is essential not only for the well-being of our community but also to protect the integrity of the Meshtastic project.

The Benefits of the Change​

1. Regional Information Control: By limiting topic subscriptions, we ensure that information stays within its relevant region, preventing groups from sharing data outside users' designated areas.
2. Improved Server Performance: With over 50% of MQTT traffic previously related to position data reporting, this change has significantly reduced server resource requirements. As a result, we have seen improvements in:
   • Availability
   • Stability
   • Reliability
3. Cost Efficiency: Hosting a free service comes with its own set of challenges. The reduction in traffic has led to lower hosting costs, making the service more sustainable in the long run.
4. Continued Success: Like the success we experienced at DEF CON 32, where we implemented previous traffic management policies, we believe this change will further contribute to a successful MQTT server for the community.

New Features Implemented​

In response to community feedback, we have already enacted one of the solutions to enhance user experience. While subscribing to all topics remains disabled, we have introduced precise location filtering. This means:

• Server-Level Filtering: Only position packets with imprecise location information will be passed to the topic, ensuring that sensitive data is not exposed. Note: This filtering is only applied to the default key.

Key Takeaways​

• The Meshtastic project has removed the ability to subscribe to all topics to ensure that information remains within relevant regions.
• Users can still subscribe to regional topics to receive localized updates.
• This change has improved server performance and reduced hosting costs.
• Precise location filtering has been implemented to prevent sensitive data exposure.

Conclusion​

The Meshtastic project is committed to protecting user privacy while providing a reliable and efficient service. We understand that changes can be challenging, but we believe that these adjustments will ultimately benefit our community. We appreciate your understanding and support as we navigate these important changes together.

Thank you for being a part of the Meshtastic community! Your feedback is invaluable as we continue to improve our services. Feel free to use the comment section below.

Since Flood Routing is not very efficient, we realize that this approach is not perfect. The firmware has a number of measures in place to limit traffic in order not to overwhelm a mesh, but as with any RF based protocol, there are limitations to the capacity of the mesh. In attempts to enhance the efficiency, we have evaluated “smarter” routing protocols at times in the past. However, we have yet to find anything that would consistently outperform the current approach in the use-cases and scenarios Meshtastic is currently being utilized. We’ll go over several reasons for why we believe Managed Flood Routing remains a superior approach for Meshtastic.

Key Advantages of Meshtastic's Managed Flood Routing​

1. Eliminates route discovery overhead
2. Provides superior adaptation to dynamic network topologies
3. Optimized for broadcast-heavy traffic patterns common in Meshtastic
4. Demonstrates excellent scalability in low-bandwidth environments
5. Minimizes resource utilization on constrained IoT devices
6. Empirically validated through extensive network simulations

Avoids Route Discovery​

First and foremost, Managed Flood Routing eliminates the need for route discovery or centralized control. In traditional routing algorithms, devices rely on predefined or dynamic routes to forward messages to their destinations. With Managed Flood Routing, you can start messaging immediately after booting your device. Furthermore, route discovery and maintenance leads to overhead, which quickly becomes very significant with a low-bandwidth protocol such as LoRa. In order to maintain routes, either additional control packets are needed, or metadata has to be added to normal traffic. Either increases utilization of precious airtime. In static scenarios, this is not a significant issue, but when the topology changes often -as we discuss in the next section- the overhead quickly outweighs the benefit of a smarter routing protocol.

Seamlessly Adapts to Network Topology Changes​

Another significant advantage of Managed Flood Routing is its ability to adapt to network topology changes. In mesh networks, devices can join or leave the network at any time, and in the case of Meshtastic, nodes are often mobile causing the network topology to change frequently. Even environmental changes such as the weather or the time of day may influence routes. Traditional routing algorithms struggle to keep up with these changes, often leading to message loss or delays. Managed Flood Routing, however, excels in such scenarios. As each device will participate in the routing when called upon, the network quickly adapts to the changes, ensuring that messages find their way to the destination even in the face of frequent topology changes.

Inefficiency is Limited​

A routing protocol aims to deliver packets at the destination in the most efficient way possible. Indeed for packets with a single destination, a lot can be gained by choosing only one efficient route. However, for broadcasts the potential gain is limited, as it is intended to be delivered to every node in the mesh. Since the majority of packets in Meshtastic are broadcasts rather than messages targeting a specific node, a smarter protocol would have limited influence. Additionally, in a wireless medium, even if a packet is directed to a certain node, all nodes in range will witness it and during that time they cannot transmit or receive another packet, meaning that even with a perfect routing protocol, nodes that may not be interested in a packet will still receive it, especially if they have good receiver sensitivity, which is frequently the case for LoRa.

Provides Scalability on low-bandwidth LoRa transport​

Furthermore, Managed Flood Routing is certainly scalable, because nodes that are unlikely to contribute to routing will not participate. In large-scale mesh networks, where hundreds of devices are meshing, scalability becomes a critical factor, and minimizing airtime is king. Traditional routing algorithms often struggle to handle the increasing number of devices and the associated routing overhead, due to the additional control messages required to maintain routes with highly ephemeral topologies. On the other hand, with Managed Flood Routing, new devices joining the network integrate into the routing process without any additional ceremony, contributing to the overall network resilience and message delivery efficiency.

Functions on Resource Constrained Devices​

Finally, Managed Flood Routing minimizes footprint on very resource-constrained low power IoT devices. Traditional routing algorithms often require devices to maintain large routing tables or perform complex calculations, consuming additional RAM, flash, and valuable computational resources. Managed Flood Routing, with its simplicity and distributed nature, significantly reduces the resource overhead. Devices only need to forward messages they receive, without the need for complex computations, resulting in more device resource availability for other valuable features and improved device autonomy.

Many decisions are based on data from Meshtasticator simulations

Considerations and Future Directions​

While Managed Flood Routing has proven highly effective for Meshtastic, we acknowledge its limitations:

• Not optimal for all network configurations
• Potential for improvement in specific unicast scenarios
• Ongoing research into hybrid approaches for future implementations

The current Managed Flood Routing is not perfect and success is not guaranteed, but it has been proven to be effective even in large meshes of more than 100 nodes with proper traffic control. There are trade-offs associated with any approach, and utilizing any “smarter” protocol will inevitably lead to overhead in several ways which, in our view, can quickly diminish its benefits.

As a community, we are raising our voices in opposition to this proposal, and here’s why we believe it’s crucial for all stakeholders, especially amateur radio operators, tech enthusiasts, and public safety advocates, to understand the ramifications of this change.

Understanding the 900 MHz Band and Its Importance​

The 900 MHz band is a critical piece of spectrum used for various applications, including industrial, scientific, and medical (ISM) purposes, as well as amateur radio. It’s a unique band that supports a wide array of technologies, from garage door openers and baby monitors to more advanced uses like Meshtastic’s decentralized communication networks.

Meshtastic leverages LoRa (Long Range) technology to facilitate long-distance communication without relying on centralized infrastructure. This capability is especially valuable in remote areas where traditional communication networks are either unavailable or unreliable. The proposal by NextNav threatens to disrupt this delicate balance by reallocating portions of the 900 MHz band, which could severely impact these unlicensed applications.

Key Concerns with NextNav’s Proposal​

1. Potential Interference with Unlicensed Bands​

NextNav’s proposal suggests creating a 5-MHz uplink in the 902-907 MHz band paired with a 10-MHz downlink in the 918-928 MHz band. However, these changes could lead to significant interference with existing unlicensed, low-power devices that currently operate within these frequencies. For the Meshtastic community and others relying on these bands, the result could be a substantial degradation in network performance, especially in rural and underserved regions where alternatives are limited.

“The 900 MHz band serves as a critical resource for those of us building decentralized networks. Interference from reallocated spectrum could cripple these grassroots communication efforts.” – JM Casler aka MC Hamster, Meshtastic Project Lead

2. Impact on Innovation and Open-Source Projects​

Open-source projects like Meshtastic thrive in an environment where access to unlicensed spectrum is available for experimentation and innovation. By granting exclusive or prioritized access to these frequencies, the FCC risks stifling the creativity and diversity of applications that have historically driven advancements in wireless technology.

The open-source community has long been a bastion of innovation, creating technologies that benefit a wide range of users, from hobbyists to public safety officials. Restricting access to this spectrum could not only limit the development of new tools and applications but also hinder the progression of existing projects that rely on these frequencies.

3. Threat to Public Safety and Community Resilience​

In disaster-prone or remote areas, decentralized communication networks are often the only lifeline when traditional infrastructure fails. Meshtastic’s low-power, long-range communication capabilities have proven invaluable in such situations, providing critical connectivity in times of need. By reallocating the spectrum these networks depend on, NextNav’s proposal could inadvertently weaken community resilience and public safety.

4. Equity and Accessibility Concerns​

One of the most powerful aspects of the unlicensed spectrum is its ability to democratize communication. It allows small-scale operators, hobbyists, and underserved communities to build and maintain their own networks without the need for expensive licenses or subscriptions. NextNav’s proposal risks creating a barrier to entry, effectively widening the digital divide and excluding those who can’t afford to compete with larger entities for spectrum access.

Meshtastic's Formal Opposition to NextNav’s 900 MHz Proposal​

As part of our commitment to protecting the interests of our community and the broader public that relies on the 900 MHz band, Meshtastic has officially filed an opposition to NextNav’s proposed changes with the FCC. This filing outlines our concerns about the potential interference and the negative impact this reallocation could have on open-source projects, innovation, and public safety.

We believe it's vital that the FCC hears from all stakeholders who will be affected by these changes. By formally opposing the proposal, we aim to ensure that the voices of small-scale operators, hobbyists, and underserved communities are heard.

View the Opposition Letter​

This document details our stance and the reasons we believe the proposed changes are detrimental to the community. We encourage our readers to review the letter and consider how this issue might affect their own use of the 900 MHz band.

Key Takeaways​

• Unlicensed Spectrum is Vital: The 900 MHz band is crucial for a wide range of applications, particularly for community-driven projects like Meshtastic that rely on this spectrum to operate effectively.
• Innovation at Risk: Limiting access to unlicensed spectrum could stifle innovation within the open-source community, hindering the development of new technologies and applications.
• Public Safety Concerns: Decentralized communication networks provide critical connectivity in emergencies; reallocating this spectrum could weaken these vital lifelines.
• Equity and Accessibility: The unlicensed spectrum serves as a democratizing resource, and restricting access could disproportionately impact small-scale operators and underserved communities.

Frequently Asked Questions (FAQ)​

Q1: What exactly is NextNav proposing with the 900 MHz band?
A1: NextNav is proposing to reconfigure the lower 900 MHz band by creating a 5-MHz uplink in the 902-907 MHz band paired with a 10-MHz downlink in the 918-928 MHz band, which could interfere with existing unlicensed uses of this spectrum.

Q2: How will this proposal impact Meshtastic users?
A2: The proposal could cause significant interference with Meshtastic’s low-power, long-range communication networks, potentially degrading performance, especially in remote and underserved areas.

Q3: Why is unlicensed spectrum important for open-source projects?
A3: Unlicensed spectrum allows for experimentation and innovation without the need for costly licenses, fostering a diverse range of applications and advancing wireless technology.

Q4: What are the potential public safety implications of this proposal?
A4: By reallocating spectrum that decentralized networks rely on, the proposal could undermine public safety by weakening the communication networks used in emergencies.

Q5: Who stands to lose the most if this proposal is approved?
A5: Small-scale operators, hobbyists, and underserved communities who rely on unlicensed spectrum for affordable communication solutions are likely to be the most affected.

Conclusion​

The proposed changes to the 900 MHz band by NextNav could have far-reaching consequences for a wide range of users, particularly those involved in community-driven, open-source projects like Meshtastic. It’s crucial that the FCC considers these impacts and seeks a balanced approach that protects the interests of all stakeholders, ensuring that this valuable public resource remains accessible for innovation, public safety, and community resilience.

Let’s ensure that the airwaves remain a shared space for all, fostering innovation and supporting those who need it most. Join us in voicing our opposition to this proposal and advocating for a fair and equitable solution.