News

• When In Doubt Client Mode
• Meshtastic v2.6 A Feature-Packed Release
• Ok to MQTT (Why We Need It)
• Introductions Are in Order
• Welcome To IowaMesh and the New Format

When In Doubt Client Mode

When In Doubt Always choose Client Mode (A guide to roles on our devices)

One of the things that need to be address up front as IowaMesh grows will be the appropriate use of the modes. Probably another controversial post much like the Ok to MQTT post, but it’s a good chance for all of us to look at the choices we make and out it effects the Mesh

So Lets get on with it!

Selecting the appropriate device role is crucial for maintaining an efficient and reliable Meshtastic mesh network. With recent updates to Meshtastic, certain roles have been refined or deprecated to enhance network performance. For mobile nodes and specific stationary scenarios, Client and Client Mute modes are often the most suitable choices. Let’s explore these roles and discuss the implications of misapplying routing roles.​

Updated Meshtastic Device Roles: Meshtastic nodes can be configured with various roles, each tailored to specific functions:

• Client: This is the default role for most nodes, enabling standard communication capabilities. Nodes in Client mode send and receive messages and participate in routing when necessary.

• Client Mute: Similar to Client mode but with routing disabled. These nodes send and receive their own messages without relaying messages for others, reducing network congestion in areas with high node density. ​

• Router: Intended for stationary nodes strategically placed to route messages and extend network coverage. Routers prioritize relaying messages from other devices and attempt to conserve power by reducing their own transmissions.

• Repeater: Functions similarly to a Router but focuses solely on rebroadcasting messages without originating its own. Repeaters are typically used to enhance coverage in specific areas. ​

• Router Late: A newer role designed for nodes that should act as routers but with a delayed rebroadcast, allowing other nodes to transmit first. This role helps in scenarios where a node is well-placed but should not dominate the routing process. ​

• Sensor: For devices primarily gathering and transmitting sensor data. While they can route messages, their main function is to report telemetry, even during high channel utilization. ​

Notably, the Router-Client role has been deprecated in recent Meshtastic versions to simplify role assignments and improve network efficiency.​

So lets look at some advantages and disadvantages

Advantages of Client and Client Mute Modes for Mobile Nodes:

• Network Efficiency Mobile nodes in Client mode can participate in routing when necessary, but in areas with dense network coverage, this can lead to redundant transmissions. Switching to Client Mute mode in such scenarios prevents unnecessary rebroadcasts, reducing the risk of packet collisions and network congestion. ​
• Battery Conservation Routing and rebroadcasting consume additional power. By operating in Client or Client Mute mode, mobile nodes conserve battery life, extending their operational duration—especially critical for handheld or portable devices.​
• Stability and Reliability Mobile nodes frequently change positions, leading to variable connectivity. Assigning them as Routers can disrupt message paths when they move out of range. Keeping mobile nodes in Client or Client Mute mode maintains stable routing through strategically placed stationary routers.​

While stationary nodes often serve as Routers to extend network coverage, certain situations warrant using Client or Client Mute modes Considerations for Stationary Nodes:

• Specific Use Cases: Nodes dedicated to particular functions, like sensors, may not need to route messages.​
• High-Density Areas: In environments with numerous nodes, excessive routers can lead to packet collisions and reduced network performance.

So what are the risks of misapplying Router and Repeater Roles:

• Increased Packet Collisions
• Overuse of Routers and Repeaters, especially in close proximity, can cause simultaneous rebroadcasts, leading to higher noise levels and packet errors.
• Reduced Network Range Improperly placed routers may consume message hops prematurely, preventing packets from reaching more strategically located nodes and limiting overall network range.​
• Asymmetrical Links
• Poor router placement can result in one-way communication, where messages are sent but responses cannot return, disrupting effective two-way communication.​

Sometimes it’s hard not to be that guy but maybe with a little bit of explanation we can help make sure the mesh stays working well for everyone.

So I might argue here that Client will be the choice of modes for most of us. I might even go as far as Client Mute especially if you are travling by plane. The traveler bridges larges area’s for a while, but then breaks it again. Would love to hear your feedback as well! Hope this helps as we continue to grow the mesh here in Iowa!

Meshtastic v2.6 A Feature-Packed Release

Meshtastic v2.6: A Feature-Packed Release

Meshtastic recently announced the public release of Meshtastic v2.6, a major update that has been years in the making. This release introduces several exciting new features and improvements, making it the most feature-packed Meshtastic to date. Here’s a summary of what’s changed in Meshtastic v2.6.

Key Features in 2.6

1. Next-Hop Routing

After extensive preparation, implementation, simulations, and real-life testing, Meshtastic introduced a more efficient routing protocol for direct messages called “next-hop routing”. This new protocol is designed to optimize the delivery of direct messages.

Meshtastic uses a “managed flood” approach for message delivery, where multiple devices attempt to relay messages. While effective, this method can lead to network congestion especially for direct messages. Next-hop routing addresses this by designating a specific device to relay the packet, reducing unnecessary transmissions and improving overall network efficiency for direct messages. If a node moves or RF conditions change, the next-hop designation may become invalid. In such cases, the node will fall back to managed flooding at the last retransmission attempt if it does not hear its next-hop relay.

Next-Hop Header: The last two unused bytes of the unencrypted Meshtastic header denotes the current relayer and the next-hop node. This approach ensures minimal routing control overhead and memory usage while maintaining compatibility with older firmware versions.

Stages of Establishing A Next-Hop

1. Initial Transmission: When a new message is directed to a single destination, it will use the managed flood approach.
2. Acknowledgement or Response: If a response (e.g., NodeInfo response, acknowledgment, or traceroute) is received and the relaying device matches one of the original relayers, it is designated as the next-hop.
3. Subsequent Transmission: Any future transmissions will use the designated next-hop node to relay the packet, reducing the number of devices involved in the process.

2. Meshtastic UI (MUI)

MUI is a brand-new interface for compatible standalone Meshtastic devices offering a seamless touchscreen experience, allowing users to interact with the network without needing a phone. MUI is still in early development, and Meshtastic is actively working on adding more features and improving performance.

MUI is compatible the following devices: LilyGo T-Deck, Seeed SenseCAP Indicator, unPhone, PICOmputer, T-HMI, Mesh-Tab,Raspberry Pi, LuckFox with TFT SPI and LoRa hat, or PC with Meshstick.

MUI Features

1. Dashboard Screen: Displays device status, new messages, detected nodes, date and time, radio settings, GPS, sound, Wi-Fi, and MQTT.
2. Node List: View, filter, and highlight nodes in your network.
3. Chat Window: Send and receive messages with persistent message history.
4. Dynamic Position Map: Pan and zoom with customizable map styles for better network visualization.
5. Basic Device Configuration: Quickly set up and adjust basic settings without the need for the Meshtastic app.
6. Handy Tools: Includes a mesh scanner, signal meter, traceroute, statistics, and packet log.
7. Bluetooth Programming Mode: Easily update and configure devices wirelessly using Bluetooth.
8. 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. 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.

3. Meshtastic over LAN (UDP)

Added support for messages to be sent 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 with limited RF coverage or when bridging multiple Meshtastic networks over existing infrastructure.

4. 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.

We have been testing the release on several devices for a few weeks, and encourage others to update to the latest firmware to take advantage of these new features. Meshtastic v2.6 represents a significant step forward in our mission to provide a robust and user-friendly mesh network.

Ok to MQTT (Why We Need It)

MQTT (The almost forbidden subject)

What do you think of when I say MQTT? In the nerd spaces I normally occupy that would be Message Queuing Telemetry Transport. In most cases, it’s a great way of getting telemetry data out of IOT devices into some sort of central repository.

In the early days of Meshtastic, it would seem that MQTT was a great way of getting data across larger places especially if there wasn’t enough RF to carry these messages along the way. With growing privacy concerns the developers at Meshtatsic opted (and introduced in 2.5 firmware) to include properties in the packet that ignore MQTT or even permit MQTT.

A user on Reddit I think said it the best: “MQTT is one of the best, and apparently worst parts of the project. I do feel that currently, privacy and security is at risk when using public MQTT (even the meshtastic server), to the point where people could get hurt. I don’t think people should avoid the project, but I do think people should know the extent of the issue, an issue so severe the team has been trying to sweep it under the rug (damage control). They even mute users who bring up the issue in the discord.” - Reddit Source

From the Offical Documents that explain the settings:

Ignore MQTT Setting this to option to 'true' means the device will ignore any messages it receives via LoRa that came via MQTT somewhere along the path towards the device. Note this only works when your device and the MQTT node are running at least firmware version 2.2.19.

OK to MQTT​ Acceptable values: true, false Default is false. When set to true, this configuration indicates that the user approves their packets to be uplinked to MQTT brokers. If set to false, nodes receiving your packets are requested not to forward packets to MQTT. This configuration only applies to Channels configured with the defaultpsk and eventpsk keys set in the Meshtastic Firmware; Channels with custom keys ignore this setting. Important: This is not a cryptographic solution but a polite request that is enforced in the official firmware

So if you’ve stuck with me this far, Thank You. There is an end in sight, I promise,

IowaMesh relies on MQTT right now to keep big parts of the state connected. Without it, there’d be isolated patches where people couldn’t communicate with each other. Our ultimate goal is to shift entirely to RF, but that’s still a work in progress. Once the network is more built out, we’re planning to cut MQTT use down. So for all of you RF purests out there I urge you to consider the bigger picture here.

We take your privacy seriously. If a packet comes into the mesh marked “Ignore MQTT,” we honor that—always have, always will. The Meshmap site has supported this from day one. But there are some things you should know about how this works.

If you choose to ignore MQTT or don’t enable the “OkToMQTT” setting, your messages won’t show up in the Text Messages list on Meshmap. Most head-end nodes have “OkToMQTT” turned on, so your messages will still make their way through the mesh, but they won’t be collected or displayed.

The other thing to keep in mind is that without MQTT, some messages might only reach certain people—or maybe not get through at all, depending on how the mesh is set up that day. RF will still work as expected though, so there’s always that!

Introductions Are in Order

Introducing KN0CTJ

When brainstorming ideas for this blog, it seemed fitting to kick things off with an introduction—so here’s mine.

I’m Calvin, and I recently became a part of both the Meshtastic and Amateur Radio communities following our annual sales conference in Las Vegas. During the event, a group of my colleagues and fellow tech enthusiasts came up with an idea: we’d all head to Vegas, use Meshtastic to communicate, and learn how it works while finally meeting in person. Many of us are scattered across the globe, so this was a unique opportunity to connect.

And so, the plan was set. Twenty thousand of my “closest friends” (our sales teams) descended upon Vegas. As soon as we touched down, Meshtastic nodes began popping up everywhere. About 100 of us actively participated, and I’m already looking forward to an even bigger turnout next year.

Here’s the Reddit post my coworker shared about the event: Reddit Meshtastic in Vegas

After those exciting four days in Vegas, the general recommendation was to find a local Amateur Radio club and see how I could contribute. Unfortunately, my experience with my local radio group wasn’t ideal, but it eventually led me to the Iowa Radio Operators Discord group. From there, I started building IowaMesh.net.

The inspiration for IowaMesh.net came from seeing folks traveling from the Chicago area, joining ChiMesh, and sharing their experiences. I thought it was time to get Iowa involved and see how far we could connect. Since Iowa is pretty spread out, I began with an MQTT server and hosted a meshmap to visualize communication. While implementing RF/Lora remains a goal, MQTT has proven to be a great starting point for linking people together. We’ve expanded coverage to Altoona and Des Moines and are now reaching Jefferson, Greene County, and Cedar Rapids—and we continue growing every day.

Before diving into radio and Meshtastic, I was a Systems & Network Engineer for various companies. Eventually, I traded my 2 AM troubleshooting sessions for a pre-sales engineer role. Although networking remains close to my heart, venturing into Radio, Wireless, and Meshtastic has allowed me to apply my skills in fresh, exciting ways outside of work. It’s been a fantastic change of pace from the “same old, same old.” I’m always happy to chat about networking, radio, or other nerdy projects!

Calvin (KN0CTJ)

Welcome To IowaMesh and the New Format

Welcome to IowaMesh.net

I wanted to take a moment and say welcome to anybody whos joining us here a IowaMesh! What started out as a simple Meshmap, MQTT hosted server and connecting a group of folks from Iowa Radio Operators has evolved into what you see here today. I can’t thank Ethan (@nv1k) for helping get the frame of this built and putting up with my 1000 stupid questions (I wasn’t a developer first; Network Engineer turned PreSales Enginneer). What you see here is hours effort making sure we can best serve the Iowa and potentially further.

We’ll start posting up blog posts with builds and hardware lists. Also have pages for other hardware recomendations and some setup guides for the beginner through the more advanced user. Bear with us as we continue to build out that material (and if you have recomendations send us a note!). Not that this is any bit of an excuse, but this isn’t our day job so we will be working on this as we can. But know that we are dedicated to keep this alive and well!

So whats next? We aren’t sure. We want to build out a backbone across Iowa that users within the State and those traveling through can utilize with Meshtastic. Either way we want to connect with you and your use case and learn more. How could we be a resource to your club or maybe individual effort.

Find us on Discord, Email us with ideas, Find the source on GitHub and We are looking forward to getting to know everyone!

Calvin (KN0CTJ)