Custom solar node (nRF52840 + WioSX1262): halved RX current and fixed cold-weather brownouts — PPK2 data inside

[JBAU92]

I designed a solar Meshtastic node from scratch — custom PCB, enclosure, and firmware patches — specifically to solve the "solar deep sleep coma" that kills unattended nRF52 deployments. Sharing the full build and the data here.

The problem (why stock firmware kills solar nodes)

If you've deployed a solar node on nRF52, you've probably experienced this: a few cloudy days drain the battery, the node enters deep sleep, the sun comes back, the battery charges to 4.2V... and the node stays dead. You have to physically go reset it.

I documented the root causes in #9699 and published a working fork at JBAU92/firmware_solar_fix. Here's the summary:

1. No wake-up mechanism on XIAO/ProMicro variants. The variant.h files for seeed_xiao_nrf52840_kit and promicro define BATTERY_PIN and ADC_MULTIPLIER but completely omit BATTERY_LPCOMP_INPUT and BATTERY_LPCOMP_THRESHOLD. Without LPCOMP, the nRF52 hardware comparator never fires — so once the node enters SYSTEM_OFF, nothing can bring it back except a physical reset.

2. Default OCV curve is too aggressive. The stock OCV array pushes the node down to ~3.1V before triggering shutdown. At this voltage, the LDO is already in dropout — it can't hold a stable 3.3V rail. A single LoRa TX spike causes an immediate brownout, bootloop, or memory corruption (see also #8789) before the PowerFSM can trigger a clean SYSTEM_OFF.

3. SX1262 RX duty cycle is effectively 100%. RadioLib sets a minimum of 8 preamble symbols (×2 for worst case), which keeps the radio awake continuously in RX, consuming ~7.5 mA. For a single 18650 + small panel, the power budget simply doesn't close.

The fixes

Fix 1 — LPCOMP hardware wake-up. Injected the missing macros into the variant files: mapped the battery pin to NRF_LPCOMP_INPUT_7 with NRF_LPCOMP_REF_SUPPLY_3_8 threshold (~3.71V). The nRF52 hardware comparator now monitors the battery in SYSTEM_OFF at negligible current draw and triggers an automatic reset when the solar panel charges the cell back above 3.7V.

Fix 2 — Safe OCV curve. Redefined the 0% battery threshold to 3.4V. The node shuts down cleanly while there's still enough energy for a stable SYSTEM_OFF state, leaving a margin for the LDO and enough residual charge for the next morning's boot.

Fix 3 — Preamble symbol reduction. Lowered the minimum symbols from 8 to 5. The SX1262 now properly cycles its internal sleep/wake states during preamble detection. No packet loss observed in my local tests.

PPK2 results

Metric | Stock firmware | With fixes -- | -- | -- Average RX idle current | ~7.5 mA | ~4.5 mA Recovery after full battery depletion | ❌ Dead forever | ✅ Auto-wakes at ~3.7V Shutdown behavior near empty | Brownout / bootloop / corruption | Clean SYSTEM_OFF at 3.4V Estimated runtime (3000 mAh, no solar) | ~16 days | ~28 days

All measurements taken with Nordic PPK2 at battery terminals. The full power analysis is in the video below with timestamps.

The hardware: FARO Node v1.0
This isn't just a firmware patch — I designed a full custom PCB around the XIAO nRF52840 + Wio-SX1262 optimized for autonomous solar operation:

Single 18650 holder with solar charge circuit

SMA antenna connector

3D-printed weatherproof enclosure

Power delivery layout optimized for clean LoRa TX without voltage spikes on the rail

Resources
🎥 Full video walkthrough (power analysis with PPK2 timestamps, PCB design, assembly):
FARO Node v1.0 — Fabrication Files & Assembly Guide (Solar Meshtastic Node)

[06:06–10:00] Sleep/wake threshold analysis and fix

[11:52–16:30] RX duty cycle profiling and preamble optimization

🔧 Firmware fork (ready-to-flash .uf2 for RAK4631, XIAO nRF52840, ProMicro):
JBAU92/firmware_solar_fix

🐛 Issue with full technical discussion:
#9699

📐 Full design package (gerbers, BOM, 3D print files):
FARO Node v1.0 — Fabrication Files & Assembly Guide

Community validation
Several users have already tested the firmware fix on their own deployments — see the discussion in #9699. I'm considering submitting a PR if there's interest from the core team. Happy to discuss the approach, share additional PPK2 captures, or debate the threshold values.