Meshcore FAQ and Info¶

MeshCore is a relatively new project, started in late 2024. The software is actively evolving, with new features, performance improvements, and bug fixes being added on a regular basis.

Because the platform is still maturing, you may occasionally encounter bugs or configuration challenges that require some troubleshooting. Community feedback and participation help improve the software, making early adopters an important part of MeshCore's continued development.

Having regions configured may cost battery life¶

I have been testing battery life with and without 6 regions installed in my repeater. Having regions installed does use a small amount more battery power.

When regions are installed on a repeater, each packet being forwarded by the repeater must be checked to see if it matches a configured region. This check involves cryptographic hashing operations that are CPU intensive, so naturally more battery life will be required.

Repeater Configuration	Battery lost overnight (10,000 mah battery)
No regions installed	6% battery loss overnight
6 regions installed	10% battery loss overnight

We need to configure regions in our repeaters¶

Regions are one of those features that's easiest to deploy before you actually need them. In a small or lightly used mesh, leaving traffic unscoped works just fine. But as the network grows (or traffic grows sharply, such as during an emergency), it may be required to use regions in order to maintain communication.

All LORA mesh networks can become fully loaded as the mesh expands. Once the network is fully loaded, messages will stop being delivered reliably. Regions help reduce the load on the mesh by allowing people to limit the range of their messages, preventing the message from traveling over the entire mesh. In the meshcore app, when a region is set on a channel, messages sent to the channel will only travel to the part of the mesh in that region. NOTE: the channel will still receive all incoming messages, regardless of whether or not a region is set.

For example, if I apply the us-va-sw region to the #roanokeva channel, any message I send to the #roanokeva channel will stay within the us-va-sw region, saving the rest of the mesh network from having to repeat the message.

It is recommended to up-size when selecting a region for channel messaging... #cavespringva should use us-va-roa, #roanokeva should use us-va-sw, and #va should use us-southeast. Repeaters are not installed exactly on regional boundaries, and up-sizing the region for the channel ensures that messages are delivered to everyone who uses that channel. Up-sizing the region also allows people who are further away to access the channel, for example using us-va-sw allows our neighbors in the NRV to participate in the #roanokeva channel if they want/need to.

Alternatively, when selecting a region for war-driving, bots, or automated systems, use the smallest region available. These apps use a lot of network load, so they should be setup to use a small local region only. This help ensure the larger mesh can be used for messaging.

The first step, installing regions in repeaters¶

Before anyone can use regions, they need to be installed in repeaters. Coordination between repeater owners is the only way this will work. Repeaters without regions installed will ignore messages sent to regions. So before we can rely on using regions, all (or most) of the repeaters need to have the regions configured.

To configure region scopes in a repeater for our area, please see the meshcore repeaters configuration page.

Why am I missing some messages?¶

Channel messages and direct messages work very differently in Meshcore.

Channel messages are unreliable¶

Channel messages are sent using a single flooded packet to all nearby nodes. Only one packet is sent, but if multiple repeaters are within range of the sender, the packet is effectively multiplied by each receiving repeater. The extra packets are useful to make sure everyone in range has a good chance of receiving the message.

The ISM band where our mesh devices operate is full of small bursts of interference from things like water and power meters. Having multiple repeaters in an area will create redundancy by duplicating flooded packets, increasing the opportunity for companions to receive channel messages, even if some of them are lost due to interference.

Two repeaters, each forwards a copy of the packet containing the sender's message.

            📡 Sending Node
                  )))→

     📡 Repeater 1  📡 Repeater 2
           )))→          )))→

            📡 Receiving Node

Meshcore users who do not have the benefit of multiple repeaters nearby may notice it is difficult to follow channel conversations. In fact so many messages can be lost that a conversation is not even discernible to the receiver. The user may receive occasional stray messages, but not enough to follow a conversation.

Up to a point, adding more repeaters to an area adds redundancy and makes the network more functional.

Sending messages to channels can also be problematic. A conversation may be received in a channel, and you may think you are participating in the conversation, but in fact nobody else is receiving your messages. Your messages will appear in the conversation as it is displayed on your device, but they do not appear on one or more others devices.

How to know you are being received by others?¶

From time to time, be sure to ask if you are being received by others.
Send the word 'Test' to the #test or #bot channel and see if you get a response.
Use an observer website to see if your messages are being received.

Direct messages have delivery confirmation¶

Direct messages do not have the same questionable delivery issue as channel messages, but they can only be sent to one other node.

Direct messages are sent with multiple packets as needed, and message delivery is confirmed with an 'ACK' response. If the first attempt to send a DM fails, the companion will retry several times until delivery is confirmed.

If the message is never delivered, the message delivery is set to 'failed'. No confusion there.

Checking on your messages with Meshcore Observers¶

Observer nodes are placed strategically throughout the network, and we can use them to see if our messages are being sent out properly.

Using the Tennmesh CoreScope System¶

Note: at the time of writing, this server seems to crash often, but when its working, its got the best data.

Start on the Channels Page:

Select the channel name you want to monitor, or
Add a channel name before sending your message

Quietening a Busy Mesh¶

A large mesh can distribute so many messages and contacts it can be overwhelming. These are some settings you can change to help reduce the noise:

Disable notifications on busy channels, such as Public and #test. On your list of channels, click on the three dots menu, select Notifications and select Mentions Only.
Change the Contact Settings in your meshcore app. Your companion radio can only store 350 contacts, and a busy mesh will surpass that quickly.

Go to Settings->Contact Settings, and set Auto Add Max Hops to something low, like 3 or 4 hops. The meshcore app will continue to save all available contacts under the Discover Contacts menu, and you can manually save contacts to your companion radio from that menu if you ever need to.
Add and use local channels. This requires a bit of coordination locally to get everyone on the same channel, so having a list online somewhere is helpful.
Remove the Public channel, or any other busy channel you don't need. Especially remove the Public channel, it can be added back later if you need it.
In extreme cases, you can block the Null region ('*') from local repeaters. (This is not yet recommended by the meshcore developers.)

This will block channel messages and contacts sent without your locally defined regions. This will also block you from sending messages outside your regions. Be sure you have working regions before taking this step.

This will require extra coordination among all mesh members to add regions to their list of channels.

NOTE: There IS a region discovery feature available for companion nodes... Open a channel, from the options go to Set Region Scope, from the options go to Discover Regions.

NOTE: There is discussion about allowing direct messages even when the Null region is blocked, take a look here.

See the regions section above for references.

Using txdelay and rxdelay for repeaters close to each other¶

I have two repeaters in my location because, thanks to surrounding hills, there is no single location with a clear line-of-site to the rest of my area.

I noticed both repeaters attempt to broadcast relays at nearly the same time, and they were interfering with each other. I was able to adjust the timing on broadcasts to help prevent collisions. You make these changes in the 'Command Line' tab when signed into the Admin the repeater.

NOTE: these settings worked for me, make sure you understand what you are changing and use values that make sense for your setup.

Hilltop node