NWI Mesh Net
Discord
Guides

SenseCAP Solar Node P1-Pro

Recommended settings for the SenseCAP P1-Pro solar node.

TL;DR: A SenseCAP solar node must be quiet, predictable, and power efficient. Use long intervals, Smart Position, coarse or approximate location on public channels, conservative LoRa settings, and minimal telemetry. A well-configured solar node strengthens the mesh without wasting airtime or battery.

Purpose of a SenseCAP Solar Node

SenseCAP solar nodes are infrastructure nodes. Their job is not frequent updates or user interaction, but stable relay service over long periods on limited power.

  • Remain online continuously
  • Relay traffic reliably
  • Minimize airtime usage
  • Preserve battery during low-sun conditions

Every enabled feature has a cost. Solar nodes must be configured intentionally.

Device Configuration

  • Device Role: Client
  • Rebroadcast Mode: All
  • Node Info Broadcast Interval: 3–6 Hours

This allows the node to participate in routing without frequent self-announcement.

Avoid:

Do not reduce Node Info Broadcast intervals on solar nodes. Frequent node info packets waste airtime and battery.

Position Configuration

Position reporting is one of the largest contributors to airtime usage and power draw.

If the node is permanently mounted, use Fixed Position

A node bolted to a roof, silo, or mast is never going to move, so there is no reason to ask a GPS receiver where it is for the rest of its life. Set the location once and turn the GPS off:

  • Fixed Position: On
  • Latitude / Longitude / Altitude: entered once, by hand
  • Device GPS: Disabled (GPS mode: NOT_PRESENT)
  • Position Broadcast Interval: 1 to 6 hours
  • Smart Position: Off (it does nothing on a node that cannot move)

This is the single easiest power and airtime win on a solar install. The GPS receiver is one of the largest continuous loads on the board, and every fix it takes is energy spent re-discovering a location you already know.

Set the coordinates from your phone while you are standing at the install point, before the node goes up.

If the node is portable, use Smart Position instead

For a node that actually moves (a spare you relocate, a node in a vehicle):

  • Smart Position: On
  • Device GPS: Enabled
  • GPS Update Interval: 6 hours or longer
  • Broadcast Interval (Fallback): 1 to 6 hours
  • Minimum Interval: 5 to 10 minutes
  • Minimum Distance: 250 to 500 meters

Smart Position ensures updates only occur when movement is meaningful. Frequent GPS polling dramatically increases power draw, so keep the update interval long.

Position Flags (Keep Packets Small)

Each enabled position flag increases packet size, airtime, and collision risk.

  • Altitude: Optional (fixed infrastructure only)
  • Number of Satellites: Optional
  • Vehicle Speed: Off
  • Vehicle Heading: Off
  • Timestamp: Off

Solar nodes are not trackers. Minimal packets are healthier packets.

Channel Configuration

Primary Channel: LongFast

LongFast is a public, shared infrastructure channel. It must remain low-noise.

  • Channel Role: Primary
  • Position Enabled: On
  • Precise Location: Off
  • Approximate Location: On (0.5–1 mile)
  • Allow Position Requests: On
  • MQTT Uplink: Off (channel level)
  • MQTT Downlink: Off

This confirms node presence without exposing precise location or creating excessive updates.

Secondary / Private Channels

Private channels are optional and should be used sparingly on solar nodes.

  • Position Precision: Precise only if required
  • MQTT: Only enable if explicitly needed
  • Traffic Expectations: Low

Private channels increase wake time and airtime. Avoid unnecessary usage.

LoRa Configuration

LoRa settings determine range, airtime, and congestion behavior.

  • Region: United States
  • Use Preset: Enabled
  • Preset: Long Range – Fast (LongFast)
  • Transmit Enabled: On
  • Number of Hops: 3 (the NWI standard, see Core Technical Configurations)
  • Frequency Slot: 0 (auto)

Increasing the hop limit increases congestion and airtime for everyone, not just you. Leave it at 3.

MQTT Interaction (Radio Level)

  • OK to MQTT: On
  • Ignore MQTT: Off

This allows other nodes to publish this node’s data to MQTT without the solar node maintaining an internet connection.

Do Not:

Do not run MQTT clients directly on solar nodes. MQTT requires persistent connectivity and increases power draw.

Telemetry Configuration

Telemetry is useful but expensive on solar power.

  • Broadcast Device Metrics: On
  • Device Metrics Interval: 2–6 Hours
  • Environment Metrics: On only if sensors are present
  • Environment Metrics Interval: 2–6 Hours
  • Power Metrics: On
  • Power Metrics Interval: 2–6 Hours

Important:

Never use 30-minute telemetry intervals on solar nodes. This rapidly drains batteries and inflates mesh traffic.

Bluetooth Configuration

  • Bluetooth: Enabled (maintenance only)
  • Pairing Mode: Fixed PIN

Bluetooth activity prevents deep sleep. Avoid routine connections after deployment.

Security & Admin Keys

Set this up before the node goes on the roof. It is the difference between fixing a setting from your couch and fixing it from a ladder.

  1. In the Meshtastic app, open Settings → Radio configuration → Security.
  2. Generate or paste a Primary Admin Key (a public key whose private half you hold on your own phone or a trusted node).
  3. Back up the private key somewhere you will still have it in two years. Losing it means losing remote administration of the node.
  4. Do not regenerate keys unless you have to; regenerating invalidates remote admin for that node.

With an admin key set, you can send admin messages to the node over the mesh (or via MQTT) to change settings and reboot it, without physical access. HopWatch's remote-admin scanner will show which of your nodes are reachable this way.

Remote maintenance: check before you climb

Every trip up a ladder that a dashboard could have prevented is a wasted trip, and a risky one in winter.

Before going out to a site, check on it remotely:

  • Last heard — is the node silent, or is it fine and you just cannot see it from home?
  • Battery voltage trend — a slow decline over a cloudy week is a power-budget problem, not a hardware fault. A sudden drop is a charging fault.
  • Channel utilization and air time — a healthy node in a busy area behaves differently than a node that has started spamming.
  • SNR and hops from its neighbors — a node that is up but no longer heard directly usually has an antenna, coax, or water problem, not a firmware problem.

Seasonal patterns worth knowing here: mid-winter is a power-budget failure season (short days, snow on the panel, cold-derated batteries), while spring and summer failures skew toward water ingress and connector corrosion. If a node has been solid for a year and dies in February, suspect the power budget first.

Firmware updates on a remote node

Be conservative. A remote node that fails to boot after an update is a ladder trip in the worst weather of the year.

  • Never flash a remote node you cannot physically reach if it goes wrong, unless you have already run that exact firmware version on an identical bench node.
  • Update the bench node first and leave it running for a few days.
  • Prefer stable releases over the newest tag, and skip updates entirely if the node is working and the release notes do not affect you.
  • Do the update in good weather, in daylight, with the site accessible, not in December.

Summary: Solar Node Best Practices

  • Long intervals preserve battery
  • Permanently mounted nodes use Fixed Position with the GPS off
  • A relaying node does not sleep: size the panel and battery instead (see Power & Sleep Settings)
  • Public channels should never use precise location
  • Telemetry should be measured in hours, not minutes
  • Set an admin key before deployment, and check telemetry before you climb
  • A quiet node is a healthy node

Gear for this build

Updated 2026-08-09