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.

[valentinmariusdynu-tech]

Hi JBAU92,

This is extremely relevant to an architecture decision we are currently keeping open for Signal For All, a Romanian accessibility project developing an early-stage wearable concept for blind and partially sighted athletes.

We are deliberately comparing nRF52840 + SX1262 against ESP32-S3 + SX1262 before hardware freeze, and your PPK2 work, RX-current optimisation, brownout/recovery analysis and custom FARO PCB are exactly the kind of real engineering evidence we are looking for.

Our use case is different from a solar node: it is a small body-worn device operating during dynamic sport, potentially combining LoRa with haptic and/or short local audio output. Messages are small and time-sensitive, and stale information may need to be discarded rather than delivered late.

I would greatly value your independent view on how you would adapt the lessons from FARO to this kind of wearable — particularly RX-heavy power behaviour, SX1262 power states, nRF52840 suitability, RF/body effects and how lightweight the communication protocol could become.

Would you be open to a short 20–30 minute technical conversation?

If so, I can send you a concise visual Technical One-Pager and continue by email.

Best regards,
Marius-Valentin Dinu
ACS Signal For All | Romania
contact@signalforall.ro
signalforall.ro

[JBAU92]

Dear Marius-Valentin, Thank you for reaching out and for your interest in my work. Your project, "Signal For All," sounds very interesting. Regarding your request, I would be happy to help, but I must mention that I do not speak English fluently. For that reason, I would prefer to keep our communication strictly via email, as it allows me to translate and respond more accurately. Could you please clarify exactly what you are looking for or what specific information you need from me? Please feel free to send the technical One-Pager you mentioned via email. Best regards, Javi El sáb, 29 ago 2026 a las 20:48, valentinmariusdynu-tech (< ***@***.***>) escribió:

…

Hi JBAU92, This is extremely relevant to an architecture decision we are currently keeping open for Signal For All, a Romanian accessibility project developing an early-stage wearable concept for blind and partially sighted athletes. We are deliberately comparing nRF52840 + SX1262 against ESP32-S3 + SX1262 before hardware freeze, and your PPK2 work, RX-current optimisation, brownout/recovery analysis and custom FARO PCB are exactly the kind of real engineering evidence we are looking for. Our use case is different from a solar node: it is a small body-worn device operating during dynamic sport, potentially combining LoRa with haptic and/or short local audio output. Messages are small and time-sensitive, and stale information may need to be discarded rather than delivered late. I would greatly value your independent view on how you would adapt the lessons from FARO to this kind of wearable — particularly RX-heavy power behaviour, SX1262 power states, nRF52840 suitability, RF/body effects and how lightweight the communication protocol could become. Would you be open to a short 20–30 minute technical conversation? If so, I can send you a concise visual Technical One-Pager and continue by email. Best regards, Marius-Valentin Dinu ACS Signal For All | Romania ***@***.*** signalforall.ro — Reply to this email directly, view it on GitHub <#478?email_source=notifications&email_token=B6UBS3S2JUAH2RGKAFHPJD35MMQOTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYTANJVUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18201055>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B6UBS3X6UEIPXNHRFOTTFX35MMQOTAVCNFSNUABHKJSXA33TNF2G64TZHM4DONRSHE3DQMZSHNCGS43DOVZXG2LPNY5TSOBTGM4TAMNBOYBA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/B6UBS3QITNE77FU4WGL5CKL5MMQOTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYTANJVUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/B6UBS3X4UH75CT6NXUPBYND5MMQOTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYTANJVUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[valentinmariusdynu-tech]

Dear Javi, Thank you very much for your reply and for being willing to help. “Please feel completely free to write in the language in which you are most comfortable; I can translate your response.” Email communication is absolutely fine — and actually very useful for us, because it allows us to document the engineering reasoning accurately. Please feel completely free to write in the language in which you are most comfortable; I can translate your response. I am attaching the Signal For All Technical One-Pager I mentioned. To clarify exactly what we are looking for: Signal For All is currently before hardware architecture freeze. We have functional and accessibility requirements, but we deliberately want qualified engineers to challenge the technical solution before we build a custom prototype. We are not asking you to design the complete device. Your experience is particularly valuable to us because you have actually built and measured an nRF52840 + SX1262 system, including RX power behaviour, power-state problems, brownout/recovery and custom PCB implementation. At this stage, I would greatly value your opinion on the following questions: 1. MCU / platform For a small battery-powered wearable used during approximately 1–3 hours of sporting activity, would you prefer: nRF52840 + SX1262 or ESP32-S3 + SX1262? What would be the main reasons for your choice? 2. RX power Our device may need to remain ready to receive short messages during a sporting session. Based on your PPK2 work, what RX strategy would you consider realistic if we need a good compromise between responsiveness and battery consumption? 3. Communication protocol Our messages would be extremely small and time-sensitive. Examples might be contextual cues such as position, player-related information or another short sporting reference. A message that arrives too late may become useless or even distracting. For this use case, would you: keep Meshtastic; simplify/customise Meshtastic; use a dedicated lightweight protocol; or consider another approach? 4. RF / body-worn operation What RF and antenna problems would you expect when an EU868 SX1262 device is worn close to the human body and used during movement? What would you test before PCB design? 5. Power architecture The wearable may eventually include: nRF52840 or ESP32-class MCU; SX1262; haptic actuator; possibly short local audio output; battery monitoring; simple physical controls. What power-design mistakes would you specifically try to avoid? Your FARO work on brownout and clean recovery was particularly interesting to us. 6. Failure and recovery We are considering states such as: NORMAL → DEGRADED → LOW BATTERY → SAFE STATE → RECOVERY and communication states such as: SENT → RELAYED → ACKNOWLEDGED → USER CONFIRMED From an embedded engineering perspective, does this direction make sense? What would you change? 7. Before custom PCB Finally, if you were in our position: What are the 5 things you would insist on proving with development hardware before designing the first custom PCB? Please do not feel that you need to answer everything at once. Even comments on the areas where you have the strongest experience would be extremely valuable. And please challenge any assumption you disagree with. That is exactly why I contacted you. Thank you again for your willingness to contribute. Technology supports. The athlete decides. Best regards, Marius-Valentin Dinu ACS Signal For All | Romania signalforall.ro ***@***.*** Facebook: Signal For All Instagram: @signal.for.all

…

On 2026-08-29 22:29, JBAU92 wrote: Dear Marius-Valentin, Thank you for reaching out and for your interest in my work. Your project, "Signal For All," sounds very interesting. Regarding your request, I would be happy to help, but I must mention that I do not speak English fluently. For that reason, I would prefer to keep our communication strictly via email, as it allows me to translate and respond more accurately. Could you please clarify exactly what you are looking for or what specific information you need from me? Please feel free to send the technical One-Pager you mentioned via email. Best regards, Javi El sáb, 29 ago 2026 a las 20:48, valentinmariusdynu-tech (< ***@***.***>) escribió: > Hi JBAU92, > > This is extremely relevant to an architecture decision we are currently > keeping open for Signal For All, a Romanian accessibility project > developing an early-stage wearable concept for blind and partially sighted > athletes. > > We are deliberately comparing nRF52840 + SX1262 against ESP32-S3 + SX1262 > before hardware freeze, and your PPK2 work, RX-current optimisation, > brownout/recovery analysis and custom FARO PCB are exactly the kind of real > engineering evidence we are looking for. > > Our use case is different from a solar node: it is a small body-worn > device operating during dynamic sport, potentially combining LoRa with > haptic and/or short local audio output. Messages are small and > time-sensitive, and stale information may need to be discarded rather than > delivered late. > > I would greatly value your independent view on how you would adapt the > lessons from FARO to this kind of wearable — particularly RX-heavy power > behaviour, SX1262 power states, nRF52840 suitability, RF/body effects and > how lightweight the communication protocol could become. > > Would you be open to a short 20–30 minute technical conversation? > > If so, I can send you a concise visual Technical One-Pager and continue by > email. > > Best regards, > Marius-Valentin Dinu > ACS Signal For All | Romania > ***@***.*** > signalforall.ro > > — > Reply to this email directly, view it on GitHub > <#478?email_source=notifications&email_token=B6UBS3S2JUAH2RGKAFHPJD35MMQOTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYTANJVUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18201055>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/B6UBS3X6UEIPXNHRFOTTFX35MMQOTAVCNFSNUABHKJSXA33TNF2G64TZHM4DONRSHE3DQMZSHNCGS43DOVZXG2LPNY5TSOBTGM4TAMNBOYBA> > . > Triage notifications, keep track of coding agent tasks and review pull > requests on the go with GitHub Mobile for iOS > <https://github.com/notifications/mobile/ios/B6UBS3QITNE77FU4WGL5CKL5MMQOTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYTANJVUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> > and Android > <https://github.com/notifications/mobile/android/B6UBS3X4UH75CT6NXUPBYND5MMQOTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYTANJVUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. > Download it today! > You are receiving this because you authored the thread.Message ID: > ***@***.***> > -- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS [3] and Android [4]. Download it today! You are receiving this because you commented.Message ID: ***@***.***> Links: ------ [1] #478?email_source=notifications&email_token=CBRAUD3RB6REIWI46ADC5R35MMVFZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYTGMRUUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18201324 [2] https://github.com/notifications/unsubscribe-auth/CBRAUD6DBP4NISBXDCVORDD5MMVFZAVCNFSNUABHKJSXA33TNF2G64TZHM4DONRSHE3DQMZSHNCGS43DOVZXG2LPNY5TSOBTGM4TAMNBOYBA [3] https://github.com/notifications/mobile/ios/CBRAUDYCDQP6J543SUIUXU35MMVFZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYTGMRUUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ [4] https://github.com/notifications/mobile/android/CBRAUD4TP6LTXDRXRSQ5HFL5MMVFZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSGAYTGMRUUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ