Meshtastic
Troubleshooting and FAQ

You said there were lots of Meshtastic users in the area, but when I look at the Meshview map I only see about a dozen. Why?

The RVAMesh Meshview Map is only able to display traffic it knows about.  A dot won't appear on the map unless the node...

• is within range of an Internet (MQTT) gateway connected to the standard Meshtastic public MQTT server;

• has OK to MQTT enabled in their LoRa module configuration;

• uses LongFast (or Default on iOS) as their primary channel (Ch 0);

• has Position beacons enabled on Ch 0; and

• is sending GPS data with no more than 16 bits of precision (about 1000 feet or more).

If any of those conditions are not met, the station won't show up on the Meshview map.  Notably, OK to MQTT is off by default so most stations won't appear right out of the box.

I just powered up my new node a few minutes ago and I don't see any other users

Your node can only discover the presence of other stations when they transmit on a channel that is programmed into your radio.

• Some nodes may be configured to beacon telemetry, position, or other data very infrequently or not at all.  It could take a long time to discover stations with infrequent transmissions.

• Typically, with most common configurations, other nodes in range should be discovered within a few hours.

• Your node has to hear a transmission before a station can appear in your node database (NodeDB).

• Be sure you have the standard LongFast channel enabled (or Default on iOS) and that it's using the default encryption key AQ==

Try sending a message to #LongFast and see if you get any responses.  If you see a ✓ next to your #LongFast (or Default) message, it means it was heard by at least one other node.  An ⨯ or "Max Transmission Reached" message means your message wasn't heard by any other stations.

I am pretty sure other nodes are nearby but I can't see them and they can't see me

• In the LoRa module configuration, confirm that the country, mode, and frequency/slot are set:  US/LongFast, 906.875 MHz, slot 20 -- or as required by your local mesh

• In the Channel configuration, confirm that the primary channel (Ch. 0) is called LongFast (or Default on iOS) and it is using the default encryption key AQ==

• Check that the Device role is set to Client or Client_Mute. 

• If your device was ever powered on without a properly matched antenna connected -- even briefly -- the transmit or receive circuitry may have been permanently damaged.

• Try a different antenna.  Many "915 MHz" antennas sold on Amazon and various other online marketplaces are actually mislabeled European 868 MHz antennas that won't work well and could damage the radio. 

• There may be a firmware glitch.  Try re-flashing with a slightly newer or older firmware version, such as an alpha test release.  Alphas may introduce other bugs, but a temporary switch could help narrow down whether an issue exists within the device or its firmware.

I'm reaching other nodes but I'm not appearing in the RVA Mesh traffic log, node list, or mesh map

• In the LoRa module configuration, confirm that OK to MQTT is Yes.  This will allow traffic from your node to pass to MQTT gateways and other connected systems like Meshview.

• You may be too far from an MQTT gateway.  You may need to increase power, try a better antenna, and/or slightly increase your hop limit in the LoRa module configuration.

• If your station appears in the traffic log and node list but not on the map, see the next question.

I'm showing up on the RVA Mesh traffic log and node list but my position isn't appearing on the map

• In the Channel configuration, confirm that the primary channel (Ch. 0) is called LongFast (or Default on iOS) and it is using the default encryption key AQ==

• Check that the LongFast channel is configured with Position enabled and Precise Position disabled.  Set the precision to 16 bits or less (around 1000 feet or higher).

I changed my channel configuration and now I don't show up on Meshview

• By default, the frequency and slot are calculated from the name of the primary channel (Ch. 0).  If the channels are re-ordered or renamed, the radio may need manual configuration.

• In the Lora module configuration, confirm that the country code, mode, frequency, and slot are set:  US/LongFast, 906.875 MHz, slot 20 -- or as required by your local mesh

• Meshtastic devices only beacon telemetry and position to the primary channel (Ch. 0).  Meshview monitors #LongFast so if the primary channel is something else, the device won't be seen.

How can I beacon my position only to certain other nodes (like my family members) without everyone else seeing it?

The key is to establish a new shared primary channel:

• In the Channel configuration, create a custom channel and move it to the primary position (Ch. 0).  Enable Position beacons and set the desired Precision.

• In the Lora module configuration, confirm that the country code, mode, frequency, and slot are set:  US/LongFast, 906.875 MHz, slot 20 -- or as required by your local mesh

• Add the custom channel to the other nodes.  If it goes in the primary position (Ch. 0) then you will also see that node's periodic position beacons.

After this change is made:

• Users on the mesh can still request the device location manually over #LongFast if that channel has Position enabled.

• Requests for the device position can be received over any subscribed channel.  Replies will be sent automatically according to the position settings for that particular channel.

As an added privacy measure, if internet linking over MQTT is not needed:

• In the LoRa module configuration, set OK to MQTT to No.  This will instruct MQTT gateways to avoid relaying packets to other nodes over Internet links.

I only want to see my own nodes/friends/family, not the general public.  What do I need to change?

Removing the LongFast channel (Default on iOS) will tune out most other nodes.  You will need to establish a private channel and program it into all other nodes you want to communicate with.  Once you do this, you will no longer hear stations that are transmitting on the LongFast/Default channel.  Resetting your NodeDB will clear previously-heard stations from your node history.

Am I required to share my position in order to use Meshtastic?

No.  Many devices are GPS-equipped, and some aren't.  Regardless, the user is in control.  Override the GPS module and set a fixed position, disable position broadcasts, disable all inbound position queries, and control the precision of GPS beacons and queries using the settings available within the Meshtastic apps.

• Position beacons, if enabled, are sent periodically to radios listening to the sender's primary channel (Ch. 0) -- by default, this is #LongFast (or Default on iOS) and this behavior can be turned off.

• Position queries, if enabled, can arrive over any subscribed channel.  Responses will be sent over the originating channel according to that channel's position settings.  This can also be turned off, per-channel.

Note:  It is strongly preferred that users simply disable position beacons and replies rather than deliberately spoof an inaccurate position for privacy.

How secure is Meshtastic?  Who can read my messages?

Each Meshtastic device has a unique private and public key pair which is used to identify the device and provide for end-to-end encryption of messages and other data.  Further, group messages, position beacons, telemetry broadcasts, and other data types are sent over user-defined channels that each have their own encryption keys.  These are used to enable AES256 encryption but there are some caveats that could make Meshtastic less secure than other AES256-encrypted technologies if the keys are inadequately protected.  There's a good discussion on encryption in the Meshtastic documentation.

Of course, if the node is configured for Part 97 operation, then encryption features are disabled.

Should I back up my encryption keys?

Yes.  The Meshtastic apps and web client offer the ability to export and import the private key from a device.  The resulting file should be stored securely -- offline or in encrypted storage like a password manager.

New keys can be generated through the app at any time.  If a new key is generated, other in-range nodes may need to reset their node database (Node DB) in order to restore communication.

Can I send pictures, video, audio, or other file types over Meshtastic?

No.  Meshtastic is designed for low-volume transmission of small data packets, such as short text messages, position reports, and telemetry.  LoRa achieves its exceptional range and low power consumption by operating at very low data rates, so sending large files would take an impractical amount of time and could block the shared radio channel for everyone else.

There is one specialized exception:  Meshtastic includes an experimental Codec2 audio module that can carry very short voice clips (roughly one second in length) but it requires certain ESP32 radios with added microphone and speaker hardware.  Standard 915 MHz Meshtastic radios do not support practical voice transmission.  Meshtastic is best viewed as an off-grid messaging and information network, not a replacement for Wi-Fi, cellular data, or broadband mesh systems such as AREDN.

Fun fact:  Each LoRa packet holds about 200 bytes of meaningful data transmitted at around 1.07 kbps.  If file transfers were theoretically supported, it would take approximately 40 hours to transmit a 5 megabyte file across two hops, assuming an uncongested mesh and 10% error/retransmission rate.  Customized radio presets can move data much faster, but by default this mesh is built for messaging.

I renamed a private channel and now I've lost contact with other subscribed radios

One peculiarity of Meshtastic is that the encryption keys used for channels are defined by both the PKI (private key) and the channel name.  Renaming the channel -- even if the PKI stays the same -- effectively creates a totally different channel.  For example, LongFast (one word) with key AQ== is not the same as Long Fast (two words) with key AQ==.  Channel names matter.  If a channel is renamed on one device, all subscribed devices must also be updated.

Which Device Role should I use?

• If you're not sure, a safe default for virtually all station types is Client.  In the Client role, a device can interact with the mesh and it relays other nodes' packets in typical mesh fashion.

• Rooftop and treetop nodes that also act as primary coverage for a limited number of personal indoor nodes:  use Client Base.  This role offers preferred handling of packets to and from nodes which have been designated as a Favorite on the Client Base node.  It otherwise behaves the same as Client mode.

• Low-coverage portable nodes that are not expected to significantly contribute to mesh coverage for other devices:  use Client Mute.  This lets the device communicate with the mesh but it prevents re-transmission of other stations' packets, which significantly reduces battery consumption.  It also lowers congestion on busy meshes in situations where there are many nodes clustered in close proximity.

• Devices primarily used for position tracking:  use Tracker.  This role somewhat prioritizes the transmission of position data.

The Meshtastic website has additional information on Device roles.

⚠️ Caution:  Do not use the Router or Repeater device roles without careful coordination with existing mesh stations prior to implementation.  Locally, this would be done through the RVA Mesh Discord.

My device is connected to the public MQTT broker.  This device sees distant MQTT stations, but my other radios do not?

This is normal behavior when using the Meshtastic public MQTT broker, which has a zero-hop policy for packets coming out of MQTT.

• If MQTT Uplink is enabled on a channel:

  • Traffic received via RF will be relayed to distant stations over MQTT, unless the traffic has passed through another MQTT gateway.

  • Traffic generated by this node will be relayed to distant stations over MQTT if OK to MQTT is enabled in the radio's LoRa module configuration.

• If MQTT Downlink is enabled on a channel:

  • Traffic received via MQTT will be displayed on this radio only.

  • The zero-hop policy prevents further retransmission to other nodes.

See our page on Internet Linking with MQTT for more information.

What power limits apply when using Meshtastic in the US?

First, to define some important terms:

• Transmitter power is the amount of radio-frequency energy the radio itself sends into the antenna cable, usually measured in watts or dBm.

• EIRP is the effective strength of the transmitted signal after accounting for antenna gain and cable loss -- essentially, how powerful the signal appears in the antenna’s strongest direction.

For unlicensed operation as a standard Part 15 station:

• The maximum allowed transmitter power is 30 dBm or 1 watt.

• The maximum allowed antenna gain (after feedline losses) without lowering transmitter power is 6 dBi.

• For antennas with gain greater than 6 dBi, reduce transmitter power as necessary to keep EIRP at or below 36 dBm or 4 watts.

• Example:  30 dBm LoRa radio, directly-connected antenna with 10 dBi gain requires reducing transmitter power to 26 dBm or less in the radio's LoRa module settings.

• Example:  30 dBm LoRa radio, 15 feet of RG-174 coax (approx 3.5 dB loss), 10 dBi antenna requires reducing transmitter power to 29.5 dBm to stay below 36 dBm EIRP.

For licensed operation as a Part 97 station:

• The maximum allowed transmitter power is 10 watts PEP or about 40 dBm.

• There is no limit on allowed antenna gain except for the standard Part 97 requirement to use only the minimum amount of power necessary to establish communication.

• Encryption must be disabled and other special requirements must be met.

• Example:  30 dBm LoRa radio, 2 dB feedline loss, 20 dBi high-gain antenna = 48 dBm EIRP or about 63 watts

Here's a helpful dBm to watts converter, and vice-versa.  Also, a handy feedline loss calculator.

What radio frequency safety considerations apply to Meshtastic transmitters?

For fixed stations like rooftop or treetop nodes, you can use a simple RF exposure calculator to determine safe operating distances.  While actual transmitter airtime will most likely be far less than 100%, for purposes of RF safety calculations, it's okay to assume a worst-case 100% transmitter duty cycle.

For body-worn Meshtastic nodes such as radios affixed by belt clip or holster, pager-style radios, or radios kept in very close proximity to the body such as a backpack:  Specific Absorption Rate (SAR) data provided in FCC filings (if any) only applies to specific certified hardware configurations -- not your particular combination of radio, feedline, antenna, and operating environment.  Be safe!  Reduce transmitter power in the LoRa module settings, use low-gain antennas, position antennas away from the body, and use the Client Mute device role to reduce transmitter activity.

What are the differences in the various LoRa board types -- ESP32, nRF52840, etc.?

ESP32 boards are the most common and usually the least expensive.  This includes the Heltec V3/V4 family, many LILYGO T-Beam and T-LoRa boards, T-Deck, Station G2, and similar devices.  They offer Wi-Fi, Bluetooth, plenty of processing power, and broad hardware support, but generally consume more power than nRF52 boards.  They are a good choice for plugged-in gateways, MQTT nodes, vehicles, and general experimentation.

nRF52840 boards consume less power.  Examples include the RAK WisBlock 4631, Heltec T114, LILYGO T-Echo, Seeed Wio Tracker, and Nano G2 Ultra.  They have Bluetooth but normally no built-in Wi-Fi, and their excellent sleep efficiency makes them especially suitable for handheld, battery-powered, and solar nodes. 

There are also a few other classes:

• RP2040 boards, such as the RAK WisBlock 11310 and various Waveshare or DIY Pico-style LoRa boards.  These are inexpensive and flexible but are less common than ESP32 and nRF52840 devices.

• STM32WL boards, which combine an STM32 processor and LoRa radio in one chip.  These can be very power-efficient and compact, although the Meshtastic selection is smaller.

• Linux-based nodes, where Meshtastic runs as a native program on a Raspberry Pi or other Linux computer connected to a compatible LoRa radio.  These are most useful for gateways, servers, testing, and fixed infrastructure rather than handheld use.

In summary:

• ESP32: inexpensive, Wi-Fi capable, feature-rich, higher power consumption.

• nRF52840: much better battery life, ideal for portable and solar use.

• RP2040/STM32WL: more specialized or DIY-oriented.

• Linux: fixed gateway or server applications.

My battery is draining really fast.  What adjustments can I make?

Here are a few things to try:

• Reduce GPS beacon interval or disable GPS entirely

• Reduce or turn off telemetry beacons

• If the node is not likely contributing coverage to the overall mesh (such as indoor nodes) set the Device role to Client Mute.  This will disable the retransmission of other nodes' packets.

• Reduce transmitter power;  offset TX power reduction with a higher-gain antenna

• Check device display backlight settings, if applicable.  Reduce backlight intensity if possible and shorten the timer in the Display settings.

• Turn off WiFi if not needed and disable the MQTT module.

ESP32-based boards like the Heltec V3/V4 will drain batteries much faster than more efficient architectures like nRF52840.

Is there a RATS channel or MQTT service?

No.  The standard #LongFast public channel and public MQTT service should be adequate for most uses.