↵ select ↓ ↑ navigate esc close

Sizing a Solar Node Starts with One Number

Meshtastic Blog ·

Sizing a solar panel and a battery starts with one number: how much power your node draws. Panel wattage, battery capacity, and how many overcast days a site survives are all calculated from it. Guess that number and the deployment either dies in its first bad week or carries an expensive panel it never needed.

The number is harder to pin down than a single meter reading suggests. A node spends most of its life listening, transmits in short bursts that cost several times more, and sets its own transmission schedule from firmware defaults that shift with the size of the mesh around it.

A watt is a rate. It describes how fast a device consumes energy at the moment you look, and says nothing about how much it consumes over a day. Multiply volts by amperes to get it: 5 V x 50 mA = 250 mW.

Energy is that rate multiplied by time, expressed in watt-hours. A node drawing a steady 250 mW for 24 hours consumes 24 h x 250 mW = 6000 mWh, or 6 Wh. Panel and battery sizing works from the energy figure, not the rate.

A node's draw isn't steady, which is what makes the distinction matter. Receiving costs relatively little. Transmitting costs several times more and happens in bursts lasting a fraction of a second. A reading taken while the radio is idle understates the average, and one caught mid-transmission overstates it. Neither describes a day.

The fraction of time a radio spends transmitting is its duty cycle. Deriving it from the transmit and receive currents on a datasheet means guessing how often each happens. Measuring the node under realistic traffic lets the meter average the two instead.

The meter has to accumulate energy over time rather than display an instantaneous value. A bench supply with a running ampere-hour or watt-hour total works, as does a USB power meter that keeps a cumulative figure. An ordinary multimeter does not, because it shows the present reading and forgets it.

Resolution matters as much as the accumulating total. A node in a low-power state can sit at a few milliamperes, and a meter that rounds to the nearest 10 mA records that as nothing at all. Check that yours resolves the smallest current you expect, at the voltage you plan to run the test at.

A node transmits on its own without anyone sending a message. These background broadcasts announce that the node is alive, carry its position and telemetry, and keep other nodes' databases current. They're the floor under a power budget, and on a quiet mesh they account for most of it.

Each role carries its own broadcast defaults, and the role moves the power floor further than any other single setting. Selecting a role rewrites these intervals, so a node measured as a Client tells you little about the same hardware deployed as a Router. The firmware 2.8 defaults:

RolePositionNode infoDevice telemetryClient1 hour3 hours1 hourClient Mute1 hour3 hours1 hourClient Base1 hour3 hours1 hourRouter12 hours3 hours12 hoursRouter Late12 hours3 hours24 hoursTracker1 hour3 hours1 hourSensor1 hour3 hours1 hourTAK24 hours24 hours24 hoursTAK Tracker3 minutes24 hours24 hoursLost and Found5 minutes3 hours1 hourClient HiddenNoneNoneNone

Client is the role a node ships with. Client Hidden sets every routine broadcast to an interval long enough that it never fires, while still rebroadcasting to known meshes.

Two roles carry extra traffic the table doesn't show. Sensor enables environment telemetry every 5 minutes, and TAK Tracker enables smart broadcast with a minimum distance of 20 m and a minimum interval of 15 seconds, so a TAK Tracker in motion transmits far more often than its 3-minute position interval suggests.

Broadcasts aren't acknowledged the way direct messages are. Other nodes rebroadcast them, and the original sender can overhear that rebroadcast as an implicit acknowledgement. The power cost of a broadcast therefore lands on every node that repeats it, not only on the one that sent it.

Three firmware behaviors move those intervals, and each one changes a measurement:

  • Intervals scale with the size of the mesh. The firmware stretches broadcast intervals as the number of online nodes rises, so a node on a 60-node mesh transmits less often than the same node on a three-node mesh. Testing on a mesh smaller than the deployment overstates consumption.
  • A fixed position holds a six-hour floor. Setting a node to a fixed position pins its position broadcasts to once every six hours, and configuring a shorter interval doesn't override that. The same floor applies to any node that hasn't moved since its last broadcast.
  • The public channel enforces its own minimums. A node broadcasting position on the default channel has its interval raised to at least one hour whatever the configuration says.

Airtime gates transmission on top of all of it. The firmware holds off when channel utilization over the previous minute reaches 25%, or 40% for the tracker roles, and when the node's own transmit time reaches half the duty cycle its region allows. A node on a congested mesh transmits less often than its intervals request, and draws less power as a result.

Earlier guidance suggested simulating message traffic by lowering a fixed-position node's position broadcast interval to one or three minutes. That approach doesn't work on firmware 2.8. The six-hour floor overrides the shorter interval, the node transmits no more often than it would have, and the test measures an idle node.

Generate the traffic explicitly instead.

Use at least two nodes, and get as close to the size of the deployment mesh as you can, because interval scaling depends on it. Configure the node under test the way it will be deployed: the same role, modem preset, and region, paired to a phone over Bluetooth only if it will be in the field.

Drive the traffic from a second node with the CLI. A loop is repeatable and doesn't depend on anyone remembering to send a message:

1
2while true; do
3
4  meshtastic --sendtext "power test"
5
6  sleep 120
7
8done

The CLI talks to a node over USB serial by default. To drive one over Wi-Fi, add --host <NODE_IP_ADDRESS>, taking the address from the node's network settings.

Set the interval to the message rate you expect. A message every two minutes is 30 an hour, which is a busy mesh. Every 10 minutes is six an hour, which is closer to most.

The node under test rebroadcasts what it hears, and that's where much of its transmit time goes. If it will also originate messages in the field, send some from it during the test as well.

warning

Airtime is shared by every node within radio range on the same frequency and preset, and a private channel does not isolate a test from the mesh around it. Keep the message rate no higher than the traffic you're modeling, and do not leave a fast loop running longer than the test needs.

Run the test for at least an hour. Two to six hours gives a result worth trusting, provided the conditions resemble the deployment. Reset the meter's accumulated total before starting, note the start time, and stop on the same minute of the hour to keep the arithmetic simple.

Divide the accumulated energy by the length of the test.

A meter that reads in watt-hours needs no conversion. A three-hour test accumulating 0.72 Wh gives 0.72 Wh / 3 h = 240 mW.

A meter that reads in ampere-hours needs the test voltage as well. Multiply the accumulated ampere-hours by the voltage, then divide by the duration. A three-hour test at 5.1 V reading 142 mAh works out as:

  • 5.1 V x 142 mAh = 724.2 mWh
  • 724.2 mWh / 3 h = 241.4 mW

An average draw of 241.4 mW is the figure to carry into panel and battery sizing.

Multiplying the average by 24 gives the energy the site has to supply each day, so 241.4 mW x 24 h is about 5.8 Wh. Panel and battery sizing starts from that, with margin added for overcast days and for losses in the charge controller and the battery.

Where the result is more than a site can support, the settings that shape it are documented in Power Configuration and Position Configuration. Lengthening broadcast intervals and enabling power saving both trade visibility on the mesh for runtime.

About this post​

This material was contributed by KeithMon in 2023 as a standalone documentation page. It moves to the blog as part of a reorganization of the hardware documentation, where guidance of this kind sits better than it does among reference material, and the measurement procedure has been updated for firmware 2.8.

Read original article →