MeshAtlas

Independent communication. Community-built coverage. Beyond mobile networks and internet dependency.

Troubleshooting a Meshtastic Node That Cannot Be Heard

A layered checklist for a node that appears powered but produces no useful radio presence.

Start locally

Confirm the device boots, remains powered and can be reached through its local interface. Check logs where available. Verify the firmware target matches the hardware and that the radio is detected. A display or Bluetooth connection proves the microcontroller is running, not that the LoRa transmitter and antenna path work.

Inspect for restart loops, low voltage, overheating and power-saving behavior. Test with a stable supply and a known-good data cable before climbing to the site.

Verify the antenna before transmitting

Never intentionally transmit without an appropriate antenna attached. Inspect the connector type carefully: SMA and RP-SMA parts can mechanically mate in confusing combinations while leaving the expected center contact absent. Check pigtails, adapters, bulkheads, water ingress and coax damage. Confirm the antenna is for the correct frequency band.

Check the radio layer

Compare the legal region, band, modem preset and frequency slot with a known-good nearby node. Custom modem parameters must also match. Move the test nodes close enough for a reliable link but not so close that abnormal receiver overload becomes a concern. Send explicit messages rather than waiting only for periodic NodeInfo or position packets.

Check the message layer

Compatible radios can exchange or relay packets without displaying readable messages when channel keys differ. Confirm the channel index, name and pre-shared key. Check whether uplink/downlink, rebroadcast mode, role, hop limit or ignored message types affect the test. Use a fresh controlled test channel only as a diagnostic step; do not overwrite the production configuration without a backup.

Determine whether it transmits or receives

TestInterpretation
Node hears nearby known-good packetsReceiver and configuration may work; inspect its transmit path
Nearby node hears its packetsTransmitter works; inspect receive path or application/channel display
Neither direction works nearbyConfiguration, antenna connection, radio hardware or firmware target
Works nearby but not installedSite, feed line, antenna, noise, power or coverage assumption

Inspect infrastructure-specific causes

At a remote site, compare current battery voltage and temperature with installation records. Look for solar-charge failure, corrosion, condensation, loose mast connections, animal damage and a water-filled coax. Confirm that a remote configuration change did not alter region, preset, slot, role or power behavior. Check whether the node’s name changed after a reset, making it appear absent under its old identity.

Escalate without destroying evidence

Record the current state before factory-resetting or reflashing. Export configuration and logs, photograph connections and change one variable at a time. Substitution with a known-good radio, antenna and supply is usually faster than guessing. If the node is on an exposed mast or roof, follow the site safety and access plan; radio troubleshooting does not justify unsafe climbing.

Follow the layers in order

Use a fixed order: power and boot, radio detection, antenna path, regional/modem compatibility, channel access, packet behavior, installed-site propagation and mesh routing. Moving randomly between factory resets, antennas and app settings destroys evidence. Note each test and its result so another maintainer can continue without repeating work.

If the node was previously operational, begin with what changed: storm, power outage, firmware update, battery replacement, new nearby equipment, host work on the roof or remote configuration.

Return-to-service test

After finding the fault, restore the documented production configuration and repeat the commissioning tests. Verify short-range transmit and receive, planned remote endpoints, power recovery and telemetry. Update the maintenance log with the failed component or setting. If coverage remains unverified, mark the public listing degraded or inactive rather than assuming the old map is still valid.

Related troubleshooting guides

Official sources

Firmware, applications and documentation change over time. Confirm current setting names and applicable regional rules before commissioning or changing live infrastructure.

Share with