Meshtastic

Overview

Meshtastic is an open source, low bandwidth mesh network that runs on 933MHz in the U.S. It runs on LoRa radio technology which is very low power, line of sight. Nodes can broadcast for miles if you are high on a hill. In an urban, flat area you might get 0.25 miles. But the power of the mesh is that if just one node can hear your message, then it can be relayed on to others.

Some people use these nodes when they are out camping in the wilderness without any cell phone service. The nodes automatically repeat messages and share their GPS location. It's a great way for a team to stay in touch.

Of course if you are the only person in your area running a Meshtastic node, then you won't have anyone to chat with. If you want to join a local mesh then you should web search for a group of enthusiasts in your area. Often an area will use radio settings that are different from the defaults, so you need to know what they are. For example, in the San Francisco Bay Area there is an active group names Bay Mesh. They use Discord to help people grow the mesh.

You can buy a node for as little as $25. The node pairs with your phone over Bluetooth and you control it via the Meshtastic app. Once you have your node running you can send text messages to other nodes, or send a message to the "general" channel. Channels are encrypted but the General channel has a default encryption key of AQ== so everyone can read those messages.

You can read up on this fascinating technology at the Meshtastic web site.

Why this page?

While the documentation is good, it feels like a lot is left unsaid. This page holds tips, tricks, and just bits of knowledge that we have come across in bringing up our own nodes into the BayMesh. If you read something here that you know is in the docs, please comment or email and we'll replace whatever we have here with a link to the official docs.

Hopefully we'll get this knowledge into the official docs, but that can take a while. In the meantime, this page can be updated on the spur of the moment.

Radio Things

Bay Mesh has some good hardware recommendations.

We have personally used the Heltec V3. It is small and simple to use. It comes with a small whip antenna. When we upgraded with this inexpensive antenna our connectivity went way up.

Many radios run at 125 milliwatt. However, some run at 1 watt which is 8 times the transmit power! We are waiting to receive our B&Q Station G2 to see how much this boosts our experience.

LoRa spread spectrum technology is very good in noisy environments. The radio can reliably receive data at -14dB or better.

Height above ground will dramatically improve your experience. The higher the better. If you drive to the top of a hill your signal will propagate much further. Like A LOT further. In one experiment we got good reception 1/4 mile down the block in an urban setting; the same devices with one on a hill worked at 3 miles! Always line of sight.

With all the nodes rebroadcasting messages you might think the mesh would collapse from congestion; Meshtastic uses some clever algorithms to prevent this.

• When a message is received a node does not immediately resend it. It puts the message in a queue to resend. The queue can hold 20 messages. If the queue is full, then older messages are dropped; this should only happen in the case of high network congestion.
• Nodes keep a list of the messages they have recently received. When a node is ready to resend a message it checks if the message is already on that list; if so then the node does not resend it.
• A node that receives a message notes the Signal-to-Noise Ratio (SNR) of the transmission. A node waits some time before resending the message. The stronger the signal it received, the longer it waits before resending. The idea here is that a high SNR means the sending node is nearby; a low SNR means the sending node is far away. With this algorithm nodes that are furthest from the sender (theoretically) will resend the message first thus pushing the message further away from the sending node. Nodes between the sender and the rebroadcaster will see the resend and that will stop them from resending the message. The range is between 0 and 16 multiples of the slot time.
• Each node monitors the radio utilization. If the utilization is "too high" it waits for the utilization to drop below a certain value.
• When a node is ready to send a message it monitors the radio and waits for a time when the air waves are clear (Channel Activity Detection or CAD). The amount of time needed for this process is called a "slot time".

About ROUTER nodes:

• Note that ROUTER node resends quickly and it always sends every message it gets. The assumption is that only nodes in key mesh positions will be set to ROUTER.
• Note that ROUTER_LATE also resends every message it gets. However, it will resend after the end of the longest client window (a second or two). This gives Client nodes a chance to mesh messages before the ROUTER_LATE resend would shut them down. This is intended for the case of a directional antenna that is specifically pointed to link to another far away area. Think of this as "wait until the normal mesh nodes are done, then speak anyway".

Configuration Notes

The default is "Client". In this mode your node will participate in the mesh by retransmitting messages it receives. (This is a simplification, read the Meshtastic web site for more details.) However, this can clog up the mesh. Unless you are building your own network in some remote wilderness, your nodes should always be configured as "Client Mute", or "Client Hidden". NEVER configure as "Repeater" or "Router" until you know your local mesh needs that.

One exception - Suppose you have several devices in your home / building. In this case you could have one node put up high, maybe in the attic or on the roof, set to "Client" while all your other nodes are "Client Mute". This way your mute node messages will get picked up by your roof top node and it will send them on to further nodes.

Channels

The Meshtastic documentation uses the term "Channel" when discussing radio presets. This is confusing. A Channel in Meshtastic is a communication mesh on top of the radio mesh. Each channel has a name and an encryption key. While nodes in the mesh will pass on channel messages, they cannot read the contents. Only nodes that know the channel name and encryption key can read the messages sent on that channel.

Channels have other control attributes, such as whether to share exact position with other nodes in that channel.

Channels choose a frequency to broadcast on that is slightly different from the base frequency chosen for the LoRa radio - typically through selecting a pre-set. The exact frequency is based on a hash of the name of the channel and the encryption key for the channel. This makes is unlikely for two Channels to pick the same exact frequency and thus avoids collisions and congestion. Nodes can receive and rebroadcast all the possible Channel frequencies the could be used in their radio mesh.

Each node has one Primary Channel. The primary channel is where the node will send periodic announcements of its location and status. In Android the default channel name is the LoRa radio preset in camel case. In iOS the primary channel name is blank. The firmware interprets the blank channel name as "take the preset name and camel case it". (What if a node is not using a preset?) By default the primary channel has an encryption key of AQ==

Position Info

There are several ways to control how much positional information is shared. First, you can configure your node to not share position information, then nothing gets out. Second, if your device does not have its own GPS unit, then it gets the GPS position from your phone when you are connected. On an iPhone you can choose to share "precise location" or not. If you don't share precise location, then iOS takes care of fuzzing your location. Next, Meshtastic nodes have a position fuzzing function as well. You can choose to fuzz your location from 150 feet miles to 14 miles.

Position sharing can also vary by Channel. You can choose to have the node not fuzz location on a particular channel. Of course, a node without GPS cannot report position any more accurately than what is provided by iOS; the errors build on each other.

If you set your node to use Fixed Location then when you save that choice the node gets a position update from your phone and uses that (subject to any fuzzing the phone does on location) but does not apply the Meshtastic fuzzing. (Is this true, or does the node use the last position it used in reporting its location to the mesh?)

Position Precision documentation

Node Info

Nodes will send out a Node Info message base on the interval in Settings / Device / Node Info Broadcast Interval. It is recommended to set that to 3 hours or more in big meshes. Node Info messages contain the node name, hardware type, location (if allowed), firmware version, etc.

If you change your device name, other nodes will not immediately pick up the change; their own NodeDB will have the old information. Other nodes will update when they receive the next Node Info packet from your node.

Consider that not every Node Info message will reach every node in the mesh. If you have been moving around with your node then many remote nodes may have old node info data for a long time.

OK To MQTT

This value is set by the node that originates the message. If the message reaches a node that bridges the mesh to MQTT on the internet then only messages marked OK To MQTT will be passed on.

Some areas (like the SF Bay Area) have some nodes that send traffic to a public logger using MQTT. In this particular case you can monitor the #_logger channel in their Discord server and see traffic there. This is an excellent way to see that your messages are making it into the mesh. It takes just a few seconds for your message to appear in the logger.

Note that if a gateway node (one that sends messages to MQTT) refuses to resend a message due to channel utilization, it also will not send the message to MQTT.

Control

Depending on your hardware, you can communicate and control the node through a serial cable, Bluetooth, or over WiFi.

Bluetooth

The simplest way to configure and communicate through your node is with the smart phone Meshtastic app. You pair the node with your phone over Bluetooth and then can see data from the node. There are also Mac and Windows apps that work to some degree - I've found them a bit flakey.

While a node can be paired with several devices, it can only be connected to one at a time. If you connect to a node with your phone and then go to the laptop app you won't see the node there. You need to disconnect the phone from the node before you can see it in the laptop app - or with another phone.

Sometimes things have become pretty confused and we had to "forget" the node on our Bluetooth devices to get it all working again.

Serial

If you run the laptop app you can connect a serial cable to the node. This seems pretty stable. However, you MUST use a cable that supports data. A lot of cheap USB cables are power-only and this can be very frustrating. If it isn't working, check the cable.

WiFi

Some nodes support WiFi. Often when you enable WiFi it disables Bluetooth. WiFi REQUIRES an SSID on 2.4GHz that is NOT SHARED with a 5GHz network. For example, many home WiFi networks use the same SSID for 2.4 and 5 bands. The access point then "steers" devices to the correct band. This confuses the node and you'll have intermittent success. Find a way to have an SSID for just the 2.4GHz WiFi band and you'll see things work.

When on WiFi you can use a browser to connect to the node through the Meshtastic client. I've found that works, but is confusing. If you get stuck, refresh the page and start again.

Another excellent choice is MeshSense software. This open source solution connects to nodes and gives you great insight into what's going on. It is not good for having text conversations, that is best done in the phone app.

Apple iPhone App

Each node keeps a Node DB with information on other nodes it has seen. This is displayed as a list and a map in the app.

A node can only be connected to one device at a time. When you disconnect from a node the info remains in the app for you to see. When you next connect to a "new" node with the app it will forget everything from the previous node and gather the node db from the current node.

In the node map, pulsing nodes are ones that have been seen "recently", whatever that means.

In the node map, a halo around a node indicates that the node is not sharing precise GPS location. The node is just "somewhere inside that halo".

Nodes running "older" versions of the firmware will incorrectly show up as "directly connected" in the node list because they cannot handle the hop start info in the messages. They still resend messages.

LoRa Details

Meshtastic runs over LoRa. For those familiar with LoRa you might wonder what settings are used. Meshtastic allows any of the LoRa parameters, but also supplies a number of "presets". This is important because radios must use the same LoRa settings (e.g. network id, bandwidth, spreading factor) to be able to communicate. For example, if some nodes use a spreading factor of 7 and others use 9, they will not communicate; you will have two meshes. There are a few exceptions.

Coding Rate does not affect the ability to communicate. A node in a noisy environment could choose to use a lower coding rate and still participate in the network. The lower coding rate would only affect communication to the first hop. Lower coding rate will make the messages take more air time, thus increasing congestion.

We do not know if preamble length affects the mesh.

Solar Powered Nodes

Solar powered nodes in strategic placements can really improve and extend the mesh. Many people have built solar powered nodes to put up in trees or on mountain tops.

Some people have used the Harbor Breeze Solar Light to power a node. It's definitely the cheapest way to get into a solar node. You can make better ones but in CA where is is sunny all the time it's just fine. If you were in Washington it might not be sunny enough for this solution.

Here is a nice solar build step by step and the parts list.

Things I'd like to know

1. MeshSense: What is the meaning of all the Types of messages? POSITION_APP TELEMETRY_APP NODEINFO_APP
2. MeshSense: Is there a way to set Favorite for a node?
3. MeshSense: Can MeshSense change the configuration of a node or is it just read only?
4. MeshSense: Is there a way to view a conversation in a Channel?
5. NodeDB: How does the node short name get updated in the NodeDB? We might change a node's name and it takes all day for it to propogate.
6. NodeDB: When do nodes get added to the NodeDB?
7. MeshSense: Can we tell if a message has been acknowledged by another node?
8. Heltec V3: What does the Program button do?
9. Config: Under Device / Rebroadcast what does "Local" or "Known" mean?
10. Config: Display / Carousel Interval: in iOS app the value can be "off". What value does the correspond to in the web config app where the selector goes +/-.
11. Heltec V3: The display shows an arrow and a dot for the displayed node location. What does the config value "always point north" mean?
12. What is the best way to administer a node that is at the top of a pole? What if it is not in WiFi range? What if out of BT range?
13. iOS: When I click to view the Logs, why is it always blank?
14. iOS: When sending a message to a node what does "unknown public key" mean and how does it resolve itself over time?
15. MeshSense: Is there any way to search the node list?
16. What actually happens when one node sends a position request to another node?
17. iOS: Does Settings -> Device -> Reset NodeDB reset the nodedb in the node, or just the copy of it that the app has copied over?
18. When is a node's info deleted from a NodeDB?
19. iOS: iOS has a location setting called "only when using app". Assume this is set. I then run Meshtastic connected to my node. I then run a different app. I then lock my phone. I drive around with my node in my pocket. Does my node get new position updates from the phone? Does the iOS location setting "Always" change this behavior?
20. regarding location privacy on the Primary Channel. According to the documetation one's position is always shared on the Primary Channel: https://meshtastic.org/docs/configuration/tips/#not-sharing-your-location However, at least as of Firmware 2.6.4, the option exists under even the Primary Channel to disable Position. Does that mean that we no longer need to go through the process to rearrange our channels to stop broadcasting our position? Can we instead just disable Position on the Primary Channel?