Meshtastic Solar Node: Planning a Solar Repeater

A solar Meshtastic node is a radio with a battery and panel, placed somewhere high to extend coverage, and the official guidance for planning one comes down to three things: choose a role that fits the site, measure the node’s real energy use before sizing the panel and battery, and test everything before you install it somewhere hard to reach. The Meshtastic project doesn’t publish a standard panel or battery size, because power draw depends on the hardware, role, preset, and how busy your mesh is.

This is a planning guide compiled from the official docs and blog. LoRa Mesh Atlas has not built or measured solar nodes, and we don’t quote wattage figures that the official sources don’t provide. For hardware options, see /devices/.

Step 1: Decide what the node is for

“Solar repeater” can mean different things, and the right role follows from the job.

Situation	Role the docs point to	Why
Rooftop or high spot near home, helping the local mesh	CLIENT	The tips page lists rooftop and high-visibility installations as good fits for CLIENT, which still relays.
Roof or attic node serving your own handheld nodes	CLIENT_BASE	Gives priority to your favorited nodes (Device config).
Mountaintop or tower with exceptional coverage, coordinated with your mesh	ROUTER	“ONLY suitable for stationary devices placed in extremely strategic locations” (role blog).
Fixed site that is the only path out for a blocked area (canyon, far side of a hill)	ROUTER_LATE	Designed for sites “critical for reliable passage of traffic, but known to not be optimally sited for serving the overall mesh” (ROUTER_LATE blog).
Weather or environmental station	SENSOR	Prioritizes telemetry and can sleep between readings.

The docs are firm that misusing ROUTER hurts a mesh: it increases collisions, uses up hops early, and can create one-way links. The ROUTER_LATE post specifically says that role is “not intended as a rooftop node to extend the range of devices inside your house.” Talk to your local group before deploying any infrastructure role. Our roles guide covers this in depth.

Step 2: Understand power-saving behavior

How a node sleeps depends on chip family and role (Device config, Power config):

• ESP32, power saving on: Bluetooth, Wi-Fi, serial, screen, and GPS shut down, and the CPU enters a low-power state. “The LoRa radio will be left on stand-by for receiving any packets which will wake up the device.” So the node can still relay.
• ESP32, ROUTER role: power saving is enabled automatically “and cannot be turned off.” Because that disables Bluetooth, the docs suggest using remote admin to change settings.
• ESP32 or nRF52, SENSOR and TRACKER with power saving: the node sleeps for its reporting interval, wakes to send, then sleeps again. “The LoRA radio does not remain in standby mode to accept packets.” These roles won’t relay while asleep, so they’re poor choices for a relay site.

The Power Configuration page opens with advice worth repeating: power settings are advanced, and “most users should choose a role under Device Config to manage power for their device and shouldn’t ever need to adjust these settings.”

Chip family

The official Getting Started page says “the nRF52 chip is much more power efficient than the ESP32 chip,” and describes nRF52 as “ideal for battery-powered and solar deployments.” It also notes nRF52 has Bluetooth but no Wi-Fi. If you need a Wi-Fi gateway (for MQTT, for example), that changes the trade-off. Our device database lists each board’s MCU, and the finder can filter by it.

Routine traffic

Fewer transmissions mean less energy. By default a node broadcasts NodeInfo every 3 hours. In firmware 2.8 (an alpha as of October 2026), device telemetry and position broadcasts are off unless enabled; when enabled, their default interval is 1 hour, or 12 hours for ROUTER and ROUTER_LATE (Mesh Broadcast Algorithm). The 2.8 announcement lists this as a change from 2.7, so on 2.7 check these settings yourself. A relay node’s biggest variable load is the traffic it relays for others.

Step 3: Measure energy use, then size panel and battery

The Meshtastic blog post Measure power use for a solar Meshtastic node lays out the official method:

1. Measure energy over time, not one reading. Nodes spend much of their time listening and draw more when transmitting. Use a meter or bench supply that totals watt-hours or amp-hours, and check it can resolve low currents.
2. Run it long enough. At least an hour; two to six hours gives a more useful average.
3. Match the field setup. Use the same role, region, modem preset, and power settings. For a solar router, measure the energy it uses relaying traffic.
4. Simulate relaying with three nodes. A sender, the node under test, and a receiver placed so it only hears the sender through the test node. The post includes a short Python script that sends a message every two minutes with a hop limit of 1.
5. Don’t test on a populated mesh. Use a frequency slot local users aren’t using, since nearby nodes can relay your test packets.
6. Do the math. Average power = energy ÷ test duration. Multiply by 24 hours for daily energy. Then size the panel and battery “allowing for weather and system losses.”

The post’s worked example (a 3-hour test at 5.1 V using 142 mAh, about 241 mW average and about 5.8 Wh per day) illustrates the arithmetic only. It is not a typical figure for any particular device, and your measurement will differ.

Step 4: Battery, charging, and temperature

The official Meshtastic docs we reviewed don’t give battery chemistry recommendations or temperature limits for solar builds. What they do provide:

• Battery reading calibration. If the battery percentage is wrong, the Power config page explains the ADC multiplier override and a calibration process.
• Shutdown after losing power. An option to shut down after a set time without external power, with a warning to confirm your board detects external power correctly first.
• Power monitoring. With a supported current/voltage sensor, the apps can chart voltage and current per channel; the Android docs call this useful for monitoring solar charging or battery health (Android telemetry).

For charge and discharge temperature limits, follow the datasheets for your specific battery cell and charge controller. Outdoor enclosures can get much hotter or colder than ambient air, so check those limits against your local climate before choosing parts.

Step 5: Enclosure and antenna

From the official antenna selection page:

• Keep cable runs short. “It is often more effective to place a node outside than to have it indoors with the antenna outside,” except in extreme heat, cold, or humidity, and then only with “the shortest possible low loss cable.” It adds that “a proper enclosure should mitigate bad weather.”
• Avoid mounting flush against a building. Signal toward the wall is “largely lost or attenuated.”
• Use an antenna tuned for 902–928 MHz with matching impedance and connector, and never transmit without one connected.
• Ground planes matter for many antenna types.

The docs’ community section lists enclosure projects, including 3D-printed solar cases, but those are community contributions rather than official recommendations.

Step 6: Site it with data

• Model coverage first. The official Site Planner (site.meshtastic.org) predicts coverage from terrain. Its docs note the elevation data is accurate to about 90 meters and ignores buildings and trees.
• Check the geometry. Our range tool estimates radio horizon and Fresnel zone clearance for a given antenna height.
• Collect real data. The role blog suggests “collecting some real world data on the mesh first” before choosing an infrastructure site.

See the Meshtastic range guide for why height and line of sight dominate.

Step 7: Plan for remote management and security

• Test before you climb. The tips page: “TEST your settings and hardware before you install in hard-to-reach locations.”
• Set up remote admin. Since firmware 2.5, a node accepts admin messages only from up to three authorized public keys (Security config). Confirm it works before deployment.
• Back up keys before you flash or deploy (flashing guide).
• Leave private channels off unattended nodes. The Encryption docs advise: “Do not configure private channels on unattended nodes.” Relays don’t need the key, and physical access makes keys easy to extract.
• Use the right preset. A solar node only helps if it’s on the same preset and slot as your mesh (presets guide).

Summary checklist

• Role chosen for the site, coordinated with local operators
• Hardware chip family suited to the power budget (nRF52 favored for solar by the docs)
• Energy measured over hours under realistic relay load
• Panel and battery sized from that measurement, with margin
• Battery and charger temperature limits checked against the datasheets and your climate
• Weatherproof enclosure, short cable, tuned antenna, mounted clear of walls
• Remote admin tested, keys backed up, no private channel keys on the node