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

Check out their glossary of terms and their configuration tips.

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. OR, if you read something here that you think is wrong or off base, please post to the #docs channel on Discord.

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.

AND, if the reader feels like it, please take information from this page and add it to the official docs.

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. Another tip is to use a directional antenna to get your node onto the local mesh. If you know where other stable nodes are, then you can point your antenna in their direction. Directional antennas are easier to find and cheaper than buying a more powerful radio. For a stationary node you can tape a 10" x 10" sheet of aluminum foil to a piece of cardboard and place it about 3.1 inches behind your antenna to increase the directionality of the antenna. We had a 3dBm antenna and the aluminum element dramatically helped.

Many radios run at 125 milliwatt. However, some run at 1 watt which is 8 times the transmit power! I'm told that the B&Q Station G2 is fantastic, but costs more than other rigs. It is very powerful with a 4 watt radio, which is illegal to use above 1 watt. Set the node output power at 6dBm; since it has an amplifier that will equate to about 29dBm. We are waiting to receive our B&Q Station G2 to see how much this boosts our experience.

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.

Protocol Details

Best to read the official docs

LoRa Details

Meshtastic runs over LoRa. LoRa is a spread spectrum technology.

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

The LoRa Physical Header contains a sync word, which is a unique identifier that allows different LoRa networks to distinguish themselves. For Meshtastic, this sync word is set to 0x2B. This allows Meshtastic radios to recognize and process packets that are intended for their network and filter out other LoRa traffic that might be on the same frequency.

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, frequency slot) 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 between nodes. 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.

The actual center radio frequency used is configured using the Frequency Slot. Nodes using different Slots cannot communicate with each other. Different regions have a different number of Slots available. The number of slots also depends on the LoRa Bandwidth setting. More info Note that Medium Slow uses Slot 52; Medium Fast, 45; Long Fast, 20. Use the frequency calculator to discover the actual center frequency.

On iOS, if you set the Slot to 0, then the firmware will pick a Slot based on the name of your Primary Channel. Your Primary Channel name should either be blank, or match the camel case name of the preset you use. For example, if you set Frequency Slot to 0 when using the Medium Slow preset, your Primary Channel name should be MediumSlow or blank. If not, you will not be on the same Frequency Slot as the general population of nodes using Medium Slow preset.

By choosing LoRa settings and/or frequency slot that does not match one of the presets you will create your own independent mesh. But where's the fun in that?

The Mesh

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 30 messages of all types. 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. When the ROUTER node sends a message many clients waiting to resend the message will hear the ROUTER's resend and then not resend the message themselves. If everyone runs as ROUTER then the mesh will be flooding every message and collapse from over utilization.
• Note that ROUTER_LATE also resends every message it gets. However, it will resend after the end of the longest client resend wait 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".

Messages

When a node wants to send a message, it waits for a clear time on the radio. See the doc.

When a message is sent, remote nodes in the same mesh may receive it and decide to resend it.

A broadcast message is one sent with no recipient. For example, automated Node Info and telemetry "broadcasts". All messages sent on one of the Channels (see below) is considered a broadcast message because it does not have a recipient. If the sending node hears its message rebroadcast by another node, then the message is marked "acknowledged".

Messages that are not acknowledged will be resent up to two more times. Typically within a few seconds.

A direct message (DM) is one sent with a designated recipient node. Nodes are designated using their hex id. For example, !432e1cd4 When the sending node hears its message rebroadcast by another node, the status becomes "acknowledged by another node". When the message reaches the designated recipient node, that remote node will reply with an ACK message. If that message makes it back to the sending node, then the message status is "acknowledged" and a green lock icon appears on the message (iOS).

Note that a mesh is dynamic. A message might make it to another node and be rebroadcast, yet the originating node does not hear the rebroadcast for some reason, so it sends the message again. If this happens 3 times the status will be "Max Retries Reached", even though the message made it to the mesh. Or the ACK from a recipient might be lost on the way back to the sender. These things can be more common in a mesh that is experiencing congestion. So your local node might think a message was not acknowledged even though the message was received by the mesh and the designated recipient.

The longer the message, the more likely it is to fail. Reason being, these devices have relatively slow data transfer rates. The signal has to be strong enough at the receiving end for the entire message. Shorter messages are less likely to be 'broken' by having bits lost in transmission.

Encrypted Send Failed

A node sending a DM to a remote node may get the "Encrypted Send Failed" message. This happens when the sending node has a public key that does not match the key of the recipient node. These keys are kept in the NodeDB and advertised by periodic Node Info messages. A node might have a bad key for a remote client that has changed its public key, perhaps through a full reinstall of the firmware. To correct this, the sending node should delete the remote node from its NodeDB and wait for the entry to be added again. Having the remote node send a message on the Primary Channel that the local node sees can facilitate this.

No Channel

Similar to the Encrypted Send Failed error, this can happen when the recipient node has aged out of the device NodeDB after the phone app has already pulled the NodeDB. Thus the phone app has a node in it that is not present in the device NodeDB. Fix this by exiting the phone app and reconnecting to the device.

Note, however, that if the recipient node is no longer in the device NodeDB, then you will not see it in your node list after restarting the app - that node is gone. To prevent this, you should mark nodes as "favorite". Nodes that are marked as Favorite are not aged out of the device NodeDB.

(In a future version of the apps, any node that you DM will automatically be marked as a Favorite.)

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 (modem) presets. This is confusing. I discourage the use of Channel when talking about radio presets.

A Channel in Meshtastic is a communication mesh on top of the radio mesh. Each channel has a name and an encryption key. When a node receives a message it will try to decrypt it. The clear text message header has a hint in it (a one byte hash of the channel name) so the receiving node can guess which encryption key in its configuration to try - it does not have to try them all. If a node has the correct decryption key for the message, then it can read the contents.

While nodes in the mesh will rebroadcast channel messages, only nodes that know the channel name and encryption key can read the messages sent on that channel. If a node can read a message is it considered to be on a "local" mesh; other messages are considered on a "foreign" mesh.

Nodes can be set to only rebroadcast messages that are on their "local" mesh.

When a node receives a message that it can decrypt, it adds the originating node to its NodeDB and traffic from or to that node is considered "local". Note that setting a node to rebroadcast only "local" mesh traffic does not clear out the NodeDB. So it is possible that after setting a node to rebroadcast only "local" mesh traffic, it will continue to send messages that it is unable to decrypt. This will continue until the nodes addressed in the messages are aged out of the NodeDB. So, if you want to immediately stop forwarding "foreign" mesh traffic you should set local-only and clear your NodeDB. < Could use some double checking on this point. >

Each node has one Primary Channel, Channel 0. The name of the Primary Channel is used to determine the Frequency Slot that the node radio uses. Only nodes that use the same Frequency Slot can participate in a mesh. The user can also manually set the Frequency Slot, then the name of the Primary Channel is irrelevant. Frequency bands in US.

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

Default Channel

Each mesh has a default Channel configuration that is the camel cased name of the preset and the encryption key of AQ==. This generates a Frequency Slot. Different presets generate different default Frequency Slots. LongFast / AQ== indicates Slot 20; MediumSlow / AQ== indicates Slot 52. (Note that in the iOS app the default channel name is just left blank and the firmware in the node fills in the channel name.)

If NOT using a preset and the Channel 0 name is blank, then the firmware will use the word “Custom” to determine the frequency slot.

Primary Channel

Typically the Primary Channel uses the default Channel name and key.

Node telemetry data is sent over the Primary Channel - such as periodic Node Info messages. Automatic broadcasts, such as periodic Node Info messages, are always sent over the Primary Channel.

Some owners prefer to change the Primary Channel for their node. They do this by changing the name or encryption key (preferably both). In this way only nodes who have a channel with the same name and encryption key can read messages sent by this node. Thus, telemetry messages like Node Info sent over the Primary Channel are not readable by all other mesh participants. However, when they change the Primary Channel name their node is likely to pick a different Frequency Slot. If an owner wants to participate in their local public mesh, then when changing the name of the Primary Channel, they should purposely set the Frequency Slot for the preset they are using (see Default Channel above).

However, when node X sees a message from node W in a channel they both have configured, it may issue a Node Info request to node W in the same channel and node W might respond with Node Info in that channel. Of course, node X and W must share a Channel for this to happen. A node will not request a Node Info exchange if the node is just resending a message is cannot decrypt.

Questions:

1. Is there a configuration to stop these node info responses on the Primary Channel?
2. In this configuration, if the node issues a position request to another node does it go out on the Primary Channel? If so, then unless the other node also has the same channel name/key it will not respond, right?
3. If a node does not have any channel configured with the default channel, then messages from all the "normal" nodes on the network will be encrypted and its nodedb will never get Node Info messages.

Secondary Channels

A node may have several other channels called Secondary Channels. Each Secondary Channel has a name and encryption key. These channels all use the same radio Frequency Slot determined by the settings of the Primary Channel for the node.

Messages in these Secondary Channels can only be read by other nodes that have a channel with the same name and encryption key. Thus, a Secondary Channel is a way for a group of nodes to communicate with each other in private, while still using the mesh to transport their messages.

Suppose a node changes its Primary Channel to some other name/key. Another node uses the same name/key pair for a Secondary Channel. The two nodes can still communicate as long as they have compatible radio settings.

Question:

1. So, when a node receives a message does it try to decrypt the message with all the channel keys in its configuration?

Position Info

Note that position info is specified by the sending node and can be completely fabricated. A node can report itself at any lat/long it wants.

When positional information is automatically shared, it goes out on the Primary Channel (Channel 0).

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. Because Meshtastic position fuzzing just truncates lower order digits of the latitude/longitude the nodes using fuzzing will appear to lie on a grid when mapped.

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.

Question: Is this true, or does the node use the last position it used in reporting its location to the mesh?

A node can send a position request to another node. If done through a phone app, then the request is sent on Channel 0. If the request is sent through the CLI, then it can be sent on a specific channel. If the receiving node does not have the channel configured, then it cannot decode the message and will not respond. A node might still not respond to a position request based on its settings.

Position Precision documentation

Questions

1. Do nodes ever automatically request the position of another node?
2. When a node receives a position request, does it always respond, based on configuration, or is there some minimum time between position responses, as there is with Node Info requests?

Node Information

NodeDB

Nodes each maintain a NodeDB. When you connect to a node with an app, the app will read the NodeDB and display information from it.

You can designate nodes as "favorite" and typically the app will put those nodes at the top of the displayed node list.

Nodes are added to the NodeDB when the node receives a NodeInfo message from a remote node.

The node's NodeDB holds 80 entries. They age out FIFO. A node that has been marked as a "favorite" will not age out of the NodeDB.

You can "reset NodeDB" to clear the NodeDB on the node. You might do this if you change meshes (choose a different pre-set) or if you change location and want to focus only on nodes in the new location. Resetting the NodeDB will wipe out favorites as well.

Node Info

Node Info messages contain the node name, hardware type, location (if allowed), firmware version, etc.

Nodes will send out a Node Info message on Channel 0 based on the interval in Settings / Device / Node Info Broadcast Interval. It is recommended to set that to 3 hours or more in big meshes. On busy networks the node will send even less frequently than the configured interval. On a really small network (like 10 nodes in the NodeDB) a node might send more frequently. In general it can, and should, take hours to discover all nearby nodes. The firmware uses this algorithm

ScaledInterval = Interval * (1.0 + ((NumberOfOnlineNodes - 40) * 0.075))

NodeInfo messages are sent with the configured Message Hop Count Limit.

If a node receives a message on a Channel that it can read (decrypt) and it does not have the sending node in its NodeDB, then it will send a node info request to the sending node. A node will not respond to a Node Info request if it has broadcast a Node Info message within the last 5 minutes.

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 NodeInfo message from your node. If a remote node changes their private/public key (for example by a reinstall of the software without backing up the keys) then when you try to DM that node you will get an error - until your node's NodeDB gets an update from the remote 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.

Questions:

• Does the interval scaling only apply to telemetry? Or does it also apply to NodeInfo?

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.

Traceroute

The firmware will not do more than one traceroute every 30 seconds. This is to prevent congestion.

In a traceroute to a destination node, all the nodes that pass along the traceroute will add their name, SNR, and SSRI to the message. If the traceroute makes it to the destination, that node may reply to the sender. On the way back to the sender, nodes that pass along the traceroute will add their info to the message. It the traceroute makes it back to the originator then you can get some information on the paths.

A node in a traceroute might be listed as "unknown" because it is not in the local node's NodeDB. Nodes that receive a Traceroute reply do not add all the nodes in the reply to their own NodeDB; that only happens when they receive a message from a particular node.

A node might be listed as "Repeater" (when it is not configured as a Router) because

1. it does not have the channel name and key that were used for the channel that the traceroute was sent on.
2. it is running firmware older than 2.5

In this case we only know there was a node involved because it decremented the hop count in the message.

Nodes will show up as FFFF in Traceroutes when they don't have the public channel set up.

If you see a node name but a ? for SNR, that is pre-2.5 firmware.

An example traceroute

> Route: jschrempp makernexus.org --> jbs1 base San Carlos makernexus.org (8.75dB) --> Herkimer-O (-16.5dB) --> Herkimer-1!433d26b8 (8.5dB)
< Route Back: Herkimer-1!433d26b8 —-> Herkimer-O (8.25dB) --> jbs1 base San Carlos makernexus.org(-4.75dB) --> jschrempp makernexus.org (8.25dB)

Device Config

Questions:

1. Under 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 +/- ? Is it 0? -1?

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.

If you get the message "you might have to forget this device" on your phone, then you do that, and eventually try to re-pair your node but the node does not display the Blue Tooth key ... Perhaps your node is currently connected to another device? Maybe you ran the Meshtastic client on your laptop and it automatically reconnected to your node and so now it isn't available to your phone? Not that this happened to me and took me 20 minutes of angst to figure out. Nope, not me. Asking for a friend.

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.

Via the Mesh

Like one up on a pole. Administer it over the mesh.

CLI

The command line interface is available in Python CLI

The --configure command does not take all the configs from the exported file, however. This is an issue with restoring configs. Don't count on the restore to bring back your whole config.

You can request Telemetry from another node using the CLI. Telemetry includes items like battery level, temperature, and info about any sensors that are connected.

Questions:

• How does Telemetry differ from NodeInfo?

Apple iPhone App

Each node keeps a NodeDB with information on other nodes it has seen. This is displayed as a list and a map in the app. Nodes keep about 80 entries in their NodeDB, aging out older ones that are not marked as favorites. However, the iPhone app can hold information on more than 80 nodes. So, it is possible to see nodes on the map on your iPhone that are no longer in the device's NodeDB. If you try to DM one of these nodes you will get an error.

When you DM a node it is automatically favorited so that the keys don't roll out of the firmware's NodeDB.

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.

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

• Nodes that do not share position information are not shown on the map.

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.

When you click to View Logs, it can take quite some time for the display to populate.

If you want to suppress notifications for messages on a channel, go to Messsages / Channels then long press on a channel name.

DM Help is available if you go to Messages / Direct Messages and tap on the little question mark circled in the lower left of your display. This is a hidden gem!

In a DM, a little green lock means the specific node you messaged has acked you. Your message made it.

Note that you can not send a Telemetry request from the iOS app. You have to use the CLI.

Note that if you experiment with non-preset radio settings, the iOS app does not always communicate the changes in an effective way. One known limitation is that when running a custom setting the iOS app allows you to specify a Bandwidth of 250 kHz but the node receives a value of 0, and the firmware does not interpret that correctly.

Questions

1. 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?

Apple MacOS App

There is an app but it is no longer being updated.

MeshSense App

This app can be used to monitor and control a node. MeshSense is open source and gives great insight into what your node is doing for the network.

It is recommended that you turn off "Automatically send Traceroute requests to active nodes when missing or when hops change" because it can result in a lot of mesh traffic. You find this through the gear icon in the upper right corner, then Settings.

Questions:

1. What is the meaning of all the Types of messages? POSITION_APP TELEMETRY_APP NODEINFO_APP
2. Is there a way to set Favorite for a node?
3. Can MeshSense change the configuration of a node or is it just read only?
4. Is there a way to view a conversation in a Channel?
5. Can we tell if a message has been acknowledged by another node?
6. Is there any way to search the node list?

Visualize the Mesh

Your node has a view of the mesh based on the nodes it has heard from. To get a bigger view of the mesh in your area, look for a local group that logs and plots nodes. For example, the Bay Area group has an online map view of the nodes. Note that you can filter this to show nodes on the two meshes in the Bay Area; the long-fast and the medium-slow meshes.

Hardware

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

This is an Instructable for a waterproof solar node.

This is a pre built outdoor node 150mw from Seeed Studio

And a nice, tight package from Rak.

Or cheapest node we've seen.

Heltec V3

If your device does not have a battery, it has been reported that using USB-C cable for power can cause messages to fail to send. If you add a USB-C to USB-A adapter then delivery success goes up.

The "program" button will cycle the little display through the last 8 message screens.

A better antenna can be added. Basically all radios use a IPEX connector on the board, and then an antenna pigtail that changes the IPEX connector to a SMA Female. Then the actual antenna has a SMA Male connect.

Questions

1. The display shows an arrow and a dot for the displayed node location. What does the config value "always point north" mean?